From nobody Fri Feb 2 02:23:45 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B17B124BE8 for ; Fri, 2 Feb 2018 02:23:43 -0800 (PST) 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 ZgIhn7UFuUUv for ; Fri, 2 Feb 2018 02:23:40 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AC65127978 for ; Fri, 2 Feb 2018 02:23:40 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id i141so23230823qke.0 for ; Fri, 02 Feb 2018 02:23:40 -0800 (PST) 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:thread-index:content-language; bh=3GoaS3zearpCtTHn5Oy61ZEAVOkCSiP6ycvHsjdMRa0=; b=JgKQmNLcVCDvI0HjzbhRaSo+HU2VxEhnwU65RVx8Q5UvdY1AWMIoHxeGTOQu0dmxFV s8ZuBhZs6Pp7/epXlwWgdrBzF61pyaMxSFwCTiwBBJOZh/cWg1ZuSNZIZ92PhzL/Ngcv 38TMnnLvSND4Qwci38hVN6PvWrspj0qcldGMMmh2aAWZFoU8AJmLX5rDES5wQvatpP4c cvvTx97bI6SGoxaAL+arH0U3gxLNJDdASER1FRWmgxcRaC8Piv/iijWVJlffnzW+tbb9 ViHIdcLY3l8bEE//O0qXjeeKf0xKrCQso8OUHXxxH5QkRIFVdintNOZBmiNHon69T/ch hQBw== 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:thread-index:content-language; bh=3GoaS3zearpCtTHn5Oy61ZEAVOkCSiP6ycvHsjdMRa0=; b=GpLPEOEcsceA2840cWazEc3cZDPysRwCA3dYTWK/IEyEiA7MASuIXg8kRUTe0FM2DJ lSqjsTgZ2VdRjYsjgdWC1paAciC+7ZMfOM0R4D2lvwOLu0UqR+AT0pPULMIcncJqTmXv /JlVmTOnWJEGSP8+VmN2CV5g/tXj5huUj0F7ZhL84fRCrC9X46eQmQ3lH3uTpJhPDCSx YYBXyQqi8lgzbCYGWPlbTADvk4v3jndPYtqkE7PSTbZas1kG0FbKg6bMFZOWMpJyYG2S NB+9K5Z1iusPu8SHlk6rIjZgMp36e2rhZMdB3qPBAAguMlNCEFPynwhgpdS1unTq2G6P 5Q1A== X-Gm-Message-State: AKwxytdX55JY0HZJqosFiuGeoYjbhTLsAn90Hypntn4YrYEMNIPjOAhe wxpcbFUgzbwWUtDu4Lj90jw= X-Google-Smtp-Source: AH8x226ElUcoKc2KtI13HXYBX3yBayPEobGnvdtiCWQSgrFOMGBdlB0QcgfpbDocRNzXpeCFhBEb8w== X-Received: by 10.55.157.82 with SMTP id g79mr61148005qke.161.1517567019121; Fri, 02 Feb 2018 02:23:39 -0800 (PST) Received: from FrancoisPC (pool-108-48-182-86.washdc.fios.verizon.net. [108.48.182.86]) by smtp.gmail.com with ESMTPSA id f2sm1145481qkb.19.2018.02.02.02.23.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Feb 2018 02:23:37 -0800 (PST) From: =?utf-8?Q?Fran=C3=A7ois_Simon?= To: "'Alexandre Petrescu'" Cc: , References: <1517217856.4315.32.camel@it.uc3m.es> <006601d39910$bdcf1cf0$396d56d0$@gmail.com> In-Reply-To: Date: Fri, 2 Feb 2018 05:23:36 -0500 Message-ID: <000101d39c0f$e3b32f90$ab198eb0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0002_01D39BE5.FAE1E280" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQL7ISfFSBtQJ/i74DjDJlbgILh28gG4su6HASuQMD+hKrdl4A== Content-Language: en-us Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 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: Fri, 02 Feb 2018 10:23:44 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0002_01D39BE5.FAE1E280 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Mr. Petrescu, Let's try one more time to clarify the FCC DSRC (in US only) issue. FCC =E2=80=93 DSRC Background: - The US Federal Communications Commission (FCC) Dedicated Short Range = Communication (DSRC) is defined in the Code of Federal Regulations (CFR) = 47 mainly Parts 90 and 95. The last update is dated October 1st, 2010; - This includes the ASTM E 2213-03 standard: =E2=80=9CStandard = Speci=EF=AC=81cation for Telecommunications and Information Exchange = Between Roadside and Vehicle Systems =E2=80=94 5 GHz Band Dedicated = Short Range Communications (DSRC) Medium Access Control (MAC) and = Physical Layer (PHY) Speci=EF=AC=81cations=E2=80=9D; approved July 10, = 2003. The standard is derived from IEEE 802.11a and, in most part, is = equivalent to IEEE 802.11 OCB. To date, the DSRC CFRs do not specify = IEEE 802.11 OCB. - The related CFRs state that DSRC shall comply with the ASTM E 2213-03. Overview of DSRC functions: The functions listed in DSRC related CFRs are, in general, specified in = the ASTM E 2213-03 and IEEE 802.11 OCB: - MAC service definition, frame format, and procedures; - PHY Orthogonal frequency division multiplexing (OFDM);=20 - PHY Service Data Unit format and modulations (data rates): - 5.9 GHz band allocated channels, frequency, max. EIRP, and spectrum = mask; - Individual Channel use: Safety applications, non-safety applications, = and priorities.=20 Protocols DSRC being uniquely a MAC and PHY communications service, there here no = restriction on Transport and Network protocols that can be used (except = for the LCC specified by reference in IEEE 802.11 OCB). In the US, the = WAVE standards (IEEE 1609 series) specify these protocols when using = DSRC as the communication service. OBU / RSU The CFR (FCC) definitions are: Roadside unit (RSU). A Roadside Unit is a DSRC transceiver that is = mounted along a road or pedestrian passageway. An RSU may also be = mounted on a vehicle or is hand carried, but it may only operate when = the vehicle or hand- carried unit is stationary. Furthermore, an RSU = operating under this part is restricted to the location where it is = licensed to operate. However, portable or hand-held RSUs are permitted = to operate where they do not interfere with a site-licensed operation. A = RSU broadcasts data to OBUs or exchanges data with OBUs in its = communications zone. An RSU also provides channel assignments and = operating instructions to OBUs in its communications zone, when = required. - [CFR 90.7 - Definitions] - Revised as October 2010. On-Board unit (OBU). 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. The OBUs receive and contend for time to = transmit on one or more radio frequency (RF) channels. Except where = specifically excluded, OBU operation is permitted wherever vehicle = operation or human passage is permitted. The OBUs mounted in vehicles = are licensed by rule under part 95 of this chapter and communicate with = Roadside Units (RSUs) and other OBUs. Portable OBUs are also licensed by = rule under part 95 of this chapter. OBU operations in the Unlicensed = National Information Infrastructure (UNII) Bands follow the rules in = those bands. - [CFR 90.7 - Definitions] - October 2010 IPWAVE Issue =E2=80=9CThe problem with the FCC definition of OBU is that it has no = relationship to IP. Worse, that FCC definition has no indication that = it MAY use IP somehow. And here we say that all OBUs must use IP. Do = you see what I mean?=E2=80=9D Correct; the OBU has no relationship with IP and is not intended to. IP = is a network protocol. If an On-Board Unit (OBU) device is required to = exchange IP, it needs to be dealt in protocol(s) and/or Management in = higher layers similar to WAVE within the On-Board Equipment (OBE) . =E2=80=9CDo you think FCC will mind if we use the term OBU in this draft = to mean something else? I, and a colleague, think that FCC would not = mind.=E2=80=9D Depending of the reader. If one is familiar with DSRC, OBU and RSU as = defined by FCC will come in mind. As far as I know, = =E2=80=9COBU=E2=80=9D and =E2=80=9CRSU=E2=80=9D are not registered and = could be used for other definitions (something like = =E2=80=9CATM=E2=80=9D: Asynchronous Transfer Mode and Automatic Teller = Machine =F0=9F=98=8A). My suggestion to the IPWAVE team is to use = =E2=80=9COBE and RSE=E2=80=9D. This is my personal view as I do not represent any involved interest. = If any one has questions, let me know. Francois Simon Lojik Technologies -----Original Message----- From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu Sent: Monday, January 29, 2018 10:08 AM To: its@ietf.org Subject: Re: [ipwave] Shepherd review of = draft-ietf-ipwave-ipv6-over-80211ocb-12 Le 29/01/2018 =C3=A0 15:52, Fran=C3=A7ois Simon a =C3=A9crit : > My comments arewithin the text*[Fygs.......]*. [...] > In the terminology section, the OBU term is mentioned to be defined=20 > outside the IETF. This is fine, but we have to provide a reference. > And even with that, it would not harm to include some short definition = > to provide context. The RSU term is also defined outside the IETF and=20 > there is quite a lot of text provided (I think the relevant part is=20 > the last sentence, the one starting with "The difference between..."). = > Both terms should be handled in the same way. >=20 > *[Fygs: The**definitions**was issued by the FCC 20 years ago. I have = > already provided that information**and references multiple > times.]*** The problem with the FCC definition of OBU is that it has no = relationship to IP. Worse, that FCC definition has no indication that = it MAY use IP somehow. And here we say that all OBUs must use IP. Do = you see what I mean? Do you think FCC will mind if we use the term OBU in this draft to mean = something else? I, and a colleague, think that FCC would not mind. Alex _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its ------=_NextPart_000_0002_01D39BE5.FAE1E280 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable RE: [ipwave] Shepherd review of = draft-ietf-ipwave-ipv6-over-80211ocb-12

Mr. = Petrescu,

Let's try one more time to clarify the FCC DSRC (in US = only) issue.

FCC = =E2=80=93 DSRC

Background:

-       The US Federal = Communications Commission (FCC) Dedicated Short Range Communication = (DSRC) is defined in the Code of Federal Regulations (CFR) 47 mainly = Parts 90 and 95. The last update is dated October 1st, = 2010;

-       = This includes the ASTM E 2213-03 standard: = =E2=80=9CStandard Speci=EF=AC=81cation for Telecommunications and = Information Exchange Between Roadside and Vehicle Systems =E2=80=94 5 = GHz Band Dedicated Short Range Communications (DSRC) Medium Access = Control (MAC) and Physical Layer (PHY) Speci=EF=AC=81cations=E2=80=9D; = approved July 10, 2003. The standard is derived from IEEE 802.11a and, = in most part, is equivalent to IEEE 802.11 OCB. To date, the DSRC CFRs = do not specify IEEE 802.11 OCB.

-       = The related CFRs state that DSRC shall comply = with the ASTM E 2213-03.

Overview of = DSRC functions:

The functions = listed in DSRC related CFRs are, in general, specified in the ASTM E = 2213-03 and IEEE 802.11 OCB:

-       MAC service definition, frame = format, and procedures;

-       = PHY Orthogonal frequency division multiplexing = (OFDM);

-       = PHY Service Data Unit format and modulations = (data rates):

-       = 5.9 GHz band allocated channels, frequency, max. = EIRP, and spectrum mask;

-       = Individual Channel use: Safety applications, = non-safety applications, and priorities.

Protocols

DSRC being uniquely a MAC and PHY communications = service, there here no restriction on Transport and Network protocols = that can be used (except for the LCC specified by reference in IEEE = 802.11 OCB). In the US, the WAVE standards (IEEE 1609 series) specify = these protocols when using DSRC as the communication = service.

OBU / = RSU

The CFR (FCC) = definitions are:

Roadside = unit (RSU). A Roadside Unit is a DSRC transceiver that is mounted along = a road or pedestrian passageway. An RSU may also be mounted on a vehicle = or is hand carried, but it may only operate when the vehicle or hand- = carried unit is stationary. Furthermore, an RSU operating under this = part is restricted to the location where it is licensed to operate. = However, portable or hand-held RSUs are permitted to operate where they = do not interfere with a site-licensed operation. A RSU broadcasts data = to OBUs or exchanges data with OBUs in its communications zone. An RSU = also provides channel assignments and operating instructions to OBUs in = its communications zone, when required. - [CFR 90.7 - Definitions] - = Revised as October 2010.

On-Board = unit (OBU). 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. The OBUs receive and contend for time to transmit = on one or more radio frequency (RF) channels. Except where specifically = excluded, OBU operation is permitted wherever vehicle operation or human = passage is permitted. The OBUs mounted in vehicles are licensed by rule = under part 95 of this chapter and communicate with Roadside Units (RSUs) = and other OBUs. Portable OBUs are also licensed by rule under part 95 of = this chapter. OBU operations in the Unlicensed National Information = Infrastructure (UNII) Bands follow the rules in those = bands. - = [CFR 90.7 - Definitions] - October 2010

IPWAVE = Issue

=E2=80=9CThe = problem with the FCC definition of OBU is that it has no relationship to = IP.  Worse, that FCC definition has no indication that it MAY use = IP somehow.  And here we say that all OBUs must use IP.  Do = you see what I mean?=E2=80=9D

Correct; the = OBU has no relationship with IP and is not intended to. IP is a network = protocol.  If an On-Board Unit (OBU) device is required to exchange = IP, it needs to be dealt in protocol(s) and/or Management in higher = layers similar to WAVE within the On-Board Equipment (OBE) = .

=E2=80=9CDo = you think FCC will mind if we use the term OBU in this draft to mean = something else?  I, and a colleague, think that FCC would not = mind.=E2=80=9D

Depending of = the reader. If one is familiar with DSRC, OBU and RSU as defined by FCC = will come in mind. As far as I know, =E2=80=9COBU=E2=80=9D and = =E2=80=9CRSU=E2=80=9D are not registered and could be used for other = definitions (something like =E2=80=9CATM=E2=80=9D: Asynchronous Transfer = Mode and Automatic Teller Machine =F0=9F=98=8A). My suggestion to the IPWAVE team is to use = =E2=80=9COBE and RSE=E2=80=9D.

This is my = personal view as I do not represent any involved = interest.  If any one has questions, let me = know.

Francois = Simon

Lojik = Technologies

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

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

Sent: Monday, = January 29, 2018 10:08 AM

To: = its@ietf.org

Subject: Re: = [ipwave] Shepherd review of = draft-ietf-ipwave-ipv6-over-80211ocb-12



Le 29/01/2018 =C3=A0 15:52, Fran=C3=A7ois Simon a = =C3=A9crit :

> My = comments arewithin the text*[Fygs.......]*.

[...]

> In the = terminology section, the OBU term is mentioned to be defined =

> outside = the IETF. This is fine, but we have to provide a = reference.

> And even = with that, it would not harm to include some short definition =

> to provide = context. The RSU term is also defined outside the IETF and =

> there is = quite a lot of text provided (I think the relevant part is =

> the last = sentence, the one starting with "The difference between..."). =

> Both terms = should be handled in the same way.

> =

> *[Fygs: = The**definitions**was issued by the FCC 20 years ago.  I have  =

> already = provided that information**and references multiple

> = times.]***

The problem = with the FCC definition of OBU is that it has no relationship to = IP.  Worse, that FCC definition has no indication that it MAY use = IP somehow.  And here we say that all OBUs must use IP.  Do = you see what I mean?

Do you think = FCC will mind if we use the term OBU in this draft to mean something = else?  I, and a colleague, think that FCC would not = mind.

Alex

_______________________________________________

its mailing = list

its@ietf.org

https://www.ietf.org/m= ailman/listinfo/its

------=_NextPart_000_0002_01D39BE5.FAE1E280-- From nobody Fri Feb 2 06:29:52 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D06612D950 for ; Fri, 2 Feb 2018 06:29:51 -0800 (PST) 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 Kbb-hQE7W7F2 for ; Fri, 2 Feb 2018 06:29:48 -0800 (PST) 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 0851512D881 for ; Fri, 2 Feb 2018 06:29:47 -0800 (PST) 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 w12ETkC6024814; Fri, 2 Feb 2018 15:29:46 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2B2E9203DFA; Fri, 2 Feb 2018 15:29:46 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 1D1C4203BA6; Fri, 2 Feb 2018 15:29:46 +0100 (CET) Received: from [132.166.85.102] ([132.166.85.102]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w12ETj78014502; Fri, 2 Feb 2018 15:29:45 +0100 To: =?UTF-8?Q?Fran=c3=a7ois_Simon?= Cc: its@ietf.org References: <1517217856.4315.32.camel@it.uc3m.es> <006601d39910$bdcf1cf0$396d56d0$@gmail.com> <000101d39c0f$e3b32f90$ab198eb0$@gmail.com> From: Alexandre Petrescu Message-ID: <707c9f11-c10e-f1e3-f68d-ab98fc632ca7@gmail.com> Date: Fri, 2 Feb 2018 15:29:45 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <000101d39c0f$e3b32f90$ab198eb0$@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 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: Fri, 02 Feb 2018 14:29:51 -0000 Le 02/02/2018 à 11:23, François Simon a écrit : > Mr. Petrescu, > > Let's try one more time to clarify the FCC DSRC (in US only) issue. > > *FCC – DSRC* > > *Background:*** > > ** > > -** The US Federal Communications Commission (FCC) Dedicated Short Range > Communication (DSRC) is defined in the Code of Federal Regulations (CFR) > 47 mainly Parts 90 and 95. The last update is dated October 1st, 2010; > > -This includes the ASTM E 2213-03 standard: “Standard Specification for > Telecommunications and Information Exchange Between Roadside and Vehicle > Systems — 5 GHz Band Dedicated Short Range Communications (DSRC) Medium > Access Control (MAC) and Physical Layer (PHY) Specifications”; approved > July 10, 2003. The standard is derived from IEEE 802.11a and, in most > part, is equivalent to IEEE 802.11 OCB. To date, the DSRC CFRs do not > specify IEEE 802.11 OCB. > > -The related CFRs state that DSRC shall comply with the ASTM E 2213-03. > > *Overview of DSRC functions:*** > > ** > > The functions listed in DSRC related CFRs are, in general, specified in > the ASTM E 2213-03 and IEEE 802.11 OCB: > > -MAC service definition, frame format, and procedures; > > -PHY Orthogonal frequency division multiplexing (OFDM); > > -PHY Service Data Unit format and modulations (data rates): > > -5.9 GHz band allocated channels, frequency, max. EIRP, and spectrum mask; > > -Individual Channel use: Safety applications, non-safety applications, > and priorities. > > *Protocols*** > > ** > > DSRC being uniquely a MAC and PHY communications service, there here no > restriction on Transport and Network protocols that can be used (except > for the LCC specified by reference in IEEE 802.11 OCB). In the US, the > WAVE standards (IEEE 1609 series) specify these protocols when using > DSRC as the communication service. > > *OBU / RSU*** > > ** > > The CFR (FCC) definitions are: > > /Roadside unit (RSU). A Roadside Unit is a DSRC transceiver that is > mounted along a road or pedestrian passageway. An RSU may also be > mounted on a vehicle or is hand carried, but it may only operate when > the vehicle or hand- carried unit is stationary. Furthermore, an RSU > operating under this part is restricted to the location where it is > licensed to operate. However, portable or hand-held RSUs are permitted > to operate where they do not interfere with a site-licensed operation. A > RSU broadcasts data to OBUs or exchanges data with OBUs in its > communications zone. An RSU also provides channel assignments and > operating instructions to OBUs in its communications zone, when > required./- [CFR 90.7 - Definitions] - Revised as October 2010. > > /On-Board unit (OBU). 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. The OBUs receive and contend for time to > transmit on one or more radio frequency (RF) channels. Except where > specifically excluded, OBU operation is permitted wherever vehicle > operation or human passage is permitted. The OBUs mounted in vehicles > are licensed by rule under part 95 of this chapter and communicate with > Roadside Units (RSUs) and other OBUs. Portable OBUs are also licensed by > rule under part 95 of this chapter. OBU operations in the Unlicensed > National Information Infrastructure (UNII) Bands follow the rules in > those bands./- [CFR 90.7 - Definitions] - October 2010 > > *IPWAVE Issue*** > > ** > > /“The problem with the FCC definition of OBU is that it has no > relationship to IP.  Worse, that FCC definition has no indication that > it MAY use IP somehow.  And here we say that all OBUs must use IP.  Do > you see what I mean?”/// > > // > > Correct; the OBU has no relationship with IP and is not intended to. IP > is a network protocol.  If an On-Board Unit (OBU) device is required to > exchange IP, it needs to be dealt in protocol(s) and/or Management in > higher layers similar to WAVE within the On-Board Equipment (OBE) . > > /“Do you think FCC will mind if we use the term OBU in this draft to > mean something else?  I, and a colleague, think that FCC would not mind.”/// > > // > > Depending of the reader. If one is familiar with DSRC, OBU and RSU as > defined by FCC will come in mind. As far as I know, “OBU” and “RSU” are > not registered and could be used for other definitions (something like > “ATM”: Asynchronous Transfer Mode and Automatic Teller Machine😊). My > suggestion to the IPWAVE team is to use “OBE and RSE”. > > This is my personal view as I donot represent any involved interest.  If > any one has questions, let me know. If we want to go with OBE instead of OBU then we must be ready to defend it in our respective contexts. Are we ready to? (I already have a hard time with telling people "802.11p" no longer exists, especially to those who are afraid I want to use LTE to 'kill' 802.11p; and now to tell them to use "OBE" instead of "OBU" just in order to use IP seems like an additional effort). All the OBUs I use do run IP. Can FCC change their definition to include a reference to this IP draft? Alex > > Francois Simon > > Lojik Technologies > > -----Original Message----- > > From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu > > Sent: Monday, January 29, 2018 10:08 AM > > To: its@ietf.org > > Subject: Re: [ipwave] Shepherd review of > draft-ietf-ipwave-ipv6-over-80211ocb-12 > > > > Le 29/01/2018 à 15:52, François Simon a écrit : > >> My comments arewithin the text*[Fygs.......]*. > > [...] > >> In the terminology section, the OBU term is mentioned to be defined > >> outside the IETF. This is fine, but we have to provide a reference. > >> And even with that, it would not harm to include some short definition > >> to provide context. The RSU term is also defined outside the IETF and > >> there is quite a lot of text provided (I think the relevant part is > >> the last sentence, the one starting with "The difference between..."). > >> Both terms should be handled in the same way. > >> > >> *[Fygs: The**definitions**was issued by the FCC 20 years ago.  I have > >> already provided that information**and references multiple > >> times.]*** > > The problem with the FCC definition of OBU is that it has no > relationship to IP.  Worse, that FCC definition has no indication that > it MAY use IP somehow.  And here we say that all OBUs must use IP.  Do > you see what I mean? > > Do you think FCC will mind if we use the term OBU in this draft to mean > something else?  I, and a colleague, think that FCC would not mind. > > Alex > > _______________________________________________ > > its mailing list > > its@ietf.org > > https://www.ietf.org/mailman/listinfo/its > From nobody Fri Feb 2 08:09:46 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01C4312DA4B for ; Fri, 2 Feb 2018 08:09:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 VD_Y0eUYvOlz for ; Fri, 2 Feb 2018 08:09:43 -0800 (PST) Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (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 71BC312DA28 for ; Fri, 2 Feb 2018 08:09:43 -0800 (PST) Received: from resomta-po-19v.sys.comcast.net ([96.114.154.243]) by resqmta-po-08v.sys.comcast.net with ESMTP id hdtjeL280Mk7PhduJeIRbk; Fri, 02 Feb 2018 16:09:43 +0000 Received: from [172.22.228.216] ([162.210.130.3]) by resomta-po-19v.sys.comcast.net with SMTP id hds9e7luHSPUJhdsBe5ZTJ; Fri, 02 Feb 2018 16:07:40 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Tony Li In-Reply-To: <707c9f11-c10e-f1e3-f68d-ab98fc632ca7@gmail.com> Date: Fri, 2 Feb 2018 08:07:27 -0800 Cc: =?utf-8?Q?Fran=C3=A7ois_Simon?= , its@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5137E64F-E458-408E-AE4C-C1D1C855BA7D@tony.li> References: <1517217856.4315.32.camel@it.uc3m.es> <006601d39910$bdcf1cf0$396d56d0$@gmail.com> <000101d39c0f$e3b32f90$ab198eb0$@gmail.com> <707c9f11-c10e-f1e3-f68d-ab98fc632ca7@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3445.5.20) X-CMAE-Envelope: MS4wfMmCJk55Z/vzQbPMTZgUzYO4PFSweoOOHG1ObHZwXYrEZSmtR/gej6XgIetNLod2OyuSoAKLJ1zUqKWJjvCWIGDzMs1EwOwlDyJXDMJ2Goq81ya4UtaC zFyTVHsUuku6AXkMqf85p68a5c/suRiy8iI4VAsv5hM9fwVVhIi4atmm8Pcnb/+SvZ60yMra5wLECavXRY5Qgql2S8zrK2qRNEdT+nPyHR0UyiNywmjc0U3D Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 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: Fri, 02 Feb 2018 16:09:45 -0000 >> Depending of the reader. If one is familiar with DSRC, OBU and RSU as = defined by FCC will come in mind. As far as I know, =E2=80=9COBU=E2=80=9D = and =E2=80=9CRSU=E2=80=9D are not registered and could be used for other = definitions (something like =E2=80=9CATM=E2=80=9D: Asynchronous Transfer = Mode and Automatic Teller Machine=F0=9F=98=8A). My suggestion to the = IPWAVE team is to use =E2=80=9COBE and RSE=E2=80=9D. >> This is my personal view as I donot represent any involved interest. = If any one has questions, let me know. >=20 > If we want to go with OBE instead of OBU then we must be ready to = defend it in our respective contexts. Are we ready to? Might I suggest that we use IP-OBU? This would make it obvious that it = is an OBU speaking IP. Tony From nobody Fri Feb 2 11:12:22 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA7212E054 for ; Fri, 2 Feb 2018 11:12:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=us-toyota-itc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TzSXK5btoAEP for ; Fri, 2 Feb 2018 11:12:19 -0800 (PST) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::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 002E012E045 for ; Fri, 2 Feb 2018 11:12:18 -0800 (PST) Received: by mail-it0-x22e.google.com with SMTP id n206so9096682itg.1 for ; Fri, 02 Feb 2018 11:12:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=us-toyota-itc-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LVAeG0QQiiVldo+UBl/C5JHKDRzHIi/Jit7B+4d3/XI=; b=gNigmRSiZ0AUEVWtBt/fCOZUAmRNrOIx9g0mxBM0eCg6wjUMvdCD6C1YHa3K85bRsw kWrtU7A7lyzTexP5NRsxEMQbM+yA9KODuheFA2Au4luUQiBYJfxDvRXbBZfCg8Bwz6AM Qgu0gRzwMZYVWj0AHzD4pnbqTnPWZaMI8BbCTiQoLmxXg5xBks5C8zGHrjSxmGikYisT jwcmdaM0CJErUwsE9fRoy3140IrSHnq/5RgaPMwlKIaDFrbGgb1c4V0pramXFx/v7ilJ QxC+ES5f3oYRsiiFP8/UH7YQpmZPdsKnTyj/7MahxJT/nSOUnMDKGUDFQVq85w4ORu7K AMoQ== 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=LVAeG0QQiiVldo+UBl/C5JHKDRzHIi/Jit7B+4d3/XI=; b=ZP9c4YgtTCuwh0ivCYT/5gpU5yHUl1dSBmBGwn0mYH/sfBsExxQh3+NBjnhnTUUiKQ 0yiROnf53V6Hh+YVR/pKc6LBFQuY/YaRmII0VWXCtdDWVopTQKSWFldfbNuBjdcTSEzp KebTdBRvcyPXn2OQIFmMQ+UX7IbHN7ewKZ1X6kFeizknnkj4oobKenDoGgd1FyR6UYPN ZA/LZ8l9XEHNY0cvp40fN3vNXoHV5ozGax+RIFAsoXI4JmUx2FhfAVn+EHS/yyQFfrqN +iVBOBDZP1fEZCIeFdE+U41+1Okndr8ovHrmGlP0EgBGuCXffUn/YcL1rBGwgpnB/usx j7ZQ== X-Gm-Message-State: AKwxytfniOk3oc/f8yXD+kNUwJfTsrbBI4IwdTHBNGV6khzYGwfUxoI5 uTMiFFvG08pQ0OQwXChFGGZ5w2w9hRwh9PcKauysuA== X-Google-Smtp-Source: AH8x224qkTcly+yM/Asu+kVpPv3E0PB4SJuRdqh0QRipHy2iFu/JUZNU5JH8p/IZSe5x9AAKbw2GcFE7QyLTrFY2yZM= X-Received: by 10.36.160.140 with SMTP id o134mr17901172ite.70.1517598738293; Fri, 02 Feb 2018 11:12:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.65.71 with HTTP; Fri, 2 Feb 2018 11:12:17 -0800 (PST) In-Reply-To: <707c9f11-c10e-f1e3-f68d-ab98fc632ca7@gmail.com> References: <1517217856.4315.32.camel@it.uc3m.es> <006601d39910$bdcf1cf0$396d56d0$@gmail.com> <000101d39c0f$e3b32f90$ab198eb0$@gmail.com> <707c9f11-c10e-f1e3-f68d-ab98fc632ca7@gmail.com> From: John Kenney Date: Fri, 2 Feb 2018 11:12:17 -0800 Message-ID: To: Alexandre Petrescu Cc: =?UTF-8?Q?Fran=C3=A7ois_Simon?= , its@ietf.org Content-Type: multipart/alternative; boundary="94eb2c049e9ab5617605643f7df9" Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 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: Fri, 02 Feb 2018 19:12:21 -0000 --94eb2c049e9ab5617605643f7df9 Content-Type: text/plain; charset="UTF-8" > > Can FCC change their definition to include a reference to this IP draft? > > Absolutely not. Let's kill this idea as quickly as possible. The FCC is intentionally agnostic about what comes above the MAC layer of DSRC. There is no reason why they should mention IP or any other higher layer protocol, and the lack of mention of such protocols should be understood to mean there are no regulatory requirements with respect to them. Also, please do not re-use the terms OBU and RSU with different meanings than given by the FCC. That's asking for trouble. Please don't create new definitions of OBE and RSE either. Tony Li's suggestion for an IP-specific label seems like a good way to proceed. I also mention that the IEEE 802.11p, 1609.2, 1609.3 and 1609.4 standards do not use either of those terms. In other words, from a WAVE standards point of view, there is no distinction between an OBU and an RSU. I haven't been following this IETF work very closely, but it may be worth re-examining whether any such distinctions are necessary for you as well. Best Regards, John -- John Kenney Director and Principal Researcher Toyota InfoTechnology Center, USA 465 Bernardo Avenue Mountain View, CA 94043 Tel: 650-694-4160. Mobile: 650-224-6644 --94eb2c049e9ab5617605643f7df9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

=

Can FCC change their definition to include a reference to this IP draft?
Absolutely not. Let's kill this idea as quickly a= s possible.=C2=A0 The FCC is intentionally agnostic about what comes above = the MAC layer of DSRC.=C2=A0 There is no reason why they should mention IP = or any other higher layer protocol, and the lack of mention of such protoco= ls should be understood to mean there are no regulatory requirements with r= espect to them.=C2=A0=C2=A0

Also, please do not re= -use the terms OBU and RSU with different meanings than given by the FCC. T= hat's asking for trouble. Please don't create new definitions of OB= E and RSE either. Tony Li's suggestion for an IP-specific label seems l= ike a good way to proceed.

I also mention that the= IEEE 802.11p, 1609.2, 1609.3 and 1609.4 standards do not use either of tho= se terms.=C2=A0 In other words, from a WAVE standards point of view, there = is no distinction between an OBU and an RSU.=C2=A0 I haven't been follo= wing this IETF work very closely, but it may be worth re-examining whether = any such distinctions are necessary for you as well.

Best Reg= ards,
John
=C2=A0

--
John Kenney
Director and Principal Researcher
Toyota InfoTechnology Center, USA
465 Bernardo Avenue
Mountain View, CA 94043
Tel: 650-694-4160. Mobile: 650-224-6644
--94eb2c049e9ab5617605643f7df9-- From nobody Sat Feb 3 06:29:40 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2876512D850 for ; Sat, 3 Feb 2018 06:29:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.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, 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 (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 l73ue6cNXFlS for ; Sat, 3 Feb 2018 06:29:34 -0800 (PST) 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 1472D1289B0 for ; Sat, 3 Feb 2018 06:29:34 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id 69so14382990qkz.2 for ; Sat, 03 Feb 2018 06:29:33 -0800 (PST) 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=VOpOLsAF+iK5aabz3Zb+qB3qXlGHmoWt/4yrqDWLl8w=; b=QLx/AVPgYLvzdT8oBRStI7gKaIM8RCjyDr9ydH4HIAoAH2a+UgnU2HvPbhgvUA/qPQ 64cU39AocYA79dlu2pbVKpKbr0bV3g4MamobHUuZW1utOnIhQ0KRT4iB3Iqs+KjcXBHR MqP40pK2xOYzoMvOQk1Rmx1ywGt+JHOLSvph95oio9E/QJJzsN7kTyTdrsoXQ2+1rmyh pVfcYpB5hodSC2pmRBAyPG37zQgcM8FUHC450b2WVi8E97QsnJtaB4Uc3lrRGu2Po3OG +Wxl9Xc21i8GY80LRwEe93ieA9MS4YIYiZsE2NPV5JCMiLhrdeQQHv2OINUd2b1yAYEb 5Lvw== 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=VOpOLsAF+iK5aabz3Zb+qB3qXlGHmoWt/4yrqDWLl8w=; b=DuSKpSRMZ7DJ2sQn+1Be5ZK55zwRIzMpP6nG2N2HYbYe0FofFLVLfMfH1Pgzz2+lNN ntsh3YUgdN6EcmyLWGZJErsN6BDPQcx4xAsau5aNxwc6255lroawhVXT+MJn3gpGhU9A vmiUe833alPb28OvgTxoi1G/zJqzFLlpzPX0sIt25KkXPGX30dvlaxN0T2ITqTezH9na p/b/ZHJV8DuxJi//7fHjAtaiS62m8nmSRiLK7n1CxV4+BUUZ+aHrYyIZ5mdcy1HY7Pon x5mbhVuxn/4kQtwTC3StqBl0OMVzRVRORt6rEbAfZFrKPED1TOglTRNv5GjpiYkZv5PF cRXQ== X-Gm-Message-State: AKwxyte/39u7G845/XntLLEYfjGSK+JuMg8UYv+bjSpLwwo/q2auyRqA AIIDJzjDimWLrthKeZ9/LjM= X-Google-Smtp-Source: AH8x226ef/YPlEhMuE9VbgSClCm61O1OxLAmpZV3JRlEy8WRhrRrHBYM5tXwrhZd7ZHQWrxS09g+wg== X-Received: by 10.55.73.1 with SMTP id w1mr22753099qka.215.1517668173016; Sat, 03 Feb 2018 06:29:33 -0800 (PST) Received: from FrancoisPC (pool-108-48-182-86.washdc.fios.verizon.net. [108.48.182.86]) by smtp.gmail.com with ESMTPSA id x135sm3033170qkx.93.2018.02.03.06.29.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 03 Feb 2018 06:29:31 -0800 (PST) From: =?UTF-8?Q?Fran=C3=A7ois_Simon?= To: , Cc: , References: <1517217856.4315.32.camel@it.uc3m.es> <006601d39910$bdcf1cf0$396d56d0$@gmail.com> <000101d39c0f$e3b32f90$ab198eb0$@gmail.com> <707c9f11-c10e-f1e3-f68d-ab98fc632ca7@gmail.com> <000a01d39c59$f944e2a0$ebcea7e0$@gmail.com> In-Reply-To: <000a01d39c59$f944e2a0$ebcea7e0$@gmail.com> Date: Sat, 3 Feb 2018 09:29:28 -0500 Message-ID: <006e01d39cfb$67b536d0$371fa470$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006F_01D39CD1.7EE3E9C0" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQL7ISfFSBtQJ/i74DjDJlbgILh28gG4su6HASuQMD8BaTCMjwK9q5dAAk24uYqg+MqrUA== Archived-At: Subject: [ipwave] FW: Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 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, 03 Feb 2018 14:29:38 -0000 This is a multipart message in MIME format. ------=_NextPart_000_006F_01D39CD1.7EE3E9C0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Gentlemen, Mr. Petrescu responded to my email with: 1. " If we want to go with OBE instead of OBU then we must be ready to = defend it in our respective contexts. Are we ready to?" Argument: From the FCC is concerned, the term "Roadside Equipment" is = not defined. Its purpose was to allocated 75 MHz within the 5.9 GHz = spectrum, define a channel plan, and define application priorities = (emphasis on safety applications) in the use of the allocated channels = (mainly for government entities). However, The US DOT defines OBE and = RSE: - On-Board Equipment (OBE) - Term refers to the compliment of equipment = located in the vehicle for the purpose of supporting the vehicle side of = the applications. It is likely to include the DSRC radios, other radio = equipment, message processing, driver interface, and other applications = to support the use cases described herein [see Reference]. It is also = referred to as the Vehicle ITS Station. When referring to the DSRC radio = alone, the correct term is OBU.=E2=80=9D =09 - Roadside Equipment (RSE) - Term used to describe the compliment of = equipment to be located at the roadside; the RSE will prepare and = transmit messages to the vehicles and receive messages from the vehicles = for the purpose of supporting the V2I applications. This is intended to = include the DSRC radio, traffic signal controller where appropriate, = interface to the backhaul communications network necessary to support = the applications, and support such functions as data security, = encryption, buffering, and message processing. When speaking of the DSRC = radio alone, the correct term is RSU.=E2=80=9D. =09 Reference: 2015 FHWA Vehicle to Infrastructure Deployment Guidance = and Products. 2. =E2=80=9C(I already have a hard time with telling people "802.11p" no = longer exists,=E2=80=A6=E2=80=9D Argument: You have made the point (justification) once. In verbal = discussion, let the member refer it as they wish. As an editor of IPWAVE = documents, mention the rational once in the introduction and insure that = =E2=80=9CIEEE 802.11p=E2=80=9D is replaced by =E2=80=9C802.11 = OCB=E2=80=9D in the remaining text. 3. =E2=80=9C=E2=80=A6.especially to those who are afraid I want to use = LTE to 'kill' 802.11p=E2=80=A6=E2=80=9D Argument: If this is yours and your organization goal, you are not the = only one. This has been debated for few years already. This is not a = technical argument, therefore I will not address it.=20 4. =E2=80=9C=E2=80=A6and now to tell them to use "OBE" instead of "OBU" = just in order to use IP seems like an additional effort).=E2=80=9D Argument: I am not suggesting to do a =E2=80=9Cglobal=E2=80=9D change = of =E2=80=9COBU / RSU=E2=80=9D with =E2=80=9COBE / RSE=E2=80=9D. = =E2=80=9CUnit=E2=80=9D and =E2=80=9CEquipment=E2=80=9D have their own = context. However, =E2=80=9CUnit=E2=80=9D is the radio included in = =E2=80=9CEquipment=E2=80=9D and by itself does not make a system = enabling the transportation of IP as defined by IETF. I am suggesting = the use of OBU/OBE and RSU/RSE within their appropriate context. 5. =E2=80=9CAll the OBUs I use do run IP.=E2=80=9D Argument: It depends of your definition of =E2=80=9Crun=E2=80=9D. The = OBU (radio) does nothing with IP (or any other network protocols). The = OBU exchange MAC protocol data units (MPDU) with its peer(s) via a = wireless media channel. The Internet Protocol (IP) is the payload of = the MPDU. 6. =E2=80=9CCan FCC change their definition to include a reference to = this IP draft?:=E2=80=9D Argument: NO. FCC is an independent agency of the US government. For = some of you who remember the PTTs in Europe, it is somewhat similar; two = to three years to fulfill a simple residence telephone request; should I = say more? =F0=9F=98=89=20 =09 I hope this help somewhat but do remember this comments apply to US = only. If you have any comments and/or questions, let me know. Sincerely, Francois Simon Lojik Technologies -----Original Message----- From: Fran=C3=A7ois Simon [mailto:fygsimon@gmail.com]=20 Sent: Friday, February 02, 2018 2:14 PM To: fygsimon@gmail.com Subject: FW: [ipwave] Shepherd review of = draft-ietf-ipwave-ipv6-over-80211ocb-12 -----Original Message----- From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com]=20 Sent: Friday, February 02, 2018 9:30 AM To: Fran=C3=A7ois Simon = > Cc: its@ietf.org =20 Subject: Re: [ipwave] Shepherd review of = draft-ietf-ipwave-ipv6-over-80211ocb-12 Le 02/02/2018 =C3=A0 11:23, Fran=C3=A7ois Simon a =C3=A9crit : > Mr. Petrescu, >=20 > Let's try one more time to clarify the FCC DSRC (in US only) issue. >=20 > *FCC =E2=80=93 DSRC* >=20 > *Background:*** >=20 > ** >=20 > -** The US Federal Communications Commission (FCC) Dedicated Short=20 > Range Communication (DSRC) is defined in the Code of Federal=20 > Regulations (CFR) > 47 mainly Parts 90 and 95. The last update is dated October 1st, 2010; >=20 > -This includes the ASTM E 2213-03 standard: =E2=80=9CStandard = Speci=EF=AC=81cation for=20 > Telecommunications and Information Exchange Between Roadside and=20 > Vehicle Systems =E2=80=94 5 GHz Band Dedicated Short Range = Communications=20 > (DSRC) Medium Access Control (MAC) and Physical Layer (PHY)=20 > Speci=EF=AC=81cations=E2=80=9D; approved July 10, 2003. The standard = is derived from=20 > IEEE 802.11a and, in most part, is equivalent to IEEE 802.11 OCB. To=20 > date, the DSRC CFRs do not specify IEEE 802.11 OCB. >=20 > -The related CFRs state that DSRC shall comply with the ASTM E = 2213-03. >=20 > *Overview of DSRC functions:*** >=20 > ** >=20 > The functions listed in DSRC related CFRs are, in general, specified=20 > in the ASTM E 2213-03 and IEEE 802.11 OCB: >=20 > -MAC service definition, frame format, and procedures; >=20 > -PHY Orthogonal frequency division multiplexing (OFDM); >=20 > -PHY Service Data Unit format and modulations (data rates): >=20 > -5.9 GHz band allocated channels, frequency, max. EIRP, and spectrum=20 > mask; >=20 > -Individual Channel use: Safety applications, non-safety applications, = > and priorities. >=20 > *Protocols*** >=20 > ** >=20 > DSRC being uniquely a MAC and PHY communications service, there here=20 > no restriction on Transport and Network protocols that can be used=20 > (except for the LCC specified by reference in IEEE 802.11 OCB). In the = > US, the WAVE standards (IEEE 1609 series) specify these protocols when = > using DSRC as the communication service. >=20 > *OBU / RSU*** >=20 > ** >=20 > The CFR (FCC) definitions are: >=20 > /Roadside unit (RSU). A Roadside Unit is a DSRC transceiver that is=20 > mounted along a road or pedestrian passageway. An RSU may also be=20 > mounted on a vehicle or is hand carried, but it may only operate when=20 > the vehicle or hand- carried unit is stationary. Furthermore, an RSU=20 > operating under this part is restricted to the location where it is=20 > licensed to operate. However, portable or hand-held RSUs are permitted = > to operate where they do not interfere with a site-licensed operation. = > A RSU broadcasts data to OBUs or exchanges data with OBUs in its=20 > communications zone. An RSU also provides channel assignments and=20 > operating instructions to OBUs in its communications zone, when > required./- [CFR 90.7 - Definitions] - Revised as October 2010. >=20 > /On-Board unit (OBU). An On-Board Unit is a DSRCS transceiver that is=20 > 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=20 > is either mobile or stationary. The OBUs receive and contend for time=20 > to transmit on one or more radio frequency (RF) channels. Except where = > specifically excluded, OBU operation is permitted wherever vehicle=20 > operation or human passage is permitted. The OBUs mounted in vehicles=20 > are licensed by rule under part 95 of this chapter and communicate=20 > with Roadside Units (RSUs) and other OBUs. Portable OBUs are also=20 > licensed by rule under part 95 of this chapter. OBU operations in the=20 > Unlicensed National Information Infrastructure (UNII) Bands follow the = > rules in those bands./- [CFR 90.7 - Definitions] - October 2010 >=20 > *IPWAVE Issue*** >=20 > ** >=20 > /=E2=80=9CThe problem with the FCC definition of OBU is that it has no = > relationship to IP. Worse, that FCC definition has no indication that = > it MAY use IP somehow. And here we say that all OBUs must use IP. Do = > you see what I mean?=E2=80=9D/// >=20 > // >=20 > Correct; the OBU has no relationship with IP and is not intended to.=20 > IP is a network protocol. If an On-Board Unit (OBU) device is=20 > required to exchange IP, it needs to be dealt in protocol(s) and/or=20 > Management in higher layers similar to WAVE within the On-Board = Equipment (OBE) . >=20 > /=E2=80=9CDo you think FCC will mind if we use the term OBU in this = draft to=20 > mean something else? I, and a colleague, think that FCC would not=20 > mind.=E2=80=9D/// >=20 > // >=20 > Depending of the reader. If one is familiar with DSRC, OBU and RSU as=20 > defined by FCC will come in mind. As far as I know, = =E2=80=9COBU=E2=80=9D and =E2=80=9CRSU=E2=80=9D=20 > are not registered and could be used for other definitions (something=20 > like > =E2=80=9CATM=E2=80=9D: Asynchronous Transfer Mode and Automatic Teller = Machine=F0=9F=98=8A). My=20 > suggestion to the IPWAVE team is to use =E2=80=9COBE and RSE=E2=80=9D. >=20 > This is my personal view as I donot represent any involved interest. =20 > If any one has questions, let me know. If we want to go with OBE instead of OBU then we must be ready to defend = it in our respective contexts. Are we ready to? (I already have a hard time with telling people "802.11p" no longer = exists, especially to those who are afraid I want to use LTE to 'kill'=20 802.11p; and now to tell them to use "OBE" instead of "OBU" just in = order to use IP seems like an additional effort). All the OBUs I use do run IP. Can FCC change their definition to include a reference to this IP draft? Alex >=20 > Francois Simon >=20 > Lojik Technologies >=20 > -----Original Message----- >=20 > From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre=20 > Petrescu >=20 > Sent: Monday, January 29, 2018 10:08 AM >=20 > To: its@ietf.org =20 >=20 > Subject: Re: [ipwave] Shepherd review of > draft-ietf-ipwave-ipv6-over-80211ocb-12 >=20 >=20 >=20 > Le 29/01/2018 =C3=A0 15:52, Fran=C3=A7ois Simon a =C3=A9crit : >=20 >> My comments arewithin the text*[Fygs.......]*. >=20 > [...] >=20 >> In the terminology section, the OBU term is mentioned to be defined >=20 >> outside the IETF. This is fine, but we have to provide a reference. >=20 >> And even with that, it would not harm to include some short=20 >> definition >=20 >> to provide context. The RSU term is also defined outside the IETF and >=20 >> there is quite a lot of text provided (I think the relevant part is >=20 >> the last sentence, the one starting with "The difference = between...").=20 >=20 >> Both terms should be handled in the same way. >=20 >>=20 >=20 >> *[Fygs: The**definitions**was issued by the FCC 20 years ago. I have >=20 >> already provided that information**and references multiple >=20 >> times.]*** >=20 > The problem with the FCC definition of OBU is that it has no=20 > relationship to IP. Worse, that FCC definition has no indication that = > it MAY use IP somehow. And here we say that all OBUs must use IP. Do = > you see what I mean? >=20 > Do you think FCC will mind if we use the term OBU in this draft to=20 > mean something else? I, and a colleague, think that FCC would not = mind. >=20 > Alex >=20 > _______________________________________________ >=20 > its mailing list >=20 > its@ietf.org =20 >=20 > https://www.ietf.org/mailman/listinfo/its >=20 ------=_NextPart_000_006F_01D39CD1.7EE3E9C0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable FW: [ipwave] Shepherd review of = draft-ietf-ipwave-ipv6-over-80211ocb-12

Gentlemen,

Mr. = Petrescu responded to my email with:

1.      " If we want to go with OBE = instead of OBU then we must be ready to defend it in our respective = contexts.  Are we ready to?"

    Argument: From the FCC is concerned, the term "Roadside Equipment" = is not defined. Its purpose was to allocated 75 MHz within the 5.9 = GHz spectrum, = define a channel plan, and define = application priorities (emphasis on safety = applications) = in the use of the allocated channels (mainly for government = entities).  However, The US DOT defines OBE and RSE:

-       On-Board Equipment (OBE) - = Term refers to the compliment of equipment located in the = vehicle for the purpose of supporting the vehicle side of the = applications. It is likely to include the DSRC radios, other radio = equipment, message processing, driver interface, and other applications = to support the use cases described herein [see = Reference]. It is also referred to as the Vehicle ITS Station. = When referring to the DSRC radio alone, the correct term is = OBU.=E2=80=9D

-       Roadside Equipment = (RSE) - Term used to describe the compliment of equipment to be located = at the roadside; the RSE will prepare and transmit messages to the = vehicles and receive messages from the vehicles for the purpose of = supporting the V2I applications. This is intended to include the DSRC = radio, traffic signal controller where appropriate, interface to the = backhaul communications network necessary to support the applications, = and support such functions as data security, encryption, buffering, and = message processing. When speaking of the DSRC radio alone, the correct = term is RSU.=E2=80=9D.

        Reference: 2015 FHWA Vehicle to Infrastructure Deployment Guidance = and Products.

2.      =E2=80=9C(I already have a hard time = with telling people "802.11p" no longer = exists,=E2=80=A6=E2=80=9D

    Argument:  You have made the point (justification) once. In verbal = discussion, let the member refer it as they wish. As an = editor of = IPWAVE = documents, mention the rational once in the introduction and = insure that =E2=80=9CIEEE 802.11p=E2=80=9D is replaced by = =E2=80=9C802.11 OCB=E2=80=9D in the remaining text.

3.      =E2=80=9C=E2=80=A6.especially to those who are = afraid I want to use LTE to 'kill' 802.11p=E2=80=A6=E2=80=9D

    Argument:  If this is yours and your organization goal, you = are not the only one. This has been debated for few years = already.  = This is not a = technical argument, therefore I will not address = it.

4.      =E2=80=9C=E2=80=A6and now to tell them to use = "OBE" instead of "OBU" just in order to use IP seems = like an additional effort).=E2=80=9D

    Argument:  I am not suggesting to do a = =E2=80=9Cglobal=E2=80=9D change of =E2=80=9COBU / RSU=E2=80=9D with =E2=80=9COBE / RSE=E2=80=9D.  =E2=80=9CUnit=E2=80=9D and =E2=80=9CEquipment=E2=80=9D have = their own context.  However, =E2=80=9CUnit=E2=80=9D is the radio included in = =E2=80=9CEquipment=E2=80=9D = and by itself does not make a = system enabling the transportation of IP as defined by = IETF.  I = am suggesting the use of OBU/OBE and RSU/RSE within their appropriate = context.

5.      =E2=80=9CAll the OBUs I use do run = IP.=E2=80=9D

    Argument: It depends of your definition of = =E2=80=9Crun=E2=80=9D. The OBU (radio) does nothing with = IP (or any = other network protocols). The OBU exchange MAC protocol data units (MPDU) with its peer(s) via a wireless = media = channel.  = The Internet = Protocol = (IP) is the = payload  of the MPDU.

6.      =E2=80=9CCan FCC change their definition to = include a reference to this IP draft?:=E2=80=9D

    Argument: = NO.  FCC is an independent agency of the = US government. For some of you who = remember the PTTs in Europe, it is somewhat similar; two to = three years to fulfill a simple residence telephone = request; should I say more? =F0=9F=98=89

I hope this = help somewhat but do remember this comments apply to US only.  If you have any = comments and/or questions, let me know.

Sincerely,

Francois = Simon

Lojik = Technologies

-----Original = Message-----
From: Fran=C3=A7ois Simon [mailto:fygsimon@gmail.com]
Sent: Friday, February 02, 2018 2:14 PM
To: fygsimon@gmail.com
Subject: FW: [ipwave] Shepherd review of = draft-ietf-ipwave-ipv6-over-80211ocb-12

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

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

Sent: Friday, = February 02, 2018 9:30 AM

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

Cc: its@ietf.org

Subject: Re: = [ipwave] Shepherd review of = draft-ietf-ipwave-ipv6-over-80211ocb-12



Le 02/02/2018 = =C3=A0 11:23, Fran=C3=A7ois Simon a =C3=A9crit :

> Mr. = Petrescu,

> =

> Let's try = one more time to clarify the FCC DSRC (in US only) = issue.

> =

> *FCC = =E2=80=93 DSRC*

> =

> = *Background:***

> =

> = **

> =

> -** The US = Federal Communications Commission (FCC) Dedicated Short =

> Range = Communication (DSRC) is defined in the Code of Federal =

> = Regulations (CFR)

> 47 mainly = Parts 90 and 95. The last update is dated October 1st, = 2010;

> =

> -This = includes the ASTM E 2213-03 standard: =E2=80=9CStandard = Speci=EF=AC=81cation for

> = Telecommunications and Information Exchange Between Roadside and =

> Vehicle = Systems =E2=80=94 5 GHz Band Dedicated Short Range Communications =

> (DSRC) = Medium Access Control (MAC) and Physical Layer (PHY)

> = Speci=EF=AC=81cations=E2=80=9D; approved July 10, 2003. The standard is = derived from

> IEEE = 802.11a and, in most part, is equivalent to IEEE 802.11 OCB. To =

> date, the = DSRC CFRs do not specify IEEE 802.11 OCB.

> =

> -The = related CFRs state that DSRC shall comply with the ASTM E = 2213-03.

> =

> *Overview = of DSRC functions:***

> =

> = **

> =

> The = functions listed in DSRC related CFRs are, in general, specified =

> in the = ASTM E 2213-03 and IEEE 802.11 OCB:

> =

> -MAC = service definition, frame format, and procedures;

> =

> -PHY = Orthogonal frequency division multiplexing (OFDM);

> =

> -PHY = Service Data Unit format and modulations (data rates):

> =

> -5.9 GHz = band allocated channels, frequency, max. EIRP, and spectrum =

> = mask;

> =

> = -Individual Channel use: Safety applications, non-safety applications, =

> and = priorities.

> =

> = *Protocols***

> =

> = **

> =

> DSRC being = uniquely a MAC and PHY communications service, there here =

> no = restriction on Transport and Network protocols that can be used =

> (except = for the LCC specified by reference in IEEE 802.11 OCB). In the =

> US, the = WAVE standards (IEEE 1609 series) specify these protocols when =

> using DSRC = as the communication service.

> =

> *OBU / = RSU***

> =

> = **

> =

> The CFR = (FCC) definitions are:

> =

> /Roadside = unit (RSU). A Roadside Unit is a DSRC transceiver that is =

> mounted = along a road or pedestrian passageway. An RSU may also be =

> mounted on = a vehicle or is hand carried, but it may only operate when =

> the = vehicle or hand- carried unit is stationary. Furthermore, an RSU =

> operating = under this part is restricted to the location where it is =

> licensed = to operate. However, portable or hand-held RSUs are permitted =

> to operate = where they do not interfere with a site-licensed operation. =

> A RSU = broadcasts data to OBUs or exchanges data with OBUs in its =

> = communications zone. An RSU also provides channel assignments and =

> operating = instructions to OBUs in its communications zone, when

> = required./- [CFR 90.7 - Definitions] - Revised as October = 2010.

> =

> /On-Board = unit (OBU). 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. The OBUs receive and contend for time =

> to = transmit on one or more radio frequency (RF) channels. Except where =

> = specifically excluded, OBU operation is permitted wherever vehicle =

> operation = or human passage is permitted. The OBUs mounted in vehicles =

> are = licensed by rule under part 95 of this chapter and communicate =

> with = Roadside Units (RSUs) and other OBUs. Portable OBUs are also =

> licensed = by rule under part 95 of this chapter. OBU operations in the =

> Unlicensed = National Information Infrastructure (UNII) Bands follow the =

> rules in = those bands./- [CFR 90.7 - Definitions] - October 2010

> =

> *IPWAVE = Issue***

> =

> = **

> =

> = /=E2=80=9CThe problem with the FCC definition of OBU is that it has no =

> = relationship to IP.  Worse, that FCC definition has no indication = that

> it MAY use = IP somehow.  And here we say that all OBUs must use IP.  Do =

> you see = what I mean?=E2=80=9D///

> =

> = //

> =

> Correct; = the OBU has no relationship with IP and is not intended to. =

> IP is a = network protocol.  If an On-Board Unit (OBU) device is =

> required = to exchange IP, it needs to be dealt in protocol(s) and/or =

> Management = in higher layers similar to WAVE within the On-Board Equipment (OBE) = .

> =

> = /=E2=80=9CDo you think FCC will mind if we use the term OBU in this = draft to

> mean = something else?  I, and a colleague, think that FCC would not =

> = mind.=E2=80=9D///

> =

> = //

> =

> Depending = of the reader. If one is familiar with DSRC, OBU and RSU as =

> defined by = FCC will come in mind. As far as I know, =E2=80=9COBU=E2=80=9D and = =E2=80=9CRSU=E2=80=9D

> are not = registered and could be used for other definitions (something =

> = like

> = =E2=80=9CATM=E2=80=9D: Asynchronous Transfer Mode and Automatic Teller = Machine=F0=9F=98=8A). My

> suggestion = to the IPWAVE team is to use =E2=80=9COBE and = RSE=E2=80=9D.

> =

> This is my = personal view as I donot represent any involved interest.  =

> If any one = has questions, let me know.

If we want to = go with OBE instead of OBU then we must be ready to defend it in our = respective contexts.  Are we ready to?

(I already have = a hard time with telling people "802.11p" no longer exists, = especially to those who are afraid I want to use LTE to 'kill' =

802.11p; and = now to tell them to use "OBE" instead of "OBU" just = in order to use IP seems like an additional effort).

All the OBUs I = use do run IP.

Can FCC change = their definition to include a reference to this IP = draft?

Alex

> =

> Francois = Simon

> =

> Lojik = Technologies

> =

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

> =

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

> = Petrescu

> =

> Sent: = Monday, January 29, 2018 10:08 AM

> =

> = To: its@ietf.org

> =

> Subject: = Re: [ipwave] Shepherd review of

> = draft-ietf-ipwave-ipv6-over-80211ocb-12

> =

> =

> =

> Le = 29/01/2018 =C3=A0 15:52, Fran=C3=A7ois Simon a =C3=A9crit = :

> =

>> My = comments arewithin the text*[Fygs.......]*.

> =

> = [...]

> =

>> In the = terminology section, the OBU term is mentioned to be = defined

> =

>> = outside the IETF. This is fine, but we have to provide a = reference.

> =

>> And = even with that, it would not harm to include some short =

>> = definition

> =

>> to = provide context. The RSU term is also defined outside the IETF = and

> =

>> there = is quite a lot of text provided (I think the relevant part = is

> =

>> the = last sentence, the one starting with "The difference = between...").

> =

>> Both = terms should be handled in the same way.

> =

>> =

> =

>> = *[Fygs: The**definitions**was issued by the FCC 20 years ago.  I = have

> =

>> = already provided that information**and references = multiple

> =

>> = times.]***

> =

> The = problem with the FCC definition of OBU is that it has no =

> = relationship to IP.  Worse, that FCC definition has no indication = that

> it MAY use = IP somehow.  And here we say that all OBUs must use IP.  Do =

> you see = what I mean?

> =

> Do you = think FCC will mind if we use the term OBU in this draft to =

> mean = something else?  I, and a colleague, think that FCC would not = mind.

> =

> = Alex

> =

> = _______________________________________________

> =

> its = mailing list

> =

> its@ietf.org

> =

> https://www.ietf.org/mailman/listinfo/its<= SPAN LANG=3D"en-us">

> =

------=_NextPart_000_006F_01D39CD1.7EE3E9C0-- From nobody Sun Feb 4 07:48:53 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 957EE12711A for ; Sun, 4 Feb 2018 07:48:52 -0800 (PST) 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 Sgi6lX60UWQv for ; Sun, 4 Feb 2018 07:48:49 -0800 (PST) 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 11A2012702E for ; Sun, 4 Feb 2018 07:48:43 -0800 (PST) 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 w14Fmgi2006380; Sun, 4 Feb 2018 16:48:42 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2DEA0200C99; Sun, 4 Feb 2018 16:48:42 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 1FE95200BBA; Sun, 4 Feb 2018 16:48:42 +0100 (CET) Received: from [132.166.84.126] ([132.166.84.126]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w14FmfGQ013267; Sun, 4 Feb 2018 16:48:41 +0100 To: =?UTF-8?Q?Fran=c3=a7ois_Simon?= Cc: its@ietf.org References: <1517217856.4315.32.camel@it.uc3m.es> <006601d39910$bdcf1cf0$396d56d0$@gmail.com> <000101d39c0f$e3b32f90$ab198eb0$@gmail.com> From: Alexandre Petrescu Message-ID: <827a8e03-75fc-7b64-9b2a-2c2bdc0288ed@gmail.com> Date: Sun, 4 Feb 2018 16:48:41 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <000101d39c0f$e3b32f90$ab198eb0$@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 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, 04 Feb 2018 15:48:53 -0000 Le 02/02/2018 à 11:23, François Simon a écrit : > Mr. Petrescu, > > Let's try one more time to clarify the FCC DSRC (in US only) issue. > > *FCC – DSRC* > > *Background:*** > > ** > > -** The US Federal Communications Commission (FCC) Dedicated Short Range > Communication (DSRC) is defined in the Code of Federal Regulations (CFR) > 47 mainly Parts 90 and 95. The last update is dated October 1st, 2010; > > -This includes the ASTM E 2213-03 standard: “Standard Specification for > Telecommunications and Information Exchange Between Roadside and Vehicle > Systems — 5 GHz Band Dedicated Short Range Communications (DSRC) Medium > Access Control (MAC) and Physical Layer (PHY) Specifications”; approved > July 10, 2003. The standard is derived from IEEE 802.11a and, in most > part, is equivalent to IEEE 802.11 OCB. To date, the DSRC CFRs do not > specify IEEE 802.11 OCB. > > -The related CFRs state that DSRC shall comply with the ASTM E 2213-03. Thank you for the explanation. It is useful to understand that DSRC is related to ASTM E 2213-03 and that neither refers to 802.11 OCB. I think in works related to standards and products it is advantageous if there is correlation. For example, in an ideal world, standards talk about "A" and the regulation also about "A" and the products and sofware are also labelled "A". In our context, software is labelled "OCB" (kernel drivers), regulation talks "DSRC" and standards "802.11p" and "802.11 OCB". > *Overview of DSRC functions:*** > > ** > > The functions listed in DSRC related CFRs are, in general, specified in > the ASTM E 2213-03 and IEEE 802.11 OCB: > > -MAC service definition, frame format, and procedures; > > -PHY Orthogonal frequency division multiplexing (OFDM); > > -PHY Service Data Unit format and modulations (data rates): > > -5.9 GHz band allocated channels, frequency, max. EIRP, and spectrum mask; > > -Individual Channel use: Safety applications, non-safety applications, > and priorities. > > *Protocols*** > > ** > > DSRC being uniquely a MAC and PHY communications service, I thought "DSRC" is also about Applications and Use-cases. > there here no > restriction on Transport and Network protocols that can be used (except > for the LCC specified by reference in IEEE 802.11 OCB). In the US, the > WAVE standards (IEEE 1609 series) specify these protocols when using > DSRC as the communication service. It is one thing to have no restrictions, and another thing to reckon that IP is the networking layer. > > *OBU / RSU*** > > ** > > The CFR (FCC) definitions are: > > /Roadside unit (RSU). A Roadside Unit is a DSRC transceiver Sigh, it is way different. An RSU product has many transceivers inside. > that is > mounted along a road or pedestrian passageway. An RSU may also be > mounted on a vehicle or is hand carried, but it may only operate when > the vehicle or hand- carried unit is stationary. Furthermore, an RSU > operating under this part is restricted to the location where it is > licensed to operate. However, portable or hand-held RSUs are permitted > to operate where they do not interfere with a site-licensed operation. A > RSU broadcasts data to OBUs or exchanges data with OBUs in its > communications zone. An RSU also provides channel assignments and > operating instructions to OBUs in its communications zone, when > required./- [CFR 90.7 - Definitions] - Revised as October 2010. I think it should be updated to refer to this document. > /On-Board unit (OBU). 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. The OBUs receive and contend for time to > transmit on one or more radio frequency (RF) channels. Except where > specifically excluded, OBU operation is permitted wherever vehicle > operation or human passage is permitted. The OBUs mounted in vehicles > are licensed by rule under part 95 of this chapter and communicate with > Roadside Units (RSUs) and other OBUs. Portable OBUs are also licensed by > rule under part 95 of this chapter. OBU operations in the Unlicensed > National Information Infrastructure (UNII) Bands follow the rules in > those bands./- [CFR 90.7 - Definitions] - October 2010 Thanks for the definitions. They are far different from what we need in this draft. I will see the other suggestions. Alex > > *IPWAVE Issue*** > > ** > > /“The problem with the FCC definition of OBU is that it has no > relationship to IP.  Worse, that FCC definition has no indication that > it MAY use IP somehow.  And here we say that all OBUs must use IP.  Do > you see what I mean?”/// > > // > > Correct; the OBU has no relationship with IP and is not intended to. IP > is a network protocol.  If an On-Board Unit (OBU) device is required to > exchange IP, it needs to be dealt in protocol(s) and/or Management in > higher layers similar to WAVE within the On-Board Equipment (OBE) . > > /“Do you think FCC will mind if we use the term OBU in this draft to > mean something else?  I, and a colleague, think that FCC would not mind.”/// > > // > > Depending of the reader. If one is familiar with DSRC, OBU and RSU as > defined by FCC will come in mind. As far as I know, “OBU” and “RSU” are > not registered and could be used for other definitions (something like > “ATM”: Asynchronous Transfer Mode and Automatic Teller Machine😊). My > suggestion to the IPWAVE team is to use “OBE and RSE”. > > This is my personal view as I donot represent any involved interest.  If > any one has questions, let me know. > > Francois Simon > > Lojik Technologies > > -----Original Message----- > > From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu > > Sent: Monday, January 29, 2018 10:08 AM > > To: its@ietf.org > > Subject: Re: [ipwave] Shepherd review of > draft-ietf-ipwave-ipv6-over-80211ocb-12 > > > > Le 29/01/2018 à 15:52, François Simon a écrit : > >> My comments arewithin the text*[Fygs.......]*. > > [...] > >> In the terminology section, the OBU term is mentioned to be defined > >> outside the IETF. This is fine, but we have to provide a reference. > >> And even with that, it would not harm to include some short definition > >> to provide context. The RSU term is also defined outside the IETF and > >> there is quite a lot of text provided (I think the relevant part is > >> the last sentence, the one starting with "The difference between..."). > >> Both terms should be handled in the same way. > >> > >> *[Fygs: The**definitions**was issued by the FCC 20 years ago.  I have > >> already provided that information**and references multiple > >> times.]*** > > The problem with the FCC definition of OBU is that it has no > relationship to IP.  Worse, that FCC definition has no indication that > it MAY use IP somehow.  And here we say that all OBUs must use IP.  Do > you see what I mean? > > Do you think FCC will mind if we use the term OBU in this draft to mean > something else?  I, and a colleague, think that FCC would not mind. > > Alex > > _______________________________________________ > > its mailing list > > its@ietf.org > > https://www.ietf.org/mailman/listinfo/its > From nobody Sun Feb 4 07:51:06 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99DFB1270FC for ; Sun, 4 Feb 2018 07:51:04 -0800 (PST) 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 QM67VV8_NMkM for ; Sun, 4 Feb 2018 07:51:02 -0800 (PST) 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 A8FF812702E for ; Sun, 4 Feb 2018 07:51:02 -0800 (PST) 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 w14Fp0NB058778; Sun, 4 Feb 2018 16:51:00 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 1BC93201583; Sun, 4 Feb 2018 16:51:00 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 0C55B200C1D; Sun, 4 Feb 2018 16:51:00 +0100 (CET) Received: from [132.166.84.126] ([132.166.84.126]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w14Fox97014458; Sun, 4 Feb 2018 16:50:59 +0100 To: John Kenney Cc: =?UTF-8?Q?Fran=c3=a7ois_Simon?= , its@ietf.org References: <1517217856.4315.32.camel@it.uc3m.es> <006601d39910$bdcf1cf0$396d56d0$@gmail.com> <000101d39c0f$e3b32f90$ab198eb0$@gmail.com> <707c9f11-c10e-f1e3-f68d-ab98fc632ca7@gmail.com> From: Alexandre Petrescu Message-ID: <2352df6e-55d4-5147-1237-d1b68dc78c00@gmail.com> Date: Sun, 4 Feb 2018 16:50:59 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.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] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 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, 04 Feb 2018 15:51:05 -0000 Le 02/02/2018 à 20:12, John Kenney a écrit : > > > Can FCC change their definition to include a reference to this IP draft? > > Absolutely not. Let's kill this idea as quickly as possible.  The FCC is > intentionally agnostic about what comes above the MAC layer of DSRC. > There is no reason why they should mention IP or any other higher layer > protocol, and the lack of mention of such protocols should be understood > to mean there are no regulatory requirements with respect to them. > > Also, please do not re-use the terms OBU and RSU with different meanings > than given by the FCC. That's asking for trouble. Please don't create > new definitions of OBE and RSE either. Tony Li's suggestion for an > IP-specific label seems like a good way to proceed. Noted. > > I also mention that the IEEE 802.11p, 1609.2, 1609.3 and 1609.4 > standards do not use either of those terms.  In other words, from a WAVE > standards point of view, there is no distinction between an OBU and an > RSU.  I haven't been following this IETF work very closely, but it may > be worth re-examining whether any such distinctions are necessary for > you as well. Noted. Alex > > Best Regards, > John > > -- > John Kenney > Director and Principal Researcher > Toyota InfoTechnology Center, USA > 465 Bernardo Avenue > Mountain View, CA 94043 > Tel: 650-694-4160. Mobile: 650-224-6644 From nobody Sun Feb 4 08:07:52 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E55F71270AB for ; Sun, 4 Feb 2018 08:07:50 -0800 (PST) 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 krPZc-nXRkkr for ; Sun, 4 Feb 2018 08:07:49 -0800 (PST) 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 C3DA9127077 for ; Sun, 4 Feb 2018 08:07:48 -0800 (PST) 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 w14G7k7t008529; Sun, 4 Feb 2018 17:07:46 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9598A200FCC; Sun, 4 Feb 2018 17:07:46 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 69F4F200C1D; Sun, 4 Feb 2018 17:07:46 +0100 (CET) Received: from [132.166.84.126] ([132.166.84.126]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w14G7jVt024354; Sun, 4 Feb 2018 17:07:45 +0100 To: =?UTF-8?Q?Fran=c3=a7ois_Simon?= Cc: its@ietf.org References: <1517217856.4315.32.camel@it.uc3m.es> <006601d39910$bdcf1cf0$396d56d0$@gmail.com> <000101d39c0f$e3b32f90$ab198eb0$@gmail.com> From: Alexandre Petrescu Message-ID: <87888ef4-ae0e-421c-0e48-43b0276f038a@gmail.com> Date: Sun, 4 Feb 2018 17:07:44 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <000101d39c0f$e3b32f90$ab198eb0$@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 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, 04 Feb 2018 16:07:51 -0000 I am adding this OBU ref for reference but I have a question: Le 02/02/2018 à 11:23, François Simon a écrit : [...] > /On-Board unit (OBU). An On-Board Unit is a DSRCS transceiver that is Is DSRCS a typo? (correct DSRC). Alex > 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. The OBUs receive and contend for time to > transmit on one or more radio frequency (RF) channels. Except where > specifically excluded, OBU operation is permitted wherever vehicle > operation or human passage is permitted. The OBUs mounted in vehicles > are licensed by rule under part 95 of this chapter and communicate with > Roadside Units (RSUs) and other OBUs. Portable OBUs are also licensed by > rule under part 95 of this chapter. OBU operations in the Unlicensed > National Information Infrastructure (UNII) Bands follow the rules in > those bands./- [CFR 90.7 - Definitions] - October 2010 > > *IPWAVE Issue*** > > ** > > /“The problem with the FCC definition of OBU is that it has no > relationship to IP.  Worse, that FCC definition has no indication that > it MAY use IP somehow.  And here we say that all OBUs must use IP.  Do > you see what I mean?”/// > > // > > Correct; the OBU has no relationship with IP and is not intended to. IP > is a network protocol.  If an On-Board Unit (OBU) device is required to > exchange IP, it needs to be dealt in protocol(s) and/or Management in > higher layers similar to WAVE within the On-Board Equipment (OBE) . > > /“Do you think FCC will mind if we use the term OBU in this draft to > mean something else?  I, and a colleague, think that FCC would not mind.”/// > > // > > Depending of the reader. If one is familiar with DSRC, OBU and RSU as > defined by FCC will come in mind. As far as I know, “OBU” and “RSU” are > not registered and could be used for other definitions (something like > “ATM”: Asynchronous Transfer Mode and Automatic Teller Machine😊). My > suggestion to the IPWAVE team is to use “OBE and RSE”. > > This is my personal view as I donot represent any involved interest.  If > any one has questions, let me know. > > Francois Simon > > Lojik Technologies > > -----Original Message----- > > From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu > > Sent: Monday, January 29, 2018 10:08 AM > > To: its@ietf.org > > Subject: Re: [ipwave] Shepherd review of > draft-ietf-ipwave-ipv6-over-80211ocb-12 > > > > Le 29/01/2018 à 15:52, François Simon a écrit : > >> My comments arewithin the text*[Fygs.......]*. > > [...] > >> In the terminology section, the OBU term is mentioned to be defined > >> outside the IETF. This is fine, but we have to provide a reference. > >> And even with that, it would not harm to include some short definition > >> to provide context. The RSU term is also defined outside the IETF and > >> there is quite a lot of text provided (I think the relevant part is > >> the last sentence, the one starting with "The difference between..."). > >> Both terms should be handled in the same way. > >> > >> *[Fygs: The**definitions**was issued by the FCC 20 years ago.  I have > >> already provided that information**and references multiple > >> times.]*** > > The problem with the FCC definition of OBU is that it has no > relationship to IP.  Worse, that FCC definition has no indication that > it MAY use IP somehow.  And here we say that all OBUs must use IP.  Do > you see what I mean? > > Do you think FCC will mind if we use the term OBU in this draft to mean > something else?  I, and a colleague, think that FCC would not mind. > > Alex > > _______________________________________________ > > its mailing list > > its@ietf.org > > https://www.ietf.org/mailman/listinfo/its > From nobody Sun Feb 4 08:10:37 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD1FF127077 for ; Sun, 4 Feb 2018 08:10:35 -0800 (PST) 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 mqZI2RutY3V5 for ; Sun, 4 Feb 2018 08:10:34 -0800 (PST) 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 EE12E1271FD for ; Sun, 4 Feb 2018 08:10:33 -0800 (PST) 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 w14GAW3v046369 for ; Sun, 4 Feb 2018 17:10:32 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4192520147D for ; Sun, 4 Feb 2018 17:10:32 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 2F086200FF1 for ; Sun, 4 Feb 2018 17:10:32 +0100 (CET) Received: from [132.166.84.126] ([132.166.84.126]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w14GAV2l026066 for ; Sun, 4 Feb 2018 17:10:32 +0100 To: its@ietf.org References: <1517217856.4315.32.camel@it.uc3m.es> From: Alexandre Petrescu Message-ID: <330dcee5-163a-32e0-d99d-34a2cd3fa03e@gmail.com> Date: Sun, 4 Feb 2018 17:10:31 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <1517217856.4315.32.camel@it.uc3m.es> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 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, 04 Feb 2018 16:10:36 -0000 Le 29/01/2018 à 10:24, Carlos Jesús Bernardos Cano a écrit : [...] > - The use of MAY (to be interpreted as in RFC2119) in the terminology > section does not seem appropriate to me. I don't think normative text > applies to whether an OBRU may be ab IP router. Following suggestions I propose we use "IP-OBU" instead of OBRU, and remove the MAY, if you do not mind. Alex From nobody Sun Feb 4 09:06:30 2018 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 28A71127369; Sun, 4 Feb 2018 09:06:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: its@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.71.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151776398910.12307.1103664206845001181@ietfa.amsl.com> Date: Sun, 04 Feb 2018 09:06:29 -0800 Archived-At: Subject: [ipwave] I-D Action: draft-ietf-ipwave-ipv6-over-80211ocb-13.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, 04 Feb 2018 17:06:29 -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 Jerome Haerri Jong-Hyouk Lee Thierry Ernst Filename : draft-ietf-ipwave-ipv6-over-80211ocb-13.txt Pages : 38 Date : 2018-02-04 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. 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-13 https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-13 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 Feb 4 09:07:42 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78F9C12751F for ; Sun, 4 Feb 2018 09:07:41 -0800 (PST) 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 bNKz5eEuhOTa for ; Sun, 4 Feb 2018 09:07:39 -0800 (PST) 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 84CD6127369 for ; Sun, 4 Feb 2018 09:07:39 -0800 (PST) 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 w14H7bcq067541 for ; Sun, 4 Feb 2018 18:07:37 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 94031200FF1 for ; Sun, 4 Feb 2018 18:07:37 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 6BB51201583 for ; Sun, 4 Feb 2018 18:07:37 +0100 (CET) Received: from [132.166.84.126] ([132.166.84.126]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w14H7avi026759 for ; Sun, 4 Feb 2018 18:07:37 +0100 To: its@ietf.org References: <1517217856.4315.32.camel@it.uc3m.es> From: Alexandre Petrescu Message-ID: Date: Sun, 4 Feb 2018 18:07:36 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <1517217856.4315.32.camel@it.uc3m.es> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 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, 04 Feb 2018 17:07:41 -0000 Le 29/01/2018 à 10:24, Carlos Jesús Bernardos Cano a écrit : [...] > - The abstract mentions that in order to transmit IPv6 packets on IEEE > 802.11-OCB, "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". But the MTU part of the draft does not use any normative text, > the header format is exactly the same than for IEEE 802.11, as the > type value. The MTU text currently says: > The default MTU for IP packets on 802.11-OCB is 1500 octets. I modify it to say: > The default MTU for IP packets on 802.11-OCB MUST be 1500 octets. > - Section 1 lists two exceptions for 802.11-OCB compared to Ethernet. > The first one is not different from regular 802.11, I dont understand you. The first one says that there are differences between IP-over-WiFi and IP-over-Ethernet. These differences are in the headers. To adapt to these differences an Ethernet Adaptation Layer is proposed. Does this explain better? Do I understand the worry correctly? > but for the second > one, the document only provides recommendations. Should it provide something else? > - I always thought that "WiFi" does not stand for "Wireless Fidelity". > See https://boingboing.net/2005/11/08/wifi-isnt-short-for.html Other persons commented, so at this time I propose to leave the def unchanged. [...] > > - In section 3, it is mentioned that "the operating environment > (vehicular networks) brings in new perspectives" --> which are those > (that are covered/tackled by the document? The document does not cover these new 'perspectives'. The 'perspectives' are the ND operation, the handovers for Mobile IP, the security - the 3 perspectives are difference in OCB than in WiFi. We dont describe any here. Maybe new work is needed for ND-over-OCB, or Mobile IP with OCB access, or Security for OCB. > - In section 4.1, does the text mean that the MTU SHOULD/MUST be 1500 > octects. If that is what is meant, this is really a normative thing > that should be written using normative text. If it is just a > recommendation, then this should be clearly written as such. MUST be. > - All the text of section 4.2.1 is not normative, but more a report of > what is done today in existing implementations. YEs, it is done today in existing WiFi implementations (not Ethernet). > Is there any different > there that is specific of 802.11-OCB? No, there is nothing different. I can change the text, but not sure what would be ok. Should I move section 4.2.1 in an Appendix? > - All subsections 4.x seem informative, not normative. Similar to MTU, I could write in the 4.2 "Frame Format" that the EtherType MUST be 0x86DD (instead of just "is"). Would this make it more Normative? In section 4.3 "LL Addresses" I could put "it is RECOMMENDED" instead of "it is recommended". Sections 4.4. "Address Mapping" and 4.4.1 "Address Mapping -- Unicast" I could remove. Section 4.4.2 "Address Mapping - Multicast" could be removed. Section 4.5 "Stateless Autoconf" - I could write "the u/g bits MUST be opaque" instead of "are significant". Section 4.6 "Subnet Structure" - could be removed altogether. Are these ok with you? > - The privacy part of section 5 is important, as it impacts the > operation of IPv6 over this type of networks, so I think this deserves > more attention. Should I make a subsection called "Privacy Considerations" within the SEcurity considerations? > - In section, H.1, more details about how the captures were obtained > should be provided (HW, SW, etc.). We added this if sounds ok: > The packet is captured on the Host. The Host is an IP-OBU > containing an 802.11 interface in format PCI express (an ITRI > product). The kernel runs the ath5k software driver with > modifications for OCB mode. The capture tool is Wireshark. > The file format for save and analyze is 'pcap'. The packet is > generated by the Router. The Router is an IP-RSU (ITRI > product). > Authors, please respond to my questions/comments and address them in a > new version of the document. We submitted a new version, but please reply to my comments so I fully address the comments. https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-13 Alex From nobody Sun Feb 4 09:08:45 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB55912751F for ; Sun, 4 Feb 2018 09:08:43 -0800 (PST) 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 s0LVvIQSjA0q for ; Sun, 4 Feb 2018 09:08:42 -0800 (PST) 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 E27AB127369 for ; Sun, 4 Feb 2018 09:08:41 -0800 (PST) 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 w14H8ejG067673 for ; Sun, 4 Feb 2018 18:08:40 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 29A7F201A74 for ; Sun, 4 Feb 2018 18:08:40 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 1E627201583 for ; Sun, 4 Feb 2018 18:08:40 +0100 (CET) Received: from [132.166.84.126] ([132.166.84.126]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w14H8dVj027329 for ; Sun, 4 Feb 2018 18:08:39 +0100 References: <151776398936.12307.8496388113130838703.idtracker@ietfa.amsl.com> To: "its@ietf.org" From: Alexandre Petrescu X-Forwarded-Message-Id: <151776398936.12307.8496388113130838703.idtracker@ietfa.amsl.com> Message-ID: Date: Sun, 4 Feb 2018 18:08:38 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <151776398936.12307.8496388113130838703.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------BD8898B1B4535B7C2D5E653B" Content-Language: fr Archived-At: Subject: [ipwave] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-13.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, 04 Feb 2018 17:08:44 -0000 This is a multi-part message in MIME format. --------------BD8898B1B4535B7C2D5E653B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit This addresses partially the Shepherd's comments. Alex -------- Message transféré -------- Sujet : New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-13.txt Date : Sun, 4 Feb 2018 09:06:29 -0800 De : internet-drafts@ietf.org Pour : Jerome Haerri , ipwave-chairs@ietf.org, Jerome Haerri , Alexandre Petrescu , Alexandre Petrescu , Nabil Benamar , Thierry Ernst , Jong-Hyouk Lee A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-13.txt has been successfully submitted by Alexandre Petrescu and posted to the IETF repository. Name: draft-ietf-ipwave-ipv6-over-80211ocb Revision: 13 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: 2018-02-04 Group: ipwave Pages: 38 URL: https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-13.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-13 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-13 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-13 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. 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 --------------BD8898B1B4535B7C2D5E653B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

This addresses partially the Shepherd's comments.

Alex



-------- Message transféré --------
Sujet : New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-13.txt
Date : Sun, 4 Feb 2018 09:06:29 -0800
De : internet-drafts@ietf.org
Pour : Jerome Haerri <Jerome.Haerri@eurecom.fr>, ipwave-chairs@ietf.org, Jerome Haerri <jerome.haerri@eurecom.fr>, Alexandre Petrescu <Alexandre.Petrescu@cea.fr>, Alexandre Petrescu <alexandre.petrescu@cea.fr>, Nabil Benamar <n.benamar@est.umi.ac.ma>, Thierry Ernst <thierry.ernst@yogoko.fr>, Jong-Hyouk Lee <jonghyouk@smu.ac.kr> 


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

Name:		draft-ietf-ipwave-ipv6-over-80211ocb
Revision:	13
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:	2018-02-04
Group:		ipwave
Pages:		38
URL:            https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-13.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-13
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-13
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-13

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.

                                                                                  


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
--------------BD8898B1B4535B7C2D5E653B-- From nobody Sun Feb 4 09:56:24 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 497D4127775 for ; Sun, 4 Feb 2018 09:56:21 -0800 (PST) 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 l7i5TvjhhS_w for ; Sun, 4 Feb 2018 09:56:17 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DD341275C5 for ; Sun, 4 Feb 2018 09:56:17 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id c82so2027211qka.0 for ; Sun, 04 Feb 2018 09:56:17 -0800 (PST) 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=/tvpcVa7YJia3W32eYKMvDec8eDdPq/m2NR8OdgTGgo=; b=Of3kgSyvBP7XjrfAhIGVxhK0JcCyKzx4qltG4x3hUvUCNG2AhnhaP4y3p0g7p2F634 oP0FS8etW9q1z0ecXgMp3yixhV3xhNdlqdt2FYRu9HNbS89DimPI7TS/0AOgdmRn8Kdv nkDX2ggh6aDF4tPjxR/FtQ/m4auLoOnaCDNMUkLy8AeKZMn5XI0Dp3VDKjXlop/pKzDj GMbRhPU5C7CPo1kZUWAVx1BEmitKc+lKUCmVFYHHmEWdtQKgirsJSWquqpOeLJFCp9t9 YiPC6fii8xCXjW0L8X5XTorU4vGnLk6UCetwu/p3W0eW6ti0I43ZQWjkj/N9u5P4RamY 8XSw== 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=/tvpcVa7YJia3W32eYKMvDec8eDdPq/m2NR8OdgTGgo=; b=MRTgM7ZXC1rdD3DOUad0MVTEF0rVuQ3PLvBFXc6m1+lei7FzaVM2Wf73/sJ5Isskw2 kjYjYoOirRk7jlqSZP6rNgJti4/pzKQ/yXlnqWAueHTw/8F++xMktsgoaXnTQuCpqy6C REHJ21w4fWW+VnZuqHPmGpjs7e1vNfW4XnDbjgOZxToEz1mbl2MTup546um+Zg4Hmtrk F3/YKE7t7SUhmznZQWKLyrmjR7nIIpl5yjZskhDPE53BbChKqeQrHQpMAaJC5oVHmLYG qmyW9ioQUmG86V5RBMMzd8xtyw1lTaxMtRShvtRRFswoeftvq3gpxL+8VDzy1hfvUHGj 2mZQ== X-Gm-Message-State: APf1xPA8zfrl3inytJqljw7jp7Esw43XbBcnT8NNFGlWi9z2ewbTOV7g 3owcPA1+O3/oOm3hq2GP4uX+Cg== X-Google-Smtp-Source: AH8x227Ew5g/DyKAYqegTJEYrasnB34cdcFNF0cEK6lm0wLz6o7G24uXMilJpogqpTc34RZbo4SNzw== X-Received: by 10.55.59.203 with SMTP id i194mr15338137qka.60.1517766976090; Sun, 04 Feb 2018 09:56:16 -0800 (PST) Received: from FrancoisPC (pool-108-48-182-86.washdc.fios.verizon.net. [108.48.182.86]) by smtp.gmail.com with ESMTPSA id m68sm4564792qkc.5.2018.02.04.09.56.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Feb 2018 09:56:15 -0800 (PST) From: =?UTF-8?Q?Fran=C3=A7ois_Simon?= To: , Cc: , References: <1517217856.4315.32.camel@it.uc3m.es> <006601d39910$bdcf1cf0$396d56d0$@gmail.com> <000101d39c0f$e3b32f90$ab198eb0$@gmail.com> <707c9f11-c10e-f1e3-f68d-ab98fc632ca7@gmail.com> <000a01d39c59$f944e2a0$ebcea7e0$@gmail.com> <006e01d39cfb$67b536d0$371fa470$@gmail.com> In-Reply-To: <006e01d39cfb$67b536d0$371fa470$@gmail.com> Date: Sun, 4 Feb 2018 12:56:13 -0500 Message-ID: <003801d39de1$72fad540$58f07fc0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0039_01D39DB7.8A2BF930" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQL7ISfFSBtQJ/i74DjDJlbgILh28gG4su6HASuQMD8BaTCMjwK9q5dAAk24uYoBkDUWX6DuNybQ Archived-At: Subject: [ipwave] FW: Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 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, 04 Feb 2018 17:56:21 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0039_01D39DB7.8A2BF930 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I am not sure this was sent. I apologize. Fygs =20 From: Fran=C3=A7ois Simon [mailto:fygsimon@gmail.com]=20 Sent: Saturday, February 03, 2018 9:29 AM To: cjbc@it.uc3m.es; alexandre.petrescu@gmail.com Cc: its@ietf.org; fygsimon@gmail.com Subject: FW: [ipwave] Shepherd review of = draft-ietf-ipwave-ipv6-over-80211ocb-12 =20 Gentlemen, Mr. Petrescu responded to my email with: 1. " If we want to go with OBE instead of OBU then we must be ready = to defend it in our respective contexts. Are we ready to?" Argument: From the FCC is concerned, the term "Roadside Equipment" is = not defined. Its purpose was to allocated 75 MHz within the 5.9 GHz = spectrum, define a channel plan, and define application priorities = (emphasis on safety applications) in the use of the allocated channels = (mainly for government entities). However, The US DOT defines OBE and = RSE: - On-Board Equipment (OBE) - Term refers to the compliment of = equipment located in the vehicle for the purpose of supporting the = vehicle side of the applications. It is likely to include the DSRC = radios, other radio equipment, message processing, driver interface, and = other applications to support the use cases described herein [see = Reference]. It is also referred to as the Vehicle ITS Station. When = referring to the DSRC radio alone, the correct term is OBU.=E2=80=9D - Roadside Equipment (RSE) - Term used to describe the compliment = of equipment to be located at the roadside; the RSE will prepare and = transmit messages to the vehicles and receive messages from the vehicles = for the purpose of supporting the V2I applications. This is intended to = include the DSRC radio, traffic signal controller where appropriate, = interface to the backhaul communications network necessary to support = the applications, and support such functions as data security, = encryption, buffering, and message processing. When speaking of the DSRC = radio alone, the correct term is RSU.=E2=80=9D. Reference: 2015 FHWA Vehicle to Infrastructure Deployment Guidance and = Products. 2. =E2=80=9C(I already have a hard time with telling people = "802.11p" no longer exists,=E2=80=A6=E2=80=9D Argument: You have made the point (justification) once. In verbal = discussion, let the member refer it as they wish. As an editor of IPWAVE = documents, mention the rational once in the introduction and insure that = =E2=80=9CIEEE 802.11p=E2=80=9D is replaced by =E2=80=9C802.11 = OCB=E2=80=9D in the remaining text. 3. =E2=80=9C=E2=80=A6.especially to those who are afraid I want to = use LTE to 'kill' 802.11p=E2=80=A6=E2=80=9D Argument: If this is yours and your organization goal, you are not the = only one. This has been debated for few years already. This is not a = technical argument, therefore I will not address it.=20 4. =E2=80=9C=E2=80=A6and now to tell them to use "OBE" instead of = "OBU" just in order to use IP seems like an additional effort).=E2=80=9D Argument: I am not suggesting to do a =E2=80=9Cglobal=E2=80=9D change = of =E2=80=9COBU / RSU=E2=80=9D with =E2=80=9COBE / RSE=E2=80=9D. = =E2=80=9CUnit=E2=80=9D and =E2=80=9CEquipment=E2=80=9D have their own = context. However, =E2=80=9CUnit=E2=80=9D is the radio included in = =E2=80=9CEquipment=E2=80=9D and by itself does not make a system = enabling the transportation of IP as defined by IETF. I am suggesting = the use of OBU/OBE and RSU/RSE within their appropriate context. 5. =E2=80=9CAll the OBUs I use do run IP.=E2=80=9D Argument: It depends of your definition of =E2=80=9Crun=E2=80=9D. The = OBU (radio) does nothing with IP (or any other network protocols). The = OBU exchange MAC protocol data units (MPDU) with its peer(s) via a = wireless media channel. The Internet Protocol (IP) is the payload of = the MPDU. 6. =E2=80=9CCan FCC change their definition to include a reference = to this IP draft?:=E2=80=9D Argument: NO. FCC is an independent agency of the US government. For = some of you who remember the PTTs in Europe, it is somewhat similar; two = to three years to fulfill a simple residence telephone request; should I = say more? =F0=9F=98=89=20 I hope this help somewhat but do remember this comments apply to US = only. If you have any comments and/or questions, let me know. Sincerely, Francois Simon Lojik Technologies -----Original Message----- From: Fran=C3=A7ois Simon [mailto:fygsimon@gmail.com] Sent: Friday, February 02, 2018 2:14 PM To: fygsimon@gmail.com =20 Subject: FW: [ipwave] Shepherd review of = draft-ietf-ipwave-ipv6-over-80211ocb-12 -----Original Message----- From: Alexandre Petrescu [ = mailto:alexandre.petrescu@gmail.com]=20 Sent: Friday, February 02, 2018 9:30 AM To: Fran=C3=A7ois Simon = > Cc: its@ietf.org =20 Subject: Re: [ipwave] Shepherd review of = draft-ietf-ipwave-ipv6-over-80211ocb-12 =20 Le 02/02/2018 =C3=A0 11:23, Fran=C3=A7ois Simon a =C3=A9crit : > Mr. Petrescu, >=20 > Let's try one more time to clarify the FCC DSRC (in US only) issue. >=20 > *FCC =E2=80=93 DSRC* >=20 > *Background:*** >=20 > ** >=20 > -** The US Federal Communications Commission (FCC) Dedicated Short=20 > Range Communication (DSRC) is defined in the Code of Federal=20 > Regulations (CFR) > 47 mainly Parts 90 and 95. The last update is dated October 1st, 2010; >=20 > -This includes the ASTM E 2213-03 standard: =E2=80=9CStandard = Speci=EF=AC=81cation for=20 > Telecommunications and Information Exchange Between Roadside and=20 > Vehicle Systems =E2=80=94 5 GHz Band Dedicated Short Range = Communications=20 > (DSRC) Medium Access Control (MAC) and Physical Layer (PHY)=20 > Speci=EF=AC=81cations=E2=80=9D; approved July 10, 2003. The standard = is derived from=20 > IEEE 802.11a and, in most part, is equivalent to IEEE 802.11 OCB. To=20 > date, the DSRC CFRs do not specify IEEE 802.11 OCB. >=20 > -The related CFRs state that DSRC shall comply with the ASTM E = 2213-03. >=20 > *Overview of DSRC functions:*** >=20 > ** >=20 > The functions listed in DSRC related CFRs are, in general, specified=20 > in the ASTM E 2213-03 and IEEE 802.11 OCB: >=20 > -MAC service definition, frame format, and procedures; >=20 > -PHY Orthogonal frequency division multiplexing (OFDM); >=20 > -PHY Service Data Unit format and modulations (data rates): >=20 > -5.9 GHz band allocated channels, frequency, max. EIRP, and spectrum=20 > mask; >=20 > -Individual Channel use: Safety applications, non-safety applications, = > and priorities. >=20 > *Protocols*** >=20 > ** >=20 > DSRC being uniquely a MAC and PHY communications service, there here=20 > no restriction on Transport and Network protocols that can be used=20 > (except for the LCC specified by reference in IEEE 802.11 OCB). In the = > US, the WAVE standards (IEEE 1609 series) specify these protocols when = > using DSRC as the communication service. >=20 > *OBU / RSU*** >=20 > ** >=20 > The CFR (FCC) definitions are: >=20 > /Roadside unit (RSU). A Roadside Unit is a DSRC transceiver that is=20 > mounted along a road or pedestrian passageway. An RSU may also be=20 > mounted on a vehicle or is hand carried, but it may only operate when=20 > the vehicle or hand- carried unit is stationary. Furthermore, an RSU=20 > operating under this part is restricted to the location where it is=20 > licensed to operate. However, portable or hand-held RSUs are permitted = > to operate where they do not interfere with a site-licensed operation. = > A RSU broadcasts data to OBUs or exchanges data with OBUs in its=20 > communications zone. An RSU also provides channel assignments and=20 > operating instructions to OBUs in its communications zone, when > required./- [CFR 90.7 - Definitions] - Revised as October 2010. >=20 > /On-Board unit (OBU). An On-Board Unit is a DSRCS transceiver that is=20 > 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=20 > is either mobile or stationary. The OBUs receive and contend for time=20 > to transmit on one or more radio frequency (RF) channels. Except where = > specifically excluded, OBU operation is permitted wherever vehicle=20 > operation or human passage is permitted. The OBUs mounted in vehicles=20 > are licensed by rule under part 95 of this chapter and communicate=20 > with Roadside Units (RSUs) and other OBUs. Portable OBUs are also=20 > licensed by rule under part 95 of this chapter. OBU operations in the=20 > Unlicensed National Information Infrastructure (UNII) Bands follow the = > rules in those bands./- [CFR 90.7 - Definitions] - October 2010 >=20 > *IPWAVE Issue*** >=20 > ** >=20 > /=E2=80=9CThe problem with the FCC definition of OBU is that it has no = > relationship to IP. Worse, that FCC definition has no indication that = > it MAY use IP somehow. And here we say that all OBUs must use IP. Do = > you see what I mean?=E2=80=9D/// >=20 > // >=20 > Correct; the OBU has no relationship with IP and is not intended to.=20 > IP is a network protocol. If an On-Board Unit (OBU) device is=20 > required to exchange IP, it needs to be dealt in protocol(s) and/or=20 > Management in higher layers similar to WAVE within the On-Board = Equipment (OBE) . >=20 > /=E2=80=9CDo you think FCC will mind if we use the term OBU in this = draft to=20 > mean something else? I, and a colleague, think that FCC would not=20 > mind.=E2=80=9D/// >=20 > // >=20 > Depending of the reader. If one is familiar with DSRC, OBU and RSU as=20 > defined by FCC will come in mind. As far as I know, = =E2=80=9COBU=E2=80=9D and =E2=80=9CRSU=E2=80=9D=20 > are not registered and could be used for other definitions (something=20 > like > =E2=80=9CATM=E2=80=9D: Asynchronous Transfer Mode and Automatic Teller = Machine=F0=9F=98=8A). My=20 > suggestion to the IPWAVE team is to use =E2=80=9COBE and RSE=E2=80=9D. >=20 > This is my personal view as I donot represent any involved interest. =20 > If any one has questions, let me know. If we want to go with OBE instead of OBU then we must be ready to defend = it in our respective contexts. Are we ready to? (I already have a hard time with telling people "802.11p" no longer = exists, especially to those who are afraid I want to use LTE to 'kill'=20 802.11p; and now to tell them to use "OBE" instead of "OBU" just in = order to use IP seems like an additional effort). All the OBUs I use do run IP. Can FCC change their definition to include a reference to this IP draft? Alex >=20 > Francois Simon >=20 > Lojik Technologies >=20 > -----Original Message----- >=20 > From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre=20 > Petrescu >=20 > Sent: Monday, January 29, 2018 10:08 AM >=20 > To: its@ietf.org =20 >=20 > Subject: Re: [ipwave] Shepherd review of > draft-ietf-ipwave-ipv6-over-80211ocb-12 >=20 >=20 >=20 > Le 29/01/2018 =C3=A0 15:52, Fran=C3=A7ois Simon a =C3=A9crit : >=20 >> My comments arewithin the text*[Fygs.......]*. >=20 > [...] >=20 >> In the terminology section, the OBU term is mentioned to be defined >=20 >> outside the IETF. This is fine, but we have to provide a reference. >=20 >> And even with that, it would not harm to include some short=20 >> definition >=20 >> to provide context. The RSU term is also defined outside the IETF and >=20 >> there is quite a lot of text provided (I think the relevant part is >=20 >> the last sentence, the one starting with "The difference = between...").=20 >=20 >> Both terms should be handled in the same way. >=20 >>=20 >=20 >> *[Fygs: The**definitions**was issued by the FCC 20 years ago. I have >=20 >> already provided that information**and references multiple >=20 >> times.]*** >=20 > The problem with the FCC definition of OBU is that it has no=20 > relationship to IP. Worse, that FCC definition has no indication that = > it MAY use IP somehow. And here we say that all OBUs must use IP. Do = > you see what I mean? >=20 > Do you think FCC will mind if we use the term OBU in this draft to=20 > mean something else? I, and a colleague, think that FCC would not = mind. >=20 > Alex >=20 > _______________________________________________ >=20 > its mailing list >=20 > its@ietf.org =20 >=20 > https://www.ietf.org/mailman/listinfo/its >=20 ------=_NextPart_000_0039_01D39DB7.8A2BF930 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable FW: [ipwave] Shepherd review of = draft-ietf-ipwave-ipv6-over-80211ocb-12

I am not = sure this was sent.=C2=A0 I apologize.=C2=A0 Fygs

 

From: Fran=C3=A7ois Simon = [mailto:fygsimon@gmail.com]
Sent: Saturday, February 03, 2018 = 9:29 AM
To: cjbc@it.uc3m.es; = alexandre.petrescu@gmail.com
Cc: its@ietf.org; = fygsimon@gmail.com
Subject: FW: [ipwave] Shepherd review of = draft-ietf-ipwave-ipv6-over-80211ocb-12

 

Gentlemen,

Mr.= Petrescu responded to my email = with:

1.      " If we = want to go with OBE instead of OBU then we must be ready to defend it in = our respective contexts.  Are we ready = to?"

Argument: From the FCC is concerned, = the term "Roadside Equipment" is not defined. Its = purpose was to allocated 75 MHz within the 5.9 GHz spectrum, define a = channel plan, and define application priorities (emphasis on safety = applications) in the use of the allocated channels (mainly for = government entities).  However, The US DOT defines OBE and = RSE:

-       On-Board Equipment = (OBE) - Term refers to the compliment of equipment located in the = vehicle for the purpose of supporting the vehicle side of the = applications. It is likely to include the DSRC radios, other radio = equipment, message processing, driver interface, and other applications = to support the use cases described herein [see Reference]. It is also = referred to as the Vehicle ITS Station. When referring to the DSRC radio = alone, the correct term is OBU.=E2=80=9D

-       Roadside Equipment = (RSE) - Term used to describe the compliment of equipment to be located = at the roadside; the RSE will prepare and transmit messages to the = vehicles and receive messages from the vehicles for the purpose of = supporting the V2I applications. This is intended to include the DSRC = radio, traffic signal controller where appropriate, interface to the = backhaul communications network necessary to support the applications, = and support such functions as data security, encryption, buffering, and = message processing. When speaking of the DSRC radio alone, the correct = term is RSU.=E2=80=9D.

Reference: 2015 FHWA Vehicle to = Infrastructure Deployment Guidance and = Products.

2.      = =E2=80=9C(I already have a hard time with telling people = "802.11p" no longer = exists,=E2=80=A6=E2=80=9D

Argument:  You have made = the point (justification) once. In verbal discussion, let the member = refer it as they wish. As an editor of IPWAVE documents, mention the = rational once in the introduction and insure that =E2=80=9CIEEE = 802.11p=E2=80=9D is replaced by =E2=80=9C802.11 OCB=E2=80=9D in the = remaining text.

3.      = =E2=80=9C=E2=80=A6.especially to those who are afraid I want to use LTE = to 'kill' 802.11p=E2=80=A6=E2=80=9D

Argument:  If this is yours and = your organization goal, you are not the only one. This has been debated = for few years already.  This is not a technical argument, therefore = I will not address it. =

4.      = =E2=80=9C=E2=80=A6and now to tell them to use "OBE" instead = of "OBU" just in order to use IP seems like an additional = effort).=E2=80=9D

Argument:  I am not suggesting to = do a =E2=80=9Cglobal=E2=80=9D change of =E2=80=9COBU / RSU=E2=80=9D with = =E2=80=9COBE / RSE=E2=80=9D.  =E2=80=9CUnit=E2=80=9D and = =E2=80=9CEquipment=E2=80=9D have their own context.  However, = =E2=80=9CUnit=E2=80=9D is the radio included in = =E2=80=9CEquipment=E2=80=9D and by itself does not make a system = enabling the transportation of IP as defined by IETF.  I am = suggesting the use of OBU/OBE and RSU/RSE within their appropriate = context.

5.      = =E2=80=9CAll the OBUs I use do run IP.=E2=80=9D

Argument: It depends of your = definition of =E2=80=9Crun=E2=80=9D. The OBU (radio) does nothing with = IP (or any other network protocols). The OBU exchange MAC protocol data = units (MPDU) with its peer(s) via a wireless media channel.  The = Internet Protocol (IP) is the payload  of the = MPDU.

6.      =E2=80=9CCan FCC = change their definition to include a reference to this IP = draft?:=E2=80=9D

Argument: NO.  FCC is an independent agency of the US government. For some of you = who remember the PTTs in Europe, it is somewhat similar; two to three = years to fulfill a simple residence telephone request; should I say = more? 😉 =

I hope this help somewhat but do remember this = comments apply to US only.  If you have any comments and/or = questions, let me = know.

Sincerely,

Francois = Simon

Lojik Technologies

-----Original = Message-----
From: Fran=C3=A7ois Simon [mailto:fygsimon@gmail.com]
Sent= : Friday, February 02, 2018 2:14 PM
To: fygsimon@gmail.com
Subject: = FW: [ipwave] Shepherd review of = draft-ietf-ipwave-ipv6-over-80211ocb-12

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

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

Sent: Friday, February 02, 2018 9:30 = AM

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

Cc: its@ietf.org

Subject: = Re: [ipwave] Shepherd review of = draft-ietf-ipwave-ipv6-over-80211ocb-12

 

Le 02/02/2018 = =C3=A0 11:23, Fran=C3=A7ois Simon a =C3=A9crit :

> = Mr. Petrescu,

>

> Let's try one = more time to clarify the FCC DSRC (in US only) = issue.

>

> *FCC =E2=80=93 = DSRC*

>

> = *Background:***

>

> = **

>

> -** The US Federal = Communications Commission (FCC) Dedicated Short

> = Range Communication (DSRC) is defined in the Code of Federal =

> Regulations (CFR)

> 47 mainly = Parts 90 and 95. The last update is dated October 1st, = 2010;

>

> -This includes the = ASTM E 2213-03 standard: =E2=80=9CStandard Speci=EF=AC=81cation for =

> Telecommunications and Information Exchange = Between Roadside and

> Vehicle Systems =E2=80=94 5 = GHz Band Dedicated Short Range Communications

> = (DSRC) Medium Access Control (MAC) and Physical Layer (PHY) =

> Speci=EF=AC=81cations=E2=80=9D; approved July 10, = 2003. The standard is derived from

> IEEE 802.11a = and, in most part, is equivalent to IEEE 802.11 OCB. To =

> date, the DSRC CFRs do not specify IEEE 802.11 = OCB.

>

> -The related CFRs = state that DSRC shall comply with the ASTM E = 2213-03.

>

> *Overview of DSRC = functions:***

>

> = **

>

> The functions listed in = DSRC related CFRs are, in general, specified

> in = the ASTM E 2213-03 and IEEE 802.11 OCB:

> =

> -MAC service definition, frame format, and = procedures;

>

> -PHY Orthogonal = frequency division multiplexing (OFDM);

> =

> -PHY Service Data Unit format and modulations = (data rates):

>

> -5.9 GHz band = allocated channels, frequency, max. EIRP, and spectrum =

> mask;

> =

> -Individual Channel use: Safety applications, = non-safety applications,

> and = priorities.

>

> = *Protocols***

>

> = **

>

> DSRC being uniquely a = MAC and PHY communications service, there here

> no = restriction on Transport and Network protocols that can be used =

> (except for the LCC specified by reference in = IEEE 802.11 OCB). In the

> US, the WAVE standards = (IEEE 1609 series) specify these protocols when

> = using DSRC as the communication service.

> =

> *OBU / RSU***

> =

> **

>

> = The CFR (FCC) definitions are:

> =

> /Roadside unit (RSU). A Roadside Unit is a DSRC = transceiver that is

> mounted along a road or = pedestrian passageway. An RSU may also be

> mounted = on a vehicle or is hand carried, but it may only operate when =

> the vehicle or hand- carried unit is stationary. = Furthermore, an RSU

> operating under this part is = restricted to the location where it is

> licensed = to operate. However, portable or hand-held RSUs are permitted =

> to operate where they do not interfere with a = site-licensed operation.

> A RSU broadcasts data to = OBUs or exchanges data with OBUs in its

> = communications zone. An RSU also provides channel assignments and =

> operating instructions to OBUs in its = communications zone, when

> required./- [CFR 90.7 - = Definitions] - Revised as October 2010.

> =

> /On-Board unit (OBU). 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. The OBUs receive = and contend for time

> to transmit on one or more = radio frequency (RF) channels. Except where

> = specifically excluded, OBU operation is permitted wherever vehicle =

> operation or human passage is permitted. The OBUs = mounted in vehicles

> are licensed by rule under = part 95 of this chapter and communicate

> with = Roadside Units (RSUs) and other OBUs. Portable OBUs are also =

> licensed by rule under part 95 of this chapter. = OBU operations in the

> Unlicensed National = Information Infrastructure (UNII) Bands follow the =

> rules in those bands./- [CFR 90.7 - Definitions] = - October 2010

>

> *IPWAVE = Issue***

>

> = **

>

> /=E2=80=9CThe problem = with the FCC definition of OBU is that it has no

> = relationship to IP.  Worse, that FCC definition has no indication = that

> it MAY use IP somehow.  And here we say = that all OBUs must use IP.  Do

> you see what = I mean?=E2=80=9D///

>

> = //

>

> Correct; the OBU has no = relationship with IP and is not intended to.

> IP = is a network protocol.  If an On-Board Unit (OBU) device is =

> required to exchange IP, it needs to be dealt in = protocol(s) and/or

> Management in higher layers = similar to WAVE within the On-Board Equipment (OBE) = .

>

> /=E2=80=9CDo you think = FCC will mind if we use the term OBU in this draft to =

> mean something else?  I, and a colleague, = think that FCC would not

> = mind.=E2=80=9D///

>

> = //

>

> Depending of the reader. = If one is familiar with DSRC, OBU and RSU as

> = defined by FCC will come in mind. As far as I know, = =E2=80=9COBU=E2=80=9D and =E2=80=9CRSU=E2=80=9D

> = are not registered and could be used for other definitions (something =

> like

> =E2=80=9CATM=E2=80=9D: = Asynchronous Transfer Mode and Automatic Teller Machine😊). My =

> suggestion to the IPWAVE team is to use = =E2=80=9COBE and RSE=E2=80=9D.

> =

> This is my personal view as I donot represent any = involved interest. 

> If any one has = questions, let me know.

If we want to go with OBE = instead of OBU then we must be ready to defend it in our respective = contexts.  Are we ready to?

(I already have a hard = time with telling people "802.11p" no longer exists, = especially to those who are afraid I want to use LTE to 'kill' =

802.11p; and now to tell them to use "OBE" = instead of "OBU" just in order to use IP seems like an = additional effort).

All the OBUs I use do run = IP.

Can FCC change their definition to include a = reference to this IP draft?

Alex

> =

> Francois Simon

> =

> Lojik Technologies

> =

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

> =

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

> = Petrescu

>

> Sent: Monday, = January 29, 2018 10:08 AM

>

> = To: its@ietf.org

> =

> Subject: Re: [ipwave] Shepherd review = of

> = draft-ietf-ipwave-ipv6-over-80211ocb-12

> =

>

>

> Le = 29/01/2018 =C3=A0 15:52, Fran=C3=A7ois Simon a =C3=A9crit = :

>

>> My comments arewithin = the text*[Fygs.......]*.

>

> = [...]

>

>> In the = terminology section, the OBU term is mentioned to be = defined

>

>> outside the = IETF. This is fine, but we have to provide a = reference.

>

>> And even = with that, it would not harm to include some short =

>> definition

> =

>> to provide context. The RSU term is also = defined outside the IETF and

> =

>> there is quite a lot of text provided (I = think the relevant part is

> =

>> the last sentence, the one starting with = "The difference between...").

> =

>> Both terms should be handled in the same = way.

>

>> =

>

>> *[Fygs: = The**definitions**was issued by the FCC 20 years ago.  I = have

>

>> already provided = that information**and references multiple

> =

>> times.]***

> =

> The problem with the FCC definition of OBU is = that it has no

> relationship to IP.  Worse, = that FCC definition has no indication that

> it MAY = use IP somehow.  And here we say that all OBUs must use IP.  = Do

> you see what I mean?

> =

> Do you think FCC will mind if we use the term OBU = in this draft to

> mean something else?  I, = and a colleague, think that FCC would not mind.

> =

> Alex

>

> = _______________________________________________

> =

> its mailing list

> =

> its@ietf.org

> =

> https://www.ietf.org/m= ailman/listinfo/its

> =

------=_NextPart_000_0039_01D39DB7.8A2BF930-- From nobody Sun Feb 4 11:56:17 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A758129C6E for ; Sun, 4 Feb 2018 11:56:15 -0800 (PST) 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] 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 5h0jg15aDpVB for ; Sun, 4 Feb 2018 11:56:13 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F8F5129C6D for ; Sun, 4 Feb 2018 11:56:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id DE5E63005D0 for ; Sun, 4 Feb 2018 14:56:08 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id LnBFZdrt9UKU for ; Sun, 4 Feb 2018 14:56:07 -0500 (EST) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id BA8C830044B for ; Sun, 4 Feb 2018 14:56:07 -0500 (EST) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_E94372D4-03DB-49C1-9341-A6F35C4FCB32" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sun, 4 Feb 2018 14:56:08 -0500 References: <1517217856.4315.32.camel@it.uc3m.es> <006601d39910$bdcf1cf0$396d56d0$@gmail.com> <000101d39c0f$e3b32f90$ab198eb0$@gmail.com> <707c9f11-c10e-f1e3-f68d-ab98fc632ca7@gmail.com> To: its@ietf.org In-Reply-To: <707c9f11-c10e-f1e3-f68d-ab98fc632ca7@gmail.com> Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 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, 04 Feb 2018 19:56:15 -0000 --Apple-Mail=_E94372D4-03DB-49C1-9341-A6F35C4FCB32 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > /=E2=80=9CThe problem with the FCC definition of OBU is that it has no = relationship to IP. Worse, that FCC definition has no indication that = it MAY use IP somehow. And here we say that all OBUs must use IP. Do = you see what I mean?=E2=80=9D/// > // > Correct; the OBU has no relationship with IP and is not intended to. = IP is a network protocol. If an On-Board Unit (OBU) device is required = to exchange IP, it needs to be dealt in protocol(s) and/or Management in = higher layers similar to WAVE within the On-Board Equipment (OBE) . > /=E2=80=9CDo you think FCC will mind if we use the term OBU in this = draft to mean something else? I, and a colleague, think that FCC would = not mind.=E2=80=9D/// > // > Depending of the reader. If one is familiar with DSRC, OBU and RSU as = defined by FCC will come in mind. As far as I know, =E2=80=9COBU=E2=80=9D = and =E2=80=9CRSU=E2=80=9D are not registered and could be used for other = definitions (something like =E2=80=9CATM=E2=80=9D: Asynchronous Transfer = Mode and Automatic Teller Machine=F0=9F=98=8A). My suggestion to the = IPWAVE team is to use =E2=80=9COBE and RSE=E2=80=9D. > This is my personal view as I donot represent any involved interest. = If any one has questions, let me know. I think it should be fairly easy to use the term OBU properly. Some = OBUs will make use of IP, and when they do, they MUST follow the = guidance in this document. Russ --Apple-Mail=_E94372D4-03DB-49C1-9341-A6F35C4FCB32 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

/=E2=80=9CThe problem with = the FCC definition of OBU is that it has no relationship to IP.  = Worse, that FCC definition has no indication that it MAY use IP = somehow.  And here we say that all OBUs must use IP.  Do you = see what I mean?=E2=80=9D///
//
Correct; the = OBU has no relationship with IP and is not intended to. IP is a network = protocol.  If an On-Board Unit (OBU) device is required to exchange = IP, it needs to be dealt in protocol(s) and/or Management in higher = layers similar to WAVE within the On-Board Equipment (OBE) .
/=E2=80=9CDo you think FCC will mind if we use the term OBU = in this draft to mean something else?  I, and a colleague, think = that FCC would not mind.=E2=80=9D///
//
Depending of the reader. If one is familiar with DSRC, OBU = and RSU as defined by FCC will come in mind. As far as I know, =E2=80=9COB= U=E2=80=9D and =E2=80=9CRSU=E2=80=9D are not registered and could be = used for other definitions (something like =E2=80=9CATM=E2=80=9D: = Asynchronous Transfer Mode and Automatic Teller Machine=F0=9F=98=8A). My = suggestion to the IPWAVE team is to use =E2=80=9COBE and RSE=E2=80=9D.
This is my personal view as I donot represent any involved = interest.  If any one has questions, let me = know.

I think it = should be fairly easy to use the term OBU properly.  Some OBUs will = make use of IP, and when they do, they MUST follow the guidance in this = document.

Russ

= --Apple-Mail=_E94372D4-03DB-49C1-9341-A6F35C4FCB32-- From nobody Sun Feb 4 18:59:20 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E78AB126C89 for ; Sun, 4 Feb 2018 18:59:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 p6PbGb01m1Lx for ; Sun, 4 Feb 2018 18:59:16 -0800 (PST) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::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 B2FFF1200C1 for ; Sun, 4 Feb 2018 18:59:15 -0800 (PST) Received: by mail-qt0-x234.google.com with SMTP id m11so10381537qtn.10 for ; Sun, 04 Feb 2018 18:59:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-language:thread-index; bh=mB5TtTGHrkXSNy0QYdVHK+foxU4KauMor7TWkTpYL5U=; b=P7gmyG929B99jx9Wd7ji2At7P6jGVr/8aTDT/7RHN4eHWO1WPuopAS8o/yoPv93cPz skMey62m5PpoNH7igGz+SQbXf0iBu05roe/FYT8jUM3W0pByNlddSwitQYpKowsPRBpX c109OhZF87/uEeXz6uQQ1t5cw1gH+jzUk2bRQgs6+hW1iqVPYhnqY3ydk/JS85CqNSPG oS9S5lyiWcbPYC7GEOsS8Pssp3VdBKIHbxLDmgyHzppeiSdh7gbnrhu9PjQSei9SllHW sH3pTIT2jLDVZDkPnzww2h6IdwdFXpo8X876DtY5W0/vtHJNhKSyN369VX66NgqK0CYQ cppQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-language:thread-index; bh=mB5TtTGHrkXSNy0QYdVHK+foxU4KauMor7TWkTpYL5U=; b=OnEUHzFjUoBWrvbQ9Dk1FMADAenBxv5lLt2btYs7GOJxIiyan7XR/nKqbHXTIOm/yj FFt66x3W1cqqSbsga8TtKVgHPDDbVLttlEjw69hwpC2miXjSKMptU1iYVZD54H99hQHL KnUOoIHfNhhkfe5rqoHAHyb5B+jCjSCimemUZhvjb9ZhCfwWGgMyhPlBx09pwtNcDPZE NqIlZQ9fo9N4XU0tk6CDa2bb9D6aOHWglRoUaBfHTQuiwW6AiLM2mOTzRJPnjz95KZoW eVnNSdhFJ4kBF3YHwLV5WnfVXi4wzTNzNfc+Uc1kTmVyLMJOgyzhFXE146G5FtG9S//e W/8w== X-Gm-Message-State: APf1xPBTDJ1AdEkEc+2vwUc0JyPGQd0jjXedbdBWahPE+/Hj+S9dp0sg 9r272Lvo7VG+Tq2Ybti+JZI= X-Google-Smtp-Source: AH8x224UhdurBmnK4vxu9j1frgj13+jZgoekkq0QO/hmW4YzcYX0mukktjgBKfNEOK1XBFQ3hyPUTg== X-Received: by 10.200.16.141 with SMTP id a13mr15978938qtj.65.1517799554798; Sun, 04 Feb 2018 18:59:14 -0800 (PST) Received: from FrancoisPC (pool-108-48-182-86.washdc.fios.verizon.net. [108.48.182.86]) by smtp.gmail.com with ESMTPSA id r9sm2993086qtb.2.2018.02.04.18.59.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Feb 2018 18:59:14 -0800 (PST) From: =?utf-8?Q?Fran=C3=A7ois_Simon?= To: "'Alexandre Petrescu'" , References: <1517217856.4315.32.camel@it.uc3m.es> In-Reply-To: Date: Sun, 4 Feb 2018 21:59:13 -0500 Message-ID: <003c01d39e2d$4dfadf00$e9f09d00$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003D_01D39E03.652E73F0" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQL7ISfFSBtQJ/i74DjDJlbgILh28gI8mfjJoTQnSaA= Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 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, 05 Feb 2018 02:59:19 -0000 This is a multipart message in MIME format. ------=_NextPart_000_003D_01D39E03.652E73F0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The MTU text currently says: > The default MTU for IP packets on 802.11-OCB is 1500 octets. I modify it to say: > The default MTU for IP packets on 802.11-OCB MUST be 1500 octets. - The MTU text currently says: > The default MTU for IP packets on = 802.11-OCB is 1500 octets. [Fygs: IEEE 802.11 OCB - MSDU size 2304] - I modify it to say: > The default MTU for IP packets on 802.11-OCB = MUST be 1500 octets. [Fygs: =E2=80=9Cis=E2=80=9D was correct] -----Original Message----- From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu Sent: Sunday, February 04, 2018 12:08 PM To: its@ietf.org Subject: Re: [ipwave] Shepherd review of = draft-ietf-ipwave-ipv6-over-80211ocb-12 Le 29/01/2018 =C3=A0 10:24, Carlos Jes=C3=BAs Bernardos Cano a = =C3=A9crit : [...] > - The abstract mentions that in order to transmit IPv6 packets on IEEE = > 802.11-OCB, "there is a need to define a few parameters such as the=20 > supported Maximum Transmission Unit size on the 802.11-OCB link, the=20 > header format preceding the IPv6 header, the Type value within it, and = > others". But the MTU part of the draft does not use any normative = text, > the header format is exactly the same than for IEEE 802.11, as the=20 > type value. The MTU text currently says: > The default MTU for IP packets on 802.11-OCB is 1500 octets. I modify it to say: > The default MTU for IP packets on 802.11-OCB MUST be 1500 octets. > - Section 1 lists two exceptions for 802.11-OCB compared to Ethernet. > The first one is not different from regular 802.11, I dont understand you. The first one says that there are differences between IP-over-WiFi and = IP-over-Ethernet. These differences are in the headers. To adapt to = these differences an Ethernet Adaptation Layer is proposed. Does this explain better? Do I understand the worry correctly? > but for the second > one, the document only provides recommendations. Should it provide something else? > - I always thought that "WiFi" does not stand for "Wireless Fidelity". > See https://boingboing.net/2005/11/08/wifi-isnt-short-for.html Other persons commented, so at this time I propose to leave the def = unchanged. [...] >=20 > - In section 3, it is mentioned that "the operating environment=20 > (vehicular networks) brings in new perspectives" --> which are those=20 > (that are covered/tackled by the document? The document does not cover these new 'perspectives'. The = 'perspectives' are the ND operation, the handovers for Mobile IP, the = security - the 3 perspectives are difference in OCB than in WiFi. We = dont describe any here. Maybe new work is needed for ND-over-OCB, or Mobile IP with OCB access, = or Security for OCB. > - In section 4.1, does the text mean that the MTU SHOULD/MUST be 1500=20 > octects. If that is what is meant, this is really a normative thing=20 > that should be written using normative text. If it is just a=20 > recommendation, then this should be clearly written as such. MUST be. > - All the text of section 4.2.1 is not normative, but more a report of = > what is done today in existing implementations. YEs, it is done today in existing WiFi implementations (not Ethernet). > Is there any different > there that is specific of 802.11-OCB? No, there is nothing different. I can change the text, but not sure what would be ok. Should I move section 4.2.1 in an Appendix? > - All subsections 4.x seem informative, not normative. Similar to MTU, I could write in the 4.2 "Frame Format" that the = EtherType MUST be 0x86DD (instead of just "is"). Would this make it = more Normative? In section 4.3 "LL Addresses" I could put "it is RECOMMENDED" instead of = "it is recommended". Sections 4.4. "Address Mapping" and 4.4.1 "Address Mapping -- Unicast" I = could remove. Section 4.4.2 "Address Mapping - Multicast" could be removed. Section 4.5 "Stateless Autoconf" - I could write "the u/g bits MUST be = opaque" instead of "are significant". Section 4.6 "Subnet Structure" - could be removed altogether. Are these ok with you? > - The privacy part of section 5 is important, as it impacts the=20 > operation of IPv6 over this type of networks, so I think this deserves = > more attention. Should I make a subsection called "Privacy Considerations" within the = SEcurity considerations? > - In section, H.1, more details about how the captures were obtained=20 > should be provided (HW, SW, etc.). We added this if sounds ok: > The packet is captured on the Host. The Host is an IP-OBU > containing an 802.11 interface in format PCI express (an ITRI > product). The kernel runs the ath5k software driver with > modifications for OCB mode. The capture tool is Wireshark. > The file format for save and analyze is 'pcap'. The packet is > generated by the Router. The Router is an IP-RSU (ITRI > product). > Authors, please respond to my questions/comments and address them in a = > new version of the document. We submitted a new version, but please reply to my comments so I fully = address the comments. https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-13 Alex _______________________________________________ its mailing list its@ietf.org =20 https://www.ietf.org/mailman/listinfo/its ------=_NextPart_000_003D_01D39E03.652E73F0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable RE: [ipwave] Shepherd review of = draft-ietf-ipwave-ipv6-over-80211ocb-12

The MTU text = currently says:

> The = default MTU for IP packets on 802.11-OCB is 1500 = octets.

I modify it = to say:

 > = The default MTU for IP packets on 802.11-OCB MUST be 1500 = octets.

-       The MTU text currently = says: > The default MTU for IP packets on 802.11-OCB is = 1500 octets. [Fygs: IEEE 802.11 OCB - MSDU size 2304]

-       I modify it to = say:  > The default MTU for IP packets on 802.11-OCB MUST = be 1500 octets. [Fygs: =E2=80=9Cis=E2=80=9D was = correct]

-----Original = Message-----
From: its [mailto:its-bounces@ietf.org] On = Behalf Of Alexandre Petrescu
Sent: Sunday, February 04, 2018 12:08 PM
To: its@ietf.org
Subject: Re: [ipwave] Shepherd review of = draft-ietf-ipwave-ipv6-over-80211ocb-12

Le 29/01/2018 = =C3=A0 10:24, Carlos Jes=C3=BAs Bernardos Cano a = =C3=A9crit=C2=A0:

[...]

> - The = abstract mentions that in order to transmit IPv6 packets on IEEE =

> = 802.11-OCB, "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". But the MTU part of the draft does not use any normative = text,

>   the header format is exactly the same = than for IEEE 802.11, as the

> type = value.

The MTU text = currently says:

> The = default MTU for IP packets on 802.11-OCB is 1500 = octets.

I modify it to = say:

 > The = default MTU for IP packets on 802.11-OCB MUST be 1500 = octets.

> - Section = 1 lists two exceptions for 802.11-OCB compared to = Ethernet.

> The first = one is not different from regular 802.11,

I dont = understand you.

The first one = says that there are differences between IP-over-WiFi and = IP-over-Ethernet.  These differences are in the headers.  To = adapt to these differences an Ethernet Adaptation Layer is = proposed.

Does this = explain better?

Do I understand = the worry correctly?

> but for = the second

> one, the = document only provides recommendations.

Should it = provide something else?

> - I always = thought that "WiFi" does not stand for "Wireless = Fidelity".

> = See https://boingboing.net/2005/11/08/wifi-isnt-short-for.ht= ml

Other persons = commented, so at this time I propose to leave the def = unchanged.

[...]

> =

> - In = section 3, it is mentioned that "the operating environment =

> (vehicular = networks) brings in new perspectives" --> which are those =

> (that are = covered/tackled by the document?

The document = does not cover these new 'perspectives'.  The 'perspectives' are = the ND operation, the handovers for Mobile IP, the security - the 3 = perspectives are difference in OCB than in WiFi.  We dont describe = any here.

Maybe new work = is needed for ND-over-OCB, or Mobile IP with OCB access, or Security for = OCB.

> - In = section 4.1, does the text mean that the MTU SHOULD/MUST be 1500 =

> octects. = If that is what is meant, this is really a normative thing =

> that = should be written using normative text. If it is just a =

> = recommendation, then this should be clearly written as = such.

MUST = be.

> - All the = text of section 4.2.1 is not normative, but more a report of =

> what is = done today in existing implementations.

YEs, it is done = today in existing WiFi implementations (not Ethernet).

> Is there = any different

> there that = is specific of 802.11-OCB?

No, there is = nothing different.

I can change = the text, but not sure what would be ok.

Should I move = section 4.2.1 in an Appendix?

> - All = subsections 4.x seem informative, not normative.

Similar to MTU, = I could write in the 4.2 "Frame Format" that the EtherType = MUST be 0x86DD (instead of just "is").  Would this make = it more Normative?

In section 4.3 = "LL Addresses" I could put "it is RECOMMENDED" = instead of "it is recommended".

Sections 4.4. = "Address Mapping" and 4.4.1 "Address Mapping -- = Unicast" I could remove.

Section 4.4.2 = "Address Mapping - Multicast" could be = removed.

Section 4.5 = "Stateless Autoconf" - I could write "the u/g bits MUST = be opaque" instead of "are = significant".

Section 4.6 = "Subnet Structure" - could be removed = altogether.

Are these ok = with you?

> - The = privacy part of section 5 is important, as it impacts the =

> operation = of IPv6 over this type of networks, so I think this deserves =

> more = attention.

Should I make a = subsection called "Privacy Considerations" within the SEcurity = considerations?

> - In = section, H.1, more details about how the captures were obtained =

> should be = provided (HW, SW, etc.).

We added this = if sounds ok:

> =       The packet is captured on the Host.  = The Host is an IP-OBU

> =       containing an 802.11 interface in format = PCI express (an ITRI

> =       product).  The kernel runs the ath5k = software driver with

> =       modifications for OCB mode.  The = capture tool is Wireshark.

> =       The file format for save and analyze is = 'pcap'.  The packet is

> =       generated by the Router.  The Router = is an IP-RSU (ITRI

> =       product).

> Authors, = please respond to my questions/comments and address them in a =

> new = version of the document.

We submitted a = new version, but please reply to my comments so I fully address the = comments.

https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-= 80211ocb-13

Alex

_______________________________________________

its mailing = list

its@ietf.org

https://www.ietf.org/mailman/listinfo/its<= SPAN LANG=3D"en-us">

------=_NextPart_000_003D_01D39E03.652E73F0-- From nobody Sun Feb 4 19:30:55 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36E031205F0 for ; Sun, 4 Feb 2018 19:30:54 -0800 (PST) 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 XP57ks5pmcPd for ; Sun, 4 Feb 2018 19:30:50 -0800 (PST) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00634126B6E for ; Sun, 4 Feb 2018 19:30:49 -0800 (PST) Received: by mail-qk0-x229.google.com with SMTP id w128so8578180qkb.5 for ; Sun, 04 Feb 2018 19:30:49 -0800 (PST) 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=mUXRajuqfdvUrJ81wrYtnYv+c2zruqrQrxCDFDYkY0g=; b=gGa75QFX1ryZnxGdHre7rZDQZztvOiiTkTm7YzE6aYfjaJZ8G6iPoQ/Kx/WZxpH9Eu Bbld41ryUik7Pq0PHj8xcjkjxom1ts3pgLp/6Ya6Kd6QLRz4FWELr3d8ovuGt7hLHtlo QccwpXKPd8cDYW2YnzybshbH2udLWMowizM0hU/46a0WWSoacvlmiPTjNUMivsQ4qBT6 3kr23SYk760EdzZbZzBdk4LQEvGKENZGhQ+9n3z1/Rtymwl6T8yDo+f2ZYyC6rz38fKC TPnCqc8vXeJAQeZMEdEkIoP8qnA+sW7n7gdCk5l7mmyO1N7ccJK3mvY7j9ko0JCKMhvw HV0Q== 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=mUXRajuqfdvUrJ81wrYtnYv+c2zruqrQrxCDFDYkY0g=; b=PKCu+tuSqEaYhd2MfmspwqrqpOGT1Jaiz7hFriQUuwbHvh+GTjHydOO8buDmw4c6kF TMqnTzIn6fz0X2yOv3qgAWqwCOpc5tVsVRoUrAd5fJsIcWzgJoDyacWFW+4pcqG/Bqtp qRNvOdgYBOor9RVYRQ4Btif8qp3pt/U+tfaOl4LzHmH9GzjM7rc5ousaSuMVIgldZV/4 19ZqVpmAJi9qx1vXi1U9NfP2TkScwQMkczA6UAAnOiFMkcqLSdGFLwMnSLkdxcrJMWLN YJhxcU7F0xM3lSaasopIbsXkrlfsOpouJlIHWXSZPI7Hxz9dOnfSbc6KrmgkTPZSA6Fm 4tFQ== X-Gm-Message-State: APf1xPCmXp1tuLy+QHpiZgdXT1iR31ahuKKS2q92e1TmJedJ1mtN45Lx wedC+Zz+yDXJMOXSoyRCbBI= X-Google-Smtp-Source: AH8x226oxCwazqrckQI/B/sbBbFeXr3x7imdG0MP8vcyAZpiHE2dhEB4wK3dQ0LCwC3jraRO0SttPw== X-Received: by 10.55.71.87 with SMTP id u84mr163078qka.255.1517801448981; Sun, 04 Feb 2018 19:30:48 -0800 (PST) Received: from FrancoisPC (pool-108-48-182-86.washdc.fios.verizon.net. [108.48.182.86]) by smtp.gmail.com with ESMTPSA id z22sm5198504qti.75.2018.02.04.19.30.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Feb 2018 19:30:47 -0800 (PST) From: =?utf-8?Q?Fran=C3=A7ois_Simon?= To: "'Alexandre Petrescu'" Cc: , References: <1517217856.4315.32.camel@it.uc3m.es> <006601d39910$bdcf1cf0$396d56d0$@gmail.com> <000101d39c0f$e3b32f90$ab198eb0$@gmail.com> <827a8e03-75fc-7b64-9b2a-2c2bdc0288ed@gmail.com> In-Reply-To: <827a8e03-75fc-7b64-9b2a-2c2bdc0288ed@gmail.com> Date: Sun, 4 Feb 2018 22:30:47 -0500 Message-ID: <004901d39e31$b6d89630$2489c290$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004A_01D39E07.CE04FF30" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQL7ISfFSBtQJ/i74DjDJlbgILh28gG4su6HASuQMD8BaTCMjwID0JIooROREFA= Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 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, 05 Feb 2018 03:30:54 -0000 This is a multipart message in MIME format. ------=_NextPart_000_004A_01D39E07.CE04FF30 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Mr. Petrescu, " I thought "DSRC" is also about Applications and Use-cases." - No; It is a Dedicated Short Range Communication service. I believe = that SAE DSRC Technical Committee (US) is defining applications and = use-cases. =E2=80=9CIt is one thing to have no restrictions, and another thing to = reckon that IP is the networking layer.=E2=80=9D - Layer 3 (Network Layer) * CLNP Connectionless Networking = Protocol * EGP = Exterior Gateway Protocol * EIGRP Enhanced Interior Gateway = Routing Protocol * ICMP = Internet Control Message Protocol * IGMP Internet Group Management = Protocol * IGRP Interior Gateway Routing = Protocol * IPv4 Internet Protocol version 4 * IPv6 Internet Protocol version 6 * IPSec Internet Protocol = Security * IPX Internetwork Packet change * NAT = Network Address Translation * Routed-SMLT =20 * SCCP = = Signalling Connection Control Part * AppleTalk DDP * GRE = Generic Routing Encapsulation for tunneling * OSPF Open Shortest Path First * RIP = Routing Information Protocol * HSRP Hot = Standby Router protocol * VRRP = = Virtual Router Redundancy Protocol =E2=80=9CAn RSU product has many transceivers inside.=E2=80=9D - An RSE may have multiple transceivers. =09 =09 -----Original Message----- From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com]=20 Sent: Sunday, February 04, 2018 10:49 AM To: Fran=C3=A7ois Simon Cc: its@ietf.org Subject: Re: [ipwave] Shepherd review of = draft-ietf-ipwave-ipv6-over-80211ocb-12 Le 02/02/2018 =C3=A0 11:23, Fran=C3=A7ois Simon a =C3=A9crit : > Mr. Petrescu, >=20 > Let's try one more time to clarify the FCC DSRC (in US only) issue. >=20 > *FCC =E2=80=93 DSRC* >=20 > *Background:*** >=20 > ** >=20 > -** The US Federal Communications Commission (FCC) Dedicated Short=20 > Range Communication (DSRC) is defined in the Code of Federal=20 > Regulations (CFR) > 47 mainly Parts 90 and 95. The last update is dated October 1st, 2010; >=20 > -This includes the ASTM E 2213-03 standard: =E2=80=9CStandard = Speci=EF=AC=81cation for=20 > Telecommunications and Information Exchange Between Roadside and=20 > Vehicle Systems =E2=80=94 5 GHz Band Dedicated Short Range = Communications=20 > (DSRC) Medium Access Control (MAC) and Physical Layer (PHY)=20 > Speci=EF=AC=81cations=E2=80=9D; approved July 10, 2003. The standard = is derived from=20 > IEEE 802.11a and, in most part, is equivalent to IEEE 802.11 OCB. To=20 > date, the DSRC CFRs do not specify IEEE 802.11 OCB. >=20 > -The related CFRs state that DSRC shall comply with the ASTM E = 2213-03. Thank you for the explanation. It is useful to understand that DSRC is = related to ASTM E 2213-03 and that neither refers to 802.11 OCB. I think in works related to standards and products it is advantageous if = there is correlation. For example, in an ideal world, standards talk about "A" and the = regulation also about "A" and the products and sofware are also labelled = "A". In our context, software is labelled "OCB" (kernel drivers), regulation = talks "DSRC" and standards "802.11p" and "802.11 OCB". > *Overview of DSRC functions:*** >=20 > ** >=20 > The functions listed in DSRC related CFRs are, in general, specified=20 > in the ASTM E 2213-03 and IEEE 802.11 OCB: >=20 > -MAC service definition, frame format, and procedures; >=20 > -PHY Orthogonal frequency division multiplexing (OFDM); >=20 > -PHY Service Data Unit format and modulations (data rates): >=20 > -5.9 GHz band allocated channels, frequency, max. EIRP, and spectrum=20 > mask; >=20 > -Individual Channel use: Safety applications, non-safety applications, = > and priorities. >=20 > *Protocols*** >=20 > ** >=20 > DSRC being uniquely a MAC and PHY communications service, I thought "DSRC" is also about Applications and Use-cases. > there here no > restriction on Transport and Network protocols that can be used=20 > (except for the LCC specified by reference in IEEE 802.11 OCB). In the = > US, the WAVE standards (IEEE 1609 series) specify these protocols when = > using DSRC as the communication service. It is one thing to have no restrictions, and another thing to reckon = that IP is the networking layer. >=20 > *OBU / RSU*** >=20 > ** >=20 > The CFR (FCC) definitions are: >=20 > /Roadside unit (RSU). A Roadside Unit is a DSRC transceiver Sigh, it is way different. An RSU product has many transceivers inside. > that is > mounted along a road or pedestrian passageway. An RSU may also be=20 > mounted on a vehicle or is hand carried, but it may only operate when=20 > the vehicle or hand- carried unit is stationary. Furthermore, an RSU=20 > operating under this part is restricted to the location where it is=20 > licensed to operate. However, portable or hand-held RSUs are permitted = > to operate where they do not interfere with a site-licensed operation. = > A RSU broadcasts data to OBUs or exchanges data with OBUs in its=20 > communications zone. An RSU also provides channel assignments and=20 > operating instructions to OBUs in its communications zone, when > required./- [CFR 90.7 - Definitions] - Revised as October 2010. I think it should be updated to refer to this document. > /On-Board unit (OBU). An On-Board Unit is a DSRCS transceiver that is=20 > 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=20 > is either mobile or stationary. The OBUs receive and contend for time=20 > to transmit on one or more radio frequency (RF) channels. Except where = > specifically excluded, OBU operation is permitted wherever vehicle=20 > operation or human passage is permitted. The OBUs mounted in vehicles=20 > are licensed by rule under part 95 of this chapter and communicate=20 > with Roadside Units (RSUs) and other OBUs. Portable OBUs are also=20 > licensed by rule under part 95 of this chapter. OBU operations in the=20 > Unlicensed National Information Infrastructure (UNII) Bands follow the = > rules in those bands./- [CFR 90.7 - Definitions] - October 2010 Thanks for the definitions. They are far different from what we need in this draft. I will see the other suggestions. Alex >=20 > *IPWAVE Issue*** >=20 > ** >=20 > /=E2=80=9CThe problem with the FCC definition of OBU is that it has no = > relationship to IP. Worse, that FCC definition has no indication that = > it MAY use IP somehow. And here we say that all OBUs must use IP. Do = > you see what I mean?=E2=80=9D/// >=20 > // >=20 > Correct; the OBU has no relationship with IP and is not intended to.=20 > IP is a network protocol. If an On-Board Unit (OBU) device is=20 > required to exchange IP, it needs to be dealt in protocol(s) and/or=20 > Management in higher layers similar to WAVE within the On-Board = Equipment (OBE) . >=20 > /=E2=80=9CDo you think FCC will mind if we use the term OBU in this = draft to=20 > mean something else? I, and a colleague, think that FCC would not=20 > mind.=E2=80=9D/// >=20 > // >=20 > Depending of the reader. If one is familiar with DSRC, OBU and RSU as=20 > defined by FCC will come in mind. As far as I know, = =E2=80=9COBU=E2=80=9D and =E2=80=9CRSU=E2=80=9D=20 > are not registered and could be used for other definitions (something=20 > like > =E2=80=9CATM=E2=80=9D: Asynchronous Transfer Mode and Automatic Teller = Machine=F0=9F=98=8A). My=20 > suggestion to the IPWAVE team is to use =E2=80=9COBE and RSE=E2=80=9D. >=20 > This is my personal view as I donot represent any involved interest. =20 > If any one has questions, let me know. >=20 > Francois Simon >=20 > Lojik Technologies >=20 > -----Original Message----- >=20 > From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre=20 > Petrescu >=20 > Sent: Monday, January 29, 2018 10:08 AM >=20 > To: its@ietf.org =20 >=20 > Subject: Re: [ipwave] Shepherd review of > draft-ietf-ipwave-ipv6-over-80211ocb-12 >=20 >=20 >=20 > Le 29/01/2018 =C3=A0 15:52, Fran=C3=A7ois Simon a =C3=A9crit : >=20 >> My comments arewithin the text*[Fygs.......]*. >=20 > [...] >=20 >> In the terminology section, the OBU term is mentioned to be defined >=20 >> outside the IETF. This is fine, but we have to provide a reference. >=20 >> And even with that, it would not harm to include some short=20 >> definition >=20 >> to provide context. The RSU term is also defined outside the IETF and >=20 >> there is quite a lot of text provided (I think the relevant part is >=20 >> the last sentence, the one starting with "The difference = between...").=20 >=20 >> Both terms should be handled in the same way. >=20 >>=20 >=20 >> *[Fygs: The**definitions**was issued by the FCC 20 years ago. I have >=20 >> already provided that information**and references multiple >=20 >> times.]*** >=20 > The problem with the FCC definition of OBU is that it has no=20 > relationship to IP. Worse, that FCC definition has no indication that = > it MAY use IP somehow. And here we say that all OBUs must use IP. Do = > you see what I mean? >=20 > Do you think FCC will mind if we use the term OBU in this draft to=20 > mean something else? I, and a colleague, think that FCC would not = mind. >=20 > Alex >=20 > _______________________________________________ >=20 > its mailing list >=20 > its@ietf.org =20 >=20 > https://www.ietf.org/mailman/listinfo/its >=20 ------=_NextPart_000_004A_01D39E07.CE04FF30 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable RE: [ipwave] Shepherd review of = draft-ietf-ipwave-ipv6-over-80211ocb-12

Mr. = Petrescu,

" I thought "DSRC" is also about Applications = and Use-cases."

-       No; It is a Dedicated Short Range = Communication service.  I believe that SAE DSRC Technical Committee (US) is defining = applications = and use-cases.

=E2=80=9CIt is one thing to have no restrictions, and another = thing to reckon that IP is the networking layer.=E2=80=9D

-       Layer 3 (Network Layer)

·       CLNP Connectionless Networking = Protocol

·       EGP Exterior Gateway = Protocol

·       EIGRP Enhanced Interior Gateway Routing = Protocol

·       = ICMP Internet Control Message = Protocol

·       IGMP Internet Group Management = Protocol

·       IGRP Interior Gateway Routing = Protocol

·       IPv4 Internet Protocol version = 4

·       IPv6 Internet Protocol version = 6

·       IPSec Internet Protocol = Security

·       IPX Internetwork Packet = change

·       NAT Network Address = Translation

·       Routed-SMLT

·       SCCP Signalling Connection Control = Part

·       AppleTalk DDP

·       GRE Generic Routing Encapsulation for = tunneling

·       OSPF Open Shortest Path = First

·       RIP Routing Information = Protocol

·       HSRP Hot Standby Router = protocol

·       VRRP Virtual Router Redundancy = Protocol

=E2=80=9CAn RSU product has many transceivers = inside.=E2=80=9D

-       An RSE may have = multiple = transceivers.

-----Original = Message-----
From: Alexandre Petrescu [mailto:alexandre.petrescu@gm= ail.com]
Sent: Sunday, February 04, 2018 10:49 AM
To: Fran=C3=A7ois Simon <fygsimon@gmail.com>
Cc: its@ietf.org
Subject: Re: [ipwave] Shepherd review of = draft-ietf-ipwave-ipv6-over-80211ocb-12

Le 02/02/2018 = =C3=A0 11:23, Fran=C3=A7ois Simon a =C3=A9crit=C2=A0:

> Mr. = Petrescu,

> =

> Let's try = one more time to clarify the FCC DSRC (in US only) = issue.

> =

> *FCC = =E2=80=93 DSRC*

> =

> = *Background:***

> =

> = **

> =

> -** The US = Federal Communications Commission (FCC) Dedicated Short =

> Range = Communication (DSRC) is defined in the Code of Federal =

> = Regulations (CFR)

> 47 mainly = Parts 90 and 95. The last update is dated October 1st, = 2010;

> =

> -This = includes the ASTM E 2213-03 standard: =E2=80=9CStandard = Speci=EF=AC=81cation for

> = Telecommunications and Information Exchange Between Roadside and =

> Vehicle = Systems =E2=80=94 5 GHz Band Dedicated Short Range Communications =

> (DSRC) = Medium Access Control (MAC) and Physical Layer (PHY)

> = Speci=EF=AC=81cations=E2=80=9D; approved July 10, 2003. The standard is = derived from

> IEEE = 802.11a and, in most part, is equivalent to IEEE 802.11 OCB. To =

> date, the = DSRC CFRs do not specify IEEE 802.11 OCB.

> =

> -The = related CFRs state that DSRC shall comply with the ASTM E = 2213-03.

Thank you for = the explanation.  It is useful to understand that DSRC is related = to ASTM E 2213-03 and that neither refers to 802.11 = OCB.

I think in = works related to standards and products it is advantageous if there is = correlation.

For example, in = an ideal world, standards talk about "A" and the regulation = also about "A" and the products and sofware are also labelled = "A".

In our context, = software is labelled "OCB" (kernel drivers), regulation talks = "DSRC" and standards "802.11p" and "802.11 = OCB".

> *Overview = of DSRC functions:***

> =

> = **

> =

> The = functions listed in DSRC related CFRs are, in general, specified =

> in the = ASTM E 2213-03 and IEEE 802.11 OCB:

> =

> -MAC = service definition, frame format, and procedures;

> =

> -PHY = Orthogonal frequency division multiplexing (OFDM);

> =

> -PHY = Service Data Unit format and modulations (data rates):

> =

> -5.9 GHz = band allocated channels, frequency, max. EIRP, and spectrum =

> = mask;

> =

> = -Individual Channel use: Safety applications, non-safety applications, =

> and = priorities.

> =

> = *Protocols***

> =

> = **

> =

> DSRC being = uniquely a MAC and PHY communications service,

I thought = "DSRC" is also about Applications and = Use-cases.

> there here = no

> = restriction on Transport and Network protocols that can be used =

> (except = for the LCC specified by reference in IEEE 802.11 OCB). In the =

> US, the = WAVE standards (IEEE 1609 series) specify these protocols when =

> using DSRC = as the communication service.

It is one thing = to have no restrictions, and another thing to reckon that IP is the = networking layer.

> =

> *OBU / = RSU***

> =

> = **

> =

> The CFR = (FCC) definitions are:

> =

> /Roadside = unit (RSU). A Roadside Unit is a DSRC transceiver

Sigh, it is way = different.

An RSU product = has many transceivers inside.

> that = is

> mounted = along a road or pedestrian passageway. An RSU may also be =

> mounted on = a vehicle or is hand carried, but it may only operate when =

> the = vehicle or hand- carried unit is stationary. Furthermore, an RSU =

> operating = under this part is restricted to the location where it is =

> licensed = to operate. However, portable or hand-held RSUs are permitted =

> to operate = where they do not interfere with a site-licensed operation. =

> A RSU = broadcasts data to OBUs or exchanges data with OBUs in its =

> = communications zone. An RSU also provides channel assignments and =

> operating = instructions to OBUs in its communications zone, when

> = required./- [CFR 90.7 - Definitions] - Revised as October = 2010.

I think it = should be updated to refer to this document.

> /On-Board = unit (OBU). 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. The OBUs receive and contend for time =

> to = transmit on one or more radio frequency (RF) channels. Except where =

> = specifically excluded, OBU operation is permitted wherever vehicle =

> operation = or human passage is permitted. The OBUs mounted in vehicles =

> are = licensed by rule under part 95 of this chapter and communicate =

> with = Roadside Units (RSUs) and other OBUs. Portable OBUs are also =

> licensed = by rule under part 95 of this chapter. OBU operations in the =

> Unlicensed = National Information Infrastructure (UNII) Bands follow the =

> rules in = those bands./- [CFR 90.7 - Definitions] - October 2010

Thanks for the = definitions.

They are far = different from what we need in this draft.

I will see the = other suggestions.

Alex

> =

> *IPWAVE = Issue***

> =

> = **

> =

> = /=E2=80=9CThe problem with the FCC definition of OBU is that it has no =

> = relationship to IP.=C2=A0 Worse, that FCC definition has no indication = that

> it MAY use = IP somehow.=C2=A0 And here we say that all OBUs must use IP.=C2=A0 Do =

> you see = what I mean?=E2=80=9D///

> =

> = //

> =

> Correct; = the OBU has no relationship with IP and is not intended to. =

> IP is a = network protocol.=C2=A0 If an On-Board Unit (OBU) device is =

> required = to exchange IP, it needs to be dealt in protocol(s) and/or =

> Management = in higher layers similar to WAVE within the On-Board Equipment (OBE) = .

> =

> = /=E2=80=9CDo you think FCC will mind if we use the term OBU in this = draft to

> mean = something else?=C2=A0 I, and a colleague, think that FCC would not =

> = mind.=E2=80=9D///

> =

> = //

> =

> Depending = of the reader. If one is familiar with DSRC, OBU and RSU as =

> defined by = FCC will come in mind. As far as I know, =E2=80=9COBU=E2=80=9D and = =E2=80=9CRSU=E2=80=9D

> are not = registered and could be used for other definitions (something =

> = like

> = =E2=80=9CATM=E2=80=9D: Asynchronous Transfer Mode and Automatic Teller = Machine=F0=9F=98=8A). My

> suggestion = to the IPWAVE team is to use =E2=80=9COBE and = RSE=E2=80=9D.

> =

> This is my = personal view as I donot represent any involved interest.=C2=A0 =

> If any one = has questions, let me know.

> =

> Francois = Simon

> =

> Lojik = Technologies

> =

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

> =

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

> = Petrescu

> =

> Sent: = Monday, January 29, 2018 10:08 AM

> =

> = To: its@ietf.org

> =

> Subject: = Re: [ipwave] Shepherd review of

> = draft-ietf-ipwave-ipv6-over-80211ocb-12

> =

> =

> =

> Le = 29/01/2018 =C3=A0 15:52, Fran=C3=A7ois Simon a =C3=A9crit = :

> =

>> My = comments arewithin the text*[Fygs.......]*.

> =

> = [...]

> =

>> In the = terminology section, the OBU term is mentioned to be = defined

> =

>> = outside the IETF. This is fine, but we have to provide a = reference.

> =

>> And = even with that, it would not harm to include some short =

>> = definition

> =

>> to = provide context. The RSU term is also defined outside the IETF = and

> =

>> there = is quite a lot of text provided (I think the relevant part = is

> =

>> the = last sentence, the one starting with "The difference = between...").

> =

>> Both = terms should be handled in the same way.

> =

>> =

> =

>> = *[Fygs: The**definitions**was issued by the FCC 20 years ago.=C2=A0 I = have

> =

>> = already provided that information**and references = multiple

> =

>> = times.]***

> =

> The = problem with the FCC definition of OBU is that it has no =

> = relationship to IP.=C2=A0 Worse, that FCC definition has no indication = that

> it MAY use = IP somehow.=C2=A0 And here we say that all OBUs must use IP.=C2=A0 Do =

> you see = what I mean?

> =

> Do you = think FCC will mind if we use the term OBU in this draft to =

> mean = something else?=C2=A0 I, and a colleague, think that FCC would not = mind.

> =

> = Alex

> =

> = _______________________________________________

> =

> its = mailing list

> =

> its@ietf.org

> =

> https://www.ietf.org/mailman/listinfo/its<= SPAN LANG=3D"en-us">

>

------=_NextPart_000_004A_01D39E07.CE04FF30-- From nobody Sun Feb 4 20:33:56 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A43D0126CD8 for ; Sun, 4 Feb 2018 20:33:54 -0800 (PST) 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 TPzqZ3WoxRbE for ; Sun, 4 Feb 2018 20:33:52 -0800 (PST) Received: from resqmta-po-06v.sys.comcast.net (resqmta-po-06v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:165]) (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 A2104126CD6 for ; Sun, 4 Feb 2018 20:33:52 -0800 (PST) Received: from resomta-po-16v.sys.comcast.net ([96.114.154.240]) by resqmta-po-06v.sys.comcast.net with ESMTP id iYTYeZxGibL3ViYTYe3Z2T; Mon, 05 Feb 2018 04:33:52 +0000 Received: from [IPv6:2602:306:35a4:2190:8560:cda0:1ee:a428] ([IPv6:2602:306:35a4:2190:8560:cda0:1ee:a428]) by resomta-po-16v.sys.comcast.net with SMTP id iYTHevxcDZxJeiYTNeLfCp; Mon, 05 Feb 2018 04:33:50 +0000 From: Tony Li Message-Id: <2C80DD5A-743B-4429-B8B7-0DB809375144@tony.li> Content-Type: multipart/alternative; boundary="Apple-Mail=_81E21E4C-A24A-465E-90F8-9F1C1FF1B724" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Sun, 4 Feb 2018 20:33:34 -0800 In-Reply-To: <003c01d39e2d$4dfadf00$e9f09d00$@gmail.com> Cc: Alexandre Petrescu , its@ietf.org To: =?utf-8?Q?Fran=C3=A7ois_Simon?= References: <1517217856.4315.32.camel@it.uc3m.es> <003c01d39e2d$4dfadf00$e9f09d00$@gmail.com> X-Mailer: Apple Mail (2.3445.5.20) X-CMAE-Envelope: MS4wfN2mKrIoRVheVWwW1nwFJUTtV7JhpjdEC/KE9S7dC6eGWuZ3F8z4JgB5Wo7M+2ndsAEERoy7igBZqSI6qvOyHhjbLVkO2TMEciS/P41vhXDWcvhTDj/r w4oIqSQNfrzve3wZ6JBxqZUf8Q0hg5xLJsTk7M1vUB9LkbWNokq0Wrw6Bhrx5Bpwbm/uGLLGKWLTsrJbGtU5IdD0FrWfX+qSFcelxfyQqa4rlB86mRgiCrPV 0bqxBjE+xPi3SGeJWkusGw== Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 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, 05 Feb 2018 04:33:55 -0000 --Apple-Mail=_81E21E4C-A24A-465E-90F8-9F1C1FF1B724 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Fran=C3=A7ois, > The MTU text currently says: > > The default MTU for IP packets on 802.11-OCB is 1500 octets. > I modify it to say: > > The default MTU for IP packets on 802.11-OCB MUST be 1500 octets. > - The MTU text currently says: > The default MTU for IP packets = on 802.11-OCB is 1500 octets. [Fygs: IEEE 802.11 OCB - MSDU size 2304] Be that as it may, we really need 802.11-OCB to have an MTU of 1500.=20 > - I modify it to say: > The default MTU for IP packets on = 802.11-OCB MUST be 1500 octets. [Fygs: =E2=80=9Cis=E2=80=9D was correct] If you want us to use normative language, then per RFC 2119, we need to = use MUST. The word =E2=80=9Cis=E2=80=9D has no normative connotations. Tony --Apple-Mail=_81E21E4C-A24A-465E-90F8-9F1C1FF1B724 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Fran=C3=A7ois,

RE: [ipwave] Shepherd review of = draft-ietf-ipwave-ipv6-over-80211ocb-12
The MTU text currently says:
> The default MTU for IP packets on = 802.11-OCB is 1500 octets.
I modify it to = say:
 > The default MTU for IP packets on 802.11-OCB MUST = be 1500 octets.
-       The MTU text currently says: > The = default MTU for IP packets on 802.11-OCB is 1500 = octets. [Fygs: = IEEE = 802.11 OCB - MSDU size = 2304]


Be that as it may, we = really need 802.11-OCB to have an MTU of 1500. 


-       I modify it = to say:  > The default MTU = for IP packets on 802.11-OCB MUST be 1500 octets. = [Fygs: =E2=80=9Cis=E2=80=9D was = correct]


If you want us to use = normative language, then per RFC 2119, we need to use MUST. The word = =E2=80=9Cis=E2=80=9D has no normative connotations.

Tony

= --Apple-Mail=_81E21E4C-A24A-465E-90F8-9F1C1FF1B724-- From nobody Sun Feb 4 23:52:10 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C39212946D for ; Sun, 4 Feb 2018 23:52:09 -0800 (PST) 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 L9h_seT51uyT for ; Sun, 4 Feb 2018 23:52:06 -0800 (PST) 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 DCDF41241F5 for ; Sun, 4 Feb 2018 23:52:05 -0800 (PST) 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 w157q32T010864; Mon, 5 Feb 2018 08:52:03 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6CC21201A84; Mon, 5 Feb 2018 08:52:03 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 5E6E4200D25; Mon, 5 Feb 2018 08:52:03 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w157q37p015076; Mon, 5 Feb 2018 08:52:03 +0100 To: =?UTF-8?Q?Fran=c3=a7ois_Simon?= , its@ietf.org References: <1517217856.4315.32.camel@it.uc3m.es> <003c01d39e2d$4dfadf00$e9f09d00$@gmail.com> From: Alexandre Petrescu Message-ID: <7a42bede-8517-d891-98ee-5e7e4f6fb0e2@gmail.com> Date: Mon, 5 Feb 2018 08:52:02 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <003c01d39e2d$4dfadf00$e9f09d00$@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 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, 05 Feb 2018 07:52:09 -0000 Le 05/02/2018 à 03:59, François Simon a écrit : > /The MTU text currently says:/ > > /> The default MTU for IP packets on 802.11-OCB is 1500 octets./ > > /I modify it to say:/ > > / > The default MTU for IP packets on 802.11-OCB MUST be 1500 octets./// > > -// The MTU text currently says:> The default MTU for IP packets on > 802.11-OCB is 1500 octets.*[Fygs: IEEE****802.11 OCB -****MSDU size > 2304****]* It is good to know the MSDU size. However, here we talk about MTU, not MSDU. The 'MTU' is what one sees when typing 'ifconfig'. > -I modify it to say:> The default MTU for IP packets on 802.11-OCB MUST > be 1500 octets.*[Fygs: “is” was correct]* "Is" may have been correct as English expression, but if we want to make it Normative text then we must use normative words such as MUST, SHOULD, MAY, in capitals. Alex > > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu > Sent: Sunday, February 04, 2018 12:08 PM > To: its@ietf.org > Subject: Re: [ipwave] Shepherd review of > draft-ietf-ipwave-ipv6-over-80211ocb-12 > > Le 29/01/2018 à 10:24, Carlos Jesús Bernardos Cano a écrit : > > [...] > >> - The abstract mentions that in order to transmit IPv6 packets on IEEE > >> 802.11-OCB, "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". But the MTU part of the draft does not use any normative text, > >>   the header format is exactly the same than for IEEE 802.11, as the > >> type value. > > The MTU text currently says: > >> The default MTU for IP packets on 802.11-OCB is 1500 octets. > > I modify it to say: > >  > The default MTU for IP packets on 802.11-OCB MUST be 1500 octets. > >> - Section 1 lists two exceptions for 802.11-OCB compared to Ethernet. > >> The first one is not different from regular 802.11, > > I dont understand you. > > The first one says that there are differences between IP-over-WiFi and > IP-over-Ethernet.  These differences are in the headers.  To adapt to > these differences an Ethernet Adaptation Layer is proposed. > > Does this explain better? > > Do I understand the worry correctly? > >> but for the second > >> one, the document only provides recommendations. > > Should it provide something else? > >> - I always thought that "WiFi" does not stand for "Wireless Fidelity". > >> Seehttps://boingboing.net/2005/11/08/wifi-isnt-short-for.html > > Other persons commented, so at this time I propose to leave the def > unchanged. > > [...] > >> > >> - In section 3, it is mentioned that "the operating environment > >> (vehicular networks) brings in new perspectives" --> which are those > >> (that are covered/tackled by the document? > > The document does not cover these new 'perspectives'.  The > 'perspectives' are the ND operation, the handovers for Mobile IP, the > security - the 3 perspectives are difference in OCB than in WiFi.  We > dont describe any here. > > Maybe new work is needed for ND-over-OCB, or Mobile IP with OCB access, > or Security for OCB. > >> - In section 4.1, does the text mean that the MTU SHOULD/MUST be 1500 > >> octects. If that is what is meant, this is really a normative thing > >> that should be written using normative text. If it is just a > >> recommendation, then this should be clearly written as such. > > MUST be. > >> - All the text of section 4.2.1 is not normative, but more a report of > >> what is done today in existing implementations. > > YEs, it is done today in existing WiFi implementations (not Ethernet). > >> Is there any different > >> there that is specific of 802.11-OCB? > > No, there is nothing different. > > I can change the text, but not sure what would be ok. > > Should I move section 4.2.1 in an Appendix? > >> - All subsections 4.x seem informative, not normative. > > Similar to MTU, I could write in the 4.2 "Frame Format" that the > EtherType MUST be 0x86DD (instead of just "is").  Would this make it > more Normative? > > In section 4.3 "LL Addresses" I could put "it is RECOMMENDED" instead of > "it is recommended". > > Sections 4.4. "Address Mapping" and 4.4.1 "Address Mapping -- Unicast" I > could remove. > > Section 4.4.2 "Address Mapping - Multicast" could be removed. > > Section 4.5 "Stateless Autoconf" - I could write "the u/g bits MUST be > opaque" instead of "are significant". > > Section 4.6 "Subnet Structure" - could be removed altogether. > > Are these ok with you? > >> - The privacy part of section 5 is important, as it impacts the > >> operation of IPv6 over this type of networks, so I think this deserves > >> more attention. > > Should I make a subsection called "Privacy Considerations" within the > SEcurity considerations? > >> - In section, H.1, more details about how the captures were obtained > >> should be provided (HW, SW, etc.). > > We added this if sounds ok: > >>       The packet is captured on the Host.  The Host is an IP-OBU > >>       containing an 802.11 interface in format PCI express (an ITRI > >>       product).  The kernel runs the ath5k software driver with > >>       modifications for OCB mode.  The capture tool is Wireshark. > >>       The file format for save and analyze is 'pcap'.  The packet is > >>       generated by the Router.  The Router is an IP-RSU (ITRI > >>       product). > >> Authors, please respond to my questions/comments and address them in a > >> new version of the document. > > We submitted a new version, but please reply to my comments so I fully > address the comments. > > https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-13 > > Alex > > _______________________________________________ > > its mailing list > > its@ietf.org > > https://www.ietf.org/mailman/listinfo/its > From nobody Mon Feb 5 00:07:39 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA561243F3 for ; Mon, 5 Feb 2018 00:07:37 -0800 (PST) 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 GP7Lw5rNIAIw for ; Mon, 5 Feb 2018 00:07:35 -0800 (PST) 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 C8FC31241F5 for ; Mon, 5 Feb 2018 00:07:34 -0800 (PST) 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 w1587W5D016437; Mon, 5 Feb 2018 09:07:32 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C1485200C44; Mon, 5 Feb 2018 09:07:32 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id AD6EB2022CB; Mon, 5 Feb 2018 09:07:32 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w1587WUp027491; Mon, 5 Feb 2018 09:07:32 +0100 To: =?UTF-8?Q?Fran=c3=a7ois_Simon?= Cc: its@ietf.org References: <1517217856.4315.32.camel@it.uc3m.es> <006601d39910$bdcf1cf0$396d56d0$@gmail.com> <000101d39c0f$e3b32f90$ab198eb0$@gmail.com> <827a8e03-75fc-7b64-9b2a-2c2bdc0288ed@gmail.com> <004901d39e31$b6d89630$2489c290$@gmail.com> From: Alexandre Petrescu Message-ID: <46f0fd1b-dac5-0369-f985-b062df170cb0@gmail.com> Date: Mon, 5 Feb 2018 09:07:32 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <004901d39e31$b6d89630$2489c290$@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 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, 05 Feb 2018 08:07:37 -0000 Le 05/02/2018 à 04:30, François Simon a écrit : > Mr. Petrescu, > > /"//I thought "DSRC" is also about Applications and Use-cases.//"/// > > -// No; It is a Dedicated Short Range Communication service. > IbelievethatSAE DSRCTechnical Committee (US) is defining applicationsand > use-cases.// > > // > > “/It is one thing to have no restrictions, and another thing to reckon > that IP is the networking layer.//”/// > > -//Layer 3 (Network Layer) Well, I am happy you list all these network layer protocols. As a side note, it would be good to let know wikipedia to refer here. (there are details that situate the listed protocols to be a little bit above network layer, not right at the network layer). Among the listed protocols the ones precisely at networking layer are: IPv4, IPv6 and IPX. All the others are a little bit above. I have seen IPv4 and IPv6 over 802.11 OCB, but I have not seen IPX run on 802.11 OCB. Stating that IPX _could_ run on 802.11 OCB is a theoretical assumption, but in practice you never know. There is a huge difference between stating IP runs on 802.11 OCB and stating that IPX runs on 802.11 OCB. The protocols I have seen running on 802.11 OCB are IP, ETSI geonetworking and BSM. I think it would be good that DSRC said "802.11 OCB supports network-layer protocols such as IP, ETSI geonetworking and BSM", rather than saying "802.11 OCB supports _any_ network layer parotocols". > ·___CLNP_Connectionless Networking > Protocol > > ·___EGP_Exterior Gateway > Protocol > > ·___EIGRP_Enhanced Interior Gateway > Routing Protocol > > ·___ICMP_Internet > Control Message Protocol > > ·___IGMP_Internet Group Management > Protocol > > ·___IGRP_Interior Gateway Routing > Protocol > > ·___IPv4_Internet Protocol version 4 > > ·___IPv6_Internet Protocol version 6 > > ·___IPSec_Internet Protocol Security > > ·___IPX_Internetwork Packet change > > ·___NAT_Network > Address Translation > > ·___Routed-SMLT_ > > ·___SCCP_Signalling > Connection Control Part > > ·AppleTalk DDP > > ·___GRE_Generic > Routing Encapsulation for tunneling > > ·___OSPF_Open Shortest Path First > > ·___RIP_Routing > Information Protocol > > ·___HSRP_Hot > Standby Router protocol > > ·___VRRP_Virtual > Router Redundancy Protocol > > “/An RSU product has many transceivers inside.//”/// > > -// An RSE may have multiple transceivers. I think there is a huge terminology issue here. "RSE" is not used, I never heard it. Most people say "RSU" to mean a "box" whereas the FCC term RSU seem to mean just a "transceiver". A "transceiver" is typically a "modem". Products are marketed as "RSU" and they are boxes. They have much more inside than just the "transceiver". What could be understood as 'transceiver' (transmitter/receiver) is the modem (modulator/demodulator) or 'baseband' processor, that sits on an extension board that itself sits on a motherboard. There is power supply too. All these make an "RSU". Some RSUs have even more devices like solar panels, mechanical hooks, sophisticated antennas, EV charge stations, LTE modems, optical backhaul and more. BEcause of this discrepancy, I prefer to forget use his "RSU" term in this IP-over-OCB document just as for information. RAther, use the "IP-RSU" to mean what we want it to mean. Alex > > -----Original Message----- > From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] > Sent: Sunday, February 04, 2018 10:49 AM > To: François Simon > Cc: its@ietf.org > Subject: Re: [ipwave] Shepherd review of > draft-ietf-ipwave-ipv6-over-80211ocb-12 > > Le 02/02/2018 à 11:23, François Simon a écrit : > >> Mr. Petrescu, > >> > >> Let's try one more time to clarify the FCC DSRC (in US only) issue. > >> > >> *FCC – DSRC* > >> > >> *Background:*** > >> > >> ** > >> > >> -** The US Federal Communications Commission (FCC) Dedicated Short > >> Range Communication (DSRC) is defined in the Code of Federal > >> Regulations (CFR) > >> 47 mainly Parts 90 and 95. The last update is dated October 1st, 2010; > >> > >> -This includes the ASTM E 2213-03 standard: “Standard Specification for > >> Telecommunications and Information Exchange Between Roadside and > >> Vehicle Systems — 5 GHz Band Dedicated Short Range Communications > >> (DSRC) Medium Access Control (MAC) and Physical Layer (PHY) > >> Specifications”; approved July 10, 2003. The standard is derived from > >> IEEE 802.11a and, in most part, is equivalent to IEEE 802.11 OCB. To > >> date, the DSRC CFRs do not specify IEEE 802.11 OCB. > >> > >> -The related CFRs state that DSRC shall comply with the ASTM E 2213-03. > > Thank you for the explanation.  It is useful to understand that DSRC is > related to ASTM E 2213-03 and that neither refers to 802.11 OCB. > > I think in works related to standards and products it is advantageous if > there is correlation. > > For example, in an ideal world, standards talk about "A" and the > regulation also about "A" and the products and sofware are also labelled > "A". > > In our context, software is labelled "OCB" (kernel drivers), regulation > talks "DSRC" and standards "802.11p" and "802.11 OCB". > >> *Overview of DSRC functions:*** > >> > >> ** > >> > >> The functions listed in DSRC related CFRs are, in general, specified > >> in the ASTM E 2213-03 and IEEE 802.11 OCB: > >> > >> -MAC service definition, frame format, and procedures; > >> > >> -PHY Orthogonal frequency division multiplexing (OFDM); > >> > >> -PHY Service Data Unit format and modulations (data rates): > >> > >> -5.9 GHz band allocated channels, frequency, max. EIRP, and spectrum > >> mask; > >> > >> -Individual Channel use: Safety applications, non-safety applications, > >> and priorities. > >> > >> *Protocols*** > >> > >> ** > >> > >> DSRC being uniquely a MAC and PHY communications service, > > I thought "DSRC" is also about Applications and Use-cases. > >> there here no > >> restriction on Transport and Network protocols that can be used > >> (except for the LCC specified by reference in IEEE 802.11 OCB). In the > >> US, the WAVE standards (IEEE 1609 series) specify these protocols when > >> using DSRC as the communication service. > > It is one thing to have no restrictions, and another thing to reckon > that IP is the networking layer. > >> > >> *OBU / RSU*** > >> > >> ** > >> > >> The CFR (FCC) definitions are: > >> > >> /Roadside unit (RSU). A Roadside Unit is a DSRC transceiver > > Sigh, it is way different. > > An RSU product has many transceivers inside. > >> that is > >> mounted along a road or pedestrian passageway. An RSU may also be > >> mounted on a vehicle or is hand carried, but it may only operate when > >> the vehicle or hand- carried unit is stationary. Furthermore, an RSU > >> operating under this part is restricted to the location where it is > >> licensed to operate. However, portable or hand-held RSUs are permitted > >> to operate where they do not interfere with a site-licensed operation. > >> A RSU broadcasts data to OBUs or exchanges data with OBUs in its > >> communications zone. An RSU also provides channel assignments and > >> operating instructions to OBUs in its communications zone, when > >> required./- [CFR 90.7 - Definitions] - Revised as October 2010. > > I think it should be updated to refer to this document. > >> /On-Board unit (OBU). 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. The OBUs receive and contend for time > >> to transmit on one or more radio frequency (RF) channels. Except where > >> specifically excluded, OBU operation is permitted wherever vehicle > >> operation or human passage is permitted. The OBUs mounted in vehicles > >> are licensed by rule under part 95 of this chapter and communicate > >> with Roadside Units (RSUs) and other OBUs. Portable OBUs are also > >> licensed by rule under part 95 of this chapter. OBU operations in the > >> Unlicensed National Information Infrastructure (UNII) Bands follow the > >> rules in those bands./- [CFR 90.7 - Definitions] - October 2010 > > Thanks for the definitions. > > They are far different from what we need in this draft. > > I will see the other suggestions. > > Alex > >> > >> *IPWAVE Issue*** > >> > >> ** > >> > >> /“The problem with the FCC definition of OBU is that it has no > >> relationship to IP.  Worse, that FCC definition has no indication that > >> it MAY use IP somehow.  And here we say that all OBUs must use IP.  Do > >> you see what I mean?”/// > >> > >> // > >> > >> Correct; the OBU has no relationship with IP and is not intended to. > >> IP is a network protocol.  If an On-Board Unit (OBU) device is > >> required to exchange IP, it needs to be dealt in protocol(s) and/or > >> Management in higher layers similar to WAVE within the On-Board Equipment (OBE) . > >> > >> /“Do you think FCC will mind if we use the term OBU in this draft to > >> mean something else?  I, and a colleague, think that FCC would not > >> mind.”/// > >> > >> // > >> > >> Depending of the reader. If one is familiar with DSRC, OBU and RSU as > >> defined by FCC will come in mind. As far as I know, “OBU” and “RSU” > >> are not registered and could be used for other definitions (something > >> like > >> “ATM”: Asynchronous Transfer Mode and Automatic Teller Machine😊). My > >> suggestion to the IPWAVE team is to use “OBE and RSE”. > >> > >> This is my personal view as I donot represent any involved interest. > >> If any one has questions, let me know. > >> > >> Francois Simon > >> > >> Lojik Technologies > >> > >> -----Original Message----- > >> > >> From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre > >> Petrescu > >> > >> Sent: Monday, January 29, 2018 10:08 AM > >> > >> To:its@ietf.org > >> > >> Subject: Re: [ipwave] Shepherd review of > >> draft-ietf-ipwave-ipv6-over-80211ocb-12 > >> > >> > >> > >> Le 29/01/2018 à 15:52, François Simon a écrit : > >> > >>> My comments arewithin the text*[Fygs.......]*. > >> > >> [...] > >> > >>> In the terminology section, the OBU term is mentioned to be defined > >> > >>> outside the IETF. This is fine, but we have to provide a reference. > >> > >>> And even with that, it would not harm to include some short > >>> definition > >> > >>> to provide context. The RSU term is also defined outside the IETF and > >> > >>> there is quite a lot of text provided (I think the relevant part is > >> > >>> the last sentence, the one starting with "The difference between..."). > >> > >>> Both terms should be handled in the same way. > >> > >>> > >> > >>> *[Fygs: The**definitions**was issued by the FCC 20 years ago.  I have > >> > >>> already provided that information**and references multiple > >> > >>> times.]*** > >> > >> The problem with the FCC definition of OBU is that it has no > >> relationship to IP.  Worse, that FCC definition has no indication that > >> it MAY use IP somehow.  And here we say that all OBUs must use IP.  Do > >> you see what I mean? > >> > >> Do you think FCC will mind if we use the term OBU in this draft to > >> mean something else?  I, and a colleague, think that FCC would not mind. > >> > >> Alex > >> > >> _______________________________________________ > >> > >> its mailing list > >> > >>its@ietf.org > >> > >>https://www.ietf.org/mailman/listinfo/its > >> > From nobody Mon Feb 5 07:10:43 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4EC1242F7 for ; Mon, 5 Feb 2018 07:10:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 9C37dajm4Em1 for ; Mon, 5 Feb 2018 07:10:39 -0800 (PST) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::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 7DDEB12D837 for ; Mon, 5 Feb 2018 07:10:39 -0800 (PST) Received: by mail-qt0-x234.google.com with SMTP id t25so6366554qtg.3 for ; Mon, 05 Feb 2018 07:10:39 -0800 (PST) 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:thread-index:content-language; bh=wi1zJBqq7AV3BlgjKTQYZvCYklBBoh9eGB3sbKIKKmA=; b=Lq6jnX36NqvQ0+cWtT9yLv5VeHS0l/MSTdJ79a+JaErQ3O/Fbd4I/Q4AFdtu5eQ0bb XpfuMgnqXiVa4/d9qgiImRag1Pi8/rrpc7rnnO0rSQQPvpzhK+oDasIOEEWcX0R428Tt 348E3+R41+/E6hKRBQ+QTl7qHA+7GoZmfsiINuKV7TLfK/57JzjOK7a5K67oMHZTO7FY tHQuTBoFJ5gqixXgTrzm42LEBNjELtxiddRhPEUu6Kuaa7itKRmSf0vBar7I2qgBvODf 380HNFAoRYYoDX+RgRKxsiNo+FzP55ZcKcrzkbYJGu2hqVPuuRwkgFkC9VxE+CJxBycE g7JQ== 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:thread-index:content-language; bh=wi1zJBqq7AV3BlgjKTQYZvCYklBBoh9eGB3sbKIKKmA=; b=RhxbFwHb0KLaYrLKghckRB3auLLslNW2S1Lub/F7rpydqMQtqCMaI9K2EZmjI5enMT nm/4jUzWquXHwyFSnmVqtfPNyYovXpk2QoIcuht7pavW6tFWwGDIxakEQeF57jIETg/j HuSaAdj9MTmvHl1ezdW2BoSm+RcLokU8NqlEu7jDGX063iaoaqNlv3NOsRU2m/Kg9Hvc XfNwYwPqGN/3t5HplTD3DplNDTbhV44GsWwzhHLDZqXz6LYWdGiaERHv64dIUxduf9m3 Q0RGtUt6/Bb5784zt8Mq1xeGfc+07z+TnGB/LuekZVqyXryUAkeG+K8GtPUF0sEJIi6f fhXg== X-Gm-Message-State: AKwxytf7Kyc5v34EgqhS11gun+z5HMCub3NYJgfS6sbOtkTrDbGFsvNE p4Dt/sZI8LQgV4Mj93tvc5o= X-Google-Smtp-Source: AH8x224IobUA0P1BR4djshWfgIf2r4tPu7Xtkf7zNUd97jFgiBdo6TEuhVoCQsIlyj1napv3DXwwlg== X-Received: by 10.200.112.1 with SMTP id x1mr69577081qtm.138.1517843438637; Mon, 05 Feb 2018 07:10:38 -0800 (PST) Received: from FrancoisPC (pool-108-48-182-86.washdc.fios.verizon.net. [108.48.182.86]) by smtp.gmail.com with ESMTPSA id l10sm5691558qta.45.2018.02.05.07.10.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Feb 2018 07:10:37 -0800 (PST) From: =?utf-8?Q?Fran=C3=A7ois_Simon?= To: "'Alexandre Petrescu'" Cc: References: <1517217856.4315.32.camel@it.uc3m.es> <006601d39910$bdcf1cf0$396d56d0$@gmail.com> <000101d39c0f$e3b32f90$ab198eb0$@gmail.com> <87888ef4-ae0e-421c-0e48-43b0276f038a@gmail.com> In-Reply-To: <87888ef4-ae0e-421c-0e48-43b0276f038a@gmail.com> Date: Mon, 5 Feb 2018 10:10:37 -0500 Message-ID: <001a01d39e93$7ad4e4b0$707eae10$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01D39E69.92014DB0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQL7ISfFSBtQJ/i74DjDJlbgILh28gG4su6HASuQMD8BaTCMjwKzySiooQ7ZoBA= Content-Language: en-us Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 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, 05 Feb 2018 15:10:42 -0000 This is a multipart message in MIME format. ------=_NextPart_000_001B_01D39E69.92014DB0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable "Is DSRCS a typo? (correct DSRC)." - No typo. DSRCS stands for =E2=80=9CDedicated Short Range Communication = Service=E2=80=9D -----Original Message----- From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com]=20 Sent: Sunday, February 04, 2018 11:08 AM To: Fran=C3=A7ois Simon Cc: its@ietf.org Subject: Re: [ipwave] Shepherd review of = draft-ietf-ipwave-ipv6-over-80211ocb-12 I am adding this OBU ref for reference but I have a question: Le 02/02/2018 =C3=A0 11:23, Fran=C3=A7ois Simon a =C3=A9crit : [...] > /On-Board unit (OBU). An On-Board Unit is a DSRCS transceiver that is Is DSRCS a typo? (correct DSRC). Alex > 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=20 > is either mobile or stationary. The OBUs receive and contend for time=20 > to transmit on one or more radio frequency (RF) channels. Except where = > specifically excluded, OBU operation is permitted wherever vehicle=20 > operation or human passage is permitted. The OBUs mounted in vehicles=20 > are licensed by rule under part 95 of this chapter and communicate=20 > with Roadside Units (RSUs) and other OBUs. Portable OBUs are also=20 > licensed by rule under part 95 of this chapter. OBU operations in the=20 > Unlicensed National Information Infrastructure (UNII) Bands follow the = > rules in those bands./- [CFR 90.7 - Definitions] - October 2010 >=20 > *IPWAVE Issue*** >=20 > ** >=20 > /=E2=80=9CThe problem with the FCC definition of OBU is that it has no = > relationship to IP. Worse, that FCC definition has no indication that = > it MAY use IP somehow. And here we say that all OBUs must use IP. Do = > you see what I mean?=E2=80=9D/// >=20 > // >=20 > Correct; the OBU has no relationship with IP and is not intended to.=20 > IP is a network protocol. If an On-Board Unit (OBU) device is=20 > required to exchange IP, it needs to be dealt in protocol(s) and/or=20 > Management in higher layers similar to WAVE within the On-Board = Equipment (OBE) . >=20 > /=E2=80=9CDo you think FCC will mind if we use the term OBU in this = draft to=20 > mean something else? I, and a colleague, think that FCC would not=20 > mind.=E2=80=9D/// >=20 > // >=20 > Depending of the reader. If one is familiar with DSRC, OBU and RSU as=20 > defined by FCC will come in mind. As far as I know, = =E2=80=9COBU=E2=80=9D and =E2=80=9CRSU=E2=80=9D=20 > are not registered and could be used for other definitions (something=20 > like > =E2=80=9CATM=E2=80=9D: Asynchronous Transfer Mode and Automatic Teller = Machine=F0=9F=98=8A). My=20 > suggestion to the IPWAVE team is to use =E2=80=9COBE and RSE=E2=80=9D. >=20 > This is my personal view as I donot represent any involved interest. =20 > If any one has questions, let me know. >=20 > Francois Simon >=20 > Lojik Technologies >=20 > -----Original Message----- >=20 > From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre=20 > Petrescu >=20 > Sent: Monday, January 29, 2018 10:08 AM >=20 > To: its@ietf.org =20 >=20 > Subject: Re: [ipwave] Shepherd review of > draft-ietf-ipwave-ipv6-over-80211ocb-12 >=20 >=20 >=20 > Le 29/01/2018 =C3=A0 15:52, Fran=C3=A7ois Simon a =C3=A9crit : >=20 >> My comments arewithin the text*[Fygs.......]*. >=20 > [...] >=20 >> In the terminology section, the OBU term is mentioned to be defined >=20 >> outside the IETF. This is fine, but we have to provide a reference. >=20 >> And even with that, it would not harm to include some short=20 >> definition >=20 >> to provide context. The RSU term is also defined outside the IETF and >=20 >> there is quite a lot of text provided (I think the relevant part is >=20 >> the last sentence, the one starting with "The difference = between...").=20 >=20 >> Both terms should be handled in the same way. >=20 >>=20 >=20 >> *[Fygs: The**definitions**was issued by the FCC 20 years ago. I have >=20 >> already provided that information**and references multiple >=20 >> times.]*** >=20 > The problem with the FCC definition of OBU is that it has no=20 > relationship to IP. Worse, that FCC definition has no indication that = > it MAY use IP somehow. And here we say that all OBUs must use IP. Do = > you see what I mean? >=20 > Do you think FCC will mind if we use the term OBU in this draft to=20 > mean something else? I, and a colleague, think that FCC would not = mind. >=20 > Alex >=20 > _______________________________________________ >=20 > its mailing list >=20 > its@ietf.org =20 >=20 > https://www.ietf.org/mailman/listinfo/its >=20 ------=_NextPart_000_001B_01D39E69.92014DB0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable RE: [ipwave] Shepherd review of = draft-ietf-ipwave-ipv6-over-80211ocb-12

"Is DSRCS a typo? (correct DSRC)."

-       No typo. DSRCS stands for = =E2=80=9CDedicated Short Range Communication Service=E2=80=9D

-----Original = Message-----
From: Alexandre Petrescu [mailto:alexandre.petrescu@gm= ail.com]
Sent: Sunday, February 04, 2018 11:08 AM
To: Fran=C3=A7ois Simon <fygsimon@gmail.com>
Cc: its@ietf.org
Subject: Re: [ipwave] Shepherd review of = draft-ietf-ipwave-ipv6-over-80211ocb-12

I am adding = this OBU ref for reference but I have a question:

Le 02/02/2018 = =C3=A0 11:23, Fran=C3=A7ois Simon a =C3=A9crit=C2=A0:

[...]

> /On-Board = unit (OBU). An On-Board Unit is a DSRCS transceiver that = is

Is DSRCS a = typo? (correct DSRC).

Alex

> 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. The OBUs receive and contend for time =

> to = transmit on one or more radio frequency (RF) channels. Except where =

> = specifically excluded, OBU operation is permitted wherever vehicle =

> operation = or human passage is permitted. The OBUs mounted in vehicles =

> are = licensed by rule under part 95 of this chapter and communicate =

> with = Roadside Units (RSUs) and other OBUs. Portable OBUs are also =

> licensed = by rule under part 95 of this chapter. OBU operations in the =

> Unlicensed = National Information Infrastructure (UNII) Bands follow the =

> rules in = those bands./- [CFR 90.7 - Definitions] - October 2010

> =

> *IPWAVE = Issue***

> =

> = **

> =

> = /=E2=80=9CThe problem with the FCC definition of OBU is that it has no =

> = relationship to IP.=C2=A0 Worse, that FCC definition has no indication = that

> it MAY use = IP somehow.=C2=A0 And here we say that all OBUs must use IP.=C2=A0 Do =

> you see = what I mean?=E2=80=9D///

> =

> = //

> =

> Correct; = the OBU has no relationship with IP and is not intended to. =

> IP is a = network protocol.=C2=A0 If an On-Board Unit (OBU) device is =

> required = to exchange IP, it needs to be dealt in protocol(s) and/or =

> Management = in higher layers similar to WAVE within the On-Board Equipment (OBE) = .

> =

> = /=E2=80=9CDo you think FCC will mind if we use the term OBU in this = draft to

> mean = something else?=C2=A0 I, and a colleague, think that FCC would not =

> = mind.=E2=80=9D///

> =

> = //

> =

> Depending = of the reader. If one is familiar with DSRC, OBU and RSU as =

> defined by = FCC will come in mind. As far as I know, =E2=80=9COBU=E2=80=9D and = =E2=80=9CRSU=E2=80=9D

> are not = registered and could be used for other definitions (something =

> = like

> = =E2=80=9CATM=E2=80=9D: Asynchronous Transfer Mode and Automatic Teller = Machine=F0=9F=98=8A). My

> suggestion = to the IPWAVE team is to use =E2=80=9COBE and = RSE=E2=80=9D.

> =

> This is my = personal view as I donot represent any involved interest.=C2=A0 =

> If any one = has questions, let me know.

> =

> Francois = Simon

> =

> Lojik = Technologies

> =

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

> =

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

> = Petrescu

> =

> Sent: = Monday, January 29, 2018 10:08 AM

> =

> = To: its@ietf.org

> =

> Subject: = Re: [ipwave] Shepherd review of

> = draft-ietf-ipwave-ipv6-over-80211ocb-12

> =

> =

> =

> Le = 29/01/2018 =C3=A0 15:52, Fran=C3=A7ois Simon a =C3=A9crit = :

> =

>> My = comments arewithin the text*[Fygs.......]*.

> =

> = [...]

> =

>> In the = terminology section, the OBU term is mentioned to be = defined

> =

>> = outside the IETF. This is fine, but we have to provide a = reference.

> =

>> And = even with that, it would not harm to include some short =

>> = definition

> =

>> to = provide context. The RSU term is also defined outside the IETF = and

> =

>> there = is quite a lot of text provided (I think the relevant part = is

> =

>> the = last sentence, the one starting with "The difference = between...").

> =

>> Both = terms should be handled in the same way.

> =

>> =

> =

>> = *[Fygs: The**definitions**was issued by the FCC 20 years ago.=C2=A0 I = have

> =

>> = already provided that information**and references = multiple

> =

>> = times.]***

> =

> The = problem with the FCC definition of OBU is that it has no =

> = relationship to IP.=C2=A0 Worse, that FCC definition has no indication = that

> it MAY use = IP somehow.=C2=A0 And here we say that all OBUs must use IP.=C2=A0 Do =

> you see = what I mean?

> =

> Do you = think FCC will mind if we use the term OBU in this draft to =

> mean = something else?=C2=A0 I, and a colleague, think that FCC would not = mind.

> =

> = Alex

> =

> = _______________________________________________

> =

> its = mailing list

> =

> its@ietf.org

> =

> https://www.ietf.org/mailman/listinfo/its<= SPAN LANG=3D"en-us">

>

------=_NextPart_000_001B_01D39E69.92014DB0-- From nobody Mon Feb 5 07:37:01 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4097C12D848 for ; Mon, 5 Feb 2018 07:37:00 -0800 (PST) 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 s2BZ3uFBwHtr for ; Mon, 5 Feb 2018 07:36:58 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::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 22570126D73 for ; Mon, 5 Feb 2018 07:36:58 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id c128so1922184qkb.4 for ; Mon, 05 Feb 2018 07:36:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :thread-index:content-language; bh=4Yf8su8NjOqay5S60QKVk/3yGINQBrAOlsXTdZHu1XY=; b=mSllAL7HEkz/5z47KVhrl2utebcq/HwOp9nYL8E2/9szQtnHHuQS1Y5WwhB27b1ff5 RLOa1BM56GP52BpMUcXmC3vFipw1yUmaVSeuFxTnUN7VMtbX+B3/shIc2ecCyou1N1j8 xZhorjuBUivg7D/QF7bp2ZZtv3UD8lUyM1f8jwF3yxSjMh25KUGZUe1dzaWfzD8UOmfB A9zAKpj8ELf8m1NZ1L8582vpVa7FqxtNcbAizmVwzCr0FVk5plMSXUomvz4Z+U3aFAhz 0AVs+5bHRQptk/OVZ9jyQzCHgq5Qx6GLyzCR3+wawzdQOl/028DOGB5TkvNNSkCvbPi7 swtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=4Yf8su8NjOqay5S60QKVk/3yGINQBrAOlsXTdZHu1XY=; b=klm2kgc5S/tK/BGzOTBOxu+zhzv/7iydE5OCcPzZWT/QWG7GDvzk0lSyO6a/3+mHwF ElZREHndna8iX++aXrsT5dY6tjOdHtT0w2kvuOXeWHbC3lCtWUY+8VsN22cp7LMWYDiN UNM8CQjXF5AioOHRhdy8RSfOWwJBQHhjcPowUZlEqRVB1Nz2YFdyO0nvP9mzGxalVJlp M09WWhrcLbL3zaKZTYBmOiRV9GawV9kp8RBsedkiOKR3+kCU8rhSd2MUgZAEs+BisQDv /2w3qDYGdO07gWYv3isCrl43Z56uqWsHO/4nH0x4mWFy/iy/jnGX4zTVFrLCLh8G6eMe 8t+g== X-Gm-Message-State: APf1xPDsYs+Hv+ArRJilh2OHA3sayqKdgTw5n+n9LnEhPyUPi16uT6vy 5j2wiMLaqvy+9f99xYARUdWXew== X-Google-Smtp-Source: AH8x226AcyggZqutiyIbc4zXdjwBbXAzmyHpxHN51azx/Xt1s+H/biCmR45JgkiSDMminbpRn9GKhw== X-Received: by 10.55.40.10 with SMTP id o10mr18417197qkh.134.1517845017300; Mon, 05 Feb 2018 07:36:57 -0800 (PST) Received: from FrancoisPC (pool-108-48-182-86.washdc.fios.verizon.net. [108.48.182.86]) by smtp.gmail.com with ESMTPSA id q2sm709324qta.47.2018.02.05.07.36.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Feb 2018 07:36:56 -0800 (PST) From: =?utf-8?Q?Fran=C3=A7ois_Simon?= To: "'Russ Housley'" , References: <1517217856.4315.32.camel@it.uc3m.es> <006601d39910$bdcf1cf0$396d56d0$@gmail.com> <000101d39c0f$e3b32f90$ab198eb0$@gmail.com> <707c9f11-c10e-f1e3-f68d-ab98fc632ca7@gmail.com> In-Reply-To: Date: Mon, 5 Feb 2018 10:36:56 -0500 Message-ID: <003f01d39e97$27bd15f0$773741d0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0040_01D39E6D.3EE97EF0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQL7ISfFSBtQJ/i74DjDJlbgILh28gG4su6HASuQMD8BaTCMjwK9q5dAArfdMz6g+NKOEA== Content-Language: en-us Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 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, 05 Feb 2018 15:37:00 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0040_01D39E6D.3EE97EF0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =E2=80=9CI think it should be fairly easy to use the term OBU properly. = Some OBUs will make use of IP, and when they do, they MUST follow the = guidance in this document.=E2=80=9D * An OBU does not use IP; It provide the service to transport a MPDU = (MAC) which contains the IPv6 frame (Network Layer). =20 =20 =20 From: its [mailto:its-bounces@ietf.org] On Behalf Of Russ Housley Sent: Sunday, February 04, 2018 2:56 PM To: its@ietf.org Subject: Re: [ipwave] Shepherd review of = draft-ietf-ipwave-ipv6-over-80211ocb-12 =20 =20 /=E2=80=9CThe problem with the FCC definition of OBU is that it has no = relationship to IP. Worse, that FCC definition has no indication that = it MAY use IP somehow. And here we say that all OBUs must use IP. Do = you see what I mean?=E2=80=9D/// // Correct; the OBU has no relationship with IP and is not intended to. IP = is a network protocol. If an On-Board Unit (OBU) device is required to = exchange IP, it needs to be dealt in protocol(s) and/or Management in = higher layers similar to WAVE within the On-Board Equipment (OBE) . /=E2=80=9CDo you think FCC will mind if we use the term OBU in this = draft to mean something else? I, and a colleague, think that FCC would = not mind.=E2=80=9D/// // Depending of the reader. If one is familiar with DSRC, OBU and RSU as = defined by FCC will come in mind. As far as I know, = =E2=80=9COBU=E2=80=9D and =E2=80=9CRSU=E2=80=9D are not registered and = could be used for other definitions (something like = =E2=80=9CATM=E2=80=9D: Asynchronous Transfer Mode and Automatic Teller = Machine=F0=9F=98=8A). My suggestion to the IPWAVE team is to use = =E2=80=9COBE and RSE=E2=80=9D. This is my personal view as I donot represent any involved interest. If = any one has questions, let me know. =20 I think it should be fairly easy to use the term OBU properly. Some = OBUs will make use of IP, and when they do, they MUST follow the = guidance in this document. =20 Russ =20 ------=_NextPart_000_0040_01D39E6D.3EE97EF0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

=E2=80=9CI think it should be fairly easy to use = the term OBU properly.  Some OBUs will make use of IP, and when = they do, they MUST follow the guidance in this = document.=E2=80=9D

  • An OBU does not use = IP; It provide the service to transport a MPDU (MAC) which contains the = IPv6 frame (Network Layer).

 

 

 

From: its = [mailto:its-bounces@ietf.org] On Behalf Of Russ = Housley
Sent: Sunday, February 04, 2018 2:56 PM
To: = its@ietf.org
Subject: Re: [ipwave] Shepherd review of = draft-ietf-ipwave-ipv6-over-80211ocb-12

 

 

/=E2=80=9CTh= e problem with the FCC definition of OBU is that it has no relationship = to IP.  Worse, that FCC definition has no indication that it MAY = use IP somehow.  And here we say that all OBUs must use IP.  = Do you see what I mean?=E2=80=9D///
//
Correct; the OBU has no = relationship with IP and is not intended to. IP is a network = protocol.  If an On-Board Unit (OBU) device is required to exchange = IP, it needs to be dealt in protocol(s) and/or Management in higher = layers similar to WAVE within the On-Board Equipment (OBE) = .
/=E2=80=9CDo you think FCC will mind if we use the term OBU in this = draft to mean something else?  I, and a colleague, think that FCC = would not mind.=E2=80=9D///
//
Depending of the reader. If one is = familiar with DSRC, OBU and RSU as defined by FCC will come in mind. As = far as I know, =E2=80=9COBU=E2=80=9D and =E2=80=9CRSU=E2=80=9D are not = registered and could be used for other definitions (something like = =E2=80=9CATM=E2=80=9D: Asynchronous Transfer Mode and Automatic Teller = Machine😊). My = suggestion to the IPWAVE team is to use =E2=80=9COBE and = RSE=E2=80=9D.
This is my personal view as I donot represent any = involved interest.  If any one has questions, let me = know.

 

I think = it should be fairly easy to use the term OBU properly.  Some OBUs = will make use of IP, and when they do, they MUST follow the guidance in = this document.

 

Russ

 

------=_NextPart_000_0040_01D39E6D.3EE97EF0-- From nobody Mon Feb 5 07:40:45 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27AED12D848 for ; Mon, 5 Feb 2018 07:40:45 -0800 (PST) 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 b2ObOtOLsaCT for ; Mon, 5 Feb 2018 07:40:43 -0800 (PST) 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 B546B126D73 for ; Mon, 5 Feb 2018 07:40:42 -0800 (PST) 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 w15Feemx011791; Mon, 5 Feb 2018 16:40:40 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id ADEF7204481; Mon, 5 Feb 2018 16:40:40 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9DEA5204461; Mon, 5 Feb 2018 16:40:40 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w15FeevB028393; Mon, 5 Feb 2018 16:40:40 +0100 To: =?UTF-8?Q?Fran=c3=a7ois_Simon?= Cc: its@ietf.org References: <1517217856.4315.32.camel@it.uc3m.es> <006601d39910$bdcf1cf0$396d56d0$@gmail.com> <000101d39c0f$e3b32f90$ab198eb0$@gmail.com> <87888ef4-ae0e-421c-0e48-43b0276f038a@gmail.com> <001a01d39e93$7ad4e4b0$707eae10$@gmail.com> From: Alexandre Petrescu Message-ID: Date: Mon, 5 Feb 2018 16:40:40 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <001a01d39e93$7ad4e4b0$707eae10$@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 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, 05 Feb 2018 15:40:45 -0000 Le 05/02/2018 à 16:10, François Simon a écrit : > /"//Is DSRCS a typo? (correct DSRC).//"/// > > -// No typo. DSRCS stands for “Dedicated Short Range Communication Service” So, in order to define OBU in terms of DSRCS one has to define first DSRCS, all while caring to avoid loops. I think it can become too lengthy. Alex > > -----Original Message----- > From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] > Sent: Sunday, February 04, 2018 11:08 AM > To: François Simon > Cc: its@ietf.org > Subject: Re: [ipwave] Shepherd review of > draft-ietf-ipwave-ipv6-over-80211ocb-12 > > I am adding this OBU ref for reference but I have a question: > > Le 02/02/2018 à 11:23, François Simon a écrit : > > [...] > >> /On-Board unit (OBU). An On-Board Unit is a DSRCS transceiver that is > > Is DSRCS a typo? (correct DSRC). > > Alex > >> 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. The OBUs receive and contend for time > >> to transmit on one or more radio frequency (RF) channels. Except where > >> specifically excluded, OBU operation is permitted wherever vehicle > >> operation or human passage is permitted. The OBUs mounted in vehicles > >> are licensed by rule under part 95 of this chapter and communicate > >> with Roadside Units (RSUs) and other OBUs. Portable OBUs are also > >> licensed by rule under part 95 of this chapter. OBU operations in the > >> Unlicensed National Information Infrastructure (UNII) Bands follow the > >> rules in those bands./- [CFR 90.7 - Definitions] - October 2010 > >> > >> *IPWAVE Issue*** > >> > >> ** > >> > >> /“The problem with the FCC definition of OBU is that it has no > >> relationship to IP.  Worse, that FCC definition has no indication that > >> it MAY use IP somehow.  And here we say that all OBUs must use IP.  Do > >> you see what I mean?”/// > >> > >> // > >> > >> Correct; the OBU has no relationship with IP and is not intended to. > >> IP is a network protocol.  If an On-Board Unit (OBU) device is > >> required to exchange IP, it needs to be dealt in protocol(s) and/or > >> Management in higher layers similar to WAVE within the On-Board Equipment (OBE) . > >> > >> /“Do you think FCC will mind if we use the term OBU in this draft to > >> mean something else?  I, and a colleague, think that FCC would not > >> mind.”/// > >> > >> // > >> > >> Depending of the reader. If one is familiar with DSRC, OBU and RSU as > >> defined by FCC will come in mind. As far as I know, “OBU” and “RSU” > >> are not registered and could be used for other definitions (something > >> like > >> “ATM”: Asynchronous Transfer Mode and Automatic Teller Machine😊). My > >> suggestion to the IPWAVE team is to use “OBE and RSE”. > >> > >> This is my personal view as I donot represent any involved interest. > >> If any one has questions, let me know. > >> > >> Francois Simon > >> > >> Lojik Technologies > >> > >> -----Original Message----- > >> > >> From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre > >> Petrescu > >> > >> Sent: Monday, January 29, 2018 10:08 AM > >> > >> To:its@ietf.org > >> > >> Subject: Re: [ipwave] Shepherd review of > >> draft-ietf-ipwave-ipv6-over-80211ocb-12 > >> > >> > >> > >> Le 29/01/2018 à 15:52, François Simon a écrit : > >> > >>> My comments arewithin the text*[Fygs.......]*. > >> > >> [...] > >> > >>> In the terminology section, the OBU term is mentioned to be defined > >> > >>> outside the IETF. This is fine, but we have to provide a reference. > >> > >>> And even with that, it would not harm to include some short > >>> definition > >> > >>> to provide context. The RSU term is also defined outside the IETF and > >> > >>> there is quite a lot of text provided (I think the relevant part is > >> > >>> the last sentence, the one starting with "The difference between..."). > >> > >>> Both terms should be handled in the same way. > >> > >>> > >> > >>> *[Fygs: The**definitions**was issued by the FCC 20 years ago.  I have > >> > >>> already provided that information**and references multiple > >> > >>> times.]*** > >> > >> The problem with the FCC definition of OBU is that it has no > >> relationship to IP.  Worse, that FCC definition has no indication that > >> it MAY use IP somehow.  And here we say that all OBUs must use IP.  Do > >> you see what I mean? > >> > >> Do you think FCC will mind if we use the term OBU in this draft to > >> mean something else?  I, and a colleague, think that FCC would not mind. > >> > >> Alex > >> > >> _______________________________________________ > >> > >> its mailing list > >> > >>its@ietf.org > >> > >>https://www.ietf.org/mailman/listinfo/its > >> > From nobody Mon Feb 5 17:16:00 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6963912DA07 for ; Mon, 5 Feb 2018 17:15:58 -0800 (PST) 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 gMqeJ-fOtPfs for ; Mon, 5 Feb 2018 17:15:56 -0800 (PST) Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (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 636E312DA05 for ; Mon, 5 Feb 2018 17:15:55 -0800 (PST) Received: from resomta-po-14v.sys.comcast.net ([96.114.154.238]) by resqmta-po-03v.sys.comcast.net with ESMTP id irrEe2jrIdNHnirrXem2Qh; Tue, 06 Feb 2018 01:15:55 +0000 Received: from [172.22.228.216] ([162.210.130.3]) by resomta-po-14v.sys.comcast.net with SMTP id irpLeQhqvn7MwirpOeHNSU; Tue, 06 Feb 2018 01:13:52 +0000 From: tony.li@tony.li Message-Id: <2CB46182-B481-4E77-AEE9-C2392B5D6AEC@tony.li> Content-Type: multipart/alternative; boundary="Apple-Mail=_51771857-BEB6-47C0-927B-7BD33321DC2C" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Mon, 5 Feb 2018 17:13:38 -0800 In-Reply-To: Cc: =?utf-8?Q?Fran=C3=A7ois_Simon?= , Alexandre Petrescu , its@ietf.org To: dickroy@alum.mit.edu References: <1517217856.4315.32.camel@it.uc3m.es> <003c01d39e2d$4dfadf00$e9f09d00$@gmail.com> <2C80DD5A-743B-4429-B8B7-0DB809375144@tony.li> X-Mailer: Apple Mail (2.3445.5.20) X-CMAE-Envelope: MS4wfH+oM6/eT/Z+1grZuQcvMpI7+BKH6/kp7k4JIzmOD6QSQAS/jGqtZOabVkMbKamUTz//53mVvQBVF7YMjYvOZie63wGDioUg0XmkjNbgMM7R1FjHY7rU Zahx/fBABSRd2YV9Xl62R78vD2DuD4+ncfJo/pXV0LkxARvXIHH2H2WE6zAOAmhgYJGLN4NEvehrqmxwXVLgzBUxVWKqRaPhhocPC9/8N3VVgk3ytMBvveeT GQdyB6WYzjRVHVhaumqYxbSFbj6pGzp4GdSbTvaeAHU= Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 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, 06 Feb 2018 01:15:58 -0000 --Apple-Mail=_51771857-BEB6-47C0-927B-7BD33321DC2C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Dick, > > The default MTU for IP packets on 802.11-OCB MUST be 1500 octets. > - The MTU text currently says: > The default MTU for IP packets = on 802.11-OCB is 1500 octets. [Fygs: IEEE 802.11 OCB - MSDU size 2304] > =20 > =20 > Be that as it may, we really need 802.11-OCB to have an MTU of 1500.=20= > [RR] Not true. You may want to require it when using 802.11 as a first = hop on an ethernet LAN, however no such requirement is necessary for = example when broadcasting BSMs or SPaT/MAP ADUs.=20 AFAIK, those have nothing to do with IP. What you wanna do with your = OBU that is NOT IP is completely outside of the scope of this document, = working group, and mailing list. > - I modify it to say: > The default MTU for IP packets on = 802.11-OCB MUST be 1500 octets. [Fygs: =E2=80=9Cis=E2=80=9D was correct] > =20 > =20 > If you want us to use normative language, then per RFC 2119, we need = to use MUST. The word =E2=80=9Cis=E2=80=9D has no normative = connotations. > [RR] Don=E2=80=99t make such blanket normative statements without = qualifiers. Sorry, but that=E2=80=99s just the basics of working with RFC 2119. > You might also note that in 1609.3 you will find the following = interesting ASN.1: > =E2=80=9Cdot3WsmMaxLength OBJECT-TYPE > SYNTAX INTEGER (1..2302) > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "Maximum size in octets of the variable length portion > of a WSM, including data. > The default value is 1400. Max value is > 802.11 MAC MSDU size minus EtherType size (2304 minus > 2 =3D 2302)." > ::=3D { dot3LocalInfo 4=E2=80=9D That=E2=80=99s very unfortunate and unsuitable for IP over 802.11-OCB. The default 1500 byte MTU is pretty much a necessity for inter-operation = with the rest of the Internet. We=E2=80=99ve done other media with other = MTUs before and been repeatedly bitten by fragmentation. Yes, you can = use other MTUs in limited settings, but it requires careful site = engineering and planning. Dissimilar MTUs on the same media cause all = sorts of black-hole problems. The best solution is to simply start = everyone off at 1500. Tony --Apple-Mail=_51771857-BEB6-47C0-927B-7BD33321DC2C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Hi Dick,

 > The default MTU for = IP packets on 802.11-OCB MUST be 1500 octets.
-       The MTU text = currently says: > The = default MTU for IP packets on 802.11-OCB is 1500 octets. [Fygs: IEEE 802.11 OCB - MSDU size 2304]
 
 
Be = that as it may, we really need 802.11-OCB to have an MTU of = 1500. 
[RR] Not true. You may want to require it when using 802.11 = as a first hop on an ethernet LAN, however no such requirement is = necessary for example when broadcasting BSMs or SPaT/MAP ADUs. 


AFAIK, those have nothing to = do with IP.  What you wanna do with your OBU that is NOT IP is = completely outside of the scope of this document, working group, and = mailing list.


-       I modify it = to say:  > The default MTU for IP = packets on 802.11-OCB MUST be 1500 octets. [Fygs: =E2=80=9Cis=E2=80=9D was = correct]
 
 
If you = want us to use normative language, then per RFC 2119, we need to use = MUST. The word =E2=80=9Cis=E2=80=9D has no normative connotations.
[RR] Don=E2=80=99t make such blanket normative statements = without = qualifiers.


Sorry, but that=E2=80= =99s just the basics of working with RFC 2119.


You might also note that in = 1609.3 you will find the following interesting ASN.1:
=E2=80=9Cdot3WsmMaxLength = OBJECT-TYPE
SYNTAX INTEGER (1..2302)
MAX-ACCESS read-write
STATUS = current
DESCRIPTION
"Maximum size in octets of the = variable length portion
of a WSM, including data.
The = default value is 1400. Max value is
802.11 = MAC MSDU size minus EtherType size (2304 minus
2 =3D = 2302)."
::=3D { dot3LocalInfo = 4=E2=80=9D


That=E2=80=99s = very unfortunate and unsuitable for IP over 802.11-OCB.

The default 1500 byte MTU is pretty much a = necessity for inter-operation with the rest of the Internet. We=E2=80=99ve= done other media with other MTUs before and been repeatedly bitten by = fragmentation. Yes, you can use other MTUs in limited settings, but it = requires careful site engineering and planning.  Dissimilar MTUs on = the same media cause all sorts of black-hole problems. The best solution = is to simply start everyone off at 1500.

Tony

= --Apple-Mail=_51771857-BEB6-47C0-927B-7BD33321DC2C-- From nobody Mon Feb 5 18:25:17 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 145E912D80E for ; Mon, 5 Feb 2018 18:25:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.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, 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 (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 Q5b1PE_lhWn3 for ; Mon, 5 Feb 2018 18:25:11 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C4CA120725 for ; Mon, 5 Feb 2018 18:25:11 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id x127so455666qkb.12 for ; Mon, 05 Feb 2018 18:25:11 -0800 (PST) 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:thread-index:content-language; bh=FL86ctVJ/PloYv9P0/eGjyP8wEEjuVtVXerhzQmgp74=; b=POuH0d8aSZVOhmkOAnNGS05pcqycZEomsuDNAdYV26eAgwZWy2DLwtlzjrT8YWFkz7 BNqQl8TkvRxbT0sDhVfJYF6OJPUGcd2TMhYZUbxZ4FpXYjqBzbuQNnFr4GDMRDWEku6s QQ1eZHrryjEzaGoCcn8NRvGVRF46JE/HWuuIe7gC+RrOg5u5he/xyHNJVooMgceP3qrV O55ptqeWlC/fNg/8rU3xDR2sFs4U+yFLu/uYgh0fshoKSddhd1nGKT8Tyb0f2+I3O/HZ DhgoE5NnW4Gq4zDynx9SkTuOlXKRuUEx6kSGwjuJ9YZ1sXpUB14RvirKeuj0RkGkxkpN DC/w== 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:thread-index:content-language; bh=FL86ctVJ/PloYv9P0/eGjyP8wEEjuVtVXerhzQmgp74=; b=VZjeSaluCYgEtphVUqGWyKEsI0e+4CTSxFpWbbEi5gMfGeiWFkR6UJwuKhaljKOz0I ZpiCBEEQlJQtSGgmnNb7EdTXwLAJxTInzh52Qdw8gTeSOIQ3mbVFtAK24d+t5GpTKPVf mMgXEYB9PKsvp05R/57Oiqmw4GHU3bA3oHHzkJad1Aca+DoD1LLqhjolSrGFRWcEwbtA dv82UmFd9NOD4qbo6iPhhcPcPDLEMWpD/6Jb7FCDnqC1ZtWKVyFbCR48c6IG6Z9SWrE1 zGiEMnbBdnonpKZKEonSlUkDeMwvcIDxA5+XxlvtqH5hysIo0SStModwnkgYNa4swCwJ iVvg== X-Gm-Message-State: APf1xPCe/+g+30QqcuLxrffI+noCeVNORT52GadxnwihkhAJsglZ+Gx3 9BozFrhz8KFfEMiFRZKDwoo= X-Google-Smtp-Source: AH8x2272NC2Vnp3rWvhiZjpcbiZnE79L+LfRKpsjXTFLeb86P3ENUGxxjh4aLdInjS7crwUwb6mwvA== X-Received: by 10.55.123.67 with SMTP id w64mr1246245qkc.31.1517883910715; Mon, 05 Feb 2018 18:25:10 -0800 (PST) Received: from FrancoisPC (pool-108-48-182-86.washdc.fios.verizon.net. [108.48.182.86]) by smtp.gmail.com with ESMTPSA id z22sm6728695qti.75.2018.02.05.18.25.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Feb 2018 18:25:09 -0800 (PST) From: =?utf-8?Q?Fran=C3=A7ois_Simon?= To: Cc: , References: <1517217856.4315.32.camel@it.uc3m.es> <006601d39910$bdcf1cf0$396d56d0$@gmail.com> <000101d39c0f$e3b32f90$ab198eb0$@gmail.com> <87888ef4-ae0e-421c-0e48-43b0276f038a@gmail.com> <001a01d39e93$7ad4e4b0$707eae10$@gmail.com> In-Reply-To: Date: Mon, 5 Feb 2018 21:25:09 -0500 Message-ID: <000e01d39ef1$b5d553c0$217ffb40$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01D39EC7.CD042DC0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQL7ISfFSBtQJ/i74DjDJlbgILh28gG4su6HASuQMD8BaTCMjwKzySioAdr+SycCSIzPe6DueO2w Content-Language: en-us Archived-At: Subject: [ipwave] FW: Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 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, 06 Feb 2018 02:25:15 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000F_01D39EC7.CD042DC0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable " So, in order to define OBU in terms of DSRCS one has to define first = DSRCS, all while caring to avoid loops. I think it can become too = lengthy." - Dedicated Short-Range Communications Services (DSRCS). - The use of = radio techniques to transfer data over short distances between roadside = and mobile units, between mobile units, and between portable and mobile units to = perform operations related to the improvement of traffic flow, traffic = safety, and other intelligent transportation service applications in a variety = of environments. DSRCS systems may also transmit status and = instructional messages related to the units involved. [ Ref. 47 CFR 90.7 =E2=80=93 = Definitions] -----Original Message----- From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com]=20 Sent: Monday, February 05, 2018 10:41 AM To: Fran=C3=A7ois Simon Cc: its@ietf.org Subject: Re: [ipwave] Shepherd review of = draft-ietf-ipwave-ipv6-over-80211ocb-12 Le 05/02/2018 =C3=A0 16:10, Fran=C3=A7ois Simon a =C3=A9crit : > /"//Is DSRCS a typo? (correct DSRC).//"/// >=20 > -// No typo. DSRCS stands for =E2=80=9CDedicated Short Range = Communication Service=E2=80=9D So, in order to define OBU in terms of DSRCS one has to define first = DSRCS, all while caring to avoid loops. I think it can become too = lengthy. Alex >=20 > -----Original Message----- > From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] > Sent: Sunday, February 04, 2018 11:08 AM > To: Fran=C3=A7ois Simon > > Cc: its@ietf.org =20 > Subject: Re: [ipwave] Shepherd review of > draft-ietf-ipwave-ipv6-over-80211ocb-12 >=20 > I am adding this OBU ref for reference but I have a question: >=20 > Le 02/02/2018 =C3=A0 11:23, Fran=C3=A7ois Simon a =C3=A9crit : >=20 > [...] >=20 >> /On-Board unit (OBU). An On-Board Unit is a DSRCS transceiver that is >=20 > Is DSRCS a typo? (correct DSRC). >=20 > Alex >=20 >> normally mounted in or on a vehicle, or which in some instances may=20 >> be >=20 >> a portable unit. An OBU can be operational while a vehicle or person >=20 >> is either mobile or stationary. The OBUs receive and contend for time >=20 >> to transmit on one or more radio frequency (RF) channels. Except=20 >> where >=20 >> specifically excluded, OBU operation is permitted wherever vehicle >=20 >> operation or human passage is permitted. The OBUs mounted in vehicles >=20 >> are licensed by rule under part 95 of this chapter and communicate >=20 >> with Roadside Units (RSUs) and other OBUs. Portable OBUs are also >=20 >> licensed by rule under part 95 of this chapter. OBU operations in the >=20 >> Unlicensed National Information Infrastructure (UNII) Bands follow=20 >> the >=20 >> rules in those bands./- [CFR 90.7 - Definitions] - October 2010 >=20 >>=20 >=20 >> *IPWAVE Issue*** >=20 >>=20 >=20 >> ** >=20 >>=20 >=20 >> /=E2=80=9CThe problem with the FCC definition of OBU is that it has = no >=20 >> relationship to IP. Worse, that FCC definition has no indication=20 >> that >=20 >> it MAY use IP somehow. And here we say that all OBUs must use IP. =20 >> Do >=20 >> you see what I mean?=E2=80=9D/// >=20 >>=20 >=20 >> // >=20 >>=20 >=20 >> Correct; the OBU has no relationship with IP and is not intended to.=20 >=20 >> IP is a network protocol. If an On-Board Unit (OBU) device is >=20 >> required to exchange IP, it needs to be dealt in protocol(s) and/or >=20 >> Management in higher layers similar to WAVE within the On-Board = Equipment (OBE) . >=20 >>=20 >=20 >> /=E2=80=9CDo you think FCC will mind if we use the term OBU in this = draft to >=20 >> mean something else? I, and a colleague, think that FCC would not >=20 >> mind.=E2=80=9D/// >=20 >>=20 >=20 >> // >=20 >>=20 >=20 >> Depending of the reader. If one is familiar with DSRC, OBU and RSU as >=20 >> defined by FCC will come in mind. As far as I know, = =E2=80=9COBU=E2=80=9D and =E2=80=9CRSU=E2=80=9D=20 >=20 >> are not registered and could be used for other definitions (something >=20 >> like >=20 >> =E2=80=9CATM=E2=80=9D: Asynchronous Transfer Mode and Automatic = Teller Machine=F0=9F=98=8A). My >=20 >> suggestion to the IPWAVE team is to use =E2=80=9COBE and = RSE=E2=80=9D. >=20 >>=20 >=20 >> This is my personal view as I donot represent any involved interest. = >=20 >> If any one has questions, let me know. >=20 >>=20 >=20 >> Francois Simon >=20 >>=20 >=20 >> Lojik Technologies >=20 >>=20 >=20 >> -----Original Message----- >=20 >>=20 >=20 >> From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre >=20 >> Petrescu >=20 >>=20 >=20 >> Sent: Monday, January 29, 2018 10:08 AM >=20 >>=20 >=20 >> To:its@ietf.org >=20 >>=20 >=20 >> Subject: Re: [ipwave] Shepherd review of >=20 >> draft-ietf-ipwave-ipv6-over-80211ocb-12 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >> Le 29/01/2018 =C3=A0 15:52, Fran=C3=A7ois Simon a =C3=A9crit : >=20 >>=20 >=20 >>> My comments arewithin the text*[Fygs.......]*. >=20 >>=20 >=20 >> [...] >=20 >>=20 >=20 >>> In the terminology section, the OBU term is mentioned to be defined >=20 >>=20 >=20 >>> outside the IETF. This is fine, but we have to provide a reference. >=20 >>=20 >=20 >>> And even with that, it would not harm to include some short >=20 >>> definition >=20 >>=20 >=20 >>> to provide context. The RSU term is also defined outside the IETF=20 >>> and >=20 >>=20 >=20 >>> there is quite a lot of text provided (I think the relevant part is >=20 >>=20 >=20 >>> the last sentence, the one starting with "The difference = between...").=20 >=20 >>=20 >=20 >>> Both terms should be handled in the same way. >=20 >>=20 >=20 >>>=20 >=20 >>=20 >=20 >>> *[Fygs: The**definitions**was issued by the FCC 20 years ago. I=20 >>> have >=20 >>=20 >=20 >>> already provided that information**and references multiple >=20 >>=20 >=20 >>> times.]*** >=20 >>=20 >=20 >> The problem with the FCC definition of OBU is that it has no >=20 >> relationship to IP. Worse, that FCC definition has no indication=20 >> that >=20 >> it MAY use IP somehow. And here we say that all OBUs must use IP. =20 >> Do >=20 >> you see what I mean? >=20 >>=20 >=20 >> Do you think FCC will mind if we use the term OBU in this draft to >=20 >> mean something else? I, and a colleague, think that FCC would not = mind. >=20 >>=20 >=20 >> Alex >=20 >>=20 >=20 >> _______________________________________________ >=20 >>=20 >=20 >> its mailing list >=20 >>=20 >=20 >>its@ietf.org > >=20 >>=20 >=20 >>https://www.ietf.org/mailman/listinfo/its >=20 >> >=20 ------=_NextPart_000_000F_01D39EC7.CD042DC0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable FW: [ipwave] Shepherd review of = draft-ietf-ipwave-ipv6-over-80211ocb-12

" So, in order to define OBU in terms of DSRCS one has to = define first DSRCS, all while caring to avoid loops.  I think it = can become too lengthy."

-       Dedicated Short-Range = Communications Services (DSRCS). - The use of radio = techniques to transfer data over short = distances between roadside and mobile

      units, between mobile units, and = between portable and mobile units to perform operations related to the = improvement of traffic flow, traffic safety,

      and other = intelligent transportation service applications in a variety of environments. DSRCS systems = may also transmit status and = instructional

      messages = related to the units involved. [ Ref. 47 CFR 90.7 =E2=80=93 Definitions]

-----Original = Message-----
From: Alexandre Petrescu [mailto:alexandre.petrescu@gm= ail.com]
Sent: Monday, February 05, 2018 10:41 AM
To: Fran=C3=A7ois Simon <fygsimon@gmail.com>
Cc: its@ietf.org
Subject: Re: [ipwave] Shepherd review of = draft-ietf-ipwave-ipv6-over-80211ocb-12

Le 05/02/2018 = =C3=A0 16:10, Fran=C3=A7ois Simon a =C3=A9crit=C2=A0:

> = /"//Is DSRCS a typo? (correct DSRC).//"///

> =

> -// No = typo. DSRCS stands for =E2=80=9CDedicated Short Range Communication = Service=E2=80=9D

So, in order to = define OBU in terms of DSRCS one has to define first DSRCS, all while = caring to avoid loops.  I think it can become too = lengthy.

Alex

> =

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

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

> Sent: = Sunday, February 04, 2018 11:08 AM

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

> = Cc: its@ietf.org

> Subject: = Re: [ipwave] Shepherd review of

> = draft-ietf-ipwave-ipv6-over-80211ocb-12

> =

> I am = adding this OBU ref for reference but I have a = question:

> =

> Le = 02/02/2018 =C3=A0 11:23, Fran=C3=A7ois Simon a = =C3=A9crit=C2=A0:

> =

> = [...]

> =

>> = /On-Board unit (OBU). An On-Board Unit is a DSRCS transceiver that = is

> =

> Is DSRCS a = typo? (correct DSRC).

> =

> = Alex

> =

>> = 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. The OBUs receive and contend for = time

> =

>> to = transmit on one or more radio frequency (RF) channels. Except =

>> = where

> =

>> = specifically excluded, OBU operation is permitted wherever = vehicle

> =

>> = operation or human passage is permitted. The OBUs mounted in = vehicles

> =

>> are = licensed by rule under part 95 of this chapter and = communicate

> =

>> with = Roadside Units (RSUs) and other OBUs. Portable OBUs are = also

> =

>> = licensed by rule under part 95 of this chapter. OBU operations in = the

> =

>> = Unlicensed National Information Infrastructure (UNII) Bands follow =

>> = the

> =

>> rules = in those bands./- [CFR 90.7 - Definitions] - October = 2010

> =

>> =

> =

>> = *IPWAVE Issue***

> =

>> =

> =

>> = **

> =

>> =

> =

>> = /=E2=80=9CThe problem with the FCC definition of OBU is that it has = no

> =

>> = relationship to IP.=C2=A0 Worse, that FCC definition has no indication =

>> = that

> =

>> it MAY = use IP somehow.=C2=A0 And here we say that all OBUs must use IP.=C2=A0 =

>> = Do

> =

>> you = see what I mean?=E2=80=9D///

> =

>> =

> =

>> = //

> =

>> =

> =

>> = Correct; the OBU has no relationship with IP and is not intended to. =

> =

>> IP is = a network protocol.=C2=A0 If an On-Board Unit (OBU) device = is

> =

>> = required to exchange IP, it needs to be dealt in protocol(s) = and/or

> =

>> = Management in higher layers similar to WAVE within the On-Board = Equipment (OBE) .

> =

>> =

> =

>> = /=E2=80=9CDo you think FCC will mind if we use the term OBU in this = draft to

> =

>> mean = something else?=C2=A0 I, and a colleague, think that FCC would = not

> =

>> = mind.=E2=80=9D///

> =

>> =

> =

>> = //

> =

>> =

> =

>> = Depending of the reader. If one is familiar with DSRC, OBU and RSU = as

> =

>> = defined by FCC will come in mind. As far as I know, = =E2=80=9COBU=E2=80=9D and =E2=80=9CRSU=E2=80=9D

> =

>> are = not registered and could be used for other definitions = (something

> =

>> = like

> =

>> = =E2=80=9CATM=E2=80=9D: Asynchronous Transfer Mode and Automatic Teller = Machine=F0=9F=98=8A). My

> =

>> = suggestion to the IPWAVE team is to use =E2=80=9COBE and = RSE=E2=80=9D.

> =

>> =

> =

>> This = is my personal view as I donot represent any involved interest.  =

> =

>> If any = one has questions, let me know.

> =

>> =

> =

>> = Francois Simon

> =

>> =

> =

>> Lojik = Technologies

> =

>> =

> =

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

> =

>> =

> =

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

> =

>> = Petrescu

> =

>> =

> =

>> Sent: = Monday, January 29, 2018 10:08 AM

> =

>> =

> =

>> = To:its@ietf.org<mailto:its@ietf.org>

> =

>> =

> =

>> = Subject: Re: [ipwave] Shepherd review of

> =

>> = draft-ietf-ipwave-ipv6-over-80211ocb-12

> =

>> =

> =

>> =

> =

>> =

> =

>> Le = 29/01/2018 =C3=A0 15:52, Fran=C3=A7ois Simon a =C3=A9crit = :

> =

>> =

> =

>>> My = comments arewithin the text*[Fygs.......]*.

> =

>> =

> =

>> = [...]

> =

>> =

> =

>>> In = the terminology section, the OBU term is mentioned to be = defined

> =

>> =

> =

>>> = outside the IETF. This is fine, but we have to provide a = reference.

> =

>> =

> =

>>> = And even with that, it would not harm to include some = short

> =

>>> = definition

> =

>> =

> =

>>> to = provide context. The RSU term is also defined outside the IETF =

>>> = and

> =

>> =

> =

>>> = there is quite a lot of text provided (I think the relevant part = is

> =

>> =

> =

>>> = the last sentence, the one starting with "The difference = between...").

> =

>> =

> =

>>> = Both terms should be handled in the same way.

> =

>> =

> =

>>> =

> =

>> =

> =

>>> = *[Fygs: The**definitions**was issued by the FCC 20 years ago.=C2=A0 I =

>>> = have

> =

>> =

> =

>>> = already provided that information**and references = multiple

> =

>> =

> =

>>> = times.]***

> =

>> =

> =

>> The = problem with the FCC definition of OBU is that it has = no

> =

>> = relationship to IP.=C2=A0 Worse, that FCC definition has no indication =

>> = that

> =

>> it MAY = use IP somehow.=C2=A0 And here we say that all OBUs must use IP.=C2=A0 =

>> = Do

> =

>> you = see what I mean?

> =

>> =

> =

>> Do you = think FCC will mind if we use the term OBU in this draft = to

> =

>> mean = something else?=C2=A0 I, and a colleague, think that FCC would not = mind.

> =

>> =

> =

>> = Alex

> =

>> =

> =

>> = _______________________________________________

> =

>> =

> =

>> its = mailing list

> =

>> =

> =

>>its@ietf.org<mailto:its@ietf.org>

> =

>> =

> =

>>https://www.ietf.org/mailman/listinfo/its<= SPAN LANG=3D"en-us">

> =

>>

>

------=_NextPart_000_000F_01D39EC7.CD042DC0-- From nobody Mon Feb 5 21:08:22 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7761200C1 for ; Mon, 5 Feb 2018 21:08:21 -0800 (PST) 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 GhliZdrq2rvL for ; Mon, 5 Feb 2018 21:08:19 -0800 (PST) Received: from resqmta-po-09v.sys.comcast.net (resqmta-po-09v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:168]) (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 7A52C126C89 for ; Mon, 5 Feb 2018 21:08:19 -0800 (PST) Received: from resomta-po-11v.sys.comcast.net ([96.114.154.235]) by resqmta-po-09v.sys.comcast.net with ESMTP id ivUMeJmRgb70rivUQeZmUS; Tue, 06 Feb 2018 05:08:18 +0000 Received: from [IPv6:2602:306:35a4:2190:f132:c1f0:f468:f63d] ([IPv6:2602:306:35a4:2190:f132:c1f0:f468:f63d]) by resomta-po-11v.sys.comcast.net with SMTP id ivU8eCvM8HPexivUDeX5pI; Tue, 06 Feb 2018 05:08:16 +0000 From: tony.li@tony.li Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_70E79036-AD56-47D1-A167-AF998D2B7A4C" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Mon, 5 Feb 2018 21:07:59 -0800 In-Reply-To: <03D53A26DF734C8EA6F81F64D9FE9C5A@SRA6> Cc: =?utf-8?Q?Fran=C3=A7ois_Simon?= , Alexandre Petrescu , its@ietf.org To: dickroy@alum.mit.edu References: <1517217856.4315.32.camel@it.uc3m.es> <003c01d39e2d$4dfadf00$e9f09d00$@gmail.com> <2C80DD5A-743B-4429-B8B7-0DB809375144@tony.li> <2CB46182-B481-4E77-AEE9-C2392B5D6AEC@tony.li> <03D53A26DF734C8EA6F81F64D9FE9C5A@SRA6> X-Mailer: Apple Mail (2.3445.5.20) X-CMAE-Envelope: MS4wfJKQVLGImTq9UprJ1i6LMJS1M5HxFGDaeqbebg476JYYIVyxjV/Oi8wCpZ89mA9/SiWGUa+nLhp27gPnoVMJami54v9gcMkLg2CGWk+uqNLnTqrAmU/l V7eDUTnMFJ+gnmbIpbyqqHSz5Uf/Ou9+fD8dKKEAq7CqalEus2vzckNP0KoXqv+ICQze12vx+IKJeMgjbMjl9+mk6OesWTycadKWW+V2yL9CAx6bzUzhrS86 rYwqHGjSOeo00JyivCxABt/3fAXZq9ekWd8EEU1g8rsKkBEyMiqYZ43A5NULDISH Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 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, 06 Feb 2018 05:08:21 -0000 --Apple-Mail=_70E79036-AD56-47D1-A167-AF998D2B7A4C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Dick, > What you wanna do with your OBU that is NOT IP is completely outside = of the scope of this document, working group, and mailing list. > [RR] Agreed. I=E2=80=99m just looking to make sure that the = =E2=80=9Crequirements on OBUs=E2=80=9D coming from the IETF are = conditioned on the use of IP and 802.11 5.9GHz. =20 I don=E2=80=99t think that there are any requirements that the IETF can = place on an OBU at all. Obviously, they should only apply to IP-OBUs. > [RR] I suspect even RFC 2119 allows for conditionally mandatory = requirements such as =E2=80=9Cwhen A is true, then B shall be =E2=80=A6=E2= =80=9D. =20 True, but there=E2=80=99s no qualification necessary here. The default = MTU for 802.11-OCB should be 1500. > =20 > The default 1500 byte MTU is pretty much a necessity for = inter-operation with the rest of the Internet.=20 > [RR] By Internet, I assume you mean 802.3 (bridged ) LANs (aka = ethernet), and yes, such LANs dominate the Internet landscape.=20 Not just those, but all other media that we use, admittedly in rapidly = declining population, but it include HFC, SONET, ATM, FR, FDDI, =E2=80=A6.= (Yes, I=E2=80=99m dating myself). > Dissimilar MTUs on the same media cause all sorts of black-hole = problems.=20 > [RR] Not sure what you mean by =E2=80=9Csame medium=E2=80=9D (media is = plural). I=E2=80=99m guessing the point was that problems occur when = the path between source and destination contains links with (wildly) = different MTUs which most people would agree with. =20 The big problem is hosts that are prepared to only receive packets at a = smaller MTU when the transmitter is configured for a larger MTU. The = receiver simply has no buffer adequate and ends up dropping frames. > The best solution is to simply start everyone off at 1500. > [RR] Agreed, assuming that at some point an 802.3 LAN will be part of = the transmission infrastructure, and that=E2=80=99s a real good bet most = of the time. =20 P =3D 0.99999 Tony --Apple-Mail=_70E79036-AD56-47D1-A167-AF998D2B7A4C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Hi Dick,


What you wanna do = with your OBU that is NOT IP is completely outside of the scope of this = document, working group, and mailing list.
[RR]= Agreed. I=E2=80=99m just looking to make sure that the =E2=80=9Crequireme= nts on OBUs=E2=80=9D coming from the IETF are conditioned on the use of = IP and 802.11 5.9GHz.    


I don=E2=80=99= t think that there are any requirements that the IETF can place on an = OBU at all. Obviously, they should only apply to IP-OBUs.

[RR] I suspect even RFC 2119 = allows for conditionally mandatory requirements such as =E2=80=9Cwhen A = is true, then B shall be =E2=80=A6=E2=80=9D.  =  


True, but = there=E2=80=99s no qualification necessary here.  The default MTU = for 802.11-OCB should be 1500.


 
The = default 1500 byte MTU is pretty much a necessity for inter-operation = with the rest of the Internet. 
[RR] By Internet, I assume you mean 802.3 (bridged ) LANs = (aka ethernet), and yes, such LANs dominate the Internet landscape. 
<= /div>


Not just those, but all = other media that we use, admittedly in rapidly declining population, but = it include HFC, SONET, ATM, FR, FDDI, =E2=80=A6.  (Yes, I=E2=80=99m = dating myself).


Dissimilar MTUs on the same media cause all sorts of = black-hole problems. 
[RR]= Not sure what you mean by =E2=80=9Csame medium=E2=80=9D (media is = plural).  I=E2=80=99m guessing the point was that problems occur = when the path between source and destination contains links with = (wildly) different MTUs which most people would agree with. =  


The big = problem is hosts that are prepared to only receive packets at a smaller = MTU when the transmitter is configured for a larger MTU.  The = receiver simply has no buffer adequate and ends up dropping = frames.


The best solution = is to simply start everyone off at 1500.
[RR]= Agreed, assuming that at some point an 802.3 LAN will be part of the = transmission infrastructure, and that=E2=80=99s a real good bet most of = the time.  
=

P =3D 0.99999

Tony


= --Apple-Mail=_70E79036-AD56-47D1-A167-AF998D2B7A4C-- From nobody Mon Feb 5 23:30:39 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B86AF126CD6 for ; Mon, 5 Feb 2018 23:30:38 -0800 (PST) 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 lv_DpAHZX_fm for ; Mon, 5 Feb 2018 23:30:37 -0800 (PST) Received: from mail-ot0-x22c.google.com (mail-ot0-x22c.google.com [IPv6:2607:f8b0:4003:c0f::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 D890B120727 for ; Mon, 5 Feb 2018 23:30:36 -0800 (PST) Received: by mail-ot0-x22c.google.com with SMTP id r23so852495ote.8 for ; Mon, 05 Feb 2018 23:30:36 -0800 (PST) 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=BlojuBeBxgQGd1IG/lSdiNOaUgYLe34AcJfiBIAcY98=; b=kyr5zHS2LjjFxjjAiHn1GKjVBr3gBRCjcuKu3crv7Mid7qOuj2/jO5XJUUevNCRU8K rcsNHr/4TCJgYSkWuMiSsiqbMgkJXgwL21c1lsUoC/k7j6DrcrPn9Cb9nSwjanbJyJYG RfXRMmbdHYX5sKfn0La1tauZkAk6dWuikJHrwibUAMZk9sxYLELXQgwSdrpMzUg1oiSp pqIZF709mFiGgGwZOr55qvR/q6CfZ71PzbhCcKA1O88nVbzu/bWthusKw8jOJYu8rCqf RWBuSpWL5HbT0W+rm6890VoMkF/9s41mrFfrtjx9rW2SKVSS8V5UXSrKrmlI4cWXF48t v5Gg== 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=BlojuBeBxgQGd1IG/lSdiNOaUgYLe34AcJfiBIAcY98=; b=eDDeRVm0UjVJfGMvsHtAOCaeWCwZJWJws5yJddbE7tilOqSRgB1UjebSFIqc0JSNzw +nWUNrXF70hfaqNDUjkXP0DeBxis6KYLaYJshuOISJZBpbcsRvZcUnY/RiQQF4q2aMzh Ee21lVSiAe/iHFb/9A2D/QmTSJP/SGRx6Xv7I9IaATXUYO/5QWTH8Ea8DjIZV8nyoIcN Tj4kAebItlj88kC8aPDQauwQtKjfENnvJYZkTUSGXMxHbdBSisTWuOoZUrW261npd8+/ i9t7ZGCjEygXTfFBRIehUjZPQKciuJE2QVFSWyDMBidpI4SSdK+u5grzOV/lN2ysXBgJ R8yw== X-Gm-Message-State: APf1xPA9Nbb+HsZ2TTACXM4bGbZAbMi5GGenqKRHo3HS4Ac+0jRQHTRl jzezE6wYGNw+AfZYDlCK5sxLVyQSFzdK6Dx12iI= X-Google-Smtp-Source: AH8x225S0NjXowMI9mQ8aRLgUgmEtXI+aM0Ik587btHij2eXw7meZ3Byss35+WGGdPUxfe3t5k9/ApP6mEi+YMRLcW8= X-Received: by 10.157.88.45 with SMTP id r45mr939436oth.111.1517902236167; Mon, 05 Feb 2018 23:30:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.9.153 with HTTP; Mon, 5 Feb 2018 23:30:35 -0800 (PST) In-Reply-To: <2CB46182-B481-4E77-AEE9-C2392B5D6AEC@tony.li> References: <1517217856.4315.32.camel@it.uc3m.es> <003c01d39e2d$4dfadf00$e9f09d00$@gmail.com> <2C80DD5A-743B-4429-B8B7-0DB809375144@tony.li> <2CB46182-B481-4E77-AEE9-C2392B5D6AEC@tony.li> From: Abdussalam Baryun Date: Tue, 6 Feb 2018 09:30:35 +0200 Message-ID: To: its Cc: Richard Roy , =?UTF-8?Q?Fran=C3=A7ois_Simon?= , Alexandre Petrescu Content-Type: multipart/alternative; boundary="f4030435532497317605648627d1" Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 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, 06 Feb 2018 07:30:38 -0000 --f4030435532497317605648627d1 Content-Type: text/plain; charset="UTF-8" On Tue, Feb 6, 2018 at 3:13 AM, wrote: > > Hi Dick, > > * > The default MTU for IP packets on 802.11-OCB MUST be 1500 octets.* > - The MTU text currently says: > The default MTU for IP packets on > 802.11-OCB is 1500 octets. *[Fygs: IEEE **802.11 OCB - **MSDU size 2304]* > > > Be that as it may, we really need 802.11-OCB to have an MTU of 1500. > *[RR] Not true. You may want to require it when using 802.11 as a first > hop on an ethernet LAN, however no such requirement is necessary for > example when broadcasting BSMs or SPaT/MAP ADUs. * > > > > AFAIK, those have nothing to do with IP. What you wanna do with your OBU > that is NOT IP is completely outside of the scope of this document, working > group, and mailing list. > I don't agree to use 'out of scope', it was used before many times in this list, and it is not true, I asked the WG chair and no respond, even the AD did not answer. I believe that said that there was NO REQUIREMENT, so the respond needs to say there is a requirement because ,,,,,,,,,,,,,,,,,,(your reason ),,,,,,, but you want to use the words ' OUT OF SCOPE', as some used before which was not helpful in discussions, AB --f4030435532497317605648627d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Feb 6, 2018 at 3:13 AM, <tony.li@tony.li> wrote:<= br>

Hi Dick,

=C2=A0> The default MTU for IP packets on 802.11-OCB MUST be = 1500 octets.
= -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= The MTU text cur= rently says:=C2=A0> The default MTU for IP packets on 802.11-OCB is 1500 octets.=C2=A0[Fygs: IEEE=C2= =A0802.11 OCB -=C2=A0MSDU size 2304]
=C2= =A0
=C2=A0
Be that as it may, we= really need 802.11-OCB to have an MTU of 1500.=C2=A0<= /font>
[RR] Not true. You may want to require it wh= en using 802.11 as a first hop on an ethernet LAN, however no such requirem= ent is necessary for example when broadcasting BSMs or SPaT/MAP ADUs.=C2=A0<= /font>
<= /div>


AFAIK, th= ose have nothing to do with IP.=C2=A0 What you wanna do with your OBU that = is NOT IP is completely outside of the scope of this document, working grou= p, and mailing list.

I do= n't agree to=C2=A0use 'out of scope', it was used before many t= imes in this list, and it is not true, I asked the WG chair and no respond,= even the AD did not answer. I believe that said that there was NO REQUIREM= ENT, so the respond needs to say there is a requirement because ,,,,,,,,,,,= ,,,,,,,(your reason ),,,,,,, but you want to use the words ' OUT OF SCO= PE', as some used before which was not helpful in discussions,

AB



--f4030435532497317605648627d1-- From nobody Mon Feb 5 23:38:34 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21901126CD6 for ; Mon, 5 Feb 2018 23:38:33 -0800 (PST) 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 5VPzs7fdITsw for ; Mon, 5 Feb 2018 23:38:31 -0800 (PST) Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15E9F120727 for ; Mon, 5 Feb 2018 23:38:31 -0800 (PST) Received: by mail-ot0-x229.google.com with SMTP id a7so866445otk.9 for ; Mon, 05 Feb 2018 23:38:31 -0800 (PST) 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=HUmKiCuU/zFQt5PgnUf5zC9GGxt5koCvE1ZWNuNqkig=; b=pSh+VBzRHdQQm2l572We0ejC/7Xm5dySDQnIdwvHq3nIBJPSU66pZ803AsW3iOlD8w 2nANV5Al8WR9APsqCTg/32fNdw4m6yrHfjIC3rfwSfQ1No2nzaEMbeWpDiYD0ew3tHKk iJagot8Wfr4DOoEtlh4TzRTivsn/ofRJsFMNFsv/gfi8Istz9LAFV8DypcsWs8BLy0bT Oxe6s/StnSHqxTUYB2VVCYXINOX5TbUGpiL5tmkx6QGPO6GleLA9HUk80f1FK4IfeegV 03rYOU/++ipgW4ymLnm5yAW3IhV8y1MqA/BGxAN1et7TBeWq9HQLKqmGcXgQO5BGknYm F+Mw== 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=HUmKiCuU/zFQt5PgnUf5zC9GGxt5koCvE1ZWNuNqkig=; b=htgAeApjw2Xv6mXxLm/dG22fsPWvZlQKleYKO+sdIZ/CjbFumc+pQ8j8TbxTYDrurs lciiZfABCR7AxmLDxUXUTrjlZRUgIAQwW/5jpcZ34oTD2Se+mnGTefkIJZL27ClZlIKp gQmdnTdV2098S+6ukhKHPH7FvDQ90bAle89oOm7BTjFiSchZXR0O35IL53OMGqgHbQwG wXRLYQ2e2637QNG+ibj8ivAQKbru/cN4zHea11xI5V+nBEoLq4mZFR0UAtDe0cdRQTHd iDgaR4bBzgxevzzIAfdPhlJB3bORR+CAblVfolkK/9gZBLYtxjdu8+uUItvL1GAPrhwa iRxg== X-Gm-Message-State: APf1xPDb/1hqVEzn59RuGNLi2zQsPzH+aGJF2zwrx0y4P9GKyVWQWnXD Ir52JEaYdv4E2LBmM0aky3bbUy2JRjXOUE0Ez4M= X-Google-Smtp-Source: AH8x227JAnisgLPJcCEq8xd2gB3MtjdtSxBUFMRqM+F129XxFTF8kQXiOJnxQwMLYXh3PvTxbRCHsD6OFVAhf1fb32M= X-Received: by 10.157.114.157 with SMTP id t29mr1159977otj.252.1517902710549; Mon, 05 Feb 2018 23:38:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.9.153 with HTTP; Mon, 5 Feb 2018 23:38:30 -0800 (PST) In-Reply-To: References: <1517217856.4315.32.camel@it.uc3m.es> <003c01d39e2d$4dfadf00$e9f09d00$@gmail.com> <2C80DD5A-743B-4429-B8B7-0DB809375144@tony.li> <2CB46182-B481-4E77-AEE9-C2392B5D6AEC@tony.li> <03D53A26DF734C8EA6F81F64D9FE9C5A@SRA6> From: Abdussalam Baryun Date: Tue, 6 Feb 2018 09:38:30 +0200 Message-ID: To: tony.li@tony.li Cc: Richard Roy , =?UTF-8?Q?Fran=C3=A7ois_Simon?= , Alexandre Petrescu , its Content-Type: multipart/alternative; boundary="f403045d9562ddb1df056486436d" Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 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, 06 Feb 2018 07:38:33 -0000 --f403045d9562ddb1df056486436d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 6, 2018 at 7:07 AM, wrote: > > Hi Dick, > > > What you wanna do with your OBU that is NOT IP is completely outside of > the scope of this document, working group, and mailing list. > *[RR] Agreed. I=E2=80=99m just looking to make sure that the =E2=80=9Creq= uirements on > OBUs=E2=80=9D coming from the IETF are conditioned on the use of IP and 8= 02.11 > 5.9GHz. * > > > > I don=E2=80=99t think that there are any requirements that the IETF can p= lace on > an OBU at all. Obviously, they should only apply to IP-OBUs. > > *[RR] I suspect even RFC 2119 allows for conditionally mandatory > requirements such as =E2=80=9Cwhen A is true, then B shall be =E2=80=A6= =E2=80=9D. * > > > > True, but there=E2=80=99s no qualification necessary here. The default M= TU for > 802.11-OCB should be 1500. > > > > The default 1500 byte MTU is pretty much a necessity for inter-operation > with the rest of the Internet. > *[RR] By Internet, I assume you mean 802.3 (bridged ) LANs (aka ethernet)= , > and yes, such LANs dominate the Internet landscape. * > > > > Not just those, but all other media that we use, admittedly in rapidly > declining population, but it include HFC, SONET, ATM, FR, FDDI, =E2=80=A6= . (Yes, > I=E2=80=99m dating myself). > > > Dissimilar MTUs on the same media cause all sorts of black-hole problems. > *[RR] Not sure what you mean by =E2=80=9Csame medium=E2=80=9D (media is p= lural). I=E2=80=99m > guessing the point was that problems occur when the path between source a= nd > destination contains links with (wildly) different MTUs which most people > would agree with. * > > > > The big problem is hosts that are prepared to only receive packets at a > smaller MTU when the transmitter is configured for a larger MTU. The > receiver simply has no buffer adequate and ends up dropping frames. > > > The best solution is to simply start everyone off at 1500. > *[RR] Agreed, assuming that at some point an 802.3 LAN will be part of th= e > transmission infrastructure, and that=E2=80=99s a real good bet most of t= he time. * > > If that is the assumption, then the WG MUST write it into the draft, it is an important assumption for such requirement. I preferred no such assumption, but some want the easy way. AB --f403045d9562ddb1df056486436d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Feb 6, 2018 at 7:07 AM, <tony.li@tony.li> wrote:<= br>

Hi Dick,


= =
What you wanna do with your = OBU that is NOT IP is completely outside of the scope of this document, wor= king group, and mailing list.
[RR] Agreed. I=E2=80=99m just looking to make sure that the =E2=80=9Cr= equirements on OBUs=E2=80=9D coming from the IETF are conditioned on the us= e of IP and 802.11 5.9GHz.=C2=A0 =C2=A0=C2=A0


I don=E2=80=99t thin= k that there are any requirements that the IETF can place on an OBU at all.= Obviously, they should only apply to IP-OBUs.

=
[RR] I suspect even RFC 2119 allows for condition= ally mandatory requirements such as =E2=80=9Cwhen A is true, then B shall b= e =E2=80=A6=E2=80=9D.=C2=A0 =C2=A0


True, but there=E2=80=99s no q= ualification necessary here.=C2=A0 The default MTU for 802.11-OCB should be= 1500.


=C2=A0
The default 1500 byte MTU is pretty much a necessity for inter= -operation with the rest of the Internet.=C2=A0
[RR] By Internet, I assume you mean 802.3 (bridged ) LANs (aka ethernet), = and yes, such LANs dominate the Internet landscape.=C2=A0


Not jus= t those, but all other media that we use, admittedly in rapidly declining p= opulation, but it include HFC, SONET, ATM, FR, FDDI, =E2=80=A6. =C2=A0(Yes,= I=E2=80=99m dating myself).


Dissimilar MTUs on the same media cause all sorts of black-ho= le problems.=C2=A0
[RR] Not sure what you mean= by =E2=80=9Csame medium=E2=80=9D (media is plural).=C2=A0 I=E2=80=99m gues= sing the point was that problems occur when the path between source and des= tination contains links with (wildly) different MTUs which most people woul= d agree with. =C2=A0


The big problem is hosts that are p= repared to only receive packets at a smaller MTU when the transmitter is co= nfigured for a larger MTU.=C2=A0 The receiver simply has no buffer adequate= and ends up dropping frames.


The best solution = is to simply start everyone off at 1500.
<= /span>
[RR] Agreed, assuming that at some point an 802.3 LAN will = be part of the transmission infrastructure, and that=E2=80=99s a real good = bet most of the time.=C2=A0=C2=A0

If that is the assumption, t= hen the WG MUST write it into the draft, it is an important assumption for = such requirement. I preferred no such assumption, but some want the easy wa= y.

AB
--f403045d9562ddb1df056486436d-- From nobody Tue Feb 6 02:21:44 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D597D129516 for ; Tue, 6 Feb 2018 02:21:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.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, 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 (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 Setx7_mNr-tv for ; Tue, 6 Feb 2018 02:21:39 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C4201289B0 for ; Tue, 6 Feb 2018 02:21:39 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id c82so1600158qka.0 for ; Tue, 06 Feb 2018 02:21:39 -0800 (PST) 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:thread-index:content-language; bh=GskSDoNC6F23NGwHSNQNU4+d7Cs40aZdYTBynqYVSm4=; b=RKd6PI6eBA0GmhFDjqd6cNeoz4bDhkw7z6R9+bAgEdKJWnfPk+/6yyTrcp/B1YrZgd o5h30X7UclcVGtqe1FPVJIZpjHdumjwVRS8kd6GeGdAQhygXnhechkqlvEetv9yGMiI8 6gyRozqhsFNF3SJAUS72fslMxQ9qF/D9KUTQ2nYFTKF5Kuc8OCOhnL0y9uYnT04cftcx 0XX8utMCqRonzuhXHZg8wFIg/ILqx2184qyLb3l2q42zGMKNTO7KHBjUOHBXYRZp1+sp NzJzLMTpq15xBE2Prk7Q7aingrPKqyaSC3SM3abzgIAoucAbrYQRauis+H0twPezT4Ad HFag== 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:thread-index:content-language; bh=GskSDoNC6F23NGwHSNQNU4+d7Cs40aZdYTBynqYVSm4=; b=cSiXHvQouPQzp3Zo8EHlvTzJJ/nvHeM2KQQat0Y19N/3WMT84g80cByv+91uNyqV3g M9CWAHS49++Le7uipluZeEUY7+S9PhpS5/BGTMSIEPOzOekk6qF21paHvzJCMNwfh6sU j/2q5aPNx+RB6TVPPpBTVcmuT7ZfFevSPLDnYFUxMXbpjzMeFuJHZ8bilioWtEiwtKxG ZYJtMT52duZ+3fa4a6DeYpEfTsRiXxlJ+NqRKFqOw24UY4gYsmDvDgbsX21i4aN56qrT ZnpIu5WBU+Zjo1Ex67JHnA3lG0wpTy3ZSHbbE+Vj/wCEmJnZf8VvngTBX/n9ydGaZGSV Jcpg== X-Gm-Message-State: APf1xPAjzWZukiCBTp/n5AUwJEGkBMJjzumprDval9vS370jAjpouBdb RxvS6sLkTSE5LS2bXNbz8Xrb6g== X-Google-Smtp-Source: AH8x227N06r3P2No8+u/Xjs2p+VffzaRXDhTwfDMtD4ObnW2CQwqraJukg40iGn2ghLuD7aBoYR3Gw== X-Received: by 10.55.114.133 with SMTP id n127mr2683920qkc.4.1517912498121; Tue, 06 Feb 2018 02:21:38 -0800 (PST) Received: from FrancoisPC (pool-108-48-182-86.washdc.fios.verizon.net. [108.48.182.86]) by smtp.gmail.com with ESMTPSA id u1sm6865506qkh.2.2018.02.06.02.21.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Feb 2018 02:21:37 -0800 (PST) From: =?utf-8?Q?Fran=C3=A7ois_Simon?= To: "'Alexandre Petrescu'" Cc: References: <1517217856.4315.32.camel@it.uc3m.es> <006601d39910$bdcf1cf0$396d56d0$@gmail.com> <000101d39c0f$e3b32f90$ab198eb0$@gmail.com> <827a8e03-75fc-7b64-9b2a-2c2bdc0288ed@gmail.com> <004901d39e31$b6d89630$2489c290$@gmail.com> <46f0fd1b-dac5-0369-f985-b062df170cb0@gmail.com> In-Reply-To: <46f0fd1b-dac5-0369-f985-b062df170cb0@gmail.com> Date: Tue, 6 Feb 2018 05:21:37 -0500 Message-ID: <001a01d39f34$45cb6630$d1623290$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01D39F0A.5CF7A820" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQL7ISfFSBtQJ/i74DjDJlbgILh28gG4su6HASuQMD8BaTCMjwID0JIoAJWyscwBuWwN7aEDIScQ Content-Language: en-us Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 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, 06 Feb 2018 10:21:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_001B_01D39F0A.5CF7A820 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable " The protocols I have seen running on 802.11 OCB are IP, ETSI = geonetworking and BSM." - BSM is not a protocol. The Basic Safety Message (BSM) is a message = used in V2V applications and is defined in SAE j2735 standard - = =E2=80=9CDedicated Short Range Communications (DSRC) Message Set = Dictionary=E2=80=9D. -----Original Message----- From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com]=20 Sent: Monday, February 05, 2018 3:08 AM To: Fran=C3=A7ois Simon Cc: its@ietf.org Subject: Re: [ipwave] Shepherd review of = draft-ietf-ipwave-ipv6-over-80211ocb-12 Le 05/02/2018 =C3=A0 04:30, Fran=C3=A7ois Simon a =C3=A9crit : > Mr. Petrescu, >=20 > /"//I thought "DSRC" is also about Applications and Use-cases.//"/// >=20 > -// No; It is a Dedicated Short Range Communication service. =20 > IbelievethatSAE DSRCTechnical Committee (US) is defining=20 > applicationsand use-cases.// >=20 > // >=20 > =E2=80=9C/It is one thing to have no restrictions, and another thing = to reckon=20 > that IP is the networking layer.//=E2=80=9D/// >=20 > -//Layer 3 (Network Layer) Well, I am happy you list all these network layer protocols. As a side note, it would be good to let know wikipedia to refer here.=20 (there are details that situate the listed protocols to be a little bit = above network layer, not right at the network layer). Among the listed protocols the ones precisely at networking layer are:=20 IPv4, IPv6 and IPX. All the others are a little bit above. I have seen IPv4 and IPv6 over 802.11 OCB, but I have not seen IPX run = on 802.11 OCB. Stating that IPX _could_ run on 802.11 OCB is a theoretical assumption, = but in practice you never know. There is a huge difference between stating IP runs on 802.11 OCB and = stating that IPX runs on 802.11 OCB. The protocols I have seen running on 802.11 OCB are IP, ETSI = geonetworking and BSM. I think it would be good that DSRC said "802.11 OCB supports = network-layer protocols such as IP, ETSI geonetworking and BSM", rather = than saying "802.11 OCB supports _any_ network layer parotocols". > =C2=B7___CLNP_Connectionless = Networking=20 > Protocol >=20 > = =C2=B7___EGP_Ext= er > ior Gateway Protocol >=20 > =C2=B7___EIGRP_Enhanced Interior=20 > Gateway Routing Protocol >=20 > = =C2=B7___ICMP_ col>Internet > Control Message Protocol >=20 > =C2=B7___IGMP_Internet Group = Management=20 > Protocol >=20 > =C2=B7___IGRP_Interior Gateway = Routing=20 > Protocol >=20 > =C2=B7___IPv4_Internet Protocol = version=20 > 4 >=20 > =C2=B7___IPv6_Internet Protocol = version=20 > 6 >=20 > =C2=B7___IPSec_Internet Protocol=20 > Security >=20 > =C2=B7___IPX_Internetwork Packet = change >=20 > = =C2=B7___NAT_N= et > work > Address Translation >=20 > =C2=B7___Routed-SMLT_ >=20 > = =C2=B7___SCCP_ Part>Signalling > Connection Control Part >=20 > =C2=B7AppleTalk DDP >=20 > = =C2=B7___GRE_G > eneric > Routing Encapsulation for tunneling >=20 > =C2=B7___OSPF_Open Shortest Path = First >=20 > = =C2=B7___RIP_= Ro > uting > Information Protocol >=20 > = =C2=B7___HSRP_= Ho > t > Standby Router protocol >=20 > = =C2=B7___VRRP_ ocol>Virtual > Router Redundancy Protocol >=20 > =E2=80=9C/An RSU product has many transceivers inside.//=E2=80=9D/// >=20 > -// An RSE may have multiple transceivers. I think there is a huge terminology issue here. "RSE" is not used, I never heard it. Most people say "RSU" to mean a "box" whereas the FCC term RSU seem to = mean just a "transceiver". A "transceiver" is typically a "modem". Products are marketed as "RSU" and they are boxes. They have much more = inside than just the "transceiver". What could be understood as = 'transceiver' (transmitter/receiver) is the modem (modulator/demodulator) or 'baseband' processor, that sits on an = extension board that itself sits on a motherboard. There is power = supply too. All these make an "RSU". Some RSUs have even more devices = like solar panels, mechanical hooks, sophisticated antennas, EV charge = stations, LTE modems, optical backhaul and more. BEcause of this discrepancy, I prefer to forget use his "RSU" term in = this IP-over-OCB document just as for information. RAther, use the = "IP-RSU" to mean what we want it to mean. Alex >=20 > -----Original Message----- > From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] > Sent: Sunday, February 04, 2018 10:49 AM > To: Fran=C3=A7ois Simon > > Cc: its@ietf.org =20 > Subject: Re: [ipwave] Shepherd review of > draft-ietf-ipwave-ipv6-over-80211ocb-12 >=20 > Le 02/02/2018 =C3=A0 11:23, Fran=C3=A7ois Simon a =C3=A9crit : >=20 >> Mr. Petrescu, >=20 >>=20 >=20 >> Let's try one more time to clarify the FCC DSRC (in US only) issue. >=20 >>=20 >=20 >> *FCC =E2=80=93 DSRC* >=20 >>=20 >=20 >> *Background:*** >=20 >>=20 >=20 >> ** >=20 >>=20 >=20 >> -** The US Federal Communications Commission (FCC) Dedicated Short >=20 >> Range Communication (DSRC) is defined in the Code of Federal >=20 >> Regulations (CFR) >=20 >> 47 mainly Parts 90 and 95. The last update is dated October 1st,=20 >> 2010; >=20 >>=20 >=20 >> -This includes the ASTM E 2213-03 standard: =E2=80=9CStandard = Speci=EF=AC=81cation=20 >> for >=20 >> Telecommunications and Information Exchange Between Roadside and >=20 >> Vehicle Systems =E2=80=94 5 GHz Band Dedicated Short Range = Communications >=20 >> (DSRC) Medium Access Control (MAC) and Physical Layer (PHY) >=20 >> Speci=EF=AC=81cations=E2=80=9D; approved July 10, 2003. The standard = is derived from >=20 >> IEEE 802.11a and, in most part, is equivalent to IEEE 802.11 OCB. To >=20 >> date, the DSRC CFRs do not specify IEEE 802.11 OCB. >=20 >>=20 >=20 >> -The related CFRs state that DSRC shall comply with the ASTM E = 2213-03. >=20 > Thank you for the explanation. It is useful to understand that DSRC=20 > is related to ASTM E 2213-03 and that neither refers to 802.11 OCB. >=20 > I think in works related to standards and products it is advantageous=20 > if there is correlation. >=20 > For example, in an ideal world, standards talk about "A" and the=20 > regulation also about "A" and the products and sofware are also=20 > labelled "A". >=20 > In our context, software is labelled "OCB" (kernel drivers),=20 > regulation talks "DSRC" and standards "802.11p" and "802.11 OCB". >=20 >> *Overview of DSRC functions:*** >=20 >>=20 >=20 >> ** >=20 >>=20 >=20 >> The functions listed in DSRC related CFRs are, in general, specified >=20 >> in the ASTM E 2213-03 and IEEE 802.11 OCB: >=20 >>=20 >=20 >> -MAC service definition, frame format, and procedures; >=20 >>=20 >=20 >> -PHY Orthogonal frequency division multiplexing (OFDM); >=20 >>=20 >=20 >> -PHY Service Data Unit format and modulations (data rates): >=20 >>=20 >=20 >> -5.9 GHz band allocated channels, frequency, max. EIRP, and spectrum >=20 >> mask; >=20 >>=20 >=20 >> -Individual Channel use: Safety applications, non-safety=20 >> applications, >=20 >> and priorities. >=20 >>=20 >=20 >> *Protocols*** >=20 >>=20 >=20 >> ** >=20 >>=20 >=20 >> DSRC being uniquely a MAC and PHY communications service, >=20 > I thought "DSRC" is also about Applications and Use-cases. >=20 >> there here no >=20 >> restriction on Transport and Network protocols that can be used >=20 >> (except for the LCC specified by reference in IEEE 802.11 OCB). In=20 >> the >=20 >> US, the WAVE standards (IEEE 1609 series) specify these protocols=20 >> when >=20 >> using DSRC as the communication service. >=20 > It is one thing to have no restrictions, and another thing to reckon=20 > that IP is the networking layer. >=20 >>=20 >=20 >> *OBU / RSU*** >=20 >>=20 >=20 >> ** >=20 >>=20 >=20 >> The CFR (FCC) definitions are: >=20 >>=20 >=20 >> /Roadside unit (RSU). A Roadside Unit is a DSRC transceiver >=20 > Sigh, it is way different. >=20 > An RSU product has many transceivers inside. >=20 >> that is >=20 >> mounted along a road or pedestrian passageway. An RSU may also be >=20 >> mounted on a vehicle or is hand carried, but it may only operate when >=20 >> the vehicle or hand- carried unit is stationary. Furthermore, an RSU >=20 >> operating under this part is restricted to the location where it is >=20 >> licensed to operate. However, portable or hand-held RSUs are=20 >> permitted >=20 >> to operate where they do not interfere with a site-licensed = operation.=20 >=20 >> A RSU broadcasts data to OBUs or exchanges data with OBUs in its >=20 >> communications zone. An RSU also provides channel assignments and >=20 >> operating instructions to OBUs in its communications zone, when >=20 >> required./- [CFR 90.7 - Definitions] - Revised as October 2010. >=20 > I think it should be updated to refer to this document. >=20 >> /On-Board unit (OBU). An On-Board Unit is a DSRCS transceiver that is >=20 >> normally mounted in or on a vehicle, or which in some instances may=20 >> be >=20 >> a portable unit. An OBU can be operational while a vehicle or person >=20 >> is either mobile or stationary. The OBUs receive and contend for time >=20 >> to transmit on one or more radio frequency (RF) channels. Except=20 >> where >=20 >> specifically excluded, OBU operation is permitted wherever vehicle >=20 >> operation or human passage is permitted. The OBUs mounted in vehicles >=20 >> are licensed by rule under part 95 of this chapter and communicate >=20 >> with Roadside Units (RSUs) and other OBUs. Portable OBUs are also >=20 >> licensed by rule under part 95 of this chapter. OBU operations in the >=20 >> Unlicensed National Information Infrastructure (UNII) Bands follow=20 >> the >=20 >> rules in those bands./- [CFR 90.7 - Definitions] - October 2010 >=20 > Thanks for the definitions. >=20 > They are far different from what we need in this draft. >=20 > I will see the other suggestions. >=20 > Alex >=20 >>=20 >=20 >> *IPWAVE Issue*** >=20 >>=20 >=20 >> ** >=20 >>=20 >=20 >> /=E2=80=9CThe problem with the FCC definition of OBU is that it has = no >=20 >> relationship to IP. Worse, that FCC definition has no indication=20 >> that >=20 >> it MAY use IP somehow. And here we say that all OBUs must use IP. =20 >> Do >=20 >> you see what I mean?=E2=80=9D/// >=20 >>=20 >=20 >> // >=20 >>=20 >=20 >> Correct; the OBU has no relationship with IP and is not intended to.=20 >=20 >> IP is a network protocol. If an On-Board Unit (OBU) device is >=20 >> required to exchange IP, it needs to be dealt in protocol(s) and/or >=20 >> Management in higher layers similar to WAVE within the On-Board = Equipment (OBE) . >=20 >>=20 >=20 >> /=E2=80=9CDo you think FCC will mind if we use the term OBU in this = draft to >=20 >> mean something else? I, and a colleague, think that FCC would not >=20 >> mind.=E2=80=9D/// >=20 >>=20 >=20 >> // >=20 >>=20 >=20 >> Depending of the reader. If one is familiar with DSRC, OBU and RSU as >=20 >> defined by FCC will come in mind. As far as I know, = =E2=80=9COBU=E2=80=9D and =E2=80=9CRSU=E2=80=9D=20 >=20 >> are not registered and could be used for other definitions (something >=20 >> like >=20 >> =E2=80=9CATM=E2=80=9D: Asynchronous Transfer Mode and Automatic = Teller Machine=F0=9F=98=8A). My >=20 >> suggestion to the IPWAVE team is to use =E2=80=9COBE and = RSE=E2=80=9D. >=20 >>=20 >=20 >> This is my personal view as I donot represent any involved interest. = >=20 >> If any one has questions, let me know. >=20 >>=20 >=20 >> Francois Simon >=20 >>=20 >=20 >> Lojik Technologies >=20 >>=20 >=20 >> -----Original Message----- >=20 >>=20 >=20 >> From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre >=20 >> Petrescu >=20 >>=20 >=20 >> Sent: Monday, January 29, 2018 10:08 AM >=20 >>=20 >=20 >> To:its@ietf.org >=20 >>=20 >=20 >> Subject: Re: [ipwave] Shepherd review of >=20 >> draft-ietf-ipwave-ipv6-over-80211ocb-12 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >> Le 29/01/2018 =C3=A0 15:52, Fran=C3=A7ois Simon a =C3=A9crit : >=20 >>=20 >=20 >>> My comments arewithin the text*[Fygs.......]*. >=20 >>=20 >=20 >> [...] >=20 >>=20 >=20 >>> In the terminology section, the OBU term is mentioned to be defined >=20 >>=20 >=20 >>> outside the IETF. This is fine, but we have to provide a reference. >=20 >>=20 >=20 >>> And even with that, it would not harm to include some short >=20 >>> definition >=20 >>=20 >=20 >>> to provide context. The RSU term is also defined outside the IETF=20 >>> and >=20 >>=20 >=20 >>> there is quite a lot of text provided (I think the relevant part is >=20 >>=20 >=20 >>> the last sentence, the one starting with "The difference = between...").=20 >=20 >>=20 >=20 >>> Both terms should be handled in the same way. >=20 >>=20 >=20 >>>=20 >=20 >>=20 >=20 >>> *[Fygs: The**definitions**was issued by the FCC 20 years ago. I=20 >>> have >=20 >>=20 >=20 >>> already provided that information**and references multiple >=20 >>=20 >=20 >>> times.]*** >=20 >>=20 >=20 >> The problem with the FCC definition of OBU is that it has no >=20 >> relationship to IP. Worse, that FCC definition has no indication=20 >> that >=20 >> it MAY use IP somehow. And here we say that all OBUs must use IP. =20 >> Do >=20 >> you see what I mean? >=20 >>=20 >=20 >> Do you think FCC will mind if we use the term OBU in this draft to >=20 >> mean something else? I, and a colleague, think that FCC would not = mind. >=20 >>=20 >=20 >> Alex >=20 >>=20 >=20 >> _______________________________________________ >=20 >>=20 >=20 >> its mailing list >=20 >>=20 >=20 >>its@ietf.org > >=20 >>=20 >=20 >>https://www.ietf.org/mailman/listinfo/its >=20 >> >=20 ------=_NextPart_000_001B_01D39F0A.5CF7A820 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable RE: [ipwave] Shepherd review of = draft-ietf-ipwave-ipv6-over-80211ocb-12

" The protocols I have seen running on 802.11 OCB are IP, = ETSI geonetworking and BSM."

-       BSM is = not a = protocol. The Basic Safety Message (BSM) is a message used in V2V applications = and is defined = in SAE j2735 standard -   = =E2=80=9CDedicated Short Range Communications (DSRC) Message Set = Dictionary=E2=80=9D.

-----Original = Message-----
From: Alexandre Petrescu [mailto:alexandre.petrescu@gm= ail.com]
Sent: Monday, February 05, 2018 3:08 AM
To: Fran=C3=A7ois Simon <fygsimon@gmail.com>
Cc: its@ietf.org
Subject: Re: [ipwave] Shepherd review of = draft-ietf-ipwave-ipv6-over-80211ocb-12

Le 05/02/2018 = =C3=A0 04:30, Fran=C3=A7ois Simon a =C3=A9crit=C2=A0:

> Mr. = Petrescu,

> =

> /"//I = thought "DSRC" is also about Applications and = Use-cases.//"///

> =

> -// No; It = is a Dedicated Short Range Communication service.  =

> = IbelievethatSAE DSRCTechnical Committee (US) is defining =

> = applicationsand use-cases.//

> =

> = //

> =

> = =E2=80=9C/It is one thing to have no restrictions, and another thing to = reckon

> that IP is = the networking layer.//=E2=80=9D///

> =

> -//Layer 3 = (Network Layer)

Well, I am = happy you list all these network layer protocols.

As a side note, = it would be good to let know wikipedia to refer here.

(there are = details that situate the listed protocols to be a little bit above = network layer, not right at the network layer).

Among the = listed protocols the ones precisely at networking layer are: =

IPv4, IPv6 and = IPX.  All the others are a little bit above.

I have seen = IPv4 and IPv6 over 802.11 OCB, but I have not seen IPX run on 802.11 = OCB.

Stating that = IPX _could_ run on 802.11 OCB is a theoretical assumption, but in = practice you never know.

There is a huge = difference between stating IP runs on 802.11 OCB and stating that IPX = runs on 802.11 OCB.

The protocols I = have seen running on 802.11 OCB are IP, ETSI geonetworking and = BSM.

I think it = would be good that DSRC said "802.11 OCB supports = network-layer  protocols such as IP, ETSI geonetworking and = BSM", rather than saying "802.11 OCB supports _any_ network = layer parotocols".

> = =C2=B7___CLNP_<https://en.wikipedia.org/wiki/CLNP>Connectionless Networking

> = Protocol

> =

> = =C2=B7___EGP_<https://en.wikipedia.org/wiki/Exterior_Gateway_Protocol<= /FONT>>Exter

> ior = Gateway Protocol

> =

> = =C2=B7___EIGRP_<https://en.wikipedia.org/wiki/EIGRP>Enhanced Interior

> Gateway = Routing Protocol

> =

> = =C2=B7___ICMP_<https://en.wikipedia.org/wiki/Internet_Control_Message_= Proto

> = col>Internet

> Control = Message Protocol

> =

> = =C2=B7___IGMP_<https://en.wikipedia.org/wiki/IGMP>Internet Group Management

> = Protocol

> =

> = =C2=B7___IGRP_<https://en.wikipedia.org/wiki/IGRP>Interior Gateway Routing

> = Protocol

> =

> = =C2=B7___IPv4_<https://en.wikipedia.org/wiki/IPv4>Internet Protocol version

> = 4

> =

> = =C2=B7___IPv6_<https://en.wikipedia.org/wiki/IPv6>Internet Protocol version

> = 6

> =

> = =C2=B7___IPSec_<https://en.wikipedia.org/wiki/IPSec>Internet Protocol

> = Security

> =

> = =C2=B7___IPX_<https://en.wikipedia.org/wiki/IPX>Internetwork Packet change

> =

> = =C2=B7___NAT_<https://en.wikipedia.org/wiki/Network_address_translatio= n>Net

> = work

> Address = Translation

> =

> = =C2=B7___Routed-SMLT_<https://en.wikipedia.org/wiki/R-SMLT>

> =

> = =C2=B7___SCCP_<https://en.wikipedia.org/wiki/Signalling_Connection_Con= trol_

> = Part>Signalling

> Connection = Control Part

> =

> = =C2=B7AppleTalk DDP

> =

> = =C2=B7___GRE_<https://en.wikipedia.org/wiki/Generic_Routing_Encapsulat= ion>G

> = eneric

> Routing = Encapsulation for tunneling

> =

> = =C2=B7___OSPF_<https://en.wikipedia.org/wiki/OSPF>Open Shortest Path First

> =

> = =C2=B7___RIP_<https://en.wikipedia.org/wiki/Routing_Information_Protoc= ol>Ro

> = uting

> = Information Protocol

> =

> = =C2=B7___HSRP_<https://en.wikipedia.org/wiki/Hot_Standby_Router_Protoco= l>Ho

> = t

> Standby = Router protocol

> =

> = =C2=B7___VRRP_<https://en.wikipedia.org/wiki/Virtual_Router_Redundancy= _Prot

> = ocol>Virtual

> Router = Redundancy Protocol

> =

> = =E2=80=9C/An RSU product has many transceivers = inside.//=E2=80=9D///

> =

> -// An RSE = may have multiple transceivers.

I think there = is a huge terminology issue here.

"RSE" = is not used, I never heard it.

Most people say = "RSU" to mean a "box" whereas the FCC term RSU seem = to mean just a "transceiver".  A "transceiver" = is typically a "modem".

Products are = marketed as "RSU" and they are boxes.  They have much = more inside than just the "transceiver".  What could be = understood as 'transceiver' (transmitter/receiver) is the = modem

(modulator/demodulator) or 'baseband' processor, that = sits on an extension board that itself sits on a motherboard.  = There is power supply too.  All these make an = "RSU".  Some RSUs have even more devices like solar = panels, mechanical hooks, sophisticated antennas, EV charge stations, = LTE modems, optical backhaul and more.

BEcause of this = discrepancy, I prefer to forget use his "RSU" term in this = IP-over-OCB document just as for information.  RAther, use the = "IP-RSU" to mean what we want it to mean.

Alex

> =

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

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

> Sent: = Sunday, February 04, 2018 10:49 AM

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

> = Cc: its@ietf.org

> Subject: = Re: [ipwave] Shepherd review of

> = draft-ietf-ipwave-ipv6-over-80211ocb-12

> =

> Le = 02/02/2018 =C3=A0 11:23, Fran=C3=A7ois Simon a = =C3=A9crit=C2=A0:

> =

>> Mr. = Petrescu,

> =

>> =

> =

>> Let's = try one more time to clarify the FCC DSRC (in US only) = issue.

> =

>> =

> =

>> *FCC = =E2=80=93 DSRC*

> =

>> =

> =

>> = *Background:***

> =

>> =

> =

>> = **

> =

>> =

> =

>> -** = The US Federal Communications Commission (FCC) Dedicated = Short

> =

>> Range = Communication (DSRC) is defined in the Code of Federal

> =

>> = Regulations (CFR)

> =

>> 47 = mainly Parts 90 and 95. The last update is dated October 1st, =

>> = 2010;

> =

>> =

> =

>> -This = includes the ASTM E 2213-03 standard: =E2=80=9CStandard = Speci=EF=AC=81cation

>> = for

> =

>> = Telecommunications and Information Exchange Between Roadside = and

> =

>> = Vehicle Systems =E2=80=94 5 GHz Band Dedicated Short Range = Communications

> =

>> (DSRC) = Medium Access Control (MAC) and Physical Layer (PHY)

> =

>> = Speci=EF=AC=81cations=E2=80=9D; approved July 10, 2003. The standard is = derived from

> =

>> IEEE = 802.11a and, in most part, is equivalent to IEEE 802.11 OCB. = To

> =

>> date, = the DSRC CFRs do not specify IEEE 802.11 OCB.

> =

>> =

> =

>> -The = related CFRs state that DSRC shall comply with the ASTM E = 2213-03.

> =

> Thank you = for the explanation.=C2=A0 It is useful to understand that DSRC =

> is related = to ASTM E 2213-03 and that neither refers to 802.11 = OCB.

> =

> I think in = works related to standards and products it is advantageous =

> if there = is correlation.

> =

> For = example, in an ideal world, standards talk about "A" and the =

> regulation = also about "A" and the products and sofware are also =

> labelled = "A".

> =

> In our = context, software is labelled "OCB" (kernel drivers), =

> regulation = talks "DSRC" and standards "802.11p" and = "802.11 OCB".

> =

>> = *Overview of DSRC functions:***

> =

>> =

> =

>> = **

> =

>> =

> =

>> The = functions listed in DSRC related CFRs are, in general, = specified

> =

>> in the = ASTM E 2213-03 and IEEE 802.11 OCB:

> =

>> =

> =

>> -MAC = service definition, frame format, and procedures;

> =

>> =

> =

>> -PHY = Orthogonal frequency division multiplexing (OFDM);

> =

>> =

> =

>> -PHY = Service Data Unit format and modulations (data rates):

> =

>> =

> =

>> -5.9 = GHz band allocated channels, frequency, max. EIRP, and = spectrum

> =

>> = mask;

> =

>> =

> =

>> = -Individual Channel use: Safety applications, non-safety =

>> = applications,

> =

>> and = priorities.

> =

>> =

> =

>> = *Protocols***

> =

>> =

> =

>> = **

> =

>> =

> =

>> DSRC = being uniquely a MAC and PHY communications service,

> =

> I thought = "DSRC" is also about Applications and = Use-cases.

> =

>> there = here no

> =

>> = restriction on Transport and Network protocols that can be = used

> =

>> = (except for the LCC specified by reference in IEEE 802.11 OCB). In =

>> = the

> =

>> US, = the WAVE standards (IEEE 1609 series) specify these protocols =

>> = when

> =

>> using = DSRC as the communication service.

> =

> It is one = thing to have no restrictions, and another thing to reckon =

> that IP is = the networking layer.

> =

>> =

> =

>> *OBU / = RSU***

> =

>> =

> =

>> = **

> =

>> =

> =

>> The = CFR (FCC) definitions are:

> =

>> =

> =

>> = /Roadside unit (RSU). A Roadside Unit is a DSRC = transceiver

> =

> Sigh, it = is way different.

> =

> An RSU = product has many transceivers inside.

> =

>> that = is

> =

>> = mounted along a road or pedestrian passageway. An RSU may also = be

> =

>> = mounted on a vehicle or is hand carried, but it may only operate = when

> =

>> the = vehicle or hand- carried unit is stationary. Furthermore, an = RSU

> =

>> = operating under this part is restricted to the location where it = is

> =

>> = licensed to operate. However, portable or hand-held RSUs are =

>> = permitted

> =

>> to = operate where they do not interfere with a site-licensed operation. =

> =

>> A RSU = broadcasts data to OBUs or exchanges data with OBUs in = its

> =

>> = communications zone. An RSU also provides channel assignments = and

> =

>> = operating instructions to OBUs in its communications zone, = when

> =

>> = required./- [CFR 90.7 - Definitions] - Revised as October = 2010.

> =

> I think it = should be updated to refer to this document.

> =

>> = /On-Board unit (OBU). 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. The OBUs receive and contend for = time

> =

>> to = transmit on one or more radio frequency (RF) channels. Except =

>> = where

> =

>> = specifically excluded, OBU operation is permitted wherever = vehicle

> =

>> = operation or human passage is permitted. The OBUs mounted in = vehicles

> =

>> are = licensed by rule under part 95 of this chapter and = communicate

> =

>> with = Roadside Units (RSUs) and other OBUs. Portable OBUs are = also

> =

>> = licensed by rule under part 95 of this chapter. OBU operations in = the

> =

>> = Unlicensed National Information Infrastructure (UNII) Bands follow =

>> = the

> =

>> rules = in those bands./- [CFR 90.7 - Definitions] - October = 2010

> =

> Thanks for = the definitions.

> =

> They are = far different from what we need in this draft.

> =

> I will see = the other suggestions.

> =

> = Alex

> =

>> =

> =

>> = *IPWAVE Issue***

> =

>> =

> =

>> = **

> =

>> =

> =

>> = /=E2=80=9CThe problem with the FCC definition of OBU is that it has = no

> =

>> = relationship to IP.=C2=A0 Worse, that FCC definition has no indication =

>> = that

> =

>> it MAY = use IP somehow.=C2=A0 And here we say that all OBUs must use IP.=C2=A0 =

>> = Do

> =

>> you = see what I mean?=E2=80=9D///

> =

>> =

> =

>> = //

> =

>> =

> =

>> = Correct; the OBU has no relationship with IP and is not intended to. =

> =

>> IP is = a network protocol.=C2=A0 If an On-Board Unit (OBU) device = is

> =

>> = required to exchange IP, it needs to be dealt in protocol(s) = and/or

> =

>> = Management in higher layers similar to WAVE within the On-Board = Equipment (OBE) .

> =

>> =

> =

>> = /=E2=80=9CDo you think FCC will mind if we use the term OBU in this = draft to

> =

>> mean = something else?=C2=A0 I, and a colleague, think that FCC would = not

> =

>> = mind.=E2=80=9D///

> =

>> =

> =

>> = //

> =

>> =

> =

>> = Depending of the reader. If one is familiar with DSRC, OBU and RSU = as

> =

>> = defined by FCC will come in mind. As far as I know, = =E2=80=9COBU=E2=80=9D and =E2=80=9CRSU=E2=80=9D

> =

>> are = not registered and could be used for other definitions = (something

> =

>> = like

> =

>> = =E2=80=9CATM=E2=80=9D: Asynchronous Transfer Mode and Automatic Teller = Machine=F0=9F=98=8A). My

> =

>> = suggestion to the IPWAVE team is to use =E2=80=9COBE and = RSE=E2=80=9D.

> =

>> =

> =

>> This = is my personal view as I donot represent any involved interest.  =

> =

>> If any = one has questions, let me know.

> =

>> =

> =

>> = Francois Simon

> =

>> =

> =

>> Lojik = Technologies

> =

>> =

> =

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

> =

>> =

> =

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

> =

>> = Petrescu

> =

>> =

> =

>> Sent: = Monday, January 29, 2018 10:08 AM

> =

>> =

> =

>> = To:its@ietf.org<mailto:its@ietf.org>

> =

>> =

> =

>> = Subject: Re: [ipwave] Shepherd review of

> =

>> = draft-ietf-ipwave-ipv6-over-80211ocb-12

> =

>> =

> =

>> =

> =

>> =

> =

>> Le = 29/01/2018 =C3=A0 15:52, Fran=C3=A7ois Simon a =C3=A9crit = :

> =

>> =

> =

>>> My = comments arewithin the text*[Fygs.......]*.

> =

>> =

> =

>> = [...]

> =

>> =

> =

>>> In = the terminology section, the OBU term is mentioned to be = defined

> =

>> =

> =

>>> = outside the IETF. This is fine, but we have to provide a = reference.

> =

>> =

> =

>>> = And even with that, it would not harm to include some = short

> =

>>> = definition

> =

>> =

> =

>>> to = provide context. The RSU term is also defined outside the IETF =

>>> = and

> =

>> =

> =

>>> = there is quite a lot of text provided (I think the relevant part = is

> =

>> =

> =

>>> = the last sentence, the one starting with "The difference = between...").

> =

>> =

> =

>>> = Both terms should be handled in the same way.

> =

>> =

> =

>>> =

> =

>> =

> =

>>> = *[Fygs: The**definitions**was issued by the FCC 20 years ago.=C2=A0 I =

>>> = have

> =

>> =

> =

>>> = already provided that information**and references = multiple

> =

>> =

> =

>>> = times.]***

> =

>> =

> =

>> The = problem with the FCC definition of OBU is that it has = no

> =

>> = relationship to IP.=C2=A0 Worse, that FCC definition has no indication =

>> = that

> =

>> it MAY = use IP somehow.=C2=A0 And here we say that all OBUs must use IP.=C2=A0 =

>> = Do

> =

>> you = see what I mean?

> =

>> =

> =

>> Do you = think FCC will mind if we use the term OBU in this draft = to

> =

>> mean = something else?=C2=A0 I, and a colleague, think that FCC would not = mind.

> =

>> =

> =

>> = Alex

> =

>> =

> =

>> = _______________________________________________

> =

>> =

> =

>> its = mailing list

> =

>> =

> =

>>its@ietf.org<mailto:its@ietf.org>

> =

>> =

> =

>>https://www.ietf.org/mailman/listinfo/its<= SPAN LANG=3D"en-us">

> =

>>

>

------=_NextPart_000_001B_01D39F0A.5CF7A820-- From nobody Tue Feb 6 03:47:34 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71A7912AAB6 for ; Tue, 6 Feb 2018 03:47:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.328 X-Spam-Level: X-Spam-Status: No, score=-4.328 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CBut-gKh4Mbc for ; Tue, 6 Feb 2018 03:47:28 -0800 (PST) Received: from mailout23.telekom.de (MAILOUT23.telekom.de [80.149.113.253]) (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 3A0FC1241F5 for ; Tue, 6 Feb 2018 03:47:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1517917647; x=1549453647; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=gIgTIcVnTgXyC5sYx+SjO2oUFdX75lfR7BINmckN87M=; b=Q8ETmS25HT5VGKsR6SagrPdDmGJAGbwBPyEBH13RHy/qMUcujR2Hqt8a rC83J+Pq3Zc3IM5+q/nIR/690b745VpQVpsCGHdWVRFLV3GWb34sVTDij kDRNfxb737dm5fhnDBKsDRBfLqM30UnLXsxpRS6/TsIwUGp3Mxk4+OLoA xbf8fjI8KodrnMx/I/vk/kB/RJ7WW87UoDKTO+oTEmM+Lhwp+AxDBM+h1 H/dd7WORtvf1IY56rt0/a88fFW2pxv7h80ev9W42Sxf1e//6e3Hq5aQO8 UEkCN+MQ2L6cOSvtewbHnJ+S8q8LGotv5Dyo009aQ9vMg+OE6RCgSUMEX w==; Received: from qdezc2.de.t-internal.com ([10.171.255.37]) by MAILOUT21.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Feb 2018 12:47:23 +0100 X-IronPort-AV: E=Sophos;i="5.46,468,1511823600"; d="scan'208,217";a="740927955" Received: from he105828.emea1.cds.t-internal.com ([10.169.119.31]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES256-SHA; 06 Feb 2018 12:47:23 +0100 Received: from HE105831.EMEA1.cds.t-internal.com (10.169.119.34) by HE105828.emea1.cds.t-internal.com (10.169.119.31) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 6 Feb 2018 12:47:23 +0100 Received: from HE105831.EMEA1.cds.t-internal.com ([fe80::68a7:ffa4:81be:3178]) by HE105831.emea1.cds.t-internal.com ([fe80::68a7:ffa4:81be:3178%26]) with mapi id 15.00.1347.000; Tue, 6 Feb 2018 12:47:23 +0100 From: To: , CC: Thread-Topic: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 Thread-Index: AQHTmOL4udW2ub4LKEChyUxxSy9cvaOK3vCAgAAEXoCABfntAIADf32AgADEKoCAAE1TAIABt8uAgAAoOzA= Date: Tue, 6 Feb 2018 11:47:23 +0000 Message-ID: <40618c5cbd684e4a8f7de3f2e58b9114@HE105831.emea1.cds.t-internal.com> References: <1517217856.4315.32.camel@it.uc3m.es> <006601d39910$bdcf1cf0$396d56d0$@gmail.com> <000101d39c0f$e3b32f90$ab198eb0$@gmail.com> <827a8e03-75fc-7b64-9b2a-2c2bdc0288ed@gmail.com> <004901d39e31$b6d89630$2489c290$@gmail.com> <46f0fd1b-dac5-0369-f985-b062df170cb0@gmail.com> <001a01d39f34$45cb6630$d1623290$@gmail.com> In-Reply-To: <001a01d39f34$45cb6630$d1623290$@gmail.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.17.18] Content-Type: multipart/alternative; boundary="_000_40618c5cbd684e4a8f7de3f2e58b9114HE105831emea1cdstintern_" MIME-Version: 1.0 Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 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, 06 Feb 2018 11:47:32 -0000 --_000_40618c5cbd684e4a8f7de3f2e58b9114HE105831emea1cdstintern_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQpwZXJoYXBzIHRoaXMgd2FzIGp1c3QgYSB0eXBvIG1lYW5pbmcgQmFzaWMgVHJhbnNwb3J0 IFByb3RvY29sIChCVFApIHJ1bm5pbmcgb3ZlciBnZW9uZXR3b3JraW5nIGluIEVUU0kgSVRTPw0K QmVzdCBSZWdhcmRzDQpEaXJrDQoNCkZyb206IGl0cyBbbWFpbHRvOml0cy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgRnJhbsOnb2lzIFNpbW9uDQpTZW50OiBEaWVuc3RhZywgNi4gRmVi cnVhciAyMDE4IDExOjIyDQpUbzogJ0FsZXhhbmRyZSBQZXRyZXNjdScgPGFsZXhhbmRyZS5wZXRy ZXNjdUBnbWFpbC5jb20+DQpDYzogaXRzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2lwd2F2ZV0g U2hlcGhlcmQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtaXB3YXZlLWlwdjYtb3Zlci04MDIxMW9jYi0x Mg0KDQoNCiIgVGhlIHByb3RvY29scyBJIGhhdmUgc2VlbiBydW5uaW5nIG9uIDgwMi4xMSBPQ0Ig YXJlIElQLCBFVFNJIGdlb25ldHdvcmtpbmcgYW5kIEJTTS4iDQoNCuKAoiAgICAgICBCU00gaXMg bm90IGEgcHJvdG9jb2wuIFRoZSBCYXNpYyBTYWZldHkgTWVzc2FnZSAoQlNNKSBpcyBhIG1lc3Nh Z2UgdXNlZCBpbiBWMlYgYXBwbGljYXRpb25zIGFuZCBpcyBkZWZpbmVkIGluIFNBRSBqMjczNSBz dGFuZGFyZCAtICAg4oCcRGVkaWNhdGVkIFNob3J0IFJhbmdlIENvbW11bmljYXRpb25zIChEU1JD KSBNZXNzYWdlIFNldCBEaWN0aW9uYXJ54oCdLg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogQWxleGFuZHJlIFBldHJlc2N1IFttYWlsdG86YWxleGFuZHJlLnBldHJlc2N1QGdt YWlsLmNvbV0NClNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMDUsIDIwMTggMzowOCBBTQ0KVG86IEZy YW7Dp29pcyBTaW1vbiA8Znlnc2ltb25AZ21haWwuY29tPG1haWx0bzpmeWdzaW1vbkBnbWFpbC5j b20+Pg0KQ2M6IGl0c0BpZXRmLm9yZzxtYWlsdG86aXRzQGlldGYub3JnPg0KU3ViamVjdDogUmU6 IFtpcHdhdmVdIFNoZXBoZXJkIHJldmlldyBvZiBkcmFmdC1pZXRmLWlwd2F2ZS1pcHY2LW92ZXIt ODAyMTFvY2ItMTINCg0KTGUgMDUvMDIvMjAxOCDDoCAwNDozMCwgRnJhbsOnb2lzIFNpbW9uIGEg w6ljcml0IDoNCg0KPiBNci4gUGV0cmVzY3UsDQoNCj4NCg0KPiAvIi8vSSB0aG91Z2h0ICJEU1JD IiBpcyBhbHNvIGFib3V0IEFwcGxpY2F0aW9ucyBhbmQgVXNlLWNhc2VzLi8vIi8vLw0KDQo+DQoN Cj4gLS8vIE5vOyBJdCBpcyBhIERlZGljYXRlZCBTaG9ydCBSYW5nZSBDb21tdW5pY2F0aW9uIHNl cnZpY2UuDQoNCj4gSWJlbGlldmV0aGF0U0FFIERTUkNUZWNobmljYWwgQ29tbWl0dGVlIChVUykg aXMgZGVmaW5pbmcNCg0KPiBhcHBsaWNhdGlvbnNhbmQgdXNlLWNhc2VzLi8vDQoNCj4NCg0KPiAv Lw0KDQo+DQoNCj4g4oCcL0l0IGlzIG9uZSB0aGluZyB0byBoYXZlIG5vIHJlc3RyaWN0aW9ucywg YW5kIGFub3RoZXIgdGhpbmcgdG8gcmVja29uDQoNCj4gdGhhdCBJUCBpcyB0aGUgbmV0d29ya2lu ZyBsYXllci4vL+KAnS8vLw0KDQo+DQoNCj4gLS8vTGF5ZXIgMyAoTmV0d29yayBMYXllcikNCg0K V2VsbCwgSSBhbSBoYXBweSB5b3UgbGlzdCBhbGwgdGhlc2UgbmV0d29yayBsYXllciBwcm90b2Nv bHMuDQoNCkFzIGEgc2lkZSBub3RlLCBpdCB3b3VsZCBiZSBnb29kIHRvIGxldCBrbm93IHdpa2lw ZWRpYSB0byByZWZlciBoZXJlLg0KDQoodGhlcmUgYXJlIGRldGFpbHMgdGhhdCBzaXR1YXRlIHRo ZSBsaXN0ZWQgcHJvdG9jb2xzIHRvIGJlIGEgbGl0dGxlIGJpdCBhYm92ZSBuZXR3b3JrIGxheWVy LCBub3QgcmlnaHQgYXQgdGhlIG5ldHdvcmsgbGF5ZXIpLg0KDQpBbW9uZyB0aGUgbGlzdGVkIHBy b3RvY29scyB0aGUgb25lcyBwcmVjaXNlbHkgYXQgbmV0d29ya2luZyBsYXllciBhcmU6DQoNCklQ djQsIElQdjYgYW5kIElQWC4gIEFsbCB0aGUgb3RoZXJzIGFyZSBhIGxpdHRsZSBiaXQgYWJvdmUu DQoNCkkgaGF2ZSBzZWVuIElQdjQgYW5kIElQdjYgb3ZlciA4MDIuMTEgT0NCLCBidXQgSSBoYXZl IG5vdCBzZWVuIElQWCBydW4gb24gODAyLjExIE9DQi4NCg0KU3RhdGluZyB0aGF0IElQWCBfY291 bGRfIHJ1biBvbiA4MDIuMTEgT0NCIGlzIGEgdGhlb3JldGljYWwgYXNzdW1wdGlvbiwgYnV0IGlu IHByYWN0aWNlIHlvdSBuZXZlciBrbm93Lg0KDQpUaGVyZSBpcyBhIGh1Z2UgZGlmZmVyZW5jZSBi ZXR3ZWVuIHN0YXRpbmcgSVAgcnVucyBvbiA4MDIuMTEgT0NCIGFuZCBzdGF0aW5nIHRoYXQgSVBY IHJ1bnMgb24gODAyLjExIE9DQi4NCg0KVGhlIHByb3RvY29scyBJIGhhdmUgc2VlbiBydW5uaW5n IG9uIDgwMi4xMSBPQ0IgYXJlIElQLCBFVFNJIGdlb25ldHdvcmtpbmcgYW5kIEJTTS4NCg0KSSB0 aGluayBpdCB3b3VsZCBiZSBnb29kIHRoYXQgRFNSQyBzYWlkICI4MDIuMTEgT0NCIHN1cHBvcnRz IG5ldHdvcmstbGF5ZXIgIHByb3RvY29scyBzdWNoIGFzIElQLCBFVFNJIGdlb25ldHdvcmtpbmcg YW5kIEJTTSIsIHJhdGhlciB0aGFuIHNheWluZyAiODAyLjExIE9DQiBzdXBwb3J0cyBfYW55XyBu ZXR3b3JrIGxheWVyIHBhcm90b2NvbHMiLg0KDQo+IMK3X19fQ0xOUF88aHR0cHM6Ly9lbi53aWtp cGVkaWEub3JnL3dpa2kvQ0xOUD5Db25uZWN0aW9ubGVzcyBOZXR3b3JraW5nDQoNCj4gUHJvdG9j b2wNCg0KPg0KDQo+IMK3X19fRUdQXzxodHRwczovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9FeHRl cmlvcl9HYXRld2F5X1Byb3RvY29sPkV4dGVyDQoNCj4gaW9yIEdhdGV3YXkgUHJvdG9jb2wNCg0K Pg0KDQo+IMK3X19fRUlHUlBfPGh0dHBzOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL0VJR1JQPkVu aGFuY2VkIEludGVyaW9yDQoNCj4gR2F0ZXdheSBSb3V0aW5nIFByb3RvY29sDQoNCj4NCg0KPiDC t19fX0lDTVBfPGh0dHBzOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL0ludGVybmV0X0NvbnRyb2xf TWVzc2FnZV9Qcm90bw0KDQo+IGNvbD5JbnRlcm5ldA0KDQo+IENvbnRyb2wgTWVzc2FnZSBQcm90 b2NvbA0KDQo+DQoNCj4gwrdfX19JR01QXzxodHRwczovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9J R01QPkludGVybmV0IEdyb3VwIE1hbmFnZW1lbnQNCg0KPiBQcm90b2NvbA0KDQo+DQoNCj4gwrdf X19JR1JQXzxodHRwczovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9JR1JQPkludGVyaW9yIEdhdGV3 YXkgUm91dGluZw0KDQo+IFByb3RvY29sDQoNCj4NCg0KPiDCt19fX0lQdjRfPGh0dHBzOi8vZW4u d2lraXBlZGlhLm9yZy93aWtpL0lQdjQ+SW50ZXJuZXQgUHJvdG9jb2wgdmVyc2lvbg0KDQo+IDQN Cg0KPg0KDQo+IMK3X19fSVB2Nl88aHR0cHM6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvSVB2Nj5J bnRlcm5ldCBQcm90b2NvbCB2ZXJzaW9uDQoNCj4gNg0KDQo+DQoNCj4gwrdfX19JUFNlY188aHR0 cHM6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvSVBTZWM+SW50ZXJuZXQgUHJvdG9jb2wNCg0KPiBT ZWN1cml0eQ0KDQo+DQoNCj4gwrdfX19JUFhfPGh0dHBzOi8vZW4ud2lraXBlZGlhLm9yZy93aWtp L0lQWD5JbnRlcm5ldHdvcmsgUGFja2V0IGNoYW5nZQ0KDQo+DQoNCj4gwrdfX19OQVRfPGh0dHBz Oi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL05ldHdvcmtfYWRkcmVzc190cmFuc2xhdGlvbj5OZXQN Cg0KPiB3b3JrDQoNCj4gQWRkcmVzcyBUcmFuc2xhdGlvbg0KDQo+DQoNCj4gwrdfX19Sb3V0ZWQt U01MVF88aHR0cHM6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvUi1TTUxUPg0KDQo+DQoNCj4gwrdf X19TQ0NQXzxodHRwczovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9TaWduYWxsaW5nX0Nvbm5lY3Rp b25fQ29udHJvbF8NCg0KPiBQYXJ0PlNpZ25hbGxpbmcNCg0KPiBDb25uZWN0aW9uIENvbnRyb2wg UGFydA0KDQo+DQoNCj4gwrdBcHBsZVRhbGsgRERQDQoNCj4NCg0KPiDCt19fX0dSRV88aHR0cHM6 Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvR2VuZXJpY19Sb3V0aW5nX0VuY2Fwc3VsYXRpb24+Rw0K DQo+IGVuZXJpYw0KDQo+IFJvdXRpbmcgRW5jYXBzdWxhdGlvbiBmb3IgdHVubmVsaW5nDQoNCj4N Cg0KPiDCt19fX09TUEZfPGh0dHBzOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL09TUEY+T3BlbiBT aG9ydGVzdCBQYXRoIEZpcnN0DQoNCj4NCg0KPiDCt19fX1JJUF88aHR0cHM6Ly9lbi53aWtpcGVk aWEub3JnL3dpa2kvUm91dGluZ19JbmZvcm1hdGlvbl9Qcm90b2NvbD5Sbw0KDQo+IHV0aW5nDQoN Cj4gSW5mb3JtYXRpb24gUHJvdG9jb2wNCg0KPg0KDQo+IMK3X19fSFNSUF88aHR0cHM6Ly9lbi53 aWtpcGVkaWEub3JnL3dpa2kvSG90X1N0YW5kYnlfUm91dGVyX1Byb3RvY29sPkhvDQoNCj4gdA0K DQo+IFN0YW5kYnkgUm91dGVyIHByb3RvY29sDQoNCj4NCg0KPiDCt19fX1ZSUlBfPGh0dHBzOi8v ZW4ud2lraXBlZGlhLm9yZy93aWtpL1ZpcnR1YWxfUm91dGVyX1JlZHVuZGFuY3lfUHJvdA0KDQo+ IG9jb2w+VmlydHVhbA0KDQo+IFJvdXRlciBSZWR1bmRhbmN5IFByb3RvY29sDQoNCj4NCg0KPiDi gJwvQW4gUlNVIHByb2R1Y3QgaGFzIG1hbnkgdHJhbnNjZWl2ZXJzIGluc2lkZS4vL+KAnS8vLw0K DQo+DQoNCj4gLS8vIEFuIFJTRSBtYXkgaGF2ZSBtdWx0aXBsZSB0cmFuc2NlaXZlcnMuDQoNCkkg dGhpbmsgdGhlcmUgaXMgYSBodWdlIHRlcm1pbm9sb2d5IGlzc3VlIGhlcmUuDQoNCiJSU0UiIGlz IG5vdCB1c2VkLCBJIG5ldmVyIGhlYXJkIGl0Lg0KDQpNb3N0IHBlb3BsZSBzYXkgIlJTVSIgdG8g bWVhbiBhICJib3giIHdoZXJlYXMgdGhlIEZDQyB0ZXJtIFJTVSBzZWVtIHRvIG1lYW4ganVzdCBh ICJ0cmFuc2NlaXZlciIuICBBICJ0cmFuc2NlaXZlciIgaXMgdHlwaWNhbGx5IGEgIm1vZGVtIi4N Cg0KUHJvZHVjdHMgYXJlIG1hcmtldGVkIGFzICJSU1UiIGFuZCB0aGV5IGFyZSBib3hlcy4gIFRo ZXkgaGF2ZSBtdWNoIG1vcmUgaW5zaWRlIHRoYW4ganVzdCB0aGUgInRyYW5zY2VpdmVyIi4gIFdo YXQgY291bGQgYmUgdW5kZXJzdG9vZCBhcyAndHJhbnNjZWl2ZXInICh0cmFuc21pdHRlci9yZWNl aXZlcikgaXMgdGhlIG1vZGVtDQoNCihtb2R1bGF0b3IvZGVtb2R1bGF0b3IpIG9yICdiYXNlYmFu ZCcgcHJvY2Vzc29yLCB0aGF0IHNpdHMgb24gYW4gZXh0ZW5zaW9uIGJvYXJkIHRoYXQgaXRzZWxm IHNpdHMgb24gYSBtb3RoZXJib2FyZC4gIFRoZXJlIGlzIHBvd2VyIHN1cHBseSB0b28uICBBbGwg dGhlc2UgbWFrZSBhbiAiUlNVIi4gIFNvbWUgUlNVcyBoYXZlIGV2ZW4gbW9yZSBkZXZpY2VzIGxp a2Ugc29sYXIgcGFuZWxzLCBtZWNoYW5pY2FsIGhvb2tzLCBzb3BoaXN0aWNhdGVkIGFudGVubmFz LCBFViBjaGFyZ2Ugc3RhdGlvbnMsIExURSBtb2RlbXMsIG9wdGljYWwgYmFja2hhdWwgYW5kIG1v cmUuDQoNCkJFY2F1c2Ugb2YgdGhpcyBkaXNjcmVwYW5jeSwgSSBwcmVmZXIgdG8gZm9yZ2V0IHVz ZSBoaXMgIlJTVSIgdGVybSBpbiB0aGlzIElQLW92ZXItT0NCIGRvY3VtZW50IGp1c3QgYXMgZm9y IGluZm9ybWF0aW9uLiAgUkF0aGVyLCB1c2UgdGhlICJJUC1SU1UiIHRvIG1lYW4gd2hhdCB3ZSB3 YW50IGl0IHRvIG1lYW4uDQoNCkFsZXgNCg0KPg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQoNCj4gRnJvbTogQWxleGFuZHJlIFBldHJlc2N1IFttYWlsdG86YWxleGFuZHJlLnBldHJl c2N1QGdtYWlsLmNvbV0NCg0KPiBTZW50OiBTdW5kYXksIEZlYnJ1YXJ5IDA0LCAyMDE4IDEwOjQ5 IEFNDQoNCj4gVG86IEZyYW7Dp29pcyBTaW1vbiA8Znlnc2ltb25AZ21haWwuY29tPG1haWx0bzpm eWdzaW1vbkBnbWFpbC5jb20+Pg0KDQo+IENjOiBpdHNAaWV0Zi5vcmc8bWFpbHRvOml0c0BpZXRm Lm9yZz4NCg0KPiBTdWJqZWN0OiBSZTogW2lwd2F2ZV0gU2hlcGhlcmQgcmV2aWV3IG9mDQoNCj4g ZHJhZnQtaWV0Zi1pcHdhdmUtaXB2Ni1vdmVyLTgwMjExb2NiLTEyDQoNCj4NCg0KPiBMZSAwMi8w Mi8yMDE4IMOgIDExOjIzLCBGcmFuw6dvaXMgU2ltb24gYSDDqWNyaXQgOg0KDQo+DQoNCj4+IE1y LiBQZXRyZXNjdSwNCg0KPg0KDQo+Pg0KDQo+DQoNCj4+IExldCdzIHRyeSBvbmUgbW9yZSB0aW1l IHRvIGNsYXJpZnkgdGhlIEZDQyBEU1JDIChpbiBVUyBvbmx5KSBpc3N1ZS4NCg0KPg0KDQo+Pg0K DQo+DQoNCj4+ICpGQ0Mg4oCTIERTUkMqDQoNCj4NCg0KPj4NCg0KPg0KDQo+PiAqQmFja2dyb3Vu ZDoqKioNCg0KPg0KDQo+Pg0KDQo+DQoNCj4+ICoqDQoNCj4NCg0KPj4NCg0KPg0KDQo+PiAtKiog VGhlIFVTIEZlZGVyYWwgQ29tbXVuaWNhdGlvbnMgQ29tbWlzc2lvbiAoRkNDKSBEZWRpY2F0ZWQg U2hvcnQNCg0KPg0KDQo+PiBSYW5nZSBDb21tdW5pY2F0aW9uIChEU1JDKSBpcyBkZWZpbmVkIGlu IHRoZSBDb2RlIG9mIEZlZGVyYWwNCg0KPg0KDQo+PiBSZWd1bGF0aW9ucyAoQ0ZSKQ0KDQo+DQoN Cj4+IDQ3IG1haW5seSBQYXJ0cyA5MCBhbmQgOTUuIFRoZSBsYXN0IHVwZGF0ZSBpcyBkYXRlZCBP Y3RvYmVyIDFzdCwNCg0KPj4gMjAxMDsNCg0KPg0KDQo+Pg0KDQo+DQoNCj4+IC1UaGlzIGluY2x1 ZGVzIHRoZSBBU1RNIEUgMjIxMy0wMyBzdGFuZGFyZDog4oCcU3RhbmRhcmQgU3BlY2nvrIFjYXRp b24NCg0KPj4gZm9yDQoNCj4NCg0KPj4gVGVsZWNvbW11bmljYXRpb25zIGFuZCBJbmZvcm1hdGlv biBFeGNoYW5nZSBCZXR3ZWVuIFJvYWRzaWRlIGFuZA0KDQo+DQoNCj4+IFZlaGljbGUgU3lzdGVt cyDigJQgNSBHSHogQmFuZCBEZWRpY2F0ZWQgU2hvcnQgUmFuZ2UgQ29tbXVuaWNhdGlvbnMNCg0K Pg0KDQo+PiAoRFNSQykgTWVkaXVtIEFjY2VzcyBDb250cm9sIChNQUMpIGFuZCBQaHlzaWNhbCBM YXllciAoUEhZKQ0KDQo+DQoNCj4+IFNwZWNp76yBY2F0aW9uc+KAnTsgYXBwcm92ZWQgSnVseSAx MCwgMjAwMy4gVGhlIHN0YW5kYXJkIGlzIGRlcml2ZWQgZnJvbQ0KDQo+DQoNCj4+IElFRUUgODAy LjExYSBhbmQsIGluIG1vc3QgcGFydCwgaXMgZXF1aXZhbGVudCB0byBJRUVFIDgwMi4xMSBPQ0Iu IFRvDQoNCj4NCg0KPj4gZGF0ZSwgdGhlIERTUkMgQ0ZScyBkbyBub3Qgc3BlY2lmeSBJRUVFIDgw Mi4xMSBPQ0IuDQoNCj4NCg0KPj4NCg0KPg0KDQo+PiAtVGhlIHJlbGF0ZWQgQ0ZScyBzdGF0ZSB0 aGF0IERTUkMgc2hhbGwgY29tcGx5IHdpdGggdGhlIEFTVE0gRSAyMjEzLTAzLg0KDQo+DQoNCj4g VGhhbmsgeW91IGZvciB0aGUgZXhwbGFuYXRpb24uICBJdCBpcyB1c2VmdWwgdG8gdW5kZXJzdGFu ZCB0aGF0IERTUkMNCg0KPiBpcyByZWxhdGVkIHRvIEFTVE0gRSAyMjEzLTAzIGFuZCB0aGF0IG5l aXRoZXIgcmVmZXJzIHRvIDgwMi4xMSBPQ0IuDQoNCj4NCg0KPiBJIHRoaW5rIGluIHdvcmtzIHJl bGF0ZWQgdG8gc3RhbmRhcmRzIGFuZCBwcm9kdWN0cyBpdCBpcyBhZHZhbnRhZ2VvdXMNCg0KPiBp ZiB0aGVyZSBpcyBjb3JyZWxhdGlvbi4NCg0KPg0KDQo+IEZvciBleGFtcGxlLCBpbiBhbiBpZGVh bCB3b3JsZCwgc3RhbmRhcmRzIHRhbGsgYWJvdXQgIkEiIGFuZCB0aGUNCg0KPiByZWd1bGF0aW9u IGFsc28gYWJvdXQgIkEiIGFuZCB0aGUgcHJvZHVjdHMgYW5kIHNvZndhcmUgYXJlIGFsc28NCg0K PiBsYWJlbGxlZCAiQSIuDQoNCj4NCg0KPiBJbiBvdXIgY29udGV4dCwgc29mdHdhcmUgaXMgbGFi ZWxsZWQgIk9DQiIgKGtlcm5lbCBkcml2ZXJzKSwNCg0KPiByZWd1bGF0aW9uIHRhbGtzICJEU1JD IiBhbmQgc3RhbmRhcmRzICI4MDIuMTFwIiBhbmQgIjgwMi4xMSBPQ0IiLg0KDQo+DQoNCj4+ICpP dmVydmlldyBvZiBEU1JDIGZ1bmN0aW9uczoqKioNCg0KPg0KDQo+Pg0KDQo+DQoNCj4+ICoqDQoN Cj4NCg0KPj4NCg0KPg0KDQo+PiBUaGUgZnVuY3Rpb25zIGxpc3RlZCBpbiBEU1JDIHJlbGF0ZWQg Q0ZScyBhcmUsIGluIGdlbmVyYWwsIHNwZWNpZmllZA0KDQo+DQoNCj4+IGluIHRoZSBBU1RNIEUg MjIxMy0wMyBhbmQgSUVFRSA4MDIuMTEgT0NCOg0KDQo+DQoNCj4+DQoNCj4NCg0KPj4gLU1BQyBz ZXJ2aWNlIGRlZmluaXRpb24sIGZyYW1lIGZvcm1hdCwgYW5kIHByb2NlZHVyZXM7DQoNCj4NCg0K Pj4NCg0KPg0KDQo+PiAtUEhZIE9ydGhvZ29uYWwgZnJlcXVlbmN5IGRpdmlzaW9uIG11bHRpcGxl eGluZyAoT0ZETSk7DQoNCj4NCg0KPj4NCg0KPg0KDQo+PiAtUEhZIFNlcnZpY2UgRGF0YSBVbml0 IGZvcm1hdCBhbmQgbW9kdWxhdGlvbnMgKGRhdGEgcmF0ZXMpOg0KDQo+DQoNCj4+DQoNCj4NCg0K Pj4gLTUuOSBHSHogYmFuZCBhbGxvY2F0ZWQgY2hhbm5lbHMsIGZyZXF1ZW5jeSwgbWF4LiBFSVJQ LCBhbmQgc3BlY3RydW0NCg0KPg0KDQo+PiBtYXNrOw0KDQo+DQoNCj4+DQoNCj4NCg0KPj4gLUlu ZGl2aWR1YWwgQ2hhbm5lbCB1c2U6IFNhZmV0eSBhcHBsaWNhdGlvbnMsIG5vbi1zYWZldHkNCg0K Pj4gYXBwbGljYXRpb25zLA0KDQo+DQoNCj4+IGFuZCBwcmlvcml0aWVzLg0KDQo+DQoNCj4+DQoN Cj4NCg0KPj4gKlByb3RvY29scyoqKg0KDQo+DQoNCj4+DQoNCj4NCg0KPj4gKioNCg0KPg0KDQo+ Pg0KDQo+DQoNCj4+IERTUkMgYmVpbmcgdW5pcXVlbHkgYSBNQUMgYW5kIFBIWSBjb21tdW5pY2F0 aW9ucyBzZXJ2aWNlLA0KDQo+DQoNCj4gSSB0aG91Z2h0ICJEU1JDIiBpcyBhbHNvIGFib3V0IEFw cGxpY2F0aW9ucyBhbmQgVXNlLWNhc2VzLg0KDQo+DQoNCj4+IHRoZXJlIGhlcmUgbm8NCg0KPg0K DQo+PiByZXN0cmljdGlvbiBvbiBUcmFuc3BvcnQgYW5kIE5ldHdvcmsgcHJvdG9jb2xzIHRoYXQg Y2FuIGJlIHVzZWQNCg0KPg0KDQo+PiAoZXhjZXB0IGZvciB0aGUgTENDIHNwZWNpZmllZCBieSBy ZWZlcmVuY2UgaW4gSUVFRSA4MDIuMTEgT0NCKS4gSW4NCg0KPj4gdGhlDQoNCj4NCg0KPj4gVVMs IHRoZSBXQVZFIHN0YW5kYXJkcyAoSUVFRSAxNjA5IHNlcmllcykgc3BlY2lmeSB0aGVzZSBwcm90 b2NvbHMNCg0KPj4gd2hlbg0KDQo+DQoNCj4+IHVzaW5nIERTUkMgYXMgdGhlIGNvbW11bmljYXRp b24gc2VydmljZS4NCg0KPg0KDQo+IEl0IGlzIG9uZSB0aGluZyB0byBoYXZlIG5vIHJlc3RyaWN0 aW9ucywgYW5kIGFub3RoZXIgdGhpbmcgdG8gcmVja29uDQoNCj4gdGhhdCBJUCBpcyB0aGUgbmV0 d29ya2luZyBsYXllci4NCg0KPg0KDQo+Pg0KDQo+DQoNCj4+ICpPQlUgLyBSU1UqKioNCg0KPg0K DQo+Pg0KDQo+DQoNCj4+ICoqDQoNCj4NCg0KPj4NCg0KPg0KDQo+PiBUaGUgQ0ZSIChGQ0MpIGRl ZmluaXRpb25zIGFyZToNCg0KPg0KDQo+Pg0KDQo+DQoNCj4+IC9Sb2Fkc2lkZSB1bml0IChSU1Up LiBBIFJvYWRzaWRlIFVuaXQgaXMgYSBEU1JDIHRyYW5zY2VpdmVyDQoNCj4NCg0KPiBTaWdoLCBp dCBpcyB3YXkgZGlmZmVyZW50Lg0KDQo+DQoNCj4gQW4gUlNVIHByb2R1Y3QgaGFzIG1hbnkgdHJh bnNjZWl2ZXJzIGluc2lkZS4NCg0KPg0KDQo+PiB0aGF0IGlzDQoNCj4NCg0KPj4gbW91bnRlZCBh bG9uZyBhIHJvYWQgb3IgcGVkZXN0cmlhbiBwYXNzYWdld2F5LiBBbiBSU1UgbWF5IGFsc28gYmUN Cg0KPg0KDQo+PiBtb3VudGVkIG9uIGEgdmVoaWNsZSBvciBpcyBoYW5kIGNhcnJpZWQsIGJ1dCBp dCBtYXkgb25seSBvcGVyYXRlIHdoZW4NCg0KPg0KDQo+PiB0aGUgdmVoaWNsZSBvciBoYW5kLSBj YXJyaWVkIHVuaXQgaXMgc3RhdGlvbmFyeS4gRnVydGhlcm1vcmUsIGFuIFJTVQ0KDQo+DQoNCj4+ IG9wZXJhdGluZyB1bmRlciB0aGlzIHBhcnQgaXMgcmVzdHJpY3RlZCB0byB0aGUgbG9jYXRpb24g d2hlcmUgaXQgaXMNCg0KPg0KDQo+PiBsaWNlbnNlZCB0byBvcGVyYXRlLiBIb3dldmVyLCBwb3J0 YWJsZSBvciBoYW5kLWhlbGQgUlNVcyBhcmUNCg0KPj4gcGVybWl0dGVkDQoNCj4NCg0KPj4gdG8g b3BlcmF0ZSB3aGVyZSB0aGV5IGRvIG5vdCBpbnRlcmZlcmUgd2l0aCBhIHNpdGUtbGljZW5zZWQg b3BlcmF0aW9uLg0KDQo+DQoNCj4+IEEgUlNVIGJyb2FkY2FzdHMgZGF0YSB0byBPQlVzIG9yIGV4 Y2hhbmdlcyBkYXRhIHdpdGggT0JVcyBpbiBpdHMNCg0KPg0KDQo+PiBjb21tdW5pY2F0aW9ucyB6 b25lLiBBbiBSU1UgYWxzbyBwcm92aWRlcyBjaGFubmVsIGFzc2lnbm1lbnRzIGFuZA0KDQo+DQoN Cj4+IG9wZXJhdGluZyBpbnN0cnVjdGlvbnMgdG8gT0JVcyBpbiBpdHMgY29tbXVuaWNhdGlvbnMg em9uZSwgd2hlbg0KDQo+DQoNCj4+IHJlcXVpcmVkLi8tIFtDRlIgOTAuNyAtIERlZmluaXRpb25z XSAtIFJldmlzZWQgYXMgT2N0b2JlciAyMDEwLg0KDQo+DQoNCj4gSSB0aGluayBpdCBzaG91bGQg YmUgdXBkYXRlZCB0byByZWZlciB0byB0aGlzIGRvY3VtZW50Lg0KDQo+DQoNCj4+IC9Pbi1Cb2Fy ZCB1bml0IChPQlUpLiBBbiBPbi1Cb2FyZCBVbml0IGlzIGEgRFNSQ1MgdHJhbnNjZWl2ZXIgdGhh dCBpcw0KDQo+DQoNCj4+IG5vcm1hbGx5IG1vdW50ZWQgaW4gb3Igb24gYSB2ZWhpY2xlLCBvciB3 aGljaCBpbiBzb21lIGluc3RhbmNlcyBtYXkNCg0KPj4gYmUNCg0KPg0KDQo+PiBhIHBvcnRhYmxl IHVuaXQuIEFuIE9CVSBjYW4gYmUgb3BlcmF0aW9uYWwgd2hpbGUgYSB2ZWhpY2xlIG9yIHBlcnNv bg0KDQo+DQoNCj4+IGlzIGVpdGhlciBtb2JpbGUgb3Igc3RhdGlvbmFyeS4gVGhlIE9CVXMgcmVj ZWl2ZSBhbmQgY29udGVuZCBmb3IgdGltZQ0KDQo+DQoNCj4+IHRvIHRyYW5zbWl0IG9uIG9uZSBv ciBtb3JlIHJhZGlvIGZyZXF1ZW5jeSAoUkYpIGNoYW5uZWxzLiBFeGNlcHQNCg0KPj4gd2hlcmUN Cg0KPg0KDQo+PiBzcGVjaWZpY2FsbHkgZXhjbHVkZWQsIE9CVSBvcGVyYXRpb24gaXMgcGVybWl0 dGVkIHdoZXJldmVyIHZlaGljbGUNCg0KPg0KDQo+PiBvcGVyYXRpb24gb3IgaHVtYW4gcGFzc2Fn ZSBpcyBwZXJtaXR0ZWQuIFRoZSBPQlVzIG1vdW50ZWQgaW4gdmVoaWNsZXMNCg0KPg0KDQo+PiBh cmUgbGljZW5zZWQgYnkgcnVsZSB1bmRlciBwYXJ0IDk1IG9mIHRoaXMgY2hhcHRlciBhbmQgY29t bXVuaWNhdGUNCg0KPg0KDQo+PiB3aXRoIFJvYWRzaWRlIFVuaXRzIChSU1VzKSBhbmQgb3RoZXIg T0JVcy4gUG9ydGFibGUgT0JVcyBhcmUgYWxzbw0KDQo+DQoNCj4+IGxpY2Vuc2VkIGJ5IHJ1bGUg dW5kZXIgcGFydCA5NSBvZiB0aGlzIGNoYXB0ZXIuIE9CVSBvcGVyYXRpb25zIGluIHRoZQ0KDQo+ DQoNCj4+IFVubGljZW5zZWQgTmF0aW9uYWwgSW5mb3JtYXRpb24gSW5mcmFzdHJ1Y3R1cmUgKFVO SUkpIEJhbmRzIGZvbGxvdw0KDQo+PiB0aGUNCg0KPg0KDQo+PiBydWxlcyBpbiB0aG9zZSBiYW5k cy4vLSBbQ0ZSIDkwLjcgLSBEZWZpbml0aW9uc10gLSBPY3RvYmVyIDIwMTANCg0KPg0KDQo+IFRo YW5rcyBmb3IgdGhlIGRlZmluaXRpb25zLg0KDQo+DQoNCj4gVGhleSBhcmUgZmFyIGRpZmZlcmVu dCBmcm9tIHdoYXQgd2UgbmVlZCBpbiB0aGlzIGRyYWZ0Lg0KDQo+DQoNCj4gSSB3aWxsIHNlZSB0 aGUgb3RoZXIgc3VnZ2VzdGlvbnMuDQoNCj4NCg0KPiBBbGV4DQoNCj4NCg0KPj4NCg0KPg0KDQo+ PiAqSVBXQVZFIElzc3VlKioqDQoNCj4NCg0KPj4NCg0KPg0KDQo+PiAqKg0KDQo+DQoNCj4+DQoN Cj4NCg0KPj4gL+KAnFRoZSBwcm9ibGVtIHdpdGggdGhlIEZDQyBkZWZpbml0aW9uIG9mIE9CVSBp cyB0aGF0IGl0IGhhcyBubw0KDQo+DQoNCj4+IHJlbGF0aW9uc2hpcCB0byBJUC4gIFdvcnNlLCB0 aGF0IEZDQyBkZWZpbml0aW9uIGhhcyBubyBpbmRpY2F0aW9uDQoNCj4+IHRoYXQNCg0KPg0KDQo+ PiBpdCBNQVkgdXNlIElQIHNvbWVob3cuICBBbmQgaGVyZSB3ZSBzYXkgdGhhdCBhbGwgT0JVcyBt dXN0IHVzZSBJUC4NCg0KPj4gRG8NCg0KPg0KDQo+PiB5b3Ugc2VlIHdoYXQgSSBtZWFuP+KAnS8v Lw0KDQo+DQoNCj4+DQoNCj4NCg0KPj4gLy8NCg0KPg0KDQo+Pg0KDQo+DQoNCj4+IENvcnJlY3Q7 IHRoZSBPQlUgaGFzIG5vIHJlbGF0aW9uc2hpcCB3aXRoIElQIGFuZCBpcyBub3QgaW50ZW5kZWQg dG8uDQoNCj4NCg0KPj4gSVAgaXMgYSBuZXR3b3JrIHByb3RvY29sLiAgSWYgYW4gT24tQm9hcmQg VW5pdCAoT0JVKSBkZXZpY2UgaXMNCg0KPg0KDQo+PiByZXF1aXJlZCB0byBleGNoYW5nZSBJUCwg aXQgbmVlZHMgdG8gYmUgZGVhbHQgaW4gcHJvdG9jb2wocykgYW5kL29yDQoNCj4NCg0KPj4gTWFu YWdlbWVudCBpbiBoaWdoZXIgbGF5ZXJzIHNpbWlsYXIgdG8gV0FWRSB3aXRoaW4gdGhlIE9uLUJv YXJkIEVxdWlwbWVudCAoT0JFKSAuDQoNCj4NCg0KPj4NCg0KPg0KDQo+PiAv4oCcRG8geW91IHRo aW5rIEZDQyB3aWxsIG1pbmQgaWYgd2UgdXNlIHRoZSB0ZXJtIE9CVSBpbiB0aGlzIGRyYWZ0IHRv DQoNCj4NCg0KPj4gbWVhbiBzb21ldGhpbmcgZWxzZT8gIEksIGFuZCBhIGNvbGxlYWd1ZSwgdGhp bmsgdGhhdCBGQ0Mgd291bGQgbm90DQoNCj4NCg0KPj4gbWluZC7igJ0vLy8NCg0KPg0KDQo+Pg0K DQo+DQoNCj4+IC8vDQoNCj4NCg0KPj4NCg0KPg0KDQo+PiBEZXBlbmRpbmcgb2YgdGhlIHJlYWRl ci4gSWYgb25lIGlzIGZhbWlsaWFyIHdpdGggRFNSQywgT0JVIGFuZCBSU1UgYXMNCg0KPg0KDQo+ PiBkZWZpbmVkIGJ5IEZDQyB3aWxsIGNvbWUgaW4gbWluZC4gQXMgZmFyIGFzIEkga25vdywg4oCc T0JV4oCdIGFuZCDigJxSU1XigJ0NCg0KPg0KDQo+PiBhcmUgbm90IHJlZ2lzdGVyZWQgYW5kIGNv dWxkIGJlIHVzZWQgZm9yIG90aGVyIGRlZmluaXRpb25zIChzb21ldGhpbmcNCg0KPg0KDQo+PiBs aWtlDQoNCj4NCg0KPj4g4oCcQVRN4oCdOiBBc3luY2hyb25vdXMgVHJhbnNmZXIgTW9kZSBhbmQg QXV0b21hdGljIFRlbGxlciBNYWNoaW5l8J+YiikuIE15DQoNCj4NCg0KPj4gc3VnZ2VzdGlvbiB0 byB0aGUgSVBXQVZFIHRlYW0gaXMgdG8gdXNlIOKAnE9CRSBhbmQgUlNF4oCdLg0KDQo+DQoNCj4+ DQoNCj4NCg0KPj4gVGhpcyBpcyBteSBwZXJzb25hbCB2aWV3IGFzIEkgZG9ub3QgcmVwcmVzZW50 IGFueSBpbnZvbHZlZCBpbnRlcmVzdC4NCg0KPg0KDQo+PiBJZiBhbnkgb25lIGhhcyBxdWVzdGlv bnMsIGxldCBtZSBrbm93Lg0KDQo+DQoNCj4+DQoNCj4NCg0KPj4gRnJhbmNvaXMgU2ltb24NCg0K Pg0KDQo+Pg0KDQo+DQoNCj4+IExvamlrIFRlY2hub2xvZ2llcw0KDQo+DQoNCj4+DQoNCj4NCg0K Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KPg0KDQo+Pg0KDQo+DQoNCj4+IEZyb206 IGl0cyBbbWFpbHRvOml0cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWxleGFuZHJl DQoNCj4NCg0KPj4gUGV0cmVzY3UNCg0KPg0KDQo+Pg0KDQo+DQoNCj4+IFNlbnQ6IE1vbmRheSwg SmFudWFyeSAyOSwgMjAxOCAxMDowOCBBTQ0KDQo+DQoNCj4+DQoNCj4NCg0KPj4gVG86aXRzQGll dGYub3JnPG1haWx0bzppdHNAaWV0Zi5vcmc+DQoNCj4NCg0KPj4NCg0KPg0KDQo+PiBTdWJqZWN0 OiBSZTogW2lwd2F2ZV0gU2hlcGhlcmQgcmV2aWV3IG9mDQoNCj4NCg0KPj4gZHJhZnQtaWV0Zi1p cHdhdmUtaXB2Ni1vdmVyLTgwMjExb2NiLTEyDQoNCj4NCg0KPj4NCg0KPg0KDQo+Pg0KDQo+DQoN Cj4+DQoNCj4NCg0KPj4gTGUgMjkvMDEvMjAxOCDDoCAxNTo1MiwgRnJhbsOnb2lzIFNpbW9uIGEg w6ljcml0IDoNCg0KPg0KDQo+Pg0KDQo+DQoNCj4+PiBNeSBjb21tZW50cyBhcmV3aXRoaW4gdGhl IHRleHQqW0Z5Z3MuLi4uLi4uXSouDQoNCj4NCg0KPj4NCg0KPg0KDQo+PiBbLi4uXQ0KDQo+DQoN Cj4+DQoNCj4NCg0KPj4+IEluIHRoZSB0ZXJtaW5vbG9neSBzZWN0aW9uLCB0aGUgT0JVIHRlcm0g aXMgbWVudGlvbmVkIHRvIGJlIGRlZmluZWQNCg0KPg0KDQo+Pg0KDQo+DQoNCj4+PiBvdXRzaWRl IHRoZSBJRVRGLiBUaGlzIGlzIGZpbmUsIGJ1dCB3ZSBoYXZlIHRvIHByb3ZpZGUgYSByZWZlcmVu Y2UuDQoNCj4NCg0KPj4NCg0KPg0KDQo+Pj4gQW5kIGV2ZW4gd2l0aCB0aGF0LCBpdCB3b3VsZCBu b3QgaGFybSB0byBpbmNsdWRlIHNvbWUgc2hvcnQNCg0KPg0KDQo+Pj4gZGVmaW5pdGlvbg0KDQo+ DQoNCj4+DQoNCj4NCg0KPj4+IHRvIHByb3ZpZGUgY29udGV4dC4gVGhlIFJTVSB0ZXJtIGlzIGFs c28gZGVmaW5lZCBvdXRzaWRlIHRoZSBJRVRGDQoNCj4+PiBhbmQNCg0KPg0KDQo+Pg0KDQo+DQoN Cj4+PiB0aGVyZSBpcyBxdWl0ZSBhIGxvdCBvZiB0ZXh0IHByb3ZpZGVkIChJIHRoaW5rIHRoZSBy ZWxldmFudCBwYXJ0IGlzDQoNCj4NCg0KPj4NCg0KPg0KDQo+Pj4gdGhlIGxhc3Qgc2VudGVuY2Us IHRoZSBvbmUgc3RhcnRpbmcgd2l0aCAiVGhlIGRpZmZlcmVuY2UgYmV0d2Vlbi4uLiIpLg0KDQo+ DQoNCj4+DQoNCj4NCg0KPj4+IEJvdGggdGVybXMgc2hvdWxkIGJlIGhhbmRsZWQgaW4gdGhlIHNh bWUgd2F5Lg0KDQo+DQoNCj4+DQoNCj4NCg0KPj4+DQoNCj4NCg0KPj4NCg0KPg0KDQo+Pj4gKltG eWdzOiBUaGUqKmRlZmluaXRpb25zKip3YXMgaXNzdWVkIGJ5IHRoZSBGQ0MgMjAgeWVhcnMgYWdv LiAgSQ0KDQo+Pj4gaGF2ZQ0KDQo+DQoNCj4+DQoNCj4NCg0KPj4+IGFscmVhZHkgcHJvdmlkZWQg dGhhdCBpbmZvcm1hdGlvbioqYW5kIHJlZmVyZW5jZXMgbXVsdGlwbGUNCg0KPg0KDQo+Pg0KDQo+ DQoNCj4+PiB0aW1lcy5dKioqDQoNCj4NCg0KPj4NCg0KPg0KDQo+PiBUaGUgcHJvYmxlbSB3aXRo IHRoZSBGQ0MgZGVmaW5pdGlvbiBvZiBPQlUgaXMgdGhhdCBpdCBoYXMgbm8NCg0KPg0KDQo+PiBy ZWxhdGlvbnNoaXAgdG8gSVAuICBXb3JzZSwgdGhhdCBGQ0MgZGVmaW5pdGlvbiBoYXMgbm8gaW5k aWNhdGlvbg0KDQo+PiB0aGF0DQoNCj4NCg0KPj4gaXQgTUFZIHVzZSBJUCBzb21laG93LiAgQW5k IGhlcmUgd2Ugc2F5IHRoYXQgYWxsIE9CVXMgbXVzdCB1c2UgSVAuDQoNCj4+IERvDQoNCj4NCg0K Pj4geW91IHNlZSB3aGF0IEkgbWVhbj8NCg0KPg0KDQo+Pg0KDQo+DQoNCj4+IERvIHlvdSB0aGlu ayBGQ0Mgd2lsbCBtaW5kIGlmIHdlIHVzZSB0aGUgdGVybSBPQlUgaW4gdGhpcyBkcmFmdCB0bw0K DQo+DQoNCj4+IG1lYW4gc29tZXRoaW5nIGVsc2U/ICBJLCBhbmQgYSBjb2xsZWFndWUsIHRoaW5r IHRoYXQgRkNDIHdvdWxkIG5vdCBtaW5kLg0KDQo+DQoNCj4+DQoNCj4NCg0KPj4gQWxleA0KDQo+ DQoNCj4+DQoNCj4NCg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCg0KPg0KDQo+Pg0KDQo+DQoNCj4+IGl0cyBtYWlsaW5nIGxpc3QNCg0KPg0KDQo+ Pg0KDQo+DQoNCj4+aXRzQGlldGYub3JnPG1haWx0bzppdHNAaWV0Zi5vcmc8bWFpbHRvOml0c0Bp ZXRmLm9yZyUzY21haWx0bzppdHNAaWV0Zi5vcmc+Pg0KDQo+DQoNCj4+DQoNCj4NCg0KPj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2l0cw0KDQo+DQoNCj4+DQoNCj4NCg== --_000_40618c5cbd684e4a8f7de3f2e58b9114HE105831emea1cdstintern_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHRpdGxl PlJFOiBbaXB3YXZlXSBTaGVwaGVyZCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1pcHdhdmUtaXB2Ni1v dmVyLTgwMjExb2NiLTEyPC90aXRsZT4NCjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25z ICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IlNlZ29lIFVJIEVtb2ppIjsNCglwYW5vc2UtMToyIDExIDUgMiA0IDIgNCAyIDIgMzt9 DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2 Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5tc29ub3Jt YWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29u b3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCglt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXpl OjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVt YWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0 IDcwLjg1cHQgMi4wY20gNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkRFIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+cGVyaGFwcyB0aGlzIHdhcyBqdXN0IGEgdHlwbyBtZWFuaW5n IEJhc2ljIFRyYW5zcG9ydCBQcm90b2NvbCAoQlRQKSBydW5uaW5nIG92ZXIgZ2VvbmV0d29ya2lu ZyBpbiBFVFNJIElUUz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNt O21hcmdpbi1ib3R0b206NS4wcHQ7bWFyZ2luLWxlZnQ6MGNtO3RleHQtYXV0b3NwYWNlOm5vbmUi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5CZXN0IFJlZ2FyZHM8YnI+DQpEaXJrIDwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBpdHMgW21haWx0bzppdHMt Ym91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+RnJhbsOnb2lzIFNpbW9uPGJy Pg0KPGI+U2VudDo8L2I+IERpZW5zdGFnLCA2LiBGZWJydWFyIDIwMTggMTE6MjI8YnI+DQo8Yj5U bzo8L2I+ICdBbGV4YW5kcmUgUGV0cmVzY3UnICZsdDthbGV4YW5kcmUucGV0cmVzY3VAZ21haWwu Y29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gaXRzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbaXB3YXZlXSBTaGVwaGVyZCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1pcHdhdmUtaXB2Ni1v dmVyLTgwMjExb2NiLTEyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PiZxdW90Ozwvc3Bhbj48aT48c3BhbiBsYW5nPSJFTi1VUyI+DQo8L3NwYW4+PC9pPjxpPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5UaGUgcHJvdG9jb2xzIEkgaGF2ZSBzZWVuIHJ1bm5pbmcgb24gODAyLjExIE9DQiBh cmUgSVAsIEVUU0kgZ2VvbmV0d29ya2luZyBhbmQgQlNNLiZxdW90Ozwvc3Bhbj48L2k+PG86cD48 L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJv bCI+LTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5CU00gaXMgbm90IGEg cHJvdG9jb2wuIFRoZSBCYXNpYyBTYWZldHkgTWVzc2FnZSAoQlNNKSBpcyBhPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+bWVzc2FnZSB1c2VkIGluIFYyViBh cHBsaWNhdGlvbnMgYW5kIGlzIGRlZmluZWQgaW4gU0FFIGoyNzM1IHN0YW5kYXJkIC0mbmJzcDsm bmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj7igJxE ZWRpY2F0ZWQgU2hvcnQgUmFuZ2UgQ29tbXVuaWNhdGlvbnMgKERTUkMpIE1lc3NhZ2UgU2V0IERp Y3Rpb25hcnnigJ0uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogQWxleGFuZHJlIFBldHJlc2N1IFs8YSBo cmVmPSJtYWlsdG86YWxleGFuZHJlLnBldHJlc2N1QGdtYWlsLmNvbSI+bWFpbHRvOmFsZXhhbmRy ZS5wZXRyZXNjdUBnbWFpbC5jb208L2E+XTxicj4NClNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMDUs IDIwMTggMzowOCBBTTxicj4NClRvOiBGcmFuw6dvaXMgU2ltb24gJmx0OzxhIGhyZWY9Im1haWx0 bzpmeWdzaW1vbkBnbWFpbC5jb20iPmZ5Z3NpbW9uQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KQ2M6 IDxhIGhyZWY9Im1haWx0bzppdHNAaWV0Zi5vcmciPml0c0BpZXRmLm9yZzwvYT48YnI+DQpTdWJq ZWN0OiBSZTogW2lwd2F2ZV0gU2hlcGhlcmQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtaXB3YXZlLWlw djYtb3Zlci04MDIxMW9jYi0xMjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5MZSAwNS8wMi8yMDE4IMOgIDA0OjMwLCBGcmFuw6dvaXMgU2ltb24gYSDDqWNyaXQmbmJzcDs6 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgTXIuIFBldHJlc2N1 LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IC8mcXVvdDsvL0kgdGhvdWdodCAmcXVv dDtEU1JDJnF1b3Q7IGlzIGFsc28gYWJvdXQgQXBwbGljYXRpb25zIGFuZCBVc2UtY2FzZXMuLy8m cXVvdDsvLy88L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyAtLy8gTm87IEl0IGlzIGEg RGVkaWNhdGVkIFNob3J0IFJhbmdlIENvbW11bmljYXRpb24gc2VydmljZS4mbmJzcDsNCjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IEliZWxpZXZldGhhdFNBRSBE U1JDVGVjaG5pY2FsIENvbW1pdHRlZSAoVVMpIGlzIGRlZmluaW5nDQo8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyBhcHBsaWNhdGlvbnNhbmQgdXNlLWNhc2VzLi8v PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgLy88L3NwYW4+PG86cD48L286cD48L3A+ DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+Jmd0OyDigJwvSXQgaXMgb25lIHRoaW5nIHRvIGhhdmUgbm8gcmVzdHJpY3Rpb25zLCBh bmQgYW5vdGhlciB0aGluZyB0byByZWNrb24NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4mZ3Q7IHRoYXQgSVAgaXMgdGhlIG5ldHdvcmtpbmcgbGF5ZXIuLy/igJ0vLy88 L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyAtLy9MYXllciAzIChOZXR3b3JrIExheWVy KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5XZWxsLCBJIGFtIGhhcHB5 IHlvdSBsaXN0IGFsbCB0aGVzZSBuZXR3b3JrIGxheWVyIHByb3RvY29scy48L3NwYW4+PG86cD48 L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QXMgYSBzaWRlIG5vdGUsIGl0IHdvdWxkIGJlIGdv b2QgdG8gbGV0IGtub3cgd2lraXBlZGlhIHRvIHJlZmVyIGhlcmUuDQo8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+KHRoZXJlIGFyZSBkZXRhaWxzIHRoYXQgc2l0dWF0ZSB0 aGUgbGlzdGVkIHByb3RvY29scyB0byBiZSBhIGxpdHRsZSBiaXQgYWJvdmUgbmV0d29yayBsYXll ciwgbm90IHJpZ2h0IGF0IHRoZSBuZXR3b3JrIGxheWVyKS48L3NwYW4+PG86cD48L286cD48L3A+ DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+QW1vbmcgdGhlIGxpc3RlZCBwcm90b2NvbHMgdGhlIG9uZXMgcHJl Y2lzZWx5IGF0IG5ldHdvcmtpbmcgbGF5ZXIgYXJlOg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPklQdjQsIElQdjYgYW5kIElQWC4mbmJzcDsgQWxsIHRoZSBvdGhlcnMg YXJlIGEgbGl0dGxlIGJpdCBhYm92ZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+SSBoYXZlIHNlZW4gSVB2NCBhbmQgSVB2NiBvdmVyIDgwMi4xMSBPQ0IsIGJ1dCBJIGhh dmUgbm90IHNlZW4gSVBYIHJ1biBvbiA4MDIuMTEgT0NCLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5TdGF0aW5nIHRoYXQgSVBYIF9jb3VsZF8gcnVuIG9uIDgwMi4xMSBP Q0IgaXMgYSB0aGVvcmV0aWNhbCBhc3N1bXB0aW9uLCBidXQgaW4gcHJhY3RpY2UgeW91IG5ldmVy IGtub3cuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZXJlIGlzIGEg aHVnZSBkaWZmZXJlbmNlIGJldHdlZW4gc3RhdGluZyBJUCBydW5zIG9uIDgwMi4xMSBPQ0IgYW5k IHN0YXRpbmcgdGhhdCBJUFggcnVucyBvbiA4MDIuMTEgT0NCLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgcHJvdG9jb2xzIEkgaGF2ZSBzZWVuIHJ1bm5pbmcgb24g ODAyLjExIE9DQiBhcmUgSVAsIEVUU0kgZ2VvbmV0d29ya2luZyBhbmQgQlNNLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JIHRoaW5rIGl0IHdvdWxkIGJlIGdvb2QgdGhh dCBEU1JDIHNhaWQgJnF1b3Q7ODAyLjExIE9DQiBzdXBwb3J0cyBuZXR3b3JrLWxheWVyJm5ic3A7 IHByb3RvY29scyBzdWNoIGFzIElQLCBFVFNJIGdlb25ldHdvcmtpbmcgYW5kIEJTTSZxdW90Oywg cmF0aGVyIHRoYW4gc2F5aW5nICZxdW90OzgwMi4xMSBPQ0Igc3VwcG9ydHMgX2FueV8gbmV0d29y ayBsYXllciBwYXJvdG9jb2xzJnF1b3Q7Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4mZ3Q7IMK3X19fQ0xOUF8mbHQ7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vZW4ud2lr aXBlZGlhLm9yZy93aWtpL0NMTlAiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5odHRwczovL2VuLndpa2lwZWRpYS5v cmcvd2lraS9DTE5QPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0O0Nvbm5lY3Rpb25sZXNzDQog TmV0d29ya2luZyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyBQ cm90b2NvbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IMK3X19fRUdQXyZsdDs8L3Nw YW4+PGEgaHJlZj0iaHR0cHM6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvRXh0ZXJpb3JfR2F0ZXdh eV9Qcm90b2NvbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPmh0dHBzOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL0V4 dGVyaW9yX0dhdGV3YXlfUHJvdG9jb2w8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7RXh0ZXI8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyBpb3IgR2F0ZXdheSBQ cm90b2NvbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IMK3X19fRUlHUlBfJmx0Ozwv c3Bhbj48YSBocmVmPSJodHRwczovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9FSUdSUCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPmh0dHBzOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL0VJR1JQPC9zcGFuPjwvYT48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+Jmd0O0VuaGFuY2VkDQogSW50ZXJpb3IgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiZndDsgR2F0ZXdheSBSb3V0aW5nIFByb3RvY29sPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiZndDsgwrdfX19JQ01QXyZsdDtodHRwczovL2VuLndpa2lwZWRpYS5v cmcvd2lraS9JbnRlcm5ldF9Db250cm9sX01lc3NhZ2VfUHJvdG88L3NwYW4+PG86cD48L286cD48 L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyBjb2wmZ3Q7SW50ZXJuZXQ8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyBDb250cm9sIE1lc3NhZ2UgUHJvdG9jb2w8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyDCt19fX0lHTVBfJmx0Ozwvc3Bhbj48YSBocmVm PSJodHRwczovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9JR01QIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+aHR0cHM6 Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvSUdNUDwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDtJ bnRlcm5ldA0KIEdyb3VwIE1hbmFnZW1lbnQgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiZndDsgUHJvdG9jb2w8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyDC t19fX0lHUlBfJmx0Ozwvc3Bhbj48YSBocmVmPSJodHRwczovL2VuLndpa2lwZWRpYS5vcmcvd2lr aS9JR1JQIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+aHR0cHM6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvSUdSUDwv c3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDtJbnRlcmlvcg0KIEdhdGV3YXkgUm91dGluZyA8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyBQcm90b2NvbDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IMK3X19fSVB2NF8mbHQ7PC9zcGFuPjxhIGhyZWY9Imh0 dHBzOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL0lQdjQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5odHRwczovL2Vu Lndpa2lwZWRpYS5vcmcvd2lraS9JUHY0PC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0O0ludGVy bmV0DQogUHJvdG9jb2wgdmVyc2lvbiA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+Jmd0OyA0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsg PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgwrdfX19JUHY2XyZs dDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvSVB2NiI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPmh0dHBzOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL0lQdjY8L3NwYW4+PC9hPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4mZ3Q7SW50ZXJuZXQNCiBQcm90b2NvbCB2ZXJzaW9uIDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IDY8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jmd0OyDCt19fX0lQU2VjXyZsdDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9lbi53aWtpcGVk aWEub3JnL3dpa2kvSVBTZWMiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5odHRwczovL2VuLndpa2lwZWRpYS5vcmcv d2lraS9JUFNlYzwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDtJbnRlcm5ldA0KIFByb3RvY29s IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IFNlY3VyaXR5PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgwrdfX19JUFhfJmx0Ozwvc3Bhbj48YSBocmVm PSJodHRwczovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9JUFgiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5odHRwczov L2VuLndpa2lwZWRpYS5vcmcvd2lraS9JUFg8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7SW50 ZXJuZXR3b3JrDQogUGFja2V0IGNoYW5nZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4mZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7 IMK3X19fTkFUXyZsdDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9lbi53aWtpcGVkaWEub3JnL3dp a2kvTmV0d29ya19hZGRyZXNzX3RyYW5zbGF0aW9uIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+aHR0cHM6Ly9lbi53 aWtpcGVkaWEub3JnL3dpa2kvTmV0d29ya19hZGRyZXNzX3RyYW5zbGF0aW9uPC9zcGFuPjwvYT48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+Jmd0O05ldDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4mZ3Q7IHdvcms8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyBB ZGRyZXNzIFRyYW5zbGF0aW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgwrdfX19S b3V0ZWQtU01MVF8mbHQ7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vZW4ud2lraXBlZGlhLm9yZy93 aWtpL1ItU01MVCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPmh0dHBzOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL1It U01MVDwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jmd0OyDCt19fX1NDQ1BfJmx0O2h0dHBzOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL1NpZ25h bGxpbmdfQ29ubmVjdGlvbl9Db250cm9sXzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4mZ3Q7IFBhcnQmZ3Q7U2lnbmFsbGluZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4mZ3Q7IENvbm5lY3Rpb24gQ29udHJvbCBQYXJ0PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiZndDsgwrdBcHBsZVRhbGsgRERQPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiZndDsgwrdfX19HUkVfJmx0Ozwvc3Bhbj48YSBocmVmPSJodHRwczovL2VuLndpa2lwZWRp YS5vcmcvd2lraS9HZW5lcmljX1JvdXRpbmdfRW5jYXBzdWxhdGlvbiI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPmh0 dHBzOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL0dlbmVyaWNfUm91dGluZ19FbmNhcHN1bGF0aW9u PC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0O0c8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+Jmd0OyBlbmVyaWM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+Jmd0OyBSb3V0aW5nIEVuY2Fwc3VsYXRpb24gZm9yIHR1bm5lbGluZzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4mZ3Q7IMK3X19fT1NQRl8mbHQ7PC9zcGFuPjxhIGhyZWY9Imh0dHBz Oi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL09TUEYiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5odHRwczovL2VuLndp a2lwZWRpYS5vcmcvd2lraS9PU1BGPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0O09wZW4NCiBT aG9ydGVzdCBQYXRoIEZpcnN0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgwrdfX19S SVBfJmx0Ozwvc3Bhbj48YSBocmVmPSJodHRwczovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9Sb3V0 aW5nX0luZm9ybWF0aW9uX1Byb3RvY29sIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+aHR0cHM6Ly9lbi53aWtpcGVk aWEub3JnL3dpa2kvUm91dGluZ19JbmZvcm1hdGlvbl9Qcm90b2NvbDwvc3Bhbj48L2E+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiZndDtSbzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7 IHV0aW5nPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgSW5mb3Jt YXRpb24gUHJvdG9jb2w8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0 OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyDCt19fX0hTUlBf Jmx0Ozwvc3Bhbj48YSBocmVmPSJodHRwczovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9Ib3RfU3Rh bmRieV9Sb3V0ZXJfUHJvdG9jb2wiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5odHRwczovL2VuLndpa2lwZWRpYS5v cmcvd2lraS9Ib3RfU3RhbmRieV9Sb3V0ZXJfUHJvdG9jb2w8L3NwYW4+PC9hPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4mZ3Q7SG88L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyB0PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgU3RhbmRieSBSb3V0ZXIg cHJvdG9jb2w8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyDCt19fX1ZSUlBfJmx0O2h0 dHBzOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL1ZpcnR1YWxfUm91dGVyX1JlZHVuZGFuY3lfUHJv dDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IG9jb2wmZ3Q7Vmly dHVhbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IFJvdXRlciBS ZWR1bmRhbmN5IFByb3RvY29sPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsg4oCcL0Fu IFJTVSBwcm9kdWN0IGhhcyBtYW55IHRyYW5zY2VpdmVycyBpbnNpZGUuLy/igJ0vLy88L3NwYW4+ PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyAtLy8gQW4gUlNFIG1heSBoYXZlIG11bHRpcGxlIHRy YW5zY2VpdmVycy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SSB0aGlu ayB0aGVyZSBpcyBhIGh1Z2UgdGVybWlub2xvZ3kgaXNzdWUgaGVyZS48L3NwYW4+PG86cD48L286 cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+JnF1b3Q7UlNFJnF1b3Q7IGlzIG5vdCB1c2VkLCBJIG5l dmVyIGhlYXJkIGl0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Nb3N0 IHBlb3BsZSBzYXkgJnF1b3Q7UlNVJnF1b3Q7IHRvIG1lYW4gYSAmcXVvdDtib3gmcXVvdDsgd2hl cmVhcyB0aGUgRkNDIHRlcm0gUlNVIHNlZW0gdG8gbWVhbiBqdXN0IGEgJnF1b3Q7dHJhbnNjZWl2 ZXImcXVvdDsuJm5ic3A7IEEgJnF1b3Q7dHJhbnNjZWl2ZXImcXVvdDsgaXMgdHlwaWNhbGx5IGEg JnF1b3Q7bW9kZW0mcXVvdDsuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PlByb2R1Y3RzIGFyZSBtYXJrZXRlZCBhcyAmcXVvdDtSU1UmcXVvdDsgYW5kIHRoZXkgYXJlIGJv eGVzLiZuYnNwOyBUaGV5IGhhdmUgbXVjaCBtb3JlIGluc2lkZSB0aGFuIGp1c3QgdGhlICZxdW90 O3RyYW5zY2VpdmVyJnF1b3Q7LiZuYnNwOyBXaGF0IGNvdWxkIGJlIHVuZGVyc3Rvb2QgYXMgJ3Ry YW5zY2VpdmVyJyAodHJhbnNtaXR0ZXIvcmVjZWl2ZXIpIGlzIHRoZSBtb2RlbTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4obW9kdWxhdG9yL2RlbW9kdWxhdG9yKSBvciAn YmFzZWJhbmQnIHByb2Nlc3NvciwgdGhhdCBzaXRzIG9uIGFuIGV4dGVuc2lvbiBib2FyZCB0aGF0 IGl0c2VsZiBzaXRzIG9uIGEgbW90aGVyYm9hcmQuJm5ic3A7IFRoZXJlIGlzIHBvd2VyIHN1cHBs eSB0b28uJm5ic3A7IEFsbCB0aGVzZSBtYWtlIGFuICZxdW90O1JTVSZxdW90Oy4mbmJzcDsgU29t ZSBSU1VzIGhhdmUgZXZlbiBtb3JlDQogZGV2aWNlcyBsaWtlIHNvbGFyIHBhbmVscywgbWVjaGFu aWNhbCBob29rcywgc29waGlzdGljYXRlZCBhbnRlbm5hcywgRVYgY2hhcmdlIHN0YXRpb25zLCBM VEUgbW9kZW1zLCBvcHRpY2FsIGJhY2toYXVsIGFuZCBtb3JlLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5CRWNhdXNlIG9mIHRoaXMgZGlzY3JlcGFuY3ksIEkgcHJlZmVy IHRvIGZvcmdldCB1c2UgaGlzICZxdW90O1JTVSZxdW90OyB0ZXJtIGluIHRoaXMgSVAtb3Zlci1P Q0IgZG9jdW1lbnQganVzdCBhcyBmb3IgaW5mb3JtYXRpb24uJm5ic3A7IFJBdGhlciwgdXNlIHRo ZSAmcXVvdDtJUC1SU1UmcXVvdDsgdG8gbWVhbiB3aGF0IHdlIHdhbnQgaXQgdG8gbWVhbi48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QWxleDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4mZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgRnJvbTogQWxleGFuZHJlIFBldHJlc2N1IFs8 L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmFsZXhhbmRyZS5wZXRyZXNjdUBnbWFpbC5jb20iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5tYWlsdG86YWxleGFuZHJlLnBldHJlc2N1QGdtYWlsLmNvbTwvc3Bhbj48L2E+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPl08L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyBT ZW50OiBTdW5kYXksIEZlYnJ1YXJ5IDA0LCAyMDE4IDEwOjQ5IEFNPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgVG86IEZyYW7Dp29pcyBTaW1vbiAmbHQ7PC9zcGFu PjxhIGhyZWY9Im1haWx0bzpmeWdzaW1vbkBnbWFpbC5jb20iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5meWdzaW1v bkBnbWFpbC5jb208L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgQ2M6PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4N Cjwvc3Bhbj48YSBocmVmPSJtYWlsdG86aXRzQGlldGYub3JnIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+aXRzQGll dGYub3JnPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IFN1 YmplY3Q6IFJlOiBbaXB3YXZlXSBTaGVwaGVyZCByZXZpZXcgb2Y8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyBkcmFmdC1pZXRmLWlwd2F2ZS1pcHY2LW92ZXItODAy MTFvY2ItMTI8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyBMZSAwMi8wMi8yMDE4IMOg IDExOjIzLCBGcmFuw6dvaXMgU2ltb24gYSDDqWNyaXQmbmJzcDs6PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiZndDsmZ3Q7IE1yLiBQZXRyZXNjdSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jmd0OyZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsg PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7IExldCdzIHRy eSBvbmUgbW9yZSB0aW1lIHRvIGNsYXJpZnkgdGhlIEZDQyBEU1JDIChpbiBVUyBvbmx5KSBpc3N1 ZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDsgPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiZndDsmZ3Q7ICpGQ0Mg4oCTIERTUkMqPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiZndDsmZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7 IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyAqQmFja2dy b3VuZDoqKio8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDsgPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7ICoqPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZn dDsmZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyAtKiogVGhlIFVTIEZl ZGVyYWwgQ29tbXVuaWNhdGlvbnMgQ29tbWlzc2lvbiAoRkNDKSBEZWRpY2F0ZWQgU2hvcnQ8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDsgUmFuZ2UgQ29tbXVuaWNhdGlvbiAoRFNS QykgaXMgZGVmaW5lZCBpbiB0aGUgQ29kZSBvZiBGZWRlcmFsPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiZndDsmZ3Q7IFJlZ3VsYXRpb25zIChDRlIpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiZndDsmZ3Q7IDQ3IG1haW5seSBQYXJ0cyA5MCBhbmQgOTUuIFRoZSBsYXN0IHVwZGF0ZSBp cyBkYXRlZCBPY3RvYmVyIDFzdCwNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4mZ3Q7Jmd0OyAyMDEwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4mZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyA8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDsgLVRoaXMgaW5jbHVkZXMgdGhlIEFT VE0gRSAyMjEzLTAzIHN0YW5kYXJkOiDigJxTdGFuZGFyZCBTcGVjae+sgWNhdGlvbg0KPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7IGZvcjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyBUZWxlY29tbXVuaWNhdGlvbnMgYW5kIEluZm9ybWF0 aW9uIEV4Y2hhbmdlIEJldHdlZW4gUm9hZHNpZGUgYW5kPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiZndDsmZ3Q7IFZlaGljbGUgU3lzdGVtcyDigJQgNSBHSHogQmFuZCBEZWRpY2F0ZWQgU2hv cnQgUmFuZ2UgQ29tbXVuaWNhdGlvbnM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZn dDsgKERTUkMpIE1lZGl1bSBBY2Nlc3MgQ29udHJvbCAoTUFDKSBhbmQgUGh5c2ljYWwgTGF5ZXIg KFBIWSk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDsgU3BlY2nvrIFjYXRpb25z 4oCdOyBhcHByb3ZlZCBKdWx5IDEwLCAyMDAzLiBUaGUgc3RhbmRhcmQgaXMgZGVyaXZlZCBmcm9t PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7IElFRUUgODAyLjExYSBhbmQsIGlu IG1vc3QgcGFydCwgaXMgZXF1aXZhbGVudCB0byBJRUVFIDgwMi4xMSBPQ0IuIFRvPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7IGRhdGUsIHRoZSBEU1JDIENGUnMgZG8gbm90IHNw ZWNpZnkgSUVFRSA4MDIuMTEgT0NCLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4mZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0 OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDsgLVRoZSByZWxhdGVkIENGUnMg c3RhdGUgdGhhdCBEU1JDIHNoYWxsIGNvbXBseSB3aXRoIHRoZSBBU1RNIEUgMjIxMy0wMy48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyBUaGFuayB5b3UgZm9yIHRoZSBleHBsYW5hdGlv bi4mbmJzcDsgSXQgaXMgdXNlZnVsIHRvIHVuZGVyc3RhbmQgdGhhdCBEU1JDDQo8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyBpcyByZWxhdGVkIHRvIEFTVE0gRSAy MjEzLTAzIGFuZCB0aGF0IG5laXRoZXIgcmVmZXJzIHRvIDgwMi4xMSBPQ0IuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiZndDsgSSB0aGluayBpbiB3b3JrcyByZWxhdGVkIHRvIHN0YW5kYXJk cyBhbmQgcHJvZHVjdHMgaXQgaXMgYWR2YW50YWdlb3VzDQo8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+Jmd0OyBpZiB0aGVyZSBpcyBjb3JyZWxhdGlvbi48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+Jmd0OyBGb3IgZXhhbXBsZSwgaW4gYW4gaWRlYWwgd29ybGQsIHN0 YW5kYXJkcyB0YWxrIGFib3V0ICZxdW90O0EmcXVvdDsgYW5kIHRoZQ0KPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgcmVndWxhdGlvbiBhbHNvIGFib3V0ICZxdW90 O0EmcXVvdDsgYW5kIHRoZSBwcm9kdWN0cyBhbmQgc29md2FyZSBhcmUgYWxzbw0KPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgbGFiZWxsZWQgJnF1b3Q7QSZxdW90 Oy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyBJbiBvdXIgY29udGV4dCwgc29mdHdh cmUgaXMgbGFiZWxsZWQgJnF1b3Q7T0NCJnF1b3Q7IChrZXJuZWwgZHJpdmVycyksDQo8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyByZWd1bGF0aW9uIHRhbGtzICZx dW90O0RTUkMmcXVvdDsgYW5kIHN0YW5kYXJkcyAmcXVvdDs4MDIuMTFwJnF1b3Q7IGFuZCAmcXVv dDs4MDIuMTEgT0NCJnF1b3Q7Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4mZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyAq T3ZlcnZpZXcgb2YgRFNSQyBmdW5jdGlvbnM6KioqPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PiZndDsmZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyAqKjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ Jmd0OyZndDsgVGhlIGZ1bmN0aW9ucyBsaXN0ZWQgaW4gRFNSQyByZWxhdGVkIENGUnMgYXJlLCBp biBnZW5lcmFsLCBzcGVjaWZpZWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDsg aW4gdGhlIEFTVE0gRSAyMjEzLTAzIGFuZCBJRUVFIDgwMi4xMSBPQ0I6PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiZndDsmZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4mZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0 OyAtTUFDIHNlcnZpY2UgZGVmaW5pdGlvbiwgZnJhbWUgZm9ybWF0LCBhbmQgcHJvY2VkdXJlczs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiZndDsmZ3Q7IC1QSFkgT3J0aG9nb25hbCBmcmVxdWVuY3kgZGl2aXNpb24gbXVsdGlw bGV4aW5nIChPRkRNKTs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0 OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDsgPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7IC1QSFkgU2VydmljZSBEYXRhIFVuaXQgZm9y bWF0IGFuZCBtb2R1bGF0aW9ucyAoZGF0YSByYXRlcyk6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiZndDsmZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7 IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyAtNS45IEdI eiBiYW5kIGFsbG9jYXRlZCBjaGFubmVscywgZnJlcXVlbmN5LCBtYXguIEVJUlAsIGFuZCBzcGVj dHJ1bTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyBtYXNrOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0 OyZndDsgLUluZGl2aWR1YWwgQ2hhbm5lbCB1c2U6IFNhZmV0eSBhcHBsaWNhdGlvbnMsIG5vbi1z YWZldHkNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyBh cHBsaWNhdGlvbnMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsg PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7IGFuZCBwcmlv cml0aWVzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyA8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+Jmd0OyZndDsgKlByb3RvY29scyoqKjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4mZ3Q7Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDsgKio8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiZndDsmZ3Q7IERTUkMgYmVpbmcgdW5pcXVlbHkgYSBNQUMgYW5kIFBIWSBjb21tdW5p Y2F0aW9ucyBzZXJ2aWNlLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4m Z3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IEkgdGhvdWdo dCAmcXVvdDtEU1JDJnF1b3Q7IGlzIGFsc28gYWJvdXQgQXBwbGljYXRpb25zIGFuZCBVc2UtY2Fz ZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7IHRoZXJlIGhlcmUgbm88L3Nw YW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDsgcmVzdHJpY3Rpb24gb24gVHJhbnNwb3J0 IGFuZCBOZXR3b3JrIHByb3RvY29scyB0aGF0IGNhbiBiZSB1c2VkPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiZndDsmZ3Q7IChleGNlcHQgZm9yIHRoZSBMQ0Mgc3BlY2lmaWVkIGJ5IHJlZmVy ZW5jZSBpbiBJRUVFIDgwMi4xMSBPQ0IpLiBJbg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiZndDsmZ3Q7IHRoZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4mZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7 Jmd0OyBVUywgdGhlIFdBVkUgc3RhbmRhcmRzIChJRUVFIDE2MDkgc2VyaWVzKSBzcGVjaWZ5IHRo ZXNlIHByb3RvY29scw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZn dDsmZ3Q7IHdoZW48L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDsgdXNpbmcgRFNS QyBhcyB0aGUgY29tbXVuaWNhdGlvbiBzZXJ2aWNlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4mZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4mZ3Q7IEl0IGlzIG9uZSB0aGluZyB0byBoYXZlIG5vIHJlc3RyaWN0aW9ucywgYW5kIGFub3Ro ZXIgdGhpbmcgdG8gcmVja29uDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jmd0OyB0aGF0IElQIGlzIHRoZSBuZXR3b3JraW5nIGxheWVyLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4mZ3Q7Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDsg Kk9CVSAvIFJTVSoqKjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7 IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyA8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDsgKio8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jmd0OyZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsg PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7IFRoZSBDRlIg KEZDQykgZGVmaW5pdGlvbnMgYXJlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4mZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0 OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDsgL1JvYWRzaWRlIHVuaXQgKFJT VSkuIEEgUm9hZHNpZGUgVW5pdCBpcyBhIERTUkMgdHJhbnNjZWl2ZXI8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+Jmd0OyBTaWdoLCBpdCBpcyB3YXkgZGlmZmVyZW50Ljwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4mZ3Q7IEFuIFJTVSBwcm9kdWN0IGhhcyBtYW55IHRyYW5zY2VpdmVycyBp bnNpZGUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7IHRoYXQgaXM8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDsgbW91bnRlZCBhbG9uZyBhIHJvYWQgb3IgcGVk ZXN0cmlhbiBwYXNzYWdld2F5LiBBbiBSU1UgbWF5IGFsc28gYmU8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+Jmd0OyZndDsgbW91bnRlZCBvbiBhIHZlaGljbGUgb3IgaXMgaGFuZCBjYXJyaWVk LCBidXQgaXQgbWF5IG9ubHkgb3BlcmF0ZSB3aGVuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PiZndDsmZ3Q7IHRoZSB2ZWhpY2xlIG9yIGhhbmQtIGNhcnJpZWQgdW5pdCBpcyBzdGF0aW9uYXJ5 LiBGdXJ0aGVybW9yZSwgYW4gUlNVPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7 IG9wZXJhdGluZyB1bmRlciB0aGlzIHBhcnQgaXMgcmVzdHJpY3RlZCB0byB0aGUgbG9jYXRpb24g d2hlcmUgaXQgaXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDsgbGljZW5zZWQg dG8gb3BlcmF0ZS4gSG93ZXZlciwgcG9ydGFibGUgb3IgaGFuZC1oZWxkIFJTVXMgYXJlDQo8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDsgcGVybWl0dGVkPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7IHRvIG9wZXJhdGUgd2hlcmUgdGhleSBk byBub3QgaW50ZXJmZXJlIHdpdGggYSBzaXRlLWxpY2Vuc2VkIG9wZXJhdGlvbi4NCjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyBBIFJTVSBicm9hZGNhc3RzIGRhdGEgdG8gT0JV cyBvciBleGNoYW5nZXMgZGF0YSB3aXRoIE9CVXMgaW4gaXRzPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiZndDsmZ3Q7IGNvbW11bmljYXRpb25zIHpvbmUuIEFuIFJTVSBhbHNvIHByb3ZpZGVz IGNoYW5uZWwgYXNzaWdubWVudHMgYW5kPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsm Z3Q7IG9wZXJhdGluZyBpbnN0cnVjdGlvbnMgdG8gT0JVcyBpbiBpdHMgY29tbXVuaWNhdGlvbnMg em9uZSwgd2hlbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyByZXF1aXJlZC4v LSBbQ0ZSIDkwLjcgLSBEZWZpbml0aW9uc10gLSBSZXZpc2VkIGFzIE9jdG9iZXIgMjAxMC48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyBJIHRoaW5rIGl0IHNob3VsZCBiZSB1cGRhdGVk IHRvIHJlZmVyIHRvIHRoaXMgZG9jdW1lbnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZn dDsmZ3Q7IC9Pbi1Cb2FyZCB1bml0IChPQlUpLiBBbiBPbi1Cb2FyZCBVbml0IGlzIGEgRFNSQ1Mg dHJhbnNjZWl2ZXIgdGhhdCBpczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4mZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyBu b3JtYWxseSBtb3VudGVkIGluIG9yIG9uIGEgdmVoaWNsZSwgb3Igd2hpY2ggaW4gc29tZSBpbnN0 YW5jZXMgbWF5DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZn dDsgYmU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDsgYSBwb3J0YWJsZSB1bml0 LiBBbiBPQlUgY2FuIGJlIG9wZXJhdGlvbmFsIHdoaWxlIGEgdmVoaWNsZSBvciBwZXJzb248L3Nw YW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDsgaXMgZWl0aGVyIG1vYmlsZSBvciBzdGF0 aW9uYXJ5LiBUaGUgT0JVcyByZWNlaXZlIGFuZCBjb250ZW5kIGZvciB0aW1lPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7IHRvIHRyYW5zbWl0IG9uIG9uZSBvciBtb3JlIHJhZGlv IGZyZXF1ZW5jeSAoUkYpIGNoYW5uZWxzLiBFeGNlcHQNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyB3aGVyZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4mZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4mZ3Q7Jmd0OyBzcGVjaWZpY2FsbHkgZXhjbHVkZWQsIE9CVSBvcGVyYXRpb24gaXMgcGVybWl0 dGVkIHdoZXJldmVyIHZlaGljbGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDsg b3BlcmF0aW9uIG9yIGh1bWFuIHBhc3NhZ2UgaXMgcGVybWl0dGVkLiBUaGUgT0JVcyBtb3VudGVk IGluIHZlaGljbGVzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsg PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7IGFyZSBsaWNl bnNlZCBieSBydWxlIHVuZGVyIHBhcnQgOTUgb2YgdGhpcyBjaGFwdGVyIGFuZCBjb21tdW5pY2F0 ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyB3aXRoIFJvYWRzaWRlIFVuaXRz IChSU1VzKSBhbmQgb3RoZXIgT0JVcy4gUG9ydGFibGUgT0JVcyBhcmUgYWxzbzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyBsaWNlbnNlZCBieSBydWxlIHVuZGVyIHBhcnQgOTUg b2YgdGhpcyBjaGFwdGVyLiBPQlUgb3BlcmF0aW9ucyBpbiB0aGU8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+Jmd0OyZndDsgVW5saWNlbnNlZCBOYXRpb25hbCBJbmZvcm1hdGlvbiBJbmZyYXN0 cnVjdHVyZSAoVU5JSSkgQmFuZHMgZm9sbG93DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+Jmd0OyZndDsgdGhlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsm Z3Q7IHJ1bGVzIGluIHRob3NlIGJhbmRzLi8tIFtDRlIgOTAuNyAtIERlZmluaXRpb25zXSAtIE9j dG9iZXIgMjAxMDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IFRoYW5rcyBmb3IgdGhl IGRlZmluaXRpb25zLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7 IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IFRoZXkgYXJlIGZh ciBkaWZmZXJlbnQgZnJvbSB3aGF0IHdlIG5lZWQgaW4gdGhpcyBkcmFmdC48L3NwYW4+PG86cD48 L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+Jmd0OyBJIHdpbGwgc2VlIHRoZSBvdGhlciBzdWdnZXN0aW9ucy48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyBBbGV4PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiZndDsmZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7 IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyAqSVBXQVZF IElzc3VlKioqPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7IDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyAqKjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4mZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4m Z3Q7Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDsgL+KAnFRoZSBwcm9i bGVtIHdpdGggdGhlIEZDQyBkZWZpbml0aW9uIG9mIE9CVSBpcyB0aGF0IGl0IGhhcyBubzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyByZWxhdGlvbnNoaXAgdG8gSVAuJm5ic3A7 IFdvcnNlLCB0aGF0IEZDQyBkZWZpbml0aW9uIGhhcyBubyBpbmRpY2F0aW9uDQo8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDsgdGhhdDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyBpdCBNQVkgdXNlIElQIHNvbWVob3cuJm5ic3A7IEFuZCBo ZXJlIHdlIHNheSB0aGF0IGFsbCBPQlVzIG11c3QgdXNlIElQLiZuYnNwOw0KPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7IERvPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiZndDsmZ3Q7IHlvdSBzZWUgd2hhdCBJIG1lYW4/4oCdLy8vPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4mZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7 Jmd0OyAvLzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyA8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+Jmd0OyZndDsgQ29ycmVjdDsgdGhlIE9CVSBoYXMgbm8gcmVsYXRpb25z aGlwIHdpdGggSVAgYW5kIGlzIG5vdCBpbnRlbmRlZCB0by4NCjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4mZ3Q7Jmd0OyBJUCBpcyBhIG5ldHdvcmsgcHJvdG9jb2wuJm5ic3A7IElmIGFuIE9u LUJvYXJkIFVuaXQgKE9CVSkgZGV2aWNlIGlzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZn dDsmZ3Q7IHJlcXVpcmVkIHRvIGV4Y2hhbmdlIElQLCBpdCBuZWVkcyB0byBiZSBkZWFsdCBpbiBw cm90b2NvbChzKSBhbmQvb3I8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDsgTWFu YWdlbWVudCBpbiBoaWdoZXIgbGF5ZXJzIHNpbWlsYXIgdG8gV0FWRSB3aXRoaW4gdGhlIE9uLUJv YXJkIEVxdWlwbWVudCAoT0JFKSAuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7 IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyAv4oCcRG8geW91IHRoaW5rIEZD QyB3aWxsIG1pbmQgaWYgd2UgdXNlIHRoZSB0ZXJtIE9CVSBpbiB0aGlzIGRyYWZ0IHRvPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7IG1lYW4gc29tZXRoaW5nIGVsc2U/Jm5ic3A7 IEksIGFuZCBhIGNvbGxlYWd1ZSwgdGhpbmsgdGhhdCBGQ0Mgd291bGQgbm90PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7IG1pbmQu4oCdLy8vPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiZndDsmZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4m Z3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyAvLzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+Jmd0OyZndDsgRGVwZW5kaW5nIG9mIHRoZSByZWFkZXIuIElmIG9uZSBpcyBmYW1pbGlh ciB3aXRoIERTUkMsIE9CVSBhbmQgUlNVIGFzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZn dDsmZ3Q7IGRlZmluZWQgYnkgRkNDIHdpbGwgY29tZSBpbiBtaW5kLiBBcyBmYXIgYXMgSSBrbm93 LCDigJxPQlXigJ0gYW5kIOKAnFJTVeKAnQ0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZn dDsmZ3Q7IGFyZSBub3QgcmVnaXN0ZXJlZCBhbmQgY291bGQgYmUgdXNlZCBmb3Igb3RoZXIgZGVm aW5pdGlvbnMgKHNvbWV0aGluZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4mZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyBs aWtlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7IOKAnEFUTeKAnTogQXN5bmNo cm9ub3VzIFRyYW5zZmVyIE1vZGUgYW5kIEF1dG9tYXRpYyBUZWxsZXIgTWFjaGluZTwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJIEVtb2pp JnF1b3Q7LHNhbnMtc2VyaWYiPiYjMTI4NTIyOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+KS4NCiBNeTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyBzdWdnZXN0aW9uIHRvIHRoZSBJUFdB VkUgdGVhbSBpcyB0byB1c2Ug4oCcT0JFIGFuZCBSU0XigJ0uPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiZndDsmZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4m Z3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyBUaGlz IGlzIG15IHBlcnNvbmFsIHZpZXcgYXMgSSBkb25vdCByZXByZXNlbnQgYW55IGludm9sdmVkIGlu dGVyZXN0LiZuYnNwOw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZn dDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7IElmIGFu eSBvbmUgaGFzIHF1ZXN0aW9ucywgbGV0IG1lIGtub3cuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiZndDsmZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7 IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyBGcmFuY29p cyBTaW1vbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyA8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+Jmd0OyZndDsgTG9qaWsgVGVjaG5vbG9naWVzPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiZndDsmZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4mZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0 OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4mZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4m Z3Q7Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDsgRnJvbTogaXRzIFs8 L3NwYW4+PGEgaHJlZj0ibWFpbHRvOml0cy1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ bWFpbHRvOml0cy1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+XQ0KIE9u IEJlaGFsZiBPZiBBbGV4YW5kcmU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDsg UGV0cmVzY3U8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDsgPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7IFNlbnQ6IE1vbmRheSwgSmFudWFyeSAyOSwgMjAxOCAx MDowOCBBTTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyA8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+Jmd0OyZndDsgVG86aXRzQGlldGYub3JnJmx0Ozwvc3Bhbj48YSBocmVm PSJtYWlsdG86aXRzQGlldGYub3JnIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+bWFpbHRvOml0c0BpZXRmLm9yZzwv c3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0 OyZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBb aXB3YXZlXSBTaGVwaGVyZCByZXZpZXcgb2Y8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0 OyZndDsgZHJhZnQtaWV0Zi1pcHdhdmUtaXB2Ni1vdmVyLTgwMjExb2NiLTEyPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4mZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7 Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDsgPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiZndDsmZ3Q7IExlIDI5LzAxLzIwMTggw6AgMTU6NTIsIEZyYW7Dp29pcyBT aW1vbiBhIMOpY3JpdCA6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZn dDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7IDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyZndDsgTXkgY29tbWVudHMgYXJld2l0aGlu IHRoZSB0ZXh0KltGeWdzLi4uLi4uLl0qLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4mZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7 Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDsgWy4uLl08L3NwYW4+PG86 cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZn dDsmZ3Q7Jmd0OyBJbiB0aGUgdGVybWlub2xvZ3kgc2VjdGlvbiwgdGhlIE9CVSB0ZXJtIGlzIG1l bnRpb25lZCB0byBiZSBkZWZpbmVkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7 IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyZndDsgb3V0c2lkZSB0aGUgSUVU Ri4gVGhpcyBpcyBmaW5lLCBidXQgd2UgaGF2ZSB0byBwcm92aWRlIGEgcmVmZXJlbmNlLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jmd0OyZndDsmZ3Q7IEFuZCBldmVuIHdpdGggdGhhdCwgaXQgd291bGQgbm90IGhhcm0gdG8g aW5jbHVkZSBzb21lIHNob3J0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7Jmd0 OyBkZWZpbml0aW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsg PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7IDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyZndDsgdG8gcHJvdmlkZSBjb250ZXh0LiBUaGUg UlNVIHRlcm0gaXMgYWxzbyBkZWZpbmVkIG91dHNpZGUgdGhlIElFVEYNCjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyZndDsgYW5kPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiZndDsmZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4mZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0 OyZndDsgdGhlcmUgaXMgcXVpdGUgYSBsb3Qgb2YgdGV4dCBwcm92aWRlZCAoSSB0aGluayB0aGUg cmVsZXZhbnQgcGFydCBpczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4m Z3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyA8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDsmZ3Q7IHRoZSBsYXN0IHNlbnRlbmNlLCB0 aGUgb25lIHN0YXJ0aW5nIHdpdGggJnF1b3Q7VGhlIGRpZmZlcmVuY2UgYmV0d2Vlbi4uLiZxdW90 OykuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDsgPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiZndDsmZ3Q7Jmd0OyBCb3RoIHRlcm1zIHNob3VsZCBiZSBoYW5kbGVkIGlu IHRoZSBzYW1lIHdheS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0 OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDsgPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+Jmd0OyZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZn dDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7Jmd0OyAq W0Z5Z3M6IFRoZSoqZGVmaW5pdGlvbnMqKndhcyBpc3N1ZWQgYnkgdGhlIEZDQyAyMCB5ZWFycyBh Z28uJm5ic3A7IEkNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7 Jmd0OyZndDsgaGF2ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7 IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyA8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDsmZ3Q7IGFscmVhZHkgcHJvdmlkZWQgdGhhdCBp bmZvcm1hdGlvbioqYW5kIHJlZmVyZW5jZXMgbXVsdGlwbGU8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+Jmd0OyZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZn dDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7Jmd0OyB0 aW1lcy5dKioqPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7IDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyBUaGUgcHJvYmxlbSB3aXRoIHRoZSBGQ0MgZGVmaW5p dGlvbiBvZiBPQlUgaXMgdGhhdCBpdCBoYXMgbm88L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ Jmd0OyZndDsgcmVsYXRpb25zaGlwIHRvIElQLiZuYnNwOyBXb3JzZSwgdGhhdCBGQ0MgZGVmaW5p dGlvbiBoYXMgbm8gaW5kaWNhdGlvbg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiZndDsmZ3Q7IHRoYXQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDsg aXQgTUFZIHVzZSBJUCBzb21laG93LiZuYnNwOyBBbmQgaGVyZSB3ZSBzYXkgdGhhdCBhbGwgT0JV cyBtdXN0IHVzZSBJUC4mbmJzcDsNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4mZ3Q7Jmd0OyBEbzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4m Z3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyB5b3Ug c2VlIHdoYXQgSSBtZWFuPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4m Z3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyA8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDsgRG8geW91IHRoaW5rIEZDQyB3aWxsIG1p bmQgaWYgd2UgdXNlIHRoZSB0ZXJtIE9CVSBpbiB0aGlzIGRyYWZ0IHRvPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiZndDsmZ3Q7IG1lYW4gc29tZXRoaW5nIGVsc2U/Jm5ic3A7IEksIGFuZCBh IGNvbGxlYWd1ZSwgdGhpbmsgdGhhdCBGQ0Mgd291bGQgbm90IG1pbmQuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiZndDsmZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4mZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0 OyBBbGV4PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7IDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7 IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyA8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDsgaXRzIG1haWxpbmcgbGlzdDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0 OyZndDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOml0c0BpZXRmLm9yZyUzY21haWx0bzppdHNAaWV0 Zi5vcmciPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5pdHNAaWV0Zi5vcmcmbHQ7bWFpbHRvOml0c0BpZXRmLm9yZzwv c3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0 OyZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7PC9zcGFuPjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXRzIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pdHM8L3NwYW4+PC9hPjxvOnA+ PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7PC9zcGFuPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHA+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiZndDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPg0KPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_40618c5cbd684e4a8f7de3f2e58b9114HE105831emea1cdstintern_-- From nobody Tue Feb 6 07:40:15 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C568812D832 for ; Tue, 6 Feb 2018 07:40:14 -0800 (PST) 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 OvTWiyN6ftnY for ; Tue, 6 Feb 2018 07:40:12 -0800 (PST) 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 5A17D12D7FC for ; Tue, 6 Feb 2018 07:40:12 -0800 (PST) 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 w16Fe5KN167638; Tue, 6 Feb 2018 16:40:05 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D4B4E2049DD; Tue, 6 Feb 2018 16:40:05 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C2AA02047E6; Tue, 6 Feb 2018 16:40:05 +0100 (CET) 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 w16Fe3HU029281; Tue, 6 Feb 2018 16:40:03 +0100 To: dickroy@alum.mit.edu, "'Tony Li'" , "=?UTF-8?Q?'Fran=c3=a7ois_Simon'?=" Cc: its@ietf.org References: <1517217856.4315.32.camel@it.uc3m.es> <003c01d39e2d$4dfadf00$e9f09d00$@gmail.com> <2C80DD5A-743B-4429-B8B7-0DB809375144@tony.li> From: Alexandre Petrescu Message-ID: <8890c5a1-814a-c525-1d5c-ec2024b7b854@gmail.com> Date: Tue, 6 Feb 2018 16:40:02 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.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] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 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, 06 Feb 2018 15:40:14 -0000 Le 06/02/2018 01:32, Dick Roy a crit: > ------------------------------------------------------------------------ > > *From:*its [mailto:its-bounces@ietf.org] *On Behalf Of *Tony Li > *Sent:* Sunday, February 4, 2018 8:34 PM > *To:* Franois Simon > *Cc:* Alexandre Petrescu; its@ietf.org > *Subject:* Re: [ipwave] Shepherd review of > draft-ietf-ipwave-ipv6-over-80211ocb-12 > > Franois, > > > > /The MTU text currently says:/ > > /> The default MTU for IP packets on 802.11-OCB is 1500 octets./ > > /I modify it to say:/ > > /> The default MTU for IP packets on 802.11-OCB MUST be 1500 octets./ > > -The MTU text currently says: > The default MTU for IP packets on > 802.11-OCB is 1500 octets.***[Fygs: IEEE **802.11 OCB - **MSDU size 2304]* > > Be that as it may, we really need 802.11-OCB to have an MTU of 1500. > > */[RR] Not true. You may want to require it when using 802.11 as a first > hop on an ethernet LAN, however no such requirement is necessary for > example when broadcasting BSMs or SPaT/MAP ADUs. /* I agree. These non-IP ADUs have other requirements. When these ADUs are transmitted over 802.11 OCB they must respect the 802.11 OCB MTU. That is not a problem, because the MTU of 802.11 in OCB mode is much larger than typical BSM messages (1500 bytes vs 400 bytes, or so). So we stay that way th 1500 bytes. Alex > > > > -I modify it to say: > The default MTU for IP packets on 802.11-OCB MUST > be 1500 octets.***[Fygs: is was correct]* > > If you want us to use normative language, then per RFC 2119, we need to > use MUST. The word is has no normative connotations. > > */[RR] Dont make such blanket normative statements without qualifiers. > You might also note that in 1609.3 you will find the following > interesting ASN.1:/* > > *//*dot3WsmMaxLength OBJECT-TYPE > > SYNTAX INTEGER (1..2302) > > MAX-ACCESS read-write > > STATUS current > > DESCRIPTION > > "Maximum size in octets of the variable length portion > > of a WSM, including data. > > The default value is 1400. Max value is > > 802.11 MAC MSDU size minus EtherType size (2304 minus > > 2 = 2302)." > > ::= { dot3LocalInfo 4*//* > > Tony > From nobody Tue Feb 6 07:41:43 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70D7D12D84C for ; Tue, 6 Feb 2018 07:41:42 -0800 (PST) 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 fKm2VAlPVv91 for ; Tue, 6 Feb 2018 07:41:34 -0800 (PST) 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 D9A4412D7FC for ; Tue, 6 Feb 2018 07:41:32 -0800 (PST) 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 w16FfUSA039903; Tue, 6 Feb 2018 16:41:30 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8EB3D202168; Tue, 6 Feb 2018 16:41:30 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 80EF8201465; Tue, 6 Feb 2018 16:41:30 +0100 (CET) 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 w16FfTj3031414; Tue, 6 Feb 2018 16:41:29 +0100 To: =?UTF-8?Q?Fran=c3=a7ois_Simon?= Cc: its@ietf.org References: <1517217856.4315.32.camel@it.uc3m.es> <006601d39910$bdcf1cf0$396d56d0$@gmail.com> <000101d39c0f$e3b32f90$ab198eb0$@gmail.com> <87888ef4-ae0e-421c-0e48-43b0276f038a@gmail.com> <001a01d39e93$7ad4e4b0$707eae10$@gmail.com> <000e01d39ef1$b5d553c0$217ffb40$@gmail.com> From: Alexandre Petrescu Message-ID: <38aab103-1a78-b0ba-c7af-2c3bf5ec5c75@gmail.com> Date: Tue, 6 Feb 2018 16:41:29 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <000e01d39ef1$b5d553c0$217ffb40$@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] FW: Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 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, 06 Feb 2018 15:41:42 -0000 If I add DSRCS, and DSRC, and OBU - it makes for 3 terms only tangentially relevant. I find it too much. There are two very relevant terms: IP-OBU and IP-RSU. We need to have more relevant terms than tangentially relevant terms. Le 06/02/2018 à 03:25, François Simon a écrit : > /"//So, in order to define OBU in terms of DSRCS one has to define first > DSRCS, all while caring to avoid loops.  I think it can become too > lengthy.//"/// > > -///Dedicated Short-Range Communications////Services (DSRCS)/.-The use > of radio techniquesto transfer data over short distancesbetween roadside > and mobile > > units, between mobile units, and betweenportable and mobile > units to performoperations related to the improvementof traffic > flow, traffic safety, > > and other intelligent transportationservice applications in a > varietyof environments. DSRCS systems mayalso transmit status > and instructional > > messages related to the units involved.[ Ref. 47 CFR90.7 – > Definitions] > > -----Original Message----- > From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] > Sent: Monday, February 05, 2018 10:41 AM > To: François Simon > Cc: its@ietf.org > Subject: Re: [ipwave] Shepherd review of > draft-ietf-ipwave-ipv6-over-80211ocb-12 > > Le 05/02/2018 à 16:10, François Simon a écrit : > >> /"//Is DSRCS a typo? (correct DSRC).//"/// > >> > >> -// No typo. DSRCS stands for “Dedicated Short Range Communication Service” > > So, in order to define OBU in terms of DSRCS one has to define first > DSRCS, all while caring to avoid loops.  I think it can become too lengthy. > > Alex > >> > >> -----Original Message----- > >> From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] > >> Sent: Sunday, February 04, 2018 11:08 AM > >> To: François Simon > > >> Cc:its@ietf.org > >> Subject: Re: [ipwave] Shepherd review of > >> draft-ietf-ipwave-ipv6-over-80211ocb-12 > >> > >> I am adding this OBU ref for reference but I have a question: > >> > >> Le 02/02/2018 à 11:23, François Simon a écrit : > >> > >> [...] > >> > >>> /On-Board unit (OBU). An On-Board Unit is a DSRCS transceiver that is > >> > >> Is DSRCS a typo? (correct DSRC). > >> > >> Alex > >> > >>> 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. The OBUs receive and contend for time > >> > >>> to transmit on one or more radio frequency (RF) channels. Except > >>> where > >> > >>> specifically excluded, OBU operation is permitted wherever vehicle > >> > >>> operation or human passage is permitted. The OBUs mounted in vehicles > >> > >>> are licensed by rule under part 95 of this chapter and communicate > >> > >>> with Roadside Units (RSUs) and other OBUs. Portable OBUs are also > >> > >>> licensed by rule under part 95 of this chapter. OBU operations in the > >> > >>> Unlicensed National Information Infrastructure (UNII) Bands follow > >>> the > >> > >>> rules in those bands./- [CFR 90.7 - Definitions] - October 2010 > >> > >>> > >> > >>> *IPWAVE Issue*** > >> > >>> > >> > >>> ** > >> > >>> > >> > >>> /“The problem with the FCC definition of OBU is that it has no > >> > >>> relationship to IP.  Worse, that FCC definition has no indication > >>> that > >> > >>> it MAY use IP somehow.  And here we say that all OBUs must use IP. > >>> Do > >> > >>> you see what I mean?”/// > >> > >>> > >> > >>> // > >> > >>> > >> > >>> Correct; the OBU has no relationship with IP and is not intended to. > >> > >>> IP is a network protocol.  If an On-Board Unit (OBU) device is > >> > >>> required to exchange IP, it needs to be dealt in protocol(s) and/or > >> > >>> Management in higher layers similar to WAVE within the On-Board Equipment (OBE) . > >> > >>> > >> > >>> /“Do you think FCC will mind if we use the term OBU in this draft to > >> > >>> mean something else?  I, and a colleague, think that FCC would not > >> > >>> mind.”/// > >> > >>> > >> > >>> // > >> > >>> > >> > >>> Depending of the reader. If one is familiar with DSRC, OBU and RSU as > >> > >>> defined by FCC will come in mind. As far as I know, “OBU” and “RSU” > >> > >>> are not registered and could be used for other definitions (something > >> > >>> like > >> > >>> “ATM”: Asynchronous Transfer Mode and Automatic Teller Machine😊). My > >> > >>> suggestion to the IPWAVE team is to use “OBE and RSE”. > >> > >>> > >> > >>> This is my personal view as I donot represent any involved interest. > >> > >>> If any one has questions, let me know. > >> > >>> > >> > >>> Francois Simon > >> > >>> > >> > >>> Lojik Technologies > >> > >>> > >> > >>> -----Original Message----- > >> > >>> > >> > >>> From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre > >> > >>> Petrescu > >> > >>> > >> > >>> Sent: Monday, January 29, 2018 10:08 AM > >> > >>> > >> > >>> To:its@ietf.org > >> > >>> > >> > >>> Subject: Re: [ipwave] Shepherd review of > >> > >>> draft-ietf-ipwave-ipv6-over-80211ocb-12 > >> > >>> > >> > >>> > >> > >>> > >> > >>> Le 29/01/2018 à 15:52, François Simon a écrit : > >> > >>> > >> > >>>> My comments arewithin the text*[Fygs.......]*. > >> > >>> > >> > >>> [...] > >> > >>> > >> > >>>> In the terminology section, the OBU term is mentioned to be defined > >> > >>> > >> > >>>> outside the IETF. This is fine, but we have to provide a reference. > >> > >>> > >> > >>>> And even with that, it would not harm to include some short > >> > >>>> definition > >> > >>> > >> > >>>> to provide context. The RSU term is also defined outside the IETF > >>>> and > >> > >>> > >> > >>>> there is quite a lot of text provided (I think the relevant part is > >> > >>> > >> > >>>> the last sentence, the one starting with "The difference between..."). > >> > >>> > >> > >>>> Both terms should be handled in the same way. > >> > >>> > >> > >>>> > >> > >>> > >> > >>>> *[Fygs: The**definitions**was issued by the FCC 20 years ago.  I > >>>> have > >> > >>> > >> > >>>> already provided that information**and references multiple > >> > >>> > >> > >>>> times.]*** > >> > >>> > >> > >>> The problem with the FCC definition of OBU is that it has no > >> > >>> relationship to IP.  Worse, that FCC definition has no indication > >>> that > >> > >>> it MAY use IP somehow.  And here we say that all OBUs must use IP. > >>> Do > >> > >>> you see what I mean? > >> > >>> > >> > >>> Do you think FCC will mind if we use the term OBU in this draft to > >> > >>> mean something else?  I, and a colleague, think that FCC would not mind. > >> > >>> > >> > >>> Alex > >> > >>> > >> > >>> _______________________________________________ > >> > >>> > >> > >>> its mailing list > >> > >>> > >> > >>>its@ietf.org> > >> > >>> > >> > >>>https://www.ietf.org/mailman/listinfo/its > >> > >>> > >> > From nobody Tue Feb 6 07:46:03 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0C3912D831 for ; Tue, 6 Feb 2018 07:46:01 -0800 (PST) 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 4gavRYpAygvd for ; Tue, 6 Feb 2018 07:45:58 -0800 (PST) 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 1C3BA126D73 for ; Tue, 6 Feb 2018 07:45:57 -0800 (PST) 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 w16FjtDD169203; Tue, 6 Feb 2018 16:45:56 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E0525204A2B; Tue, 6 Feb 2018 16:45:55 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id CF6E02048B9; Tue, 6 Feb 2018 16:45:55 +0100 (CET) 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 w16FjsfW003692; Tue, 6 Feb 2018 16:45:54 +0100 To: Dirk.von-Hugo@telekom.de, fygsimon@gmail.com Cc: its@ietf.org References: <1517217856.4315.32.camel@it.uc3m.es> <006601d39910$bdcf1cf0$396d56d0$@gmail.com> <000101d39c0f$e3b32f90$ab198eb0$@gmail.com> <827a8e03-75fc-7b64-9b2a-2c2bdc0288ed@gmail.com> <004901d39e31$b6d89630$2489c290$@gmail.com> <46f0fd1b-dac5-0369-f985-b062df170cb0@gmail.com> <001a01d39f34$45cb6630$d1623290$@gmail.com> <40618c5cbd684e4a8f7de3f2e58b9114@HE105831.emea1.cds.t-internal.com> From: Alexandre Petrescu Message-ID: <9342d7fc-c9d1-93d5-cbf9-475872973f79@gmail.com> Date: Tue, 6 Feb 2018 16:45:54 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <40618c5cbd684e4a8f7de3f2e58b9114@HE105831.emea1.cds.t-internal.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 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, 06 Feb 2018 15:46:02 -0000 Le 06/02/2018 à 12:47, Dirk.von-Hugo@telekom.de a écrit : > Hi, > > perhaps this was just a typo meaning Basic Transport Protocol (BTP) > running over geonetworking in ETSI ITS? Perhaps. This comes from a larger problem: the way we talk about protocols with programmers is some times in terms of what wireshark shows. The dissectors for ETSI ITS (BTP, CAM, DENM, more) are not integrated in the main wireshark. So, depending on the wireshark version, depending on the ETSI ITS standard version so depending on the dissectors version, the programmers see different protocols on the screen. But yes, I wanted indeed to say ETSI ITS protocols (presumably BTP). Alex > > Best Regards > Dirk > > *From:*its [mailto:its-bounces@ietf.org] *On Behalf Of *François Simon > *Sent:* Dienstag, 6. Februar 2018 11:22 > *To:* 'Alexandre Petrescu' > *Cc:* its@ietf.org > *Subject:* Re: [ipwave] Shepherd review of > draft-ietf-ipwave-ipv6-over-80211ocb-12 > > "///The protocols I have seen running on 802.11 OCB are IP, ETSI > geonetworking and BSM."/ > > -BSM is not a protocol. The Basic Safety Message (BSM) is amessage used > in V2V applications and is defined in SAE j2735 standard - “Dedicated > Short Range Communications (DSRC) Message Set Dictionary”. > > -----Original Message----- > From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] > Sent: Monday, February 05, 2018 3:08 AM > To: François Simon > > Cc: its@ietf.org > Subject: Re: [ipwave] Shepherd review of > draft-ietf-ipwave-ipv6-over-80211ocb-12 > > Le 05/02/2018 à 04:30, François Simon a écrit : > >> Mr. Petrescu, > >> > >> /"//I thought "DSRC" is also about Applications and Use-cases.//"/// > >> > >> -// No; It is a Dedicated Short Range Communication service. > >> IbelievethatSAE DSRCTechnical Committee (US) is defining > >> applicationsand use-cases.// > >> > >> // > >> > >> “/It is one thing to have no restrictions, and another thing to reckon > >> that IP is the networking layer.//”/// > >> > >> -//Layer 3 (Network Layer) > > Well, I am happy you list all these network layer protocols. > > As a side note, it would be good to let know wikipedia to refer here. > > (there are details that situate the listed protocols to be a little bit > above network layer, not right at the network layer). > > Among the listed protocols the ones precisely at networking layer are: > > IPv4, IPv6 and IPX.  All the others are a little bit above. > > I have seen IPv4 and IPv6 over 802.11 OCB, but I have not seen IPX run > on 802.11 OCB. > > Stating that IPX _could_ run on 802.11 OCB is a theoretical assumption, > but in practice you never know. > > There is a huge difference between stating IP runs on 802.11 OCB and > stating that IPX runs on 802.11 OCB. > > The protocols I have seen running on 802.11 OCB are IP, ETSI > geonetworking and BSM. > > I think it would be good that DSRC said "802.11 OCB supports > network-layer  protocols such as IP, ETSI geonetworking and BSM", rather > than saying "802.11 OCB supports _any_ network layer parotocols". > >> ·___CLNP_Connectionless Networking > >> Protocol > >> > >> ·___EGP_Exter > >> ior Gateway Protocol > >> > >> ·___EIGRP_Enhanced Interior > >> Gateway Routing Protocol > >> > >> ·___ICMP_ >> col>Internet > >> Control Message Protocol > >> > >> ·___IGMP_Internet Group Management > >> Protocol > >> > >> ·___IGRP_Interior Gateway Routing > >> Protocol > >> > >> ·___IPv4_Internet Protocol version > >> 4 > >> > >> ·___IPv6_Internet Protocol version > >> 6 > >> > >> ·___IPSec_Internet Protocol > >> Security > >> > >> ·___IPX_Internetwork Packet change > >> > >> ·___NAT_Net > >> work > >> Address Translation > >> > >> ·___Routed-SMLT_ > >> > >> ·___SCCP_ >> Part>Signalling > >> Connection Control Part > >> > >> ·AppleTalk DDP > >> > >> ·___GRE_G > >> eneric > >> Routing Encapsulation for tunneling > >> > >> ·___OSPF_Open Shortest Path First > >> > >> ·___RIP_Ro > >> uting > >> Information Protocol > >> > >> ·___HSRP_Ho > >> t > >> Standby Router protocol > >> > >> ·___VRRP_ >> ocol>Virtual > >> Router Redundancy Protocol > >> > >> “/An RSU product has many transceivers inside.//”/// > >> > >> -// An RSE may have multiple transceivers. > > I think there is a huge terminology issue here. > > "RSE" is not used, I never heard it. > > Most people say "RSU" to mean a "box" whereas the FCC term RSU seem to > mean just a "transceiver".  A "transceiver" is typically a "modem". > > Products are marketed as "RSU" and they are boxes.  They have much more > inside than just the "transceiver".  What could be understood as > 'transceiver' (transmitter/receiver) is the modem > > (modulator/demodulator) or 'baseband' processor, that sits on an > extension board that itself sits on a motherboard.  There is power > supply too.  All these make an "RSU".  Some RSUs have even more devices > like solar panels, mechanical hooks, sophisticated antennas, EV charge > stations, LTE modems, optical backhaul and more. > > BEcause of this discrepancy, I prefer to forget use his "RSU" term in > this IP-over-OCB document just as for information.  RAther, use the > "IP-RSU" to mean what we want it to mean. > > Alex > >> > >> -----Original Message----- > >> From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] > >> Sent: Sunday, February 04, 2018 10:49 AM > >> To: François Simon > > >> Cc:its@ietf.org > >> Subject: Re: [ipwave] Shepherd review of > >> draft-ietf-ipwave-ipv6-over-80211ocb-12 > >> > >> Le 02/02/2018 à 11:23, François Simon a écrit : > >> > >>> Mr. Petrescu, > >> > >>> > >> > >>> Let's try one more time to clarify the FCC DSRC (in US only) issue. > >> > >>> > >> > >>> *FCC – DSRC* > >> > >>> > >> > >>> *Background:*** > >> > >>> > >> > >>> ** > >> > >>> > >> > >>> -** The US Federal Communications Commission (FCC) Dedicated Short > >> > >>> Range Communication (DSRC) is defined in the Code of Federal > >> > >>> Regulations (CFR) > >> > >>> 47 mainly Parts 90 and 95. The last update is dated October 1st, > >>> 2010; > >> > >>> > >> > >>> -This includes the ASTM E 2213-03 standard: “Standard Specification > >>> for > >> > >>> Telecommunications and Information Exchange Between Roadside and > >> > >>> Vehicle Systems — 5 GHz Band Dedicated Short Range Communications > >> > >>> (DSRC) Medium Access Control (MAC) and Physical Layer (PHY) > >> > >>> Specifications”; approved July 10, 2003. The standard is derived from > >> > >>> IEEE 802.11a and, in most part, is equivalent to IEEE 802.11 OCB. To > >> > >>> date, the DSRC CFRs do not specify IEEE 802.11 OCB. > >> > >>> > >> > >>> -The related CFRs state that DSRC shall comply with the ASTM E 2213-03. > >> > >> Thank you for the explanation.  It is useful to understand that DSRC > >> is related to ASTM E 2213-03 and that neither refers to 802.11 OCB. > >> > >> I think in works related to standards and products it is advantageous > >> if there is correlation. > >> > >> For example, in an ideal world, standards talk about "A" and the > >> regulation also about "A" and the products and sofware are also > >> labelled "A". > >> > >> In our context, software is labelled "OCB" (kernel drivers), > >> regulation talks "DSRC" and standards "802.11p" and "802.11 OCB". > >> > >>> *Overview of DSRC functions:*** > >> > >>> > >> > >>> ** > >> > >>> > >> > >>> The functions listed in DSRC related CFRs are, in general, specified > >> > >>> in the ASTM E 2213-03 and IEEE 802.11 OCB: > >> > >>> > >> > >>> -MAC service definition, frame format, and procedures; > >> > >>> > >> > >>> -PHY Orthogonal frequency division multiplexing (OFDM); > >> > >>> > >> > >>> -PHY Service Data Unit format and modulations (data rates): > >> > >>> > >> > >>> -5.9 GHz band allocated channels, frequency, max. EIRP, and spectrum > >> > >>> mask; > >> > >>> > >> > >>> -Individual Channel use: Safety applications, non-safety > >>> applications, > >> > >>> and priorities. > >> > >>> > >> > >>> *Protocols*** > >> > >>> > >> > >>> ** > >> > >>> > >> > >>> DSRC being uniquely a MAC and PHY communications service, > >> > >> I thought "DSRC" is also about Applications and Use-cases. > >> > >>> there here no > >> > >>> restriction on Transport and Network protocols that can be used > >> > >>> (except for the LCC specified by reference in IEEE 802.11 OCB). In > >>> the > >> > >>> US, the WAVE standards (IEEE 1609 series) specify these protocols > >>> when > >> > >>> using DSRC as the communication service. > >> > >> It is one thing to have no restrictions, and another thing to reckon > >> that IP is the networking layer. > >> > >>> > >> > >>> *OBU / RSU*** > >> > >>> > >> > >>> ** > >> > >>> > >> > >>> The CFR (FCC) definitions are: > >> > >>> > >> > >>> /Roadside unit (RSU). A Roadside Unit is a DSRC transceiver > >> > >> Sigh, it is way different. > >> > >> An RSU product has many transceivers inside. > >> > >>> that is > >> > >>> mounted along a road or pedestrian passageway. An RSU may also be > >> > >>> mounted on a vehicle or is hand carried, but it may only operate when > >> > >>> the vehicle or hand- carried unit is stationary. Furthermore, an RSU > >> > >>> operating under this part is restricted to the location where it is > >> > >>> licensed to operate. However, portable or hand-held RSUs are > >>> permitted > >> > >>> to operate where they do not interfere with a site-licensed operation. > >> > >>> A RSU broadcasts data to OBUs or exchanges data with OBUs in its > >> > >>> communications zone. An RSU also provides channel assignments and > >> > >>> operating instructions to OBUs in its communications zone, when > >> > >>> required./- [CFR 90.7 - Definitions] - Revised as October 2010. > >> > >> I think it should be updated to refer to this document. > >> > >>> /On-Board unit (OBU). 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. The OBUs receive and contend for time > >> > >>> to transmit on one or more radio frequency (RF) channels. Except > >>> where > >> > >>> specifically excluded, OBU operation is permitted wherever vehicle > >> > >>> operation or human passage is permitted. The OBUs mounted in vehicles > >> > >>> are licensed by rule under part 95 of this chapter and communicate > >> > >>> with Roadside Units (RSUs) and other OBUs. Portable OBUs are also > >> > >>> licensed by rule under part 95 of this chapter. OBU operations in the > >> > >>> Unlicensed National Information Infrastructure (UNII) Bands follow > >>> the > >> > >>> rules in those bands./- [CFR 90.7 - Definitions] - October 2010 > >> > >> Thanks for the definitions. > >> > >> They are far different from what we need in this draft. > >> > >> I will see the other suggestions. > >> > >> Alex > >> > >>> > >> > >>> *IPWAVE Issue*** > >> > >>> > >> > >>> ** > >> > >>> > >> > >>> /“The problem with the FCC definition of OBU is that it has no > >> > >>> relationship to IP.  Worse, that FCC definition has no indication > >>> that > >> > >>> it MAY use IP somehow.  And here we say that all OBUs must use IP. > >>> Do > >> > >>> you see what I mean?”/// > >> > >>> > >> > >>> // > >> > >>> > >> > >>> Correct; the OBU has no relationship with IP and is not intended to. > >> > >>> IP is a network protocol.  If an On-Board Unit (OBU) device is > >> > >>> required to exchange IP, it needs to be dealt in protocol(s) and/or > >> > >>> Management in higher layers similar to WAVE within the On-Board Equipment (OBE) . > >> > >>> > >> > >>> /“Do you think FCC will mind if we use the term OBU in this draft to > >> > >>> mean something else?  I, and a colleague, think that FCC would not > >> > >>> mind.”/// > >> > >>> > >> > >>> // > >> > >>> > >> > >>> Depending of the reader. If one is familiar with DSRC, OBU and RSU as > >> > >>> defined by FCC will come in mind. As far as I know, “OBU” and “RSU” > >> > >>> are not registered and could be used for other definitions (something > >> > >>> like > >> > >>> “ATM”: Asynchronous Transfer Mode and Automatic Teller Machine😊). My > >> > >>> suggestion to the IPWAVE team is to use “OBE and RSE”. > >> > >>> > >> > >>> This is my personal view as I donot represent any involved interest. > >> > >>> If any one has questions, let me know. > >> > >>> > >> > >>> Francois Simon > >> > >>> > >> > >>> Lojik Technologies > >> > >>> > >> > >>> -----Original Message----- > >> > >>> > >> > >>> From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre > >> > >>> Petrescu > >> > >>> > >> > >>> Sent: Monday, January 29, 2018 10:08 AM > >> > >>> > >> > >>> To:its@ietf.org > >> > >>> > >> > >>> Subject: Re: [ipwave] Shepherd review of > >> > >>> draft-ietf-ipwave-ipv6-over-80211ocb-12 > >> > >>> > >> > >>> > >> > >>> > >> > >>> Le 29/01/2018 à 15:52, François Simon a écrit : > >> > >>> > >> > >>>> My comments arewithin the text*[Fygs.......]*. > >> > >>> > >> > >>> [...] > >> > >>> > >> > >>>> In the terminology section, the OBU term is mentioned to be defined > >> > >>> > >> > >>>> outside the IETF. This is fine, but we have to provide a reference. > >> > >>> > >> > >>>> And even with that, it would not harm to include some short > >> > >>>> definition > >> > >>> > >> > >>>> to provide context. The RSU term is also defined outside the IETF > >>>> and > >> > >>> > >> > >>>> there is quite a lot of text provided (I think the relevant part is > >> > >>> > >> > >>>> the last sentence, the one starting with "The difference between..."). > >> > >>> > >> > >>>> Both terms should be handled in the same way. > >> > >>> > >> > >>>> > >> > >>> > >> > >>>> *[Fygs: The**definitions**was issued by the FCC 20 years ago.  I > >>>> have > >> > >>> > >> > >>>> already provided that information**and references multiple > >> > >>> > >> > >>>> times.]*** > >> > >>> > >> > >>> The problem with the FCC definition of OBU is that it has no > >> > >>> relationship to IP.  Worse, that FCC definition has no indication > >>> that > >> > >>> it MAY use IP somehow.  And here we say that all OBUs must use IP. > >>> Do > >> > >>> you see what I mean? > >> > >>> > >> > >>> Do you think FCC will mind if we use the term OBU in this draft to > >> > >>> mean something else?  I, and a colleague, think that FCC would not mind. > >> > >>> > >> > >>> Alex > >> > >>> > >> > >>> _______________________________________________ > >> > >>> > >> > >>> its mailing list > >> > >>> > >> > >>>its@ietf.org > > >> > >>> > >> > >>>https://www.ietf.org/mailman/listinfo/its > >> > >>> > >> > From nobody Tue Feb 6 08:40:29 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C19012D84D for ; Tue, 6 Feb 2018 08:40:25 -0800 (PST) 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 PHsqjODES57T for ; Tue, 6 Feb 2018 08:40:21 -0800 (PST) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4161212D838 for ; Tue, 6 Feb 2018 08:40:21 -0800 (PST) Received: by mail-qt0-x232.google.com with SMTP id h4so3068825qtn.13 for ; Tue, 06 Feb 2018 08:40:21 -0800 (PST) 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:thread-index:content-language; bh=PdxUJJv5unBYsHcQ2ZxWZKArdIYou5ji1z8oOEYEVAU=; b=Fznaawc23uukWsn7cMoJkKX3y1CB66GFXmlpFfTH1PclSxq2UoGGbV7Ck4QUiNyqE4 bc4TG5gUIwEITgLKi8boOtLItzwlrKFEAIG+pfvXUf8SE4Qgni/JC3HMpCQ5EnyuPQ/i yZfM6P0HD5yRCKyUZjcmwojcLEfA2DcQplokb7Uf94+swygQC21ffKfF6htjqyZyPxsU ztqLBjIUGlA1r2r/804DDN2HcmKe/xcFBhU1b7e3Ughz8P+XL58YsVB+TemkoBhxpqwu ek91uN6RBAU/FQ14eRGUI34UI5wxo3lp8Kx8tqOpAw2mW7vHYJXvLIrD+NNz4gtuPSxl ce6A== 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:thread-index:content-language; bh=PdxUJJv5unBYsHcQ2ZxWZKArdIYou5ji1z8oOEYEVAU=; b=luftRNKsmf/TFsWe9dIcxTAYNSwlQ9AeZn66aAWAykZWc0VEQvrWoiASSTVCQU+zzY Hu7z1VLNqqrvF9hoz9jtD79U76NyFs3EKNJn5YNCRem82aUQk/Mp3wVFy7VpkxwEwwis ijUSpBidTqYlIlKumbYf1DVQ9+s1mpCsZg/HXr8LK7haXWKe9VjpBz9TRfFbRsX58/3G q7AXrfiumnUQZPQ5j+s2zViyNCVIxicBanKI8+r6yazwVLLd8BQff346HSsYLQkKRZ1k qwyW2MZwsZi87oFovFiM2QveFA3CeTcjRV7PurNpI1iyZKCvGMNZD3I/pe/WjMMAujk2 BP9w== X-Gm-Message-State: APf1xPBAYrx1R28gAaOK+6OgQtnuHl38R583H9L1b/kWKqmHwHfYTTjD AAfRh9EyiCKcjXzhl3lEpiA= X-Google-Smtp-Source: AH8x225FY+bcIWJbXZV1HJI6nSVnV8okhoQ6fQzZG3cxplfeAOpaStRQ62pkChFMN7/k3KjiY4TPmA== X-Received: by 10.237.45.1 with SMTP id h1mr4402056qtd.34.1517935220206; Tue, 06 Feb 2018 08:40:20 -0800 (PST) Received: from FrancoisPC (pool-108-48-182-86.washdc.fios.verizon.net. [108.48.182.86]) by smtp.gmail.com with ESMTPSA id s81sm5308285qkl.63.2018.02.06.08.40.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Feb 2018 08:40:19 -0800 (PST) From: =?utf-8?Q?Fran=C3=A7ois_Simon?= To: "'Alexandre Petrescu'" Cc: References: <1517217856.4315.32.camel@it.uc3m.es> <006601d39910$bdcf1cf0$396d56d0$@gmail.com> <000101d39c0f$e3b32f90$ab198eb0$@gmail.com> <87888ef4-ae0e-421c-0e48-43b0276f038a@gmail.com> <001a01d39e93$7ad4e4b0$707eae10$@gmail.com> <000e01d39ef1$b5d553c0$217ffb40$@gmail.com> <38aab103-1a78-b0ba-c7af-2c3bf5ec5c75@gmail.com> In-Reply-To: <38aab103-1a78-b0ba-c7af-2c3bf5ec5c75@gmail.com> Date: Tue, 6 Feb 2018 11:40:19 -0500 Message-ID: <005c01d39f69$2d04ad20$870e0760$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005D_01D39F3F.4435D110" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQL7ISfFSBtQJ/i74DjDJlbgILh28gG4su6HASuQMD8BaTCMjwKzySioAdr+SycCSIzPewHYVzWuAlCyLzmgzhxiMA== Content-Language: en-us Archived-At: Subject: Re: [ipwave] FW: Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 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, 06 Feb 2018 16:40:25 -0000 This is a multipart message in MIME format. ------=_NextPart_000_005D_01D39F3F.4435D110 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Mr. Petrescu, =E2=80=9CThere are two very relevant terms: IP-OBU and IP-RSU.=E2=80=9D - If the Working Group thinks these terms are relevant, then so bid. I = respectfully disagree. Furthermore, I have nothing more to add to this = discussion; I have provided all US relevant definitions. Sincerely, Francois Simon Lojik Technologies =20 -----Original Message----- From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com]=20 Sent: Tuesday, February 06, 2018 10:41 AM To: Fran=C3=A7ois Simon Cc: its@ietf.org Subject: Re: FW: [ipwave] Shepherd review of = draft-ietf-ipwave-ipv6-over-80211ocb-12 If I add DSRCS, and DSRC, and OBU - it makes for 3 terms only = tangentially relevant. I find it too much. There are two very relevant terms: IP-OBU and IP-RSU. We need to have more relevant terms than tangentially relevant terms. Le 06/02/2018 =C3=A0 03:25, Fran=C3=A7ois Simon a =C3=A9crit : > /"//So, in order to define OBU in terms of DSRCS one has to define=20 > first DSRCS, all while caring to avoid loops. I think it can become=20 > too lengthy.//"/// >=20 > -///Dedicated Short-Range Communications////Services (DSRCS)/.-The use = > of radio techniquesto transfer data over short distancesbetween=20 > roadside and mobile >=20 > units, between mobile units, and betweenportable and mobile > units to performoperations related to the improvementof = traffic > flow, traffic safety, >=20 > and other intelligent transportationservice applications in a > varietyof environments. DSRCS systems mayalso transmit status > and instructional >=20 > messages related to the units involved.[ Ref. 47 CFR90.7 = =E2=80=93 > Definitions] >=20 > -----Original Message----- > From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] > Sent: Monday, February 05, 2018 10:41 AM > To: Fran=C3=A7ois Simon > > Cc: its@ietf.org =20 > Subject: Re: [ipwave] Shepherd review of > draft-ietf-ipwave-ipv6-over-80211ocb-12 >=20 > Le 05/02/2018 =C3=A0 16:10, Fran=C3=A7ois Simon a =C3=A9crit : >=20 >> /"//Is DSRCS a typo? (correct DSRC).//"/// >=20 >>=20 >=20 >> -// No typo. DSRCS stands for =E2=80=9CDedicated Short Range = Communication Service=E2=80=9D >=20 > So, in order to define OBU in terms of DSRCS one has to define first=20 > DSRCS, all while caring to avoid loops. I think it can become too = lengthy. >=20 > Alex >=20 >>=20 >=20 >> -----Original Message----- >=20 >> From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] >=20 >> Sent: Sunday, February 04, 2018 11:08 AM >=20 >> To: Fran=C3=A7ois Simon >> >=20 >> Cc:its@ietf.org >=20 >> Subject: Re: [ipwave] Shepherd review of >=20 >> draft-ietf-ipwave-ipv6-over-80211ocb-12 >=20 >>=20 >=20 >> I am adding this OBU ref for reference but I have a question: >=20 >>=20 >=20 >> Le 02/02/2018 =C3=A0 11:23, Fran=C3=A7ois Simon a =C3=A9crit : >=20 >>=20 >=20 >> [...] >=20 >>=20 >=20 >>> /On-Board unit (OBU). An On-Board Unit is a DSRCS transceiver that=20 >>> is >=20 >>=20 >=20 >> Is DSRCS a typo? (correct DSRC). >=20 >>=20 >=20 >> Alex >=20 >>=20 >=20 >>> normally mounted in or on a vehicle, or which in some instances may >=20 >>> be >=20 >>=20 >=20 >>> a portable unit. An OBU can be operational while a vehicle or person >=20 >>=20 >=20 >>> is either mobile or stationary. The OBUs receive and contend for=20 >>> time >=20 >>=20 >=20 >>> to transmit on one or more radio frequency (RF) channels. Except >=20 >>> where >=20 >>=20 >=20 >>> specifically excluded, OBU operation is permitted wherever vehicle >=20 >>=20 >=20 >>> operation or human passage is permitted. The OBUs mounted in=20 >>> vehicles >=20 >>=20 >=20 >>> are licensed by rule under part 95 of this chapter and communicate >=20 >>=20 >=20 >>> with Roadside Units (RSUs) and other OBUs. Portable OBUs are also >=20 >>=20 >=20 >>> licensed by rule under part 95 of this chapter. OBU operations in=20 >>> the >=20 >>=20 >=20 >>> Unlicensed National Information Infrastructure (UNII) Bands follow >=20 >>> the >=20 >>=20 >=20 >>> rules in those bands./- [CFR 90.7 - Definitions] - October 2010 >=20 >>=20 >=20 >>>=20 >=20 >>=20 >=20 >>> *IPWAVE Issue*** >=20 >>=20 >=20 >>>=20 >=20 >>=20 >=20 >>> ** >=20 >>=20 >=20 >>>=20 >=20 >>=20 >=20 >>> /=E2=80=9CThe problem with the FCC definition of OBU is that it has = no >=20 >>=20 >=20 >>> relationship to IP. Worse, that FCC definition has no indication >=20 >>> that >=20 >>=20 >=20 >>> it MAY use IP somehow. And here we say that all OBUs must use IP. =20 >=20 >>> Do >=20 >>=20 >=20 >>> you see what I mean?=E2=80=9D/// >=20 >>=20 >=20 >>>=20 >=20 >>=20 >=20 >>> // >=20 >>=20 >=20 >>>=20 >=20 >>=20 >=20 >>> Correct; the OBU has no relationship with IP and is not intended to. = >=20 >>=20 >=20 >>> IP is a network protocol. If an On-Board Unit (OBU) device is >=20 >>=20 >=20 >>> required to exchange IP, it needs to be dealt in protocol(s) and/or >=20 >>=20 >=20 >>> Management in higher layers similar to WAVE within the On-Board = Equipment (OBE) . >=20 >>=20 >=20 >>>=20 >=20 >>=20 >=20 >>> /=E2=80=9CDo you think FCC will mind if we use the term OBU in this = draft to >=20 >>=20 >=20 >>> mean something else? I, and a colleague, think that FCC would not >=20 >>=20 >=20 >>> mind.=E2=80=9D/// >=20 >>=20 >=20 >>>=20 >=20 >>=20 >=20 >>> // >=20 >>=20 >=20 >>>=20 >=20 >>=20 >=20 >>> Depending of the reader. If one is familiar with DSRC, OBU and RSU=20 >>> as >=20 >>=20 >=20 >>> defined by FCC will come in mind. As far as I know, = =E2=80=9COBU=E2=80=9D and =E2=80=9CRSU=E2=80=9D=20 >=20 >>=20 >=20 >>> are not registered and could be used for other definitions=20 >>> (something >=20 >>=20 >=20 >>> like >=20 >>=20 >=20 >>> =E2=80=9CATM=E2=80=9D: Asynchronous Transfer Mode and Automatic = Teller Machine=F0=9F=98=8A).=20 >>> My >=20 >>=20 >=20 >>> suggestion to the IPWAVE team is to use =E2=80=9COBE and = RSE=E2=80=9D. >=20 >>=20 >=20 >>>=20 >=20 >>=20 >=20 >>> This is my personal view as I donot represent any involved interest. = =20 >=20 >>=20 >=20 >>> If any one has questions, let me know. >=20 >>=20 >=20 >>>=20 >=20 >>=20 >=20 >>> Francois Simon >=20 >>=20 >=20 >>>=20 >=20 >>=20 >=20 >>> Lojik Technologies >=20 >>=20 >=20 >>>=20 >=20 >>=20 >=20 >>> -----Original Message----- >=20 >>=20 >=20 >>>=20 >=20 >>=20 >=20 >>> From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre >=20 >>=20 >=20 >>> Petrescu >=20 >>=20 >=20 >>>=20 >=20 >>=20 >=20 >>> Sent: Monday, January 29, 2018 10:08 AM >=20 >>=20 >=20 >>>=20 >=20 >>=20 >=20 >>> To:its@ietf.org >=20 >>=20 >=20 >>>=20 >=20 >>=20 >=20 >>> Subject: Re: [ipwave] Shepherd review of >=20 >>=20 >=20 >>> draft-ietf-ipwave-ipv6-over-80211ocb-12 >=20 >>=20 >=20 >>>=20 >=20 >>=20 >=20 >>>=20 >=20 >>=20 >=20 >>>=20 >=20 >>=20 >=20 >>> Le 29/01/2018 =C3=A0 15:52, Fran=C3=A7ois Simon a =C3=A9crit : >=20 >>=20 >=20 >>>=20 >=20 >>=20 >=20 >>>> My comments arewithin the text*[Fygs.......]*. >=20 >>=20 >=20 >>>=20 >=20 >>=20 >=20 >>> [...] >=20 >>=20 >=20 >>>=20 >=20 >>=20 >=20 >>>> In the terminology section, the OBU term is mentioned to be defined >=20 >>=20 >=20 >>>=20 >=20 >>=20 >=20 >>>> outside the IETF. This is fine, but we have to provide a reference. >=20 >>=20 >=20 >>>=20 >=20 >>=20 >=20 >>>> And even with that, it would not harm to include some short >=20 >>=20 >=20 >>>> definition >=20 >>=20 >=20 >>>=20 >=20 >>=20 >=20 >>>> to provide context. The RSU term is also defined outside the IETF >=20 >>>> and >=20 >>=20 >=20 >>>=20 >=20 >>=20 >=20 >>>> there is quite a lot of text provided (I think the relevant part is >=20 >>=20 >=20 >>>=20 >=20 >>=20 >=20 >>>> the last sentence, the one starting with "The difference = between...").=20 >=20 >>=20 >=20 >>>=20 >=20 >>=20 >=20 >>>> Both terms should be handled in the same way. >=20 >>=20 >=20 >>>=20 >=20 >>=20 >=20 >>>>=20 >=20 >>=20 >=20 >>>=20 >=20 >>=20 >=20 >>>> *[Fygs: The**definitions**was issued by the FCC 20 years ago. I >=20 >>>> have >=20 >>=20 >=20 >>>=20 >=20 >>=20 >=20 >>>> already provided that information**and references multiple >=20 >>=20 >=20 >>>=20 >=20 >>=20 >=20 >>>> times.]*** >=20 >>=20 >=20 >>>=20 >=20 >>=20 >=20 >>> The problem with the FCC definition of OBU is that it has no >=20 >>=20 >=20 >>> relationship to IP. Worse, that FCC definition has no indication >=20 >>> that >=20 >>=20 >=20 >>> it MAY use IP somehow. And here we say that all OBUs must use IP. =20 >=20 >>> Do >=20 >>=20 >=20 >>> you see what I mean? >=20 >>=20 >=20 >>>=20 >=20 >>=20 >=20 >>> Do you think FCC will mind if we use the term OBU in this draft to >=20 >>=20 >=20 >>> mean something else? I, and a colleague, think that FCC would not = mind. >=20 >>=20 >=20 >>>=20 >=20 >>=20 >=20 >>> Alex >=20 >>=20 >=20 >>>=20 >=20 >>=20 >=20 >>> _______________________________________________ >=20 >>=20 >=20 >>>=20 >=20 >>=20 >=20 >>> its mailing list >=20 >>=20 >=20 >>>=20 >=20 >>=20 >=20 >>>its@ietf.org . >>>org>> >=20 >>=20 >=20 >>>=20 >=20 >>=20 >=20 >>>https://www.ietf.org/mailman/listinfo/its >=20 >>=20 >=20 >>> >=20 >> >=20 ------=_NextPart_000_005D_01D39F3F.4435D110 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable RE: FW: [ipwave] Shepherd review of = draft-ietf-ipwave-ipv6-over-80211ocb-12

Mr. = Petrescu,

=E2=80=9CThere are two very relevant = terms: IP-OBU and IP-RSU.=E2=80=9D

-       If the Working Group thinks these terms are relevant, = then so = bid. I respectfully disagree. Furthermore, I have nothing more to = add to this = discussion; I have provided all US relevant = definitions.

Sincerely,

Francois = Simon

Lojik = Technologies

 

-----Original = Message-----
From: Alexandre Petrescu [mailto:alexandre.petrescu@gm= ail.com]
Sent: Tuesday, February 06, 2018 10:41 AM
To: Fran=C3=A7ois Simon <fygsimon@gmail.com>
Cc: its@ietf.org
Subject: Re: FW: [ipwave] Shepherd review of = draft-ietf-ipwave-ipv6-over-80211ocb-12

If I add DSRCS, = and DSRC, and OBU - it makes for 3 terms only tangentially = relevant.

I find it too = much.

There are two = very relevant terms: IP-OBU and IP-RSU.

We need to have = more relevant terms than tangentially relevant terms.

Le 06/02/2018 = =C3=A0 03:25, Fran=C3=A7ois Simon a =C3=A9crit=C2=A0:

> = /"//So, in order to define OBU in terms of DSRCS one has to define =

> first = DSRCS, all while caring to avoid loops.=C2=A0 I think it can become =

> too = lengthy.//"///

> =

> = -///Dedicated Short-Range Communications////Services (DSRCS)/.-The use =

> of radio = techniquesto transfer data over short distancesbetween =

> roadside = and mobile

> =

>         = units, between mobile units, and betweenportable and = mobile

>         = units to performoperations related to the improvementof = traffic

>         = flow, traffic safety,

> =

>         = and other intelligent transportationservice applications in = a

>         = varietyof environments. DSRCS systems mayalso transmit = status

>         = and instructional

> =

>         = messages related to the units involved.[ Ref. 47 CFR90.7 = =E2=80=93

>         = Definitions]

> =

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

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

> Sent: = Monday, February 05, 2018 10:41 AM

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

> = Cc: its@ietf.org

> Subject: = Re: [ipwave] Shepherd review of

> = draft-ietf-ipwave-ipv6-over-80211ocb-12

> =

> Le = 05/02/2018 =C3=A0 16:10, Fran=C3=A7ois Simon a = =C3=A9crit=C2=A0:

> =

>> = /"//Is DSRCS a typo? (correct DSRC).//"///

> =

>> =

> =

>> -// No = typo. DSRCS stands for =E2=80=9CDedicated Short Range Communication = Service=E2=80=9D

> =

> So, in = order to define OBU in terms of DSRCS one has to define first =

> DSRCS, all = while caring to avoid loops.=C2=A0 I think it can become too = lengthy.

> =

> = Alex

> =

>> =

> =

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

> =

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

> =

>> Sent: = Sunday, February 04, 2018 11:08 AM

> =

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

> =

>> = Cc:its@ietf.org<mailto:its@ietf.org>

> =

>> = Subject: Re: [ipwave] Shepherd review of

> =

>> = draft-ietf-ipwave-ipv6-over-80211ocb-12

> =

>> =

> =

>> I am = adding this OBU ref for reference but I have a = question:

> =

>> =

> =

>> Le = 02/02/2018 =C3=A0 11:23, Fran=C3=A7ois Simon a = =C3=A9crit=C2=A0:

> =

>> =

> =

>> = [...]

> =

>> =

> =

>>> = /On-Board unit (OBU). An On-Board Unit is a DSRCS transceiver that =

>>> = is

> =

>> =

> =

>> Is = DSRCS a typo? (correct DSRC).

> =

>> =

> =

>> = Alex

> =

>> =

> =

>>> = 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. The OBUs receive and contend for =

>>> = time

> =

>> =

> =

>>> to = transmit on one or more radio frequency (RF) channels. = Except

> =

>>> = where

> =

>> =

> =

>>> = specifically excluded, OBU operation is permitted wherever = vehicle

> =

>> =

> =

>>> = operation or human passage is permitted. The OBUs mounted in =

>>> = vehicles

> =

>> =

> =

>>> = are licensed by rule under part 95 of this chapter and = communicate

> =

>> =

> =

>>> = with Roadside Units (RSUs) and other OBUs. Portable OBUs are = also

> =

>> =

> =

>>> = licensed by rule under part 95 of this chapter. OBU operations in =

>>> = the

> =

>> =

> =

>>> = Unlicensed National Information Infrastructure (UNII) Bands = follow

> =

>>> = the

> =

>> =

> =

>>> = rules in those bands./- [CFR 90.7 - Definitions] - October = 2010

> =

>> =

> =

>>> =

> =

>> =

> =

>>> = *IPWAVE Issue***

> =

>> =

> =

>>> =

> =

>> =

> =

>>> = **

> =

>> =

> =

>>> =

> =

>> =

> =

>>> = /=E2=80=9CThe problem with the FCC definition of OBU is that it has = no

> =

>> =

> =

>>> = relationship to IP.=C2=A0 Worse, that FCC definition has no = indication

> =

>>> = that

> =

>> =

> =

>>> it = MAY use IP somehow.=C2=A0 And here we say that all OBUs must use = IP. 

> =

>>> = Do

> =

>> =

> =

>>> = you see what I mean?=E2=80=9D///

> =

>> =

> =

>>> =

> =

>> =

> =

>>> = //

> =

>> =

> =

>>> =

> =

>> =

> =

>>> = Correct; the OBU has no relationship with IP and is not intended to. =

> =

>> =

> =

>>> IP = is a network protocol.=C2=A0 If an On-Board Unit (OBU) device = is

> =

>> =

> =

>>> = required to exchange IP, it needs to be dealt in protocol(s) = and/or

> =

>> =

> =

>>> = Management in higher layers similar to WAVE within the On-Board = Equipment (OBE) .

> =

>> =

> =

>>> =

> =

>> =

> =

>>> = /=E2=80=9CDo you think FCC will mind if we use the term OBU in this = draft to

> =

>> =

> =

>>> = mean something else?=C2=A0 I, and a colleague, think that FCC would = not

> =

>> =

> =

>>> = mind.=E2=80=9D///

> =

>> =

> =

>>> =

> =

>> =

> =

>>> = //

> =

>> =

> =

>>> =

> =

>> =

> =

>>> = Depending of the reader. If one is familiar with DSRC, OBU and RSU =

>>> = as

> =

>> =

> =

>>> = defined by FCC will come in mind. As far as I know, = =E2=80=9COBU=E2=80=9D and =E2=80=9CRSU=E2=80=9D

> =

>> =

> =

>>> = are not registered and could be used for other definitions =

>>> = (something

> =

>> =

> =

>>> = like

> =

>> =

> =

>>> = =E2=80=9CATM=E2=80=9D: Asynchronous Transfer Mode and Automatic Teller = Machine=F0=9F=98=8A).

>>> = My

> =

>> =

> =

>>> = suggestion to the IPWAVE team is to use =E2=80=9COBE and = RSE=E2=80=9D.

> =

>> =

> =

>>> =

> =

>> =

> =

>>> = This is my personal view as I donot represent any involved = interest. 

> =

>> =

> =

>>> If = any one has questions, let me know.

> =

>> =

> =

>>> =

> =

>> =

> =

>>> = Francois Simon

> =

>> =

> =

>>> =

> =

>> =

> =

>>> = Lojik Technologies

> =

>> =

> =

>>> =

> =

>> =

> =

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

> =

>> =

> =

>>> =

> =

>> =

> =

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

> =

>> =

> =

>>> = Petrescu

> =

>> =

> =

>>> =

> =

>> =

> =

>>> = Sent: Monday, January 29, 2018 10:08 AM

> =

>> =

> =

>>> =

> =

>> =

> =

>>> = To:its@ietf.org<mailto:its@ietf.org>

> =

>> =

> =

>>> =

> =

>> =

> =

>>> = Subject: Re: [ipwave] Shepherd review of

> =

>> =

> =

>>> = draft-ietf-ipwave-ipv6-over-80211ocb-12

> =

>> =

> =

>>> =

> =

>> =

> =

>>> =

> =

>> =

> =

>>> =

> =

>> =

> =

>>> Le = 29/01/2018 =C3=A0 15:52, Fran=C3=A7ois Simon a =C3=A9crit = :

> =

>> =

> =

>>> =

> =

>> =

> =

>>>> My comments arewithin the = text*[Fygs.......]*.

> =

>> =

> =

>>> =

> =

>> =

> =

>>> = [...]

> =

>> =

> =

>>> =

> =

>> =

> =

>>>> In the terminology section, the OBU = term is mentioned to be defined

> =

>> =

> =

>>> =

> =

>> =

> =

>>>> outside the IETF. This is fine, but we = have to provide a reference.

> =

>> =

> =

>>> =

> =

>> =

> =

>>>> And even with that, it would not harm = to include some short

> =

>> =

> =

>>>> definition

> =

>> =

> =

>>> =

> =

>> =

> =

>>>> to provide context. The RSU term is = also defined outside the IETF

> =

>>>> and

> =

>> =

> =

>>> =

> =

>> =

> =

>>>> there is quite a lot of text provided = (I think the relevant part is

> =

>> =

> =

>>> =

> =

>> =

> =

>>>> the last sentence, the one starting = with "The difference between...").

> =

>> =

> =

>>> =

> =

>> =

> =

>>>> Both terms should be handled in the = same way.

> =

>> =

> =

>>> =

> =

>> =

> =

>>>>

> =

>> =

> =

>>> =

> =

>> =

> =

>>>> *[Fygs: The**definitions**was issued = by the FCC 20 years ago.=C2=A0 I

> =

>>>> have

> =

>> =

> =

>>> =

> =

>> =

> =

>>>> already provided that information**and = references multiple

> =

>> =

> =

>>> =

> =

>> =

> =

>>>> times.]***

> =

>> =

> =

>>> =

> =

>> =

> =

>>> = The problem with the FCC definition of OBU is that it has = no

> =

>> =

> =

>>> = relationship to IP.=C2=A0 Worse, that FCC definition has no = indication

> =

>>> = that

> =

>> =

> =

>>> it = MAY use IP somehow.=C2=A0 And here we say that all OBUs must use = IP. 

> =

>>> = Do

> =

>> =

> =

>>> = you see what I mean?

> =

>> =

> =

>>> =

> =

>> =

> =

>>> Do = you think FCC will mind if we use the term OBU in this draft = to

> =

>> =

> =

>>> = mean something else?=C2=A0 I, and a colleague, think that FCC would not = mind.

> =

>> =

> =

>>> =

> =

>> =

> =

>>> = Alex

> =

>> =

> =

>>> =

> =

>> =

> =

>>> = _______________________________________________

> =

>> =

> =

>>> =

> =

>> =

> =

>>> = its mailing list

> =

>> =

> =

>>> =

> =

>> =

> =

>>>its@ietf.org<mailto:its@ietf.org<mailto:its@ietf.o= rg<mailto:its@ietf.

>>>org>>

> =

>> =

> =

>>> =

> =

>> =

> =

>>>https://www.ietf.org/mailman/listinfo/its<= SPAN LANG=3D"en-us">

> =

>> =

> =

>>>

> =

>>

>

------=_NextPart_000_005D_01D39F3F.4435D110-- From nobody Tue Feb 6 08:47:52 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9B1B12D856 for ; Tue, 6 Feb 2018 08:47:44 -0800 (PST) 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 TVlRvvMTbJod for ; Tue, 6 Feb 2018 08:47:41 -0800 (PST) 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 43D9312D855 for ; Tue, 6 Feb 2018 08:47:41 -0800 (PST) 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 w16GldAU035733; Tue, 6 Feb 2018 17:47:39 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7EFCE204A1A; Tue, 6 Feb 2018 17:47:39 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 70744202037; Tue, 6 Feb 2018 17:47:39 +0100 (CET) Received: from [132.166.84.122] ([132.166.84.122]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w16GlcZ2013856; Tue, 6 Feb 2018 17:47:39 +0100 To: =?UTF-8?Q?Fran=c3=a7ois_Simon?= Cc: its@ietf.org References: <1517217856.4315.32.camel@it.uc3m.es> <006601d39910$bdcf1cf0$396d56d0$@gmail.com> <000101d39c0f$e3b32f90$ab198eb0$@gmail.com> <87888ef4-ae0e-421c-0e48-43b0276f038a@gmail.com> <001a01d39e93$7ad4e4b0$707eae10$@gmail.com> <000e01d39ef1$b5d553c0$217ffb40$@gmail.com> <38aab103-1a78-b0ba-c7af-2c3bf5ec5c75@gmail.com> <005c01d39f69$2d04ad20$870e0760$@gmail.com> From: Alexandre Petrescu Message-ID: <589c15a1-5ab4-3e16-5b92-c98c7043dcb7@gmail.com> Date: Tue, 6 Feb 2018 17:47:37 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <005c01d39f69$2d04ad20$870e0760$@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] FW: Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 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, 06 Feb 2018 16:47:45 -0000 Le 06/02/2018 à 17:40, François Simon a écrit : > Mr. Petrescu, > > /“//There are two very relevant terms: IP-OBU and IP-RSU.//”/// > > -// IftheWorkingGroupthinksthese terms are relevant, thenso > bid.Irespectfully disagree.Furthermore,I have nothing more to add to > this discussion;I have provided allUS relevant definitions. I thank you for the definitions. I propose we go this way: Copy the definitions from your emails for DSRCS, and then DSRC and then OBU and RSU in terms of DSRCS and of DSRC. But have these definitions (DSRCS, DSRC, OBU and RSU) in an Appendix, not in the Terminology section. The Terminology section would list IP-OBU and IP-RSU and refer to the Appendix. Alex > > Sincerely, > > Francois Simon > > Lojik Technologies > > -----Original Message----- > From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] > Sent: Tuesday, February 06, 2018 10:41 AM > To: François Simon > Cc: its@ietf.org > Subject: Re: FW: [ipwave] Shepherd review of > draft-ietf-ipwave-ipv6-over-80211ocb-12 > > If I add DSRCS, and DSRC, and OBU - it makes for 3 terms only > tangentially relevant. > > I find it too much. > > There are two very relevant terms: IP-OBU and IP-RSU. > > We need to have more relevant terms than tangentially relevant terms. > > Le 06/02/2018 à 03:25, François Simon a écrit : > >> /"//So, in order to define OBU in terms of DSRCS one has to define > >> first DSRCS, all while caring to avoid loops.  I think it can become > >> too lengthy.//"/// > >> > >> -///Dedicated Short-Range Communications////Services (DSRCS)/.-The use > >> of radio techniquesto transfer data over short distancesbetween > >> roadside and mobile > >> > >>         units, between mobile units, and betweenportable and mobile > >>         units to performoperations related to the improvementof traffic > >>         flow, traffic safety, > >> > >>         and other intelligent transportationservice applications in a > >>         varietyof environments. DSRCS systems mayalso transmit status > >>         and instructional > >> > >>         messages related to the units involved.[ Ref. 47 CFR90.7 – > >>         Definitions] > >> > >> -----Original Message----- > >> From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] > >> Sent: Monday, February 05, 2018 10:41 AM > >> To: François Simon > > >> Cc:its@ietf.org > >> Subject: Re: [ipwave] Shepherd review of > >> draft-ietf-ipwave-ipv6-over-80211ocb-12 > >> > >> Le 05/02/2018 à 16:10, François Simon a écrit : > >> > >>> /"//Is DSRCS a typo? (correct DSRC).//"/// > >> > >>> > >> > >>> -// No typo. DSRCS stands for “Dedicated Short Range Communication Service” > >> > >> So, in order to define OBU in terms of DSRCS one has to define first > >> DSRCS, all while caring to avoid loops.  I think it can become too lengthy. > >> > >> Alex > >> > >>> > >> > >>> -----Original Message----- > >> > >>> From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] > >> > >>> Sent: Sunday, February 04, 2018 11:08 AM > >> > >>> To: François Simon >> > >> > >>> Cc:its@ietf.org > >> > >>> Subject: Re: [ipwave] Shepherd review of > >> > >>> draft-ietf-ipwave-ipv6-over-80211ocb-12 > >> > >>> > >> > >>> I am adding this OBU ref for reference but I have a question: > >> > >>> > >> > >>> Le 02/02/2018 à 11:23, François Simon a écrit : > >> > >>> > >> > >>> [...] > >> > >>> > >> > >>>> /On-Board unit (OBU). An On-Board Unit is a DSRCS transceiver that > >>>> is > >> > >>> > >> > >>> Is DSRCS a typo? (correct DSRC). > >> > >>> > >> > >>> Alex > >> > >>> > >> > >>>> 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. The OBUs receive and contend for > >>>> time > >> > >>> > >> > >>>> to transmit on one or more radio frequency (RF) channels. Except > >> > >>>> where > >> > >>> > >> > >>>> specifically excluded, OBU operation is permitted wherever vehicle > >> > >>> > >> > >>>> operation or human passage is permitted. The OBUs mounted in > >>>> vehicles > >> > >>> > >> > >>>> are licensed by rule under part 95 of this chapter and communicate > >> > >>> > >> > >>>> with Roadside Units (RSUs) and other OBUs. Portable OBUs are also > >> > >>> > >> > >>>> licensed by rule under part 95 of this chapter. OBU operations in > >>>> the > >> > >>> > >> > >>>> Unlicensed National Information Infrastructure (UNII) Bands follow > >> > >>>> the > >> > >>> > >> > >>>> rules in those bands./- [CFR 90.7 - Definitions] - October 2010 > >> > >>> > >> > >>>> > >> > >>> > >> > >>>> *IPWAVE Issue*** > >> > >>> > >> > >>>> > >> > >>> > >> > >>>> ** > >> > >>> > >> > >>>> > >> > >>> > >> > >>>> /“The problem with the FCC definition of OBU is that it has no > >> > >>> > >> > >>>> relationship to IP.  Worse, that FCC definition has no indication > >> > >>>> that > >> > >>> > >> > >>>> it MAY use IP somehow.  And here we say that all OBUs must use IP. > >> > >>>> Do > >> > >>> > >> > >>>> you see what I mean?”/// > >> > >>> > >> > >>>> > >> > >>> > >> > >>>> // > >> > >>> > >> > >>>> > >> > >>> > >> > >>>> Correct; the OBU has no relationship with IP and is not intended to. > >> > >>> > >> > >>>> IP is a network protocol.  If an On-Board Unit (OBU) device is > >> > >>> > >> > >>>> required to exchange IP, it needs to be dealt in protocol(s) and/or > >> > >>> > >> > >>>> Management in higher layers similar to WAVE within the On-Board Equipment (OBE) . > >> > >>> > >> > >>>> > >> > >>> > >> > >>>> /“Do you think FCC will mind if we use the term OBU in this draft to > >> > >>> > >> > >>>> mean something else?  I, and a colleague, think that FCC would not > >> > >>> > >> > >>>> mind.”/// > >> > >>> > >> > >>>> > >> > >>> > >> > >>>> // > >> > >>> > >> > >>>> > >> > >>> > >> > >>>> Depending of the reader. If one is familiar with DSRC, OBU and RSU > >>>> as > >> > >>> > >> > >>>> defined by FCC will come in mind. As far as I know, “OBU” and “RSU” > >> > >>> > >> > >>>> are not registered and could be used for other definitions > >>>> (something > >> > >>> > >> > >>>> like > >> > >>> > >> > >>>> “ATM”: Asynchronous Transfer Mode and Automatic Teller Machine😊). > >>>> My > >> > >>> > >> > >>>> suggestion to the IPWAVE team is to use “OBE and RSE”. > >> > >>> > >> > >>>> > >> > >>> > >> > >>>> This is my personal view as I donot represent any involved interest. > >> > >>> > >> > >>>> If any one has questions, let me know. > >> > >>> > >> > >>>> > >> > >>> > >> > >>>> Francois Simon > >> > >>> > >> > >>>> > >> > >>> > >> > >>>> Lojik Technologies > >> > >>> > >> > >>>> > >> > >>> > >> > >>>> -----Original Message----- > >> > >>> > >> > >>>> > >> > >>> > >> > >>>> From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre > >> > >>> > >> > >>>> Petrescu > >> > >>> > >> > >>>> > >> > >>> > >> > >>>> Sent: Monday, January 29, 2018 10:08 AM > >> > >>> > >> > >>>> > >> > >>> > >> > >>>> To:its@ietf.org > >> > >>> > >> > >>>> > >> > >>> > >> > >>>> Subject: Re: [ipwave] Shepherd review of > >> > >>> > >> > >>>> draft-ietf-ipwave-ipv6-over-80211ocb-12 > >> > >>> > >> > >>>> > >> > >>> > >> > >>>> > >> > >>> > >> > >>>> > >> > >>> > >> > >>>> Le 29/01/2018 à 15:52, François Simon a écrit : > >> > >>> > >> > >>>> > >> > >>> > >> > >>>>> My comments arewithin the text*[Fygs.......]*. > >> > >>> > >> > >>>> > >> > >>> > >> > >>>> [...] > >> > >>> > >> > >>>> > >> > >>> > >> > >>>>> In the terminology section, the OBU term is mentioned to be defined > >> > >>> > >> > >>>> > >> > >>> > >> > >>>>> outside the IETF. This is fine, but we have to provide a reference. > >> > >>> > >> > >>>> > >> > >>> > >> > >>>>> And even with that, it would not harm to include some short > >> > >>> > >> > >>>>> definition > >> > >>> > >> > >>>> > >> > >>> > >> > >>>>> to provide context. The RSU term is also defined outside the IETF > >> > >>>>> and > >> > >>> > >> > >>>> > >> > >>> > >> > >>>>> there is quite a lot of text provided (I think the relevant part is > >> > >>> > >> > >>>> > >> > >>> > >> > >>>>> the last sentence, the one starting with "The difference between..."). > >> > >>> > >> > >>>> > >> > >>> > >> > >>>>> Both terms should be handled in the same way. > >> > >>> > >> > >>>> > >> > >>> > >> > >>>>> > >> > >>> > >> > >>>> > >> > >>> > >> > >>>>> *[Fygs: The**definitions**was issued by the FCC 20 years ago.  I > >> > >>>>> have > >> > >>> > >> > >>>> > >> > >>> > >> > >>>>> already provided that information**and references multiple > >> > >>> > >> > >>>> > >> > >>> > >> > >>>>> times.]*** > >> > >>> > >> > >>>> > >> > >>> > >> > >>>> The problem with the FCC definition of OBU is that it has no > >> > >>> > >> > >>>> relationship to IP.  Worse, that FCC definition has no indication > >> > >>>> that > >> > >>> > >> > >>>> it MAY use IP somehow.  And here we say that all OBUs must use IP. > >> > >>>> Do > >> > >>> > >> > >>>> you see what I mean? > >> > >>> > >> > >>>> > >> > >>> > >> > >>>> Do you think FCC will mind if we use the term OBU in this draft to > >> > >>> > >> > >>>> mean something else?  I, and a colleague, think that FCC would not mind. > >> > >>> > >> > >>>> > >> > >>> > >> > >>>> Alex > >> > >>> > >> > >>>> > >> > >>> > >> > >>>> _______________________________________________ > >> > >>> > >> > >>>> > >> > >>> > >> > >>>> its mailing list > >> > >>> > >> > >>>> > >> > >>> > >> > >>>>its@ietf.org. > >>>>org>> > >> > >>> > >> > >>>> > >> > >>> > >> > >>>>https://www.ietf.org/mailman/listinfo/its > >> > >>> > >> > >>>> > >> > >>> > >> > From nobody Tue Feb 6 09:40:28 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 872AD126CF6 for ; Tue, 6 Feb 2018 09:40:26 -0800 (PST) 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 QjhEdMcFlTyC for ; Tue, 6 Feb 2018 09:40:23 -0800 (PST) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF212127337 for ; Tue, 6 Feb 2018 09:40:22 -0800 (PST) Received: by mail-ot0-x232.google.com with SMTP id h14so1718282otj.5 for ; Tue, 06 Feb 2018 09:40:22 -0800 (PST) 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=L6ClBJrmQ0cYX33ppvEboaPuMMbXP2855+lOZFb8gMk=; b=M35F+hOG+fGK11VkWaTFjazu/Rzx3bQZVjVQ4epbTxButYbsbduW7h+eyYv5OfypaG mAdQWQ6nzuT8ezZxSHGzSrfvwOnGzGB0qyZD1LMZrwb9hlR3outfxkOUkH106iZ42SJz 4HdeuDn61nJi5Ax8yS7RCw2YBkYhVBpwvbVDOYjcKuml52w7o18AYh+YIdSKyuWm3gPW gXyLo2oTPNP0BPv1CpYnmDuH1j5RyE+aTGZbF+2Zi8Dwc2Jmfb0PPEq5/PDavn1hgpNH lUK64n/A4T1fE6eWK39p58IGH/z6Y9i/FqXDc3DHqs5BeYDlgjlXm/KfDrm+agiLeC8w LbaQ== 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=L6ClBJrmQ0cYX33ppvEboaPuMMbXP2855+lOZFb8gMk=; b=nhy84NDTJtIfmSMT8hAnSoMPLMRmBI8P+ikzg8h7CjqNeiTlw+O6PVdRDqwy7hnR1L D2Y8gysRb0gCnSwBVsiAk6k/1tZ6iPjnX1pHJcav6yUXV74jDru19+BzkWt7naokrZEZ DR2wI3a2UZQ39RiByMBoRKWvojTIC6ZEtgGmx0RJqy/DLcessCm6c3VjAxgCPK6qxNUt Qo5h5WDvCT30ivdEUwGBfZZmVSOSg/j1KmovyXCOlQf6TaG06xmbABcSP3owZoSdlClX hDMl4uKEVuAxz4q9c8BJ92zMcMLwpL3usWUR3XigNJMDWDDEbKJcOO6FfAZ/Xzj3H8tt vMNA== X-Gm-Message-State: APf1xPBG/MUWCyEfTHRvkn9jmoTfK/eTn3C1hW9kv6ZbqY0nMhJMb3sc fM5Szt4PVBxHcqF2hw0xu8qu8QpGNqNkc/Y4xXYG3A== X-Google-Smtp-Source: AH8x225MjTkmJiB/8w0Afr6s7RXUp+pblzL9ViU7IcqgIu7FcyQFvYdbwvalU6GzedpjhHOvZvdatwBC0BVFSizWTHY= X-Received: by 10.157.63.225 with SMTP id i30mr2279758ote.51.1517938822021; Tue, 06 Feb 2018 09:40:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.9.153 with HTTP; Tue, 6 Feb 2018 09:40:20 -0800 (PST) In-Reply-To: <589c15a1-5ab4-3e16-5b92-c98c7043dcb7@gmail.com> References: <1517217856.4315.32.camel@it.uc3m.es> <006601d39910$bdcf1cf0$396d56d0$@gmail.com> <000101d39c0f$e3b32f90$ab198eb0$@gmail.com> <87888ef4-ae0e-421c-0e48-43b0276f038a@gmail.com> <001a01d39e93$7ad4e4b0$707eae10$@gmail.com> <000e01d39ef1$b5d553c0$217ffb40$@gmail.com> <38aab103-1a78-b0ba-c7af-2c3bf5ec5c75@gmail.com> <005c01d39f69$2d04ad20$870e0760$@gmail.com> <589c15a1-5ab4-3e16-5b92-c98c7043dcb7@gmail.com> From: Abdussalam Baryun Date: Tue, 6 Feb 2018 19:40:20 +0200 Message-ID: To: Alexandre Petrescu Cc: =?UTF-8?Q?Fran=C3=A7ois_Simon?= , its Content-Type: multipart/alternative; boundary="001a113e4fca47089905648eaceb" Archived-At: Subject: Re: [ipwave] FW: Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 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, 06 Feb 2018 17:40:27 -0000 --001a113e4fca47089905648eaceb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alex and Francois, I don't mind putting any clear definition in terms but should be used in the body consistently within the draft. Also we need to try to make the definition short and to the point. I am not very interested in this IP-xxx, however, I like the terminology used in RFC8200. so we should mention that our IP-units are nodes or routers, in terminology the definition word 'computer' used is not consistent with other ietf RFCs. AB On Tue, Feb 6, 2018 at 6:47 PM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > > > Le 06/02/2018 =C3=A0 17:40, Fran=C3=A7ois Simon a =C3=A9crit : > >> Mr. Petrescu, >> >> /=E2=80=9C//There are two very relevant terms: IP-OBU and IP-RSU.//=E2= =80=9D/// >> >> -// IftheWorkingGroupthinksthese terms are relevant, thenso >> bid.Irespectfully disagree.Furthermore,I have nothing more to add to thi= s >> discussion;I have provided allUS relevant definitions. >> > > I thank you for the definitions. > > I propose we go this way: > > Copy the definitions from your emails for DSRCS, and then DSRC and then > OBU and RSU in terms of DSRCS and of DSRC. > > But have these definitions (DSRCS, DSRC, OBU and RSU) in an Appendix, not > in the Terminology section. > > The Terminology section would list IP-OBU and IP-RSU and refer to the > Appendix. > > Alex > > >> Sincerely, >> >> Francois Simon >> >> Lojik Technologies >> >> -----Original Message----- >> From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] >> Sent: Tuesday, February 06, 2018 10:41 AM >> To: Fran=C3=A7ois Simon >> Cc: its@ietf.org >> Subject: Re: FW: [ipwave] Shepherd review of >> draft-ietf-ipwave-ipv6-over-80211ocb-12 >> >> If I add DSRCS, and DSRC, and OBU - it makes for 3 terms only >> tangentially relevant. >> >> I find it too much. >> >> There are two very relevant terms: IP-OBU and IP-RSU. >> >> We need to have more relevant terms than tangentially relevant terms. >> >> Le 06/02/2018 =C3=A0 03:25, Fran=C3=A7ois Simon a =C3=A9crit : >> >> /"//So, in order to define OBU in terms of DSRCS one has to define >>> >> >> first DSRCS, all while caring to avoid loops. I think it can become >>> >> >> too lengthy.//"/// >>> >> >> >>> >> -///Dedicated Short-Range Communications////Services (DSRCS)/.-The use >>> >> >> of radio techniquesto transfer data over short distancesbetween >>> >> >> roadside and mobile >>> >> >> >>> >> units, between mobile units, and betweenportable and mobile >>> >> >> units to performoperations related to the improvementof traffic >>> >> >> flow, traffic safety, >>> >> >> >>> >> and other intelligent transportationservice applications in a >>> >> >> varietyof environments. DSRCS systems mayalso transmit status >>> >> >> and instructional >>> >> >> >>> >> messages related to the units involved.[ Ref. 47 CFR90.7 =E2=80= =93 >>> >> >> Definitions] >>> >> >> >>> >> -----Original Message----- >>> >> >> From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] >>> >> >> Sent: Monday, February 05, 2018 10:41 AM >>> >> >> To: Fran=C3=A7ois Simon > >>> >> >> Cc:its@ietf.org >>> >> >> Subject: Re: [ipwave] Shepherd review of >>> >> >> draft-ietf-ipwave-ipv6-over-80211ocb-12 >>> >> >> >>> >> Le 05/02/2018 =C3=A0 16:10, Fran=C3=A7ois Simon a =C3=A9crit : >>> >> >> >>> >> /"//Is DSRCS a typo? (correct DSRC).//"/// >>>> >>> >> >>> >> >>>> >> >>> >> -// No typo. DSRCS stands for =E2=80=9CDedicated Short Range Communicati= on >>>> Service=E2=80=9D >>>> >>> >> >>> >> So, in order to define OBU in terms of DSRCS one has to define first >>> >> >> DSRCS, all while caring to avoid loops. I think it can become too >>> lengthy. >>> >> >> >>> >> Alex >>> >> >> >>> >> >>>> >> >>> >> -----Original Message----- >>>> >>> >> >>> >> From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] >>>> >>> >> >>> >> Sent: Sunday, February 04, 2018 11:08 AM >>>> >>> >> >>> >> To: Fran=C3=A7ois Simon >>> fygsimon@gmail.com>> >>>> >>> >> >>> >> Cc:its@ietf.org >>>> >>> >> >>> >> Subject: Re: [ipwave] Shepherd review of >>>> >>> >> >>> >> draft-ietf-ipwave-ipv6-over-80211ocb-12 >>>> >>> >> >>> >> >>>> >> >>> >> I am adding this OBU ref for reference but I have a question: >>>> >>> >> >>> >> >>>> >> >>> >> Le 02/02/2018 =C3=A0 11:23, Fran=C3=A7ois Simon a =C3=A9crit : >>>> >>> >> >>> >> >>>> >> >>> >> [...] >>>> >>> >> >>> >> >>>> >> >>> >> /On-Board unit (OBU). An On-Board Unit is a DSRCS transceiver that >>>>> >>>> >> is >>>>> >>>> >> >>> >> >>>> >> >>> >> Is DSRCS a typo? (correct DSRC). >>>> >>> >> >>> >> >>>> >> >>> >> Alex >>>> >>> >> >>> >> >>>> >> >>> >> 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. The OBUs receive and contend for >>>>> >>>> >> time >>>>> >>>> >> >>> >> >>>> >> >>> >> to transmit on one or more radio frequency (RF) channels. Except >>>>> >>>> >> >>> >> where >>>>> >>>> >> >>> >> >>>> >> >>> >> specifically excluded, OBU operation is permitted wherever vehicle >>>>> >>>> >> >>> >> >>>> >> >>> >> operation or human passage is permitted. The OBUs mounted in >>>>> >>>> >> vehicles >>>>> >>>> >> >>> >> >>>> >> >>> >> are licensed by rule under part 95 of this chapter and communicate >>>>> >>>> >> >>> >> >>>> >> >>> >> with Roadside Units (RSUs) and other OBUs. Portable OBUs are also >>>>> >>>> >> >>> >> >>>> >> >>> >> licensed by rule under part 95 of this chapter. OBU operations in >>>>> >>>> >> the >>>>> >>>> >> >>> >> >>>> >> >>> >> Unlicensed National Information Infrastructure (UNII) Bands follow >>>>> >>>> >> >>> >> the >>>>> >>>> >> >>> >> >>>> >> >>> >> rules in those bands./- [CFR 90.7 - Definitions] - October 2010 >>>>> >>>> >> >>> >> >>>> >> >>> >> >>>>> >> >>> >> >>>> >> >>> >> *IPWAVE Issue*** >>>>> >>>> >> >>> >> >>>> >> >>> >> >>>>> >> >>> >> >>>> >> >>> >> ** >>>>> >>>> >> >>> >> >>>> >> >>> >> >>>>> >> >>> >> >>>> >> >>> >> /=E2=80=9CThe problem with the FCC definition of OBU is that it has no >>>>> >>>> >> >>> >> >>>> >> >>> >> relationship to IP. Worse, that FCC definition has no indication >>>>> >>>> >> >>> >> that >>>>> >>>> >> >>> >> >>>> >> >>> >> it MAY use IP somehow. And here we say that all OBUs must use IP. >>>>> >>>> >> >>> >> Do >>>>> >>>> >> >>> >> >>>> >> >>> >> you see what I mean?=E2=80=9D/// >>>>> >>>> >> >>> >> >>>> >> >>> >> >>>>> >> >>> >> >>>> >> >>> >> // >>>>> >>>> >> >>> >> >>>> >> >>> >> >>>>> >> >>> >> >>>> >> >>> >> Correct; the OBU has no relationship with IP and is not intended to. >>>>> >>>> >> >>> >> >>>> >> >>> >> IP is a network protocol. If an On-Board Unit (OBU) device is >>>>> >>>> >> >>> >> >>>> >> >>> >> required to exchange IP, it needs to be dealt in protocol(s) and/or >>>>> >>>> >> >>> >> >>>> >> >>> >> Management in higher layers similar to WAVE within the On-Board Equipmen= t >>>>> (OBE) . >>>>> >>>> >> >>> >> >>>> >> >>> >> >>>>> >> >>> >> >>>> >> >>> >> /=E2=80=9CDo you think FCC will mind if we use the term OBU in this draf= t to >>>>> >>>> >> >>> >> >>>> >> >>> >> mean something else? I, and a colleague, think that FCC would not >>>>> >>>> >> >>> >> >>>> >> >>> >> mind.=E2=80=9D/// >>>>> >>>> >> >>> >> >>>> >> >>> >> >>>>> >> >>> >> >>>> >> >>> >> // >>>>> >>>> >> >>> >> >>>> >> >>> >> >>>>> >> >>> >> >>>> >> >>> >> Depending of the reader. If one is familiar with DSRC, OBU and RSU >>>>> >>>> >> as >>>>> >>>> >> >>> >> >>>> >> >>> >> defined by FCC will come in mind. As far as I know, =E2=80=9COBU=E2=80= =9D and =E2=80=9CRSU=E2=80=9D >>>>> >>>> >> >>> >> >>>> >> >>> >> are not registered and could be used for other definitions >>>>> >>>> >> (something >>>>> >>>> >> >>> >> >>>> >> >>> >> like >>>>> >>>> >> >>> >> >>>> >> >>> >> =E2=80=9CATM=E2=80=9D: Asynchronous Transfer Mode and Automatic Teller M= achine=F0=9F=98=8A). >>>>> >>>> >> My >>>>> >>>> >> >>> >> >>>> >> >>> >> suggestion to the IPWAVE team is to use =E2=80=9COBE and RSE=E2=80=9D. >>>>> >>>> >> >>> >> >>>> >> >>> >> >>>>> >> >>> >> >>>> >> >>> >> This is my personal view as I donot represent any involved interest. >>>>> >>>> >> >>> >> >>>> >> >>> >> If any one has questions, let me know. >>>>> >>>> >> >>> >> >>>> >> >>> >> >>>>> >> >>> >> >>>> >> >>> >> Francois Simon >>>>> >>>> >> >>> >> >>>> >> >>> >> >>>>> >> >>> >> >>>> >> >>> >> Lojik Technologies >>>>> >>>> >> >>> >> >>>> >> >>> >> >>>>> >> >>> >> >>>> >> >>> >> -----Original Message----- >>>>> >>>> >> >>> >> >>>> >> >>> >> >>>>> >> >>> >> >>>> >> >>> >> From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre >>>>> >>>> >> >>> >> >>>> >> >>> >> Petrescu >>>>> >>>> >> >>> >> >>>> >> >>> >> >>>>> >> >>> >> >>>> >> >>> >> Sent: Monday, January 29, 2018 10:08 AM >>>>> >>>> >> >>> >> >>>> >> >>> >> >>>>> >> >>> >> >>>> >> >>> >> To:its@ietf.org >>>>> >>>> >> >>> >> >>>> >> >>> >> >>>>> >> >>> >> >>>> >> >>> >> Subject: Re: [ipwave] Shepherd review of >>>>> >>>> >> >>> >> >>>> >> >>> >> draft-ietf-ipwave-ipv6-over-80211ocb-12 >>>>> >>>> >> >>> >> >>>> >> >>> >> >>>>> >> >>> >> >>>> >> >>> >> >>>>> >> >>> >> >>>> >> >>> >> >>>>> >> >>> >> >>>> >> >>> >> Le 29/01/2018 =C3=A0 15:52, Fran=C3=A7ois Simon a =C3=A9crit : >>>>> >>>> >> >>> >> >>>> >> >>> >> >>>>> >> >>> >> >>>> >> >>> >> My comments arewithin the text*[Fygs.......]*. >>>>>> >>>>> >> >>> >> >>>> >> >>> >> >>>>> >> >>> >> >>>> >> >>> >> [...] >>>>> >>>> >> >>> >> >>>> >> >>> >> >>>>> >> >>> >> >>>> >> >>> >> In the terminology section, the OBU term is mentioned to be defined >>>>>> >>>>> >> >>> >> >>>> >> >>> >> >>>>> >> >>> >> >>>> >> >>> >> outside the IETF. This is fine, but we have to provide a reference. >>>>>> >>>>> >> >>> >> >>>> >> >>> >> >>>>> >> >>> >> >>>> >> >>> >> And even with that, it would not harm to include some short >>>>>> >>>>> >> >>> >> >>>> >> >>> >> definition >>>>>> >>>>> >> >>> >> >>>> >> >>> >> >>>>> >> >>> >> >>>> >> >>> >> to provide context. The RSU term is also defined outside the IETF >>>>>> >>>>> >> >>> >> and >>>>>> >>>>> >> >>> >> >>>> >> >>> >> >>>>> >> >>> >> >>>> >> >>> >> there is quite a lot of text provided (I think the relevant part is >>>>>> >>>>> >> >>> >> >>>> >> >>> >> >>>>> >> >>> >> >>>> >> >>> >> the last sentence, the one starting with "The difference between..."). >>>>>> >>>>> >> >>> >> >>>> >> >>> >> >>>>> >> >>> >> >>>> >> >>> >> Both terms should be handled in the same way. >>>>>> >>>>> >> >>> >> >>>> >> >>> >> >>>>> >> >>> >> >>>> >> >>> >> >>>>>> >> >>> >> >>>> >> >>> >> >>>>> >> >>> >> >>>> >> >>> >> *[Fygs: The**definitions**was issued by the FCC 20 years ago. I >>>>>> >>>>> >> >>> >> have >>>>>> >>>>> >> >>> >> >>>> >> >>> >> >>>>> >> >>> >> >>>> >> --001a113e4fca47089905648eaceb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alex and Francois,

I don&= #39;t mind putting any clear definition in=C2=A0terms but should be used in= the body consistently within the draft. Also we need to try to make the de= finition short and to the point. I am not very interested in this IP-xxx, h= owever, I like the terminology used in RFC8200. so we should mention that o= ur IP-units are nodes or routers, in terminology the definition word 'c= omputer' used is not consistent with other ietf RFCs.

AB

On Tue, Feb 6, 2018 at 6:47 PM, Alexandre Petrescu &= lt;alexan= dre.petrescu@gmail.com> wrote:


Le 06/02/2018 =C3=A0 17:40, Fran=C3=A7ois Simon a =C3=A9crit=C2=A0:
Mr. Petrescu,

/=E2=80=9C//There are two very relevant terms: IP-OBU and IP-RSU.//=E2=80= =9D///

-// IftheWorkingGroupthinksthese terms are relevant, thenso bid.Irespectful= ly disagree.Furthermore,I have nothing more to add to this discussion;I hav= e provided allUS relevant definitions.

I thank you for the definitions.

I propose we go this way:

Copy the definitions from your emails for DSRCS, and then DSRC and then OBU= and RSU in terms of DSRCS and of DSRC.

But have these definitions (DSRCS, DSRC, OBU and RSU) in an Appendix, not i= n the Terminology section.

The Terminology section would list IP-OBU and IP-RSU and refer to the Appen= dix.

Alex


Sincerely,

Francois Simon

Lojik Technologies

-----Original Message-----
From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com]
Sent: Tuesday, February 06, 2018 10:41 AM
To: Fran=C3=A7ois Simon <fygsimon@gmail.com>
Cc: its@ietf.org
Subject: Re: FW: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80= 211ocb-12

If I add DSRCS, and DSRC, and OBU - it makes for 3 terms only tangentially = relevant.

I find it too much.

There are two very relevant terms: IP-OBU and IP-RSU.

We need to have more relevant terms than tangentially relevant terms.

Le 06/02/2018 =C3=A0 03:25, Fran=C3=A7ois Simon a =C3=A9crit=C2=A0:

/"//So, in order to define OBU in terms of DSRCS one has to define

first DSRCS, all while caring to avoid loops.=C2=A0 I think it can become <= br>

too lengthy.//"///



-///Dedicated Short-Range Communications////Services (DSRCS)/.-The use

of radio techniquesto transfer data over short distancesbetween

roadside and mobile



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 units, between mobile unit= s, and betweenportable and mobile

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 units to performoperations= related to the improvementof traffic

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 flow, traffic safety,



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and other intelligent tran= sportationservice applications in a

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 varietyof environments. DS= RCS systems mayalso transmit status

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and instructional



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 messages related to the un= its involved.[ Ref. 47 CFR90.7 =E2=80=93

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Definitions]



-----Original Message-----

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

Sent: Monday, February 05, 2018 10:41 AM

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

Cc:its@ietf.org&= lt;mailto:its@ietf.o= rg>

Subject: Re: [ipwave] Shepherd review of

draft-ietf-ipwave-ipv6-over-80211ocb-12



Le 05/02/2018 =C3=A0 16:10, Fran=C3=A7ois Simon a =C3=A9crit=C2=A0:



/"//Is DSRCS a typo? (correct DSRC).//"///







-// No typo. DSRCS stands for =E2=80=9CDedicated Short Range Communication = Service=E2=80=9D



So, in order to define OBU in terms of DSRCS one has to define first

DSRCS, all while caring to avoid loops.=C2=A0 I think it can become too len= gthy.



Alex







-----Original Message-----



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



Sent: Sunday, February 04, 2018 11:08 AM



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



Cc:its@ietf.org&= lt;mailto:its@ietf.o= rg>



Subject: Re: [ipwave] Shepherd review of



draft-ietf-ipwave-ipv6-over-80211ocb-12







I am adding this OBU ref for reference but I have a question:







Le 02/02/2018 =C3=A0 11:23, Fran=C3=A7ois Simon a =C3=A9crit=C2=A0:







[...]







/On-Board unit (OBU). An On-Board Unit is a DSRCS transceiver that

is







Is DSRCS a typo? (correct DSRC).







Alex







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. The OBUs receive and contend for

time







to transmit on one or more radio frequency (RF) channels. Except



where







specifically excluded, OBU operation is permitted wherever vehicle







operation or human passage is permitted. The OBUs mounted in

vehicles







are licensed by rule under part 95 of this chapter and communicate







with Roadside Units (RSUs) and other OBUs. Portable OBUs are also







licensed by rule under part 95 of this chapter. OBU operations in

the







Unlicensed National Information Infrastructure (UNII) Bands follow



the







rules in those bands./- [CFR 90.7 - Definitions] - October 2010















*IPWAVE Issue***















**















/=E2=80=9CThe problem with the FCC definition of OBU is that it has no







relationship to IP.=C2=A0 Worse, that FCC definition has no indication



that







it MAY use IP somehow.=C2=A0 And here we say that all OBUs must use IP.=C2= =A0



Do







you see what I mean?=E2=80=9D///















//















Correct; the OBU has no relationship with IP and is not intended to.







IP is a network protocol.=C2=A0 If an On-Board Unit (OBU) device is







required to exchange IP, it needs to be dealt in protocol(s) and/or







Management in higher layers similar to WAVE within the On-Board Equipment (= OBE) .















/=E2=80=9CDo you think FCC will mind if we use the term OBU in this draft t= o







mean something else?=C2=A0 I, and a colleague, think that FCC would not







mind.=E2=80=9D///















//















Depending of the reader. If one is familiar with DSRC, OBU and RSU

as







defined by FCC will come in mind. As far as I know, =E2=80=9COBU=E2=80=9D a= nd =E2=80=9CRSU=E2=80=9D







are not registered and could be used for other definitions

(something







like







=E2=80=9CATM=E2=80=9D: Asynchronous Transfer Mode and Automatic Teller Mach= ine=F0=9F=98=8A).

My







suggestion to the IPWAVE team is to use =E2=80=9COBE and RSE=E2=80=9D.















This is my personal view as I donot represent any involved interest.=C2=A0 =







If any one has questions, let me know.















Francois Simon















Lojik Technologies















-----Original Message-----















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







Petrescu















Sent: Monday, January 29, 2018 10:08 AM















To:its@ietf.org&= lt;mailto:its@ietf.o= rg>















Subject: Re: [ipwave] Shepherd review of







draft-ietf-ipwave-ipv6-over-80211ocb-12































Le 29/01/2018 =C3=A0 15:52, Fran=C3=A7ois Simon a =C3=A9crit :















My comments arewithin the text*[Fygs.......]*.















[...]















In the terminology section, the OBU term is mentioned to be defined















outside the IETF. This is fine, but we have to provide a reference.















And even with that, it would not harm to include some short







definition















to provide context. The RSU term is also defined outside the IETF



and















there is quite a lot of text provided (I think the relevant part is















the last sentence, the one starting with "The difference between...&qu= ot;).















Both terms should be handled in the same way.































*[Fygs: The**definitions**was issued by the FCC 20 years ago.=C2=A0 I



have














--001a113e4fca47089905648eaceb-- From nobody Tue Feb 6 10:06:13 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84E571270AB for ; Tue, 6 Feb 2018 10:06:11 -0800 (PST) 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 CgwdzHBFbbMY for ; Tue, 6 Feb 2018 10:06:09 -0800 (PST) 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 C25F7124239 for ; Tue, 6 Feb 2018 10:06:08 -0800 (PST) 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 w16I66lj008352; Tue, 6 Feb 2018 19:06:06 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id DBE27204A43; Tue, 6 Feb 2018 19:06:06 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id CACA02047BB; Tue, 6 Feb 2018 19:06:06 +0100 (CET) Received: from [132.166.84.139] ([132.166.84.139]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w16I66Xq027074; Tue, 6 Feb 2018 19:06:06 +0100 To: Abdussalam Baryun Cc: =?UTF-8?Q?Fran=c3=a7ois_Simon?= , its References: <1517217856.4315.32.camel@it.uc3m.es> <006601d39910$bdcf1cf0$396d56d0$@gmail.com> <000101d39c0f$e3b32f90$ab198eb0$@gmail.com> <87888ef4-ae0e-421c-0e48-43b0276f038a@gmail.com> <001a01d39e93$7ad4e4b0$707eae10$@gmail.com> <000e01d39ef1$b5d553c0$217ffb40$@gmail.com> <38aab103-1a78-b0ba-c7af-2c3bf5ec5c75@gmail.com> <005c01d39f69$2d04ad20$870e0760$@gmail.com> <589c15a1-5ab4-3e16-5b92-c98c7043dcb7@gmail.com> From: Alexandre Petrescu Message-ID: Date: Tue, 6 Feb 2018 19:06:05 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.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] FW: Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 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, 06 Feb 2018 18:06:11 -0000 Le 06/02/2018 à 18:40, Abdussalam Baryun a écrit : > Hi Alex and Francois, > > I don't mind putting any clear definition in terms but should be used in > the body consistently within the draft. IP-OBU and IP-RSU are used in the text. We are not using DSRC, DSRCS, OBU nor RSU in the text. > Also we need to try to make the > definition short and to the point. I am not very interested in this > IP-xxx, however, I like the terminology used in RFC8200. so we should > mention that our IP-units are nodes or routers, Noted. > in terminology the > definition word 'computer' used is not consistent with other ietf RFCs. 'computer' is generic enough to not need a definition. I used 'computer' to solve the problem of saying 'Host' vs saying 'Router'. That debate is not solved and we wont solve it here. Alex > > AB > > On Tue, Feb 6, 2018 at 6:47 PM, Alexandre Petrescu > > wrote: > > > > Le 06/02/2018 à 17:40, François Simon a écrit : > > Mr. Petrescu, > > /“//There are two very relevant terms: IP-OBU and IP-RSU.//”/// > > -// IftheWorkingGroupthinksthese terms are relevant, thenso > bid.Irespectfully disagree.Furthermore,I have nothing more to > add to this discussion;I have provided allUS relevant definitions. > > > I thank you for the definitions. > > I propose we go this way: > > Copy the definitions from your emails for DSRCS, and then DSRC and > then OBU and RSU in terms of DSRCS and of DSRC. > > But have these definitions (DSRCS, DSRC, OBU and RSU) in an > Appendix, not in the Terminology section. > > The Terminology section would list IP-OBU and IP-RSU and refer to > the Appendix. > > Alex > > > Sincerely, > > Francois Simon > > Lojik Technologies > > -----Original Message----- > From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com > ] > Sent: Tuesday, February 06, 2018 10:41 AM > To: François Simon > > Cc: its@ietf.org > Subject: Re: FW: [ipwave] Shepherd review of > draft-ietf-ipwave-ipv6-over-80211ocb-12 > > If I add DSRCS, and DSRC, and OBU - it makes for 3 terms only > tangentially relevant. > > I find it too much. > > There are two very relevant terms: IP-OBU and IP-RSU. > > We need to have more relevant terms than tangentially relevant > terms. > > Le 06/02/2018 à 03:25, François Simon a écrit : > > /"//So, in order to define OBU in terms of DSRCS one has to > define > > > first DSRCS, all while caring to avoid loops.  I think it > can become > > > too lengthy.//"/// > > > > > -///Dedicated Short-Range Communications////Services > (DSRCS)/.-The use > > > of radio techniquesto transfer data over short distancesbetween > > > roadside and mobile > > > > >          units, between mobile units, and betweenportable > and mobile > > >          units to performoperations related to the > improvementof traffic > > >          flow, traffic safety, > > > > >          and other intelligent transportationservice > applications in a > > >          varietyof environments. DSRCS systems mayalso > transmit status > > >          and instructional > > > > >          messages related to the units involved.[ Ref. 47 > CFR90.7 – > > >          Definitions] > > > > > -----Original Message----- > > > From: Alexandre Petrescu > [mailto:alexandre.petrescu@gmail.com > ] > > > Sent: Monday, February 05, 2018 10:41 AM > > > To: François Simon >> > > > Cc:its@ietf.org > > > > > Subject: Re: [ipwave] Shepherd review of > > > draft-ietf-ipwave-ipv6-over-80211ocb-12 > > > > > Le 05/02/2018 à 16:10, François Simon a écrit : > > > > > /"//Is DSRCS a typo? (correct DSRC).//"/// > > > > > > > > > -// No typo. DSRCS stands for “Dedicated Short Range > Communication Service” > > > > > So, in order to define OBU in terms of DSRCS one has to > define first > > > DSRCS, all while caring to avoid loops.  I think it can > become too lengthy. > > > > > Alex > > > > > > > > > -----Original Message----- > > > > > From: Alexandre Petrescu > [mailto:alexandre.petrescu@gmail.com > ] > > > > > Sent: Sunday, February 04, 2018 11:08 AM > > > > > To: François Simon >>> > > > > > Cc:its@ietf.org > > > > > > > Subject: Re: [ipwave] Shepherd review of > > > > > draft-ietf-ipwave-ipv6-over-80211ocb-12 > > > > > > > > > I am adding this OBU ref for reference but I have a > question: > > > > > > > > > Le 02/02/2018 à 11:23, François Simon a écrit : > > > > > > > > > [...] > > > > > > > > > /On-Board unit (OBU). An On-Board Unit is a DSRCS > transceiver that > > > is > > > > > > > > > Is DSRCS a typo? (correct DSRC). > > > > > > > > > Alex > > > > > > > > > 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. The OBUs receive and > contend for > > > time > > > > > > > > > to transmit on one or more radio frequency (RF) > channels. Except > > > > > where > > > > > > > > > specifically excluded, OBU operation is permitted > wherever vehicle > > > > > > > > > operation or human passage is permitted. The OBUs > mounted in > > > vehicles > > > > > > > > > are licensed by rule under part 95 of this chapter > and communicate > > > > > > > > > with Roadside Units (RSUs) and other OBUs. Portable > OBUs are also > > > > > > > > > licensed by rule under part 95 of this chapter. OBU > operations in > > > the > > > > > > > > > Unlicensed National Information Infrastructure > (UNII) Bands follow > > > > > the > > > > > > > > > rules in those bands./- [CFR 90.7 - Definitions] - > October 2010 > > > > > > > > > > > > > > > > > *IPWAVE Issue*** > > > > > > > > > > > > > > > > > ** > > > > > > > > > > > > > > > > > /“The problem with the FCC definition of OBU is that > it has no > > > > > > > > > relationship to IP.  Worse, that FCC definition has > no indication > > > > > that > > > > > > > > > it MAY use IP somehow.  And here we say that all > OBUs must use IP. > > > > > Do > > > > > > > > > you see what I mean?”/// > > > > > > > > > > > > > > > > > // > > > > > > > > > > > > > > > > > Correct; the OBU has no relationship with IP and is > not intended to. > > > > > > > > > IP is a network protocol.  If an On-Board Unit (OBU) > device is > > > > > > > > > required to exchange IP, it needs to be dealt in > protocol(s) and/or > > > > > > > > > Management in higher layers similar to WAVE within > the On-Board Equipment (OBE) . > > > > > > > > > > > > > > > > > /“Do you think FCC will mind if we use the term OBU > in this draft to > > > > > > > > > mean something else?  I, and a colleague, think that > FCC would not > > > > > > > > > mind.”/// > > > > > > > > > > > > > > > > > // > > > > > > > > > > > > > > > > > Depending of the reader. If one is familiar with > DSRC, OBU and RSU > > > as > > > > > > > > > defined by FCC will come in mind. As far as I know, > “OBU” and “RSU” > > > > > > > > > are not registered and could be used for other > definitions > > > (something > > > > > > > > > like > > > > > > > > > “ATM”: Asynchronous Transfer Mode and Automatic > Teller Machine😊). > > > My > > > > > > > > > suggestion to the IPWAVE team is to use “OBE and RSE”. > > > > > > > > > > > > > > > > > This is my personal view as I donot represent any > involved interest. > > > > > > > > > If any one has questions, let me know. > > > > > > > > > > > > > > > > > Francois Simon > > > > > > > > > > > > > > > > > Lojik Technologies > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > > > > From: its [mailto:its-bounces@ietf.org > ] On Behalf Of Alexandre > > > > > > > > > Petrescu > > > > > > > > > > > > > > > > > Sent: Monday, January 29, 2018 10:08 AM > > > > > > > > > > > > > > > > > To:its@ietf.org > > > > > > > > > > > > > > > > > > > Subject: Re: [ipwave] Shepherd review of > > > > > > > > > draft-ietf-ipwave-ipv6-over-80211ocb-12 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Le 29/01/2018 à 15:52, François Simon a écrit : > > > > > > > > > > > > > > > > > My comments arewithin the text*[Fygs.......]*. > > > > > > > > > > > > > > > > > [...] > > > > > > > > > > > > > > > > > In the terminology section, the OBU term is > mentioned to be defined > > > > > > > > > > > > > > > > > outside the IETF. This is fine, but we have to > provide a reference. > > > > > > > > > > > > > > > > > And even with that, it would not harm to include > some short > > > > > > > > > definition > > > > > > > > > > > > > > > > > to provide context. The RSU term is also defined > outside the IETF > > > > > and > > > > > > > > > > > > > > > > > there is quite a lot of text provided (I think > the relevant part is > > > > > > > > > > > > > > > > > the last sentence, the one starting with "The > difference between..."). > > > > > > > > > > > > > > > > > Both terms should be handled in the same way. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *[Fygs: The**definitions**was issued by the FCC > 20 years ago.  I > > > > > have > > > > > > > > > > > > > > > From nobody Tue Feb 6 10:08:52 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F181272E1 for ; Tue, 6 Feb 2018 10:08:50 -0800 (PST) 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 kLx9SD0VWAit for ; Tue, 6 Feb 2018 10:08:48 -0800 (PST) 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 BFFEB1270AB for ; Tue, 6 Feb 2018 10:08:47 -0800 (PST) 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 w16I8hLD030076; Tue, 6 Feb 2018 19:08:43 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 89687204A45; Tue, 6 Feb 2018 19:08:43 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 76FC9204A43; Tue, 6 Feb 2018 19:08:43 +0100 (CET) Received: from [132.166.84.139] ([132.166.84.139]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w16I8gCj029855; Tue, 6 Feb 2018 19:08:43 +0100 To: dickroy@alum.mit.edu, "'Abdussalam Baryun'" Cc: "=?UTF-8?Q?'Fran=c3=a7ois_Simon'?=" , "'its'" References: <1517217856.4315.32.camel@it.uc3m.es> <006601d39910$bdcf1cf0$396d56d0$@gmail.com> <000101d39c0f$e3b32f90$ab198eb0$@gmail.com> <87888ef4-ae0e-421c-0e48-43b0276f038a@gmail.com> <001a01d39e93$7ad4e4b0$707eae10$@gmail.com> <000e01d39ef1$b5d553c0$217ffb40$@gmail.com> <38aab103-1a78-b0ba-c7af-2c3bf5ec5c75@gmail.com> <005c01d39f69$2d04ad20$870e0760$@gmail.com> <589c15a1-5ab4-3e16-5b92-c98c7043dcb7@gmail.com> From: Alexandre Petrescu Message-ID: <56e50435-bdb0-4f79-d7c9-7e782418a316@gmail.com> Date: Tue, 6 Feb 2018 19:08:42 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.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] FW: Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 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, 06 Feb 2018 18:08:50 -0000 Le 06/02/2018 à 19:04, Dick Roy a écrit : > ------------------------------------------------------------------------ > > *From:*its [mailto:its-bounces@ietf.org] *On Behalf Of *Abdussalam Baryun > *Sent:* Tuesday, February 6, 2018 9:40 AM > *To:* Alexandre Petrescu > *Cc:* François Simon; its > *Subject:* Re: [ipwave] FW: Shepherd review of > draft-ietf-ipwave-ipv6-over-80211ocb-12 > > Hi Alex and Francois, > > I don't mind putting any clear definition in terms but should be used in > the body consistently within the draft. Also we need to try to make the > definition short and to the point. I am not very interested in this > IP-xxx, however, I like the terminology used in RFC8200. so we should > mention that our IP-units are nodes or routers, > > */[RR] While certainly not an expert on this, I was under the impression > any entity on an IP network was a node, and that there are two types of > functionality: host and router.  A node can implement host > functionality, router functionality, or both. If that’s the case, this > ought to be clearly stated somewhere./* You see, people already say 'Host vs Router' and 'Node vs Router'. There are a few IPv6 related RFCs that disagree on it. Here we say 'IP-OBU' and 'IP-RSU' and 'computer'. Alex > > */ > RR/* > > in terminology the definition word 'computer' used is not consistent > with other ietf RFCs. > > AB > > On Tue, Feb 6, 2018 at 6:47 PM, Alexandre Petrescu > > wrote: > > > > Le 06/02/2018 à 17:40, François Simon a écrit : > > Mr. Petrescu, > > /“//There are two very relevant terms: IP-OBU and IP-RSU.//”/// > > -// IftheWorkingGroupthinksthese terms are relevant, thenso > bid.Irespectfully disagree.Furthermore,I have nothing more to add to > this discussion;I have provided allUS relevant definitions. > > > I thank you for the definitions. > > I propose we go this way: > > Copy the definitions from your emails for DSRCS, and then DSRC and then > OBU and RSU in terms of DSRCS and of DSRC. > > But have these definitions (DSRCS, DSRC, OBU and RSU) in an Appendix, > not in the Terminology section. > > The Terminology section would list IP-OBU and IP-RSU and refer to the > Appendix. > > Alex > > > Sincerely, > > Francois Simon > > Lojik Technologies > > -----Original Message----- > From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com > ] > Sent: Tuesday, February 06, 2018 10:41 AM > To: François Simon > > Cc: its@ietf.org > Subject: Re: FW: [ipwave] Shepherd review of > draft-ietf-ipwave-ipv6-over-80211ocb-12 > > If I add DSRCS, and DSRC, and OBU - it makes for 3 terms only > tangentially relevant. > > I find it too much. > > There are two very relevant terms: IP-OBU and IP-RSU. > > We need to have more relevant terms than tangentially relevant terms. > > Le 06/02/2018 à 03:25, François Simon a écrit : > > /"//So, in order to define OBU in terms of DSRCS one has to define > > first DSRCS, all while caring to avoid loops.  I think it can become > > too lengthy.//"/// > > -///Dedicated Short-Range Communications////Services (DSRCS)/.-The use > > of radio techniquesto transfer data over short distancesbetween > > roadside and mobile > >          units, between mobile units, and betweenportable and mobile > >          units to performoperations related to the improvementof > traffic > >          flow, traffic safety, > >          and other intelligent transportationservice applications in a > >          varietyof environments. DSRCS systems mayalso transmit status > >          and instructional > >          messages related to the units involved.[ Ref. 47 CFR90.7 – > >          Definitions] > > -----Original Message----- > > From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com > ] > > Sent: Monday, February 05, 2018 10:41 AM > > To: François Simon >> > > Cc:its@ietf.org > > > Subject: Re: [ipwave] Shepherd review of > > draft-ietf-ipwave-ipv6-over-80211ocb-12 > > Le 05/02/2018 à 16:10, François Simon a écrit : > > /"//Is DSRCS a typo? (correct DSRC).//"/// > > -// No typo. DSRCS stands for “Dedicated Short Range > Communication Service” > > So, in order to define OBU in terms of DSRCS one has to define first > > DSRCS, all while caring to avoid loops.  I think it can become too > lengthy. > > Alex > > -----Original Message----- > > From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com > ] > > Sent: Sunday, February 04, 2018 11:08 AM > > To: François Simon >>> > > Cc:its@ietf.org > > > Subject: Re: [ipwave] Shepherd review of > > draft-ietf-ipwave-ipv6-over-80211ocb-12 > > I am adding this OBU ref for reference but I have a question: > > Le 02/02/2018 à 11:23, François Simon a écrit : > > [...] > > /On-Board unit (OBU). An On-Board Unit is a DSRCS > transceiver that > > is > > Is DSRCS a typo? (correct DSRC). > > Alex > > 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. The OBUs receive and contend > for > > time > > to transmit on one or more radio frequency (RF) channels. Except > > where > > specifically excluded, OBU operation is permitted wherever > vehicle > > operation or human passage is permitted. The OBUs mounted in > > vehicles > > are licensed by rule under part 95 of this chapter and > communicate > > with Roadside Units (RSUs) and other OBUs. Portable OBUs are > also > > licensed by rule under part 95 of this chapter. OBU > operations in > > the > > Unlicensed National Information Infrastructure (UNII) Bands > follow > > the > > rules in those bands./- [CFR 90.7 - Definitions] - October 2010 > > *IPWAVE Issue*** > > ** > > /“The problem with the FCC definition of OBU is that it has no > > relationship to IP.  Worse, that FCC definition has no > indication > > that > > it MAY use IP somehow.  And here we say that all OBUs must > use IP. > > Do > > you see what I mean?”/// > > // > > Correct; the OBU has no relationship with IP and is not > intended to. > > IP is a network protocol.  If an On-Board Unit (OBU) device is > > required to exchange IP, it needs to be dealt in protocol(s) > and/or > > Management in higher layers similar to WAVE within the > On-Board Equipment (OBE) . > > /“Do you think FCC will mind if we use the term OBU in this > draft to > > mean something else?  I, and a colleague, think that FCC > would not > > mind.”/// > > // > > Depending of the reader. If one is familiar with DSRC, OBU > and RSU > > as > > defined by FCC will come in mind. As far as I know, “OBU” > and “RSU” > > are not registered and could be used for other definitions > > (something > > like > > “ATM”: Asynchronous Transfer Mode and Automatic Teller > Machine😊). > > My > > suggestion to the IPWAVE team is to use “OBE and RSE”. > > This is my personal view as I donot represent any involved > interest. > > If any one has questions, let me know. > > Francois Simon > > Lojik Technologies > > -----Original Message----- > > From: its [mailto:its-bounces@ietf.org > ] On Behalf Of Alexandre > > Petrescu > > Sent: Monday, January 29, 2018 10:08 AM > > To:its@ietf.org > > > > Subject: Re: [ipwave] Shepherd review of > > draft-ietf-ipwave-ipv6-over-80211ocb-12 > > Le 29/01/2018 à 15:52, François Simon a écrit : > > My comments arewithin the text*[Fygs.......]*. > > [...] > > In the terminology section, the OBU term is mentioned to > be defined > > outside the IETF. This is fine, but we have to provide a > reference. > > And even with that, it would not harm to include some short > > definition > > to provide context. The RSU term is also defined outside > the IETF > > and > > there is quite a lot of text provided (I think the > relevant part is > > the last sentence, the one starting with "The difference > between..."). > > Both terms should be handled in the same way. > > *[Fygs: The**definitions**was issued by the FCC 20 years > ago.  I > > have > From nobody Tue Feb 6 11:01:38 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7A541267BB for ; Tue, 6 Feb 2018 11:01:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.018 X-Spam-Level: X-Spam-Status: No, score=-2.018 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=yahoo.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id up6G8U2UlQus for ; Tue, 6 Feb 2018 11:01:32 -0800 (PST) Received: from sonic305-20.consmr.mail.ir2.yahoo.com (sonic305-20.consmr.mail.ir2.yahoo.com [77.238.177.82]) (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 BD11A120713 for ; Tue, 6 Feb 2018 11:01:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.es; s=s2048; t=1517943689; bh=YIKtqkdF4B8xZMJwUQ2aGa1Q/dwzHtJMR1cdEX82TAE=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=YJp75ZUl9A/F01nhtdFXQga6fpSQfdYxo4mDulZKQiEDvERwdnP8xEYk8KOLOJdxM0G6n/ldtYQKPY/Nj9lhSwJLoyBZ807W9kdEmVDRtefEDJLRzYy2oMRITOAJb00eZnECsHiGXGATmH9TPOMrRaZYhODuCEXUD65WnqK9K1QIjSIU5GpwsFMe4zy763UVKFzCiyB/fAjIo0zPX9+idwUFktclm1B7R6E5zMHdcUd34nFQf8z86Ri3RPe1hOtdj60ibU/fEgoFJkfKU4cnADXdyKLOxszGpHYmNR1+IygpBj3dnxHc26aG2Fe4BzoxGu2S16Gr8M88WT+ZRVQN+Q== X-YMail-OSG: wr8uEIYVM1lSJNvENRwsVnQar9tt.l4LF2dMl_tMLXdXKlDJbtZoHVjvS6kLqml uir5oXwkZ_cM7nDcQtUT738l48fYs6sUrDshCVKvFOG0b6cxCMlIA38JcPzDq7ufLnSbObBd6YC5 YtOHA.NM0DoPv3NzyW8Dmo8hYqafq90AawuxhVpk.1DTJ6OWZT_BeTWQOP9aE44d4E87Kdy1pa0h WWplZ_ycR_632bQgZQOeIzLVCHUufysZhy5qvTW8_9pU.60U8N4ksk9jjnsQtLI7GQrFr.pFbHk. OBt21thvzno699BIM9GYuHaDxOJcQnVDTA2MDis4O_lAMvecPClpklZ3HL8UoOJaJKoUsmsb7ic6 t7ouwgpH6iktV5fYdeK8X2V8kZB7p4d3Exc55HPJ6Aak4BdkJ2OIfJ3372aKTZxdN7fyy79eZdT5 3BOHK8K4mxz9pFeC0r6JmmQ_Bt0KomGWv1SMOya_csb6HxBx.kS1bvGX7wN2VOF.cEuB3M1TSBsl xCDCLYmF7sKg- Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.ir2.yahoo.com with HTTP; Tue, 6 Feb 2018 19:01:29 +0000 Date: Tue, 6 Feb 2018 19:01:28 +0000 (UTC) From: Alfonso Guillen Reply-To: Alfonso Guillen To: "its@ietf.org" Message-ID: <401391121.6944810.1517943688733@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_6944809_1894944028.1517943688716" X-Mailer: WebService/1.1.11316 YahooMailNeo Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36 Archived-At: Subject: Re: [ipwave] its Digest, Vol 68, Issue 18 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, 06 Feb 2018 19:01:38 -0000 ------=_Part_6944809_1894944028.1517943688716 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Some one, can support me how can I help in this Vol and Issue? Regards=C2=A0Alfonso=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 De: "its-request@ietf.org" Para: its@ietf.org=20 Enviado: Martes 6 de febrero de 2018 12:09 Asunto: its Digest, Vol 68, Issue 18 =20 Send its mailing list submissions to =C2=A0=C2=A0=C2=A0 its@ietf.org To subscribe or unsubscribe via the World Wide Web, visit =C2=A0=C2=A0=C2=A0 https://www.ietf.org/mailman/listinfo/its or, via email, send a message with subject or body 'help' to =C2=A0=C2=A0=C2=A0 its-request@ietf.org You can reach the person managing the list at =C2=A0=C2=A0=C2=A0 its-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of its digest..." Today's Topics: =C2=A0 1. Re: FW: Shepherd review of =C2=A0 =C2=A0 =C2=A0 draft-ietf-ipwave-ipv6-over-80211ocb-12 (Alexandre Pet= rescu) =C2=A0 2. Re: FW: Shepherd review of =C2=A0 =C2=A0 =C2=A0 draft-ietf-ipwave-ipv6-over-80211ocb-12 (Alexandre Pet= rescu) Le 06/02/2018 =C3=A0 18:40, Abdussalam Baryun a =C3=A9crit=C2=A0: > Hi Alex and Francois, >=20 > I don't mind putting any clear definition in=C2=A0terms but should be use= d in=20 > the body consistently within the draft. IP-OBU and IP-RSU are used in the text.=C2=A0 We are not using DSRC, DSRCS,= =20 OBU nor RSU in the text. > Also we need to try to make the=20 > definition short and to the point. I am not very interested in this=20 > IP-xxx, however, I like the terminology used in RFC8200. so we should=20 > mention that our IP-units are nodes or routers, Noted. > in terminology the=20 > definition word 'computer' used is not consistent with other ietf RFCs. 'computer' is generic enough to not need a definition. I used 'computer' to solve the problem of saying 'Host' vs saying=20 'Router'.=C2=A0 That debate is not solved and we wont solve it here. Alex >=20 > AB >=20 > On Tue, Feb 6, 2018 at 6:47 PM, Alexandre Petrescu=20 > > wrot= e: >=20 >=20 >=20 >=C2=A0 =C2=A0 Le 06/02/2018 =C3=A0 17:40, Fran=C3=A7ois Simon a =C3=A9crit= =C2=A0: >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Mr. Petrescu, >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 /=E2=80=9C//There are two very relevant terms:= IP-OBU and IP-RSU.//=E2=80=9D/// >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 -// IftheWorkingGroupthinksthese terms are rel= evant, thenso >=C2=A0 =C2=A0 =C2=A0 =C2=A0 bid.Irespectfully disagree.Furthermore,I have = nothing more to >=C2=A0 =C2=A0 =C2=A0 =C2=A0 add to this discussion;I have provided allUS r= elevant definitions. >=20 >=20 >=C2=A0 =C2=A0 I thank you for the definitions. >=20 >=C2=A0 =C2=A0 I propose we go this way: >=20 >=C2=A0 =C2=A0 Copy the definitions from your emails for DSRCS, and then DS= RC and >=C2=A0 =C2=A0 then OBU and RSU in terms of DSRCS and of DSRC. >=20 >=C2=A0 =C2=A0 But have these definitions (DSRCS, DSRC, OBU and RSU) in an >=C2=A0 =C2=A0 Appendix, not in the Terminology section. >=20 >=C2=A0 =C2=A0 The Terminology section would list IP-OBU and IP-RSU and ref= er to >=C2=A0 =C2=A0 the Appendix. >=20 >=C2=A0 =C2=A0 Alex >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Sincerely, >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Francois Simon >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Lojik Technologies >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 -----Original Message----- >=C2=A0 =C2=A0 =C2=A0 =C2=A0 From: Alexandre Petrescu [mailto:alexandre.pet= rescu@gmail.com >=C2=A0 =C2=A0 =C2=A0 =C2=A0 ] >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Sent: Tuesday, February 06, 2018 10:41 AM >=C2=A0 =C2=A0 =C2=A0 =C2=A0 To: Fran=C3=A7ois Simon > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Cc: its@ietf.org >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Subject: Re: FW: [ipwave] Shepherd review of >=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-ipwave-ipv6-over-80211ocb-12 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 If I add DSRCS, and DSRC, and OBU - it makes f= or 3 terms only >=C2=A0 =C2=A0 =C2=A0 =C2=A0 tangentially relevant. >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 I find it too much. >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 There are two very relevant terms: IP-OBU and = IP-RSU. >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 We need to have more relevant terms than tange= ntially relevant >=C2=A0 =C2=A0 =C2=A0 =C2=A0 terms. >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Le 06/02/2018 =C3=A0 03:25, Fran=C3=A7ois Simo= n a =C3=A9crit=C2=A0: >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /"//So, in order to define OBU i= n terms of DSRCS one has to >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 define >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 first DSRCS, all while caring to= avoid loops.=C2=A0 I think it >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 can become >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 too lengthy.//"/// >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -///Dedicated Short-Range Commun= ications////Services >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (DSRCS)/.-The use >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 of radio techniquesto transfer d= ata over short distancesbetween >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 roadside and mobile >=20 >=20 >=20 >=20 >=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 units, between mobile units, and betweenportable >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 and mobile >=20 >=20 >=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 units to performoperations related to the >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 improvementof traffic >=20 >=20 >=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 flow, traffic safety, >=20 >=20 >=20 >=20 >=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 and other intelligent transportationservice >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 applications in a >=20 >=20 >=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 varietyof environments. DSRCS systems mayalso >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 transmit status >=20 >=20 >=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 and instructional >=20 >=20 >=20 >=20 >=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 messages related to the units involved.[ Ref. 47 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CFR90.7 =E2=80=93 >=20 >=20 >=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 Definitions] >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -----Original Message----- >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 From: Alexandre Petrescu >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [mailto:alexandre.petrescu@gmail= .com >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ] >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Sent: Monday, February 05, 2018 = 10:41 AM >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 To: Fran=C3=A7ois Simon =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >> >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Cc:its@ietf.org >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Subject: Re: [ipwave] Shepherd r= eview of >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-ipwave-ipv6-over-8021= 1ocb-12 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Le 05/02/2018 =C3=A0 16:10, Fran= =C3=A7ois Simon a =C3=A9crit=C2=A0: >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /"//Is DSRCS a typ= o? (correct DSRC).//"/// >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -// No typo. DSRCS= stands for =E2=80=9CDedicated Short Range >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Communication Serv= ice=E2=80=9D >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 So, in order to define OBU in te= rms of DSRCS one has to >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 define first >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DSRCS, all while caring to avoid= loops.=C2=A0 I think it can >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 become too lengthy. >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Alex >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -----Original Mess= age----- >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 From: Alexandre Pe= trescu >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [mailto:alexandre.= petrescu@gmail.com >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ] >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Sent: Sunday, Febr= uary 04, 2018 11:08 AM >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 To: Fran=C3=A7ois = Simon =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 >>> >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Cc:its@ietf.org >=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 > >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Subject: Re: [ipwa= ve] Shepherd review of >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-ipwave-= ipv6-over-80211ocb-12 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I am adding this O= BU ref for reference but I have a >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 question: >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Le 02/02/2018 =C3= =A0 11:23, Fran=C3=A7ois Simon a =C3=A9crit=C2=A0: >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [...] >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /On-= Board unit (OBU). An On-Board Unit is a DSRCS >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 tran= sceiver that >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 is >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Is DSRCS a typo? (= correct DSRC). >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Alex >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 norm= ally mounted in or on a vehicle, or which in >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 some= instances may >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 be >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 a po= rtable unit. An OBU can be operational while a >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 vehi= cle or person >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 is e= ither mobile or stationary. The OBUs receive and >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 cont= end for >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 time >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to t= ransmit on one or more radio frequency (RF) >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 chan= nels. Except >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 wher= e >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 spec= ifically excluded, OBU operation is permitted >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 wher= ever vehicle >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 oper= ation or human passage is permitted. The OBUs >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 moun= ted in >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 vehi= cles >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 are = licensed by rule under part 95 of this chapter >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 and = communicate >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 with= Roadside Units (RSUs) and other OBUs. Portable >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 OBUs= are also >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 lice= nsed by rule under part 95 of this chapter. OBU >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 oper= ations in >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Unli= censed National Information Infrastructure >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (UNI= I) Bands follow >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 rule= s in those bands./- [CFR 90.7 - Definitions] - >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Octo= ber 2010 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *IPW= AVE Issue*** >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ** >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /=E2= =80=9CThe problem with the FCC definition of OBU is that >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 it h= as no >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 rela= tionship to IP.=C2=A0 Worse, that FCC definition has >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 no i= ndication >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 that >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 it M= AY use IP somehow.=C2=A0 And here we say that all >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 OBUs= must use IP. >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Do >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 you = see what I mean?=E2=80=9D/// >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Corr= ect; the OBU has no relationship with IP and is >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 not = intended to. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IP i= s a network protocol.=C2=A0 If an On-Board Unit (OBU) >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 devi= ce is >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 requ= ired to exchange IP, it needs to be dealt in >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 prot= ocol(s) and/or >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Mana= gement in higher layers similar to WAVE within >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the = On-Board Equipment (OBE) . >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /=E2= =80=9CDo you think FCC will mind if we use the term OBU >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in t= his draft to >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mean= something else?=C2=A0 I, and a colleague, think that >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 FCC = would not >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mind= .=E2=80=9D/// >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Depe= nding of the reader. If one is familiar with >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DSRC= , OBU and RSU >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 as >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 defi= ned by FCC will come in mind. As far as I know, >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2= =80=9COBU=E2=80=9D and =E2=80=9CRSU=E2=80=9D >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 are = not registered and could be used for other >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 defi= nitions >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (som= ething >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 like >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2= =80=9CATM=E2=80=9D: Asynchronous Transfer Mode and Automatic >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Tell= er Machine=F0=9F=98=8A). >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 My >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 sugg= estion to the IPWAVE team is to use =E2=80=9COBE and RSE=E2=80=9D. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 This= is my personal view as I donot represent any >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 invo= lved interest. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 If a= ny one has questions, let me know. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Fran= cois Simon >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Loji= k Technologies >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ----= -Original Message----- >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 From= : its [mailto:its-bounces@ietf.org >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ] On Behalf Of Alexandre >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Petr= escu >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Sent= : Monday, January 29, 2018 10:08 AM >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 To:i= ts@ietf.org >=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 > >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Subj= ect: Re: [ipwave] Shepherd review of >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draf= t-ietf-ipwave-ipv6-over-80211ocb-12 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Le 2= 9/01/2018 =C3=A0 15:52, Fran=C3=A7ois Simon a =C3=A9crit : >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 My comments arewithin the text*[Fygs.......]*. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [...= ] >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 In the terminology section, the OBU term is >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 mentioned to be defined >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 outside the IETF. This is fine, but we have to >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 provide a reference. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 And even with that, it would not harm to include >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 some short >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 definition >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 to provide context. The RSU term is also defined >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 outside the IETF >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 and >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 there is quite a lot of text provided (I think >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 the relevant part is >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 the last sentence, the one starting with "The >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 difference between..."). >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Both terms should be handled in the same way. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 *[Fygs: The**definitions**was issued by the FCC >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 20 years ago.=C2=A0 I >=20 >=20 >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 have >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 Le 06/02/2018 =C3=A0 19:04, Dick Roy a =C3=A9crit=C2=A0: > ------------------------------------------------------------------------ >=20 > *From:*its [mailto:its-bounces@ietf.org] *On Behalf Of *Abdussalam Baryun > *Sent:* Tuesday, February 6, 2018 9:40 AM > *To:* Alexandre Petrescu > *Cc:* Fran=C3=A7ois Simon; its > *Subject:* Re: [ipwave] FW: Shepherd review of=20 > draft-ietf-ipwave-ipv6-over-80211ocb-12 >=20 > Hi Alex and Francois, >=20 > I don't mind putting any clear definition in=C2=A0terms but should be use= d in=20 > the body consistently within the draft. Also we need to try to make the= =20 > definition short and to the point. I am not very interested in this=20 > IP-xxx, however, I like the terminology used in RFC8200. so we should=20 > mention that our IP-units are nodes or routers, >=20 > */[RR] While certainly not an expert on this, I was under the impression= =20 > any entity on an IP network was a node, and that there are two types of= =20 > functionality: host and router.=C2=A0 A node can implement host=20 > functionality, router functionality, or both. If that=E2=80=99s the case,= this=20 > ought to be clearly stated somewhere./* You see, people already say 'Host vs Router' and 'Node vs Router'.=20 There are a few IPv6 related RFCs that disagree on it. Here we say 'IP-OBU' and 'IP-RSU' and 'computer'. Alex >=20 > */ > RR/* >=20 > in terminology the definition word 'computer' used is not consistent=20 > with other ietf RFCs. >=20 > AB >=20 > On Tue, Feb 6, 2018 at 6:47 PM, Alexandre Petrescu=20 > > wrot= e: >=20 >=20 >=20 > Le 06/02/2018 =C3=A0 17:40, Fran=C3=A7ois Simon a =C3=A9crit=C2=A0: >=20 > Mr. Petrescu, >=20 > /=E2=80=9C//There are two very relevant terms: IP-OBU and IP-RSU.//=E2=80= =9D/// >=20 > -// IftheWorkingGroupthinksthese terms are relevant, thenso=20 > bid.Irespectfully disagree.Furthermore,I have nothing more to add to=20 > this discussion;I have provided allUS relevant definitions. >=20 >=20 > I thank you for the definitions. >=20 > I propose we go this way: >=20 > Copy the definitions from your emails for DSRCS, and then DSRC and then= =20 > OBU and RSU in terms of DSRCS and of DSRC. >=20 > But have these definitions (DSRCS, DSRC, OBU and RSU) in an Appendix,=20 > not in the Terminology section. >=20 > The Terminology section would list IP-OBU and IP-RSU and refer to the=20 > Appendix. >=20 > Alex >=20 >=20 > Sincerely, >=20 > Francois Simon >=20 > Lojik Technologies >=20 > -----Original Message----- > From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com=20 > ] > Sent: Tuesday, February 06, 2018 10:41 AM > To: Fran=C3=A7ois Simon > > Cc: its@ietf.org > Subject: Re: FW: [ipwave] Shepherd review of=20 > draft-ietf-ipwave-ipv6-over-80211ocb-12 >=20 > If I add DSRCS, and DSRC, and OBU - it makes for 3 terms only=20 > tangentially relevant. >=20 > I find it too much. >=20 > There are two very relevant terms: IP-OBU and IP-RSU. >=20 > We need to have more relevant terms than tangentially relevant terms. >=20 > Le 06/02/2018 =C3=A0 03:25, Fran=C3=A7ois Simon a =C3=A9crit=C2=A0: >=20 > /"//So, in order to define OBU in terms of DSRCS one has to define >=20 >=C2=A0 =C2=A0 first DSRCS, all while caring to avoid loops.=C2=A0 I think = it can become >=20 >=C2=A0 =C2=A0 too lengthy.//"/// >=20 >=C2=A0 =C2=A0 -///Dedicated Short-Range Communications////Services (DSRCS)= /.-The use >=20 >=C2=A0 =C2=A0 of radio techniquesto transfer data over short distancesbetw= een >=20 >=C2=A0 =C2=A0 roadside and mobile >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 unit= s, between mobile units, and betweenportable and mobile >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 unit= s to performoperations related to the improvementof >=C2=A0 =C2=A0 traffic >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 flow= , traffic safety, >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and = other intelligent transportationservice applications in a >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 vari= etyof environments. DSRCS systems mayalso transmit status >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and = instructional >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 mess= ages related to the units involved.[ Ref. 47 CFR90.7 =E2=80=93 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Defi= nitions] >=20 >=C2=A0 =C2=A0 -----Original Message----- >=20 >=C2=A0 =C2=A0 From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.co= m >=C2=A0 =C2=A0 ] >=20 >=C2=A0 =C2=A0 Sent: Monday, February 05, 2018 10:41 AM >=20 >=C2=A0 =C2=A0 To: Fran=C3=A7ois Simon =C2=A0 =C2=A0 =C2=A0 =C2=A0 >> >=20 >=C2=A0 =C2=A0 Cc:its@ietf.org =C2=A0 =C2=A0 > >=20 >=C2=A0 =C2=A0 Subject: Re: [ipwave] Shepherd review of >=20 >=C2=A0 =C2=A0 draft-ietf-ipwave-ipv6-over-80211ocb-12 >=20 >=C2=A0 =C2=A0 Le 05/02/2018 =C3=A0 16:10, Fran=C3=A7ois Simon a =C3=A9crit= =C2=A0: >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 /"//Is DSRCS a typo? (correct DSRC).//"/// >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 -// No typo. DSRCS stands for =E2=80=9CDedicat= ed Short Range >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Communication Service=E2=80=9D >=20 >=C2=A0 =C2=A0 So, in order to define OBU in terms of DSRCS one has to defi= ne first >=20 >=C2=A0 =C2=A0 DSRCS, all while caring to avoid loops.=C2=A0 I think it can= become too >=C2=A0 =C2=A0 lengthy. >=20 >=C2=A0 =C2=A0 Alex >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 -----Original Message----- >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 From: Alexandre Petrescu [mailto:alexandre.pet= rescu@gmail.com >=C2=A0 =C2=A0 =C2=A0 =C2=A0 ] >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Sent: Sunday, February 04, 2018 11:08 AM >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 To: Fran=C3=A7ois Simon =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 >>> >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Cc:its@ietf.org =C2=A0 =C2=A0 =C2=A0 =C2=A0 > >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Subject: Re: [ipwave] Shepherd review of >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-ipwave-ipv6-over-80211ocb-12 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 I am adding this OBU ref for reference but I h= ave a question: >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Le 02/02/2018 =C3=A0 11:23, Fran=C3=A7ois Simo= n a =C3=A9crit=C2=A0: >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 [...] >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /On-Board unit (OBU). An On-Boar= d Unit is a DSRCS >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 transceiver that >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 is >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Is DSRCS a typo? (correct DSRC). >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Alex >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 normally mounted in or on a vehi= cle, or which in some >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 instances may >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 be >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 a portable unit. An OBU can be o= perational while a vehicle >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 or person >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 is either mobile or stationary. = The OBUs receive and contend >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 for >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 time >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to transmit on one or more radio= frequency (RF) channels. Except >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 where >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 specifically excluded, OBU opera= tion is permitted wherever >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 vehicle >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 operation or human passage is pe= rmitted. The OBUs mounted in >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 vehicles >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 are licensed by rule under part = 95 of this chapter and >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 communicate >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 with Roadside Units (RSUs) and o= ther OBUs. Portable OBUs are >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 also >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 licensed by rule under part 95 o= f this chapter. OBU >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 operations in >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Unlicensed National Information = Infrastructure (UNII) Bands >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 follow >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 rules in those bands./- [CFR 90.= 7 - Definitions] - October 2010 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *IPWAVE Issue*** >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ** >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /=E2=80=9CThe problem with the F= CC definition of OBU is that it has no >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 relationship to IP.=C2=A0 Worse,= that FCC definition has no >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 indication >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 that >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 it MAY use IP somehow.=C2=A0 And= here we say that all OBUs must >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 use IP. >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Do >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 you see what I mean?=E2=80=9D/// >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Correct; the OBU has no relation= ship with IP and is not >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 intended to. >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IP is a network protocol.=C2=A0 = If an On-Board Unit (OBU) device is >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 required to exchange IP, it need= s to be dealt in protocol(s) >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 and/or >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Management in higher layers simi= lar to WAVE within the >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On-Board Equipment (OBE) . >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /=E2=80=9CDo you think FCC will = mind if we use the term OBU in this >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft to >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mean something else?=C2=A0 I, an= d a colleague, think that FCC >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 would not >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mind.=E2=80=9D/// >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Depending of the reader. If one = is familiar with DSRC, OBU >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 and RSU >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 as >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 defined by FCC will come in mind= . As far as I know, =E2=80=9COBU=E2=80=9D >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 and =E2=80=9CRSU=E2=80=9D >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 are not registered and could be = used for other definitions >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (something >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 like >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=9CATM=E2=80=9D: Asynchron= ous Transfer Mode and Automatic Teller >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Machine=F0=9F=98=8A). >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 My >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 suggestion to the IPWAVE team is= to use =E2=80=9COBE and RSE=E2=80=9D. >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 This is my personal view as I do= not represent any involved >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 interest. >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 If any one has questions, let me= know. >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Francois Simon >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Lojik Technologies >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -----Original Message----- >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 From: its [mailto:its-bounces@ie= tf.org >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ] O= n Behalf Of Alexandre >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Petrescu >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Sent: Monday, January 29, 2018 1= 0:08 AM >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 To:its@ietf.org >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Subject: Re: [ipwave] Shepherd r= eview of >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-ipwave-ipv6-over-8021= 1ocb-12 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Le 29/01/2018 =C3=A0 15:52, Fran= =C3=A7ois Simon a =C3=A9crit : >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 My comments arewit= hin the text*[Fygs.......]*. >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [...] >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 In the terminology= section, the OBU term is mentioned to >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 be defined >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 outside the IETF. = This is fine, but we have to provide a >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 reference. >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 And even with that= , it would not harm to include some short >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 definition >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to provide context= . The RSU term is also defined outside >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the IETF >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 and >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 there is quite a l= ot of text provided (I think the >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 relevant part is >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the last sentence,= the one starting with "The difference >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 between..."). >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Both terms should = be handled in the same way. >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *[Fygs: The**defin= itions**was issued by the FCC 20 years >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ago.=C2=A0 I >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 have >=20 _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its =20 ------=_Part_6944809_1894944028.1517943688716 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Some one, can support me how can I help= in this Vol and Issue?

Regards
 <= /div>
Alfonso&= nbsp;
 
 
 
 


De:= "its-request@ietf.org" <its-request@ietf.org>
Para: its@ietf.org
Enviado: Martes 6 de febrero de 2018 12:09
= Asunto: its Digest, Vol 6= 8, Issue 18

Send its mailing list submissions to

To subscribe or unsubscribe via= the World Wide Web, visit
or, via email, send a message with subject o= r body 'help' to

You can reach the person managing the list at

When replying, please edit your Subject line s= o it is more specific
than "Re: Contents of its d= igest..."
Today's Topics:

  1. Re: FW: Shepherd revie= w of
      draft-ietf-ipwave-ipv6-over-80211ocb-12 (Alexa= ndre Petrescu)
  2. Re: FW: Shepherd review of
    &n= bsp; draft-ietf-ipwave-ipv6-over-80211ocb-12 (Alexandre Petrescu)


Le 06/02/2018 =C3=A0 18:40, Abdussalam Baryun a =C3=A9c= rit :
> Hi Alex and Francois,
>
> I don't mind putt= ing any clear definition in terms but should be used in
> the b= ody consistently within the draft.

IP-OBU and IP-RSU are used in the= text.  We are not using DSRC, DSRCS,
OBU nor RSU in the text.
=
> Also we need to try to make the
> definition short and to t= he point. I am not very interested in this
> IP-xxx, however, I like= the terminology used in RFC8200. so we should
> mention that our IP= -units are nodes or routers,

Noted.

> in terminology the <= br>> definition word 'computer' used is not consistent with other ietf R= FCs.

'computer' is generic enough to not need a definition.

I= used 'computer' to solve the problem of saying 'Host' vs saying
'Route= r'.  That debate is not solved and we wont solve it here.

Alex<= br>
>
> AB
>
> On Tue, Feb 6, 2018 at 6:47 PM, Al= exandre Petrescu
> <alexandre.petrescu@gmail= .com <mailto:alexandre.petrescu@gmail.com&g= t;> wrote:
>
>
>
>    Le 06/02/201= 8 =C3=A0 17:40, Fran=C3=A7ois Simon a =C3=A9crit :
>
>&nb= sp;       Mr. Petrescu,
>
>     = ;   /=E2=80=9C//There are two very relevant terms: IP-OBU and IP-RSU.= //=E2=80=9D///
>
>        -// IftheWorkin= gGroupthinksthese terms are relevant, thenso
>      &n= bsp; bid.Irespectfully disagree.Furthermore,I have nothing more to
>=         add to this discussion;I have provided allUS r= elevant definitions.
>
>
>    I thank you fo= r the definitions.
>
>    I propose we go this way:=
>
>    Copy the definitions from your emails for D= SRCS, and then DSRC and
>    then OBU and RSU in terms of = DSRCS and of DSRC.
>
>    But have these definition= s (DSRCS, DSRC, OBU and RSU) in an
>    Appendix, not in t= he Terminology section.
>
>    The Terminology sect= ion would list IP-OBU and IP-RSU and refer to
>    the App= endix.
>
>    Alex
>
>
>  =       Sincerely,
>
>       = ; Francois Simon
>
>        Lojik Techno= logies
>
>        -----Original Message--= ---
>        From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com
>    &n= bsp;   <mailto:alexandre.petrescu@gmail.com>]
>        Sent: Tuesday, February 06, 201= 8 10:41 AM
>        To: Fran=C3=A7ois Simon <= fygsimon@gmail.com <mailto:fygsimon@gmail.com>>
>&= nbsp;       Cc: its@ietf.org <mailto:its@ietf.org>
>  &n= bsp;     Subject: Re: FW: [ipwave] Shepherd review of
>&nb= sp;       draft-ietf-ipwave-ipv6-over-80211ocb-12
> <= br>>        If I add DSRCS, and DSRC, and OBU - it = makes for 3 terms only
>        tangentially rel= evant.
>
>        I find it too much.
= >
>        There are two very relevant terms= : IP-OBU and IP-RSU.
>
>        We need t= o have more relevant terms than tangentially relevant
>    =     terms.
>
>        Le 06/02= /2018 =C3=A0 03:25, Fran=C3=A7ois Simon a =C3=A9crit :
>
>= ;            /"//So, in order to define OBU = in terms of DSRCS one has to
>          &nbs= p; define
>
>
>          &nbs= p; first DSRCS, all while caring to avoid loops.  I think it
>&= nbsp;           can become
>
>
&= gt;            too lengthy.//"///
> >
>
>
>            = -///Dedicated Short-Range Communications////Services
>    =         (DSRCS)/.-The use
>
>
>&nb= sp;           of radio techniquesto transfer data= over short distancesbetween
>
>
>      =       roadside and mobile
>
>
>
>= ;
>                &nbs= p;      units, between mobile units, and betweenpo= rtable
>            and mobile
>=
>
>               &n= bsp;       units to performoperations related= to the
>            improvementof tra= ffic
>
>
>            &nb= sp;          flow, traffic safety,<= br>>
>
>
>
>        &nbs= p;              and other= intelligent transportationservice
>         = ;   applications in a
>
>
>      &= nbsp;               = varietyof environments. DSRCS systems mayalso
>      =       transmit status
>
>
>   = ;                 &n= bsp;  and instructional
>
>
>
>
>&nb= sp;                  = ;    messages related to the units involved.[ Ref. 47
>= ;            CFR90.7 =E2=80=93
>
&= gt;
>                &n= bsp;      Definitions]
>
>
> <= br>>
>            -----Original Me= ssage-----
>
>
>          &nbs= p; From: Alexandre Petrescu
>          &nbs= p; [mailto:alexandre.petrescu@gmail.com
>&n= bsp;           <mailto:al= exandre.petrescu@gmail.com>]
>
>
>    =         Sent: Monday, February 05, 2018 10:41 AM
&g= t;
>
>            To: Fran=C3= =A7ois Simon <fygsimon@gmail.com
>       =     <mailto:fygsimon@gmail.com><mailto:fygsimon@= gmail.com
>            <mailto:= fygsimon@gmail.com>>>
>
>
>    =         Cc:its@ietf.org
>        &n= bsp;   <mailto:Cc%3Aits@ietf.org><mailto:its@ietf.org
>  &n= bsp;         <mailto:its@ietf.org>>
>
>=
>            Subject: Re: [ipwave] S= hepherd review of
>
>
>        &nbs= p;   draft-ietf-ipwave-ipv6-over-80211ocb-12
>
>
>= ;
>
>            Le 05/02/2018= =C3=A0 16:10, Fran=C3=A7ois Simon a =C3=A9crit :
>
> >
>
>              &nb= sp; /"//Is DSRCS a typo? (correct DSRC).//"///
>
>
> <= br>>
>
>
>
>
>      &n= bsp;         -// No typo. DSRCS stands for =E2=80=9CDe= dicated Short Range
>             =   Communication Service=E2=80=9D
>
>
>
> =
>            So, in order to define O= BU in terms of DSRCS one has to
>          &= nbsp; define first
>
>
>        &n= bsp;   DSRCS, all while caring to avoid loops.  I think it can>            become too lengthy.
>= ;
>
>
>
>          &nb= sp; Alex
>
>
>
>
>
>
> >
>                ----= -Original Message-----
>
>
>
>
>  &n= bsp;             From: Alexandre Petrescu>                [mailto:alexandre.petrescu@gmail.com
>     = ;           <mailto:alexa= ndre.petrescu@gmail.com>]
>
>
>
>
>= ;                Sent: Sunday, Feb= ruary 04, 2018 11:08 AM
>
>
>
>
>  &= nbsp;             To: Fran=C3=A7ois Simon &l= t;fygsimon@gmail.com
>            =     <mailto:fygsimon@gmail.com><mailto:fygsimon@= gmail.com
>               = ; <mailto:fygsimon@gmail.com><mailto:fygsimon@gmail.com=
>                <mailto= :fygsimon@gmail.com><mailto:fygsimon@gmail.com
> = ;               <mailto:fygsimon@= gmail.com>>>>
>
>
>
>
>&n= bsp;               Cc:its@ietf.org
>&nbs= p;               <mailto:Cc%3Aits@ietf.org<= /a>><mailto:its@ietf.org
>            &n= bsp;   <mailto:its@ietf.org>>
>
>
>
> >                Subject: Re:= [ipwave] Shepherd review of
>
>
>
>
>&nb= sp;               draft-ietf-ipwave-ipv= 6-over-80211ocb-12
>
>
>
>
>
> >
>
>              &nb= sp; I am adding this OBU ref for reference but I have a
>  &nbs= p;             question:
>
> >
>
>
>
>
>
>    &= nbsp;           Le 02/02/2018 =C3=A0 11:23, Fran= =C3=A7ois Simon a =C3=A9crit :
>
>
>
>
= >
>
>
>
>          =       [...]
>
>
>
>
> >
>
>
>            &= nbsp;       /On-Board unit (OBU). An On-Board Unit is a DSR= CS
>                  &n= bsp; transceiver that
>
>
>       =             is
>
>
> >
>
>
>
>
>      &nb= sp;         Is DSRCS a typo? (correct DSRC).
> <= br>>
>
>
>
>
>
>
> = ;               Alex
>
> <= br>>
>
>
>
>
>
>    =                 normally mounted i= n or on a vehicle, or which in
>          &n= bsp;         some instances may
>
>
&= gt;
>
>               = ;     be
>
>
>
>
>
> >
>
>              &n= bsp;     a portable unit. An OBU can be operational while a
&= gt;                    v= ehicle or person
>
>
>
>
>
>
&= gt;
>
>               = ;     is either mobile or stationary. The OBUs receive and
&g= t;                    co= ntend for
>
>
>           = ;         time
>
>
>
>
= >
>
>
>
>          =           to transmit on one or more radio freque= ncy (RF)
>                &nb= sp;   channels. Except
>
>
>
>
>&nb= sp;                   where>
>
>
>
>
>
>
>
&= gt;                    s= pecifically excluded, OBU operation is permitted
>     = ;               wherever vehicle
>= ;
>
>
>
>
>
>
>
>&n= bsp;                   operat= ion or human passage is permitted. The OBUs
>      &nb= sp;             mounted in
>
> =
>                  &nbs= p; vehicles
>
>
>
>
>
>
> =
>
>                &n= bsp;   are licensed by rule under part 95 of this chapter
>&nbs= p;                   and comm= unicate
>
>
>
>
>
>
>
&= gt;
>                  =   with Roadside Units (RSUs) and other OBUs. Portable
>  &= nbsp;                 OBUs are als= o
>
>
>
>
>
>
>
> >                   = licensed by rule under part 95 of this chapter. OBU
>    =                 operations in
&= gt;
>
>               = ;     the
>
>
>
>
>
> <= br>>
>
>              &= nbsp;     Unlicensed National Information Infrastructure
>=                     (UNI= I) Bands follow
>
>
>
>
>    &n= bsp;               the
>
>=
>
>
>
>
>
>
>   = ;                 rules in those b= ands./- [CFR 90.7 - Definitions] -
>         = ;           October 2010
>
>
>= ;
>
>
>
>
>
>
>
> <= br>>
>
>
>
>
>      &n= bsp;             *IPWAVE Issue***
> >
>
>
>
>
>
>
>
&= gt;
>
>
>
>
>
>
>  &n= bsp;                 **
> >
>
>
>
>
>
>
>
&= gt;
>
>
>
>
>
>
>  &n= bsp;                 /=E2=80=9CThe= problem with the FCC definition of OBU is that
>     =               it has no
>
&g= t;
>
>
>
>
>
>
>  &nb= sp;                 relationship t= o IP.  Worse, that FCC definition has
>      &nbs= p;             no indication
>
>= ;
>
>
>             = ;       that
>
>
>
>
> >
>
>
>            =         it MAY use IP somehow.  And here we say t= hat all
>                &nbs= p;   OBUs must use IP.
>
>
>
>
>&nb= sp;                   Do
&= gt;
>
>
>
>
>
>
>
>=                     you = see what I mean?=E2=80=9D///
>
>
>
>
> >
>
>
>
>
>
>
>
&= gt;
>
>
>            &nb= sp;       //
>
>
>
>
> >
>
>
>
>
>
>
>
&= gt;
>
>
>            &nb= sp;       Correct; the OBU has no relationship with IP and = is
>                  &n= bsp; not intended to.
>
>
>
>
>
>=
>
>
>             =       IP is a network protocol.  If an On-Board Unit = (OBU)
>                 =   device is
>
>
>
>
>
> >
>
>              &nb= sp;     required to exchange IP, it needs to be dealt in
>=                     prot= ocol(s) and/or
>
>
>
>
>
>
>= ;
>
>                =     Management in higher layers similar to WAVE within
>&n= bsp;                   the On= -Board Equipment (OBE) .
>
>
>
>
>
&g= t;
>
>
>
>
>
>
>
> =
>
>
>              =       /=E2=80=9CDo you think FCC will mind if we use the te= rm OBU
>                 = ;   in this draft to
>
>
>
>
>
= >
>
>
>            &n= bsp;       mean something else?  I, and a colleague, t= hink that
>                &n= bsp;   FCC would not
>
>
>
>
>
= >
>
>
>            &n= bsp;       mind.=E2=80=9D///
>
>
>
= >
>
>
>
>
>
>
>
>= ;
>
>
>
>
>        &= nbsp;           //
>
>
>
= >
>
>
>
>
>
>
>
>= ;
>
>
>
>
>        &= nbsp;           Depending of the reader. If one i= s familiar with
>              &nb= sp;     DSRC, OBU and RSU
>
>
>   =                 as
>
&g= t;
>
>
>
>
>
>
>  &nb= sp;                 defined by FCC= will come in mind. As far as I know,
>        &n= bsp;           =E2=80=9COBU=E2=80=9D and =E2=80= =9CRSU=E2=80=9D
>
>
>
>
>
>
&g= t;
>
>               =     are not registered and could be used for other
> = ;                   definitio= ns
>
>
>             = ;       (something
>
>
>
>
&= gt;
>
>
>
>          &= nbsp;         like
>
>
>
> =
>
>
>
>
>        &nb= sp;           =E2=80=9CATM=E2=80=9D: Asynchronous= Transfer Mode and Automatic
>          &nbs= p;         Teller Machine=F0=9F=98=8A).
>
&g= t;
>                  &= nbsp; My
>
>
>
>
>
>
> >
>                 = ;   suggestion to the IPWAVE team is to use =E2=80=9COBE and RSE=E2= =80=9D.
>
>
>
>
>
>
>
&= gt;
>
>
>
>
>
>
>
>=
>                  &nb= sp; This is my personal view as I donot represent any
>   =                 involved interest= .
>
>
>
>
>
>
>
> >                   = If any one has questions, let me know.
>
>
>
>=
>
>
>
>
>
>
>
> >
>
>
>
>         = ;           Francois Simon
>
>
&= gt;
>
>
>
>
>
>
>
>=
>
>
>
>
>
>      =               Lojik Technologies
>= ;
>
>
>
>
>
>
>
> <= br>>
>
>
>
>
>
>
> = ;                   -----Orig= inal Message-----
>
>
>
>
>
>
= >
>
>
>
>
>
>
>
>= ;
>
>                =     From: its [mailto:its-bounces@ietf.org
> = ;                   <mailt= o:its-bounces@ietf.org>] On Behalf Of Alexandre
>
>= ;
>
>
>
>
>
>
>  &nbs= p;                 Petrescu
>= ;
>
>
>
>
>
>
>
> <= br>>
>
>
>
>
>
>
> = ;                   Sent: Mon= day, January 29, 2018 10:08 AM
>
>
>
>
> =
>
>
>
>
>
>
>
> >
>
>
>            &= nbsp;       To:its@ietf.org
>        &nb= sp;           <mailto:To%3Aits@ietf.org><ma= ilto:its@ie= tf.org
>                &= nbsp;   <mailto:its@ietf.org>>
>
>
>
> <= br>>
>
>
>
>
>
>
>
= >
>
>
>
>          =           Subject: Re: [ipwave] Shepherd review o= f
>
>
>
>
>
>
>
> >                   = draft-ietf-ipwave-ipv6-over-80211ocb-12
>
>
>
>= ;
>
>
>
>
>
>
>
> <= br>>
>
>
>
>
>
>
>
= >
>
>
>
>
>
>
>
>= ;
>
>
>
>          &nb= sp;         Le 29/01/2018 =C3=A0 15:52, Fran=C3=A7ois = Simon a =C3=A9crit :
>
>
>
>
>
> <= br>>
>
>
>
>
>
>
>
= >
>
>              &nbs= p;         My comments arewithin the text*[Fygs.......= ]*.
>
>
>
>
>
>
>
> =
>
>
>
>
>
>
>
> >                    = [...]
>
>
>
>
>
>
>
&g= t;
>
>
>
>
>
>
>
> =
>                  &nbs= p;     In the terminology section, the OBU term is
> =                     &nbs= p; mentioned to be defined
>
>
>
>
> >
>
>
>
>
>
>
>
&g= t;
>
>
>            &nbs= p;           outside the IETF. This is fine, but = we have to
>                &= nbsp;       provide a reference.
>
>
> =
>
>
>
>
>
>
>
> >
>
>
>
>
>      &nbs= p;                 And even with t= hat, it would not harm to include
>         =               some short
>
&= gt;
>
>
>
>
>
>
>  &n= bsp;                     = definition
>
>
>
>
>
>
> <= br>>
>
>
>
>
>
>
>
= >
>                 =       to provide context. The RSU term is also defined
= >                    &= nbsp;   outside the IETF
>
>
>
>
>&= nbsp;                    =   and
>
>
>
>
>
>
> =
>
>
>
>
>
>
>
> >
>                 = ;       there is quite a lot of text provided (I think
&= gt;                    &n= bsp;   the relevant part is
>
>
>
>
&g= t;
>
>
>
>
>
>
>
> =
>
>
>
>           = ;             the last sentence, the one sta= rting with "The
>              &nb= sp;         difference between...").
>
> =
>
>
>
>
>
>
>
> >
>
>
>
>
>
>    &n= bsp;                   Both t= erms should be handled in the same way.
>
>
>
> =
>
>
>
>
>
>
>
> >
>
>
>
>
>
>
>
&g= t;
>
>
>
>
>
>
>
> =
>
>
>
>           = ;             *[Fygs: The**definitions**was = issued by the FCC
>              &= nbsp;         20 years ago.  I
>
> <= br>>
>
>              &= nbsp;         have
>
>
>
> =
>
>
>
>
>
>
>
> >
>
>





L= e 06/02/2018 =C3=A0 19:04, Dick Roy a =C3=A9crit :
> -----------= -------------------------------------------------------------
>
&= gt; *From:*its [mailto:its-bounces@ietf.org] *On Behalf Of *Abduss= alam Baryun
> *Sent:* Tuesday, February 6, 2018 9:40 AM
> *To:*= Alexandre Petrescu
> *Cc:* Fran=C3=A7ois Simon; its
> *Subject= :* Re: [ipwave] FW: Shepherd review of
> draft-ietf-ipwave-ipv6-over= -80211ocb-12
>
> Hi Alex and Francois,
>
> I don'= t mind putting any clear definition in terms but should be used in > the body consistently within the draft. Also we need to try to make t= he
> definition short and to the point. I am not very interested in = this
> IP-xxx, however, I like the terminology used in RFC8200. so w= e should
> mention that our IP-units are nodes or routers,
> <= br>> */[RR] While certainly not an expert on this, I was under the impre= ssion
> any entity on an IP network was a node, and that there are t= wo types of
> functionality: host and router.  A node can imple= ment host
> functionality, router functionality, or both. If that=E2= =80=99s the case, this
> ought to be clearly stated somewhere./*
=
You see, people already say 'Host vs Router' and 'Node vs Router'.
= There are a few IPv6 related RFCs that disagree on it.

Here we say '= IP-OBU' and 'IP-RSU' and 'computer'.

Alex

>
> */> RR/*
>
> in terminology the definition word 'computer' u= sed is not consistent
> with other ietf RFCs.
>
> AB>
> On Tue, Feb 6, 2018 at 6:47 PM, Alexandre Petrescu
> = <alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>> wrote:
>
= >
>
> Le 06/02/2018 =C3=A0 17:40, Fran=C3=A7ois Simon a = =C3=A9crit :
>
> Mr. Petrescu,
>
> /=E2=80= =9C//There are two very relevant terms: IP-OBU and IP-RSU.//=E2=80=9D///>
> -// IftheWorkingGroupthinksthese terms are relevant, thenso =
> bid.Irespectfully disagree.Furthermore,I have nothing more to add = to
> this discussion;I have provided allUS relevant definitions.
= >
>
> I thank you for the definitions.
>
> I = propose we go this way:
>
> Copy the definitions from your ema= ils for DSRCS, and then DSRC and then
> OBU and RSU in terms of DSRC= S and of DSRC.
>
> But have these definitions (DSRCS, DSRC, OB= U and RSU) in an Appendix,
> not in the Terminology section.
>=
> The Terminology section would list IP-OBU and IP-RSU and refer to= the
> Appendix.
>
> Alex
>
>
> Sin= cerely,
>
> Francois Simon
>
> Lojik Technologies=
>
> -----Original Message-----
> From: Alexandre Petres= cu [mailto:alexandre.petrescu@gmail.com
> &= lt;mailto:alexandre.petrescu@gmail.com>]
>= ; Sent: Tuesday, February 06, 2018 10:41 AM
> To: Fran=C3=A7ois Simon= <fygsimon@gmail.com <mailto:fygsimon@gmail.com>>
= > Cc: it= s@ietf.org <mailto:its@ietf.org>
> Subject: Re: FW: [ipwave] Sheph= erd review of
> draft-ietf-ipwave-ipv6-over-80211ocb-12
>
= > If I add DSRCS, and DSRC, and OBU - it makes for 3 terms only
>= tangentially relevant.
>
> I find it too much.
>
&g= t; There are two very relevant terms: IP-OBU and IP-RSU.
>
> W= e need to have more relevant terms than tangentially relevant terms.
>= ;
> Le 06/02/2018 =C3=A0 03:25, Fran=C3=A7ois Simon a =C3=A9crit&nbs= p;:
>
> /"//So, in order to define OBU in terms of DSRCS one h= as to define
>
>    first DSRCS, all while caring t= o avoid loops.  I think it can become
>
>    t= oo lengthy.//"///
>
>    -///Dedicated Short-Range = Communications////Services (DSRCS)/.-The use
>
>    = of radio techniquesto transfer data over short distancesbetween
> >    roadside and mobile
>
>    &nbs= p;          units, between mobile u= nits, and betweenportable and mobile
>
>      &= nbsp;        units to performoperations = related to the improvementof
>    traffic
>
>=                flow,= traffic safety,
>
>         &nb= sp;     and other intelligent transportationservice app= lications in a
>
>          = ;     varietyof environments. DSRCS systems mayalso tra= nsmit status
>
>          &= nbsp;    and instructional
>
>    &nb= sp;          messages related to th= e units involved.[ Ref. 47 CFR90.7 =E2=80=93
>
>    =            Definitions]
>= ;
>    -----Original Message-----
>
>  =   From: Alexandre Petrescu [mailto:alexandre.pet= rescu@gmail.com
>    <mailto:a= lexandre.petrescu@gmail.com>]
>
>    Sent: M= onday, February 05, 2018 10:41 AM
>
>    To: Fran= =C3=A7ois Simon <fygsimon@gmail.com
>    <mailt= o:fygsimon@gmail.com><mailto:fygsimon@gmail.com
>&nbs= p;   <mailto:fygsimon@gmail.com>>>
>
>&= nbsp;   Cc:its@ietf.org <mailto:Cc%3Aits@ietf.org><mailto:its@ietf.org
&= gt;    <mailto:its@ietf.org>>
>
>    S= ubject: Re: [ipwave] Shepherd review of
>
>    draf= t-ietf-ipwave-ipv6-over-80211ocb-12
>
>    Le 05/02= /2018 =C3=A0 16:10, Fran=C3=A7ois Simon a =C3=A9crit :
>
>= ;        /"//Is DSRCS a typo? (correct DSRC).//"///>
>        -// No typo. DSRCS stands for = =E2=80=9CDedicated Short Range
>        Communic= ation Service=E2=80=9D
>
>    So, in order to defin= e OBU in terms of DSRCS one has to define first
>
>  &nbs= p; DSRCS, all while caring to avoid loops.  I think it can become too=
>    lengthy.
>
>    Alex
>=
>        -----Original Message-----
> >        From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com
>      =   <mailto:alexandre.petrescu@gmail.com&g= t;]
>
>        Sent: Sunday, February 04,= 2018 11:08 AM
>
>        To: Fran=C3=A7o= is Simon <fygsimon@gmail.com
>        &l= t;mailto:fygsimon@gmail.com><mailto:fygsimon@gmail.com
&= gt;        <mailto:fygsimon@gmail.com><m= ailto:fygsimon@gmail.com
>        <mailt= o:fygsimon@gmail.com><mailto:fygsimon@gmail.com
>&nbs= p;       <mailto:fygsimon@gmail.com>>>>=
>
>        Cc:its@ietf.org <mailto:Cc%3Aits@ietf.or= g><mailto:its@ietf.org
>        <mailto:its@ietf.org<= /a>>>
>
>        Subject: Re: [ipwa= ve] Shepherd review of
>
>        draft-i= etf-ipwave-ipv6-over-80211ocb-12
>
>       = ; I am adding this OBU ref for reference but I have a question:
> >        Le 02/02/2018 =C3=A0 11:23, Fran=C3=A7oi= s Simon a =C3=A9crit :
>
>        [.= ..]
>
>            /On-Board un= it (OBU). An On-Board Unit is a DSRCS
>        &n= bsp;   transceiver that
>
>        &= nbsp;   is
>
>        Is DSRCS a ty= po? (correct DSRC).
>
>        Alex
&g= t;
>            normally mounted in o= r on a vehicle, or which in some
>          =   instances may
>
>          &n= bsp; be
>
>            a porta= ble unit. An OBU can be operational while a vehicle
>    &n= bsp;       or person
>
>      &= nbsp;     is either mobile or stationary. The OBUs receive and c= ontend
>            for
>
&g= t;            time
>
>  &n= bsp;         to transmit on one or more radio frequenc= y (RF) channels. Except
>
>          =   where
>
>            sp= ecifically excluded, OBU operation is permitted wherever
>  &nbs= p;         vehicle
>
>     = ;       operation or human passage is permitted. The OBUs m= ounted in
>
>            vehicl= es
>
>            are licensed = by rule under part 95 of this chapter and
>       = ;     communicate
>
>        &n= bsp;   with Roadside Units (RSUs) and other OBUs. Portable OBUs are>            also
>
> = ;           licensed by rule under part 95 of thi= s chapter. OBU
>            operations= in
>
>            the
> =
>            Unlicensed National Info= rmation Infrastructure (UNII) Bands
>        &nbs= p;   follow
>
>           = the
>
>            rules in t= hose bands./- [CFR 90.7 - Definitions] - October 2010
>
> = ;           *IPWAVE Issue***
>
>&nbs= p;           **
>
>    &nb= sp;       /=E2=80=9CThe problem with the FCC definition of = OBU is that it has no
>
>          &n= bsp; relationship to IP.  Worse, that FCC definition has no
>&n= bsp;           indication
>
>  =           that
>
>    &nbs= p;       it MAY use IP somehow.  And here we say that = all OBUs must
>            use IP.
= >
>            Do
>
>=             you see what I mean?=E2=80=9D///=
>
>            //
>
= >            Correct; the OBU has no rela= tionship with IP and is not
>           = ; intended to.
>
>            = IP is a network protocol.  If an On-Board Unit (OBU) device is
>=
>            required to exchange IP= , it needs to be dealt in protocol(s)
>        &n= bsp;   and/or
>
>          &nbs= p; Management in higher layers similar to WAVE within the
>  &n= bsp;         On-Board Equipment (OBE) .
>
&g= t;            /=E2=80=9CDo you think FCC wil= l mind if we use the term OBU in this
>        &n= bsp;   draft to
>
>          &n= bsp; mean something else?  I, and a colleague, think that FCC
>=             would not
>
> =           mind.=E2=80=9D///
>
>&nbs= p;           //
>
>    &nb= sp;       Depending of the reader. If one is familiar with = DSRC, OBU
>            and RSU
>=
>            as
>
>&nbs= p;           defined by FCC will come in mind. As= far as I know, =E2=80=9COBU=E2=80=9D
>        &n= bsp;   and =E2=80=9CRSU=E2=80=9D
>
>     =       are not registered and could be used for other defin= itions
>
>            (somethin= g
>
>            like
> <= br>>            =E2=80=9CATM=E2=80=9D: As= ynchronous Transfer Mode and Automatic Teller
>      &= nbsp;     Machine=F0=9F=98=8A).
>
>    &n= bsp;       My
>
>        &= nbsp;   suggestion to the IPWAVE team is to use =E2=80=9COBE and RSE= =E2=80=9D.
>
>            This = is my personal view as I donot represent any involved
>    =         interest.
>
>     =       If any one has questions, let me know.
>
&= gt;            Francois Simon
>
&g= t;            Lojik Technologies
> >            -----Original Message-----<= br>>
>            From: its [mailt= o:its-bounces@ietf.org
>          &= nbsp; <mailto:its-bounces@ietf.org>] On Behalf Of Alexandre=
>
>            Petrescu
>= ;
>            Sent: Monday, January = 29, 2018 10:08 AM
>
>           = To:its@ie= tf.org
>            <mailto:To%= 3Aits@i= etf.org><mailto:its@ietf.org
>          &= nbsp; <mailto:its@ietf.org>>
>
>       =     Subject: Re: [ipwave] Shepherd review of
>
>&n= bsp;           draft-ietf-ipwave-ipv6-over-80211o= cb-12
>
>            Le 29/01/2= 018 =C3=A0 15:52, Fran=C3=A7ois Simon a =C3=A9crit :
>
> =               My comments arewithin th= e text*[Fygs.......]*.
>
>          &= nbsp; [...]
>
>            &nbs= p;   In the terminology section, the OBU term is mentioned to
>=                 be defined
>=
>                outside t= he IETF. This is fine, but we have to provide a
>     =           reference.
>
>  &nbs= p;             And even with that, it would = not harm to include some short
>
>        =         definition
>
>     = ;           to provide context. The RSU term is a= lso defined outside
>             =   the IETF
>
>           =     and
>
>          &nbs= p;     there is quite a lot of text provided (I think the
>= ;                relevant part is<= br>>
>                th= e last sentence, the one starting with "The difference
>   =             between...").
>
>&= nbsp;               Both terms should b= e handled in the same way.
>
>        &nbs= p;       *[Fygs: The**definitions**was issued by the FCC 20= years
>                ago.=   I
>
>              &= nbsp; have
>



_________________________________= ______________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/li= stinfo/its


------=_Part_6944809_1894944028.1517943688716-- From nobody Wed Feb 7 01:07:50 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9BD7126CC7 for ; Wed, 7 Feb 2018 01:07:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 1tMax7IWjiEg for ; Wed, 7 Feb 2018 01:07:48 -0800 (PST) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::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 53EB81200C1 for ; Wed, 7 Feb 2018 01:07:48 -0800 (PST) Received: by mail-oi0-x22e.google.com with SMTP id t78so128610oih.4 for ; Wed, 07 Feb 2018 01:07:48 -0800 (PST) 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=CDl7zQ44dnKaQwZgx7RK0awCAifYN+aFvGfbAXej7yU=; b=VKeqSXpBTMr4ftV7HKWxav6fPiu3Ol6tkMt2BkV6ljmFNjLev5lXCuij5aQ/W9gZnZ 6ub4yMGP82e/5xfLQ4urVMUudZg4c++Zh12UdOtz6cPT+BrJ7oHoD4qTY5JsnXSWmvob EnXuGeBISznlnCr/QsgHbuJwpzG7aC7CzwXcOiDdviIvuYFZVgyxqwBq6gLqXoseDmuD H815h45D5883XiGWyydMiuL1KXPbqpbIFVHRCrkB7xtuW7ZEcchr8GACMOHjiiiJy5+L m/BAUYxJXfB2bhDC5TtjFG/8+88WLo9BjiQMFCku7HMNOv8fEfSluQ+ppo0L5FblF9GU +M9g== 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=CDl7zQ44dnKaQwZgx7RK0awCAifYN+aFvGfbAXej7yU=; b=WVHDzbbCmmRLAwPOBzWT6ywszAH89JFlxumUcf/0gbmJ1GGOeKcC5mMrmYL0x7saMw xsX4k5k5Mc6rnqCUEsQyXiXH+qNIytOkMe/eUUgPc3cpHC5nRn//JlSlR6bLsYK2T5i5 Nr+lPN1AJ9ToOv5euG4Q8BNj7w2Wh8LoWLCqH3D0RqKy/defVH1zwhK8xwuojHEPJtEr krACLpWUlWjj+hiwU6G9gFyS0+yNYVNDbPNw6x3LMBUYKYzN7VjWSugCWpFNCB5sBlvC 2nwZVu7LZrcmhmbHEiu7+kngxCjfx1xpKVhjH7OwTFC/yNbvFIAodxNia5kjK9qyrdQG sj3g== X-Gm-Message-State: APf1xPAohWriNPKlkk6buVxdduX4H+XpAtAIdwF6q1AB/1YhLLIfK41a WlOWur0oGXJ5PK51I1j530NN72I9q+IDG3RyvzE= X-Google-Smtp-Source: AH8x226RQr8teL6Bnddesg1ydwLHOwRglhkBlMbQ+kg2EswFNHxl6uR5wUZf9jBTmMFkPehFLlldxAChZHHN/68e3es= X-Received: by 10.202.68.213 with SMTP id r204mr3668729oia.80.1517994467711; Wed, 07 Feb 2018 01:07:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.9.153 with HTTP; Wed, 7 Feb 2018 01:07:47 -0800 (PST) In-Reply-To: <56e50435-bdb0-4f79-d7c9-7e782418a316@gmail.com> References: <1517217856.4315.32.camel@it.uc3m.es> <006601d39910$bdcf1cf0$396d56d0$@gmail.com> <000101d39c0f$e3b32f90$ab198eb0$@gmail.com> <87888ef4-ae0e-421c-0e48-43b0276f038a@gmail.com> <001a01d39e93$7ad4e4b0$707eae10$@gmail.com> <000e01d39ef1$b5d553c0$217ffb40$@gmail.com> <38aab103-1a78-b0ba-c7af-2c3bf5ec5c75@gmail.com> <005c01d39f69$2d04ad20$870e0760$@gmail.com> <589c15a1-5ab4-3e16-5b92-c98c7043dcb7@gmail.com> <56e50435-bdb0-4f79-d7c9-7e782418a316@gmail.com> From: Abdussalam Baryun Date: Wed, 7 Feb 2018 11:07:47 +0200 Message-ID: To: Alexandre Petrescu Cc: its Content-Type: multipart/alternative; boundary="001a113d74ea04e0f205649ba1c5" Archived-At: Subject: Re: [ipwave] FW: Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 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, 07 Feb 2018 09:07:50 -0000 --001a113d74ea04e0f205649ba1c5 Content-Type: text/plain; charset="UTF-8" I don't mind. Thanks, AB --001a113d74ea04e0f205649ba1c5 Content-Type: text/html; charset="UTF-8"

I don't mind. Thanks,

AB
--001a113d74ea04e0f205649ba1c5-- From nobody Wed Feb 7 03:26:52 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C60E126C0F for ; Wed, 7 Feb 2018 03:26:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=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 tkWnOnMosEql for ; Wed, 7 Feb 2018 03:26:47 -0800 (PST) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6CD9124235 for ; Wed, 7 Feb 2018 03:26:46 -0800 (PST) Received: by mail-wm0-x243.google.com with SMTP id f3so2652637wmc.1 for ; Wed, 07 Feb 2018 03:26:46 -0800 (PST) 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:date:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=sdsaF1gArw9DDumBjlCV6t6HWHCZFa7Yj0H6hxFKkxo=; b=BbSNCaky6lqvUDEkbvk/Mgu2I2Roq84aWkupPllivvs1v7wp4xpIAntRiZ1bWQ6se7 HlrOehXGC4dnG/pxtcgatwBkeyMFwG3qzLuGDmOIsVxANBzZd48V9gKj2UGpl1gIpzUH yWgCtKTJxXQIwt+emDcgI5cxEKqbTa2tTMUDsjQAXHPoeusFl6E2XfLgenBXZHc4n/GB 1GY21opTV5pukHsSEEFk85IvTnwQkGyprpcS4NtDidT8SYZKM9DoSdwtHIHPwcgMCNDI ftECdvSzVh750jsXC/n66zft4HS8JbWNIAprnzpsYmkkaFqrSaP7rgwYg1Q/qutCLmu9 l2JA== 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:date :in-reply-to:references:organization:mime-version :content-transfer-encoding; bh=sdsaF1gArw9DDumBjlCV6t6HWHCZFa7Yj0H6hxFKkxo=; b=sKj2iyWieEhm/sWWHs08zQ5QVkiQUwpxqPoJKzxQgsI17kC1t8nwB7QIQ5z+LSqo/v 55I9eNmpmGDhdprDhH+EeS9zr8WbuuI/sK1s/C4AzRnsu93YU8vtxJIzrj1ZDXhBJnZx EUGdU2q4AS0fWY1Eu0XFM1vbKsmwpZ5JnyBzCOCAdEYxN6d0z9qvapGHEzcqFrhRqiFF Alc3Fv+v78aItC5ZVTR9TmE1m7uNOXJYy9GxxXnkXGtyEMA1qpOOsw3eNGRT+dwA5yto x+pv7wDqCG9KOeCAVwPN0qGBkoUjthE90h7R0MEnD4Zg2GBNa81VQrzNlXR9Jw/OjaPQ Hc9g== X-Gm-Message-State: APf1xPDeUIhG6h2F/UX0LWXbE26VSSObJrOEQXTMxQ46H0nCGOZTAd3/ XCYE4OfAif7VVaeCfs3Q3KjovmYn X-Google-Smtp-Source: AH8x224oAzt8FjSV8aBM6GfDIdOfAs7zVOWbx1g0Jv6NM2OE/Nki+sJ3/m4h/Eno5SijMr8R4lqwqw== X-Received: by 10.28.59.214 with SMTP id i205mr4137425wma.18.1518002805202; Wed, 07 Feb 2018 03:26:45 -0800 (PST) Received: from acorde.lan (grid1.tmit.bme.hu. [152.66.247.112]) by smtp.gmail.com with ESMTPSA id r189sm2514238wmd.39.2018.02.07.03.26.44 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 07 Feb 2018 03:26:44 -0800 (PST) Message-ID: <1518002798.4020.169.camel@it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano Reply-To: cjbc@it.uc3m.es To: Alexandre Petrescu , its@ietf.org Date: Wed, 07 Feb 2018 12:26:38 +0100 In-Reply-To: References: <1517217856.4315.32.camel@it.uc3m.es> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.3-1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 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, 07 Feb 2018 11:26:50 -0000 Hi Alex, On Sun, 2018-02-04 at 18:07 +0100, Alexandre Petrescu wrote: > > Le 29/01/2018 à 10:24, Carlos Jesús Bernardos Cano a écrit : > [...] > > > - The abstract mentions that in order to transmit IPv6 packets on > > IEEE > > 802.11-OCB, "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". But the MTU part of the draft does not use any normative > > text, > > the header format is exactly the same than for IEEE 802.11, as > > the > > type value. > > The MTU text currently says: > > The default MTU for IP packets on 802.11-OCB is 1500 octets. > > I modify it to say: > > The default MTU for IP packets on 802.11-OCB MUST be 1500 octets. > > > - Section 1 lists two exceptions for 802.11-OCB compared to > > Ethernet. > > The first one is not different from regular 802.11, > > I dont understand you. > > The first one says that there are differences between IP-over-WiFi > and > IP-over-Ethernet. These differences are in the headers. To adapt > to > these differences an Ethernet Adaptation Layer is proposed. > > Does this explain better? > > Do I understand the worry correctly? My point is that there is no difference from how IPv6 works over regular WiFi. The adaptation layer is not something IETF can do normative specs. > > > but for the second > > one, the document only provides recommendations. > > Should it provide something else? My comment relates again to the point that this document is aimed to be normative, but we are mostly providing guidelines/recommendations. > > > - I always thought that "WiFi" does not stand for "Wireless > > Fidelity". > > See https://boingboing.net/2005/11/08/wifi-isnt-short-for.html > > Other persons commented, so at this time I propose to leave the def > unchanged. OK, but I still feel that this definition is wrong, but this is rough consensus :D > > [...] > > > > - In section 3, it is mentioned that "the operating environment > > (vehicular networks) brings in new perspectives" --> which are > > those > > (that are covered/tackled by the document? > > The document does not cover these new 'perspectives'. The > 'perspectives' are the ND operation, the handovers for Mobile IP, > the > security - the 3 perspectives are difference in OCB than in > WiFi. We > dont describe any here. > > Maybe new work is needed for ND-over-OCB, or Mobile IP with OCB > access, > or Security for OCB. Agree. I think it is worth to list/mention this. I agree that the document does not tacklke them, but since we mention 'new perspectives', I think the reader may expect an explanation of what those are. > > > - In section 4.1, does the text mean that the MTU SHOULD/MUST be > > 1500 > > octects. If that is what is meant, this is really a normative thing > > that should be written using normative text. If it is just a > > recommendation, then this should be clearly written as such. > > MUST be. > > > - All the text of section 4.2.1 is not normative, but more a report > > of > > what is done today in existing implementations. > > YEs, it is done today in existing WiFi implementations (not > Ethernet). > > > Is there any different > > there that is specific of 802.11-OCB? > > No, there is nothing different. > > I can change the text, but not sure what would be ok. > > Should I move section 4.2.1 in an Appendix? Not sure at this point. Let's think about that possibility. > > > - All subsections 4.x seem informative, not normative. > > Similar to MTU, I could write in the 4.2 "Frame Format" that the > EtherType MUST be 0x86DD (instead of just "is"). Would this make it > more Normative? Yes, but it would anyway be exactly the same as with IPv6-over- Ethernet. My concern is that there seem to be nothing really new of IPv6-over-802.11-OCB compared to IPv6-over-Ethernet/IEEE 802.11. > > In section 4.3 "LL Addresses" I could put "it is RECOMMENDED" instead > of > "it is recommended". > > Sections 4.4. "Address Mapping" and 4.4.1 "Address Mapping -- > Unicast" I > could remove. > > Section 4.4.2 "Address Mapping - Multicast" could be removed. > > Section 4.5 "Stateless Autoconf" - I could write "the u/g bits MUST > be > opaque" instead of "are significant". > > Section 4.6 "Subnet Structure" - could be removed altogether. > > Are these ok with you? Yes. > > > - The privacy part of section 5 is important, as it impacts the > > operation of IPv6 over this type of networks, so I think this > > deserves > > more attention. > > Should I make a subsection called "Privacy Considerations" within > the > SEcurity considerations? That's an option, but what I'd like is to have a bit more text about privacy. > > > - In section, H.1, more details about how the captures were > > obtained > > should be provided (HW, SW, etc.). > > We added this if sounds ok: > > The packet is captured on the Host. The Host is an IP-OBU > > containing an 802.11 interface in format PCI express (an ITRI > > product). The kernel runs the ath5k software driver with > > modifications for OCB mode. The capture tool is Wireshark. > > The file format for save and analyze is 'pcap'. The packet is > > generated by the Router. The Router is an IP-RSU (ITRI > > product). OK, thanks. That's is fine. Carlos > > Authors, please respond to my questions/comments and address them > > in a > > new version of the document. > > We submitted a new version, but please reply to my comments so I > fully > address the comments. > > https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-13 > > Alex > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Wed Feb 7 04:33:59 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A058F124205 for ; Wed, 7 Feb 2018 04:33:58 -0800 (PST) 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 t_IrGwxDVT10 for ; Wed, 7 Feb 2018 04:33:55 -0800 (PST) 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 792241241FC for ; Wed, 7 Feb 2018 04:33:55 -0800 (PST) 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 w17CXrNp048117; Wed, 7 Feb 2018 13:33:53 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A3BFD202E7F; Wed, 7 Feb 2018 13:33:53 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 95CAD202B13; Wed, 7 Feb 2018 13:33:53 +0100 (CET) Received: from [132.166.84.12] ([132.166.84.12]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w17CXqpr011159; Wed, 7 Feb 2018 13:33:53 +0100 To: cjbc@it.uc3m.es, its@ietf.org References: <1517217856.4315.32.camel@it.uc3m.es> <1518002798.4020.169.camel@it.uc3m.es> From: Alexandre Petrescu Message-ID: Date: Wed, 7 Feb 2018 13:33:52 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <1518002798.4020.169.camel@it.uc3m.es> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 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, 07 Feb 2018 12:33:58 -0000 Hi Carlos, Le 07/02/2018 à 12:26, Carlos Jesús Bernardos Cano a écrit : > Hi Alex, > > On Sun, 2018-02-04 at 18:07 +0100, Alexandre Petrescu wrote: >> >> Le 29/01/2018 à 10:24, Carlos Jesús Bernardos Cano a écrit : >> [...] >> >>> - The abstract mentions that in order to transmit IPv6 packets on >>> IEEE >>> 802.11-OCB, "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". But the MTU part of the draft does not use any normative >>> text, >>> the header format is exactly the same than for IEEE 802.11, as >>> the >>> type value. >> >> The MTU text currently says: >>> The default MTU for IP packets on 802.11-OCB is 1500 octets. >> >> I modify it to say: >> > The default MTU for IP packets on 802.11-OCB MUST be 1500 octets. >> >>> - Section 1 lists two exceptions for 802.11-OCB compared to >>> Ethernet. >>> The first one is not different from regular 802.11, >> >> I dont understand you. >> >> The first one says that there are differences between IP-over-WiFi >> and >> IP-over-Ethernet. These differences are in the headers. To adapt >> to >> these differences an Ethernet Adaptation Layer is proposed. >> >> Does this explain better? >> >> Do I understand the worry correctly? > > My point is that there is no difference from how IPv6 works over > regular WiFi. I agree, but there is no RFC for IPv6 over regular WiFi. There is an IPv6-over-Ethernet, but not for IPv6-over-WiFi. When run over WiFi, there is a need of Adaptation Layer. This Adaptation Layer has direct impact on how fragmentation is performed: the field "Sequence number" of the 802.11 Data header is increased when the IP MTU is overcome. This behavior does not exist in Ethernet. > The adaptation layer is not something IETF can do > normative specs. Excuse me Carlos, I dont understand this? There is this RFC4919 section 5 "LowPAN Adaptation Layer and Frame Format" of RFC 4919 "IPv6 over 802.15.4". There are other Adaptation Layers defined in other RFCs on the Standards Track. Or maybe I dont understand what do you mean by "the adaptation layer is not something IETF can do normative specs". >>> but for the second >>> one, the document only provides recommendations. >> >> Should it provide something else? > > My comment relates again to the point that this document is aimed to be > normative, but we are mostly providing guidelines/recommendations. We strived to the best of our wit to move most of guidelines/recommendations into Appendixes. Maybe more should be done. > >> >>> - I always thought that "WiFi" does not stand for "Wireless >>> Fidelity". >>> See https://boingboing.net/2005/11/08/wifi-isnt-short-for.html >> >> Other persons commented, so at this time I propose to leave the def >> unchanged. > > OK, but I still feel that this definition is wrong, but this is rough > consensus :D Maybe we can say: "WiFi - it is believed, in general, that WiFi stands for [...]". > >> >> [...] >>> >>> - In section 3, it is mentioned that "the operating environment >>> (vehicular networks) brings in new perspectives" --> which are >>> those >>> (that are covered/tackled by the document? >> >> The document does not cover these new 'perspectives'. The >> 'perspectives' are the ND operation, the handovers for Mobile IP, >> the >> security - the 3 perspectives are difference in OCB than in >> WiFi. We >> dont describe any here. >> >> Maybe new work is needed for ND-over-OCB, or Mobile IP with OCB >> access, >> or Security for OCB. > > Agree. I think it is worth to list/mention this. I agree that the > document does not tacklke them, but since we mention 'new > perspectives', I think the reader may expect an explanation of what > those are. I agree. I will write something. > >> >>> - In section 4.1, does the text mean that the MTU SHOULD/MUST be >>> 1500 >>> octects. If that is what is meant, this is really a normative thing >>> that should be written using normative text. If it is just a >>> recommendation, then this should be clearly written as such. >> >> MUST be. >> >>> - All the text of section 4.2.1 is not normative, but more a report >>> of >>> what is done today in existing implementations. >> >> YEs, it is done today in existing WiFi implementations (not >> Ethernet). >> >>> Is there any different >>> there that is specific of 802.11-OCB? >> >> No, there is nothing different. >> >> I can change the text, but not sure what would be ok. >> >> Should I move section 4.2.1 in an Appendix? > > Not sure at this point. Let's think about that possibility. > >> >>> - All subsections 4.x seem informative, not normative. >> >> Similar to MTU, I could write in the 4.2 "Frame Format" that the >> EtherType MUST be 0x86DD (instead of just "is"). Would this make it >> more Normative? > > Yes, but it would anyway be exactly the same as with IPv6-over- > Ethernet. My concern is that there seem to be nothing really new of > IPv6-over-802.11-OCB compared to IPv6-over-Ethernet/IEEE 802.11. IPv6-over-Ethernet should not be conflated with IPv6-over-802.11. They are not the same. There is an Adaptation Layer. The 802.11 field "Sequence number" exists in 802.11 but not in Ethernet. There is nothing new between IPv6-over-OCB and IPv6-over-80211. There is something IP new between IPv6-over-80211 and IPv6-over-Ethernet. There is no RFC for IPv6-over-80211. As a consequence, there is something new between IPv6-over-OCB and IPv6-over-Ethernet that deserves be agreed. >> In section 4.3 "LL Addresses" I could put "it is RECOMMENDED" instead >> of >> "it is recommended". >> >> Sections 4.4. "Address Mapping" and 4.4.1 "Address Mapping -- >> Unicast" I >> could remove. >> >> Section 4.4.2 "Address Mapping - Multicast" could be removed. >> >> Section 4.5 "Stateless Autoconf" - I could write "the u/g bits MUST >> be >> opaque" instead of "are significant". >> >> Section 4.6 "Subnet Structure" - could be removed altogether. >> >> Are these ok with you? > > Yes. > >> >>> - The privacy part of section 5 is important, as it impacts the >>> operation of IPv6 over this type of networks, so I think this >>> deserves >>> more attention. >> >> Should I make a subsection called "Privacy Considerations" within >> the >> SEcurity considerations? > > That's an option, but what I'd like is to have a bit more text about > privacy. I will ask my co-authors. >>> - In section, H.1, more details about how the captures were >>> obtained >>> should be provided (HW, SW, etc.). >> >> We added this if sounds ok: >>> The packet is captured on the Host. The Host is an IP-OBU >>> containing an 802.11 interface in format PCI express (an ITRI >>> product). The kernel runs the ath5k software driver with >>> modifications for OCB mode. The capture tool is Wireshark. >>> The file format for save and analyze is 'pcap'. The packet is >>> generated by the Router. The Router is an IP-RSU (ITRI >>> product). > > OK, thanks. That's is fine. Ok, I am happy. Alex > > Carlos > >>> Authors, please respond to my questions/comments and address them >>> in a >>> new version of the document. >> >> We submitted a new version, but please reply to my comments so I >> fully >> address the comments. >> >> https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-13 >> >> Alex >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its > From nobody Wed Feb 7 05:54:22 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF6BE126BF7 for ; Wed, 7 Feb 2018 05:54:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=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 X39f2Om1uu8r for ; Wed, 7 Feb 2018 05:54:17 -0800 (PST) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 062681200FC for ; Wed, 7 Feb 2018 05:54:17 -0800 (PST) Received: by mail-wm0-x244.google.com with SMTP id g1so3284927wmg.2 for ; Wed, 07 Feb 2018 05:54:16 -0800 (PST) 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:date:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=zuNGGJoRmiCqsbUwPyxLIo66uAXqSDI/qaFOwqYi/6Q=; b=X6JkiemVccA+ZZEdnshUJXV137fCdnt/eVScj9AAO0Sz2BeRhSA3QjI6vYhSGcc+oP tqe5HrNDir1C5uAhI4TGxhQzjA4FDbYvfI4+F0Qd5vD8IWDdGvZbtO9gZOtBQ4TJwwi2 3aZ8Hg/m76ey7t9kjuXsmx28O8d6Hdbe2cwas5o2Gm516WEnaWWkKiSuXnNXEnWhhssH mffcxC2xRLruemLNrzntDLYmacCrCcRueJ8eNAu9wf1OVlRU4fy/WcRFi6JN3rfmjkaU LViuWCAabJUrVo77GSM7AvDpx7ayfFbuRo76xqXBBdLCoD5ZnSyHzM2VSlzvTKMEQY9n c6Ig== 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:date :in-reply-to:references:organization:mime-version :content-transfer-encoding; bh=zuNGGJoRmiCqsbUwPyxLIo66uAXqSDI/qaFOwqYi/6Q=; b=bf8wkhFOwfkHHJyo+T8j6SNLjPewSZytUkbJ8Ks4aOJqW+l9Qla4ot45NKxFk1YAP0 MWsdUIBhR4isT7yt4LysdijtE4s9eUlfidE54c1kKNDSC0X4dI8LIgM5KGOBiqkG6mXU 6PMU+w9xxbyokoa3DvHCCZ/mUT1klEE4Mj8ojEA1Tsn0+UGCWXttp33+e1qvOFJOHcel eWX4rwKY5m9MdPxGdmYpZSocTQZgWLw236Zj8Cz21TAR928CJwNUtQFcKAm7H+6xSmg/ viW4i7zlYLIulS2r7xHKKNsNuE9XDtRX3t0WHYSkG+/yV2AXcJ49aAYbU73rvX3cxQa2 I+9g== X-Gm-Message-State: APf1xPArk6r+stcsYht3yxOF5N3Kao+WcUYaCy+NLQZUsK7SFqpjL8BE jji2zHXl5NxUkAbVXqzEgQ/Kyw== X-Google-Smtp-Source: AH8x224nxeFOl4TtSoA9f/8hYt2SHIVcfuYcD/LMEsBCqjvQlgQv150URZlyiF3w2OEv1RPtn7xgkQ== X-Received: by 10.28.5.145 with SMTP id 139mr4490110wmf.89.1518011655242; Wed, 07 Feb 2018 05:54:15 -0800 (PST) Received: from acorde (apn-5-206-142-183.vodafone.hu. [5.206.142.183]) by smtp.gmail.com with ESMTPSA id 62sm1355276wrg.81.2018.02.07.05.54.13 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 07 Feb 2018 05:54:14 -0800 (PST) Message-ID: <1518011649.4020.186.camel@it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano Reply-To: cjbc@it.uc3m.es To: Alexandre Petrescu , its@ietf.org Date: Wed, 07 Feb 2018 14:54:09 +0100 In-Reply-To: References: <1517217856.4315.32.camel@it.uc3m.es> <1518002798.4020.169.camel@it.uc3m.es> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.3-1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 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, 07 Feb 2018 13:54:21 -0000 Hi Alex, On Wed, 2018-02-07 at 13:33 +0100, Alexandre Petrescu wrote: > Hi Carlos, > > Le 07/02/2018 à 12:26, Carlos Jesús Bernardos Cano a écrit : > > Hi Alex, > > > > On Sun, 2018-02-04 at 18:07 +0100, Alexandre Petrescu wrote: > > > > > > Le 29/01/2018 à 10:24, Carlos Jesús Bernardos Cano a écrit : > > > [...] > > > > > > > - The abstract mentions that in order to transmit IPv6 packets > > > > on > > > > IEEE > > > > 802.11-OCB, "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". But the MTU part of the draft does not use any > > > > normative > > > > text, > > > > the header format is exactly the same than for IEEE 802.11, > > > > as > > > > the > > > > type value. > > > > > > The MTU text currently says: > > > > The default MTU for IP packets on 802.11-OCB is 1500 octets. > > > > > > I modify it to say: > > > > The default MTU for IP packets on 802.11-OCB MUST be 1500 > > > octets. > > > > > > > - Section 1 lists two exceptions for 802.11-OCB compared to > > > > Ethernet. > > > > The first one is not different from regular 802.11, > > > > > > I dont understand you. > > > > > > The first one says that there are differences between IP-over- > > > WiFi > > > and > > > IP-over-Ethernet. These differences are in the headers. To > > > adapt > > > to > > > these differences an Ethernet Adaptation Layer is proposed. > > > > > > Does this explain better? > > > > > > Do I understand the worry correctly? > > > > My point is that there is no difference from how IPv6 works over > > regular WiFi. > > I agree, but there is no RFC for IPv6 over regular WiFi. > > There is an IPv6-over-Ethernet, but not for IPv6-over-WiFi. > > When run over WiFi, there is a need of Adaptation Layer. > > This Adaptation Layer has direct impact on how fragmentation is > performed: the field "Sequence number" of the 802.11 Data header is > increased when the IP MTU is overcome. This behavior does not exist > in > Ethernet. But this does not affect the way IPv6 works, does it? This is something taken care by the IEEE 802.11 data header, no? > > > The adaptation layer is not something IETF can do > > normative specs. > > Excuse me Carlos, I dont understand this? There is this RFC4919 > section > 5 "LowPAN Adaptation Layer and Frame Format" of RFC 4919 "IPv6 over > 802.15.4". There are other Adaptation Layers defined in other RFCs > on > the Standards Track. > > Or maybe I dont understand what do you mean by "the adaptation layer > is > not something IETF can do normative specs". > But the adaptation layer you refer to in the ipwave draft is already defined by IEEE 802.11, right? I mean that it is not something the IETF will define. It is already there. The LoWPAN adaptation layer is something defined by IETF to allow IPv6 over IEEE 802.15.4 frame. But in the case of OCB, there is no _additional_ adaptation layer defined in the document (the one documented is the one provided by IEEE 802.11, and this cannot be specified by the IETF). This is what I meant. Not sure if now is more clear. > > > > > but for the second > > > > one, the document only provides recommendations. > > > > > > Should it provide something else? > > > > My comment relates again to the point that this document is aimed > > to be > > normative, but we are mostly providing guidelines/recommendations. > > We strived to the best of our wit to move most of > guidelines/recommendations into Appendixes. Maybe more should be > done. Thanks! I'll check and comment back. > > > > > > > > > > - I always thought that "WiFi" does not stand for "Wireless > > > > Fidelity". > > > > See https://boingboing.net/2005/11/08/wifi-isnt-short-for.html > > > > > > Other persons commented, so at this time I propose to leave the > > > def > > > unchanged. > > > > OK, but I still feel that this definition is wrong, but this is > > rough > > consensus :D > > Maybe we can say: "WiFi - it is believed, in general, that WiFi > stands > for [...]". Well, I don't want to make something big of this. If people are happy with the way it is, keep it. It is something very minor anyway. > > > > > > > > > [...] > > > > > > > > - In section 3, it is mentioned that "the operating environment > > > > (vehicular networks) brings in new perspectives" --> which are > > > > those > > > > (that are covered/tackled by the document? > > > > > > The document does not cover these new 'perspectives'. The > > > 'perspectives' are the ND operation, the handovers for Mobile IP, > > > the > > > security - the 3 perspectives are difference in OCB than in > > > WiFi. We > > > dont describe any here. > > > > > > Maybe new work is needed for ND-over-OCB, or Mobile IP with OCB > > > access, > > > or Security for OCB. > > > > Agree. I think it is worth to list/mention this. I agree that the > > document does not tacklke them, but since we mention 'new > > perspectives', I think the reader may expect an explanation of what > > those are. > > I agree. I will write something. > > > > > > > > > > - In section 4.1, does the text mean that the MTU SHOULD/MUST > > > > be > > > > 1500 > > > > octects. If that is what is meant, this is really a normative > > > > thing > > > > that should be written using normative text. If it is just a > > > > recommendation, then this should be clearly written as such. > > > > > > MUST be. > > > > > > > - All the text of section 4.2.1 is not normative, but more a > > > > report > > > > of > > > > what is done today in existing implementations. > > > > > > YEs, it is done today in existing WiFi implementations (not > > > Ethernet). > > > > > > > Is there any different > > > > there that is specific of 802.11-OCB? > > > > > > No, there is nothing different. > > > > > > I can change the text, but not sure what would be ok. > > > > > > Should I move section 4.2.1 in an Appendix? > > > > Not sure at this point. Let's think about that possibility. > > > > > > > > > - All subsections 4.x seem informative, not normative. > > > > > > Similar to MTU, I could write in the 4.2 "Frame Format" that the > > > EtherType MUST be 0x86DD (instead of just "is"). Would this make > > > it > > > more Normative? > > > > Yes, but it would anyway be exactly the same as with IPv6-over- > > Ethernet. My concern is that there seem to be nothing really new of > > IPv6-over-802.11-OCB compared to IPv6-over-Ethernet/IEEE 802.11. > > IPv6-over-Ethernet should not be conflated with IPv6-over- > 802.11. They > are not the same. There is an Adaptation Layer. The 802.11 field > "Sequence number" exists in 802.11 but not in Ethernet. > > There is nothing new between IPv6-over-OCB and IPv6-over-80211. > > There is something IP new between IPv6-over-80211 and IPv6-over- > Ethernet. > > There is no RFC for IPv6-over-80211. But nothing needed to be done for that, right? You might argue that the effort going on in intarea and mboned/pim on multicast over IEEE 802.11 might have something to do with this, but it is mostly about optimizations, no mandatory things required to make IPv6 over 802.11 work. > > As a consequence, there is something new between IPv6-over-OCB and > IPv6-over-Ethernet that deserves be agreed. I'm not arguing against that. Just saying that this was not completely clear in the draft. > > > > In section 4.3 "LL Addresses" I could put "it is RECOMMENDED" > > > instead > > > of > > > "it is recommended". > > > > > > Sections 4.4. "Address Mapping" and 4.4.1 "Address Mapping -- > > > Unicast" I > > > could remove. > > > > > > Section 4.4.2 "Address Mapping - Multicast" could be removed. > > > > > > Section 4.5 "Stateless Autoconf" - I could write "the u/g bits > > > MUST > > > be > > > opaque" instead of "are significant". > > > > > > Section 4.6 "Subnet Structure" - could be removed altogether. > > > > > > Are these ok with you? > > > > Yes. > > > > > > > > > - The privacy part of section 5 is important, as it impacts the > > > > operation of IPv6 over this type of networks, so I think this > > > > deserves > > > > more attention. > > > > > > Should I make a subsection called "Privacy Considerations" within > > > the > > > SEcurity considerations? > > > > That's an option, but what I'd like is to have a bit more text > > about > > privacy. > > I will ask my co-authors. > > > > > - In section, H.1, more details about how the captures were > > > > obtained > > > > should be provided (HW, SW, etc.). > > > > > > We added this if sounds ok: > > > > The packet is captured on the Host. The Host is an IP- > > > > OBU > > > > containing an 802.11 interface in format PCI express > > > > (an ITRI > > > > product). The kernel runs the ath5k software driver > > > > with > > > > modifications for OCB mode. The capture tool is > > > > Wireshark. > > > > The file format for save and analyze is 'pcap'. The > > > > packet is > > > > generated by the Router. The Router is an IP-RSU (ITRI > > > > product). > > > > OK, thanks. That's is fine. > > Ok, I am happy. Thanks a lot for all the efforts! Carlos > > Alex > > > > > Carlos > > > > > > Authors, please respond to my questions/comments and address > > > > them > > > > in a > > > > new version of the document. > > > > > > We submitted a new version, but please reply to my comments so I > > > fully > > > address the comments. > > > > > > https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb- > > > 13 > > > > > > Alex > > > > > > _______________________________________________ > > > its mailing list > > > its@ietf.org > > > https://www.ietf.org/mailman/listinfo/its From nobody Wed Feb 7 06:18:50 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DEBE1205F0 for ; Wed, 7 Feb 2018 06:18:49 -0800 (PST) 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 cGzywS39CYqI for ; Wed, 7 Feb 2018 06:18:46 -0800 (PST) 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 71FB71200B9 for ; Wed, 7 Feb 2018 06:18:46 -0800 (PST) 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 w17EIiUs073139; Wed, 7 Feb 2018 15:18:44 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6D37320319D; Wed, 7 Feb 2018 15:18:44 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 5E1F220318B; Wed, 7 Feb 2018 15:18:44 +0100 (CET) Received: from [132.166.84.12] ([132.166.84.12]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w17EIhK8030603; Wed, 7 Feb 2018 15:18:43 +0100 To: cjbc@it.uc3m.es, its@ietf.org References: <1517217856.4315.32.camel@it.uc3m.es> <1518002798.4020.169.camel@it.uc3m.es> <1518011649.4020.186.camel@it.uc3m.es> From: Alexandre Petrescu Message-ID: Date: Wed, 7 Feb 2018 15:18:43 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <1518011649.4020.186.camel@it.uc3m.es> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 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, 07 Feb 2018 14:18:49 -0000 Le 07/02/2018 à 14:54, Carlos Jesús Bernardos Cano a écrit : > Hi Alex, > > On Wed, 2018-02-07 at 13:33 +0100, Alexandre Petrescu wrote: >> Hi Carlos, >> >> Le 07/02/2018 à 12:26, Carlos Jesús Bernardos Cano a écrit : >>> Hi Alex, >>> >>> On Sun, 2018-02-04 at 18:07 +0100, Alexandre Petrescu wrote: >>>> >>>> Le 29/01/2018 à 10:24, Carlos Jesús Bernardos Cano a écrit : >>>> [...] >>>> >>>>> - The abstract mentions that in order to transmit IPv6 packets >>>>> on >>>>> IEEE >>>>> 802.11-OCB, "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". But the MTU part of the draft does not use any >>>>> normative >>>>> text, >>>>> the header format is exactly the same than for IEEE 802.11, >>>>> as >>>>> the >>>>> type value. >>>> >>>> The MTU text currently says: >>>>> The default MTU for IP packets on 802.11-OCB is 1500 octets. >>>> >>>> I modify it to say: >>>> > The default MTU for IP packets on 802.11-OCB MUST be 1500 >>>> octets. >>>> >>>>> - Section 1 lists two exceptions for 802.11-OCB compared to >>>>> Ethernet. >>>>> The first one is not different from regular 802.11, >>>> >>>> I dont understand you. >>>> >>>> The first one says that there are differences between IP-over- >>>> WiFi >>>> and >>>> IP-over-Ethernet. These differences are in the headers. To >>>> adapt >>>> to >>>> these differences an Ethernet Adaptation Layer is proposed. >>>> >>>> Does this explain better? >>>> >>>> Do I understand the worry correctly? >>> >>> My point is that there is no difference from how IPv6 works over >>> regular WiFi. >> >> I agree, but there is no RFC for IPv6 over regular WiFi. >> >> There is an IPv6-over-Ethernet, but not for IPv6-over-WiFi. >> >> When run over WiFi, there is a need of Adaptation Layer. >> >> This Adaptation Layer has direct impact on how fragmentation is >> performed: the field "Sequence number" of the 802.11 Data header is >> increased when the IP MTU is overcome. This behavior does not exist >> in >> Ethernet. > > But this does not affect the way IPv6 works, does it? This is something > taken care by the IEEE 802.11 data header, no? At sending, the IP stack decides whether it fragments and then tells the MAC layer to increase its seqno. At reception, vice-versa. IPv6 Fragment Header also has an Identification field. The two fields (Id field in IPv6 header and seqno in 802.11 MAC header) are correlated. That's pretty much it. It could be the same with QoS (TCLASS field in 802.11 header, and Traffic Class field in 802.11 Header); but at this time there's no work on this. > >> >>> The adaptation layer is not something IETF can do >>> normative specs. >> >> Excuse me Carlos, I dont understand this? There is this RFC4919 >> section >> 5 "LowPAN Adaptation Layer and Frame Format" of RFC 4919 "IPv6 over >> 802.15.4". There are other Adaptation Layers defined in other RFCs >> on >> the Standards Track. >> >> Or maybe I dont understand what do you mean by "the adaptation layer >> is >> not something IETF can do normative specs". >> > > But the adaptation layer you refer to in the ipwave draft is already > defined by IEEE 802.11, right? No, Ethernet Adaptation Layer is not defined anywhere. It is just implemented. Now it is defined in this ipwave Internet Draft. > I mean that it is not something the IETF > will define. It is already there. It is there implemented but there is no spec, neither at IEEE nor at IETF. Now it is in this ipwave draft, if we want it. > The LoWPAN adaptation layer is > something defined by IETF to allow IPv6 over IEEE 802.15.4 frame. Yes. In their case too, IPv6 worked fine over some kind of 802.15.4, there was no need of new RFC. Yet they felt there was a need of an Adaptation Layer. But they went way too far with that Adaptation Layer: instead of just reproducing how IP-over-15.4 works fine they felt like creating new functionalities; yet these added parts is what they make it incompatible with how "IPv6 works ok over 15.4". I believe in our case, the IPv6-over-OCB reflects precisely how IPv6 works ok over OCB. There is no new things added. I also want to tell about implementation: the OCB mode evolved from driver patches maintained by various individuals to more and more integration into the streamline kernel. Nowadays only a few changes are needed to the streamline kernel, the OCB is there almost entirely. The ipwave draft is in conformance with this OCB mode in the linux kernel. > But > in the case of OCB, there is no _additional_ adaptation layer defined > in the document (the one documented is the one provided by IEEE 802.11, > and this cannot be specified by the IETF). This is what I meant. Not > sure if now is more clear. I understand better what you meant, thank you, but I disagree. >> >>>>> but for the second >>>>> one, the document only provides recommendations. >>>> >>>> Should it provide something else? >>> >>> My comment relates again to the point that this document is aimed >>> to be >>> normative, but we are mostly providing guidelines/recommendations. >> >> We strived to the best of our wit to move most of >> guidelines/recommendations into Appendixes. Maybe more should be >> done. > > Thanks! I'll check and comment back. > >> >>> >>>> >>>>> - I always thought that "WiFi" does not stand for "Wireless >>>>> Fidelity". >>>>> See https://boingboing.net/2005/11/08/wifi-isnt-short-for.html >>>> >>>> Other persons commented, so at this time I propose to leave the >>>> def >>>> unchanged. >>> >>> OK, but I still feel that this definition is wrong, but this is >>> rough >>> consensus :D >> >> Maybe we can say: "WiFi - it is believed, in general, that WiFi >> stands >> for [...]". > > Well, I don't want to make something big of this. If people are happy > with the way it is, keep it. It is something very minor anyway. I agree. > >> >>> >>>> >>>> [...] >>>>> >>>>> - In section 3, it is mentioned that "the operating environment >>>>> (vehicular networks) brings in new perspectives" --> which are >>>>> those >>>>> (that are covered/tackled by the document? >>>> >>>> The document does not cover these new 'perspectives'. The >>>> 'perspectives' are the ND operation, the handovers for Mobile IP, >>>> the >>>> security - the 3 perspectives are difference in OCB than in >>>> WiFi. We >>>> dont describe any here. >>>> >>>> Maybe new work is needed for ND-over-OCB, or Mobile IP with OCB >>>> access, >>>> or Security for OCB. >>> >>> Agree. I think it is worth to list/mention this. I agree that the >>> document does not tacklke them, but since we mention 'new >>> perspectives', I think the reader may expect an explanation of what >>> those are. >> >> I agree. I will write something. >> >>> >>>> >>>>> - In section 4.1, does the text mean that the MTU SHOULD/MUST >>>>> be >>>>> 1500 >>>>> octects. If that is what is meant, this is really a normative >>>>> thing >>>>> that should be written using normative text. If it is just a >>>>> recommendation, then this should be clearly written as such. >>>> >>>> MUST be. >>>> >>>>> - All the text of section 4.2.1 is not normative, but more a >>>>> report >>>>> of >>>>> what is done today in existing implementations. >>>> >>>> YEs, it is done today in existing WiFi implementations (not >>>> Ethernet). >>>> >>>>> Is there any different >>>>> there that is specific of 802.11-OCB? >>>> >>>> No, there is nothing different. >>>> >>>> I can change the text, but not sure what would be ok. >>>> >>>> Should I move section 4.2.1 in an Appendix? >>> >>> Not sure at this point. Let's think about that possibility. >>> >>>> >>>>> - All subsections 4.x seem informative, not normative. >>>> >>>> Similar to MTU, I could write in the 4.2 "Frame Format" that the >>>> EtherType MUST be 0x86DD (instead of just "is"). Would this make >>>> it >>>> more Normative? >>> >>> Yes, but it would anyway be exactly the same as with IPv6-over- >>> Ethernet. My concern is that there seem to be nothing really new of >>> IPv6-over-802.11-OCB compared to IPv6-over-Ethernet/IEEE 802.11. >> >> IPv6-over-Ethernet should not be conflated with IPv6-over- >> 802.11. They >> are not the same. There is an Adaptation Layer. The 802.11 field >> "Sequence number" exists in 802.11 but not in Ethernet. >> >> There is nothing new between IPv6-over-OCB and IPv6-over-80211. >> >> There is something IP new between IPv6-over-80211 and IPv6-over- >> Ethernet. >> >> There is no RFC for IPv6-over-80211. > > But nothing needed to be done for that, right? See above; if one wants to make IPv6-over-WiFi to work then one needs an RFC (as one has an RFC for IPv6-over-Etherent). That RFC tells that everything is the same as on Ethernet, except Fragmentation. IPv6-over-Ethernet has nothing about Fragmentation. YEt IPv6-over-WiFi does implement matters related to Fragmentation. You can check it yourself: set the MTU on the interface to 500 ('ifconfig mtu') and then ping 1000byte packets (ping -s 1000), you will see packet captures with Wireshark in monitor mode illustrative how Fragmentation at IP and MAC layer is performed. But, I agree with you, and we can also say that IPv6 works fine over 802.11 OCB and leave it there, no need of RFC. (the issue I have with this is that people say that if you want to use OCB then you must use BSM or CAM, because there is a standard for that BSM or CAM). > You might argue that the > effort going on in intarea and mboned/pim on multicast over IEEE 802.11 > might have something to do with this, but it is mostly about > optimizations, no mandatory things required to make IPv6 over 802.11 > work. If there are no mandatory things, then there is no RFC, right? > >> >> As a consequence, there is something new between IPv6-over-OCB and >> IPv6-over-Ethernet that deserves be agreed. > > I'm not arguing against that. Just saying that this was not completely > clear in the draft. We tried to explain it in section 1 "Introduction" and in section 4.2.1 "Ethernet Adaptation Layer". Maybe I need to add a statement that says that this Ethernet Adaptation Layer is not defined at IEEE? Alex > >> >>>> In section 4.3 "LL Addresses" I could put "it is RECOMMENDED" >>>> instead >>>> of >>>> "it is recommended". >>>> >>>> Sections 4.4. "Address Mapping" and 4.4.1 "Address Mapping -- >>>> Unicast" I >>>> could remove. >>>> >>>> Section 4.4.2 "Address Mapping - Multicast" could be removed. >>>> >>>> Section 4.5 "Stateless Autoconf" - I could write "the u/g bits >>>> MUST >>>> be >>>> opaque" instead of "are significant". >>>> >>>> Section 4.6 "Subnet Structure" - could be removed altogether. >>>> >>>> Are these ok with you? >>> >>> Yes. >>> >>>> >>>>> - The privacy part of section 5 is important, as it impacts the >>>>> operation of IPv6 over this type of networks, so I think this >>>>> deserves >>>>> more attention. >>>> >>>> Should I make a subsection called "Privacy Considerations" within >>>> the >>>> SEcurity considerations? >>> >>> That's an option, but what I'd like is to have a bit more text >>> about >>> privacy. >> >> I will ask my co-authors. >> >>>>> - In section, H.1, more details about how the captures were >>>>> obtained >>>>> should be provided (HW, SW, etc.). >>>> >>>> We added this if sounds ok: >>>>> The packet is captured on the Host. The Host is an IP- >>>>> OBU >>>>> containing an 802.11 interface in format PCI express >>>>> (an ITRI >>>>> product). The kernel runs the ath5k software driver >>>>> with >>>>> modifications for OCB mode. The capture tool is >>>>> Wireshark. >>>>> The file format for save and analyze is 'pcap'. The >>>>> packet is >>>>> generated by the Router. The Router is an IP-RSU (ITRI >>>>> product). >>> >>> OK, thanks. That's is fine. >> >> Ok, I am happy. > > Thanks a lot for all the efforts! > > Carlos > >> >> Alex >> >>> >>> Carlos >>> >>>>> Authors, please respond to my questions/comments and address >>>>> them >>>>> in a >>>>> new version of the document. >>>> >>>> We submitted a new version, but please reply to my comments so I >>>> fully >>>> address the comments. >>>> >>>> https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb- >>>> 13 >>>> >>>> Alex >>>> >>>> _______________________________________________ >>>> its mailing list >>>> its@ietf.org >>>> https://www.ietf.org/mailman/listinfo/its > From nobody Wed Feb 7 08:51:32 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 406D712D810 for ; Wed, 7 Feb 2018 08:51:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 brOfrZ8XD1ef for ; Wed, 7 Feb 2018 08:51:28 -0800 (PST) Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (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 3D4F912706D for ; Wed, 7 Feb 2018 08:51:27 -0800 (PST) Received: from resomta-po-11v.sys.comcast.net ([96.114.154.235]) by resqmta-po-03v.sys.comcast.net with ESMTP id jSuge5CWSdNHnjSwReq9W3; Wed, 07 Feb 2018 16:51:27 +0000 Received: from [172.22.228.216] ([162.210.130.3]) by resomta-po-11v.sys.comcast.net with SMTP id jSuHeM4dUHPexjSuKeZdGm; Wed, 07 Feb 2018 16:49:25 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Tony Li In-Reply-To: Date: Wed, 7 Feb 2018 08:49:13 -0800 Cc: cjbc@it.uc3m.es, its@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <70197994-ADE9-44E5-BE89-CC346775358E@tony.li> References: <1517217856.4315.32.camel@it.uc3m.es> <1518002798.4020.169.camel@it.uc3m.es> <1518011649.4020.186.camel@it.uc3m.es> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3445.5.20) X-CMAE-Envelope: MS4wfCsETFC8busFPrdyAh4JsH7g5obmRQRwZ3CwIXbvh/QLYZ4gkBEvj43c+cC4N/L3Z7tLEhPDtyWXWwOFHhaX5XsKUQkuKIz/WpY1rvYkygBLvCP4y6to xnPNMcIPVP6xQCqWJT8WAUKrTvrFZn+MPNXK8HONlOQkVXkUyIMZYUpm+0Q3BMMqoFHXQrgaUfIS3SX/cObGpB8A8nR9IPBPSiKfwQsMfGi3ocCH7l58CfRY Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 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, 07 Feb 2018 16:51:30 -0000 Hi all, Combined reply=E2=80=A6. >>>>>> - Section 1 lists two exceptions for 802.11-OCB compared to >>>>>> Ethernet. >>>>>> The first one is not different from regular 802.11, >>>>>=20 >>>>> I dont understand you. >>>>>=20 >>>>> The first one says that there are differences between IP-over- >>>>> WiFi >>>>> and >>>>> IP-over-Ethernet. These differences are in the headers. To >>>>> adapt >>>>> to >>>>> these differences an Ethernet Adaptation Layer is proposed. >>>>>=20 >>>>> Does this explain better? >>>>>=20 >>>>> Do I understand the worry correctly? >>>>=20 >>>> My point is that there is no difference from how IPv6 works over >>>> regular WiFi. >>>=20 >>> I agree, but there is no RFC for IPv6 over regular WiFi. >>>=20 >>> There is an IPv6-over-Ethernet, but not for IPv6-over-WiFi. >>>=20 >>> When run over WiFi, there is a need of Adaptation Layer. I think we=E2=80=99re somehow confusing 802.11-OCB with Wi-Fi. They are = not the same. The encapsulations are very different. The encapsulations permitted by IEEE for 802.11-OCB don=E2=80=99t allow = for traditional DIX encoding as we use for IP over Ethernet, so the = additional adaptation is useful so that the device driver can present = DIX encoded frames to the rest of the operating system and applications. = This is the primary point of this document and this Working Group. >>> This Adaptation Layer has direct impact on how fragmentation is >>> performed: the field "Sequence number" of the 802.11 Data header is >>> increased when the IP MTU is overcome. This behavior does not exist >>> in >>> Ethernet. >> But this does not affect the way IPv6 works, does it? This is = something >> taken care by the IEEE 802.11 data header, no? >=20 > At sending, the IP stack decides whether it fragments and then tells = the MAC layer to increase its seqno. At reception, vice-versa. >=20 > IPv6 Fragment Header also has an Identification field. >=20 > The two fields (Id field in IPv6 header and seqno in 802.11 MAC = header) are correlated. Please note that that=E2=80=99s your opinion.=20 One might also point out that fragmentation is just a bad idea to begin = with and should not ever happen. Therefore, what happens after you make = the mistake of fragmenting is irrelevant. :-) Tying the L2 header to the L3 fragmentation process is, IMHO, another = mistake. It increases complexity, is a layering violation, and things = would operate just fine even if we did nothing special. If and when L3 = decides to fragment, the resulting fragments are simply separate = packets. L2 doesn=E2=80=99t need to know that they have an L3 = relationship. >>>> The adaptation layer is not something IETF can do >>>> normative specs. >>>=20 >>> Excuse me Carlos, I dont understand this? There is this RFC4919 >>> section >>> 5 "LowPAN Adaptation Layer and Frame Format" of RFC 4919 "IPv6 over >>> 802.15.4". There are other Adaptation Layers defined in other RFCs >>> on >>> the Standards Track. >>>=20 >>> Or maybe I dont understand what do you mean by "the adaptation layer >>> is >>> not something IETF can do normative specs". >>>=20 >> But the adaptation layer you refer to in the ipwave draft is already >> defined by IEEE 802.11, right? >=20 > No, Ethernet Adaptation Layer is not defined anywhere. It is just = implemented. >=20 > Now it is defined in this ipwave Internet Draft. The IEEE defines a set of permissible encapsulations. They do not = mandate how IP should be encapsulated and there are, in fact, multiple = ways that we could transmit IP over 802.11-OCB. It is within the IETF=E2=80=99s purview and charter to specify how IP = over 802.11-OCB should be encapsulated. Specifying that is the purpose = of this Working Group and this document. > See above; if one wants to make IPv6-over-WiFi to work then one needs = an RFC (as one has an RFC for IPv6-over-Etherent). That RFC tells that = everything is the same as on Ethernet, except Fragmentation. We already have IPv6 fully functional over Wi-Fi (and let=E2=80=99s be = specific, I mean 802.11b,g,a,n,ac, =E2=80=A6. ). There=E2=80=99s a huge = installed base. That=E2=80=99s not changing. 802.11-OCB is a slightly different beast and it bears documenting how we = are doing the encapsulation on the wire and the adaptation that we will = do to present DIX encapsulation upwards. > If there are no mandatory things, then there is no RFC, right? There are many RFCs that are purely informational. > Maybe I need to add a statement that says that this Ethernet = Adaptation Layer is not defined at IEEE? That would seem to be a necessary clarification. Tony From nobody Wed Feb 7 14:14:26 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 723B6126CC4 for ; Wed, 7 Feb 2018 14:14:24 -0800 (PST) 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 LXYq-zvkXALh for ; Wed, 7 Feb 2018 14:14:21 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 970921205F0 for ; Wed, 7 Feb 2018 14:14:21 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id r71so5992210wmd.1 for ; Wed, 07 Feb 2018 14:14:21 -0800 (PST) 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:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=5CU0GkjblPtIc1RPx7CF8JtWsfuYR30kA74p3ZgcUOY=; b=QRRQ7FOapZID5ChjMTQMfiXPSYR3wWAT4Eqea9sB5rMSQGLYgLBhaG1plONiOc1LfZ BLqce6IavfBkLjVN6RcgOH/brW9wIFCqK5Z9i8Gc+jMWR9hB9R5xfOKmp0s2r1rg+REj uooT5lvFV3Hy0fb2o7OpQPutv1UAm1xjH8JoXDJ31gaynlA3LcXpPv1xQZZu0JKI3mBr oT+jWclVbZZviOiMDF7ZIfy68p8NNNhE4t7YUQy+hpTTPyxGgkq3oP3scgPVfl4VcCzU McJcIDB/5Xim4lAOsAn3VUllg47eouvJLbCnvfCH73YzkS8JVEPUg1gJqZ5RoDwiEWPR gLpA== 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 :in-reply-to:references:organization:mime-version :content-transfer-encoding; bh=5CU0GkjblPtIc1RPx7CF8JtWsfuYR30kA74p3ZgcUOY=; b=lpjYDW+vto+T+H5sn7XfTygU0fqUz3J7o30MMoT9SaoOf8fJ2S/j97NG5dc0+K7SKr /KMUWK1XxQLksRhRaa8mxm6ZajJgSczaJoN2ebHBHPvTjndQWUhO1UcYH1ijumSZRae0 S5WqOzbdrLhpFlGbJFHjTUwgCDiip3bQRX0Z82YlUBk6U9KlABfumBdWKBNlj3bf3Z5j sIZzLoWpZ+EBcgRX9pdFXrQZASJ9NB6vr6+H5LQase5ltB0hoql6uF0fGluWq0Ak7vBh AGpM5g0/7Crco7i77CFsO7lkAXeRUcdrIlu0M4g73ifHC6RuVafy45ufaaH82XKhSlPg lziw== X-Gm-Message-State: APf1xPDCyovbKQjsIpTRvoBWUqwZ0dc8GXEk54iOrWIVJZ3yVdAOFIH6 /zEPnP/Sb8L1r7th92+mFSPg+A== X-Google-Smtp-Source: AH8x226jhAI0WDqz+aUw3Apgn0sjXnltec3YsNEN5dMsmqgxdExw5tNEKOn6I97NmNsKO+3Lkb5KdQ== X-Received: by 10.28.146.141 with SMTP id u135mr5836596wmd.26.1518041659723; Wed, 07 Feb 2018 14:14:19 -0800 (PST) Received: from acorde ([148.3.108.67]) by smtp.gmail.com with ESMTPSA id d17sm1834461wre.76.2018.02.07.14.14.18 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 07 Feb 2018 14:14:19 -0800 (PST) Message-ID: <1518041657.6291.27.camel@it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano Reply-To: cjbc@it.uc3m.es To: Tony Li , Alexandre Petrescu Cc: its@ietf.org Date: Wed, 07 Feb 2018 23:14:17 +0100 In-Reply-To: <70197994-ADE9-44E5-BE89-CC346775358E@tony.li> References: <1517217856.4315.32.camel@it.uc3m.es> <1518002798.4020.169.camel@it.uc3m.es> <1518011649.4020.186.camel@it.uc3m.es> <70197994-ADE9-44E5-BE89-CC346775358E@tony.li> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.3-1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 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, 07 Feb 2018 22:14:24 -0000 Hi Tony, Trying to close this thread. I mostly concur with what Tony has said in this e-mail. Alex: I (wrongly) assumed that the adaptation layer for IPv6 over IEEE 802.11 was actually specified outside IETF. In any case, my point was more on that there is nothing that needs to be specified there (IPv6 over IEEE 802.11 works), and that we have to focus in draft-ietf- ipwave-ipv6-over-80211ocb on what is new that is needed. Sorry if I created more confusion. Then, to summarize on the key points (that I believe remains): - Let's make use of normative text for the what the document actually specifies. - If the document only includes recommendations, then we can evaluate making it Informational or BCP. Thanks, Carlos On Wed, 2018-02-07 at 08:49 -0800, Tony Li wrote: > Hi all, > > Combined reply…. > > > > > > > > - Section 1 lists two exceptions for 802.11-OCB compared > > > > > > > to > > > > > > > Ethernet. > > > > > > > The first one is not different from regular 802.11, > > > > > > > > > > > > I dont understand you. > > > > > > > > > > > > The first one says that there are differences between IP- > > > > > > over- > > > > > > WiFi > > > > > > and > > > > > > IP-over-Ethernet. These differences are in the > > > > > > headers. To > > > > > > adapt > > > > > > to > > > > > > these differences an Ethernet Adaptation Layer is proposed. > > > > > > > > > > > > Does this explain better? > > > > > > > > > > > > Do I understand the worry correctly? > > > > > > > > > > My point is that there is no difference from how IPv6 works > > > > > over > > > > > regular WiFi. > > > > > > > > I agree, but there is no RFC for IPv6 over regular WiFi. > > > > > > > > There is an IPv6-over-Ethernet, but not for IPv6-over-WiFi. > > > > > > > > When run over WiFi, there is a need of Adaptation Layer. > > > > I think we’re somehow confusing 802.11-OCB with Wi-Fi. They are not > the same. The encapsulations are very different. > > The encapsulations permitted by IEEE for 802.11-OCB don’t allow for > traditional DIX encoding as we use for IP over Ethernet, so the > additional adaptation is useful so that the device driver can present > DIX encoded frames to the rest of the operating system and > applications. This is the primary point of this document and this > Working Group. > > > > > > This Adaptation Layer has direct impact on how fragmentation is > > > > performed: the field "Sequence number" of the 802.11 Data > > > > header is > > > > increased when the IP MTU is overcome. This behavior does not > > > > exist > > > > in > > > > Ethernet. > > > > > > But this does not affect the way IPv6 works, does it? This is > > > something > > > taken care by the IEEE 802.11 data header, no? > > > > At sending, the IP stack decides whether it fragments and then > > tells the MAC layer to increase its seqno. At reception, vice- > > versa. > > > > IPv6 Fragment Header also has an Identification field. > > > > The two fields (Id field in IPv6 header and seqno in 802.11 MAC > > header) are correlated. > > > Please note that that’s your opinion. > > One might also point out that fragmentation is just a bad idea to > begin with and should not ever happen. Therefore, what happens after > you make the mistake of fragmenting is irrelevant. :-) > > Tying the L2 header to the L3 fragmentation process is, IMHO, another > mistake. It increases complexity, is a layering violation, and things > would operate just fine even if we did nothing special. If and when > L3 decides to fragment, the resulting fragments are simply separate > packets. L2 doesn’t need to know that they have an L3 relationship. > > > > > > > The adaptation layer is not something IETF can do > > > > > normative specs. > > > > > > > > Excuse me Carlos, I dont understand this? There is this > > > > RFC4919 > > > > section > > > > 5 "LowPAN Adaptation Layer and Frame Format" of RFC 4919 "IPv6 > > > > over > > > > 802.15.4". There are other Adaptation Layers defined in other > > > > RFCs > > > > on > > > > the Standards Track. > > > > > > > > Or maybe I dont understand what do you mean by "the adaptation > > > > layer > > > > is > > > > not something IETF can do normative specs". > > > > > > > > > > But the adaptation layer you refer to in the ipwave draft is > > > already > > > defined by IEEE 802.11, right? > > > > No, Ethernet Adaptation Layer is not defined anywhere. It is just > > implemented. > > > > Now it is defined in this ipwave Internet Draft. > > > The IEEE defines a set of permissible encapsulations. They do not > mandate how IP should be encapsulated and there are, in fact, > multiple ways that we could transmit IP over 802.11-OCB. > > It is within the IETF’s purview and charter to specify how IP over > 802.11-OCB should be encapsulated. Specifying that is the purpose of > this Working Group and this document. > > > > See above; if one wants to make IPv6-over-WiFi to work then one > > needs an RFC (as one has an RFC for IPv6-over-Etherent). That RFC > > tells that everything is the same as on Ethernet, except > > Fragmentation. > > > We already have IPv6 fully functional over Wi-Fi (and let’s be > specific, I mean 802.11b,g,a,n,ac, …. ). There’s a huge installed > base. That’s not changing. > > 802.11-OCB is a slightly different beast and it bears documenting how > we are doing the encapsulation on the wire and the adaptation that we > will do to present DIX encapsulation upwards. > > > > If there are no mandatory things, then there is no RFC, right? > > > There are many RFCs that are purely informational. > > > > Maybe I need to add a statement that says that this Ethernet > > Adaptation Layer is not defined at IEEE? > > > That would seem to be a necessary clarification. > > Tony > From nobody Wed Feb 7 15:28:26 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F986126CD6 for ; Wed, 7 Feb 2018 15:28:25 -0800 (PST) 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 qU013_KSI7Sd for ; Wed, 7 Feb 2018 15:28:23 -0800 (PST) Received: from resqmta-po-01v.sys.comcast.net (resqmta-po-01v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:160]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C149126C83 for ; Wed, 7 Feb 2018 15:28:23 -0800 (PST) Received: from resomta-po-14v.sys.comcast.net ([96.114.154.238]) by resqmta-po-01v.sys.comcast.net with ESMTP id jZ8EeNhuZKqinjZ8Ze9WaN; Wed, 07 Feb 2018 23:28:23 +0000 Received: from [172.22.228.216] ([162.210.130.3]) by resomta-po-14v.sys.comcast.net with SMTP id jZ6PecbpVn7MwjZ6SeKxRr; Wed, 07 Feb 2018 23:26:21 +0000 From: tony.li@tony.li Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_05E752F2-7110-4ED2-B483-2764B77FC262" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 7 Feb 2018 15:26:08 -0800 In-Reply-To: <1518041657.6291.27.camel@it.uc3m.es> Cc: Alexandre Petrescu , its@ietf.org To: =?utf-8?Q?Carlos_Jes=C3=BAs_Bernardos_Cano?= References: <1517217856.4315.32.camel@it.uc3m.es> <1518002798.4020.169.camel@it.uc3m.es> <1518011649.4020.186.camel@it.uc3m.es> <70197994-ADE9-44E5-BE89-CC346775358E@tony.li> <1518041657.6291.27.camel@it.uc3m.es> X-Mailer: Apple Mail (2.3445.5.20) X-CMAE-Envelope: MS4wfK5Uwjx6UkxL4IzLyDEHi9sCcdWoAHLax/pGM/glyBHF5GX5F8O7cGvsZwNIOhsvNztBYpU06o1O9PB1NAKI8s0+UmEfgtg+z3yyJU0X51/HNeUhEOf4 uX8D+hXBeAdu8OZRT4IXWmruhHYmUch0M0tqj16L0TPb5N+xYHmG/8sUjwbUS6qKBmEr0X+c//ldJM7T1cUrKr02wY2OQFepFMdngBqtpRXDTDlhNERp9KZs Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 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, 07 Feb 2018 23:28:25 -0000 --Apple-Mail=_05E752F2-7110-4ED2-B483-2764B77FC262 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > - Let's make use of normative text for the what the document actually > specifies. >=20 > - If the document only includes recommendations, then we can evaluate > making it Informational or BCP. This document MUST specify the encapsulation and MTU for 802.11-OCB and = it MUST be normative. Apologies if this seems like shouting, I=E2=80=99m just complying with = 2119. ;-) Tony --Apple-Mail=_05E752F2-7110-4ED2-B483-2764B77FC262 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

- Let's make use of normative text for the what the document = actually
specifies.

- If the document only includes recommendations, = then we can evaluate
making it Informational or = BCP.


This document MUST specify the = encapsulation and MTU for 802.11-OCB and it MUST be normative.

Apologies if this seems = like shouting, I=E2=80=99m just complying with 2119. ;-)

Tony

= --Apple-Mail=_05E752F2-7110-4ED2-B483-2764B77FC262-- From nobody Sun Feb 11 08:53:00 2018 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 31D171201F2; Sun, 11 Feb 2018 08:52:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: its@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151836797309.17069.411060006886846041@ietfa.amsl.com> Date: Sun, 11 Feb 2018 08:52:53 -0800 Archived-At: Subject: [ipwave] I-D Action: draft-ietf-ipwave-ipv6-over-80211ocb-14.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, 11 Feb 2018 16:52:53 -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 Jerome Haerri Jong-Hyouk Lee Thierry Ernst Filename : draft-ietf-ipwave-ipv6-over-80211ocb-14.txt Pages : 39 Date : 2018-02-11 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. 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-14 https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-14 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 Feb 11 09:01:31 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 001791243F3 for ; Sun, 11 Feb 2018 09:01:28 -0800 (PST) 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 hahJ5c8PHmug for ; Sun, 11 Feb 2018 09:01:26 -0800 (PST) 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 470FD1201F2 for ; Sun, 11 Feb 2018 09:01:26 -0800 (PST) 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 w1BH1Oje002133; Sun, 11 Feb 2018 18:01:24 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5EEF2200FD4; Sun, 11 Feb 2018 18:01:24 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 4F274200CF2; Sun, 11 Feb 2018 18:01:24 +0100 (CET) Received: from [132.166.84.55] ([132.166.84.55]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w1BH1NGt015731; Sun, 11 Feb 2018 18:01:23 +0100 To: cjbc@it.uc3m.es, Tony Li Cc: its@ietf.org References: <1517217856.4315.32.camel@it.uc3m.es> <1518002798.4020.169.camel@it.uc3m.es> <1518011649.4020.186.camel@it.uc3m.es> <70197994-ADE9-44E5-BE89-CC346775358E@tony.li> <1518041657.6291.27.camel@it.uc3m.es> From: Alexandre Petrescu Message-ID: <5bf5a935-2c30-e8d2-d747-6677f5397db7@gmail.com> Date: Sun, 11 Feb 2018 18:01:20 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <1518041657.6291.27.camel@it.uc3m.es> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 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, 11 Feb 2018 17:01:29 -0000 Le 07/02/2018 à 23:14, Carlos Jesús Bernardos Cano a écrit : > Hi Tony, > > Trying to close this thread. > > I mostly concur with what Tony has said in this e-mail. I replied to his message at the end of this email. > > Alex: I (wrongly) assumed that the adaptation layer for IPv6 over IEEE > 802.11 was actually specified outside IETF. In any case, my point was > more on that there is nothing that needs to be specified there (IPv6 > over IEEE 802.11 works), and that we have to focus in draft-ietf- > ipwave-ipv6-over-80211ocb on what is new that is needed. Sorry if I > created more confusion. > > Then, to summarize on the key points (that I believe remains): > > - Let's make use of normative text for the what the document actually > specifies. Right now there is this MUST for MTU. There is more relatively normative text in section 4.5 "Stateless Autoconfiguration". This recommends the use of RFC7136 (ug bits) and RFC 8064 (stable ids) and RFC 7217 (opaque ids). These recommendations dont exist in RFC2464 (IPv6-over-Ethernet) and they dont exist in any IPv6-over-WiFi document because such IPv6-over-WiFi does not exist. I hope this qualifies as 'specification'. > - If the document only includes recommendations, then we can evaluate > making it Informational or BCP. Hm, I thought IPv6-over-foo documents are never Info or BCP. But yes, let us evaluate. > > Thanks, > > Carlos > > On Wed, 2018-02-07 at 08:49 -0800, Tony Li wrote: >> Hi all, >> >> Combined reply…. >> >>>>>>>> - Section 1 lists two exceptions for 802.11-OCB compared >>>>>>>> to >>>>>>>> Ethernet. >>>>>>>> The first one is not different from regular 802.11, >>>>>>> >>>>>>> I dont understand you. >>>>>>> >>>>>>> The first one says that there are differences between IP- >>>>>>> over- >>>>>>> WiFi >>>>>>> and >>>>>>> IP-over-Ethernet. These differences are in the >>>>>>> headers. To >>>>>>> adapt >>>>>>> to >>>>>>> these differences an Ethernet Adaptation Layer is proposed. >>>>>>> >>>>>>> Does this explain better? >>>>>>> >>>>>>> Do I understand the worry correctly? >>>>>> >>>>>> My point is that there is no difference from how IPv6 works >>>>>> over >>>>>> regular WiFi. >>>>> >>>>> I agree, but there is no RFC for IPv6 over regular WiFi. >>>>> >>>>> There is an IPv6-over-Ethernet, but not for IPv6-over-WiFi. >>>>> >>>>> When run over WiFi, there is a need of Adaptation Layer. >> >> >> >> I think we’re somehow confusing 802.11-OCB with Wi-Fi. They are not >> the same. The encapsulations are very different. >> >> The encapsulations permitted by IEEE for 802.11-OCB don’t allow for >> traditional DIX encoding as we use for IP over Ethernet, so the >> additional adaptation is useful so that the device driver can present >> DIX encoded frames to the rest of the operating system and >> applications. This is the primary point of this document and this >> Working Group. >> >> >>>>> This Adaptation Layer has direct impact on how fragmentation is >>>>> performed: the field "Sequence number" of the 802.11 Data >>>>> header is >>>>> increased when the IP MTU is overcome. This behavior does not >>>>> exist >>>>> in >>>>> Ethernet. >>>> >>>> But this does not affect the way IPv6 works, does it? This is >>>> something >>>> taken care by the IEEE 802.11 data header, no? >>> >>> At sending, the IP stack decides whether it fragments and then >>> tells the MAC layer to increase its seqno. At reception, vice- >>> versa. >>> >>> IPv6 Fragment Header also has an Identification field. >>> >>> The two fields (Id field in IPv6 header and seqno in 802.11 MAC >>> header) are correlated. >> >> >> Please note that that’s your opinion. >> >> One might also point out that fragmentation is just a bad idea to >> begin with and should not ever happen. Therefore, what happens after >> you make the mistake of fragmenting is irrelevant. :-) >> >> Tying the L2 header to the L3 fragmentation process is, IMHO, another >> mistake. It increases complexity, is a layering violation, and things >> would operate just fine even if we did nothing special. If and when >> L3 decides to fragment, the resulting fragments are simply separate >> packets. L2 doesn’t need to know that they have an L3 relationship. >> >> >>>>>> The adaptation layer is not something IETF can do >>>>>> normative specs. >>>>> >>>>> Excuse me Carlos, I dont understand this? There is this >>>>> RFC4919 >>>>> section >>>>> 5 "LowPAN Adaptation Layer and Frame Format" of RFC 4919 "IPv6 >>>>> over >>>>> 802.15.4". There are other Adaptation Layers defined in other >>>>> RFCs >>>>> on >>>>> the Standards Track. >>>>> >>>>> Or maybe I dont understand what do you mean by "the adaptation >>>>> layer >>>>> is >>>>> not something IETF can do normative specs". >>>>> >>>> >>>> But the adaptation layer you refer to in the ipwave draft is >>>> already >>>> defined by IEEE 802.11, right? >>> >>> No, Ethernet Adaptation Layer is not defined anywhere. It is just >>> implemented. >>> >>> Now it is defined in this ipwave Internet Draft. >> >> >> The IEEE defines a set of permissible encapsulations. They do not >> mandate how IP should be encapsulated and there are, in fact, >> multiple ways that we could transmit IP over 802.11-OCB. >> >> It is within the IETF’s purview and charter to specify how IP over >> 802.11-OCB should be encapsulated. Specifying that is the purpose of >> this Working Group and this document. >> >> >>> See above; if one wants to make IPv6-over-WiFi to work then one >>> needs an RFC (as one has an RFC for IPv6-over-Etherent). That RFC >>> tells that everything is the same as on Ethernet, except >>> Fragmentation. >> >> >> We already have IPv6 fully functional over Wi-Fi (and let’s be >> specific, I mean 802.11b,g,a,n,ac, …. ). There’s a huge installed >> base. That’s not changing. >> >> 802.11-OCB is a slightly different beast and it bears documenting how >> we are doing the encapsulation on the wire and the adaptation that we >> will do to present DIX encapsulation upwards. >> >> >>> If there are no mandatory things, then there is no RFC, right? >> >> >> There are many RFCs that are purely informational. >> >> >>> Maybe I need to add a statement that says that this Ethernet >>> Adaptation Layer is not defined at IEEE? >> >> >> That would seem to be a necessary clarification. I have tried to clarify it, but it seems difficult to write for me. Maybe those who state that the WiFi-to-Ethernet Adaptation Layer is defined at IEEE should provide a reference. (and I do not know what is DIX, never encountered it). Alex >> >> Tony >> > From nobody Sun Feb 11 09:03:13 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6BDB1243F3 for ; Sun, 11 Feb 2018 09:03:11 -0800 (PST) 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 Qc2I1B1_W6Vq for ; Sun, 11 Feb 2018 09:03:09 -0800 (PST) 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 5D1301201F2 for ; Sun, 11 Feb 2018 09:03:09 -0800 (PST) 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 w1BH378A013840 for ; Sun, 11 Feb 2018 18:03:07 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B1833200F9A for ; Sun, 11 Feb 2018 18:03:07 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A6070200C18 for ; Sun, 11 Feb 2018 18:03:07 +0100 (CET) Received: from [132.166.84.55] ([132.166.84.55]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w1BH361L016895 for ; Sun, 11 Feb 2018 18:03:07 +0100 References: <151836797341.17069.3562978982936866945.idtracker@ietfa.amsl.com> To: "its@ietf.org" From: Alexandre Petrescu X-Forwarded-Message-Id: <151836797341.17069.3562978982936866945.idtracker@ietfa.amsl.com> Message-ID: <3279a5f1-701c-c59e-6476-25f8b138f759@gmail.com> Date: Sun, 11 Feb 2018 18:03:06 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <151836797341.17069.3562978982936866945.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------F27C074489215A6540FFEACC" Content-Language: fr Archived-At: Subject: [ipwave] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-14.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, 11 Feb 2018 17:03:12 -0000 This is a multi-part message in MIME format. --------------F27C074489215A6540FFEACC Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi IPWAVErs, Following recent discussion I submitted a new draft that addresses raised comments. This is the changelog: o Created a new Appendix titled "Extra Terminology" that contains terms DSRC, DSRCS, OBU, RSU as defined outside IETF. Some of them are used in the main Terminology section. o Added two paragraphs explaining that ND and Mobile IPv6 have problems working over 802.11 OCB, yet their adaptations is not specified in this document. Alex -------- Message transféré -------- Sujet : New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-14.txt Date : Sun, 11 Feb 2018 08:52:53 -0800 De : internet-drafts@ietf.org Pour : Jerome Haerri , ipwave-chairs@ietf.org, Jerome Haerri , Alexandre Petrescu , Alexandre Petrescu , Nabil Benamar , Thierry Ernst , Jong-Hyouk Lee A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-14.txt has been successfully submitted by Alexandre Petrescu and posted to the IETF repository. Name: draft-ietf-ipwave-ipv6-over-80211ocb Revision: 14 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: 2018-02-11 Group: ipwave Pages: 39 URL: https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-14.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-14 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-14 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-14 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. 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 --------------F27C074489215A6540FFEACC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi IPWAVErs,

Following recent discussion I submitted a new draft that addresses raised comments.

This is the changelog:

   o  Created a new Appendix titled "Extra Terminology" that contains
      terms DSRC, DSRCS, OBU, RSU as defined outside IETF.  Some of them
      are used in the main Terminology section.

   o  Added two paragraphs explaining that ND and Mobile IPv6 have
      problems working over 802.11 OCB, yet their adaptations is not
      specified in this document.

Alex


-------- Message transféré --------
Sujet : New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-14.txt
Date : Sun, 11 Feb 2018 08:52:53 -0800
De : internet-drafts@ietf.org
Pour : Jerome Haerri <Jerome.Haerri@eurecom.fr>, ipwave-chairs@ietf.org, Jerome Haerri <jerome.haerri@eurecom.fr>, Alexandre Petrescu <Alexandre.Petrescu@cea.fr>, Alexandre Petrescu <alexandre.petrescu@cea.fr>, Nabil Benamar <n.benamar@est.umi.ac.ma>, Thierry Ernst <thierry.ernst@yogoko.fr>, Jong-Hyouk Lee <jonghyouk@smu.ac.kr> 


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

Name:		draft-ietf-ipwave-ipv6-over-80211ocb
Revision:	14
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:	2018-02-11
Group:		ipwave
Pages:		39
URL:            https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-14.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-14
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-14
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-14

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.

                                                                                  


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
--------------F27C074489215A6540FFEACC-- From nobody Sun Feb 11 14:18:15 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 941AC126C25 for ; Sun, 11 Feb 2018 14:18:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 zEoh3r5uIBbq for ; Sun, 11 Feb 2018 14:18:12 -0800 (PST) Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::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 233131200B9 for ; Sun, 11 Feb 2018 14:18:11 -0800 (PST) Received: by mail-ot0-x22b.google.com with SMTP id m20so12393221otf.3 for ; Sun, 11 Feb 2018 14:18:11 -0800 (PST) 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=uNv1ZsRv2LQfNgNBShYN6zlR36sGsMVDXxuhwZZcgOk=; b=oGglX9ADFFJ8EgBMmbUrMTg8i8p8BAOTDFOOU/3V3qeJ1qLGZ6qS5PrFpmrCzKbWoP +RncbY+HDGvm6QtO4nwNXnVmSvBF8itskMFM4ngHJs2+JI3X8OhUOlSy3vaexpWIysjY 6N42WKsMn8hzPal5bKar3qvKaqUNKprU7z4c4Hx6gbyypnhRLdGBoQd0TEHWMh9oP2DX Cb9BNqAzDZmJm5CThatPvUYqRLNWcbUTsQTLMkA4Hh7UVhlH2FsmTznXtUhur7UnX7C1 CE9XqMoR209htbgZuQWNzk9IZv5X1UG7N4F3h6BYtj5+Q/W5zOcEngsQ8tmA3qKUZnxc pnKQ== 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=uNv1ZsRv2LQfNgNBShYN6zlR36sGsMVDXxuhwZZcgOk=; b=NaYfVh1nHFRnfndZXqlp8/tU/jbOofpBy2U4x83m/QrasR+Vayonz/IhHcVAHTnp22 iS2h8j69y+LiHD+iugQH7IyjH9tojT52RWH96o0ckLA5eOXM50I3a+Jj+lVwGIjFNPHF ezIgCAsFhxdkCUGNCFYnpn3KArcARw8OTqsLiCpmCYNVKRe3efe2icfnAssj48cmMKze 4ApTyJB9eWyepv3ObP8aH9971jy2JyQ58zMMD/j9aYzFEIAPoJU90vYA9hWA6pCx9z5E eOU8N93SAljkKDcrC3YC1gjKxoz1RKFV0dmX72QtnbTL6fKX9UbrQUrDDCpj4/bBf4Yk jHxg== X-Gm-Message-State: APf1xPBlr0KKHTXv8DF62DSC57tLgEdAM/HpKT3xx4dztQ+Zee23WMtc +rYEX7K5kULJdv8VexwMP0ph0y1qGM8XlioYMbs= X-Google-Smtp-Source: AH8x224JYPrEZ7FBDYvXOqUlcqznJu9bIckxD2rZYfW3IDrU5izbxUTU2bq8Ow4DqKlREw19N85KsU1pHdZN4i/Y1PA= X-Received: by 10.157.24.28 with SMTP id b28mr7758057ote.356.1518387491419; Sun, 11 Feb 2018 14:18:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.9.153 with HTTP; Sun, 11 Feb 2018 14:18:10 -0800 (PST) In-Reply-To: <5bf5a935-2c30-e8d2-d747-6677f5397db7@gmail.com> References: <1517217856.4315.32.camel@it.uc3m.es> <1518002798.4020.169.camel@it.uc3m.es> <1518011649.4020.186.camel@it.uc3m.es> <70197994-ADE9-44E5-BE89-CC346775358E@tony.li> <1518041657.6291.27.camel@it.uc3m.es> <5bf5a935-2c30-e8d2-d747-6677f5397db7@gmail.com> From: Abdussalam Baryun Date: Mon, 12 Feb 2018 00:18:10 +0200 Message-ID: To: Alexandre Petrescu Cc: its Content-Type: multipart/alternative; boundary="001a113dc9840ebc7d0564f72398" Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 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, 11 Feb 2018 22:18:13 -0000 --001a113dc9840ebc7d0564f72398 Content-Type: text/plain; charset="UTF-8" On Sun, Feb 11, 2018 at 7:01 PM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > > > [.......] > > Maybe I need to add a statement that says that this Ethernet >>>> Adaptation Layer is not defined at IEEE? >>>> >>> >>> >>> That would seem to be a necessary clarification. >>> >> > I have tried to clarify it, but it seems difficult to write for me. > > Maybe those who state that the WiFi-to-Ethernet Adaptation Layer is > defined at IEEE should provide a reference. > > (and I do not know what is DIX, never encountered it). > I was not with this transmission over Ethernet-layer from the first time I seen it [1], but some replies were against, and the authors/WG wanted that. I suggested we needed an adaptation for ipwave, but the wg say no we cannot defined under ip which I don't believe. So IMO the majority-wg/authors can find a reference. AB [1] http://www.ietf.org/mail-archive/web/its/current/msg01889.html --001a113dc9840ebc7d0564f72398 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Feb 11, 2018 at 7:01 PM, Alexandre Petrescu &= lt;alexan= dre.petrescu@gmail.com> wrote:


[.......]

Maybe I need to add a statement that says that this Ethernet
Adaptation Layer is not defined at IEEE?


That would seem to be a necessary clarification.

I have tried to clarify it, but it seems difficult to write for me.

Maybe those who state that the WiFi-to-Ethernet Adaptation Layer is defined= at IEEE should provide a reference.

(and I do not know what is DIX, never encountered it).

I was not with this transmission over Ethernet-layer from t= he first time I seen it [1], but some replies were against, and the authors= /WG wanted that. I suggested we needed an adaptation for ipwave, but the wg= say no we cannot defined under ip which I don't believe. So IMO the ma= jority-wg/authors can find a reference.

AB


--001a113dc9840ebc7d0564f72398-- From nobody Sun Feb 11 15:40:57 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E58A126DFF for ; Sun, 11 Feb 2018 15:40:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 YTWIRIuUwpBO for ; Sun, 11 Feb 2018 15:40:54 -0800 (PST) Received: from resqmta-po-11v.sys.comcast.net (resqmta-po-11v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06F90126D3F for ; Sun, 11 Feb 2018 15:40:53 -0800 (PST) Received: from resomta-po-05v.sys.comcast.net ([96.114.154.229]) by resqmta-po-11v.sys.comcast.net with ESMTP id l1EkePihwcWJzl1Eqep3s5; Sun, 11 Feb 2018 23:40:52 +0000 Received: from [192.168.1.6] ([24.130.209.5]) by resomta-po-05v.sys.comcast.net with SMTP id l1EpevFohe9iKl1EpeDkbQ; Sun, 11 Feb 2018 23:40:52 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: tony.li@tony.li In-Reply-To: <5bf5a935-2c30-e8d2-d747-6677f5397db7@gmail.com> Date: Sun, 11 Feb 2018 15:40:50 -0800 Cc: =?utf-8?Q?Carlos_Jes=C3=BAs_Bernardos_Cano?= , its@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <7766D386-7EC7-483C-8C3C-8EF39D55FA4D@tony.li> References: <1517217856.4315.32.camel@it.uc3m.es> <1518002798.4020.169.camel@it.uc3m.es> <1518011649.4020.186.camel@it.uc3m.es> <70197994-ADE9-44E5-BE89-CC346775358E@tony.li> <1518041657.6291.27.camel@it.uc3m.es> <5bf5a935-2c30-e8d2-d747-6677f5397db7@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3445.5.20) X-CMAE-Envelope: MS4wfNxoDDPcv6bbIzMqQMv1ngIOiQ891KKRXRADTxg7tGNr/Vaj9nlbm0A/jZ/hpvTI2d6tX7xBL2VsYxhQgOaDYbCHbf/1HaUVI7G7TgqOFarRXQldamir +b7ftqTu/LXZvx3ADpJjj3QTLIM9aaHwPUCp241m3g+s33y3FUF69BrRswl7GxRk/Jwi3dR860KC1Cx1WjPrewmnE3u8eMoSEd3iiht4UO2kcb4o+1Zshdpa Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 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, 11 Feb 2018 23:40:55 -0000 > There is more relatively normative text in section 4.5 "Stateless = Autoconfiguration". This recommends the use of RFC7136 (ug bits) and = RFC 8064 (stable ids) and RFC 7217 (opaque ids). These recommendations = dont exist in RFC2464 (IPv6-over-Ethernet) and they dont exist in any = IPv6-over-WiFi document because such IPv6-over-WiFi does not exist. >=20 > I hope this qualifies as 'specification=E2=80=99. It qualifies as a recommendation for right now. If you want it to be = mandatory, you need to specifically use RFC 2119 terminology. > (and I do not know what is DIX, never encountered it). DIX is another name for Ethertype encapsulation. AFAIK, it has never = been ratified by the IEEE. Tony From nobody Mon Feb 12 04:23:49 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29DB6124D68 for ; Mon, 12 Feb 2018 04:23:48 -0800 (PST) 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 86kcPsnBiMQX for ; Mon, 12 Feb 2018 04:23:46 -0800 (PST) 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 9DF051204DA for ; Mon, 12 Feb 2018 04:23:46 -0800 (PST) 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 w1CCNiPe040875; Mon, 12 Feb 2018 13:23:44 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2D19A208641; Mon, 12 Feb 2018 11:49:37 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 1E00C20308A; Mon, 12 Feb 2018 11:49:37 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w1CAnaCh005291; Mon, 12 Feb 2018 11:49:37 +0100 To: Abdussalam Baryun Cc: its , mrcullen42@gmail.com References: <1506192164.12227.3.camel@it.uc3m.es> <390b03ec-27a6-43e3-3ea1-95715d253980@gmail.com> From: Alexandre Petrescu Message-ID: <97975302-2ab4-d9b9-d825-758bf2371dff@gmail.com> Date: Mon, 12 Feb 2018 11:49:36 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.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] 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: Mon, 12 Feb 2018 12:23:48 -0000 Abdussalam, Let me reply now after a few months. Le 05/10/2017 à 05:55, Abdussalam Baryun a écrit : > Hi Alex, > > I thank the authors for their hard work and hope we can work together > to make the doc best. I don't think it is ready for submission. I am > still reviewing but I give now some comments. > > Ethernet is defined by IEEE as IEEE802.3. I think yes, in principle; Additionally, I am not sure but it may be that "Ethernet" is a label for 802.3 like "WiFi" is for 802.11. > However, I think the document should not mention IEEE802.11 protocol > (some name WiFi) as similar protocol like IEEE802.3 ( Ethernet) > protocol, one is wireless protocol and the other is wired. I agree. I dont think this ipwave document mentions that 802.11 is similar like 802.3. Can you point me where you think it does so? > The transmissions are different, I don't see that they are similar > even their frames are not similar. So it is not correct in section > 5.2 mentioned that: > > IP packets are transmitted over 802.11-OCB as standard Ethernet > > packets. Well, IP packets _are_ transmitted as standard Ethernet packets, with an Adaptation Layer. The next phrase says so. > IMO even the document RFC2464, should have been (more technical > focus) referencing the protocol IEEE802.3, instead of naming that may > change by time. I agree. There is an ongoing work on RFC2464bis (draft-hinden something), that could be improved with this comment. Alex [...] From nobody Mon Feb 12 09:08:44 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAAE012D866 for ; Mon, 12 Feb 2018 09:08:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGm_2DhDMa61 for ; Mon, 12 Feb 2018 09:08:41 -0800 (PST) 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 1AD9C126DC2 for ; Mon, 12 Feb 2018 09:08:40 -0800 (PST) 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 w1CH4m3X145955; Mon, 12 Feb 2018 18:08:37 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 25A0420882D; Mon, 12 Feb 2018 11:59:50 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 1836A208825; Mon, 12 Feb 2018 11:59:50 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w1CAxnb9010311; Mon, 12 Feb 2018 11:59:49 +0100 To: Abdussalam Baryun Cc: its References: <1517217856.4315.32.camel@it.uc3m.es> <1518002798.4020.169.camel@it.uc3m.es> <1518011649.4020.186.camel@it.uc3m.es> <70197994-ADE9-44E5-BE89-CC346775358E@tony.li> <1518041657.6291.27.camel@it.uc3m.es> <5bf5a935-2c30-e8d2-d747-6677f5397db7@gmail.com> From: Alexandre Petrescu Message-ID: Date: Mon, 12 Feb 2018 11:59:49 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.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] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 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, 12 Feb 2018 17:08:43 -0000 Le 11/02/2018 à 23:18, Abdussalam Baryun a écrit : > > > On Sun, Feb 11, 2018 at 7:01 PM, Alexandre Petrescu > > wrote: > > > > [.......] > > Maybe I need to add a statement that says that this Ethernet > Adaptation Layer is not defined at IEEE? > > > > That would seem to be a necessary clarification. > > > I have tried to clarify it, but it seems difficult to write for me. > > Maybe those who state that the WiFi-to-Ethernet Adaptation Layer is > defined at IEEE should provide a reference. > > (and I do not know what is DIX, never encountered it). > > > I was not with this transmission over Ethernet-layer from the first time > I seen it [1], but some replies were against, and the authors/WG wanted > that. I suggested we needed an adaptation for ipwave, but the wg say no > we cannot defined under ip which I don't believe. So IMO the > majority-wg/authors can find a reference. I have tried to find a reference to an IEEE document that describes an "Ethernet Adaptation Layer". I have not found it. 1. I do have some access to some IEEE documents, but not all. 2. The name "802.11-to-Ethernet Adaptation Layer", and "Ethernet Adaptation Layer" is a name I came up with. It is derived from "WiFi-to-Ethernet" and from "Adaptation Layer". The term "Adaptation Layer" is used by other IPv6-over-foo documents at IETF. This "Ethernet Adaptation Layer" does what section 4.2.1 specifies it to do. This is what the implementations do. Because of these two reasons, I do not think there is any IEEE document that describes "Ethernet Adaptation Layer". This the best I can do to find a reference. Maybe there is an IEEE document that describes how comes that WiFi looks like Ethernet to IP? Alex > > AB > > [1] http://www.ietf.org/mail-archive/web/its/current/msg01889.html > From nobody Mon Feb 12 09:18:15 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2230912D86B for ; Mon, 12 Feb 2018 09:18:14 -0800 (PST) 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 nhv8XkrFrUiM for ; Mon, 12 Feb 2018 09:18:12 -0800 (PST) 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 10E4E1241FC for ; Mon, 12 Feb 2018 09:18:11 -0800 (PST) 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 w1CHFUSp151990 for ; Mon, 12 Feb 2018 18:18:10 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D47F1208BB0 for ; Mon, 12 Feb 2018 12:41:58 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C9A78208B44 for ; Mon, 12 Feb 2018 12:41:58 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w1CBfwh9030338 for ; Mon, 12 Feb 2018 12:41:58 +0100 To: "its@ietf.org" From: Alexandre Petrescu Message-ID: Date: Mon, 12 Feb 2018 12:41:58 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------BF6632455197061304841AEA" Content-Language: fr Archived-At: Subject: [ipwave] Use of the RFC2119 terminology in order to become a specification 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, 12 Feb 2018 17:18:14 -0000 This is a multi-part message in MIME format. --------------BF6632455197061304841AEA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Tony, >> There is more relatively normative text in section 4.5 "Stateless >> Autoconfiguration". This recommends the use of RFC7136 (ug bits) >> and RFC 8064 (stable ids) and RFC 7217 (opaque ids). These >> recommendations dont exist in RFC2464 (IPv6-over-Ethernet) and they >> dont exist in any IPv6-over-WiFi document because such >> IPv6-over-WiFi does not exist. >> >> I hope this qualifies as 'specification’. > > > It qualifies as a recommendation for right now. If you want it to be > mandatory, you need to specifically use RFC 2119 terminology. The word MUST is used in the MTU section 4.1 about MTU size. I could add another MUST in there: > The Ethernet Type code (EtherType) for IPv6 MUST be 0x86DD (hexadecimal 86DD, > or otherwise #86DD). Is this ok? >> (and I do not know what is DIX, never encountered it). > > > DIX is another name for Ethertype encapsulation. AFAIK, it has never > been ratified by the IEEE. Maybe "DIX" means "Ethernet Adaptation Layer"? Alex --------------BF6632455197061304841AEA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Tony,


>> There is more relatively normative text in section 4.5 "Stateless >> Autoconfiguration". This recommends the use of RFC7136 (ug bits) >> and RFC 8064 (stable ids) and RFC 7217 (opaque ids). These >> recommendations dont exist in RFC2464 (IPv6-over-Ethernet) and they >> dont exist in any IPv6-over-WiFi document because such >> IPv6-over-WiFi does not exist. >> >> I hope this qualifies as 'specification’. > > > It qualifies as a recommendation for right now. If you want it to be > mandatory, you need to specifically use RFC 2119 terminology.
The word MUST is used in the MTU section 4.1 about MTU size.

I could add another MUST in there:

The Ethernet Type code (EtherType) for IPv6 MUST be 0x86DD (hexadecimal 86DD,
   or otherwise #86DD).

Is this ok?


>> (and I do not know what is DIX, never encountered it). > > > DIX is another name for Ethertype encapsulation. AFAIK, it has never > been ratified by the IEEE.
Maybe "DIX" means "Ethernet Adaptation Layer"?

Alex


--------------BF6632455197061304841AEA-- From nobody Mon Feb 12 09:18:26 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CBAE12D877 for ; Mon, 12 Feb 2018 09:18:17 -0800 (PST) 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 JE1m6NVAltVw for ; Mon, 12 Feb 2018 09:18:15 -0800 (PST) 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 12C3F1241FC for ; Mon, 12 Feb 2018 09:18:14 -0800 (PST) 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 w1CHI9Ed006620 for ; Mon, 12 Feb 2018 18:18:13 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4419A2057C1 for ; Mon, 12 Feb 2018 12:49:24 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 3723D205FC1 for ; Mon, 12 Feb 2018 12:49:24 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w1CBnNGe000763 for ; Mon, 12 Feb 2018 12:49:24 +0100 To: "its@ietf.org" From: Alexandre Petrescu Message-ID: <9f4fe7c1-a89b-3861-d950-848093d6100f@gmail.com> Date: Mon, 12 Feb 2018 12:49:23 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------B50AE29DD15B51C31EADD5B6" Content-Language: fr Archived-At: Subject: [ipwave] Fragmentation operation of the Ethernet Adaptation Layer 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, 12 Feb 2018 17:18:17 -0000 This is a multi-part message in MIME format. --------------B50AE29DD15B51C31EADD5B6 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Tony, >>>> This Adaptation Layer has direct impact on how fragmentation >>>> is performed: the field "Sequence number" of the 802.11 Data >>>> header is increased when the IP MTU is overcome. This behavior >>>> does not exist in Ethernet. >>> But this does not affect the way IPv6 works, does it? This is >>> something taken care by the IEEE 802.11 data header, no? >> >> At sending, the IP stack decides whether it fragments and then >> tells the MAC layer to increase its seqno. At reception, >> vice-versa. >> >> IPv6 Fragment Header also has an Identification field. >> >> The two fields (Id field in IPv6 header and seqno in 802.11 MAC >> header) are correlated. > > > Please note that that’s your opinion. I think yes, the last phrase is my oppinion. But the first two phrases are not just my oppinion. > One might also point out that fragmentation is just a bad idea to > begin with and should not ever happen. Therefore, what happens after > you make the mistake of fragmenting is irrelevant. :-) > > Tying the L2 header to the L3 fragmentation process is, IMHO, another > mistake. Well, it depends.  If it is a mistake, then it is a mistake widely implemented that we just document here. But we can discuss the details of  this 'tying'. I am not sure whether the id field in the IPv6 frag header has a precise relationship to the seqno field in the 802.11 header. But I am sure that when the IP packet is too large compared to the MTU then both 802.11 and IP fragmentation happen. This is what all 802.11 including OCB implementations do. > It increases complexity, is a layering violation, and things > would operate just fine even if we did nothing special. If and when > L3 decides to fragment, the resulting fragments are simply separate > packets. L2 doesn’t need to know that they have an L3 relationship. That's a principle enunciated well, but the implementations dont act that way. When IP decides to fragment the MAC layer also tells this is a fragment. Alex --------------B50AE29DD15B51C31EADD5B6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Tony,

>>>> This Adaptation Layer has direct impact on how fragmentation >>>> is performed: the field "Sequence number" of the 802.11 Data >>>> header is increased when the IP MTU is overcome. This behavior >>>> does not exist in Ethernet. >>> But this does not affect the way IPv6 works, does it? This is >>> something taken care by the IEEE 802.11 data header, no? >> >> At sending, the IP stack decides whether it fragments and then >> tells the MAC layer to increase its seqno. At reception, >> vice-versa. >> >> IPv6 Fragment Header also has an Identification field. >> >> The two fields (Id field in IPv6 header and seqno in 802.11 MAC >> header) are correlated. > > > Please note that that’s your opinion.
I think yes, the last phrase is my oppinion.

But the first two phrases are not just my oppinion.

> One might also point out that fragmentation is just a bad idea to > begin with and should not ever happen. Therefore, what happens after > you make the mistake of fragmenting is irrelevant. :-) > > Tying the L2 header to the L3 fragmentation process is, IMHO, another > mistake.
Well, it depends.  If it is a mistake, then it is a mistake widely implemented that we just document here.

But we can discuss the details of  this 'tying'.

I am not sure whether the id field in the IPv6 frag header has a precise relationship to the seqno field in the 802.11 header.

But I am sure that when the IP packet is too large compared to the MTU then both 802.11 and IP fragmentation happen.
This is what all 802.11 including OCB implementations do.

> It increases complexity, is a layering violation, and things > would operate just fine even if we did nothing special. If and when > L3 decides to fragment, the resulting fragments are simply separate > packets. L2 doesn’t need to know that they have an L3 relationship.
That's a principle enunciated well, but the implementations dont act that way.

When IP decides to fragment the MAC layer also tells this is a fragment.

Alex


--------------B50AE29DD15B51C31EADD5B6-- From nobody Mon Feb 12 09:18:33 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91AD512D87A for ; Mon, 12 Feb 2018 09:18:26 -0800 (PST) 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 DjFu44fABZbv for ; Mon, 12 Feb 2018 09:18:17 -0800 (PST) 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 31BE112D876 for ; Mon, 12 Feb 2018 09:18:17 -0800 (PST) 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 w1CHIEgB154847; Mon, 12 Feb 2018 18:18:15 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 92E28208C3C; Mon, 12 Feb 2018 12:54:31 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 80CB1208C3A; Mon, 12 Feb 2018 12:54:31 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w1CBsVr4002813; Mon, 12 Feb 2018 12:54:31 +0100 To: Alfonso Guillen Cc: "its@ietf.org" From: Alexandre Petrescu Message-ID: Date: Mon, 12 Feb 2018 12:54:31 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------134D9DF4215A62C444D401F9" Content-Language: fr Archived-At: Subject: [ipwave] How to look at archives, Vol and Issue 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, 12 Feb 2018 17:18:27 -0000 This is a multi-part message in MIME format. --------------134D9DF4215A62C444D401F9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit > Some one, can support me how can I help in this Vol and Issue? > Regards Alfonso I dont know, but you could look at the archives at https://mailarchive.ietf.org/arch/search/?email_list=its The message you refer to is at: https://mailarchive.ietf.org/arch/msg/its/j9Lkt4AW_QgyscpwoWZjovpAF-E Alex > > > De:"its-request@ietf.org" ; ; > Para:its@ietf.org > Enviado: Martes 6 de febrero de 2018 12:09 > Asunto: its Digest, Vol 68, Issue 18 > > Send its mailing list submissions to > its@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/its > or, via email, send a message with subject or body 'help' to > its-request@ietf.org > > You can reach the person managing the list at > its-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of its digest..." > Today's Topics: > >   1. Re: FW: Shepherd review of >       draft-ietf-ipwave-ipv6-over-80211ocb-12 (Alexandre Petrescu) >   2. Re: FW: Shepherd review of >       draft-ietf-ipwave-ipv6-over-80211ocb-12 (Alexandre Petrescu) > > > Le 06/02/2018 à 18:40, Abdussalam Baryun a écrit : > > Hi Alex and Francois, > > > > I don't mind putting any clear definition in terms but should be used in > > the body consistently within the draft. > > IP-OBU and IP-RSU are used in the text.  We are not using DSRC, DSRCS, > OBU nor RSU in the text. > > > Also we need to try to make the > > definition short and to the point. I am not very interested in this > > IP-xxx, however, I like the terminology used in RFC8200. so we should > > mention that our IP-units are nodes or routers, > > Noted. > > > in terminology the > > definition word 'computer' used is not consistent with other ietf RFCs. > > 'computer' is generic enough to not need a definition. > > I used 'computer' to solve the problem of saying 'Host' vs saying > 'Router'.  That debate is not solved and we wont solve it here. > > Alex > > > > > AB > > > > On Tue, Feb 6, 2018 at 6:47 PM, Alexandre Petrescu > > > wrote: > > > > > > > >    Le 06/02/2018 à 17:40, François Simon a écrit : > > > >        Mr. Petrescu, > > > >        /“//There are two very relevant terms: IP-OBU and IP-RSU.//”/// > > > >        -// IftheWorkingGroupthinksthese terms are relevant, thenso > >        bid.Irespectfully disagree.Furthermore,I have nothing more to > >        add to this discussion;I have provided allUS relevant definitions. > > > > > >    I thank you for the definitions. > > > >    I propose we go this way: > > > >    Copy the definitions from your emails for DSRCS, and then DSRC and > >    then OBU and RSU in terms of DSRCS and of DSRC. > > > >    But have these definitions (DSRCS, DSRC, OBU and RSU) in an > >    Appendix, not in the Terminology section. > > > >    The Terminology section would list IP-OBU and IP-RSU and refer to > >    the Appendix. > > > >    Alex > > > > > >        Sincerely, > > > >        Francois Simon > > > >        Lojik Technologies > > > >        -----Original Message----- > >        From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com > >        ] > >        Sent: Tuesday, February 06, 2018 10:41 AM > >        To: François Simon > > >        Cc: its@ietf.org > >        Subject: Re: FW: [ipwave] Shepherd review of > >        draft-ietf-ipwave-ipv6-over-80211ocb-12 > > > >        If I add DSRCS, and DSRC, and OBU - it makes for 3 terms only > >        tangentially relevant. > > > >        I find it too much. > > > >        There are two very relevant terms: IP-OBU and IP-RSU. > > > >        We need to have more relevant terms than tangentially relevant > >        terms. > > > >        Le 06/02/2018 à 03:25, François Simon a écrit : > > > >            /"//So, in order to define OBU in terms of DSRCS one has to > >            define > > > > > >            first DSRCS, all while caring to avoid loops.  I think it > >            can become > > > > > >            too lengthy.//"/// > > > > > > > > > >            -///Dedicated Short-Range Communications////Services > >            (DSRCS)/.-The use > > > > > >            of radio techniquesto transfer data over short distancesbetween > > > > > >            roadside and mobile > > > > > > > > > >                       units, between mobile units, and betweenportable > >            and mobile > > > > > >                       units to performoperations related to the > >            improvementof traffic > > > > > >                       flow, traffic safety, > > > > > > > > > >                       and other intelligent transportationservice > >            applications in a > > > > > >                       varietyof environments. DSRCS systems mayalso > >            transmit status > > > > > >                       and instructional > > > > > > > > > >                       messages related to the units involved.[ Ref. 47 > >            CFR90.7 – > > > > > >                       Definitions] > > > > > > > > > >            -----Original Message----- > > > > > >            From: Alexandre Petrescu > >            [mailto:alexandre.petrescu@gmail.com > >            ] > > > > > >            Sent: Monday, February 05, 2018 10:41 AM > > > > > >            To: François Simon > >            >            >> > > > > > >            Cc:its@ietf.org > >            >            > > > > > > >            Subject: Re: [ipwave] Shepherd review of > > > > > >            draft-ietf-ipwave-ipv6-over-80211ocb-12 > > > > > > > > > >            Le 05/02/2018 à 16:10, François Simon a écrit : > > > > > > > > > >                /"//Is DSRCS a typo? (correct DSRC).//"/// > > > > > > > > > > > > > > > > > >                -// No typo. DSRCS stands for “Dedicated Short Range > >                Communication Service” > > > > > > > > > >            So, in order to define OBU in terms of DSRCS one has to > >            define first > > > > > >            DSRCS, all while caring to avoid loops.  I think it can > >            become too lengthy. > > > > > > > > > >            Alex > > > > > > > > > > > > > > > > > >                -----Original Message----- > > > > > > > > > >                From: Alexandre Petrescu > >                [mailto:alexandre.petrescu@gmail.com > >                ] > > > > > > > > > >                Sent: Sunday, February 04, 2018 11:08 AM > > > > > > > > > >                To: François Simon > >                >                >                >                >>> > > > > > > > > > >                Cc:its@ietf.org > >                >                > > > > > > > > > > >                Subject: Re: [ipwave] Shepherd review of > > > > > > > > > >                draft-ietf-ipwave-ipv6-over-80211ocb-12 > > > > > > > > > > > > > > > > > >                I am adding this OBU ref for reference but I have a > >                question: > > > > > > > > > > > > > > > > > >                Le 02/02/2018 à 11:23, François Simon a écrit : > > > > > > > > > > > > > > > > > >                [...] > > > > > > > > > > > > > > > > > >                    /On-Board unit (OBU). An On-Board Unit is a DSRCS > >                    transceiver that > > > > > >                    is > > > > > > > > > > > > > > > > > >                Is DSRCS a typo? (correct DSRC). > > > > > > > > > > > > > > > > > >                Alex > > > > > > > > > > > > > > > > > >                    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. The OBUs receive and > >                    contend for > > > > > >                    time > > > > > > > > > > > > > > > > > >                    to transmit on one or more radio frequency (RF) > >                    channels. Except > > > > > > > > > >                    where > > > > > > > > > > > > > > > > > >                    specifically excluded, OBU operation is permitted > >                    wherever vehicle > > > > > > > > > > > > > > > > > >                    operation or human passage is permitted. The OBUs > >                    mounted in > > > > > >                    vehicles > > > > > > > > > > > > > > > > > >                    are licensed by rule under part 95 of this chapter > >                    and communicate > > > > > > > > > > > > > > > > > >                    with Roadside Units (RSUs) and other OBUs. Portable > >                    OBUs are also > > > > > > > > > > > > > > > > > >                    licensed by rule under part 95 of this chapter. OBU > >                    operations in > > > > > >                    the > > > > > > > > > > > > > > > > > >                    Unlicensed National Information Infrastructure > >                    (UNII) Bands follow > > > > > > > > > >                    the > > > > > > > > > > > > > > > > > >                    rules in those bands./- [CFR 90.7 - Definitions] - > >                    October 2010 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >                    *IPWAVE Issue*** > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >                    ** > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >                    /“The problem with the FCC definition of OBU is that > >                    it has no > > > > > > > > > > > > > > > > > >                    relationship to IP.  Worse, that FCC definition has > >                    no indication > > > > > > > > > >                    that > > > > > > > > > > > > > > > > > >                    it MAY use IP somehow.  And here we say that all > >                    OBUs must use IP. > > > > > > > > > >                    Do > > > > > > > > > > > > > > > > > >                    you see what I mean?”/// > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >                    // > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >                    Correct; the OBU has no relationship with IP and is > >                    not intended to. > > > > > > > > > > > > > > > > > >                    IP is a network protocol.  If an On-Board Unit (OBU) > >                    device is > > > > > > > > > > > > > > > > > >                    required to exchange IP, it needs to be dealt in > >                    protocol(s) and/or > > > > > > > > > > > > > > > > > >                    Management in higher layers similar to WAVE within > >                    the On-Board Equipment (OBE) . > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >                    /“Do you think FCC will mind if we use the term OBU > >                    in this draft to > > > > > > > > > > > > > > > > > >                    mean something else?  I, and a colleague, think that > >                    FCC would not > > > > > > > > > > > > > > > > > >                    mind.”/// > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >                    // > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >                    Depending of the reader. If one is familiar with > >                    DSRC, OBU and RSU > > > > > >                    as > > > > > > > > > > > > > > > > > >                    defined by FCC will come in mind. As far as I know, > >                    “OBU” and “RSU” > > > > > > > > > > > > > > > > > >                    are not registered and could be used for other > >                    definitions > > > > > >                    (something > > > > > > > > > > > > > > > > > >                    like > > > > > > > > > > > > > > > > > >                    “ATM”: Asynchronous Transfer Mode and Automatic > >                    Teller Machine😊). > > > > > >                    My > > > > > > > > > > > > > > > > > >                    suggestion to the IPWAVE team is to use “OBE and RSE”. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >                    This is my personal view as I donot represent any > >                    involved interest. > > > > > > > > > > > > > > > > > >                    If any one has questions, let me know. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >                    Francois Simon > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >                    Lojik Technologies > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >                    -----Original Message----- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >                    From: its [mailto:its-bounces@ietf.org > >                    ] On Behalf Of Alexandre > > > > > > > > > > > > > > > > > >                    Petrescu > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >                    Sent: Monday, January 29, 2018 10:08 AM > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >                    To:its@ietf.org > >                    >                    > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >                    Subject: Re: [ipwave] Shepherd review of > > > > > > > > > > > > > > > > > >                    draft-ietf-ipwave-ipv6-over-80211ocb-12 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >                    Le 29/01/2018 à 15:52, François Simon a écrit : > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >                        My comments arewithin the text*[Fygs.......]*. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >                    [...] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >                        In the terminology section, the OBU term is > >                        mentioned to be defined > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >                        outside the IETF. This is fine, but we have to > >                        provide a reference. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >                        And even with that, it would not harm to include > >                        some short > > > > > > > > > > > > > > > > > >                        definition > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >                        to provide context. The RSU term is also defined > >                        outside the IETF > > > > > > > > > >                        and > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >                        there is quite a lot of text provided (I think > >                        the relevant part is > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >                        the last sentence, the one starting with "The > >                        difference between..."). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >                        Both terms should be handled in the same way. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >                        *[Fygs: The**definitions**was issued by the FCC > >                        20 years ago.  I > > > > > > > > > >                        have > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Le 06/02/2018 à 19:04, Dick Roy a écrit : > > ------------------------------------------------------------------------ > > > > *From:*its [mailto:its-bounces@ietf.org] *On Behalf Of *Abdussalam Baryun > > *Sent:* Tuesday, February 6, 2018 9:40 AM > > *To:* Alexandre Petrescu > > *Cc:* François Simon; its > > *Subject:* Re: [ipwave] FW: Shepherd review of > > draft-ietf-ipwave-ipv6-over-80211ocb-12 > > > > Hi Alex and Francois, > > > > I don't mind putting any clear definition in terms but should be used in > > the body consistently within the draft. Also we need to try to make the > > definition short and to the point. I am not very interested in this > > IP-xxx, however, I like the terminology used in RFC8200. so we should > > mention that our IP-units are nodes or routers, > > > > */[RR] While certainly not an expert on this, I was under the impression > > any entity on an IP network was a node, and that there are two types of > > functionality: host and router.  A node can implement host > > functionality, router functionality, or both. If that’s the case, this > > ought to be clearly stated somewhere./* > > You see, people already say 'Host vs Router' and 'Node vs Router'. > There are a few IPv6 related RFCs that disagree on it. > > Here we say 'IP-OBU' and 'IP-RSU' and 'computer'. > > Alex > > > > > */ > > RR/* > > > > in terminology the definition word 'computer' used is not consistent > > with other ietf RFCs. > > > > AB > > > > On Tue, Feb 6, 2018 at 6:47 PM, Alexandre Petrescu > > > wrote: > > > > > > > > Le 06/02/2018 à 17:40, François Simon a écrit : > > > > Mr. Petrescu, > > > > /“//There are two very relevant terms: IP-OBU and IP-RSU.//”/// > > > > -// IftheWorkingGroupthinksthese terms are relevant, thenso > > bid.Irespectfully disagree.Furthermore,I have nothing more to add to > > this discussion;I have provided allUS relevant definitions. > > > > > > I thank you for the definitions. > > > > I propose we go this way: > > > > Copy the definitions from your emails for DSRCS, and then DSRC and then > > OBU and RSU in terms of DSRCS and of DSRC. > > > > But have these definitions (DSRCS, DSRC, OBU and RSU) in an Appendix, > > not in the Terminology section. > > > > The Terminology section would list IP-OBU and IP-RSU and refer to the > > Appendix. > > > > Alex > > > > > > Sincerely, > > > > Francois Simon > > > > Lojik Technologies > > > > -----Original Message----- > > From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com > > ] > > Sent: Tuesday, February 06, 2018 10:41 AM > > To: François Simon > > > Cc: its@ietf.org > > Subject: Re: FW: [ipwave] Shepherd review of > > draft-ietf-ipwave-ipv6-over-80211ocb-12 > > > > If I add DSRCS, and DSRC, and OBU - it makes for 3 terms only > > tangentially relevant. > > > > I find it too much. > > > > There are two very relevant terms: IP-OBU and IP-RSU. > > > > We need to have more relevant terms than tangentially relevant terms. > > > > Le 06/02/2018 à 03:25, François Simon a écrit : > > > > /"//So, in order to define OBU in terms of DSRCS one has to define > > > >    first DSRCS, all while caring to avoid loops.  I think it can become > > > >    too lengthy.//"/// > > > >    -///Dedicated Short-Range Communications////Services (DSRCS)/.-The use > > > >    of radio techniquesto transfer data over short distancesbetween > > > >    roadside and mobile > > > >               units, between mobile units, and betweenportable and mobile > > > >               units to performoperations related to the improvementof > >    traffic > > > >               flow, traffic safety, > > > >               and other intelligent transportationservice applications in a > > > >               varietyof environments. DSRCS systems mayalso transmit status > > > >               and instructional > > > >               messages related to the units involved.[ Ref. 47 CFR90.7 – > > > >               Definitions] > > > >    -----Original Message----- > > > >    From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com > >    ] > > > >    Sent: Monday, February 05, 2018 10:41 AM > > > >    To: François Simon > >    >    >> > > > >    Cc:its@ietf.org >    > > > > >    Subject: Re: [ipwave] Shepherd review of > > > >    draft-ietf-ipwave-ipv6-over-80211ocb-12 > > > >    Le 05/02/2018 à 16:10, François Simon a écrit : > > > >        /"//Is DSRCS a typo? (correct DSRC).//"/// > > > >        -// No typo. DSRCS stands for “Dedicated Short Range > >        Communication Service” > > > >    So, in order to define OBU in terms of DSRCS one has to define first > > > >    DSRCS, all while caring to avoid loops.  I think it can become too > >    lengthy. > > > >    Alex > > > >        -----Original Message----- > > > >        From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com > >        ] > > > >        Sent: Sunday, February 04, 2018 11:08 AM > > > >        To: François Simon > >        >        >        >        >>> > > > >        Cc:its@ietf.org >        > > > > >        Subject: Re: [ipwave] Shepherd review of > > > >        draft-ietf-ipwave-ipv6-over-80211ocb-12 > > > >        I am adding this OBU ref for reference but I have a question: > > > >        Le 02/02/2018 à 11:23, François Simon a écrit : > > > >        [...] > > > >            /On-Board unit (OBU). An On-Board Unit is a DSRCS > >            transceiver that > > > >            is > > > >        Is DSRCS a typo? (correct DSRC). > > > >        Alex > > > >            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. The OBUs receive and contend > >            for > > > >            time > > > >            to transmit on one or more radio frequency (RF) channels. Except > > > >            where > > > >            specifically excluded, OBU operation is permitted wherever > >            vehicle > > > >            operation or human passage is permitted. The OBUs mounted in > > > >            vehicles > > > >            are licensed by rule under part 95 of this chapter and > >            communicate > > > >            with Roadside Units (RSUs) and other OBUs. Portable OBUs are > >            also > > > >            licensed by rule under part 95 of this chapter. OBU > >            operations in > > > >            the > > > >            Unlicensed National Information Infrastructure (UNII) Bands > >            follow > > > >            the > > > >            rules in those bands./- [CFR 90.7 - Definitions] - October 2010 > > > >            *IPWAVE Issue*** > > > >            ** > > > >            /“The problem with the FCC definition of OBU is that it has no > > > >            relationship to IP.  Worse, that FCC definition has no > >            indication > > > >            that > > > >            it MAY use IP somehow.  And here we say that all OBUs must > >            use IP. > > > >            Do > > > >            you see what I mean?”/// > > > >            // > > > >            Correct; the OBU has no relationship with IP and is not > >            intended to. > > > >            IP is a network protocol.  If an On-Board Unit (OBU) device is > > > >            required to exchange IP, it needs to be dealt in protocol(s) > >            and/or > > > >            Management in higher layers similar to WAVE within the > >            On-Board Equipment (OBE) . > > > >            /“Do you think FCC will mind if we use the term OBU in this > >            draft to > > > >            mean something else?  I, and a colleague, think that FCC > >            would not > > > >            mind.”/// > > > >            // > > > >            Depending of the reader. If one is familiar with DSRC, OBU > >            and RSU > > > >            as > > > >            defined by FCC will come in mind. As far as I know, “OBU” > >            and “RSU” > > > >            are not registered and could be used for other definitions > > > >            (something > > > >            like > > > >            “ATM”: Asynchronous Transfer Mode and Automatic Teller > >            Machine😊). > > > >            My > > > >            suggestion to the IPWAVE team is to use “OBE and RSE”. > > > >            This is my personal view as I donot represent any involved > >            interest. > > > >            If any one has questions, let me know. > > > >            Francois Simon > > > >            Lojik Technologies > > > >            -----Original Message----- > > > >            From: its [mailto:its-bounces@ietf.org > >            ] On Behalf Of Alexandre > > > >            Petrescu > > > >            Sent: Monday, January 29, 2018 10:08 AM > > > >            To:its@ietf.org > >            >            > > > > >            Subject: Re: [ipwave] Shepherd review of > > > >            draft-ietf-ipwave-ipv6-over-80211ocb-12 > > > >            Le 29/01/2018 à 15:52, François Simon a écrit : > > > >                My comments arewithin the text*[Fygs.......]*. > > > >            [...] > > > >                In the terminology section, the OBU term is mentioned to > >                be defined > > > >                outside the IETF. This is fine, but we have to provide a > >                reference. > > > >                And even with that, it would not harm to include some short > > > >                definition > > > >                to provide context. The RSU term is also defined outside > >                the IETF > > > >                and > > > >                there is quite a lot of text provided (I think the > >                relevant part is > > > >                the last sentence, the one starting with "The difference > >                between..."). > > > >                Both terms should be handled in the same way. > > > >                *[Fygs: The**definitions**was issued by the FCC 20 years > >                ago.  I > > > >                have > > > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > > --------------134D9DF4215A62C444D401F9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit 

Some one, can support me how can I help in this Vol and Issue?
Regards Alfonso  

I dont know, but you could look at the archives at https://mailarchive.ietf.org/arch/search/?email_list=its

The message you refer to is at:

https://mailarchive.ietf.org/arch/msg/its/j9Lkt4AW_QgyscpwoWZjovpAF-E

Alex


  

      De: "its-request@ietf.org"; <its-request@ietf.org>;
 Para: its@ietf.org 
 Enviado: Martes 6 de febrero de 2018 12:09
 Asunto: its Digest, Vol 68, Issue 18
   
Send its mailing list submissions to
    its@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
    https://www.ietf.org/mailman/listinfo/its
or, via email, send a message with subject or body 'help' to
    its-request@ietf.org

You can reach the person managing the list at
    its-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of its digest..."
Today's Topics:

  1. Re: FW: Shepherd review of
      draft-ietf-ipwave-ipv6-over-80211ocb-12 (Alexandre Petrescu)
  2. Re: FW: Shepherd review of
      draft-ietf-ipwave-ipv6-over-80211ocb-12 (Alexandre Petrescu)


Le 06/02/2018 à 18:40, Abdussalam Baryun a écrit :
> Hi Alex and Francois,
> 
> I don't mind putting any clear definition in terms but should be used in 
> the body consistently within the draft.

IP-OBU and IP-RSU are used in the text.  We are not using DSRC, DSRCS, 
OBU nor RSU in the text.

> Also we need to try to make the 
> definition short and to the point. I am not very interested in this 
> IP-xxx, however, I like the terminology used in RFC8200. so we should 
> mention that our IP-units are nodes or routers,

Noted.

> in terminology the 
> definition word 'computer' used is not consistent with other ietf RFCs.

'computer' is generic enough to not need a definition.

I used 'computer' to solve the problem of saying 'Host' vs saying 
'Router'.  That debate is not solved and we wont solve it here.

Alex

> 
> AB
> 
> On Tue, Feb 6, 2018 at 6:47 PM, Alexandre Petrescu 
> <alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>> wrote:
> 
> 
> 
>    Le 06/02/2018 à 17:40, François Simon a écrit :
> 
>        Mr. Petrescu,
> 
>        /“//There are two very relevant terms: IP-OBU and IP-RSU.//”///
> 
>        -// IftheWorkingGroupthinksthese terms are relevant, thenso
>        bid.Irespectfully disagree.Furthermore,I have nothing more to
>        add to this discussion;I have provided allUS relevant definitions.
> 
> 
>    I thank you for the definitions.
> 
>    I propose we go this way:
> 
>    Copy the definitions from your emails for DSRCS, and then DSRC and
>    then OBU and RSU in terms of DSRCS and of DSRC.
> 
>    But have these definitions (DSRCS, DSRC, OBU and RSU) in an
>    Appendix, not in the Terminology section.
> 
>    The Terminology section would list IP-OBU and IP-RSU and refer to
>    the Appendix.
> 
>    Alex
> 
> 
>        Sincerely,
> 
>        Francois Simon
> 
>        Lojik Technologies
> 
>        -----Original Message-----
>        From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com
>        <mailto:alexandre.petrescu@gmail.com>]
>        Sent: Tuesday, February 06, 2018 10:41 AM
>        To: François Simon <fygsimon@gmail.com <mailto:fygsimon@gmail.com>>
>        Cc: its@ietf.org <mailto:its@ietf.org>
>        Subject: Re: FW: [ipwave] Shepherd review of
>        draft-ietf-ipwave-ipv6-over-80211ocb-12
> 
>        If I add DSRCS, and DSRC, and OBU - it makes for 3 terms only
>        tangentially relevant.
> 
>        I find it too much.
> 
>        There are two very relevant terms: IP-OBU and IP-RSU.
> 
>        We need to have more relevant terms than tangentially relevant
>        terms.
> 
>        Le 06/02/2018 à 03:25, François Simon a écrit :
> 
>            /"//So, in order to define OBU in terms of DSRCS one has to
>            define
> 
> 
>            first DSRCS, all while caring to avoid loops.  I think it
>            can become
> 
> 
>            too lengthy.//"///
> 
> 
> 
> 
>            -///Dedicated Short-Range Communications////Services
>            (DSRCS)/.-The use
> 
> 
>            of radio techniquesto transfer data over short distancesbetween
> 
> 
>            roadside and mobile
> 
> 
> 
> 
>                       units, between mobile units, and betweenportable
>            and mobile
> 
> 
>                       units to performoperations related to the
>            improvementof traffic
> 
> 
>                       flow, traffic safety,
> 
> 
> 
> 
>                       and other intelligent transportationservice
>            applications in a
> 
> 
>                       varietyof environments. DSRCS systems mayalso
>            transmit status
> 
> 
>                       and instructional
> 
> 
> 
> 
>                       messages related to the units involved.[ Ref. 47
>            CFR90.7 –
> 
> 
>                       Definitions]
> 
> 
> 
> 
>            -----Original Message-----
> 
> 
>            From: Alexandre Petrescu
>            [mailto:alexandre.petrescu@gmail.com
>            <mailto:alexandre.petrescu@gmail.com>]
> 
> 
>            Sent: Monday, February 05, 2018 10:41 AM
> 
> 
>            To: François Simon <fygsimon@gmail.com
>            <mailto:fygsimon@gmail.com><mailto:fygsimon@gmail.com
>            <mailto:fygsimon@gmail.com>>>
> 
> 
>            Cc:its@ietf.org
>            <mailto:Cc%3Aits@ietf.org><mailto:its@ietf.org
>            <mailto:its@ietf.org>>
> 
> 
>            Subject: Re: [ipwave] Shepherd review of
> 
> 
>            draft-ietf-ipwave-ipv6-over-80211ocb-12
> 
> 
> 
> 
>            Le 05/02/2018 à 16:10, François Simon a écrit :
> 
> 
> 
> 
>                /"//Is DSRCS a typo? (correct DSRC).//"///
> 
> 
> 
> 
> 
> 
> 
> 
>                -// No typo. DSRCS stands for “Dedicated Short Range
>                Communication Service”
> 
> 
> 
> 
>            So, in order to define OBU in terms of DSRCS one has to
>            define first
> 
> 
>            DSRCS, all while caring to avoid loops.  I think it can
>            become too lengthy.
> 
> 
> 
> 
>            Alex
> 
> 
> 
> 
> 
> 
> 
> 
>                -----Original Message-----
> 
> 
> 
> 
>                From: Alexandre Petrescu
>                [mailto:alexandre.petrescu@gmail.com
>                <mailto:alexandre.petrescu@gmail.com>]
> 
> 
> 
> 
>                Sent: Sunday, February 04, 2018 11:08 AM
> 
> 
> 
> 
>                To: François Simon <fygsimon@gmail.com
>                <mailto:fygsimon@gmail.com><mailto:fygsimon@gmail.com
>                <mailto:fygsimon@gmail.com><mailto:fygsimon@gmail.com
>                <mailto:fygsimon@gmail.com><mailto:fygsimon@gmail.com
>                <mailto:fygsimon@gmail.com>>>>
> 
> 
> 
> 
>                Cc:its@ietf.org
>                <mailto:Cc%3Aits@ietf.org><mailto:its@ietf.org
>                <mailto:its@ietf.org>>
> 
> 
> 
> 
>                Subject: Re: [ipwave] Shepherd review of
> 
> 
> 
> 
>                draft-ietf-ipwave-ipv6-over-80211ocb-12
> 
> 
> 
> 
> 
> 
> 
> 
>                I am adding this OBU ref for reference but I have a
>                question:
> 
> 
> 
> 
> 
> 
> 
> 
>                Le 02/02/2018 à 11:23, François Simon a écrit :
> 
> 
> 
> 
> 
> 
> 
> 
>                [...]
> 
> 
> 
> 
> 
> 
> 
> 
>                    /On-Board unit (OBU). An On-Board Unit is a DSRCS
>                    transceiver that
> 
> 
>                    is
> 
> 
> 
> 
> 
> 
> 
> 
>                Is DSRCS a typo? (correct DSRC).
> 
> 
> 
> 
> 
> 
> 
> 
>                Alex
> 
> 
> 
> 
> 
> 
> 
> 
>                    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. The OBUs receive and
>                    contend for
> 
> 
>                    time
> 
> 
> 
> 
> 
> 
> 
> 
>                    to transmit on one or more radio frequency (RF)
>                    channels. Except
> 
> 
> 
> 
>                    where
> 
> 
> 
> 
> 
> 
> 
> 
>                    specifically excluded, OBU operation is permitted
>                    wherever vehicle
> 
> 
> 
> 
> 
> 
> 
> 
>                    operation or human passage is permitted. The OBUs
>                    mounted in
> 
> 
>                    vehicles
> 
> 
> 
> 
> 
> 
> 
> 
>                    are licensed by rule under part 95 of this chapter
>                    and communicate
> 
> 
> 
> 
> 
> 
> 
> 
>                    with Roadside Units (RSUs) and other OBUs. Portable
>                    OBUs are also
> 
> 
> 
> 
> 
> 
> 
> 
>                    licensed by rule under part 95 of this chapter. OBU
>                    operations in
> 
> 
>                    the
> 
> 
> 
> 
> 
> 
> 
> 
>                    Unlicensed National Information Infrastructure
>                    (UNII) Bands follow
> 
> 
> 
> 
>                    the
> 
> 
> 
> 
> 
> 
> 
> 
>                    rules in those bands./- [CFR 90.7 - Definitions] -
>                    October 2010
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>                    *IPWAVE Issue***
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>                    **
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>                    /“The problem with the FCC definition of OBU is that
>                    it has no
> 
> 
> 
> 
> 
> 
> 
> 
>                    relationship to IP.  Worse, that FCC definition has
>                    no indication
> 
> 
> 
> 
>                    that
> 
> 
> 
> 
> 
> 
> 
> 
>                    it MAY use IP somehow.  And here we say that all
>                    OBUs must use IP.
> 
> 
> 
> 
>                    Do
> 
> 
> 
> 
> 
> 
> 
> 
>                    you see what I mean?”///
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>                    //
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>                    Correct; the OBU has no relationship with IP and is
>                    not intended to.
> 
> 
> 
> 
> 
> 
> 
> 
>                    IP is a network protocol.  If an On-Board Unit (OBU)
>                    device is
> 
> 
> 
> 
> 
> 
> 
> 
>                    required to exchange IP, it needs to be dealt in
>                    protocol(s) and/or
> 
> 
> 
> 
> 
> 
> 
> 
>                    Management in higher layers similar to WAVE within
>                    the On-Board Equipment (OBE) .
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>                    /“Do you think FCC will mind if we use the term OBU
>                    in this draft to
> 
> 
> 
> 
> 
> 
> 
> 
>                    mean something else?  I, and a colleague, think that
>                    FCC would not
> 
> 
> 
> 
> 
> 
> 
> 
>                    mind.”///
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>                    //
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>                    Depending of the reader. If one is familiar with
>                    DSRC, OBU and RSU
> 
> 
>                    as
> 
> 
> 
> 
> 
> 
> 
> 
>                    defined by FCC will come in mind. As far as I know,
>                    “OBU” and “RSU”
> 
> 
> 
> 
> 
> 
> 
> 
>                    are not registered and could be used for other
>                    definitions
> 
> 
>                    (something
> 
> 
> 
> 
> 
> 
> 
> 
>                    like
> 
> 
> 
> 
> 
> 
> 
> 
>                    “ATM”: Asynchronous Transfer Mode and Automatic
>                    Teller Machine😊).
> 
> 
>                    My
> 
> 
> 
> 
> 
> 
> 
> 
>                    suggestion to the IPWAVE team is to use “OBE and RSE”.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>                    This is my personal view as I donot represent any
>                    involved interest.
> 
> 
> 
> 
> 
> 
> 
> 
>                    If any one has questions, let me know.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>                    Francois Simon
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>                    Lojik Technologies
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>                    -----Original Message-----
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>                    From: its [mailto:its-bounces@ietf.org
>                    <mailto:its-bounces@ietf.org>] On Behalf Of Alexandre
> 
> 
> 
> 
> 
> 
> 
> 
>                    Petrescu
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>                    Sent: Monday, January 29, 2018 10:08 AM
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>                    To:its@ietf.org
>                    <mailto:To%3Aits@ietf.org><mailto:its@ietf.org
>                    <mailto:its@ietf.org>>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>                    Subject: Re: [ipwave] Shepherd review of
> 
> 
> 
> 
> 
> 
> 
> 
>                    draft-ietf-ipwave-ipv6-over-80211ocb-12
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>                    Le 29/01/2018 à 15:52, François Simon a écrit :
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>                        My comments arewithin the text*[Fygs.......]*.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>                    [...]
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>                        In the terminology section, the OBU term is
>                        mentioned to be defined
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>                        outside the IETF. This is fine, but we have to
>                        provide a reference.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>                        And even with that, it would not harm to include
>                        some short
> 
> 
> 
> 
> 
> 
> 
> 
>                        definition
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>                        to provide context. The RSU term is also defined
>                        outside the IETF
> 
> 
> 
> 
>                        and
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>                        there is quite a lot of text provided (I think
>                        the relevant part is
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>                        the last sentence, the one starting with "The
>                        difference between...").
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>                        Both terms should be handled in the same way.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>                        *[Fygs: The**definitions**was issued by the FCC
>                        20 years ago.  I
> 
> 
> 
> 
>                        have
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 





Le 06/02/2018 à 19:04, Dick Roy a écrit :
> ------------------------------------------------------------------------
> 
> *From:*its [mailto:its-bounces@ietf.org] *On Behalf Of *Abdussalam Baryun
> *Sent:* Tuesday, February 6, 2018 9:40 AM
> *To:* Alexandre Petrescu
> *Cc:* François Simon; its
> *Subject:* Re: [ipwave] FW: Shepherd review of 
> draft-ietf-ipwave-ipv6-over-80211ocb-12
> 
> Hi Alex and Francois,
> 
> I don't mind putting any clear definition in terms but should be used in 
> the body consistently within the draft. Also we need to try to make the 
> definition short and to the point. I am not very interested in this 
> IP-xxx, however, I like the terminology used in RFC8200. so we should 
> mention that our IP-units are nodes or routers,
> 
> */[RR] While certainly not an expert on this, I was under the impression 
> any entity on an IP network was a node, and that there are two types of 
> functionality: host and router.  A node can implement host 
> functionality, router functionality, or both. If that’s the case, this 
> ought to be clearly stated somewhere./*

You see, people already say 'Host vs Router' and 'Node vs Router'. 
There are a few IPv6 related RFCs that disagree on it.

Here we say 'IP-OBU' and 'IP-RSU' and 'computer'.

Alex

> 
> */
> RR/*
> 
> in terminology the definition word 'computer' used is not consistent 
> with other ietf RFCs.
> 
> AB
> 
> On Tue, Feb 6, 2018 at 6:47 PM, Alexandre Petrescu 
> <alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>> wrote:
> 
> 
> 
> Le 06/02/2018 à 17:40, François Simon a écrit :
> 
> Mr. Petrescu,
> 
> /“//There are two very relevant terms: IP-OBU and IP-RSU.//”///
> 
> -// IftheWorkingGroupthinksthese terms are relevant, thenso 
> bid.Irespectfully disagree.Furthermore,I have nothing more to add to 
> this discussion;I have provided allUS relevant definitions.
> 
> 
> I thank you for the definitions.
> 
> I propose we go this way:
> 
> Copy the definitions from your emails for DSRCS, and then DSRC and then 
> OBU and RSU in terms of DSRCS and of DSRC.
> 
> But have these definitions (DSRCS, DSRC, OBU and RSU) in an Appendix, 
> not in the Terminology section.
> 
> The Terminology section would list IP-OBU and IP-RSU and refer to the 
> Appendix.
> 
> Alex
> 
> 
> Sincerely,
> 
> Francois Simon
> 
> Lojik Technologies
> 
> -----Original Message-----
> From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com 
> <mailto:alexandre.petrescu@gmail.com>]
> Sent: Tuesday, February 06, 2018 10:41 AM
> To: François Simon <fygsimon@gmail.com <mailto:fygsimon@gmail.com>>
> Cc: its@ietf.org <mailto:its@ietf.org>
> Subject: Re: FW: [ipwave] Shepherd review of 
> draft-ietf-ipwave-ipv6-over-80211ocb-12
> 
> If I add DSRCS, and DSRC, and OBU - it makes for 3 terms only 
> tangentially relevant.
> 
> I find it too much.
> 
> There are two very relevant terms: IP-OBU and IP-RSU.
> 
> We need to have more relevant terms than tangentially relevant terms.
> 
> Le 06/02/2018 à 03:25, François Simon a écrit :
> 
> /"//So, in order to define OBU in terms of DSRCS one has to define
> 
>    first DSRCS, all while caring to avoid loops.  I think it can become
> 
>    too lengthy.//"///
> 
>    -///Dedicated Short-Range Communications////Services (DSRCS)/.-The use
> 
>    of radio techniquesto transfer data over short distancesbetween
> 
>    roadside and mobile
> 
>               units, between mobile units, and betweenportable and mobile
> 
>               units to performoperations related to the improvementof
>    traffic
> 
>               flow, traffic safety,
> 
>               and other intelligent transportationservice applications in a
> 
>               varietyof environments. DSRCS systems mayalso transmit status
> 
>               and instructional
> 
>               messages related to the units involved.[ Ref. 47 CFR90.7 –
> 
>               Definitions]
> 
>    -----Original Message-----
> 
>    From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com
>    <mailto:alexandre.petrescu@gmail.com>]
> 
>    Sent: Monday, February 05, 2018 10:41 AM
> 
>    To: François Simon <fygsimon@gmail.com
>    <mailto:fygsimon@gmail.com><mailto:fygsimon@gmail.com
>    <mailto:fygsimon@gmail.com>>>
> 
>    Cc:its@ietf.org <mailto:Cc%3Aits@ietf.org><mailto:its@ietf.org
>    <mailto:its@ietf.org>>
> 
>    Subject: Re: [ipwave] Shepherd review of
> 
>    draft-ietf-ipwave-ipv6-over-80211ocb-12
> 
>    Le 05/02/2018 à 16:10, François Simon a écrit :
> 
>        /"//Is DSRCS a typo? (correct DSRC).//"///
> 
>        -// No typo. DSRCS stands for “Dedicated Short Range
>        Communication Service”
> 
>    So, in order to define OBU in terms of DSRCS one has to define first
> 
>    DSRCS, all while caring to avoid loops.  I think it can become too
>    lengthy.
> 
>    Alex
> 
>        -----Original Message-----
> 
>        From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com
>        <mailto:alexandre.petrescu@gmail.com>]
> 
>        Sent: Sunday, February 04, 2018 11:08 AM
> 
>        To: François Simon <fygsimon@gmail.com
>        <mailto:fygsimon@gmail.com><mailto:fygsimon@gmail.com
>        <mailto:fygsimon@gmail.com><mailto:fygsimon@gmail.com
>        <mailto:fygsimon@gmail.com><mailto:fygsimon@gmail.com
>        <mailto:fygsimon@gmail.com>>>>
> 
>        Cc:its@ietf.org <mailto:Cc%3Aits@ietf.org><mailto:its@ietf.org
>        <mailto:its@ietf.org>>
> 
>        Subject: Re: [ipwave] Shepherd review of
> 
>        draft-ietf-ipwave-ipv6-over-80211ocb-12
> 
>        I am adding this OBU ref for reference but I have a question:
> 
>        Le 02/02/2018 à 11:23, François Simon a écrit :
> 
>        [...]
> 
>            /On-Board unit (OBU). An On-Board Unit is a DSRCS
>            transceiver that
> 
>            is
> 
>        Is DSRCS a typo? (correct DSRC).
> 
>        Alex
> 
>            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. The OBUs receive and contend
>            for
> 
>            time
> 
>            to transmit on one or more radio frequency (RF) channels. Except
> 
>            where
> 
>            specifically excluded, OBU operation is permitted wherever
>            vehicle
> 
>            operation or human passage is permitted. The OBUs mounted in
> 
>            vehicles
> 
>            are licensed by rule under part 95 of this chapter and
>            communicate
> 
>            with Roadside Units (RSUs) and other OBUs. Portable OBUs are
>            also
> 
>            licensed by rule under part 95 of this chapter. OBU
>            operations in
> 
>            the
> 
>            Unlicensed National Information Infrastructure (UNII) Bands
>            follow
> 
>            the
> 
>            rules in those bands./- [CFR 90.7 - Definitions] - October 2010
> 
>            *IPWAVE Issue***
> 
>            **
> 
>            /“The problem with the FCC definition of OBU is that it has no
> 
>            relationship to IP.  Worse, that FCC definition has no
>            indication
> 
>            that
> 
>            it MAY use IP somehow.  And here we say that all OBUs must
>            use IP.
> 
>            Do
> 
>            you see what I mean?”///
> 
>            //
> 
>            Correct; the OBU has no relationship with IP and is not
>            intended to.
> 
>            IP is a network protocol.  If an On-Board Unit (OBU) device is
> 
>            required to exchange IP, it needs to be dealt in protocol(s)
>            and/or
> 
>            Management in higher layers similar to WAVE within the
>            On-Board Equipment (OBE) .
> 
>            /“Do you think FCC will mind if we use the term OBU in this
>            draft to
> 
>            mean something else?  I, and a colleague, think that FCC
>            would not
> 
>            mind.”///
> 
>            //
> 
>            Depending of the reader. If one is familiar with DSRC, OBU
>            and RSU
> 
>            as
> 
>            defined by FCC will come in mind. As far as I know, “OBU”
>            and “RSU”
> 
>            are not registered and could be used for other definitions
> 
>            (something
> 
>            like
> 
>            “ATM”: Asynchronous Transfer Mode and Automatic Teller
>            Machine😊).
> 
>            My
> 
>            suggestion to the IPWAVE team is to use “OBE and RSE”.
> 
>            This is my personal view as I donot represent any involved
>            interest.
> 
>            If any one has questions, let me know.
> 
>            Francois Simon
> 
>            Lojik Technologies
> 
>            -----Original Message-----
> 
>            From: its [mailto:its-bounces@ietf.org
>            <mailto:its-bounces@ietf.org>] On Behalf Of Alexandre
> 
>            Petrescu
> 
>            Sent: Monday, January 29, 2018 10:08 AM
> 
>            To:its@ietf.org
>            <mailto:To%3Aits@ietf.org><mailto:its@ietf.org
>            <mailto:its@ietf.org>>
> 
>            Subject: Re: [ipwave] Shepherd review of
> 
>            draft-ietf-ipwave-ipv6-over-80211ocb-12
> 
>            Le 29/01/2018 à 15:52, François Simon a écrit :
> 
>                My comments arewithin the text*[Fygs.......]*.
> 
>            [...]
> 
>                In the terminology section, the OBU term is mentioned to
>                be defined
> 
>                outside the IETF. This is fine, but we have to provide a
>                reference.
> 
>                And even with that, it would not harm to include some short
> 
>                definition
> 
>                to provide context. The RSU term is also defined outside
>                the IETF
> 
>                and
> 
>                there is quite a lot of text provided (I think the
>                relevant part is
> 
>                the last sentence, the one starting with "The difference
>                between...").
> 
>                Both terms should be handled in the same way.
> 
>                *[Fygs: The**definitions**was issued by the FCC 20 years
>                ago.  I
> 
>                have
> 



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

--------------134D9DF4215A62C444D401F9-- From nobody Tue Feb 13 02:17:04 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE7E120713 for ; Tue, 13 Feb 2018 02:17:03 -0800 (PST) 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 GfzspnqbBfTJ for ; Tue, 13 Feb 2018 02:17:01 -0800 (PST) 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 7D1E1120047 for ; Tue, 13 Feb 2018 02:17:01 -0800 (PST) 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 w1DAGtba188608; Tue, 13 Feb 2018 11:16:55 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4717120582D; Tue, 13 Feb 2018 11:16:55 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 2C713205829; Tue, 13 Feb 2018 11:16:55 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w1DAGsdD007565; Tue, 13 Feb 2018 11:16:55 +0100 To: dickroy@alum.mit.edu, "'Abdussalam Baryun'" Cc: mrcullen42@gmail.com, "'its'" References: <1506192164.12227.3.camel@it.uc3m.es> <390b03ec-27a6-43e3-3ea1-95715d253980@gmail.com> <97975302-2ab4-d9b9-d825-758bf2371dff@gmail.com> <24809DE2FFDE44A9B11AA5ACB3A0D1BE@SRA6> From: Alexandre Petrescu Message-ID: <45d910cb-7a1e-4e37-12c7-aa8bd4d311bb@gmail.com> Date: Tue, 13 Feb 2018 11:16:54 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <24809DE2FFDE44A9B11AA5ACB3A0D1BE@SRA6> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [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: Tue, 13 Feb 2018 10:17:03 -0000 Le 13/02/2018 à 02:20, Dick Roy a écrit : > FYI ... TPDUs are called segment, NPDUs are packets, MPDUs are frames, and > PPDUs are streams if you care. YEs noted. Alex [...] From nobody Tue Feb 13 02:36:13 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6BF1241F5; Tue, 13 Feb 2018 02:36:13 -0800 (PST) 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 xkIwLW-MjmjJ; Tue, 13 Feb 2018 02:36:11 -0800 (PST) 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 4D5DD120047; Tue, 13 Feb 2018 02:36:11 -0800 (PST) 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 w1DAa9OS044366; Tue, 13 Feb 2018 11:36:09 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 97A0E202AB1; Tue, 13 Feb 2018 11:36:09 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 7A1C2202034; Tue, 13 Feb 2018 11:36:09 +0100 (CET) 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 w1DAa9Ax024326; Tue, 13 Feb 2018 11:36:09 +0100 To: cjbc@it.uc3m.es Cc: draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org, "its@ietf.org" , Russ Housley , "suresh@kaloom.com" References: <1517217856.4315.32.camel@it.uc3m.es> From: Alexandre Petrescu Message-ID: Date: Tue, 13 Feb 2018 11:36:09 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <1517217856.4315.32.camel@it.uc3m.es> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 - Normative text in Ethernet Adaptation Layer 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, 13 Feb 2018 10:36:13 -0000 Hi Carlos, Le 29/01/2018 à 10:24, Carlos Jesús Bernardos Cano a écrit : [...] > - All the text of section 4.2.1 is not normative, but more a report of > what is done today in existing implementations. I propose the following improvement. OLD: > 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. NEW: > The Receiver and Transmitter Address fields in the 802.11 Data > Header MUST 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 MUST be the same as the > value of the Type field in the Ethernet II Header. Do you agree? > Is there any different > there that is specific of 802.11-OCB? This is specific to 802.11 (compared to Ethernet), including 802.11-OCB (compared to Ethernet). Alex From nobody Tue Feb 13 04:15:02 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43FF8124319 for ; Tue, 13 Feb 2018 04:15:00 -0800 (PST) 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 LK03MYYUmPKN for ; Tue, 13 Feb 2018 04:14:57 -0800 (PST) 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 96BA8120454 for ; Tue, 13 Feb 2018 04:14:57 -0800 (PST) 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 w1DCEqxH029387; Tue, 13 Feb 2018 13:14:52 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A10E7205922; Tue, 13 Feb 2018 13:14:52 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 8673620590C; Tue, 13 Feb 2018 13:14:52 +0100 (CET) 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 w1DCEqDP026137; Tue, 13 Feb 2018 13:14:52 +0100 To: dickroy@alum.mit.edu, "'Abdussalam Baryun'" Cc: mrcullen42@gmail.com, "'its'" References: <1506192164.12227.3.camel@it.uc3m.es> <390b03ec-27a6-43e3-3ea1-95715d253980@gmail.com> <97975302-2ab4-d9b9-d825-758bf2371dff@gmail.com> <24809DE2FFDE44A9B11AA5ACB3A0D1BE@SRA6> <45d910cb-7a1e-4e37-12c7-aa8bd4d311bb@gmail.com> From: Alexandre Petrescu Message-ID: Date: Tue, 13 Feb 2018 13:14:52 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <45d910cb-7a1e-4e37-12c7-aa8bd4d311bb@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-08 - *DUs 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, 13 Feb 2018 12:15:00 -0000 SDUs are called Service Data Units, and FL-SDUs are Facility-layer SDUs. Alex Le 13/02/2018 à 11:16, Alexandre Petrescu a écrit : > Le 13/02/2018 à 02:20, Dick Roy a écrit : >> FYI ... TPDUs are called segment, NPDUs are packets, MPDUs are frames, >> and >> PPDUs are streams if you care. > > YEs noted. > > Alex > [...] > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Tue Feb 13 05:21:32 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98D5F127419 for ; Tue, 13 Feb 2018 05:21:30 -0800 (PST) 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=unavailable 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 rd-41LPrbBvm for ; Tue, 13 Feb 2018 05:21:28 -0800 (PST) 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 A7F951205D3 for ; Tue, 13 Feb 2018 05:21:27 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id j199so3865692wmj.2 for ; Tue, 13 Feb 2018 05:21:27 -0800 (PST) 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:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=DPCf2HF35t3jkIeU7QMAgTrWpyO0Ai6ZevNeId7bcaI=; b=uHihMmsCimzMEWmC0Pa4FE66bozg3ht7qX+8y2q7P6hTmWzdQHivljFmLhNF6i4Hlj B9/E7bLw1tQSD2fZuCSwbYlCYgiEz2CFCCTzxlq/M1FJI67Am7BNwisYF92o1/BhA9mR eBTGoPCiZbEj7WRlCBi54JYw69C/oXjV97u+RpNDmA7Z4gKZwvFsaFbrYR07A5XyrqO7 jEqKhF9Z+/zHkjKBCP4jRs6yxNngiVVoTXTIQsiKDJ7615+thhExYQVTdBk40iHxE5eK 5MmnNajKhbj7/UpXiiwnX0kTpG6ndpXzz4nS1qP3CTl9qk3zgGM+FAj1fGDd0p92fd4k 4I4g== 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 :in-reply-to:references:organization:mime-version :content-transfer-encoding; bh=DPCf2HF35t3jkIeU7QMAgTrWpyO0Ai6ZevNeId7bcaI=; b=i/owij9qNALO8Z2OdZ58j0cvgWf6HQWwRI3VZ+i2vbiofPiLITYqonAK2uiOSf7qpB 3UVvAfDg4J/xgm3mo8VXOSwazCwcIpwLTZoYLZHJ5pXmg0LLB/ORcaF4fNiGtPFiN24A ZblWwcsAv0uQL3H2EgRqSkP7E/5X6KevyYQxtipPhie4ThBibDyI3wjyUHodTB/Xhrv2 MPbEN9PD4gLlzm15Kn9oBxhrwFcI73tlFl3vz6ph+sBSr3D0qSWeOFnA2tVG4xqPP62g 08uxZy3EXhXtLDWXE97sLU4KFNxW7ZJOZLcSJ8IgaEbZdWnZlpGwxAa6wehotZ0tUsw2 Y6AQ== X-Gm-Message-State: APf1xPBQxoTAWhMhizotvCRzgniOCCbDcprJdsFsrKjIwYMRLs6k/78V zl9TvedYpWD07q89DfCoCE8QaA== X-Google-Smtp-Source: AH8x226r/RdIbSEwFT8paWwTOsNxqvjkA2p88KagHm18EHsiDI9bm05oiXUgtIrIfpqLLMYMM4rb4w== X-Received: by 10.28.101.196 with SMTP id z187mr1351448wmb.29.1518528086090; Tue, 13 Feb 2018 05:21:26 -0800 (PST) Received: from acorde ([2001:720:410:1010:d681:d7ff:fe28:350b]) by smtp.gmail.com with ESMTPSA id 56sm18659490wrt.23.2018.02.13.05.21.25 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 13 Feb 2018 05:21:25 -0800 (PST) Message-ID: <1518528084.3933.6.camel@it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano Reply-To: cjbc@it.uc3m.es To: Alexandre Petrescu Cc: draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org, "its@ietf.org" , Russ Housley , "suresh@kaloom.com" Date: Tue, 13 Feb 2018 14:21:24 +0100 In-Reply-To: References: <1517217856.4315.32.camel@it.uc3m.es> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.3-1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 - Normative text in Ethernet Adaptation Layer 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, 13 Feb 2018 13:21:31 -0000 Hi Alex, Thanks. That works for me. Please submit a new version, that I can check and then proceed with the next steps in the publication request. Thanks! Carlos On Tue, 2018-02-13 at 11:36 +0100, Alexandre Petrescu wrote: > Hi Carlos, > > Le 29/01/2018 à 10:24, Carlos Jesús Bernardos Cano a écrit : > [...] > > - All the text of section 4.2.1 is not normative, but more a report > > of > > what is done today in existing implementations. > > I propose the following improvement. > > OLD: > > 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. > > NEW: > > The Receiver and Transmitter Address fields in the 802.11 Data > > Header MUST 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 MUST be the same as > > the > > value of the Type field in the Ethernet II Header. > > Do you agree? > > > Is there any different > > there that is specific of 802.11-OCB? > > This is specific to 802.11 (compared to Ethernet), including 802.11- > OCB > (compared to Ethernet). > > Alex From nobody Tue Feb 13 05:38:02 2018 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 4CD6C1204DA; Tue, 13 Feb 2018 05:37:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: its@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151852907524.12902.7884670291401955587@ietfa.amsl.com> Date: Tue, 13 Feb 2018 05:37:55 -0800 Archived-At: Subject: [ipwave] I-D Action: draft-ietf-ipwave-ipv6-over-80211ocb-15.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, 13 Feb 2018 13:37:55 -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 Jerome Haerri Jong-Hyouk Lee Thierry Ernst Filename : draft-ietf-ipwave-ipv6-over-80211ocb-15.txt Pages : 39 Date : 2018-02-13 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. 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-15 https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-15 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 Feb 13 05:39:12 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6B31204DA for ; Tue, 13 Feb 2018 05:39:10 -0800 (PST) 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 7bEdvJGweTlf for ; Tue, 13 Feb 2018 05:39:08 -0800 (PST) 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 BCAFB12E8B0 for ; Tue, 13 Feb 2018 05:39:07 -0800 (PST) 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 w1DDd5W1022646 for ; Tue, 13 Feb 2018 14:39:05 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id DFC9C205AF9 for ; Tue, 13 Feb 2018 14:39:05 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id D560C205AF8 for ; Tue, 13 Feb 2018 14:39:05 +0100 (CET) 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 w1DDd4so018266 for ; Tue, 13 Feb 2018 14:39:05 +0100 References: <151852907551.12902.14126492755582171996.idtracker@ietfa.amsl.com> To: "its@ietf.org" From: Alexandre Petrescu X-Forwarded-Message-Id: <151852907551.12902.14126492755582171996.idtracker@ietfa.amsl.com> Message-ID: <9be5b744-926c-9590-846e-a3b6883d011f@gmail.com> Date: Tue, 13 Feb 2018 14:39:04 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <151852907551.12902.14126492755582171996.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------362AD7AB8E0D4B18099C3137" Content-Language: fr Archived-At: Subject: [ipwave] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-15.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, 13 Feb 2018 13:39:10 -0000 This is a multi-part message in MIME format. --------------362AD7AB8E0D4B18099C3137 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi IPWAVErs, I submitted a new version of the IPv6-over-OCB draft. The changelog is:         Added normative term MUST in two places in section         "Ethernet Adaptation Layer". Alex -------- Message transféré -------- Sujet : New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-15.txt Date : Tue, 13 Feb 2018 05:37:55 -0800 De : internet-drafts@ietf.org Pour : Jerome Haerri , ipwave-chairs@ietf.org, Jerome Haerri , Alexandre Petrescu , Alexandre Petrescu , Nabil Benamar , Thierry Ernst , Jong-Hyouk Lee A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-15.txt has been successfully submitted by Alexandre Petrescu and posted to the IETF repository. Name: draft-ietf-ipwave-ipv6-over-80211ocb Revision: 15 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: 2018-02-13 Group: ipwave Pages: 39 URL: https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-15.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-15 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-15 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-15 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. 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 --------------362AD7AB8E0D4B18099C3137 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi IPWAVErs,

I submitted a new version of the IPv6-over-OCB draft.

The changelog is:

        Added normative term MUST in two places in section
        "Ethernet Adaptation Layer".

Alex



-------- Message transféré --------
Sujet : New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-15.txt
Date : Tue, 13 Feb 2018 05:37:55 -0800
De : internet-drafts@ietf.org
Pour : Jerome Haerri <Jerome.Haerri@eurecom.fr>, ipwave-chairs@ietf.org, Jerome Haerri <jerome.haerri@eurecom.fr>, Alexandre Petrescu <Alexandre.Petrescu@cea.fr>, Alexandre Petrescu <alexandre.petrescu@cea.fr>, Nabil Benamar <n.benamar@est.umi.ac.ma>, Thierry Ernst <thierry.ernst@yogoko.fr>, Jong-Hyouk Lee <jonghyouk@smu.ac.kr> 


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

Name:		draft-ietf-ipwave-ipv6-over-80211ocb
Revision:	15
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:	2018-02-13
Group:		ipwave
Pages:		39
URL:            https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-15.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-15
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-15
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-15

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.

                                                                                  


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
--------------362AD7AB8E0D4B18099C3137-- From nobody Tue Feb 13 05:50:31 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA34127909; Tue, 13 Feb 2018 05:50:29 -0800 (PST) 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 xulb7qDgwh9f; Tue, 13 Feb 2018 05:50:27 -0800 (PST) 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 B239912783A; Tue, 13 Feb 2018 05:50:26 -0800 (PST) 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 w1DDoOTW065640; Tue, 13 Feb 2018 14:50:24 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 726B420161C; Tue, 13 Feb 2018 14:50:24 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 5E0AA201FBD; Tue, 13 Feb 2018 14:50:24 +0100 (CET) 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 w1DDoOlF030689; Tue, 13 Feb 2018 14:50:24 +0100 To: cjbc@it.uc3m.es Cc: draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org, "its@ietf.org" , Russ Housley , "suresh@kaloom.com" References: <1517217856.4315.32.camel@it.uc3m.es> <1518528084.3933.6.camel@it.uc3m.es> From: Alexandre Petrescu Message-ID: Date: Tue, 13 Feb 2018 14:50:24 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <1518528084.3933.6.camel@it.uc3m.es> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 - Normative terms 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, 13 Feb 2018 13:50:30 -0000 Hi Carlos, Thanks for the reply. I submitted a new version for that. There are a few more places in section 4 that could contain normative terms. These places correspond to what implementation does. What do you think about these suggestions? OLD: 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. NEW: 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 MUST fragment. In case there are IP fragments, the field "Sequence number" of the 802.11 Data header containing the IP fragment field MUST be increased. OLD: Non-IP packets such as WAVE Short Message Protocol (WSMP) can be delivered on 802.11-OCB links. Specifications of these packets are NEW: Non-IP packets such as WAVE Short Message Protocol (WSMP) MAY be delivered on 802.11-OCB links. Specifications of these packets are OLD: performing 802.11-to-Ethernet is described in Section 4.2.1. The Ethernet Type code (EtherType) for IPv6 is 0x86DD (hexadecimal 86DD, or otherwise #86DD). NEW: performing 802.11-to-Ethernet is described in Section 4.2.1. The Ethernet Type code (EtherType) for IPv6 MUST be 0x86DD (hexadecimal 86DD, or otherwise #86DD). Alex Le 13/02/2018 à 14:21, Carlos Jesús Bernardos Cano a écrit : > Hi Alex, > > Thanks. That works for me. > > Please submit a new version, that I can check and then proceed with the > next steps in the publication request. > > Thanks! > > Carlos > > On Tue, 2018-02-13 at 11:36 +0100, Alexandre Petrescu wrote: >> Hi Carlos, >> >> Le 29/01/2018 à 10:24, Carlos Jesús Bernardos Cano a écrit : >> [...] >>> - All the text of section 4.2.1 is not normative, but more a report >>> of >>> what is done today in existing implementations. >> >> I propose the following improvement. >> >> OLD: >>> 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. >> >> NEW: >>> The Receiver and Transmitter Address fields in the 802.11 Data >>> Header MUST 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 MUST be the same as >>> the >>> value of the Type field in the Ethernet II Header. >> >> Do you agree? >> >>> Is there any different >>> there that is specific of 802.11-OCB? >> >> This is specific to 802.11 (compared to Ethernet), including 802.11- >> OCB >> (compared to Ethernet). >> >> Alex > From nobody Tue Feb 13 08:58:55 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 416E112D847 for ; Tue, 13 Feb 2018 08:58:54 -0800 (PST) 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] 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 9N-2fnhfzRHz for ; Tue, 13 Feb 2018 08:58:52 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C61A7126CE8 for ; Tue, 13 Feb 2018 08:58:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A64B7300639 for ; Tue, 13 Feb 2018 11:58:50 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Q-X2RuWUDsIp for ; Tue, 13 Feb 2018 11:58:49 -0500 (EST) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id B3123300445; Tue, 13 Feb 2018 11:58:49 -0500 (EST) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_BB765A71-F51F-4C20-BBB0-1259D698A017" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 13 Feb 2018 11:58:50 -0500 In-Reply-To: Cc: "its@ietf.org" To: Alexandre Petrescu References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [ipwave] Use of the RFC2119 terminology in order to become a specification 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, 13 Feb 2018 16:58:54 -0000 --Apple-Mail=_BB765A71-F51F-4C20-BBB0-1259D698A017 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Feb 12, 2018, at 6:41 AM, Alexandre Petrescu = wrote: >=20 > Maybe "DIX" means "Ethernet Adaptation Layer"? DIX =3D Digital Intel Xerox These three companies developed the original 10 Mbit/second Ethernet = specification. The DIX specification always used an EtherType. IEEE = 802.3 changed the specification to be a length or an EtherType. Russ --Apple-Mail=_BB765A71-F51F-4C20-BBB0-1259D698A017 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Feb 12, 2018, at 6:41 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:

Maybe "DIX" means "Ethernet Adaptation = Layer"?

DIX =3D= Digital Intel Xerox

These three companies developed the original 10 Mbit/second = Ethernet specification.  The DIX specification always used an = EtherType.  IEEE 802.3 changed the specification to be a length or = an EtherType.

Russ

= --Apple-Mail=_BB765A71-F51F-4C20-BBB0-1259D698A017-- From nobody Tue Feb 13 12:50:47 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9AC12D88B for ; Tue, 13 Feb 2018 12:50:45 -0800 (PST) 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, 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 PiYeK3OSeYeq for ; Tue, 13 Feb 2018 12:50:43 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8B19127058 for ; Tue, 13 Feb 2018 12:50:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 9BEE3300590 for ; Tue, 13 Feb 2018 15:50:41 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Kn7y_gqQO3xI for ; Tue, 13 Feb 2018 15:50:40 -0500 (EST) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 6983C300445 for ; Tue, 13 Feb 2018 15:50:40 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 13 Feb 2018 15:50:42 -0500 References: <151852907524.12902.7884670291401955587@ietfa.amsl.com> To: its@ietf.org In-Reply-To: <151852907524.12902.7884670291401955587@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [ipwave] I-D Action: draft-ietf-ipwave-ipv6-over-80211ocb-15.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, 13 Feb 2018 20:50:45 -0000 Given the recent thread on the meaning of "WiFi" I scanned through the = document to see if that term is really adding value. I also noticed that "Wi-Fi" is a registered mark. Avoiding an argument = with the owner of that mark seems desirable if the term is not adding a = lot of value in the document. The term appears six times: - The definition in Section 2 that started the thread. - The Figure 3 in Section 4.2.1 (two places). - The note below Figure 3 in Section 4.2.1. - The ChangeLog in Appendix A - The discussion in Appendix C. In most of these places, the sentence or figure is clear without "WiFi." In Appendix C, I think that the sentence could be easily reworded to = avoid the term. I suggest: =46rom the IP perspective, an 802.11-OCB MAC layer offers practically the same interface to IP as 802.11a/b/g/n and 802.3. Based on this quick analysis, I suggest that we remove "WiFi" from the = document. Russ > On Feb 13, 2018, at 8:37 AM, internet-drafts@ietf.org wrote: >=20 >=20 > 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. >=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) > Authors : Alexandre Petrescu > Nabil Benamar > Jerome Haerri > Jong-Hyouk Lee > Thierry Ernst > Filename : draft-ietf-ipwave-ipv6-over-80211ocb-15.txt > Pages : 39 > Date : 2018-02-13 >=20 > 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. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-15 > = https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb= -15 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipwave-ipv6-over-80211ocb-1= 5 >=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 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Tue Feb 13 21:11:51 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 094731242F7 for ; Tue, 13 Feb 2018 21:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 NRqrwFA24zT1 for ; Tue, 13 Feb 2018 21:11:48 -0800 (PST) Received: from mail-ot0-x22e.google.com (mail-ot0-x22e.google.com [IPv6:2607:f8b0:4003:c0f::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 185821200E5 for ; Tue, 13 Feb 2018 21:11:48 -0800 (PST) Received: by mail-ot0-x22e.google.com with SMTP id q12so19361022otg.10 for ; Tue, 13 Feb 2018 21:11:48 -0800 (PST) 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=nuUFH6qdCUtnKFAlDaHrSK6CODNVX8cfelmZvQ19qGY=; b=S89RTBdSs9yoFv/75+7moZVeSqoyF8tEO3c7CxoFL2EqYRTnnEsMcSNiobjxsrxZ8z 67LzYJzCvuoj9G1O3fwGTucnP5caGgoz50OBLjhZT47QTEflP6uTDVPh+yo6YqpcCdiH jnt9HRrlsrjVdUSu/Zf+l4s/dGekvZRtF/GVKHkCDKgda+zjFvWAcIqko4rx++Pk0kGw Hg2nA5FOG0RRxHhbOYMoPcTe2fQXUtSwE/f3AM7ZSrxClQr5BMv9/cMCtBc6fUj6GbXl nkqR5w36NaYhN19mmFpLcVcTwSBTwMqcxy5gmP9dpEmH4xhcjqBQ9mAC+WsBXHxkOEMr WKwA== 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=nuUFH6qdCUtnKFAlDaHrSK6CODNVX8cfelmZvQ19qGY=; b=e1iG+k+XBaLW4go2H4OyIxEH6czh66HxyVrj1JR214yCK9VOP2jI1U5eOwk4vHSiY0 A/+7UnGWVuWL1B2N+2WtnsCR/SzGVhZGdWGov4ZCBJeegRiHX420TFO17JyrgHJT1jiS Px22y4GCI9JsZTdFrASurJtiExSYT6e9kEoPDiHfQVl8RrFXxavr80d5WsLUFwsJOXZU ACLSS9rCxau9zRISNk18v5G4w02tJfI+BKKc+Go1IYNS8VT2FFhZ9jZKVCZmusz6jhZ0 MB3Efp5nwbv7yd23yICWJ1DcXhhJOjzADOJy+5y4Wa1vZqsNvUUPq4ZyS32x2Dudj1QT 0CFw== X-Gm-Message-State: APf1xPANLa1ow58pXQ45RkzTRzYmkcMqZ3xG7LDfohKUTluWeZQ/1oG8 xHTau3AkxYnYvNuXRKUtugSIPk6ratdULIS+MCo= X-Google-Smtp-Source: AH8x226BLkfNwvfT+83NM6c0J861Nyx/4SS4rrs+GVoQsRzmywsjsZfJncuSc6DWUMTZ1jxjwl6OpZG2LIQW2KgcWkY= X-Received: by 10.157.88.45 with SMTP id r45mr2427199oth.111.1518585107424; Tue, 13 Feb 2018 21:11:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.44 with HTTP; Tue, 13 Feb 2018 21:11:47 -0800 (PST) In-Reply-To: <97975302-2ab4-d9b9-d825-758bf2371dff@gmail.com> References: <1506192164.12227.3.camel@it.uc3m.es> <390b03ec-27a6-43e3-3ea1-95715d253980@gmail.com> <97975302-2ab4-d9b9-d825-758bf2371dff@gmail.com> From: Abdussalam Baryun Date: Wed, 14 Feb 2018 07:11:47 +0200 Message-ID: To: Alexandre Petrescu Cc: its , Margaret Cullen Content-Type: multipart/alternative; boundary="f40304355324e3aa2e056525256f" Archived-At: Subject: Re: [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: Wed, 14 Feb 2018 05:11:50 -0000 --f40304355324e3aa2e056525256f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alex, How are you doing, it is always nice to chat with you, as it was a long time from our last meeting in London 89. my comments below, On Mon, Feb 12, 2018 at 12:49 PM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > Abdussalam, > > Let me reply now after a few months. > > Le 05/10/2017 =C3=A0 05:55, Abdussalam Baryun a =C3=A9crit : > >> Hi Alex, >> >> I thank the authors for their hard work and hope we can work together >> to make the doc best. I don't think it is ready for submission. I am >> still reviewing but I give now some comments. >> >> Ethernet is defined by IEEE as IEEE802.3. >> > > I think yes, in principle; Additionally, I am not sure but it may be that > "Ethernet" is a label for 802.3 like "WiFi" is for 802.11. > > However, I think the document should not mention IEEE802.11 protocol >> (some name WiFi) as similar protocol like IEEE802.3 ( Ethernet) >> protocol, one is wireless protocol and the other is wired. >> > > I agree. > > I dont think this ipwave document mentions that 802.11 is similar like > 802.3. Can you point me where you think it does so? I seen that some where or understood that from the draft, but will check it again for you, > > > The transmissions are different, I don't see that they are similar >> even their frames are not similar. So it is not correct in section >> 5.2 mentioned that: >> >> IP packets are transmitted over 802.11-OCB as standard Ethernet >> >> packets. >> > > Well, IP packets _are_ transmitted as standard Ethernet packets, with an > Adaptation Layer. The next phrase says so. This draft is doing transmission, so transmission IMHO does not mean only packing, what will be the way of adaptation to lower layers, and if there is a problem who will take over to adapt. Does this layer see all possibilities? So that are my questions, However, did the authors find a reference to the adaptation layer techniques or not? Best Regards AB > > > IMO even the document RFC2464, should have been (more technical >> focus) referencing the protocol IEEE802.3, instead of naming that may >> change by time. >> > > I agree. > > There is an ongoing work on RFC2464bis (draft-hinden something), that > could be improved with this comment. > > Alex > [...] > --f40304355324e3aa2e056525256f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alex,

How are you doing, = it is always nice to chat with you, as it was a long time from our last=C2= =A0meeting in London 89. =C2=A0my comments below,

On Mon, Feb 12, 2018 at 12:49 PM,= Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:
Abdussalam,

Let me reply now after a few months.

Le 05/10/2017 =C3=A0 05:55, Abdussalam Baryun a =C3=A9crit :
Hi Alex,

I thank the authors for their hard work and hope we can work together
to make the doc best. I don't think it is ready for submission. I am still reviewing but I give now some comments.

Ethernet is defined by IEEE as IEEE802.3.

 I think yes, in principle; Additionally, I am not sure but it may be that &= quot;Ethernet" is a label for 802.3 like "WiFi" is for 802.1= 1.

However, I think the document should not mention IEEE802.11 protocol
(some name WiFi) as similar protocol like IEEE802.3 ( Ethernet)
protocol, one is wireless protocol and the other is wired.

 I agree.

I dont think this ipwave document mentions that 802.11 is similar like 802.= 3.=C2=A0 Can you point me where you think it does so?

=
I seen that some where or understood that from the draft, but wi= ll check it again for you,=C2=A0


The transmissions are different, I don't see that they are similar
even their frames are not similar. So it is not correct in section
5.2 mentioned that:

IP packets are transmitted over 802.11-OCB as standard Ethernet

packets.

 Well, IP packets _are_ transmitted as standard Ethernet packets, with an Ad= aptation Layer.=C2=A0 The next phrase says so.

<= div>This draft is doing transmission, so=C2=A0transmission IMHO does not me= an only packing, what will be the way of adaptation to lower layers, and if= there is a problem who will take over to adapt. Does this layer see all po= ssibilities? So that=C2=A0are my=C2=A0 questions,=C2=A0

However, did the authors find a reference to the adaptation layer tec= hniques or not?

Best Regards

<= div>AB


IMO even the document RFC2464, should have been (more technical
focus) referencing the protocol IEEE802.3, instead of naming that may
change by time.

 I agree.

There is an ongoing work on RFC2464bis (draft-hinden something), that could= be improved with this comment.

Alex
[...]

--f40304355324e3aa2e056525256f-- From nobody Tue Feb 13 22:50:57 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E7F9126579; Tue, 13 Feb 2018 22:50:55 -0800 (PST) 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 Jo8580X1vdYB; Tue, 13 Feb 2018 22:50:52 -0800 (PST) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::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 A54F9124B17; Tue, 13 Feb 2018 22:50:52 -0800 (PST) Received: by mail-oi0-x234.google.com with SMTP id r144so687897oie.6; Tue, 13 Feb 2018 22:50:52 -0800 (PST) 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=podFIBVWI/7jyXKDmI2v0M+vpXVM1nQAuGo8+bhe64M=; b=tTVtNJKS8t17w+UvVhqS9/Ei+OWcTbf87aPM030qlzacPbJh1FZddkVgLETmtDS8BZ LuM+567fzgPGcCenCTMSVWkh+KlXaUlYGIkg9LqG8Q5mo51MdaEgiim32BRUoGR2AIWd 7PWqCfY1RDi//mqgso99o7WNzEwHChoIlw6oNe7zKl8f/PyA11Yth7rqO3PP0y9I+qy6 9bHkfxZpYEUwD+F3vzQ0D+jf+ULbY0/aKYpqLDpsOI6yDi0vJk/iao+08F1ILm39rmt+ LaJI8sOdoXPIrQlu38C7tBFmv8wrYYziPtgbObd3OBUAMaFhLhHoZxt2q+I7hOqXbUbp LcUg== 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=podFIBVWI/7jyXKDmI2v0M+vpXVM1nQAuGo8+bhe64M=; b=nhXryhaOUMTdI2vQqUTtY/Mc+oNf4CEOarcy+kshIty2qO6H8Le4Ob4LntrCA1VEbD pfzXhT144KNN55a50qAeVcN+057lc9djMPgCU/9hb1Nm/FSIldQFh90fTXSJAlNWlyuR QhqHIZrpzSMoEPaXTf1ha3TgmuOlxOOWEoKcl4hLi4cyjYZhu9XlW0EsuICINUX3ujxV O4uuc68HuRy8xzgeeDEh3fNdITJ3qDfsuqFhnxZcdfpPJFYft53qPxwew9rclDICX4PZ MVcWSYMnp2zowgqHrAZN5bP7TgIoIu0L6JkIT21mrOj/V1VzLveC8F9TqEgiQIF04zJC Apdw== X-Gm-Message-State: APf1xPAP/I+FV9PVwFB+VWgkGlVIi5W5Q69gLSEeGJn1Vny14c8ZIvnL NgzxknNLyFW8zk/34R+s3PjwM3nO8tnMxyFz53U= X-Google-Smtp-Source: AH8x2245tCWt20JXjS5O5KZzM4PgNqrEhjBBM9UG1Dx8d+QLUBCZq5M7H21KzFgdb2tpN9VRng5YDQ8O/hRxdSu6liM= X-Received: by 10.202.16.12 with SMTP id 12mr2588483oiq.159.1518591052002; Tue, 13 Feb 2018 22:50:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.44 with HTTP; Tue, 13 Feb 2018 22:50:51 -0800 (PST) In-Reply-To: <9be5b744-926c-9590-846e-a3b6883d011f@gmail.com> References: <151852907551.12902.14126492755582171996.idtracker@ietfa.amsl.com> <9be5b744-926c-9590-846e-a3b6883d011f@gmail.com> From: Abdussalam Baryun Date: Wed, 14 Feb 2018 08:50:51 +0200 Message-ID: To: Alexandre Petrescu Cc: "its@ietf.org" , draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org, ipwave-chairs@ietf.org Content-Type: multipart/alternative; boundary="f4f5e808e3d436ba68056526884d" Archived-At: Subject: Re: [ipwave] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-15.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, 14 Feb 2018 06:50:55 -0000 --f4f5e808e3d436ba68056526884d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alex, There was an update of 14, nice changes but not discussed, why was not mentioned/discussed on the list, please help, You know some times authors or participants discuss off line and they forget they were off-line, so this is a reminder :-) Thaking you, AB On Tue, Feb 13, 2018 at 3:39 PM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > Hi IPWAVErs, > > I submitted a new version of the IPv6-over-OCB draft. > > The changelog is: > > Added normative term MUST in two places in section > "Ethernet Adaptation Layer". > > Alex > > > -------- Message transf=C3=A9r=C3=A9 -------- > Sujet : New Version Notification for draft-ietf-ipwave-ipv6-over- > 80211ocb-15.txt > Date : Tue, 13 Feb 2018 05:37:55 -0800 > De : internet-drafts@ietf.org > Pour : Jerome Haerri , > ipwave-chairs@ietf.org, Jerome Haerri > , Alexandre Petrescu > , Alexandre Petrescu > , Nabil Benamar > , Thierry Ernst > , Jong-Hyouk Lee > > > A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-15.txt > has been successfully submitted by Alexandre Petrescu and posted to the > IETF repository. > > Name: draft-ietf-ipwave-ipv6-over-80211ocb > Revision: 15 > 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: 2018-02-13 > Group: ipwave > Pages: 39 > URL: https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ip= v6-over-80211ocb-15.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-o= ver-80211ocb/ > Htmlized: https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-8= 0211ocb-15 > Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-i= pv6-over-80211ocb-15 > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipwave-ipv= 6-over-80211ocb-15 > > 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. > > > > > Please note that it may take a couple of minutes from the time of submiss= ion > 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 > > --f4f5e808e3d436ba68056526884d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alex,

There was an update= of 14, nice changes but not discussed, why was not mentioned/discussed on = the list, please help,

You know some times authors= or participants discuss off line and they forget they were off-line, so th= is is a reminder :-)

Thaking you,

AB

On Tue, Feb 13, 2018 at 3:39 PM, Alexandre Petrescu <alex= andre.petrescu@gmail.com> wrote:
=20 =20 =20

Hi IPWAVErs,

I submitted a new version of the IPv6-over-OCB draft.

The changelog is:

=C2=A0=C2=A0=C2=A0 =C2= =A0=C2=A0=C2=A0 Added normative term MUST in two places in section
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 "Ethernet Adaptation L= ayer".

Alex



-------- Message transf=C3=A9r=C3=A9 --------
Sujet=C2=A0: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-15.txt
Date=C2=A0: Tue, 13 Feb 2018 05:37:55 -0800
De=C2=A0: internet-drafts= @ietf.org
Pour=C2=A0: Jerome Haerri <= Jerome.Haerri@eurecom.fr>, ipwave-chairs@ietf.= org, Jerome Haerri <jerome.haerri@eu= recom.fr>, Alexandre Petrescu <Alexandre.Petre= scu@cea.fr>, Alexandre Petrescu <alexandre.petre= scu@cea.fr>, Nabil Benamar <n.benamar@est.umi= .ac.ma>, Thierry Ernst <thierry.ernst@yog= oko.fr>, Jong-Hyouk Lee <jonghyouk@smu.ac.kr&g= t; 


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

Name:		draft-ietf-ipwave-ipv6-over-80211ocb
Revision:	15
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:	2018-02-13
Group:		ipwave
Pages:		39
URL:            https://www.ietf.org/internet-drafts/dr=
aft-ietf-ipwave-ipv6-over-80211ocb-15.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-ipwav=
e-ipv6-over-80211ocb/
Htmlized:       https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-o=
ver-80211ocb-15
Htmlized:       https://datatracker.ietf.org/doc/html/draf=
t-ietf-ipwave-ipv6-over-80211ocb-15
Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-ie=
tf-ipwave-ipv6-over-80211ocb-15

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&q=
uot;)
   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


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

The IETF Secretariat

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


--f4f5e808e3d436ba68056526884d-- From nobody Tue Feb 13 23:23:56 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81D73126579 for ; Tue, 13 Feb 2018 23:23:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 FQuj5AauFjQI for ; Tue, 13 Feb 2018 23:23:52 -0800 (PST) Received: from mail-ot0-x236.google.com (mail-ot0-x236.google.com [IPv6:2607:f8b0:4003:c0f::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70E871205F0 for ; Tue, 13 Feb 2018 23:23:52 -0800 (PST) Received: by mail-ot0-x236.google.com with SMTP id m20so19588634otf.3 for ; Tue, 13 Feb 2018 23:23:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=WhxLmPX8fZbZuhbk3D4M+X1MHp+sQFEBqZKj84fxTXE=; b=bsdpbh7TY3elashNvSyGq02Xinzpyy4jcMhz/PhNiH4chE52vhdTd6ObHixKUf+aDN fOkKVLC0O6+Jkfkn5UlV21iTTKmsX3rxGJKyMHI5Z2nseZ33gKB2KpVUrLrOqCoae8Wa NwSVRGVgRru8dEyEPsPlA7eS/Cg++2O9ZOllhNchO7Nj6znldgDjmKp9Y7Laz5bcKqlU sRe3fip5tsWCaKucVbkUeIQIeAf89DY4vfReUuqcIe/ASwaX38lQ322cp66ptfBQ3aR/ TMX8jfs9pbzsVsOK2jejQA4mhxXc/gF/jUDjJI+gjLD41zkJYEwrEIf2wSx9bEtE4uZw Xeyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=WhxLmPX8fZbZuhbk3D4M+X1MHp+sQFEBqZKj84fxTXE=; b=aZhVk5Ik6NTuAFO+ZT82X2I1w4yEVjoS7q8Kso4d81w2SjMZfmrWGHRhPR4cRucLFQ PZF36h9Bq+0Fu3D3v/CFl6M88+Drw1trkfNlnQQ4Ohcmk3qFxRwFgh3lJnQZRr/2d9oW XlC80w8zX52faClAd/LW/QOSFupZCz2RRWxzSn9OwYF9Un6oBVQ5uu2tQVa+Y6AX46jH 8OnSncX4Im7FmeuN+mCip4oKI99pr9UQVPdOPJ3lKDquRIUkXlCzUo5Kgx4TwcAk3Xot XKEHiYCUkqDA2DECN09nkCaQBY0rVOQqHttF5QHDMJsw3FJ6T7hkB8+wgAlkTubQ2tzC L0bg== X-Gm-Message-State: APf1xPAi7MGkejoS5HMr0rCMwk+x3YCe7KF4XYbCe+94dO39sOydxXy4 F/vv9z5zbqsOw/kwA+SbF3An3uEaHUrTBGhr3U0NqQ== X-Google-Smtp-Source: AH8x227ZgzGyAXmpjAZvgczfwR6nx/3I2sr3GWF6tbGhHRsAVbJB7mYQOBGmIBVLaw2/xDYfTAICq3x4AvnpnpIn0FQ= X-Received: by 10.157.44.74 with SMTP id f68mr2575994otb.323.1518593031867; Tue, 13 Feb 2018 23:23:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.44 with HTTP; Tue, 13 Feb 2018 23:23:51 -0800 (PST) From: Abdussalam Baryun Date: Wed, 14 Feb 2018 09:23:51 +0200 Message-ID: To: Alexandre Petrescu Cc: its , Margaret Cullen Content-Type: multipart/alternative; boundary="94eb2c11f156391612056526feeb" Archived-At: Subject: [ipwave] Why ieee802.11 ocb Similar to Ethernet layers? do we mean MAC (was Re: 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: Wed, 14 Feb 2018 07:23:54 -0000 --94eb2c11f156391612056526feeb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 14, 2018 at 7:11 AM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > Hi Alex, > > How are you doing, it is always nice to chat with you, as it was a long > time from our last meeting in London 89. my comments below, > > On Mon, Feb 12, 2018 at 12:49 PM, Alexandre Petrescu < > alexandre.petrescu@gmail.com> wrote: > >> Abdussalam, >> >> Let me reply now after a few months. >> >> Le 05/10/2017 =C3=A0 05:55, Abdussalam Baryun a =C3=A9crit : >> >>> Hi Alex, >>> >>> I thank the authors for their hard work and hope we can work together >>> to make the doc best. I don't think it is ready for submission. I am >>> still reviewing but I give now some comments. >>> >>> Ethernet is defined by IEEE as IEEE802.3. >>> >> >> I think yes, in principle; Additionally, I am not sure but it may be tha= t >> "Ethernet" is a label for 802.3 like "WiFi" is for 802.11. >> >> However, I think the document should not mention IEEE802.11 protocol >>> (some name WiFi) as similar protocol like IEEE802.3 ( Ethernet) >>> protocol, one is wireless protocol and the other is wired. >>> >> >> I agree. >> >> I dont think this ipwave document mentions that 802.11 is similar like >> 802.3. Can you point me where you think it does so? > > In the Abstract in draft-12 and maybe in 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. So why did WG choose that in the first place? I understand that IEEE802.11 OCB has different frame or activity or diff MAC, which is Outside Context of BSS. It is not coordinated with other IEEE802.11. AB > > I seen that some where or understood that from the draft, but will check > it again for you, > >> >> >> The transmissions are different, I don't see that they are similar >>> even their frames are not similar. So it is not correct in section >>> 5.2 mentioned that: >>> >>> IP packets are transmitted over 802.11-OCB as standard Ethernet >>> >>> packets. >>> >> >> Well, IP packets _are_ transmitted as standard Ethernet packets, with an >> Adaptation Layer. The next phrase says so. > > > This draft is doing transmission, so transmission IMHO does not mean only > packing, what will be the way of adaptation to lower layers, and if there > is a problem who will take over to adapt. Does this layer see all > possibilities? So that are my questions, > > However, did the authors find a reference to the adaptation layer > techniques or not? > > Best Regards > > AB > >> >> >> IMO even the document RFC2464, should have been (more technical >>> focus) referencing the protocol IEEE802.3, instead of naming that may >>> change by time. >>> >> >> I agree. >> >> There is an ongoing work on RFC2464bis (draft-hinden something), that >> could be improved with this comment. >> >> Alex >> [...] >> > > --94eb2c11f156391612056526feeb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Feb 14, 2018 at 7:11 AM, Abdussalam Baryun &l= t;abdussala= mbaryun@gmail.com> wrote:
Hi Alex,

How are you doing, it is always ni= ce to chat with you, as it was a long time from our last=C2=A0meeting in Lo= ndon 89. =C2=A0my comments below,

<= div class=3D"gmail_quote">On Mon, Feb 12, 2018 at 12:49 PM, Alexandre= Petrescu <alexandre.petrescu@gmail.com> wrote:
Abdussalam,

Let me reply now after a few months.

Le 05/10/2017 =C3=A0 05:55, Abdussalam Baryun a =C3=A9crit :
Hi Alex,

I thank the authors for their hard work and hope we can work together
to make the doc best. I don't think it is ready for submission. I am still reviewing but I give now some comments.

Ethernet is defined by IEEE as IEEE802.3.

 I think yes, in principle; Additionally, I am not sure but it may be that &= quot;Ethernet" is a label for 802.3 like "WiFi" is for 802.1= 1.

However, I think the document should not mention IEEE802.11 protocol
(some name WiFi) as similar protocol like IEEE802.3 ( Ethernet)
protocol, one is wireless protocol and the other is wired.

 I agree.

I dont think this ipwave document mentions that 802.11 is similar like 802.= 3.=C2=A0 Can you point me where you think it does so?

In the Abstract in draft-1= 2 and maybe in others:

This document describes the= se parameters for IPv6 and IEEE
=C2=A0=C2=A0 802.11-OCB networks; it por= trays the layering of IPv6 on 802.11-OCB
=C2=A0=C2=A0 similarly to other= known 802.11 and Ethernet layers - by using an
=C2=A0=C2=A0 Ethernet Ad= aptation Layer.

So w= hy did WG choose that in the first place? I understand that IEEE802.11 OCB = has=C2=A0different frame or activity or diff MAC, which is Outside Context = of BSS. It is not coordinated with other IEEE802.11.

AB
=C2=A0

I= seen that some where or understood that from the draft, but will check it = again for you,=C2=A0


The transmissions are different, I don't see that they are similar
even their frames are not similar. So it is not correct in section
5.2 mentioned that:

IP packets are transmitted over 802.11-OCB as standard Ethernet

packets.

 Well, IP packets _are_ transmitted as standard Ethernet packets, with an Ad= aptation Layer.=C2=A0 The next phrase says so.

<= /span>
This draft is doing transmission, so=C2=A0transmission IMHO does= not mean only packing, what will be the way of adaptation to lower layers,= and if there is a problem who will take over to adapt. Does this layer see= all possibilities? So that=C2=A0are my=C2=A0 questions,=C2=A0
However, did the authors find a reference to the adaptation la= yer techniques or not?

Best Regards

AB


IMO even the document RFC2464, should have been (more technical
focus) referencing the protocol IEEE802.3, instead of naming that may
change by time.

 I agree.

There is an ongoing work on RFC2464bis (draft-hinden something), that could= be improved with this comment.

Alex
[...]


--94eb2c11f156391612056526feeb-- From nobody Tue Feb 13 23:27:43 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA213126D73 for ; Tue, 13 Feb 2018 23:27:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_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 UkNyLKBI-WAf for ; Tue, 13 Feb 2018 23:27:40 -0800 (PST) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 769B1127275 for ; Tue, 13 Feb 2018 23:27:39 -0800 (PST) Received: by mail-oi0-x235.google.com with SMTP id 24so15833918oij.3 for ; Tue, 13 Feb 2018 23:27:39 -0800 (PST) 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=mE74+1A/feFRPeFxjeSRXEtskFjTg7g/yyt4jX6L7/w=; b=SZCNp9gyfJSdGb+bZPW1opEISH3cmU6/7vbPQmD0k2J0eZGAim/dNHFpYzqMA/myj3 IdIR1cNWYIhbjI6pX9ZykvOQjN2TGakJbsRvChLILp5SPQkQe42fAhCsfjTHInsx7iLj rlMbx3BHvbWbQnV7DIYJm0ZL5xrzEsegEEOEDItKLeLc7jsHt1q8FDVu01VJYo+ldu84 iJJ5bDvm5PfdCoGtpAwV1LIRxEIT1el0dzE6gtEGi7jHTrmd08xKjYIZxufsKAIeGRJH DdIW9dXnBPy1xHfLCIFsA0QMOn9eRWQgcXOh2Mzh3PjOxmuXrW3Cn6Mzvuvs05VM4Z70 f3MQ== 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=mE74+1A/feFRPeFxjeSRXEtskFjTg7g/yyt4jX6L7/w=; b=k4SNSGOglAdCvEpJ+qVX9hjBFmtlBB7ytdxrCLRmJmFSnq2EFEtY/sKKM8aKtr6LkS GrZy2Q1xMOvTjbSDcqlQPQI6RNrWJdxUKyC6qcpO2DUFe+/jTmkBw1Be5o+LwIF4WWWM EDVgmshYPBCZYFDhD+C7VgDX6VIH2DGH5zQoRipbmirNI3HuGOtKSB+7Md+omihDYKWg puCW2pCDBK5bovLk7A4OTE9ukB7m+1PPX1rO36lwNAMIH9myqS8IO7gsfGhl6PyKkBip 2J91di+/97kLFsmX0sWMVMNuaHWgkt6kq2Vb2bN5xb81l2MDyeqYmqZpuaNH2Uz9S31g FlGg== X-Gm-Message-State: APf1xPBVfEhAWc9hUDH5pIiApxCylJfPFVkRmDYJCXjT1hue3A+YXlTU 3yHiu1K3r5FCQVzHsnrVzn6fM7RJdTr2nVs9wjc= X-Google-Smtp-Source: AH8x227soi5iJ44nZvsA7GiZSXeOq3kb+oq0azuFvCOVxS7XhSF01PVKY5kf2uUuJ05QCgCs64vOl8sMtQgCtS5n67k= X-Received: by 10.202.225.133 with SMTP id y127mr2682219oig.217.1518593258502; Tue, 13 Feb 2018 23:27:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.44 with HTTP; Tue, 13 Feb 2018 23:27:38 -0800 (PST) In-Reply-To: References: <151852907524.12902.7884670291401955587@ietfa.amsl.com> From: Abdussalam Baryun Date: Wed, 14 Feb 2018 09:27:38 +0200 Message-ID: To: Russ Housley Cc: its Content-Type: multipart/alternative; boundary="001a113d6356bb40590565270b02" Archived-At: Subject: Re: [ipwave] I-D Action: draft-ietf-ipwave-ipv6-over-80211ocb-15.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, 14 Feb 2018 07:27:43 -0000 --001a113d6356bb40590565270b02 Content-Type: text/plain; charset="UTF-8" 13, 2018 at 10:50 PM, Russ Housley wrote: > Given the recent thread on the meaning of "WiFi" I scanned through the > document to see if that term is really adding value. > > I also noticed that "Wi-Fi" is a registered mark. Avoiding an argument > with the owner of that mark seems desirable if the term is not adding a lot > of value in the document. > > The term appears six times: > - The definition in Section 2 that started the thread. > - The Figure 3 in Section 4.2.1 (two places). > - The note below Figure 3 in Section 4.2.1. > - The ChangeLog in Appendix A > - The discussion in Appendix C. > > In most of these places, the sentence or figure is clear without "WiFi." > Yes, no problem, I never liked these terms of other SDOs, it is better to stick with only one term they use IEEE802.11a/b. > > In Appendix C, I think that the sentence could be easily reworded to avoid > the term. I suggest: > > From the IP perspective, an 802.11-OCB MAC layer > offers practically the same interface to IP as 802.11a/b/g/n > and 802.3. > that suggest that the IP interface has the similar BSS service, but we are doing Outside that Context which is OCB, in other words OCB mode is not the operation of BSS and even the frame is different, our physical network infrastructure is not the same and services also, no more LAN services. We may define a special interface for IPWAVE in the draft. Does WG think we will have same LLC for all the MAC protocols you defined above including Ieee802.1obc? We don't forget that many SDOs are working on this WAVE network architecture, so hopefully we adapt our IPv6 to such OCB, Thanks, AB > > Based on this quick analysis, I suggest that we remove "WiFi" from the > document. > > Russ > > > > > On Feb 13, 2018, at 8:37 AM, internet-drafts@ietf.org wrote: > > > > > > 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 > > Jerome Haerri > > Jong-Hyouk Lee > > Thierry Ernst > > Filename : draft-ietf-ipwave-ipv6-over-80211ocb-15.txt > > Pages : 39 > > Date : 2018-02-13 > > > > 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. > > > > > > 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-15 > > https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6 > -over-80211ocb-15 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-ove > r-80211ocb-15 > > > > > > 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/ > > > > _______________________________________________ > > 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 > --001a113d6356bb40590565270b02 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

=

13, 2= 018 at 10:50 PM, Russ Housley <housley@vigilsec.com> wrot= e:
Given the recent thread on the meaning of &quo= t;WiFi" I scanned through the document to see if that term is really a= dding value.

I also noticed that "Wi-Fi" is a registered mark.=C2=A0 =C2=A0Avo= iding an argument with the owner of that mark seems desirable if the term i= s not adding a lot of value in the document.

The term appears six times:
=C2=A0- The definition in Section 2 that started the thread.
=C2=A0- The Figure 3 in Section 4.2.1 (two places).
=C2=A0- The note below Figure 3 in Section 4.2.1.
=C2=A0- The ChangeLog in Appendix A
=C2=A0- The discussion in Appendix C.

In most of these places, the sentence or figure is clear without "WiFi= ."

Yes, no problem, I never liked these terms of=C2=A0other SDOs,= it is better to stick with only one term they use IEEE802.11a/b.

In Appendix C, I think that the sentence could be easily reworded to avoid = the term.=C2=A0 I suggest:

=C2=A0 =C2=A0From the IP perspective, an 802.11-OCB MAC layer
=C2=A0 =C2=A0offers practically the same interface to IP as 802.11a/b/g/n =C2=A0 =C2=A0and 802.3.

that=C2=A0=C2=A0suggest that the IP interface = has the similar BSS service, but we are doing Outside that Context which is= OCB, in other words OCB mode is not the operation of BSS and even the fram= e=C2=A0is different, our physical network infrastructure is not the same an= d services also, no more LAN services.

=
We may define a special interface for IPWA= VE in the draft. Does WG=C2=A0think we will have same LLC for all the MAC p= rotocols you defined above including Ieee802.1obc?

We don't forget that many = SDOs are working on this WAVE network architecture, so hopefully we adapt o= ur IPv6 to such OCB,

Thanks,
AB
=C2=A0

Based on this quick analysis, I suggest that we remove "WiFi" fro= m the document.

Russ



> On Feb 13, 2018, at 8:37 AM, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the IP Wireless Access in Vehicular Envir= onments WG of the IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mo= de Outside the Context of a Basic Service Set (IPv6-over-80211-OCB)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: = Alexandre Petrescu
>=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 Nabil Benamar
>=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 Jerome Haerri
>=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 Jong-Hyouk Lee
>=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 Thierry Ernst
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-ipwave-ipv6-over-80211ocb-15.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 39
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2018-02-13
>
> Abstract:
>=C2=A0 =C2=A0In order to transmit IPv6 packets on IEEE 802.11 networks = running
>=C2=A0 =C2=A0outside the context of a basic service set (OCB, earlier &= quot;802.11p")
>=C2=A0 =C2=A0there is a need to define a few parameters such as the sup= ported
>=C2=A0 =C2=A0Maximum Transmission Unit size on the 802.11-OCB link, the= header
>=C2=A0 =C2=A0format preceding the IPv6 header, the Type value within it= , and
>=C2=A0 =C2=A0others.=C2=A0 This document describes these parameters for= IPv6 and IEEE
>=C2=A0 =C2=A0802.11-OCB networks; it portrays the layering of IPv6 on 8= 02.11-OCB
>=C2=A0 =C2=A0similarly to other known 802.11 and Ethernet layers - by u= sing an
>=C2=A0 =C2=A0Ethernet Adaptation Layer.
>
>
> 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-15
> https://datatracke= r.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-15 >
> A diff from the previous version is available at:
> https://www.ietf.org= /rfcdiff?url2=3Ddraft-ietf-ipwave-ipv6-over-80211ocb-15
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> 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/
>
> _______________________________________________
> 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

--001a113d6356bb40590565270b02-- From nobody Tue Feb 13 23:54:05 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90742126C26 for ; Tue, 13 Feb 2018 23:54:03 -0800 (PST) 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 9V7DEO1xVai3 for ; Tue, 13 Feb 2018 23:54:01 -0800 (PST) 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 988FA1205F0 for ; Tue, 13 Feb 2018 23:54:01 -0800 (PST) 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 w1E7ruKv012496; Wed, 14 Feb 2018 08:53:56 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 21C28202508; Wed, 14 Feb 2018 08:53:56 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 0DB20200C53; Wed, 14 Feb 2018 08:53:56 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w1E7rtwb026480; Wed, 14 Feb 2018 08:53:55 +0100 To: dickroy@alum.mit.edu, "'Abdussalam Baryun'" Cc: mrcullen42@gmail.com, "'its'" References: <1506192164.12227.3.camel@it.uc3m.es> <390b03ec-27a6-43e3-3ea1-95715d253980@gmail.com> <97975302-2ab4-d9b9-d825-758bf2371dff@gmail.com> <24809DE2FFDE44A9B11AA5ACB3A0D1BE@SRA6> <45d910cb-7a1e-4e37-12c7-aa8bd4d311bb@gmail.com> <79AE367CE5524ECF9E35CBFC5494498D@SRA6> From: Alexandre Petrescu Message-ID: Date: Wed, 14 Feb 2018 08:53:55 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <79AE367CE5524ECF9E35CBFC5494498D@SRA6> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-08 - *DUs 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, 14 Feb 2018 07:54:03 -0000 It is worth writing a terminology draft about *DUs, maybe it will get the terms to be more used. Alex Le 13/02/2018 à 18:51, Dick Roy a écrit : > > > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu > Sent: Tuesday, February 13, 2018 4:15 AM > To: dickroy@alum.mit.edu; 'Abdussalam Baryun' > Cc: mrcullen42@gmail.com; 'its' > Subject: Re: [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-08 - > *DUs > > SDUs are called Service Data Units, and FL-SDUs are Facility-layer SDUs. > [RR] Yes, and TPDUs are NSDUs, NPDUs are MSDUs, etc.. > > Alex > > Le 13/02/2018 à 11:16, Alexandre Petrescu a écrit : >> Le 13/02/2018 à 02:20, Dick Roy a écrit : >>> FYI ... TPDUs are called segment, NPDUs are packets, MPDUs are frames, >>> and >>> PPDUs are streams if you care. >> >> YEs noted. >> >> 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 Tue Feb 13 23:59:37 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34BF9126579 for ; Tue, 13 Feb 2018 23:59:36 -0800 (PST) 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 6yI2DCMcGCeE for ; Tue, 13 Feb 2018 23:59:34 -0800 (PST) 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 A61A51205F0 for ; Tue, 13 Feb 2018 23:59:33 -0800 (PST) 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 w1E7xW5Q014065 for ; Wed, 14 Feb 2018 08:59:32 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0FAFD20107E for ; Wed, 14 Feb 2018 08:59:32 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 057CE200803 for ; Wed, 14 Feb 2018 08:59:32 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w1E7xV3T029568 for ; Wed, 14 Feb 2018 08:59:31 +0100 To: its@ietf.org References: <151852907524.12902.7884670291401955587@ietfa.amsl.com> From: Alexandre Petrescu Message-ID: <7ea2f63b-d90c-891d-909f-51c9cfcc2c80@gmail.com> Date: Wed, 14 Feb 2018 08:59:31 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.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] I-D Action: draft-ietf-ipwave-ipv6-over-80211ocb-15.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, 14 Feb 2018 07:59:36 -0000 Abdussalam, Let me clarify. Le 14/02/2018 à 08:27, Abdussalam Baryun a écrit : > > > 13, 2018 at 10:50 PM, Russ Housley > wrote: > > Given the recent thread on the meaning of "WiFi" I scanned through > the document to see if that term is really adding value. > > I also noticed that "Wi-Fi" is a registered mark. Avoiding an > argument with the owner of that mark seems desirable if the term is > not adding a lot of value in the document. > > The term appears six times: - The definition in Section 2 that > started the thread. - The Figure 3 in Section 4.2.1 (two places). - > The note below Figure 3 in Section 4.2.1. - The ChangeLog in Appendix > A - The discussion in Appendix C. > > In most of these places, the sentence or figure is clear without > "WiFi." > > > Yes, no problem, I never liked these terms of other SDOs, it is > better to stick with only one term they use IEEE802.11a/b. > > > In Appendix C, I think that the sentence could be easily reworded to > avoid the term. I suggest: > > From the IP perspective, an 802.11-OCB MAC layer offers practically > the same interface to IP as 802.11a/b/g/n and 802.3. > > > that suggest that the IP interface has the similar BSS service, But no, because the IP interface does not use anything from a BSS service anyways. For example, the ESSID name (the 'network name') is not used by IP headers. Or maybe I dont know what do yo u mean by BSS service. > but we are doing Outside that Context which is OCB, YEs. > in other words > OCB mode is not the operation of BSS Right. > and even the frame is different, No. The 802.11 OCB frame is the same as 802.11. But I agree that the 802.11 frame is different than 802.3. Alex > our physical network infrastructure is not the same and services > also, no more LAN services. > > We may define a special interface for IPWAVE in the draft. Does WG > think we will have same LLC for all the MAC protocols you defined > above including Ieee802.1obc? > > We don't forget that many SDOs are working on this WAVE network > architecture, so hopefully we adapt our IPv6 to such OCB, > > Thanks, AB > > > Based on this quick analysis, I suggest that we remove "WiFi" from > the document. > > Russ > > > >> On Feb 13, 2018, at 8:37 AM, internet-drafts@ietf.org > wrote: >> >> >> 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 Jerome Haerri >> Jong-Hyouk Lee Thierry Ernst Filename : >> draft-ietf-ipwave-ipv6-over-80211ocb-15.txt Pages : 39 >> Date : 2018-02-13 >> >> 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. >> >> >> 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-15 > > > > > https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-15 > > >> >> A diff from the previous version is available at: >> > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-15 > > >> >> >> 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/ > >> >> _______________________________________________ its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its > > > _______________________________________________ its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > > > > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > From nobody Wed Feb 14 00:07:22 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1AE3126B6D; Wed, 14 Feb 2018 00:07:21 -0800 (PST) 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 pvi8BsX_xOfs; Wed, 14 Feb 2018 00:07:19 -0800 (PST) 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 5A204126C26; Wed, 14 Feb 2018 00:07:19 -0800 (PST) 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 w1E87GUp065473; Wed, 14 Feb 2018 09:07:16 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id AE3302032A7; Wed, 14 Feb 2018 09:07:16 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A3208202782; Wed, 14 Feb 2018 09:07:16 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w1E87GSA004645; Wed, 14 Feb 2018 09:07:16 +0100 To: Abdussalam Baryun Cc: "its@ietf.org" , draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org, ipwave-chairs@ietf.org References: <151852907551.12902.14126492755582171996.idtracker@ietfa.amsl.com> <9be5b744-926c-9590-846e-a3b6883d011f@gmail.com> From: Alexandre Petrescu Message-ID: <7b9602d4-138e-5f25-ef25-a4a72045c916@gmail.com> Date: Wed, 14 Feb 2018 09:07:16 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.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] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-15.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, 14 Feb 2018 08:07:22 -0000 Abdussalam, Le 14/02/2018 à 07:50, Abdussalam Baryun a écrit : > Hi Alex, > > There was an update of 14, nice changes but not discussed, why was > not mentioned/discussed on the list, please help, The ChangeLog entry for the update to 14 from 13 is the following: > o Created a new Appendix titled "Extra Terminology" that contains > terms DSRC, DSRCS, OBU, RSU as defined outside IETF. Some of them > are used in the main Terminology section. > > o Added two paragraphs explaining that ND and Mobile IPv6 have > problems working over 802.11 OCB, yet their adaptations is not > specified in this document. The first item was discussed publicly with François Simon and Carlos. See the archives on February 2nd, 2018; more precisely: https://mailarchive.ietf.org/arch/msg/its/CCAKjtbjWbSnTJ0-Co-93xLCbSg/?qid=00ca1fe68287382a7d9e0100555aea11 The second item was discussed publicly with Carlos, as part of the shepherd review. See the archives on January 29th, 2018; more precisely: https://mailarchive.ietf.org/arch/msg/its/XTQzTDc3VuiNWOKtIBiFmL_6cio/?qid=00ca1fe68287382a7d9e0100555aea11 > You know some times authors or participants discuss off line and they > forget they were off-line, so this is a reminder :-) Rest assured, off-line discussion with subsequent update of this document is not the case here. This document is a WG item, it belongs to the WG. Alex > > Thaking you, > > AB > > On Tue, Feb 13, 2018 at 3:39 PM, Alexandre Petrescu > > > wrote: > > Hi IPWAVErs, > > I submitted a new version of the IPv6-over-OCB draft. > > The changelog is: > > Added normative term MUST in two places in section "Ethernet > Adaptation Layer". > > Alex > > > > -------- Message transféré -------- Sujet : New Version Notification > for draft-ietf-ipwave-ipv6-over-80211ocb-15.txt Date : Tue, 13 Feb > 2018 05:37:55 -0800 De : internet-drafts@ietf.org > Pour : Jerome Haerri > , > ipwave-chairs@ietf.org , Jerome > Haerri , > Alexandre Petrescu > , Alexandre Petrescu > , Nabil > Benamar , > Thierry Ernst > , Jong-Hyouk Lee > > > > > A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-15.txt has > been successfully submitted by Alexandre Petrescu and posted to the > IETF repository. > > Name: draft-ietf-ipwave-ipv6-over-80211ocb Revision: 15 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: 2018-02-13 Group: ipwave Pages: > 39 > URL:https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-15.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-15 > > > Htmlized:https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-15 > > > Diff:https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-15 > > > > 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. > > > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available > attools.ietf.org . > > The IETF Secretariat > > > _______________________________________________ its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > > From nobody Wed Feb 14 00:15:30 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A28DD126B6D for ; Wed, 14 Feb 2018 00:15:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.633 X-Spam-Level: X-Spam-Status: No, score=-1.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NAWiMrKisBfA for ; Wed, 14 Feb 2018 00:15:28 -0800 (PST) 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 DEF3E126C26 for ; Wed, 14 Feb 2018 00:15:27 -0800 (PST) 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 w1E8FPw5021453; Wed, 14 Feb 2018 09:15:25 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8A98420107E; Wed, 14 Feb 2018 09:15:25 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 7A905200C53; Wed, 14 Feb 2018 09:15:25 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w1E8FP56010380; Wed, 14 Feb 2018 09:15:25 +0100 To: Abdussalam Baryun Cc: its , Margaret Cullen References: From: Alexandre Petrescu Message-ID: <897f2ec8-2774-08a3-d1ef-2da7555b8239@gmail.com> Date: Wed, 14 Feb 2018 09:15:25 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.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] Why ieee802.11 ocb Similar to Ethernet layers? do we mean MAC (was Re: 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: Wed, 14 Feb 2018 08:15:29 -0000 Le 14/02/2018 à 08:23, Abdussalam Baryun a écrit : > > > On Wed, Feb 14, 2018 at 7:11 AM, Abdussalam Baryun > > wrote: > > Hi Alex, > > How are you doing, it is always nice to chat with you, as it was a > long time from our last meeting in London 89.  my comments below, > > On Mon, Feb 12, 2018 at 12:49 PM, Alexandre Petrescu > > > wrote: > > Abdussalam, > > Let me reply now after a few months. > > Le 05/10/2017 à 05:55, Abdussalam Baryun a écrit : > > Hi Alex, > > I thank the authors for their hard work and hope we can work > together > to make the doc best. I don't think it is ready for > submission. I am > still reviewing but I give now some comments. > > Ethernet is defined by IEEE as IEEE802.3. > > > I think yes, in principle; Additionally, I am not sure but it > may be that "Ethernet" is a label for 802.3 like "WiFi" is for > 802.11. > > However, I think the document should not mention IEEE802.11 > protocol > (some name WiFi) as similar protocol like IEEE802.3 ( Ethernet) > protocol, one is wireless protocol and the other is wired. > > > I agree. > > I dont think this ipwave document mentions that 802.11 is > similar like 802.3.  Can you point me where you think it does so? > > > In the Abstract in draft-12 and maybe in 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. > > So why did WG choose that in the first place? Choose what? > I understand that > IEEE802.11 OCB has different frame 802.11 OCB has different frame format than 802.3 (Ethernet), but same format as 802.11. NEW: > 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 > IPv6 over other known 802.11 layers - by using an Ethernet Adaptation > Layer. What do you think about this NEW formulation? > or activity or diff MAC, which is > Outside Context of BSS. It is not coordinated with other IEEE802.11. What do you mean by not coordinated with other IEEE802.11? Alex > > AB > > > I seen that some where or understood that from the draft, but will > check it again for you, > > > > The transmissions are different, I don't see that they are > similar > even their frames are not similar. So it is not correct in > section > 5.2 mentioned that: > > IP packets are transmitted over 802.11-OCB as standard Ethernet > > packets. > > > Well, IP packets _are_ transmitted as standard Ethernet packets, > with an Adaptation Layer.  The next phrase says so. > > > This draft is doing transmission, so transmission IMHO does not mean > only packing, what will be the way of adaptation to lower layers, > and if there is a problem who will take over to adapt. Does this > layer see all possibilities? So that are my  questions, > > However, did the authors find a reference to the adaptation layer > techniques or not? > > Best Regards > > AB > > > > IMO even the document RFC2464, should have been (more technical > focus) referencing the protocol IEEE802.3, instead of naming > that may > change by time. > > > I agree. > > There is an ongoing work on RFC2464bis (draft-hinden something), > that could be improved with this comment. > > Alex > [...] > > > From nobody Wed Feb 14 00:18:05 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA80126CD6 for ; Wed, 14 Feb 2018 00:18:01 -0800 (PST) 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 G9LnkBYCHFjX for ; Wed, 14 Feb 2018 00:17:58 -0800 (PST) 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 8C21F126B6D for ; Wed, 14 Feb 2018 00:17:57 -0800 (PST) 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 w1E8Hto0022547; Wed, 14 Feb 2018 09:17:55 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2F34D20277B; Wed, 14 Feb 2018 09:17:55 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 1F3162018B7; Wed, 14 Feb 2018 09:17:55 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w1E8HsYd012048; Wed, 14 Feb 2018 09:17:55 +0100 To: Abdussalam Baryun Cc: its , Margaret Cullen References: <1506192164.12227.3.camel@it.uc3m.es> <390b03ec-27a6-43e3-3ea1-95715d253980@gmail.com> <97975302-2ab4-d9b9-d825-758bf2371dff@gmail.com> From: Alexandre Petrescu Message-ID: <69847686-289a-55c4-9bf2-5ea458ceb35a@gmail.com> Date: Wed, 14 Feb 2018 09:17:54 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.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] 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: Wed, 14 Feb 2018 08:18:01 -0000 Le 14/02/2018 à 06:11, Abdussalam Baryun a écrit : > Hi Alex, > > How are you doing, it is always nice to chat with you, as it was a long > time from our last meeting in London 89.  my comments below, > > On Mon, Feb 12, 2018 at 12:49 PM, Alexandre Petrescu > > wrote: > > Abdussalam, > > Let me reply now after a few months. > > Le 05/10/2017 à 05:55, Abdussalam Baryun a écrit : > > Hi Alex, > > I thank the authors for their hard work and hope we can work > together > to make the doc best. I don't think it is ready for submission. I am > still reviewing but I give now some comments. > > Ethernet is defined by IEEE as IEEE802.3. > > > I think yes, in principle; Additionally, I am not sure but it may be > that "Ethernet" is a label for 802.3 like "WiFi" is for 802.11. > > However, I think the document should not mention IEEE802.11 protocol > (some name WiFi) as similar protocol like IEEE802.3 ( Ethernet) > protocol, one is wireless protocol and the other is wired. > > > I agree. > > I dont think this ipwave document mentions that 802.11 is similar > like 802.3.  Can you point me where you think it does so? > > > I seen that some where or understood that from the draft, but will check > it again for you, > > > > The transmissions are different, I don't see that they are similar > even their frames are not similar. So it is not correct in section > 5.2 mentioned that: > > IP packets are transmitted over 802.11-OCB as standard Ethernet > > packets. > > > Well, IP packets _are_ transmitted as standard Ethernet packets, > with an Adaptation Layer.  The next phrase says so. > > > This draft is doing transmission, so transmission IMHO does not mean > only packing, what will be the way of adaptation to lower layers, and if > there is a problem who will take over to adapt. Does this layer see all > possibilities? So that are my  questions, By 'transmission' I understand the entire set of operations of sending and receiving. Here I understand it in a very generic manner (not just sending), because all IP-over-foo documents are titled 'Transmission'. > However, did the authors find a reference to the adaptation layer > techniques or not? Not that I am aware of. Do you want to ask them one by one? Did you find a reference to the adaptation layers techniques? Alex > > Best Regards > > AB > > > > IMO even the document RFC2464, should have been (more technical > focus) referencing the protocol IEEE802.3, instead of naming > that may > change by time. > > > I agree. > > There is an ongoing work on RFC2464bis (draft-hinden something), > that could be improved with this comment. > > Alex > [...] > > From nobody Wed Feb 14 00:22:23 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 350D9126CC4 for ; Wed, 14 Feb 2018 00:22:22 -0800 (PST) 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 WgfDQw2BkK4B for ; Wed, 14 Feb 2018 00:22:20 -0800 (PST) Received: from resqmta-po-05v.sys.comcast.net (resqmta-po-05v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:164]) (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 6DDB3126C83 for ; Wed, 14 Feb 2018 00:22:20 -0800 (PST) Received: from resomta-po-01v.sys.comcast.net ([96.114.154.225]) by resqmta-po-05v.sys.comcast.net with ESMTP id lsKTe1GshYLH9lsKaeJe7N; Wed, 14 Feb 2018 08:22:20 +0000 Received: from [10.95.80.80] ([162.210.129.5]) by resomta-po-01v.sys.comcast.net with SMTP id lsINeskOZKMyIlsIQet8i6; Wed, 14 Feb 2018 08:20:18 +0000 From: Tony Li Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_BEDF28EC-47CA-4CA2-B34B-0DCA59E24EF8" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 14 Feb 2018 00:20:02 -0800 In-Reply-To: <897f2ec8-2774-08a3-d1ef-2da7555b8239@gmail.com> Cc: Abdussalam Baryun , Margaret Cullen , its To: Alexandre Petrescu References: <897f2ec8-2774-08a3-d1ef-2da7555b8239@gmail.com> X-Mailer: Apple Mail (2.3445.5.20) X-CMAE-Envelope: MS4wfLwBxtOKaoA/KfYU916yv0T4r2cyujgUKCUMI02/GhlQwbORMMF0m7/+WTZ13jEjxiLyhWsMAq4Pq1eVBzxqkUEJSUSRNv9SrJYjQdxmsP/u9feX1V8m 3L71a9dfN8jm170QNKlzQ5uKAue2B2n2AgUpdQekBI1B1EeU/a4H4nq/I/qPmgiiADJuITbwjXW1F7LuVsgBvrFTAxFWBexvrZ1Sp2VdWBOMF+njl8/EzcoN QjUGpaiNyN2wHPYFkzA6ygIs/JtmCAB++0h485ugCOI= Archived-At: Subject: Re: [ipwave] Why ieee802.11 ocb Similar to Ethernet layers? do we mean MAC (was Re: 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: Wed, 14 Feb 2018 08:22:22 -0000 --Apple-Mail=_BEDF28EC-47CA-4CA2-B34B-0DCA59E24EF8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >> 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. >> So why did WG choose that in the first place? >=20 > Choose what? Choose to use an adaptation layer? Because it=E2=80=99s what is done to make it more obvious for the rest = of the world to make use of the media. When the rest of the world can = only deal with Ethernet encapsulation, everything else is simpler. Folks writing the device driver deal with the adaptation and everyone = else can ignore it and just use Ethernet. Tony --Apple-Mail=_BEDF28EC-47CA-4CA2-B34B-0DCA59E24EF8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

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.
So why did WG choose that in the first place?

Choose what?


Choose to use an adaptation layer?

Because it=E2=80=99s what is done to make it more = obvious for the rest of the world to make use of the media. When the = rest of the world can only deal with Ethernet encapsulation, everything = else is simpler.

Folks writing the = device driver deal with the adaptation and everyone else can ignore it = and just use Ethernet.

Tony

= --Apple-Mail=_BEDF28EC-47CA-4CA2-B34B-0DCA59E24EF8-- From nobody Wed Feb 14 00:52:10 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA93126CD6; Wed, 14 Feb 2018 00:52:05 -0800 (PST) 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 Ch-oO6SW1Oyl; Wed, 14 Feb 2018 00:52:01 -0800 (PST) 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 25D56126B6D; Wed, 14 Feb 2018 00:52:00 -0800 (PST) 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 w1E8ptlt020956; Wed, 14 Feb 2018 09:51:55 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 44B42202179; Wed, 14 Feb 2018 09:51:55 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 26B88201FF9; Wed, 14 Feb 2018 09:51:55 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w1E8psLX004463; Wed, 14 Feb 2018 09:51:55 +0100 To: dickroy@alum.mit.edu, cjbc@it.uc3m.es Cc: draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org, "'Russ Housley'" , suresh@kaloom.com, its@ietf.org References: <1517217856.4315.32.camel@it.uc3m.es> <87A7E5C11E9C48DB84FBE2CE78537448@SRA6> From: Alexandre Petrescu Message-ID: Date: Wed, 14 Feb 2018 09:51:54 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <87A7E5C11E9C48DB84FBE2CE78537448@SRA6> Content-Type: multipart/mixed; boundary="------------1D7278221C16F1A8A1E267B5" Content-Language: fr Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 - Normative text in Ethernet Adaptation Layer 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, 14 Feb 2018 08:52:05 -0000 This is a multi-part message in MIME format. --------------1D7278221C16F1A8A1E267B5 Content-Type: multipart/alternative; boundary="------------41B3C589A46F310E69224AD0" --------------41B3C589A46F310E69224AD0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Le 13/02/2018 à 20:14, Dick Roy a écrit : > Comments inline below ... > > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu > Sent: Tuesday, February 13, 2018 2:36 AM > To: cjbc@it.uc3m.es > Cc: draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org; Russ Housley; > suresh@kaloom.com; its@ietf.org > Subject: Re: [ipwave] Shepherd review of > draft-ietf-ipwave-ipv6-over-80211ocb-12 - Normative text in Ethernet > Adaptation Layer > > Hi Carlos, > > Le 29/01/2018 à 10:24, Carlos Jesús Bernardos Cano a écrit : > [...] >> - All the text of section 4.2.1 is not normative, but more a report of >> what is done today in existing implementations. > > I propose the following improvement. > > OLD: >>     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. > > NEW: >>     The Receiver and Transmitter Address fields in the 802.11 Data >>     Header MUST 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 MUST be the same as the >>     value of the Type field in the Ethernet II Header. > [RR] I do not understand the intent here.  What Ethernet header is being > referred to? It is the Ethernet II header.  This is what Wireshark displays. Please see attached a packet dump of an UDP IPv6 packet over 802.11OCB captured in nrmal mode (it's a CAM but that's not important).  Wireshark is a freely available open-source tool in widespread use which understands very many protocols, among which Ethernet and 802.11. > This presumes there is an associated Ethernet frame in the > picture somewhere.  What if there isn't? For example, V2V or V2I with no > Ethernet LAN involved. Well, do you imply that some IP packet could be sent on something which is not 802.3?  Which is further not converted to an 802.11 frame?  I have never seen such thing, but I am curious what do you mean? > Secondly, 802.11 MAC headers have both a 3 and 4 > address format depending on values of the ToDS and FromDS bits in the frame > control field in the MAC header. The To DS and From DS flag bits in the frame control field are 0, because the DS status is 'network operating in ad-hoc mode'. If needed I can provide a packet capture showing this. > The source and destination MAC addresses > are not necessarily the rx and tx MAC addresses in those cases. Now it is > true that accoding to the latest 802.11 spec, ToDS and FromDS are to be 0 if > OCBSctivated is true, however that requirement is unnecessary, and should > not have been put in place (it's a long story :^(((). The requirement unnecessary... Let us tell that to IEEE and remove it.  Until then let us stay this way :-) >  It will likely be > ignored going forward because there are many uses for the 4-address format > in ITS I could agree the use of 4 addresses (Source, Destination, Transmiter, Receiver) in the 802.11 Data header could be used in the future for ITS.  Then maybe write another Internet Draft to obsolete this one. But I dont think the future use of 4 addresses in the 802.11 Data header will prevent mapping the Source to Source and the Destination to Destination (802.11 to Ethernet II headers).  Because if they do, that will break many other things, like RFC2464 and potentially others. That will be a significant departure needing much agreement. > and there is NOTHING preventing its use other than the thoughts of a > few people.  I suggest you NOT make any requirements such as the ones above. > Implementers know how to map these addresses; they've been doing it for > years.  Trust them to do it right and don't constrain them unnecessarily. > > Do you agree? Sounds like a speculation about what the future may holds (use the 4 addresses in the 802.11 Header in ITS). If there is an example where the Source address or the Destination address in the 802.11 Data header are different than the Source address or the Destination address in the Ethernet II header (respectively) then I may change my mind. The examples that I see all act the way written in this draft (Source and Destination are same in 802.11 Data header and in Ethernet II header, respectively). DEpending on this, I may change the text, or not. (write the normative 'MUST' or 'MAY' or the non-normative 'is'). >> Is there any different >> there that is specific of 802.11-OCB? > > This is specific to 802.11 (compared to Ethernet), including 802.11-OCB > (compared to Ethernet). > [RR] I don't understand the question or the answer.  That said, there is > nothing I think the question was whether there is anything specific in 802.11 OCB Headers that is different than Ethernet.  My answer was that yes, there is something specific in 802.11 OCB Headers compared to Ethernet.  The formats are different. Alex > > Alex > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > --------------41B3C589A46F310E69224AD0 Content-Type: multipart/related; boundary="------------41656884F05F54FE2D846485" --------------41656884F05F54FE2D846485 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Le 13/02/2018 à 20:14, Dick Roy a écrit :
> Comments inline below ...
>
> -----Original Message-----
> From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu
> Sent: Tuesday, February 13, 2018 2:36 AM
> To: cjbc@it.uc3m.es
> Cc: draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org; Russ Housley;
> suresh@kaloom.com; its@ietf.org
> Subject: Re: [ipwave] Shepherd review of
> draft-ietf-ipwave-ipv6-over-80211ocb-12 - Normative text in Ethernet
> Adaptation Layer
>
> Hi Carlos,
>
> Le 29/01/2018 à 10:24, Carlos Jesús Bernardos Cano a écrit :
> [...]
>> - All the text of section 4.2.1 is not normative, but more a report of
>> what is done today in existing implementations.
>
> I propose the following improvement.
>
> OLD:
>>     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.
>
> NEW:
>>     The Receiver and Transmitter Address fields in the 802.11 Data
>>     Header MUST 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 MUST be the same as the
>>     value of the Type field in the Ethernet II Header.
> [RR] I do not understand the intent here.  What Ethernet header is being
> referred to?

It is the Ethernet II header.  This is what Wireshark displays.  Please see attached a packet dump of an UDP IPv6 packet over 802.11OCB captured in nrmal mode (it's a CAM but that's not important).  Wireshark is a freely available open-source tool in widespread use which understands very many protocols, among which Ethernet and 802.11.



> This presumes there is an associated Ethernet frame in the
> picture somewhere.  What if there isn't? For example, V2V or V2I with no
> Ethernet LAN involved.

Well, do you imply that some IP packet could be sent on something which is not 802.3?  Which is further not converted to an 802.11 frame?  I have never seen such thing, but I am curious what do you mean?

> Secondly, 802.11 MAC headers have both a 3 and 4
> address format depending on values of the ToDS and FromDS bits in the frame
> control field in the MAC header.

The To DS and From DS flag bits in the frame control field are 0, because the DS status is 'network operating in ad-hoc mode'.
If needed I can provide a packet capture showing this.



> The source and destination MAC addresses
> are not necessarily the rx and tx MAC addresses in those cases. Now it is
> true that accoding to the latest 802.11 spec, ToDS and FromDS are to be 0 if
> OCBSctivated is true, however that requirement is unnecessary, and should
> not have been put in place (it's a long story :^((().

The requirement unnecessary... Let us tell that to IEEE and remove it.  Until then let us stay this way :-)

>  It will likely be
> ignored going forward because there are many uses for the 4-address format
> in ITS

I could agree the use of 4 addresses (Source, Destination, Transmiter, Receiver) in the 802.11 Data header could be used in the future for ITS.  Then maybe write another Internet Draft to obsolete this one.

But I dont think the future use of 4 addresses in the 802.11 Data header will prevent mapping the Source to Source and the Destination to Destination (802.11 to Ethernet II headers).  Because if they do, that will break many other things, like RFC2464 and potentially others.

That will be a significant departure needing much agreement.

> and there is NOTHING preventing its use other than the thoughts of a
> few people.  I suggest you NOT make any requirements such as the ones above.
> Implementers know how to map these addresses; they've been doing it for
> years.  Trust them to do it right and don't constrain them unnecessarily.
>
> Do you agree?

Sounds like a speculation about what the future may holds (use the 4 addresses in the 802.11 Header in ITS).

If there is an example where the Source address or the Destination address in the 802.11 Data header are different than the Source address or the Destination address in the Ethernet II header (respectively) then I may change my mind.

The examples that I see all act the way written in this draft (Source and Destination are same in 802.11 Data header and in Ethernet II header, respectively).

DEpending on this, I may change the text, or not. (write the normative 'MUST' or 'MAY' or the non-normative 'is').

>> Is there any different
>> there that is specific of 802.11-OCB?
>
> This is specific to 802.11 (compared to Ethernet), including 802.11-OCB
> (compared to Ethernet).
> [RR] I don't understand the question or the answer.  That said, there is
> nothing

I think the question was whether there is anything specific in 802.11 OCB Headers that is different than Ethernet.  My answer was that yes, there is something specific in 802.11 OCB Headers compared to Ethernet.  The formats are different.

Alex

>
> Alex
>
> _______________________________________________
> its mailing list
> its@ietf.org
> https://www.ietf.org/mailman/listinfo/its
>
>
--------------41656884F05F54FE2D846485 Content-Type: image/png; name="bmcgglpopekoakgf.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="bmcgglpopekoakgf.png" iVBORw0KGgoAAAANSUhEUgAAArEAAABRCAIAAABKY2nRAAAShklEQVR4nO2dTa7quhKFM5YN A3kSQkyEBmIUp0MLMQ16W9rDoEmD+dzXgCT+WWWXE8dxyIo+bZ3LzY9dZTuViuPVvJ4PQggh hJBm9hIQQgghpAYYExBCCCHk8Xo+mn/cuHHjxo0bN27//jX//v37Hzdu3Lhx48Zt9dsnJvhv xDZ7roMQQggh41HFBP/+/WNMQAghhHw3zBMQQggh5PEKxASBOQiMCcZxOTS72/zFyM3vcds0 h2v+M9/2k5w27o4xNfo9bjfHv9mdoqkm+T1udcZhUyRfTygmgFmBcExw2zfGVnwM+j1uP5f+ Of8+Xs/H67pr7C29X93PG+9A/0JW3fsfEUmj8/28mXQYymz87EX9O/00+0v/i+nQ7nfkjv7w SKmSBuIEd9z2jVXyNNjqChZJFxOstSmSdaGKCZqm0ccE8w0l9/Pm06P+Tj8NCI0vh8i46fM+ xOl+l0PXP9FoIlzdPHzRo3NBXPOapuu8Kfv9ums2u0PEgNO5Y0B7Mw9kqytVJE1MsNKmSFZH iZjgtm8Opy58/jR6M6PwPuTv9LM9HQ9N02yO573xkNSH3uo+cN35WQoY5utOaHe/667r7TD2 dy/kcjk0u1v7kLE93V/uCHI/b5rt6f4+ubG1vRoaxPjxfU4RcPjl0OzO7eXkw71hqDVF503z /0K/J3nztncK87GM4wXB7/DOqnLHC9VI4w7HdLGWsKZWZ3V5cRCATVEoknEHNW7YCa3O+DGa 1Fx3UyQrIhIT2C2v6X43/5qns94dtP3ktrf+7faKtj//nX6aZnd7Xg7NZ2zanu5CPB4BdQDv 2KExQXfyd73O/WBxOdgVF7gcmjaV93vc9gOc2bG7KvvjCDaINkPTX9G5elskFE6Z/jWdYtvZ LSrye5I38Q6fNoYGOLM8bVE1A7HvDsn44Gwhy6tfVH95q4umr/urS+4IFsmOCXStLpJ3YVMk 66RUnsBvqdabfvMG8+l+n5jAiuWb2EvT7syxJEEaYHTuxjjvASJyW7VHqP7M3XnaYAhc+vV8 SAb5PDrE6ujYAQyawbHjU7brbrv5OVwjRRXiP703/VTq/bxpzFujdRc0zX7dtdXUPZzhKqgG 4qDlx+Rsv6fViXbwBgHZHQkxgarVmQ/3qphgzU2RrIi5YgLwgIJjApiXk2mTDfbvbtCdipfF 7VNzsJ+Hu5/Q8z/Tg53RR0zX45O/B1l5jB4ZE7wHuL/T7nw9bvcX27OKmCDNm95AbJXNeM5z /f6ZoGdt4nXHDsRBy2eLCRbd6oSywSzFBDGBlNsfExOsqymSFZH/uwNVTGDcpG/7YJ7A7m9h cEAg5S0Hzycwexd8OIvc+Yyebx9+2/+cTzunqN4TYcwg4QFOfHegiwl+j9vN7rA//j3v5/3u sAmlN4VYcMTEKFx40e+wVHp3SOlZ8cW5bzr/l3W2OuOpGnqzGwSC5fSL1M3sa5pATAAL31/d OnxFTZEQROb1CfTvDrqZB9vT8RCKCezUX2DUczOE5stCMW8ZG53bl7XgnE7229hT82bXPVwu kn8tYBDrcSRSqT5haxZeFxO0sz1e1vDnPgx1eWlQEqU320YCpkqJvoDV173EdQ2Ca4TcEbI8 eGP1PjySbP/GVmft7M4x7AaBUDm9InWNwTg8odV1hx+u8Qn/X9gUCUFwHcOaSHxR8v0s++FG SpjrMyVFqKvV1bq20hc2RUIA1Duoh/ruFhWw3Ocb/43V+8ky+s1eWWprdbXGBN/VFAmRYJ6g Ct5J1MruFrUw60JYQ7m6b+grpMpWV29M8GJTJCuAeQJCCCGEPF7MExBCCCHkDfMEhBBCCHm8 5tNKrvqt4VcxmYTxWqhFSJd47qAK8MJhlymNosuU0UoOL58+NUoBMeejcP9r6SYqlIJ90B09 2Uwft2uZs4q0MUFu3bn4unvak5jflAewlIGSNLKh6K3lwbjf/QUivQ/NQ0K60B2w2ArJ3eQ9 l+uO4TPqwbLKEXcMtWR8YImfOcXyI1BXE7dksdGKLSTWZdRS4GMPxzXSd9gKDxfcEe0yZbSS FxETBAo2tLRj11TW4i6oMmSm8QQxweZnayxuk3rymPivfzlJi1a/6C/ac4iQLqyFXnRHltFT Se4m7rlsdwz98t7VmQy7eHzvcMYQZ5WwUBXSLD+KhMcnryUrtR8lP0bqqzfCoMOlGuk7bIWH S+6IdJnJY4KQzqmnCgolTZH46QVr+3qHi6KiIftOHhNgOVckJvt6qtZbtAVs+pgAShj7gqqS ldSys8gd112zOd5OP4frIz7W4HMKzgIGCY1HMY1sQfR2lJAuunpA7Bi7GEbSqJo6gyBhYuHw Rblj4LIB1kpNxkXVvUN2HESOCVpHO/ctQ4PUtbwoK68VpE6spmw6LxeljQlUXSah2Yw7HNZI 32ErPDzojnCXGaKV7MglO57uN7vLeaOGL84r6rEi8VPt4XPmCbqeZoeoUDxaTOkkxARtOa+7 NLlCwUqgnHqp5XdL/T1u95eYC5Djfo/bzfHmh33IIEEtWm9IRfb0RG/1QTq6RNfCG3slXSx2 rI0JxGqmGcSrkXv40twxbIVBe/XG7hal7x2y46KN3P7P6854UvKWG0eWF2Tl9YLUidW0CbXk hExDvMvIP0qR6MDDYY30HbbCwyPuCHaZCt4ddOUT9FgFURPt4fPGBL3bGhAHxDqJmndi4Lo7 7HeHmISxIKiqkmNPkFVsx9zbPpZRhI77PW77e0/QOEEtWsVDJBK9HSukaxfPkPMIiR2jgllP A0rJXWlP5Rv05bljUN8RYgJ970jEjwn8kcouxrsMyPKyXJxSkHpUNYMtWR8TxLtM/MdMh8Ma 6TtshYfH3BHqMjXFBMK669qYQFy2ff6YoD1JnxKYIib4O+3Ov5fD/hKOCfpDrEFhqpjgdd01 +2PIBdBx9vxYeX5yUItWM58Dit5mjAk6zyZPunSVgsVqqgxiNLCoHPbC3DE+JsCpl3DvSCTw 7sC38/28MZzlWT4lJgj6fVg1Qy05R0wQrUj85ImHwxrpO2yFh0fcMTomCP9unk4aLJDOqS/E h5de18YE8srtimeycGNFPyakDbtyBjIfSExWf6H3lK79+7l8d/68xQ83CzCF27FSWOQ6IrXc j7n38+ZnG3l3EMycO/cS0SAg2R7XyIY1Gimk67qmm2MoiB1r5xMIv2sMgoWJ4eFLc8cwQWoj JnANgk6Lx5A88wkco/2cr2YcACwvxAR6QerEaoK6SLLdY94dANeIPwYsP+RwWCN9h63w8KA7 Br87GKaV7Oep2kKYiTJ4U8eSpuqYQNbhVX3UcYl+MgRqFE6EWlm7vhaBbAq4kGbcMRKMxjQT qLIqC6p6VsLl7CsVlFo2O2G0CtBxaMJp8Gx2B5CeSr3DgejtWCFdo9lo2iG6K8OWA6qpNggS JhYOX5Q7BgpSm33TvgEre4eqYQNv+pOfIgbBU6ehrLxWkDqxmj5gt3CjHdZlhH4U7jJDDk/8 GnABh4fcMXCOoSZn4McEa0JMS5DVMWyaG8mAOFuNfbNq2GVmI/IWhnoHQ6hS9JbMyXKFdBfN QgSpCYBdZhaGr1nEPAHJjZvOiqcoFwUXai3NlSrAkzJ5h2WXKY2iyzBPQAghhJDHi3kCQggh hLxhnoAQQgghj9d8WslEBRYsKMmvUlbxK+k/2eKcNdkgeistyp4LmBg/0h2EAPKuWSR/zQ/I LcQ39kJW4QcVbKIaRU+LPljPJaQ2RUzQfRo+oJDmp/NTzy9TmtH80t2WqB48JytFarmgqrJm NZjx9ozaOZdSM3Rcx4CYQLl6tOG4UT1L6Y6ROrxy4YeOk6RqMq9t/Ho+1CsBVxgTmAvvDOgq c8UEYMnhah8RRgm/ltKehlYVgMpbSRJKSnPdzxtjsXprbcRCqsoqxbmx9ozaQUGoRqaPoGRa y7CYoKD+ss4dsCnCtqRHbnVk+RSICS6+kK6oyzmnVrJZ7L65K/WCk2r0grLI0jpxmrHDXSU+ 1Z5AO/UlvblQaiWLRh5xUy+oPW17M+AjpO3r3huMy8Gry0XC99H4CqbCqI3V5OKqytAgopW8 C6XYs5hScwaNbFCYIvrLCe4INEXYlhLaJ2OC72SIVrLz1zspUgBzdY0fEWEkYxQopZUM1Uv1 esHoQsKeYNUI8ZzK8hv7WAvsK+0ZUbWJLEcvutgjILmro4z2dH8t95ELP1k62r7Jssj4xtb4 NRUKVkhVOSFPgKqpsyf6cTKl5nEa2ahpFdRf1rgjKKSLTsKYYPUUyhMAbQJ8BwWxcymtZFG9 NDy0GTsgVWKsIug+9Mjn1Jbf7Pz+00nMnpJ2qnv1BF1EiF5yN1rZZkrtaVRZwZ5A2zddFlnG j7FA1FVIVTnzuwNZlBn+mFupebxGNrp6Qf1lfUwgNsVwBB+BMcF3UlNMIExBKqWVjKdBLCUm aO1ga2Rp7Wm4wB28cscEKsldDVNqT6PKYntK2r5pssjhavYVEd5SF1JVzhwT6GcsTqHUnEEj 28N7d+AnaTLqL6vcITdFxYyHMIwJvpPMWsmv50MdE2BpLL+RldJK1sYEgTy/eyG8Z0TSdNC7 g3a3vTkq6e3plER+V63XSg4U8uqd6lmZ9vTz8QpP14o4LlEWWSf8Kg/ihVSVJ3h3ALt2ME2d S6k5VZS5Pv1l9RxD0BTFtsR3B6sn7/oEMVVQ54bhfw8zs1ayLiZ4Qr1g4UJ4TySLDPaEYsci YA6R1p5QO1W4ulIrWUKaSlmV9nRnTyjCa9sTavsm6JyCH5HGq5tUNybWiC0ks6py7pggLso8 qVJzmihzXfrLKe4ID7NOqVLbJ2h1ZNlwHUNSCdS3JTXD9klWAfUOyPxQ35bUDNsnWQ/MExBC CCHk8WKegBBCCCFvmCcghBBCyOPFPAEhhBBC3lArmTxeNYgyE0IImZusaxaFl/HKSGFN0sws V5RZJr+E8cxWSlArTtRK1ksYW0zS5uc1sr0ARth0I38khOjIurZxyZigoCZpbhYsyoyZRMK4 Fisp1Ip9IR9Zi1YvYewwSZuf18iSTJG5ZKG3ROmQHwkhWorEBEiHN0HG10fQJFVovJqLtnqP R/Yyeb2mmVckeKHt6XhoPuJjwaeuJYsyQ7JIGOuspGw2I7VoTWJqxYLkLtjzMUp4PosOb11G RnaA2r4jf0xtz4SsmCFayY5ccn86ISaILE4ck/EFCPpjPWGxJbwnVg+KFKk9vH10uxyaZnu6 /51+5BVOFi3KjMkgYayxUqCawEcjtWgT1Io9yV28Z0SYOEwWHd66jGy+O/hcBWr7jvxxQHsm ZLWUyBMAqdAUGV+AFBPgd67C44i7pxgTBPUOjGem/aU7SSwmAI9WixFglMkqYQysJBV+3H1R 0dhCasVIchfuqZcwloqRX4e3FiN3b0Ogtu/IH8c2AELWRMH5BKZU6AAZ3+cjdiFJ49UftvCe cFpZ5MZm5gkSYoIlizJHyCVhDKw0T0wQViuGkrtgT72EscAkOrzVGLlLSEBt35E/jm0AhKyI rN8duFnHgFToIBnfDqhJKmu8BiSMrcOVYQo6fIqYoApR5mISxhoryWltWMKRWrR+YwOT+4Qi BacB6uUKcTGG6/DWamQjxQK1fUf+SAjRknl9AmPaERb87YcJrYwvAmuSihqv/udJcE9z5qA5 nRDGLs7hk8QEVk1nEmUuJmGssxKspthshmvR6tWKkeRuQIu2tYA3HaSIDm9dRjYKH1U257eI hBSB6xi22E8VfBPZQolYGpkQshaod9DifjPGMZoSsTQyIWRdME/QYaVhOUYTQghZG8wTEEII IeTxYp6AEEIIIW+YJyCEEELI4/UFWsnazxfjCN9lTYGwFgIhhBAyI7m1kvuthIQx1KfxtE8+ kwcVn6TrY4KxhVcv+08IIYQUYqq1jUtIGMOlEl0tWr0SXdGYIGWVX0IIIaQE0+od5JEwFkDL CkkRgDomaFMdvcCMV6M0tWKoE/1sjcBUASGEkGoYopXs/O1PN4mEsQR4zpa1aJUxQZvP75d5 T9JVwurPI+pICCGElGO6PEEuCWMJL9Uf0qJNfXfQ72+K0hohjrBkvZc8EKRsuyvy9QEhhJBa KKCVPFbCWMCJCcJatMNjgvYbAXA5V9ou8CmBK2Xr1ZcQQgiZm9zfHWSXMBYJ3FBH5wlcPaSf 82nn3NG9NyMxiQQ/yuG7A0IIITWRdX2CaSSMJWTpQjMCMERvndl/LuaedrQBhV99SVag/ixL 2XKOISGEkMpY8jqGxZ6zw+8FBsIXB4QQQupiyTFBoUftSXSTuWYRIYSQ2lh2TPDKubYxPnkz hW7y1Z2dQAghhMxOhpiAGzdu3Lhx4/YF2/8BjhAsQmU+O/UAAAAASUVORK5CYII= --------------41656884F05F54FE2D846485 Content-Type: image/png; name="nooiigdgagccncfk.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="nooiigdgagccncfk.png" iVBORw0KGgoAAAANSUhEUgAAAzIAAACDCAIAAADZKbk3AAAW5klEQVR4nO2dO87bvBKGtZYk nZYRBFmBdpAiyCrUpAqyjRQGAmQZf3kK78en0G2GnJFIXWxKfh4Mgnw077rw9ZAmq0dE27Zx oBl+/99/vf399qn68ONv8P+fX8fAX5+r6vPv//13/99//75/GP+v7Nfnqqq+/grC//z4mBgY 2u8vURxRz99fqr4aU+CfHx8rXTddkN3MGQvq+fPrmPnfb59EQf++f6i+/FzqT6NFQ8K+q/99 //Dp+x+7mUOffPr+Z6Ge7tW0K49hGIZh2C5WmfLLw5Vlvdjq0QN8hxzmFWPkLgctYuKYZqBt hizrZUpVVdWn79++KqXY5TaKj06iRQX9+jwEzGsyM3myLHMKSpVlTjOtK5LeTGQZhmEYhh1r hixL5+W1xzAMwzAMu4wtyDJvQhNZhmEYhmEYtq/hLcMwDMMwDCvC8JZhGIZhGIYVYXjLMAzD MAzDijC8ZRiGYRiGYUXYbhtkYEXZuEHG4u5uGIZhGIYVYrYsS/SciYyC7cT6Ta1GcbAu0LZp S61q2usr3iDNC7St375LixgzcLY+y7t5JW2Em2V+1+1f1vVM9N7iTYJhGIZhx9pesqyzn1+1 LvE2dE0MtEwWMZ4i8PPrKJ6mnU7//Pgodov9+O3fXJ4ffvyNd+SPAy379XnM3D3AYLJDZJmT IbJs3v78+FiFu/hiGIZh2OvsdLLsz4+Pw/FBox4KhVGUlTj6aT7nNac8idJl9aQTq8tBHoQg 3TNxzCxLl2V2QcrbN/StOIxBHdZkH5B1TuOsAgzDMKwwc2WZFhDVY1hzNkZo2zbKzpBlE4N2 SQ/0rI88+DnGk4t+f6mqj99+RMc+GkcbGbaLLLMOnVTD/2yGq4SC33V+WVNB+txScTnshBeS ZUs+VAzDMAx7tp3SWyZF2L9Bdf3+MoVHDp4UrbO3LLPXnFkZ5q1OS++6qCyjIFuW9Y69S0/w IcswDMOw0uxsskz5k4YlZb8+i7k2pUUSFnuNttsk5nAquTydfUaWeTFTLVmW2QXNrXnvZNxV xVmqXscwDMOwJ9kZZZnUFuOSf+HyqcRKf3PctWfidpBlv78MXihRzylwiKOceX7MxBnDVFlm FvT326d5j1GgFNMnMc2YZQWy5B/DMAwry/bat+x5G2TIhfNac2iXj1i0HkSOfhYQVH50d9nJ Q5Mzg3o2s+PT929KrUZVXYi5pBssWdZv7RFU3izI6nmVPJ4GTZFl5m8vyguUV5kNMjAMw7AX G7v8l2xi44+DTE/kGb9XwDAMwzDsWcaZmIVa59o5XCQpWXa8CsQwDMMwzDe8ZW9uar4SVxmG YRiGvdA2ecsAAAAAYC82ecuOSwsAAADwbuAtAwAAACiCN/CW3du6am55aW5NdpILUlAv3Nu6 bu+vrgUAAMChvN5bdm9rvUFYte/4qwZ0Wdic4vAEyRqJtw+3RvTQYhV2qGeYxdR1S9fHjLkx sOuAUkQiAADAIZTjLTvINXNrxtH93tapkq9IWSbbsVCLzfUMMxCiaCFvM6YZeG9rEda3bqYg 0QUAAABX5PXesgGlhLSCGv+6NVXTDs4U0wcW6gWZqy3LRAwlI5rb4KDq0kRevbq971TPW7Ps AVOaZCpWOtFGsWM6H+OYqaU9YlFYNbeg2remK8mLGQcG5XVhszFfJ4oBAACeweHeMu/fiMBB FYzPk9NFqI9RmYwJAzkRrkjqJUuoOExZFhf0sITBHvXMlmWW40hVbVbALKubMPsxRSe+2ib0 bY0JzJhu8ij/hZjoMgAAuDSFesseeqQfxubQ99XcYu/QvHgZUiovkuMte4Shpi7YoZ6J3WO2 zF5zZumXjNVp4bXosrNcWkOzdAcFMWeSDxVT85ZuTOYxAQDg0hS8tqyXOYGTKVIe/kg9u1pN Dv2bZNn2eiYRTWJac34zssyL6RUWpa7ckuq6Vk2PY84mVxrRjxn3AgAAwMUo11v2eDxuTd22 MljEmVwszk/05rdUUHOLcvFYJMt09qYu2FTPR/Yk5hQ9WCo/U08/5kJhdvGideESOzOmndz6 7YJT0NQKJjEBAOCyFOwte8QKQs7DmVsqVJY6sFIHE3590lFbOQWpsmYWh2XU00rudI8zTxtV 3q6nG9MpzVq7FnWxXp/f/5G47UX02wQp1oyeR5UBAMDVKcdbZmGsQkoblp88gK+uZ7GUqICY wQQAgItTjrcsJp7EKlPunKWeeZQmzPw5YAAAgItQqLesm3GLfCPFyZ2z1HMdBTWjoKoAAAAc RcneMgAAAIA3olBvGQAAAMC7gbcMAAAAoAh29pa1PvsWdBnGfSvWL51KOLp8uaDSVvgDAAC8 Hzt7y7z48/k4G4o9D1GBFVswbFc0STm4vZQmyxYKWtcIf4+xpJiySfE+cvPbngEAAFyO/b1l WeEdL/2ZXYaomcnhObJscy/tK8uiwyzzYppnt3sxEwsCAAA4MaV4y+KR9tZUTTv6SPrPY/fK va3rtm2G3eutzeJnh3FvmDeSqxrJA5sE4vzzqPJ+ldbLMntqMr0g1YDwnIL0owCmg6tUwuEc ADNmcCBUcBRWkKeRHAAA4Goc4i3TSqV6DGvOxgiBSlPTc9bRPoYiGQTG4Ozqow8nYZqeGAN5 mqMdqk7PNM+3NESVUXk7TzeHGLOXrOQzbY9jOl6oBFkmz0vvNLE45kmpKTfm2CgpXKOYM8kB AACuRNneslgWKG0yqB2hAXpZFnqx8mSZI3NEjVQMW5YFITPSafMkpk4+13YdU2q2/MnBLsWo 7MLMIrEVxZymj0cVa8acKQgAAOBKlLu2zDm6XDqcfFmWPnRbZ/qcW5YtOQf3kmWdRA6vx/BH XYu/zZgqhfCwxTH9ggAAAK7EqbxlejHSnLcs4wRFa8m/O4lpyjJDCM1XfvUkZpIsm2t77FeT a+Qy15bJdssyp0shP45iup0c5+kUBAAAcC2K2LcsfRJznMOs27aZk2V6Lm/BcyZnRuXwHyR2 ZVm8fcPSDGw43afmZTN6yUlutN2OOYY2N519kiyz9q2Qq+rubW2UP10MWSdrEpYNMgAA4L1g l38AAACAIuBMTAAAAIAiwFsGAAAAUAR4ywAAAACKoFBvGZ42AAAAeDfwlgEAAAAUAd4yiNh+ ejsAAADkg7fsAJ6x81a0A+2OZxI9R5axFRkAAIAGb9numOd/+4eCryXe2v9U6mb/DgEAADg7 eMv2Jji3s5JnEOjAjYRnSuoC9Nb5t6Zq2jFcnlVgHGVgnDdg5KmyVIow5YSAIzoEAADg5BTt LfP+LZlRLHWnELVNVbd3M9BPn3gck9Blk8qRZyipUHk80ujByzw6Mzi8sopdgY9HkizL6BAA AIC3AW/ZznSCYxQqNyHLgsC9ylIZhqpu7ozOPq4hoJQsi2dLhzKdE0KTa757hwAAAJyaor1l p+TWVPqw7n4SMw40yfCWjTkJVeMIHN8xNkxbRnOWh8qyjA4BAAB4Gy7hLTNnzTYGri9Ii6Rp ni8O3M69raumkVLMzn1Olj1iXZQ4ienIsqT+PKhDAAAATswVvGXmmvGNgZsKesYGGSmlG+vJ nHjWrwBk+PhDAPXbgC2yjA0yAAAAQi7hLQMAAAA4P1fwlgEAAABcALxlAAAAAEWAtwwAAACg CPCWAQAAABQB3jIAAACAIsBbBqfg9dtpLOz99ng87m3NXh8AALABvGXpWIcVvU4tRMcBPLcG 005mKZuUbd7H/9XHM1kb7hq9zs64AACwBbxlidz0meNj4PDnyw4QWnbiHFWs3Pk/9Wjylbz4 eCZDlInLHgozPGYAALASvGVZ6PE5lCav0kf2OUnir1tTNe3g39GfW/6ulG36lfxQRzIFPrTI qzednp7ibfPOCFVNig8jEKXXbdsdwNnKwz+9ti+2Nf5s5jxRAACAHMr1lnXKzPv3RdhneN+a ftTfwU+SdVT54xF5ywKpOJ7IKVVSdKhlIDyyZZklXOaOO4+bvLxqK4jS9bl7tNSQYPDk9dGH 1V9+2xebulh3dBkAAKwFb1kWhtYY3SUvmr4KNclYDbEAXcZRgmX9yjRPltlrziypkrM6zZRl RpoozyFhX8G+T/La7k8Tu+fCM48JAABrKNdbViTRJGZl+KY2l7DFWzbKscAhFCmkjeIhmsQM pemCt8yLaZMmy4w8bVmW13Zblvkr6pBlAACwkkt4y8xJt42BNvGSf+GQCn8MsKWgdAzRcGvq tm20fhz+mOrp/2owcxJzii6WtgV5hFLFj2mSJMusPG1ZlveLSWeG1suASUwAAFjLFbxl5nL7 jYERanrMWjkeqY6VBeXiuI1ikRjXU3rmZPUTZZmVdgwOhGHcUW5Mi8RJzDhPR5b5bXfaalxd x6OJKgMAgNVcwlsGAaGOeNEmGpchQ2oxgwkAAOu5grcMNPEMHbJsK4nCjO1kAQBgC3jLLkU3 ixe5a5BlO7DciXQzAABsA28ZAAAAQBHgLQMAAAAoArxlAAAAAEWAt+wdYNETAADACTi/t8zc OWxj4FmQG2jN6S5Plr10j61T9zwAAMABnN1bJnYk0Cdzbwg8CWJT+yUKlGVn7nkAAIBjOLm3 LDgFsQpPe1wTeBZsWSYUmFKf3Znqk28q2ql+OMJbn3Q5HFXUtEN8/bnlqss8u+l8PQ8AAHAM RXvLvH9H5BHZ3YE7dXvfGLi6zvuQc1R5H9fb0F87Bfv/KuWVeIK4mTw4Cj08gGleZpXY8wAA AK/m3N6ybnQf58NuQmytDnxti1agxZnvLXuEoeb04dgJ0/GRZvJQPub13DV6HgAAYF+K9pYt c2uEIhDHUm8JfC053jKBVDibZNkgxwJnWJR8o5IqsOcBAABezbm9ZUodTIvINwbOlhZH2hi4 C2puUS4ei2SZbqYprm5N3baNjhUn9/srqZmZPQ8AAPAGnNxb9njqBhnm4vSNgesZlvAHTrWx QUJbyai6mWbzQ13lJJeOPZlrovpkgwwAAADN2b1lcAChD43daAEAAJ7B+b1lsDPxnCKyDAAA 4BngLYOJbrYymlNElgEAADwDvGUAAAAARYC3DAAAAKAI8JYBAAAAFEFB3rLWJzercUcHlkQB AADAWSjIW+bFn8/H2b3r8cq949N35Nq8lRoAAABchrK8ZVnhHf6vBF8ly8QGEwtVMGOmJwcA AIBLcQVvWaIsk341dbCQoHdPif3rw31VFydGxV6s07b+KuGt6bL1YsaBAAAA8AYU5y2rNI9h zdkYIVBpSlYpDeX7mpRrSpzMKP67+rTHMe9OfLVjroMXTB1aGcV0kwMAAMDVeSNvmVZwc7Ks d5at8lN1pY4zkfIcoyBbM+ZMcgAAALg2xXnL0sM7kmVZILv6T4RUsza3XyHObo3IS9Xh3tZ1 Lf42Y/rJAQAA4Nq8jbfs3tZyOrH75N7W886oWNot6zTtgZMryur2Luthx3SSAwAAwNUpy1u2 Yt8yS5aJFft6wnJwi7WN4S0bI6rk8TToslCKd7gYVvmPn0a/LWCDDAAAgHenIG/ZC9DuKBZy AQAAwAspyFv2ApQsY8oQAAAAXsl7e8v0fCWuMgAAAHgh7+0tAwAAACiGC3rLzuClAwAAAAjB WwYAAABQBHjLAPIYN1XZ+Qci97bmRyf7kLkP86l7/ojKn7pDdmHbTt7+bprwahY3K43Y82qm lY63rDCes5OZcQ5VUNC6t3L6y+wpBxjkHZmQVaUD6r/vWHjUJT6C3TvzkrLMaVSBskw9d/6t aCackon2iptWpp87o2UjG25JmTTcQjO3ogc9xckDirWv5wE8t5lZey6EN0L6WLyhdLxlRSEu mTpPPQ7cXI7a3XY482Dr2608WVbXtdi6t2hZti9HXeIjeLUsOwenadStqdub8AqYt6KT0pJl wQuwi3GwlF7d2XbCtQ6XQ57ijAHlSW6/ZzczeYtSI2Fi120qHW9ZSUTHpfenZMaB+xU03f5Z j4H4HiNek8bXQvlFyDhFYYop3gDO983oS8dSV9yaqm5vbT0+5d6Xb6/y8+1XpVtf6O22i7zH 62BNjN6aqmmHXB3fg1/RXS+xbNFUp4W3klX5pJ6P+nZsS2qVphwWHxl7Stq765J6KbXtXn8m PzIH3DZZeXoZ9LeaccjcwmBryTL7bONk2XRv67ptO/ddK085Nj1w5gkvjq9uuQUqWCdNzDP3 KU5+KyYOKKYss18C1qNt93wBzUy8fcKr6Q3Q6tmv6va+sfTLesu8f0tGfT2s27ZRY5QM9NMr 0h6DaNRLGLidb1Gz95v6MI5pyzL361r6k3nvdNmQqXza1ZO/xVsmq2m9mZXvU7oRZp5W0ULv yNT50XXLJXZ6SZ4iNvtN2qu82Uve18k+vhifE6vUp5AfLbY2qEDqmG9USbRdBRptX+jPhUfG DN9222Tk6dCpsofQZc6taKatojdYEL+rWfr3i8H70vd0Xyv/wlmTFbOPdtgAM4K+tu4raCG/ 5ac44a2YMaAEF0TcQeFNa7XI7vlCmpn0sg+vppvncOOomm8oHW9ZQXQXa3w33IQsCwK3ljT7 okwZufs4s8PIlLshFFNlmVNQGtPwPulbX09tkGWhIJYvsLDt8aNr52lXbassU/X1k3tVSdUr ZuW9Xop6on+D35q6rrtLFvvQZqs0lJR6OY0KpCR3qiRrJL8MGG23+zP1kZmtxWPVbZOR51LC cRz2bkXRTEvATdp6qywTI+bcvWR+U3BvWhPv+VDhM1/pjHTbXtQxWQOK6y3TgWaLzJ53i3l2 M1Meg7ChM3kGb4yNpV/WW3ZKbtYSdTPQZKW3zMxz8UvxVGH/haNLWuUtcwpKYyz81rvdj5Jl 9lPmtH36wh6kSapaPJYttN1t2twlPkSWue+iqHq3pmpu97bpZqD1Wz6lSsFbcRHn0i/ddRmy zGm7Vfn0R2a2Fo9Vt01Onk66SMQs34pG05WTVFelnyRKu7ZbZVne9+BDZdmGF3WYIm1AeY0s e04z18iymTzvbV3X4u9tpb+9t8x0h24MXF+Q/lJrftPN1iZOZZRDxxzX8r6NRhmH+QQF+V8g ule7M9TK6BnLC8RT488g5LyBjdqElXHbfm9rvSbazTMaC+febZqNl9jppU2yzL99jdumbpqm vT/ubdM0XZszqqR8VAkV9genZRVizoUNSdRTnDTC5TwyZhW33TbpeSYkG72eC7eiLCcenu1O zr20WhyYeQaZL920iw3Q4bpf8icxk57ipPEoY0BJlGVmi9bJsic1M+k7eHw1nTynJlpO6fzS 391bZkqAjYGbCpq+boobwgzcgvjuPGUpAxcapb4Uz9d/zLVu2+jdpGKOASKmX1CeLNPxp5bq /kzq59Ah0Ocpg9Urxmp7WHkzz0W3x2wHbL3Edi9tk2V2L+nwUdlYw29qlcL+mpefUZ/4d53Z 0LleNp/ihfV5yY/MAbdNTp5m2ugh7byW1kU3O9P0mtgPbFK+rjiw8hwbP7hooy5ZegE7usz2 uyznmPsUJ7oJkgeUVFlmtShPlj23mUmqzLyacZ7Tu6r/NBzP8kt/e28ZwInQX7xy3HvwNJK1 69PgtnkaiQM+vJLkJ+CQq7lc+rt7ywDOhBpf95rShn0pXJZx2xwLwqxwsh6A3a9mSul4ywBO hJpjwudRJOXJMm6b51LgHQA9+ddmz6uZlhfeMgAAAIAiwFsGAAAAUAR4ywAAAACKAG8ZwEH4 6whSN11y2Jg8ZOvaifGX7E9ZT7P7bjEAAAWBt+x1vHB8ibZaOW5Azdoq61ns/POacK+naXfz AmWZueX09s7Y0qU5aYvb3YEf3gHAnuAtexXid7JPf7F3e94PW1KO26gfQpE/Sjqox4O2Ftn0 k8uy8kRQeTUCgDPzf6Ky76mhxAPLAAAAAElFTkSuQmCC --------------41656884F05F54FE2D846485-- --------------41B3C589A46F310E69224AD0-- --------------1D7278221C16F1A8A1E267B5 Content-Type: application/octet-stream; name="CAM-over-IPv6-over-Ethernet.pcap" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="CAM-over-IPv6-over-Ethernet.pcap" 1MOyoQIABAAAAAAAAAAAAP//AAABAAAAFzKGV1IrBQBnAAAAZwAAADMzAAAAATAUSuZHjYbd YAAAAAAxEQH+gAAAAAAAADIUSv/+5keN/wIAAAAAAAAAAAAAAAAAAYA4w1AAMbcEAQIAAAAX sR4AKYnaT01S0l7HcMsAADctFgAAAAAAHwEwSoALqYAP/8A= --------------1D7278221C16F1A8A1E267B5-- From nobody Wed Feb 14 01:23:34 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29ADF126B6D for ; Wed, 14 Feb 2018 01:23:33 -0800 (PST) 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 O2RUzLvPZW0F for ; Wed, 14 Feb 2018 01:23:30 -0800 (PST) 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 75D1912773A for ; Wed, 14 Feb 2018 01:23:30 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id r78so20785212wme.0 for ; Wed, 14 Feb 2018 01:23:30 -0800 (PST) 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:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=VQ2TpGcx/ee329LMqVbIKiOw9FvCgr73ElJShsBXyAU=; b=ggjuXEH3txpsWcUjBweneEmEY29vg1vkZVSvx7E94XXE0TWNZ7sOgFi8ts5D6bopUD uWcaacsCTtBVrRYapxxdI/GTvLNgjPUbe6sxzwnecp84JC5TSVe6faIcyqvKwdZIYoXY W9bPHE72qfG1IokOD802E2peS+gF2SZh8rMfwqCJQbWJ0NKbAyxZTc1kbsyuMnPOZQFZ 4JWF2GaEXOBM9Ooym/npzLobvD+3w0LoP/TvFKlMNtAUNxv6ztgYpfc0gs+kW5zL15o7 9PcR2HyJ1UgPOYiCnGG36HqPBClsMiHgqjhyMtAmLbeMwvoCjntX2jDdX60uhHkoAlb1 UzhA== 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 :in-reply-to:references:organization:mime-version :content-transfer-encoding; bh=VQ2TpGcx/ee329LMqVbIKiOw9FvCgr73ElJShsBXyAU=; b=oU2MW/QoUxj4/jQ3dqDzQUELNsQMFqPqkz6AIpIkZHic/+6gHIGknIE5JEXgPlfOvi 8jcQQJGTlbZKDpgbP29qQZUBhO9y0VVmfgDLxwaYdglCad6/0n9qr2+QvQU3ypdZZE5a sEO+1DmCaB5Nt/398Tl+8Gg2tX1ws/IMO3OuK+VArq5kjgHxCvjSMuFVoQiGto2WZPIK EMyx4GDm4GEVMVc8QUZLN+5/AUZ2YWm8xDmR2pv01IOsLtn0rhBQ4xa/6/eKsJ/xNRkQ hpZQxRUIQ0AulwIo3F1r/BWtEEy7scdylsUFoWJVBGoBtepAuvdTcY9LP4aPtL3aAJmC XsDg== X-Gm-Message-State: APf1xPAkiMGbtJHq5NQNHI1toojFL0yrvhhPJitcG7KXY/7cAMO/LU26 xSaz9FTyhk83NKtBbGoy1Fps8A== X-Google-Smtp-Source: AH8x224QnolPwkTlt8RiRHBCjPq5fNUg3fUB9r8AGQmEw/rCN6NkH/zSIleg7kOYRF8a6fFEjvLjyw== X-Received: by 10.28.166.195 with SMTP id p186mr3337857wme.81.1518600208854; Wed, 14 Feb 2018 01:23:28 -0800 (PST) Received: from acorde ([2001:720:410:1010:d681:d7ff:fe28:350b]) by smtp.gmail.com with ESMTPSA id u22sm8089231wrf.86.2018.02.14.01.23.27 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 14 Feb 2018 01:23:28 -0800 (PST) Message-ID: <1518600207.4306.12.camel@it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano Reply-To: cjbc@it.uc3m.es To: Alexandre Petrescu Cc: draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org, "its@ietf.org" , Russ Housley , "suresh@kaloom.com" Date: Wed, 14 Feb 2018 10:23:27 +0100 In-Reply-To: References: <1517217856.4315.32.camel@it.uc3m.es> <1518528084.3933.6.camel@it.uc3m.es> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.3-1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 - Normative terms 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, 14 Feb 2018 09:23:33 -0000 Hi Alex, See inline below. On Tue, 2018-02-13 at 14:50 +0100, Alexandre Petrescu wrote: > Hi Carlos, > > Thanks for the reply. > > I submitted a new version for that. > > There are a few more places in section 4 that could contain normative > terms. > > These places correspond to what implementation does. > > What do you think about these suggestions? > > OLD: > > 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. > > NEW: > > 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 > MUST fragment. In case there are IP fragments, the field > "Sequence > number" of the 802.11 Data header containing the IP fragment > field > MUST be increased. Fine with me. > > OLD: > > Non-IP packets such as WAVE Short Message Protocol (WSMP) can be > delivered on 802.11-OCB links. Specifications of these packets > are > > NEW: > > Non-IP packets such as WAVE Short Message Protocol (WSMP) MAY be > delivered on 802.11-OCB links. Specifications of these packets > are Not sure we need to use normative text here. This is more descriptive (it has nothing to do with IP over 802.11-OCB, no? > > OLD: > > performing 802.11-to-Ethernet is described in Section 4.2.1. The > Ethernet Type code (EtherType) for IPv6 is 0x86DD (hexadecimal > 86DD, > or otherwise #86DD). > > NEW: > > performing 802.11-to-Ethernet is described in Section 4.2.1. The > Ethernet Type code (EtherType) for IPv6 MUST be 0x86DD > (hexadecimal > 86DD, or otherwise #86DD). Fine with me. Thanks! Carlos > Alex > > > > Le 13/02/2018 à 14:21, Carlos Jesús Bernardos Cano a écrit : > > Hi Alex, > > > > Thanks. That works for me. > > > > Please submit a new version, that I can check and then proceed with > > the > > next steps in the publication request. > > > > Thanks! > > > > Carlos > > > > On Tue, 2018-02-13 at 11:36 +0100, Alexandre Petrescu wrote: > > > Hi Carlos, > > > > > > Le 29/01/2018 à 10:24, Carlos Jesús Bernardos Cano a écrit : > > > [...] > > > > - All the text of section 4.2.1 is not normative, but more a > > > > report > > > > of > > > > what is done today in existing implementations. > > > > > > I propose the following improvement. > > > > > > OLD: > > > > 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. > > > > > > NEW: > > > > The Receiver and Transmitter Address fields in the 802.11 > > > > Data > > > > Header MUST 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 MUST be the same > > > > as > > > > the > > > > value of the Type field in the Ethernet II Header. > > > > > > Do you agree? > > > > > > > Is there any different > > > > there that is specific of 802.11-OCB? > > > > > > This is specific to 802.11 (compared to Ethernet), including > > > 802.11- > > > OCB > > > (compared to Ethernet). > > > > > > Alex From nobody Wed Feb 14 01:46:08 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53872126D73 for ; Wed, 14 Feb 2018 01:46:06 -0800 (PST) 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 ytXgfhVH1rwY for ; Wed, 14 Feb 2018 01:46:04 -0800 (PST) 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 18A99126CF9 for ; Wed, 14 Feb 2018 01:46:03 -0800 (PST) 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 w1E9k27I042539 for ; Wed, 14 Feb 2018 10:46:02 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E883820107E for ; Wed, 14 Feb 2018 10:46:01 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id DC3F1205F5C for ; Wed, 14 Feb 2018 10:46:01 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w1E9k1so011821 for ; Wed, 14 Feb 2018 10:46:01 +0100 To: its@ietf.org References: <151852907524.12902.7884670291401955587@ietfa.amsl.com> From: Alexandre Petrescu Message-ID: Date: Wed, 14 Feb 2018 10:46:01 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.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] I-D Action: draft-ietf-ipwave-ipv6-over-80211ocb-15.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, 14 Feb 2018 09:46:06 -0000 Le 13/02/2018 à 21:50, Russ Housley a écrit : > Given the recent thread on the meaning of "WiFi" I scanned through the document to see if that term is really adding value. > > I also noticed that "Wi-Fi" is a registered mark. Avoiding an argument with the owner of that mark seems desirable if the term is not adding a lot of value in the document. > > The term appears six times: > - The definition in Section 2 that started the thread. > - The Figure 3 in Section 4.2.1 (two places). > - The note below Figure 3 in Section 4.2.1. > - The ChangeLog in Appendix A > - The discussion in Appendix C. > > In most of these places, the sentence or figure is clear without "WiFi." > > In Appendix C, I think that the sentence could be easily reworded to avoid the term. I suggest: > > From the IP perspective, an 802.11-OCB MAC layer > offers practically the same interface to IP as 802.11a/b/g/n > and 802.3. > > Based on this quick analysis, I suggest that we remove "WiFi" from the document. I agree. These changes will be in -16. Alex > > Russ > > > >> On Feb 13, 2018, at 8:37 AM, internet-drafts@ietf.org wrote: >> >> >> 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 >> Jerome Haerri >> Jong-Hyouk Lee >> Thierry Ernst >> Filename : draft-ietf-ipwave-ipv6-over-80211ocb-15.txt >> Pages : 39 >> Date : 2018-02-13 >> >> 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. >> >> >> 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-15 >> https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-15 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-15 >> >> >> 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/ >> >> _______________________________________________ >> 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 Feb 14 01:50:04 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7C1A127275; Wed, 14 Feb 2018 01:50:01 -0800 (PST) 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 yb7TfCEh-gE1; Wed, 14 Feb 2018 01:50:00 -0800 (PST) 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 71E1B126CF9; Wed, 14 Feb 2018 01:50:00 -0800 (PST) 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 w1E9nww9044242; Wed, 14 Feb 2018 10:49:58 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7E1A92032DF; Wed, 14 Feb 2018 10:49:58 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 5FC04201FF7; Wed, 14 Feb 2018 10:49:58 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w1E9nwCP014483; Wed, 14 Feb 2018 10:49:58 +0100 To: cjbc@it.uc3m.es Cc: draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org, "its@ietf.org" , Russ Housley , "suresh@kaloom.com" References: <1517217856.4315.32.camel@it.uc3m.es> <1518528084.3933.6.camel@it.uc3m.es> <1518600207.4306.12.camel@it.uc3m.es> From: Alexandre Petrescu Message-ID: <73e3a79d-8b96-a9a0-77a2-2778f363dd90@gmail.com> Date: Wed, 14 Feb 2018 10:49:58 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <1518600207.4306.12.camel@it.uc3m.es> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 - Normative terms 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, 14 Feb 2018 09:50:02 -0000 Le 14/02/2018 à 10:23, Carlos Jesús Bernardos Cano a écrit : [...] >> OLD: >> >> Non-IP packets such as WAVE Short Message Protocol (WSMP) can be >> delivered on 802.11-OCB links. Specifications of these packets >> are >> >> NEW: >> >> Non-IP packets such as WAVE Short Message Protocol (WSMP) MAY be >> delivered on 802.11-OCB links. Specifications of these packets >> are > > Not sure we need to use normative text here. This is more > descriptive (it has nothing to do with IP over 802.11-OCB, no? I agree, it is more descriptive. Maybe in the future someone would like to send an WSMP over IPv6 over 802.11 OCB, or not. Hoping for that in the futhre, right now I will not use the MAY. Alex [...] From nobody Wed Feb 14 01:59:16 2018 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 71985126CF9; Wed, 14 Feb 2018 01:59:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: its@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151860235144.24678.12633699397814420395@ietfa.amsl.com> Date: Wed, 14 Feb 2018 01:59:11 -0800 Archived-At: Subject: [ipwave] I-D Action: draft-ietf-ipwave-ipv6-over-80211ocb-16.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: Wed, 14 Feb 2018 09:59:11 -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 Jerome Haerri Jong-Hyouk Lee Thierry Ernst Filename : draft-ietf-ipwave-ipv6-over-80211ocb-16.txt Pages : 39 Date : 2018-02-14 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. 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-16 https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-16 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 Wed Feb 14 02:03:40 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 286A812783A for ; Wed, 14 Feb 2018 02:03:39 -0800 (PST) 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 l3do8P6VyeGI for ; Wed, 14 Feb 2018 02:03:32 -0800 (PST) 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 E0B30126CF9 for ; Wed, 14 Feb 2018 02:03:31 -0800 (PST) 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 w1EA3TWD019014 for ; Wed, 14 Feb 2018 11:03:29 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id DC24F205FC4 for ; Wed, 14 Feb 2018 11:03:29 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id D0AE2200803 for ; Wed, 14 Feb 2018 11:03:29 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w1EA3TEv025580 for ; Wed, 14 Feb 2018 11:03:29 +0100 References: <151860235162.24678.17197961593763192283.idtracker@ietfa.amsl.com> To: "its@ietf.org" From: Alexandre Petrescu X-Forwarded-Message-Id: <151860235162.24678.17197961593763192283.idtracker@ietfa.amsl.com> Message-ID: <2e86e9fe-c95b-277f-d386-ffd6bea15579@gmail.com> Date: Wed, 14 Feb 2018 11:03:29 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <151860235162.24678.17197961593763192283.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------200CADB17783AB5402929BB4" Content-Language: fr Archived-At: Subject: [ipwave] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-16.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, 14 Feb 2018 10:03:39 -0000 This is a multi-part message in MIME format. --------------200CADB17783AB5402929BB4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi IPWAVErs, I submitted the version -16 of the IPv6-over-OCB draft. This closes remaining issues. This is the ChangeLog: o Removed the definition of the 'WiFi' term and its occurences. Clarified a phrase that used it inAppendix C "Aspects introduced by the OCB mode to 802.11". o Added more normative words: MUST be 0x86DD, MUST fragment if size larger than MTU, Sequence number in 802.11 Data header MUST be increased. Alex -------- Message transféré -------- Sujet : New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-16.txt Date : Wed, 14 Feb 2018 01:59:11 -0800 De : internet-drafts@ietf.org Pour : Jerome Haerri , ipwave-chairs@ietf.org, Jerome Haerri , Alexandre Petrescu , Alexandre Petrescu , Nabil Benamar , Thierry Ernst , Jong-Hyouk Lee A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-16.txt has been successfully submitted by Alexandre Petrescu and posted to the IETF repository. Name: draft-ietf-ipwave-ipv6-over-80211ocb Revision: 16 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: 2018-02-14 Group: ipwave Pages: 39 URL: https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-16.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-16 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-16 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-16 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. 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 --------------200CADB17783AB5402929BB4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi IPWAVErs,

I submitted the version -16 of the IPv6-over-OCB draft.

This closes remaining issues.

This is the ChangeLog:

   o  Removed the definition of the 'WiFi' term and its occurences.
      Clarified a phrase that used it in Appendix C "Aspects introduced
      by the OCB mode to 802.11".
   o  Added more normative words: MUST be 0x86DD, MUST fragment if size
      larger than MTU, Sequence number in 802.11 Data header MUST be
      increased.

Alex


-------- Message transféré --------
Sujet : New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-16.txt
Date : Wed, 14 Feb 2018 01:59:11 -0800
De : internet-drafts@ietf.org
Pour : Jerome Haerri <Jerome.Haerri@eurecom.fr>, ipwave-chairs@ietf.org, Jerome Haerri <jerome.haerri@eurecom.fr>, Alexandre Petrescu <Alexandre.Petrescu@cea.fr>, Alexandre Petrescu <alexandre.petrescu@cea.fr>, Nabil Benamar <n.benamar@est.umi.ac.ma>, Thierry Ernst <thierry.ernst@yogoko.fr>, Jong-Hyouk Lee <jonghyouk@smu.ac.kr> 


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

Name:		draft-ietf-ipwave-ipv6-over-80211ocb
Revision:	16
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:	2018-02-14
Group:		ipwave
Pages:		39
URL:            https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-16.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-16
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-16
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-16

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.

                                                                                  


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
--------------200CADB17783AB5402929BB4-- From nobody Wed Feb 14 04:43:35 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD11127444 for ; Wed, 14 Feb 2018 04:43:34 -0800 (PST) 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 pxzAoYks7VW1 for ; Wed, 14 Feb 2018 04:43:32 -0800 (PST) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::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 B51DA124234 for ; Wed, 14 Feb 2018 04:43:32 -0800 (PST) Received: by mail-oi0-x231.google.com with SMTP id b3so16371295oib.11 for ; Wed, 14 Feb 2018 04:43:32 -0800 (PST) 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=6RjlLiAMRAXomO0K74m3rRxOdMol9R5ZGUnvhIM8UXI=; b=S1KdR2I8rGhfbQL6/mkk3CyvMTLnjGjflTlrurZ6u+GulCvZ7L+MBACALRtazrQZC4 k4vlDXjvSWaZDE/SV1mly2/O2dpmbvpFn9qNLoyQYUmrAKQGss9O3svXErxSWZ1X4ZvC jY9ke5KcO9FzySUZOPLQse2RRbWuZGrwq8y9QQMXBZeD6087Sh72EociMPjrEWCQ/voj Vhsd6pcMTon1UjMBZnOQPeu3OCTEp4r5oikqV5t3F+wV5r8SsB5C0Hnjg5OVh6uPEMC4 ui9u0JLo4IVIZm0J0QDPlajDDjyUbChEqmYI1joZm17gAyAA8GQCXWBzLJ1xSCN/tv4a FKpg== 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=6RjlLiAMRAXomO0K74m3rRxOdMol9R5ZGUnvhIM8UXI=; b=ZqfZcej3QpxDEXu6XRnO8qsKYzjClCctusVfAlHWmI6q4MkQO73nTNj21CgAwDBi+5 G/XxRFSLWhVP+zf5QVin4znyiPwc+EQjHGoZmBSZ22R88rQFYAJD3DbDIwmJfljX/mIu CK+MYNCABmh2CAI1bAKL7P5ny32t81abf+9qSOsi+pzmTc7xbKtJNi/IgNISrUlAQgu2 v+v4p0yPrAjWqSYOS6tnhdVHoIToPcF93DzzKCY0yo1AmOarcImupOBMdk0qD12UJ+l3 4GalQkU2lt8xy0ncMHbLf4FoX3RIfe7vf38QO9KsM9cIyFCdvxbo7lBTGgnArxX9nrL/ 2wew== X-Gm-Message-State: APf1xPD+iGsZA2NeJbd1UTgzR7CGqKdnXlFKFKMjyniHiTRrCoXpSF+8 FUheOHaTixTgdYv7trMst7l9Hfrbcgo2pOEw69o= X-Google-Smtp-Source: AH8x227xZ1S6M2xJyYrA+afXUrD/qJfqeTqcrGg1/slOeIl0rnkgQNbcpRHuOYxZShOt8YBOEMFsBhqIsp9AxClmZRs= X-Received: by 10.202.225.133 with SMTP id y127mr3206410oig.217.1518612212124; Wed, 14 Feb 2018 04:43:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.44 with HTTP; Wed, 14 Feb 2018 04:43:31 -0800 (PST) In-Reply-To: <69847686-289a-55c4-9bf2-5ea458ceb35a@gmail.com> References: <1506192164.12227.3.camel@it.uc3m.es> <390b03ec-27a6-43e3-3ea1-95715d253980@gmail.com> <97975302-2ab4-d9b9-d825-758bf2371dff@gmail.com> <69847686-289a-55c4-9bf2-5ea458ceb35a@gmail.com> From: Abdussalam Baryun Date: Wed, 14 Feb 2018 14:43:31 +0200 Message-ID: To: Alexandre Petrescu Cc: its , Margaret Cullen Content-Type: multipart/alternative; boundary="001a113d63567491ca05652b75b2" Archived-At: Subject: Re: [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: Wed, 14 Feb 2018 12:43:34 -0000 --001a113d63567491ca05652b75b2 Content-Type: text/plain; charset="UTF-8" On Wed, Feb 14, 2018 at 10:17 AM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > > > > However, did the authors find a reference to the adaptation layer >> techniques or not? >> > > Not that I am aware of. Do you want to ask them one by one? > No just one is enough. So there is no reference, then please delete this issue of Ethernet adaptation, while it has no reference, > > Did you find a reference to the adaptation layers techniques? > I was against this so why should I find something I did not put in the draft. The WG should find or they should delete, AB > > Alex > > > >> Best Regards >> >> AB >> >> >> >> IMO even the document RFC2464, should have been (more technical >> focus) referencing the protocol IEEE802.3, instead of naming >> that may >> change by time. >> >> >> I agree. >> >> There is an ongoing work on RFC2464bis (draft-hinden something), >> that could be improved with this comment. >> >> Alex >> [...] >> >> >> --001a113d63567491ca05652b75b2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Feb 14, 2018 at 10:17 AM, Alexandre Petrescu = <alexa= ndre.petrescu@gmail.com> wrote:


However, did the authors find a reference to the adaptation layer technique= s or not?

 Not that I am aware of.=C2=A0 Do you want to ask them one by one?

No just one is enough.=C2=A0So there is no refer= ence, then please delete this issue of Ethernet adaptation, while it=C2=A0h= as no reference,
=C2=A0

Did you find a reference to the adaptation layers techniques?

I was against this so why should I find something I = did not put in the draft. The WG should find or they should delete,

AB=C2=A0

Alex



Best Regards

AB



=C2=A0 =C2=A0 =C2=A0 =C2=A0 IMO even the document RFC2464, should have been= (more technical
=C2=A0 =C2=A0 =C2=A0 =C2=A0 focus) referencing the protocol IEEE802.3, inst= ead of naming
=C2=A0 =C2=A0 =C2=A0 =C2=A0 that may
=C2=A0 =C2=A0 =C2=A0 =C2=A0 change by time.


=C2=A0 =C2=A0 I agree.

=C2=A0 =C2=A0 There is an ongoing work on RFC2464bis (draft-hinden somethin= g),
=C2=A0 =C2=A0 that could be improved with this comment.

=C2=A0 =C2=A0 Alex
=C2=A0 =C2=A0 [...]



--001a113d63567491ca05652b75b2-- From nobody Wed Feb 14 04:56:01 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B688126579 for ; Wed, 14 Feb 2018 04:55:59 -0800 (PST) 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 JPlcZp1iAGkc for ; Wed, 14 Feb 2018 04:55:57 -0800 (PST) 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 1926F124D37 for ; Wed, 14 Feb 2018 04:55:56 -0800 (PST) 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 w1ECttEr007759; Wed, 14 Feb 2018 13:55:55 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 1831D2060E6; Wed, 14 Feb 2018 13:55:55 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 0838A2060C8; Wed, 14 Feb 2018 13:55:55 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w1ECtsF2029157; Wed, 14 Feb 2018 13:55:54 +0100 To: Abdussalam Baryun Cc: its , Margaret Cullen References: <1506192164.12227.3.camel@it.uc3m.es> <390b03ec-27a6-43e3-3ea1-95715d253980@gmail.com> <97975302-2ab4-d9b9-d825-758bf2371dff@gmail.com> <69847686-289a-55c4-9bf2-5ea458ceb35a@gmail.com> From: Alexandre Petrescu Message-ID: <7a9c38e1-423f-29a0-ab78-795345095695@gmail.com> Date: Wed, 14 Feb 2018 13:55:54 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.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] 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: Wed, 14 Feb 2018 12:55:59 -0000 Le 14/02/2018 à 13:43, Abdussalam Baryun a écrit : > > > On Wed, Feb 14, 2018 at 10:17 AM, Alexandre Petrescu > > wrote: > > > > > However, did the authors find a reference to the adaptation > layer techniques or not? > > > Not that I am aware of.  Do you want to ask them one by one? > > > No just one is enough. So there is no reference, then please delete this > issue of Ethernet adaptation, while it has no reference, The Ethernet Adaptation Layer reference is this draft. > Did you find a reference to the adaptation layers techniques? > > > I was against this so why should I find something I did not put in the > draft. The WG should find or they should delete, See above. Alex > > AB > > > Alex > > > > Best Regards > > AB > > > >         IMO even the document RFC2464, should have been (more > technical >         focus) referencing the protocol IEEE802.3, instead of > naming >         that may >         change by time. > > >     I agree. > >     There is an ongoing work on RFC2464bis (draft-hinden > something), >     that could be improved with this comment. > >     Alex >     [...] > > > From nobody Wed Feb 14 04:59:03 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5263E126579 for ; Wed, 14 Feb 2018 04:59:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56CDvvKB1cz0 for ; Wed, 14 Feb 2018 04:58:59 -0800 (PST) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::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 BFD87124234 for ; Wed, 14 Feb 2018 04:58:59 -0800 (PST) Received: by mail-oi0-x22b.google.com with SMTP id j15so16418089oii.5 for ; Wed, 14 Feb 2018 04:58:59 -0800 (PST) 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=uGOboqMlDGsXK2RtLLctlcFLKjs59TOPj91eghHnito=; b=tGBEJjD1DYDzRHQjGN5ikVQalaW+nJo2Ui7rlOXpUahwPEdQaaz7vUq+gKUGvPu2He jPaYMCmeepaXLdBkl0IBMiI9bN9PpqCPpsL8tKeOqB0Rh526edCjMITPSY+di2flDWkR Y0/4fVPQJtZ95vU2dz0Q1erZv7usNqFV3FmnqciHk/RrU/j+jdqu6JD5vHow1w7G0nzA +ZiQkC37EXdWYKZIE+eINmyRJt3g5Jo0OORatCPzVPpkgkkF4PQR5qI9Oy01tM9KRdjt FdX0tTkIEboEAlWcgfLvSgAaC+uVsuN9ySNePGH7kbCO8X0tqXVf+dxiK5c6WWPUNbmk L6kg== 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=uGOboqMlDGsXK2RtLLctlcFLKjs59TOPj91eghHnito=; b=mlZ69yYUnFvyrTeBOOu04OA3Or7u5nUQKlm4RbZCM6e8R6n8lPsARckSS8qFNWlIhK y7OpWSQyoeia19QZkROBCRhcFJTHjAjKJFpoFY7fzI68twKeMEV9XXXxnHIYej3JxZWz SjDooTtINOMS3xzrS0ux29Pvqsii1x43AIyhuHz1IKqQlENKfN+6b0RVupFtzZvMQYtA nxdKbGkRHOIpUCvLH9mEUvmZW7vXzwm/TwQmQU2337dJeSwY8dzZK7oZ623QoUzPpk6A /avgSeX+koXTPg2jmPeC8XugyvFFVTvDl5/qvcfmrgjsTEJ/09XPfJ3yjVelq7aDf8Fv h+8Q== X-Gm-Message-State: APf1xPA7Q/ob6cKNb0NjPVNh0jPjH0nccNEBc0hERdVlPxpmijHQd81o LbfapShHfWXfi+IsIzgCPVUyKU0wInOA4Pmck4g= X-Google-Smtp-Source: AH8x225COAh1QauNV31bewfyyFSmJbYO4P7kHKzR0/CbCQ0E3qZiiLnS7VfK84EFlyq+KR8UG5y/3xL6zqr//txk/KM= X-Received: by 10.202.190.8 with SMTP id o8mr3214947oif.334.1518613139150; Wed, 14 Feb 2018 04:58:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.44 with HTTP; Wed, 14 Feb 2018 04:58:58 -0800 (PST) In-Reply-To: <7a9c38e1-423f-29a0-ab78-795345095695@gmail.com> References: <1506192164.12227.3.camel@it.uc3m.es> <390b03ec-27a6-43e3-3ea1-95715d253980@gmail.com> <97975302-2ab4-d9b9-d825-758bf2371dff@gmail.com> <69847686-289a-55c4-9bf2-5ea458ceb35a@gmail.com> <7a9c38e1-423f-29a0-ab78-795345095695@gmail.com> From: Abdussalam Baryun Date: Wed, 14 Feb 2018 14:58:58 +0200 Message-ID: To: Alexandre Petrescu , its Content-Type: multipart/alternative; boundary="001a113ddbe0b5deec05652bac11" Archived-At: Subject: Re: [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: Wed, 14 Feb 2018 12:59:01 -0000 --001a113ddbe0b5deec05652bac11 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 14, 2018 at 2:55 PM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > > > Le 14/02/2018 =C3=A0 13:43, Abdussalam Baryun a =C3=A9crit : > >> >> >> On Wed, Feb 14, 2018 at 10:17 AM, Alexandre Petrescu < >> alexandre.petrescu@gmail.com > >> wrote: >> >> >> >> >> However, did the authors find a reference to the adaptation >> layer techniques or not? >> >> >> Not that I am aware of. Do you want to ask them one by one? >> >> >> No just one is enough. So there is no reference, then please delete this >> issue of Ethernet adaptation, while it has no reference, >> > > The Ethernet Adaptation Layer reference is this draft. before the answer was no reference and now this is, ok, If so then the draft may need to define it, AB > > > > > >> --001a113ddbe0b5deec05652bac11 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Feb 14, 2018 at 2:55 PM, Alexandre Petrescu &= lt;alexan= dre.petrescu@gmail.com> wrote:


Le 14/02/2018 =C3=A0 13:43, Abdussalam Baryun a =C3=A9crit=C2=A0:


On Wed, Feb 14, 2018 at 10:17 AM, Alexandre Petrescu <alexandre.petrescu@gmail.co= m <mailto:alexandre.petrescu@gmail.com>> wrote:




=C2=A0 =C2=A0 =C2=A0 =C2=A0 However, did the authors find a reference to th= e adaptation
=C2=A0 =C2=A0 =C2=A0 =C2=A0 layer techniques or not?


=C2=A0 =C2=A0 Not that I am aware of.=C2=A0 Do you want to ask them one by = one?


No just one is enough.=C2=A0So there is no reference, then please delete th= is issue of Ethernet adaptation, while it=C2=A0has no reference,

 The Ethernet Adaptation Layer reference is this draft.
before the answer was no reference and now this is, ok, If so t= hen the draft =C2=A0may need to define it,

AB


=C2=A0 =C2=A0

--001a113ddbe0b5deec05652bac11-- From nobody Wed Feb 14 08:40:52 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 754A512D777 for ; Wed, 14 Feb 2018 08:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 O45ufYWtEEg4 for ; Wed, 14 Feb 2018 08:40:48 -0800 (PST) Received: from resqmta-po-06v.sys.comcast.net (resqmta-po-06v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:165]) (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 7022112D775 for ; Wed, 14 Feb 2018 08:40:48 -0800 (PST) Received: from resomta-po-10v.sys.comcast.net ([96.114.154.234]) by resqmta-po-06v.sys.comcast.net with ESMTP id m06weOY731xb9m06yerTCh; Wed, 14 Feb 2018 16:40:48 +0000 Received: from [172.22.228.216] ([162.210.130.3]) by resomta-po-10v.sys.comcast.net with SMTP id m04fex2p8yFm4m04heR6a4; Wed, 14 Feb 2018 16:38:45 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Tony Li In-Reply-To: Date: Wed, 14 Feb 2018 08:38:24 -0800 Cc: Dick Roy , =?utf-8?Q?Carlos_Jes=C3=BAs_Bernardos_Cano?= , draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org, Russ Housley , suresh@kaloom.com, its@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <1517217856.4315.32.camel@it.uc3m.es> <87A7E5C11E9C48DB84FBE2CE78537448@SRA6> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3445.5.20) X-CMAE-Envelope: MS4wfOpN4xoUFAOHXuPXnXyajK8DJOG/m0COZhfX24NRzx81MvZzHL3A5ax9h1AOckS/2BaXiIMeW8CvIP5btzFnWbqjWQ1OUQg7CZdM49dHHIVaVbCNz+lw vsH9En3itXDfzccjsriixDlPtapS7ZLuExz8RoeQVaFI0Un35Uq28zgXxMClVYo+u2htw+pBMQSPVk8WfdgWWl1zZFSN6i7LMmoCVUPdbkuiY9SRB7dZ1b9V V6S8kW5ayTGLgYpOqc88lLXOjsv9d/hx2iIUF7laPfHf29LTiNLLSrteAgaHi3PtDmm7WV1S/Iz5YAGX4GgwSNHmsSHldWWehQnbQVL7y3B2xRe7l7U61BNy 756zjG3GV2f5NX57b8PI7LkJDYHTGQ== Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 - Normative text in Ethernet Adaptation Layer 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, 14 Feb 2018 16:40:51 -0000 > > This presumes there is an associated Ethernet frame in the > > picture somewhere. What if there isn't? For example, V2V or V2I = with no > > Ethernet LAN involved. >=20 > Well, do you imply that some IP packet could be sent on something = which is not 802.3? Which is further not converted to an 802.11 frame? = I have never seen such thing, but I am curious what do you mean? There are MANY historical media that are not Ethernet/802.3/802.11. = SLIP, PPP, SONET, ATM, etc=E2=80=A6. 802.3 is not a strict requirement, it=E2=80=99s just become the de-facto = standard since just about everything else has aged out.=20 Doing something else would require a truly compelling reason, and = that=E2=80=99s not at all visible. Until then, let=E2=80=99s do the = obvious thing, please. > But I dont think the future use of 4 addresses in the 802.11 Data = header will prevent mapping the Source to Source and the Destination to = Destination (802.11 to Ethernet II headers). Because if they do, that = will break many other things, like RFC2464 and potentially others. >=20 > That will be a significant departure needing much agreement. Concur. Please stick with 2 addresses for now. Tony From nobody Wed Feb 14 08:47:46 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2DB612D72F for ; Wed, 14 Feb 2018 08:47:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 UK06EC9EgpG4 for ; Wed, 14 Feb 2018 08:47:43 -0800 (PST) Received: from resqmta-po-04v.sys.comcast.net (resqmta-po-04v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:163]) (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 74530126C2F for ; Wed, 14 Feb 2018 08:47:43 -0800 (PST) Received: from resomta-po-15v.sys.comcast.net ([96.114.154.239]) by resqmta-po-04v.sys.comcast.net with ESMTP id m0ByeiIhANTLXm0DfeoVBV; Wed, 14 Feb 2018 16:47:43 +0000 Received: from [172.22.228.216] ([162.210.130.3]) by resomta-po-15v.sys.comcast.net with SMTP id m0BOeHDQcGJ06m0BReeBRB; Wed, 14 Feb 2018 16:45:41 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Tony Li In-Reply-To: Date: Wed, 14 Feb 2018 08:45:22 -0800 Cc: cjbc@it.uc3m.es, draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org, Russ Housley , "suresh@kaloom.com" , "its@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <8DFCA4C6-52C2-4039-8774-D3F7D9BF6C20@tony.li> References: <1517217856.4315.32.camel@it.uc3m.es> <1518528084.3933.6.camel@it.uc3m.es> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3445.5.20) X-CMAE-Envelope: MS4wfII8zIyv26p1+C2nvoehgpv2OdbSJ8fSfnnxbWU7FAQ9uMTs+uvMouYc+CFUNwQRLKNfd/U/c0fA7yyPMH8uJ0W/jfZ5nT+/LSo1yE4FTRqK/HGuyZfg ee54BGbYiYb3VnfnaLiYrjHFM+eqQc6MOhHVde+ET8Vl+/u/hmcX6xn47EtnSO8lJk0271c4gPN9SOjsXc8hmCfr0wp0WKB1SXAAlvMgCfofk5fa242SZk15 LD0bXMC6JYjXSIpqbLe5e+274xEHlqCMfn2y5MXjwtOsxNNOm2O6phd0JDPUkUqKObEQ4zeckKuj6AKIorbhOUsSH58zkt6NRxwSU3IDrSWCis+DohSv6gKb 3oUDwBDG Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 - Normative terms 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, 14 Feb 2018 16:47:45 -0000 > In case there are IP fragments, the field "Sequence > number" of the 802.11 Data header containing the IP fragment field > MUST be increased. I=E2=80=99d like to renew my objection to this. It=E2=80=99s a layering = violation. It=E2=80=99s painful to implement. And we haven=E2=80=99t = documented any technical need for this. Tony From nobody Wed Feb 14 08:49:51 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD28E12D7E2; Wed, 14 Feb 2018 08:49:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0imX_XwmnkmJ; Wed, 14 Feb 2018 08:49:46 -0800 (PST) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2866012D77D; Wed, 14 Feb 2018 08:49:46 -0800 (PST) Received: by mail-lf0-x229.google.com with SMTP id c188so14442505lfc.11; Wed, 14 Feb 2018 08:49:46 -0800 (PST) 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=OYByEUAH3saQ9u9VL9zQcSrlARzzVFt8+khqzzK68NY=; b=hgnwgw6q8MmT26LrsEz5DQ+yv/6wufVX4cwsT9ywJnkfOOtNrxSWoEjOVZwHlC7WrM H34h5JRLuMwNbCOAtiamHeiXKXwYTLqtf/WFfMuTZrB65kovyDHXFOsPgTh5ZPrAu1QW iq07/3UAj7Y1xwaKil+zvFhEx1PhoMKp6BlvqxCu7zDLus5pXHzb1G9LfbgpOWl4GS/F KbXOk6MHsUlP0732gM9MzOAL+ftHe8x4QJpZCYOF6xjwjXvXFaU1TlJkPasr1j+AjE1S 3/A4M9mrgjlP+QJ0apgjVERV9KJEIvmn0Q6TbscgDQMw4lMxxSv+3GpfTGyZ4gsIrXms Ylwg== 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=OYByEUAH3saQ9u9VL9zQcSrlARzzVFt8+khqzzK68NY=; b=ZkEoRmVlMiE+O9E5QbElQPPumCNL5EcS5pK2/+HxoE8oNT//pnjgZAyTsy1EOTFhTn J4oUp/+fzoB+Lv/mRYQ7v8pVI8kdkFeQJ4z9TkBI8Y1B/5SQKb/XkurUkUuPr5J2JnBz Y+OLDPIEMYx8A8FTlqKZ4BrLy1pPAzl7SVtaA2NChh9kHvulbhvtYqAIrNFKZbht9AWl isv3dNMgODpJoZNSBR8Jc5WU4SvhOVeVGcA3cN7fVitSdMCxxlLP9zp4V3A5b3nzY95E 1PmxKcZBJyOFnSPPTG7IcTKVmriIiT5cfIkL+CRoaESEy/KLxzAMzsxsl8o0Zfs4Ij12 8iWw== X-Gm-Message-State: APf1xPDqoTFmvBYkdN7RB2XAOIutbz56RK/uN8CCFwBUIw1i0MIesDTn R/FvgodC3Xlf4k3bagebv3URSriMK69NnI+XYJs= X-Google-Smtp-Source: AH8x225kPBRBS4U4E2T3u1Oj31fFSO6T9WKO2AKXIR1t38m1dIkhBTZKfWpOspjEd0tpcEWOXGSJpCTXmvoSwXLF5VY= X-Received: by 10.25.160.129 with SMTP id j123mr4022013lfe.136.1518626984075; Wed, 14 Feb 2018 08:49:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.24.20 with HTTP; Wed, 14 Feb 2018 08:49:43 -0800 (PST) In-Reply-To: References: <1517217856.4315.32.camel@it.uc3m.es> <87A7E5C11E9C48DB84FBE2CE78537448@SRA6> From: Nabil Benamar Date: Wed, 14 Feb 2018 16:49:43 +0000 Message-ID: To: Tony Li Cc: Alexandre Petrescu , "its@ietf.org" , draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org, Russ Housley , =?UTF-8?Q?Carlos_Jes=C3=BAs_Bernardos_Cano?= , Dick Roy , suresh@kaloom.com Content-Type: multipart/alternative; boundary="001a11411552eea5ef05652ee57f" Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 - Normative text in Ethernet Adaptation Layer 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, 14 Feb 2018 16:49:49 -0000 --001a11411552eea5ef05652ee57f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 Best regards Nabil Benamar ------------------- =D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88 On Wed, Feb 14, 2018 at 4:38 PM, Tony Li wrote: > > > > > This presumes there is an associated Ethernet frame in the > > > picture somewhere. What if there isn't? For example, V2V or V2I with > no > > > Ethernet LAN involved. > > > > Well, do you imply that some IP packet could be sent on something which > is not 802.3? Which is further not converted to an 802.11 frame? I have > never seen such thing, but I am curious what do you mean? > > > There are MANY historical media that are not Ethernet/802.3/802.11. SLIP= , > PPP, SONET, ATM, etc=E2=80=A6. > > 802.3 is not a strict requirement, it=E2=80=99s just become the de-facto = standard > since just about everything else has aged out. > > Doing something else would require a truly compelling reason, and that=E2= =80=99s > not at all visible. Until then, let=E2=80=99s do the obvious thing, pleas= e. > > > > But I dont think the future use of 4 addresses in the 802.11 Data heade= r > will prevent mapping the Source to Source and the Destination to > Destination (802.11 to Ethernet II headers). Because if they do, that wi= ll > break many other things, like RFC2464 and potentially others. > > > > That will be a significant departure needing much agreement. > > > Concur. Please stick with 2 addresses for now. > > Tony > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > --001a11411552eea5ef05652ee57f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1



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





<= /div>

On Wed, Feb 14, 2018 at 4:38 PM, Tony Li <ton= y.li@tony.li> wrote:


> > This presumes there is an associated Ethernet frame in the
> > picture somewhere.=C2=A0 What if there isn't? For example, V2= V or V2I with no
> > Ethernet LAN involved.
>
> Well, do you imply that some IP packet could be sent on something whic= h is not 802.3?=C2=A0 Which is further not converted to an 802.11 frame?=C2= =A0 I have never seen such thing, but I am curious what do you mean?


There are MANY historical media that are not Ethernet/802.3/802.11.= =C2=A0 SLIP, PPP, SONET, ATM, etc=E2=80=A6.

802.3 is not a strict requirement, it=E2=80=99s just become the de-facto st= andard since just about everything else has aged out.

Doing something else would require a truly compelling reason, and that=E2= =80=99s not at all visible. Until then, let=E2=80=99s do the obvious thing,= please.


> But I dont think the future use of 4 addresses in the 802.11 Data head= er will prevent mapping the Source to Source and the Destination to Destina= tion (802.11 to Ethernet II headers).=C2=A0 Because if they do, that will b= reak many other things, like RFC2464 and potentially others.
>
> That will be a significant departure needing much agreement.


Concur.=C2=A0 Please stick with 2 addresses for now.

Tony

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

--001a11411552eea5ef05652ee57f-- From nobody Wed Feb 14 09:02:07 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B3B12D777 for ; Wed, 14 Feb 2018 09:02:05 -0800 (PST) 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 RMCP5rpwJmhQ for ; Wed, 14 Feb 2018 09:02:03 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::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 DAA96126D85 for ; Wed, 14 Feb 2018 09:02:02 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id x4so18611105wmc.0 for ; Wed, 14 Feb 2018 09:02:02 -0800 (PST) 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:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=QxYYzV/FOur5DYtZRT+DXwAjsAHmIFIK+yj4v9hXAZw=; b=1nVT+2Q214otmcuoDgyTLxY9KFsB1bgpxltd/o0o9DWfmi/8PlD8mq2+Ea7UndQLjp 41hrnCbETtRjq/pyGPulxhbAXhUPxhNJJg9XYYvSONESYtvU/UrtkupX4zt1YNXmThdB lt8PZ6/fd1ttowGmQiaZ1LnjnUayDCqtAaUryYVtg14Bi0up7dajFxtbN3dAvU8vrXDC WtrRoyGStRBq26tRykg1czBhcD5E2WruSJZdvGVjP/IY0fn7aC0kbJOF5+m4JKA7qkX/ 3z/cCG4O/jnOlX7R0RO9YUydyz7g9M3imctY3bZ93aCHkQNNp38IchdK7o7tlW6vC2Cd ljaA== 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 :in-reply-to:references:organization:mime-version :content-transfer-encoding; bh=QxYYzV/FOur5DYtZRT+DXwAjsAHmIFIK+yj4v9hXAZw=; b=UsH/CeRBv8yINt+EVxOuw/vq7vc36kF2HETp1US4P4FdNUxZ618Rz7BJnNLZDc8nEQ 1S4/M4TXN3UySN7V1VQbXeNR4YHKa70rxaU9jeLz8+LPsc0Xn+KuxGwRypPqlTsFAcc7 kNX71PVvIVxyFPHLOh/9ZYOo0LYQPAJUtxovmxQlaPJye7R4RfozHrnCzlRwM1O5SYvL jertWpoEXTAUoLrJkLdssj4fWsDvFqcjqdGqcjDL9uWPMqLPxqcB2t7T4jKxa2rBnmk4 IrXclpYkB1l3e27BpzvQgOr7JBk4UlEyeMkXOjNYCKzbS2v8eF8RQrbPDHHOXL/EKic4 teIw== X-Gm-Message-State: APf1xPCOKW9gaw7l2jlKDQFYfzthpz91ESTtXTZ2G59Yuj0xgIEyDFcM pBUQiRucTb34Sn4jjmUngZa24w== X-Google-Smtp-Source: AH8x227nvY0BU+a88O0N9hXiUPuy8kd8DdmsAs6dEXKNanha71f2X9B+bLT3DQeuuvycpPU79q5Xyg== X-Received: by 10.80.153.143 with SMTP id m15mr7917712edb.145.1518627721317; Wed, 14 Feb 2018 09:02:01 -0800 (PST) Received: from acorde ([2001:720:410:1010:d681:d7ff:fe28:350b]) by smtp.gmail.com with ESMTPSA id z42sm9362699edz.39.2018.02.14.09.01.59 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 14 Feb 2018 09:02:00 -0800 (PST) Message-ID: <1518627718.4306.67.camel@it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano Reply-To: cjbc@it.uc3m.es To: Tony Li , Alexandre Petrescu Cc: draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org, Russ Housley , "suresh@kaloom.com" , "its@ietf.org" Date: Wed, 14 Feb 2018 18:01:58 +0100 In-Reply-To: <8DFCA4C6-52C2-4039-8774-D3F7D9BF6C20@tony.li> References: <1517217856.4315.32.camel@it.uc3m.es> <1518528084.3933.6.camel@it.uc3m.es> <8DFCA4C6-52C2-4039-8774-D3F7D9BF6C20@tony.li> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.3-1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 - Normative terms 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, 14 Feb 2018 17:02:06 -0000 Hi, I have to admit that I read this too quickly and I also think this should not be done. So I agree with Tony. Carlos On Wed, 2018-02-14 at 08:45 -0800, Tony Li wrote: > > In case there are IP fragments, the field "Sequence > > number" of the 802.11 Data header containing the IP fragment > > field > > MUST be increased. > > > I’d like to renew my objection to this. It’s a layering violation. > It’s painful to implement. And we haven’t documented any technical > need for this. > > Tony > > From nobody Thu Feb 15 04:06:11 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2C01241F8; Thu, 15 Feb 2018 04:06:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.634 X-Spam-Level: X-Spam-Status: No, score=-2.634 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, RCVD_IN_MSPIKE_H2=-0.001, 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 y7hRg7CwpOb8; Thu, 15 Feb 2018 04:06:08 -0800 (PST) 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 312CF129C53; Thu, 15 Feb 2018 04:06:08 -0800 (PST) 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 w1FC66Kf026996; Thu, 15 Feb 2018 13:06:06 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 611D02066A7; Thu, 15 Feb 2018 13:06:06 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 422E5200CC9; Thu, 15 Feb 2018 13:06:06 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w1FC65hc025891; Thu, 15 Feb 2018 13:06:06 +0100 To: Tony Li Cc: cjbc@it.uc3m.es, draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org, Russ Housley , "suresh@kaloom.com" , "its@ietf.org" References: <1517217856.4315.32.camel@it.uc3m.es> <1518528084.3933.6.camel@it.uc3m.es> <8DFCA4C6-52C2-4039-8774-D3F7D9BF6C20@tony.li> From: Alexandre Petrescu Message-ID: <43818536-25c2-00bd-eb83-b8a6e9a60a11@gmail.com> Date: Thu, 15 Feb 2018 13:06:05 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <8DFCA4C6-52C2-4039-8774-D3F7D9BF6C20@tony.li> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 - Normative terms 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, 15 Feb 2018 12:06:10 -0000 Le 14/02/2018 à 17:45, Tony Li a écrit : > >> In case there are IP fragments, the field "Sequence number" of the >> 802.11 Data header containing the IP fragment field MUST be >> increased. > > > I’d like to renew my objection to this. It’s a layering violation. > It’s painful to implement. And we haven’t documented any technical > need for this. Layering violation: it is an interface, not a violation. Painful to implement: yes. But it is implemented widely, you can check it on your computer: ping -s 2000 (size 2000) and wireshark in monitor mode. Technical need undocumented: I agree. Alex From nobody Thu Feb 15 04:07:22 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1747112D95C; Thu, 15 Feb 2018 04:07:21 -0800 (PST) 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 jjHMxSoSBh5r; Thu, 15 Feb 2018 04:07:18 -0800 (PST) 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 875EA1241F8; Thu, 15 Feb 2018 04:07:18 -0800 (PST) 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 w1FC7EYb020456; Thu, 15 Feb 2018 13:07:14 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 15DD6203448; Thu, 15 Feb 2018 13:07:14 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id F32C1200CC9; Thu, 15 Feb 2018 13:07:13 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w1FC7DnQ026381; Thu, 15 Feb 2018 13:07:13 +0100 To: dickroy@alum.mit.edu, "'Tony Li'" Cc: draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org, "'Russ Housley'" , suresh@kaloom.com, cjbc@it.uc3m.es, its@ietf.org References: <1517217856.4315.32.camel@it.uc3m.es> <1518528084.3933.6.camel@it.uc3m.es> <8DFCA4C6-52C2-4039-8774-D3F7D9BF6C20@tony.li> <0158E8572C8D419F9DF4D057C4204615@SRA6> From: Alexandre Petrescu Message-ID: <76b43a59-1a2c-f8b0-4002-af03c69ecc22@gmail.com> Date: Thu, 15 Feb 2018 13:07:13 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <0158E8572C8D419F9DF4D057C4204615@SRA6> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 - Normative terms 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, 15 Feb 2018 12:07:21 -0000 Le 14/02/2018 à 18:30, Dick Roy a écrit : > > > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Tony Li > Sent: Wednesday, February 14, 2018 8:45 AM > To: Alexandre Petrescu > Cc: draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org; Russ Housley; > suresh@kaloom.com; cjbc@it.uc3m.es; its@ietf.org > Subject: Re: [ipwave] Shepherd review of > draft-ietf-ipwave-ipv6-over-80211ocb-12 - Normative terms > > >> In case there are IP fragments, the field "Sequence >> number" of the 802.11 Data header containing the IP fragment field >> MUST be increased. > > > I'd like to renew my objection to this. It's a layering violation. It's > painful to implement. And we haven't documented any technical need for this. > [RR] Agreed! The real point is that fragmentation at the MAC layer is > handled by the MAC. If the network layer delivers NPDUs that don't require > fragmentation, they won't be fragmented ... nuff said. Given that there are three persons opposing this I will revert back the fragmentation MUST into an 'is' and submit a new version. Alex > > Tony > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > From nobody Thu Feb 15 04:08:55 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 394071241F8 for ; Thu, 15 Feb 2018 04:08:53 -0800 (PST) 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 5o1_bPYt8OIQ for ; Thu, 15 Feb 2018 04:08:51 -0800 (PST) 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 BC66212D940 for ; Thu, 15 Feb 2018 04:08:50 -0800 (PST) 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 w1FC8lJU021048; Thu, 15 Feb 2018 13:08:47 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6E660201692; Thu, 15 Feb 2018 13:08:47 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 5C45A200CC9; Thu, 15 Feb 2018 13:08:47 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w1FC8lrd027219; Thu, 15 Feb 2018 13:08:47 +0100 To: dickroy@alum.mit.edu, "'Abdussalam Baryun'" Cc: mrcullen42@gmail.com, "'its'" References: <1506192164.12227.3.camel@it.uc3m.es> <390b03ec-27a6-43e3-3ea1-95715d253980@gmail.com> <97975302-2ab4-d9b9-d825-758bf2371dff@gmail.com> <24809DE2FFDE44A9B11AA5ACB3A0D1BE@SRA6> <45d910cb-7a1e-4e37-12c7-aa8bd4d311bb@gmail.com> <79AE367CE5524ECF9E35CBFC5494498D@SRA6> From: Alexandre Petrescu Message-ID: <0b5ac980-b7fd-c61e-630b-3333e1b77c53@gmail.com> Date: Thu, 15 Feb 2018 13:08:47 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.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] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-08 - *DUs 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, 15 Feb 2018 12:08:53 -0000 I doubt ISO has the FL-SDU term, as Facility Layer is an ETSI term. Alex Le 14/02/2018 à 18:31, Dick Roy a écrit : > Just refer to ISO OSI model and the relevant ISO standards ... they have all > that in there already! > > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu > Sent: Tuesday, February 13, 2018 11:54 PM > To: dickroy@alum.mit.edu; 'Abdussalam Baryun' > Cc: mrcullen42@gmail.com; 'its' > Subject: Re: [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-08 - > *DUs > > It is worth writing a terminology draft about *DUs, maybe it will get > the terms to be more used. > > Alex > > Le 13/02/2018 à 18:51, Dick Roy a écrit : >> >> >> -----Original Message----- >> From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu >> Sent: Tuesday, February 13, 2018 4:15 AM >> To: dickroy@alum.mit.edu; 'Abdussalam Baryun' >> Cc: mrcullen42@gmail.com; 'its' >> Subject: Re: [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-08 - >> *DUs >> >> SDUs are called Service Data Units, and FL-SDUs are Facility-layer SDUs. >> [RR] Yes, and TPDUs are NSDUs, NPDUs are MSDUs, etc.. >> >> Alex >> >> Le 13/02/2018 à 11:16, Alexandre Petrescu a écrit : >>> Le 13/02/2018 à 02:20, Dick Roy a écrit : >>>> FYI ... TPDUs are called segment, NPDUs are packets, MPDUs are frames, >>>> and >>>> PPDUs are streams if you care. >>> >>> YEs noted. >>> >>> Alex >>> [...] >>> >>> _______________________________________________ >>> its mailing list >>> its@ietf.org >>> https://www.ietf.org/mailman/listinfo/its >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >> >> > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > From nobody Thu Feb 15 04:15:18 2018 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 E9AB21270A0; Thu, 15 Feb 2018 04:15:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: its@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151869691191.7607.16349236466379337447@ietfa.amsl.com> Date: Thu, 15 Feb 2018 04:15:11 -0800 Archived-At: Subject: [ipwave] I-D Action: draft-ietf-ipwave-ipv6-over-80211ocb-17.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: Thu, 15 Feb 2018 12:15:12 -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 Jerome Haerri Jong-Hyouk Lee Thierry Ernst Filename : draft-ietf-ipwave-ipv6-over-80211ocb-17.txt Pages : 39 Date : 2018-02-15 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. 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-17 https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-17 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 Thu Feb 15 04:19:26 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87AF01267BB for ; Thu, 15 Feb 2018 04:19:25 -0800 (PST) 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 Z8GTe9v11Y3u for ; Thu, 15 Feb 2018 04:19:17 -0800 (PST) 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 81734120047 for ; Thu, 15 Feb 2018 04:19:16 -0800 (PST) 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 w1FCJF30109250 for ; Thu, 15 Feb 2018 13:19:15 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0E1F92067A4 for ; Thu, 15 Feb 2018 13:19:15 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 0306020166C for ; Thu, 15 Feb 2018 13:19:15 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w1FCJDOA032658 for ; Thu, 15 Feb 2018 13:19:14 +0100 References: <151869691215.7607.4477863832246767156.idtracker@ietfa.amsl.com> To: "its@ietf.org" From: Alexandre Petrescu X-Forwarded-Message-Id: <151869691215.7607.4477863832246767156.idtracker@ietfa.amsl.com> Message-ID: Date: Thu, 15 Feb 2018 13:19:13 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <151869691215.7607.4477863832246767156.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------98D3D47D55179388F508EBC8" Content-Language: fr Archived-At: Subject: [ipwave] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-17.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, 15 Feb 2018 12:19:25 -0000 This is a multi-part message in MIME format. --------------98D3D47D55179388F508EBC8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi IPWAVErs, I submitted a new version of the IPv6-over-OCB draft - the 17th. The ChangeLog is:         Susbtituted "MUST be increased" to "is increased" in the         MTU section, about fragmentation. The phrases in question are: NEW: > If IPv6 packets of size larger than > 1500 bytes are sent on an 802.11-OCB interface card then the IP stack > MUST fragment. In case there are IP fragments, the field "Sequence > number" of the 802.11 Data header containing the IP fragment field is > increased. OLD: > If IPv6 packets of size larger than > 1500 bytes are sent on an 802.11-OCB interface card then the IP stack > MUST fragment. In case there are IP fragments, the field "Sequence > number" of the 802.11 Data header containing the IP fragment field > MUST be increased. Alex -------- Message transféré -------- Sujet : New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-17.txt Date : Thu, 15 Feb 2018 04:15:12 -0800 De : internet-drafts@ietf.org Pour : Jerome Haerri , ipwave-chairs@ietf.org, Jerome Haerri , Alexandre Petrescu , Alexandre Petrescu , Nabil Benamar , Thierry Ernst , Jong-Hyouk Lee A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-17.txt has been successfully submitted by Alexandre Petrescu and posted to the IETF repository. Name: draft-ietf-ipwave-ipv6-over-80211ocb Revision: 17 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: 2018-02-15 Group: ipwave Pages: 39 URL: https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-17.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-17 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-17 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-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. 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 --------------98D3D47D55179388F508EBC8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi IPWAVErs,

I submitted a new version of the IPv6-over-OCB draft - the 17th.

The ChangeLog is:

        Susbtituted "MUST be increased" to "is increased" in the
        MTU section, about fragmentation.

The phrases in question are:

NEW:

                                     If IPv6 packets of size larger than
   1500 bytes are sent on an 802.11-OCB interface card then the IP stack
   MUST fragment.  In case there are IP fragments, the field "Sequence
   number" of the 802.11 Data header containing the IP fragment field is
   increased.

OLD:

                                     If IPv6 packets of size larger than
   1500 bytes are sent on an 802.11-OCB interface card then the IP stack
   MUST fragment.  In case there are IP fragments, the field "Sequence
   number" of the 802.11 Data header containing the IP fragment field
   MUST be increased.

Alex

-------- Message transféré --------
Sujet : New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-17.txt
Date : Thu, 15 Feb 2018 04:15:12 -0800
De : internet-drafts@ietf.org
Pour : Jerome Haerri <Jerome.Haerri@eurecom.fr>, ipwave-chairs@ietf.org, Jerome Haerri <jerome.haerri@eurecom.fr>, Alexandre Petrescu <Alexandre.Petrescu@cea.fr>, Alexandre Petrescu <alexandre.petrescu@cea.fr>, Nabil Benamar <n.benamar@est.umi.ac.ma>, Thierry Ernst <thierry.ernst@yogoko.fr>, Jong-Hyouk Lee <jonghyouk@smu.ac.kr> 


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

Name:		draft-ietf-ipwave-ipv6-over-80211ocb
Revision:	17
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:	2018-02-15
Group:		ipwave
Pages:		39
URL:            https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-17.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-17
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-17
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-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.

                                                                                  


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
--------------98D3D47D55179388F508EBC8-- From nobody Thu Feb 15 04:20:22 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 867131270B4 for ; Thu, 15 Feb 2018 04:20:21 -0800 (PST) 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 snlKQ2VCodV5 for ; Thu, 15 Feb 2018 04:20:15 -0800 (PST) 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 D1F97120047 for ; Thu, 15 Feb 2018 04:20:14 -0800 (PST) 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 w1FCKDem024714; Thu, 15 Feb 2018 13:20:13 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 333EF203448; Thu, 15 Feb 2018 13:20:13 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 26A6C201692; Thu, 15 Feb 2018 13:20:13 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w1FCKCxZ000771; Thu, 15 Feb 2018 13:20:13 +0100 To: Tony Li References: <151869691215.7607.4477863832246767156.idtracker@ietfa.amsl.com> Cc: "its@ietf.org" From: Alexandre Petrescu Message-ID: <4b498e61-d514-26fd-f417-184bfe36e784@gmail.com> Date: Thu, 15 Feb 2018 13:20:12 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.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] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-17.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, 15 Feb 2018 12:20:22 -0000 Tony, I hope this is fine? Alex Le 15/02/2018 à 13:19, Alexandre Petrescu a écrit : > Hi IPWAVErs, > > I submitted a new version of the IPv6-over-OCB draft - the 17th. > > The ChangeLog is: > >         Susbtituted "MUST be increased" to "is increased" in the >         MTU section, about fragmentation. > > The phrases in question are: > > NEW: > >> If IPv6 packets of size larger than >> 1500 bytes are sent on an 802.11-OCB interface card then the IP stack >> MUST fragment. In case there are IP fragments, the field "Sequence >> number" of the 802.11 Data header containing the IP fragment field is >> increased. > > OLD: > >> If IPv6 packets of size larger than >> 1500 bytes are sent on an 802.11-OCB interface card then the IP stack >> MUST fragment. In case there are IP fragments, the field "Sequence >> number" of the 802.11 Data header containing the IP fragment field >> MUST be increased. > > Alex > > -------- Message transféré -------- > Sujet : New Version Notification for > draft-ietf-ipwave-ipv6-over-80211ocb-17.txt > Date : Thu, 15 Feb 2018 04:15:12 -0800 > De : internet-drafts@ietf.org > Pour : Jerome Haerri , > ipwave-chairs@ietf.org, Jerome Haerri , > Alexandre Petrescu , Alexandre Petrescu > , Nabil Benamar , > Thierry Ernst , Jong-Hyouk Lee > > > > > A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-17.txt > has been successfully submitted by Alexandre Petrescu and posted to the > IETF repository. > > Name: draft-ietf-ipwave-ipv6-over-80211ocb > Revision: 17 > 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: 2018-02-15 > Group: ipwave > Pages: 39 > URL:https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-17.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-17 > Htmlized:https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-17 > Diff:https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-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. > > > > > 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 Thu Feb 15 05:52:38 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9ECB12DA11; Thu, 15 Feb 2018 05:52:35 -0800 (PST) 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 HVOV7PzlmB4B; Thu, 15 Feb 2018 05:52:33 -0800 (PST) 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 70F5312420B; Thu, 15 Feb 2018 05:52:33 -0800 (PST) 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 w1FDqRHj013982; Thu, 15 Feb 2018 14:52:27 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id BEED2201F9D; Thu, 15 Feb 2018 14:52:27 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A603E20692C; Thu, 15 Feb 2018 14:52:27 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w1FDqO09031404; Thu, 15 Feb 2018 14:52:27 +0100 To: dickroy@alum.mit.edu, "'Tony Li'" Cc: its@ietf.org, draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org, "'Russ Housley'" , "=?UTF-8?Q?'Carlos_Jes=c3=bas_Bernardos_Cano'?=" , suresh@kaloom.com References: <1517217856.4315.32.camel@it.uc3m.es> <87A7E5C11E9C48DB84FBE2CE78537448@SRA6> <7D76FB29BFE54E8AA9516CC1971A77E2@SRA6> From: Alexandre Petrescu Message-ID: Date: Thu, 15 Feb 2018 14:52:24 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <7D76FB29BFE54E8AA9516CC1971A77E2@SRA6> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 - Normative text in Ethernet Adaptation Layer 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, 15 Feb 2018 13:52:36 -0000 Le 14/02/2018 à 18:12, Dick Roy a écrit : > FYI ... in 802.11 data frames w/ ToDS and FromDS = 0, the 3 address format > is used and there is NO source or destination address. They are tx and rx > addresses. I dont understand what you mean by 3-address format. In the packet dumps, the Source and Destination addresses in the 802.11 Header are equal to the Transmitter (your 'tx'?) and Receiver (your 'rx'?) addresses in that header, respectively. And the ToDS and FromDS flags in that header are both reset. Further, the Ethernet II header obtained after adaptation also has these two tx and rx addresses despite FromDS and ToDS being reset. > So the comment "But I dont think the future use of 4 addresses > in the 802.11 Data header will prevent mapping the Source to Source and the > Destination to Destination (802.11 to Ethernet II headers)." is strange to > say the least Source and destination addresses only appear in the 802.11 > header when using the 4-address format with both ToDS and FromDS = 1! Well, again, the Source and Destination addresses in the 802.11 Header appear also when ToDS and FromDS are = 0. Anyone can check that. > Secondly, the only time mapping to 802.3 headers is done is when the DS > (Distribution Service in an AP) is sending a MAC frame to an 802.3 LAN. Yes, and each time we use IPv6 we use 802.3 LAN. Be it over 802.11 or over 802.11 OCB, it's always an 802.3 LAN. Because there is an adaptation layer. Were IPv6 to _not_ go through the 802.3 LAN before arriving to 802.11 then we'd have some new IPv6 Neighbor Discovery protocol that would take all these 4-addresses into account and why not the ESSID, and all the other fields in 802.11, without caring about 802.3. Alex > > RR > > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Tony Li > Sent: Wednesday, February 14, 2018 8:38 AM > To: Alexandre Petrescu > Cc: its@ietf.org; draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org; Russ > Housley; Carlos Jesús Bernardos Cano; Dick Roy; suresh@kaloom.com > Subject: Re: [ipwave] Shepherd review of > draft-ietf-ipwave-ipv6-over-80211ocb-12 - Normative text in Ethernet > Adaptation Layer > > > >>> This presumes there is an associated Ethernet frame in the >>> picture somewhere. What if there isn't? For example, V2V or V2I with no >>> Ethernet LAN involved. >> >> Well, do you imply that some IP packet could be sent on something which is > not 802.3? Which is further not converted to an 802.11 frame? I have never > seen such thing, but I am curious what do you mean? > > > There are MANY historical media that are not Ethernet/802.3/802.11. SLIP, > PPP, SONET, ATM, etc.. > > 802.3 is not a strict requirement, it's just become the de-facto standard > since just about everything else has aged out. > > Doing something else would require a truly compelling reason, and that's not > at all visible. Until then, let's do the obvious thing, please. > > >> But I dont think the future use of 4 addresses in the 802.11 Data header > will prevent mapping the Source to Source and the Destination to Destination > (802.11 to Ethernet II headers). Because if they do, that will break many > other things, like RFC2464 and potentially others. >> >> That will be a significant departure needing much agreement. > > > Concur. Please stick with 2 addresses for now. > > Tony > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > From nobody Thu Feb 15 08:30:42 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D42112DA68 for ; Thu, 15 Feb 2018 08:30:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 0rYS9xaAWX00 for ; Thu, 15 Feb 2018 08:30:38 -0800 (PST) Received: from resqmta-po-07v.sys.comcast.net (resqmta-po-07v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:166]) (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 73C24127873 for ; Thu, 15 Feb 2018 08:30:38 -0800 (PST) Received: from resomta-po-13v.sys.comcast.net ([96.114.154.237]) by resqmta-po-07v.sys.comcast.net with ESMTP id mMQ0e9IyXat5WmMQgecJ6A; Thu, 15 Feb 2018 16:30:38 +0000 Received: from [172.22.228.216] ([162.210.130.3]) by resomta-po-13v.sys.comcast.net with SMTP id mMOPelf5NP78QmMOSengSS; Thu, 15 Feb 2018 16:28:36 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: tony.li@tony.li In-Reply-To: <43818536-25c2-00bd-eb83-b8a6e9a60a11@gmail.com> Date: Thu, 15 Feb 2018 08:28:17 -0800 Cc: cjbc@it.uc3m.es, draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org, Russ Housley , "suresh@kaloom.com" , "its@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <84534C43-868E-49B1-BCC6-A4FBFD32C58B@tony.li> References: <1517217856.4315.32.camel@it.uc3m.es> <1518528084.3933.6.camel@it.uc3m.es> <8DFCA4C6-52C2-4039-8774-D3F7D9BF6C20@tony.li> <43818536-25c2-00bd-eb83-b8a6e9a60a11@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3445.5.20) X-CMAE-Envelope: MS4wfH0PX0s4sJj2Wh8wj4O7PTY6ACHlPH6LsqBWKmKHyVSLQqEK0ZYnJZQfl4VXkPgxBEXds/H8zfYcdiPZvxcFiE1+F68QiQhTkiyF4e7zRPM2xuRmee7c sdZmJql1CqTOTEnADys9mcjvPZJ5C8hXy2t1UEBOuB2iHjqHvPyPdxITkaejzaHpnmpbG63wq8Lxcy6VSkinYIUAyZoplTFk/2DKh+02RbgXx89e0upiTSWc w5tsvmobEgEw9udYldVSHRkMS+XT5nIdSKeUdIUifFDeg5mAXJeCBjQqrziaWxEBlBk6I4V7leHn1PbhVaB2wIQ6ueEmtElZZXHmPb4vG9IYzd7M36uPgRUq YGe/IONV Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 - Normative terms 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, 15 Feb 2018 16:30:40 -0000 Alex, >>> In case there are IP fragments, the field "Sequence number" of the >>> 802.11 Data header containing the IP fragment field MUST be >>> increased. >> I=E2=80=99d like to renew my objection to this. It=E2=80=99s a = layering violation. >> It=E2=80=99s painful to implement. And we haven=E2=80=99t documented = any technical >> need for this. >=20 > Layering violation: it is an interface, not a violation. Sorry, but this definitely counts as a layering violation. You=E2=80=99re = requiring the 802.11 device driver header to look up into the layer 3 = packet header and determine if a fragment header is present. That has to = happen for each and every packet transmitted by the IP-OBU. Why is a = layer 2 driver digging around in L3 details? As written, this applies to ANY fragmented packet coming through the = IP-OBU, so even if the packet was fragmented on the other side of the = Internet, it=E2=80=99s got to be examined so that we can bump the = sequence number. So this isn=E2=80=99t simply something that can be = passed down from the local IP stack. > Painful to implement: yes. But it is implemented widely, you can = check it on your computer: ping -s 2000 (size 2000) and wireshark in = monitor mode. I=E2=80=99ll stipulate that IPv4 fragmentation is widely implemented. In = fact, I=E2=80=99ve helped write and debug a couple of implementations of = it. IPv6 fragmentation is, IMHO, a mistake that should have never = propagated into the protocol. I certainly haven=E2=80=99t seen a lot of = it. I=E2=80=99ll take your word that that part is implemented. However, the fragmentation part is completely separate from the request = that you=E2=80=99re making of the device driver writer. I certainly = haven=E2=80=99t seen anyone implement this particular hack in their = driver. In the one driver that I=E2=80=99ve seen in detail, this is NOT = done. AFAICT, this is still exceedingly painful. > Technical need undocumented: I agree. Ok, so why are we doing this then? =20 Tony From nobody Thu Feb 15 08:34:32 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1473512DA6F for ; Thu, 15 Feb 2018 08:34:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Th1VUpetkR-2 for ; Thu, 15 Feb 2018 08:34:29 -0800 (PST) Received: from resqmta-po-11v.sys.comcast.net (resqmta-po-11v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F45712D949 for ; Thu, 15 Feb 2018 08:34:29 -0800 (PST) Received: from resomta-po-01v.sys.comcast.net ([96.114.154.225]) by resqmta-po-11v.sys.comcast.net with ESMTP id mMTReVIb2cWJzmMUPeydvP; Thu, 15 Feb 2018 16:34:29 +0000 Received: from [172.22.228.216] ([162.210.130.3]) by resomta-po-01v.sys.comcast.net with SMTP id mMSIeyqzXKMyImMSLevKTq; Thu, 15 Feb 2018 16:32:27 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: tony.li@tony.li In-Reply-To: <4b498e61-d514-26fd-f417-184bfe36e784@gmail.com> Date: Thu, 15 Feb 2018 08:32:17 -0800 Cc: "its@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <151869691215.7607.4477863832246767156.idtracker@ietfa.amsl.com> <4b498e61-d514-26fd-f417-184bfe36e784@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3445.5.20) X-CMAE-Envelope: MS4wfLWI83so8KceXoDlinhcnyes5hUQetXR7CPPZUc4ME0WpzjVd+5JQBCRk+Lruf0vtgPAcJSoCkLd40uWLJ2+aQpNps77H80XCdpWfA+pq5wpPKMgGYFG PG/qIZ/hBHACPnbpOKX7hlhOTGF70F9/G6Df3zPTb6jdxU3JeGARiAOAsRc4cC1D6msZi0xQ4HMblD0jfeHS7Q0I8PuAz228xqA= Archived-At: Subject: Re: [ipwave] New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-17.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, 15 Feb 2018 16:34:31 -0000 > I hope this is fine? Thank you for making this change while we discuss it. May I also suggest some additional wordsmithing? >>> If IPv6 packets of size larger = than >>> 1500 bytes are sent on an 802.11-OCB interface card then the IP = stack >>> MUST fragment. =20 Could you please substitute =E2=80=98the MTU=E2=80=99 instead of =E2=80=98= 1500 bytes=E2=80=99 in this sentence. If the MTU has been changed from the default of 1500 bytes, we want the = IP-OBU to fragment based on the configured MTU, not based on the = default. Since this is IPv6, this should only happen at the original packet = source. Tony From nobody Thu Feb 15 08:40:39 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CAF112E034 for ; Thu, 15 Feb 2018 08:40:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, 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 cg8Iq6J_keI0 for ; Thu, 15 Feb 2018 08:40:13 -0800 (PST) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8511912DDD0 for ; Thu, 15 Feb 2018 08:39:23 -0800 (PST) Received: by mail-lf0-x22c.google.com with SMTP id f137so376838lfe.4 for ; Thu, 15 Feb 2018 08:39:23 -0800 (PST) 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=w90GN7e4R4qriXQvKA6U5QYreYQJ4AixvdHTEFwkRGg=; b=YAzyoHhybWVwVdwFrHSZYtsGw3LZNlDVkyZOxpUezbYc+G214/lscOQ776vJJscBjk 5Xknk1gQgcFH/HP7bS730Hx4Buk59ubg4IkN1En3q3YQ16il3kpbKIB1/w05PPu26tYV F6E/jcfDT6RBQJMESq/xDhj+v3FoOTvjySyW79Du2Xwuj89ksPaDRcZcW3At2iZSttDD 5fxa61PH7X2E0c8RdW7J1F3aCV3+kaQ2rKhcjbVPNtsfRlh6l7edyZZblPzFctdUnNtx 6SL7RCQcJhq1KLgclprC5Azm/q0UQj/76xgG7n+tSOM9qJRki0ujoKLxgkJsbONz3KY3 phgw== 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=w90GN7e4R4qriXQvKA6U5QYreYQJ4AixvdHTEFwkRGg=; b=SnLawdVgizCwKMxawdaG8CERT9spqiE/AjQ9/18UA4+PvV7huMu8caSTwrMtpUGBXs gmn5lHcBbvjy8wt7WeDmROrpkvP1OLQvb0u1NqlwbBs0uwDcLqXmhVgpDnx5W2QRo0aV oSSra3AGtCmNzMlI2e7bO5D4Z9w425gnpmaM81qqAaKbYGr228P17G6Ys07FHEVy1Btl Ckc3cQVAIvBvzsPcNnlN7yfHu/9AOcgmJRI7gPpMR9dh5JdcpmOfBo2L8FfnQr/B7aM1 Fy5bV1go69v6aT9/JwWNmTeqxeBquJmF6F6mF2UP3HQVY8cgf0Ej1o6yml++mf9pR10r bIdQ== X-Gm-Message-State: APf1xPBDHVJI0LOmMn3PM2QJmPVUKsV+iEbJTS/URdLONXxW+xN9ZCeN TP2DEoKx5MxkO0ccJWEl75+bJgDZMgn6DT0pAVI= X-Google-Smtp-Source: AH8x225IeBwErj648CpJH9uShhTiBEOErqH9VjHbUpKMRSZmgZk+F2edxoeJyZOiylDaOCZsLQzvWDT9kZ/cpKAezTs= X-Received: by 10.25.19.226 with SMTP id 95mr2404533lft.57.1518712761481; Thu, 15 Feb 2018 08:39:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.24.20 with HTTP; Thu, 15 Feb 2018 08:39:20 -0800 (PST) In-Reply-To: References: <151869691215.7607.4477863832246767156.idtracker@ietfa.amsl.com> <4b498e61-d514-26fd-f417-184bfe36e784@gmail.com> From: Nabil Benamar Date: Thu, 15 Feb 2018 16:39:20 +0000 Message-ID: To: Tony Li Cc: Alexandre Petrescu , "its@ietf.org" Content-Type: multipart/alternative; boundary="001a113ea2eca9fdb2056542deba" Archived-At: Subject: Re: [ipwave] New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-17.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, 15 Feb 2018 16:40:22 -0000 --001a113ea2eca9fdb2056542deba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, I agree with Tony....We do not need to stick with the 1500 bytes value= . Best regards Nabil Benamar ------------------- =D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88 On Thu, Feb 15, 2018 at 4:32 PM, wrote: > > > I hope this is fine? > > > > Thank you for making this change while we discuss it. > > May I also suggest some additional wordsmithing? > > >>> If IPv6 packets of size larger > than > >>> 1500 bytes are sent on an 802.11-OCB interface card then the IP > stack > >>> MUST fragment. > > > Could you please substitute =E2=80=98the MTU=E2=80=99 instead of =E2=80= =981500 bytes=E2=80=99 in this > sentence. > > If the MTU has been changed from the default of 1500 bytes, we want the > IP-OBU to fragment based on the configured MTU, not based on the default. > > Since this is IPv6, this should only happen at the original packet source= . > > Tony > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > --001a113ea2eca9fdb2056542deba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, I agree with Tony....We do n= ot need to stick with the 1500 bytes value.



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





<= /div>

On Thu, Feb 15, 2018 at 4:32 PM, <tony.li@t= ony.li> wrote:

> I hope this is fine?



Thank you for making this change while we discuss it.

May I also suggest some additional wordsmithing?

>>>=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 If IP= v6 packets of size larger than
>>>=C2=A0 =C2=A0 1500 bytes are sent on an 802.11-OCB interface ca= rd then the IP stack
>>>=C2=A0 =C2=A0 MUST fragment.


Could you please substitute =E2=80=98the MTU=E2=80=99 instead of =E2= =80=981500 bytes=E2=80=99 in this sentence.

If the MTU has been changed from the default of 1500 bytes, we want the IP-= OBU to fragment based on the configured MTU, not based on the default.

Since this is IPv6, this should only happen at the original packet source.<= br>
Tony

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

--001a113ea2eca9fdb2056542deba-- From nobody Thu Feb 15 09:13:20 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D76AF1289B0; Thu, 15 Feb 2018 09:13:15 -0800 (PST) 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 WatR9uwg4Q6m; Thu, 15 Feb 2018 09:13:12 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55BCF129C56; Thu, 15 Feb 2018 09:13:12 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id c19so493459qtm.7; Thu, 15 Feb 2018 09:13:12 -0800 (PST) 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=h3zFpHQfACDg9g/BRFpFq5ybo3ivNXBowPcRHDXaATE=; b=vDM83MusUmLeEHSBCbukDGm+aRRNiciR3zKMoHtC52JLPHx4y1OATNkZ4SWG7pgnKs tLHoC6shN8ITKBtA5paRgMhr25uzXrodwOUV4YW/d/twRQzMbWlUJp95eCOSFErBSbiJ 84tEbv33O1Z6uoF7TnvF1I20+9/yNAfnZ4BWHAzmY2PtbjdNJ6ceUa6z1rnyVVaFpPzN RvDShjXR2nchz27oACycygPzj2OQZ1NOstRehZApPpQVMViwbvD6zivac+o55ufr15cc AGpqdYktZNcUEjbHlcwLi21PDsJ9AseGAFc2KYgMhnTWdmAPMfnarDXGZ1CZ+7Vx+nKf Mmvw== 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=h3zFpHQfACDg9g/BRFpFq5ybo3ivNXBowPcRHDXaATE=; b=i67UuDnKlBMLfp1g3/6XgFHqxIQZdSpHaEIdifDJ3FxK6ygJChH1jPFqXLDgsqyfy9 KAvlbBEMufS1hpd0Aylk/e6vgYfV09GttidGLCULD/YDb0WvqFnwYMG5lNA9mo6jj+4B gmlbBeIZWdZgCvU8FXxy/AEjg3wNx+ZlZzHOacH9NzjSIhvRl8yNCN+NU6YDKtdUV3CM tQIxCArnefyq5NwZLg9vYi6rokTaGCFb7JLrf7nCnjyU1wqA0dSeWfrdz5ZGaf0+d6a5 UrDJ3/0S2ErNNXo2iJO+xQM7sTvdv82ZY4yOjWAxA0TXKHpNPsiKS2W/vkf3Psjhuj/w vk2g== X-Gm-Message-State: APf1xPAN33wadXhEisPK8U5i1UQqBwgOh4yU0UOUOw+tXOCbHYz+o9FQ /Th5iQshPaYHMe94c2L+LWg= X-Google-Smtp-Source: AH8x227qQpGk/qZ7adfzxkDswCVPyO4pIicrEqYT8Zbx78Z3s2XNHmeAD5f+VlIuZs/RwkOcW1/j+g== X-Received: by 10.237.57.100 with SMTP id l91mr5434778qte.25.1518714791484; Thu, 15 Feb 2018 09:13:11 -0800 (PST) Received: from FrancoisPC (pool-108-48-182-86.washdc.fios.verizon.net. [108.48.182.86]) by smtp.gmail.com with ESMTPSA id f197sm8317277qka.3.2018.02.15.09.13.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Feb 2018 09:13:10 -0800 (PST) From: =?UTF-8?Q?Fran=C3=A7ois_Simon?= To: "'Alexandre Petrescu'" , , "'Tony Li'" Cc: , "'Russ Housley'" , =?UTF-8?Q?'Carlos_Jes=C3=BAs_Bernardos_Cano'?= , , References: <1517217856.4315.32.camel@it.uc3m.es> <87A7E5C11E9C48DB84FBE2CE78537448@SRA6> <7D76FB29BFE54E8AA9516CC1971A77E2@SRA6> In-Reply-To: Date: Thu, 15 Feb 2018 12:13:11 -0500 Message-ID: <016e01d3a680$42697ab0$c73c7010$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_016F_01D3A656.599372B0" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQL7ISfFSBtQJ/i74DjDJlbgILh28gIyD6U7AthUKlABOJ1fmwKs1CX1ARpSNiQB+ojDB6D2mC3Q Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 - Normative text in Ethernet Adaptation Layer 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, 15 Feb 2018 17:13:16 -0000 This is a multipart message in MIME format. ------=_NextPart_000_016F_01D3A656.599372B0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable "There are four address fields in the MAC frame format. These fields are = used to indicate the basic service set identifier (BSSID), source = address (SA), destination address (DA), transmitting STA address (TA), = and receiving STA address (RA). Certain frames might not contain some of = the address fields." In OCB: Address field 1 =3D Receiver Address (RA) Address field 2 =3D Transmitter Address (TA) (MAC address) Address field 3 =3D BSSID (all '1s') Address field 4 =3D Source Address (SA) Source Address (omitted)=20 3 address fields (1, 2, and 3) are used. ToDS and FromDS =3D 0b0 Fygs -----Original Message----- From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu Sent: Thursday, February 15, 2018 8:52 AM To: dickroy@alum.mit.edu; 'Tony Li' Cc: draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org; 'Russ Housley' = ; 'Carlos Jes=C3=BAs Bernardos Cano' = ; its@ietf.org; suresh@kaloom.com Subject: Re: [ipwave] Shepherd review of = draft-ietf-ipwave-ipv6-over-80211ocb-12 - Normative text in Ethernet = Adaptation Layer Le 14/02/2018 =C3=A0 18:12, Dick Roy a =C3=A9crit : > FYI ... in 802.11 data frames w/ ToDS and FromDS =3D 0, the 3 address=20 > format is used and there is NO source or destination address. They=20 > are tx and rx addresses. I dont understand what you mean by 3-address format. In the packet dumps, the Source and Destination addresses in the 802.11 = Header are equal to the Transmitter (your 'tx'?) and Receiver (your 'rx'?) addresses in that header, respectively. And the ToDS and FromDS = flags in that header are both reset. Further, the Ethernet II header obtained after adaptation also has these = two tx and rx addresses despite FromDS and ToDS being reset. > So the comment "But I dont think the future use of 4 addresses in the=20 > 802.11 Data header will prevent mapping the Source to Source and the=20 > Destination to Destination (802.11 to Ethernet II headers)." is=20 > strange to say the least Source and destination addresses only appear = > in the 802.11 header when using the 4-address format with both ToDS = and FromDS =3D 1! Well, again, the Source and Destination addresses in the 802.11 Header = appear also when ToDS and FromDS are =3D 0. Anyone can check that. > Secondly, the only time mapping to 802.3 headers is done is when the=20 > DS (Distribution Service in an AP) is sending a MAC frame to an 802.3 = LAN. Yes, and each time we use IPv6 we use 802.3 LAN. Be it over 802.11 or = over 802.11 OCB, it's always an 802.3 LAN. Because there is an = adaptation layer. Were IPv6 to _not_ go through the 802.3 LAN before arriving to 802.11 = then we'd have some new IPv6 Neighbor Discovery protocol that would take = all these 4-addresses into account and why not the ESSID, and all the = other fields in 802.11, without caring about 802.3. Alex >=20 > RR >=20 > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Tony Li > Sent: Wednesday, February 14, 2018 8:38 AM > To: Alexandre Petrescu > Cc: its@ietf.org ; = draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org = ; Russ=20 > Housley; Carlos Jes=C3=BAs Bernardos Cano; Dick Roy; suresh@kaloom.com = =20 > Subject: Re: [ipwave] Shepherd review of > draft-ietf-ipwave-ipv6-over-80211ocb-12 - Normative text in Ethernet=20 > Adaptation Layer >=20 >=20 >=20 >>> This presumes there is an associated Ethernet frame in the picture=20 >>> somewhere. What if there isn't? For example, V2V or V2I with no=20 >>> Ethernet LAN involved. >> >> Well, do you imply that some IP packet could be sent on something=20 >> which is > not 802.3? Which is further not converted to an 802.11 frame? I have = > never seen such thing, but I am curious what do you mean? >=20 >=20 > There are MANY historical media that are not Ethernet/802.3/802.11. =20 > SLIP, PPP, SONET, ATM, etc.. >=20 > 802.3 is not a strict requirement, it's just become the de-facto=20 > standard since just about everything else has aged out. >=20 > Doing something else would require a truly compelling reason, and=20 > that's not at all visible. Until then, let's do the obvious thing, = please. >=20 >=20 >> But I dont think the future use of 4 addresses in the 802.11 Data=20 >> header > will prevent mapping the Source to Source and the Destination to=20 > Destination > (802.11 to Ethernet II headers). Because if they do, that will break=20 > many other things, like RFC2464 and potentially others. >> >> That will be a significant departure needing much agreement. >=20 >=20 > Concur. Please stick with 2 addresses for now. >=20 > Tony >=20 > _______________________________________________ > its mailing list > its@ietf.org =20 > https://www.ietf.org/mailman/listinfo/its >=20 >=20 _______________________________________________ its mailing list its@ietf.org =20 https://www.ietf.org/mailman/listinfo/its ------=_NextPart_000_016F_01D3A656.599372B0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable RE: [ipwave] Shepherd review of = draft-ietf-ipwave-ipv6-over-80211ocb-12 - Normative text in Ethernet = Adaptation Layer

"There are four address fields in the MAC frame format. = These fields are used to indicate the basic service set identifier = (BSSID), source address (SA), destination address (DA), transmitting STA = address (TA), and receiving STA address (RA). Certain frames might not = contain some of the address fields."

In = OCB:

Address field 1 = =3D Receiver Address (RA)

Address field 2 = =3D Transmitter Address (TA) (MAC address)

Address field 3 = =3D BSSID (all '1s')

Address field 4 = =3D Source Address (SA) Source Address (omitted)

3 address = fields (1, 2, and 3) are used.

ToDS and FromDS = =3D 0b0

Fygs

-----Original = Message-----
From: its [mailto:its-bounces@ietf.org] On = Behalf Of Alexandre Petrescu
Sent: Thursday, February 15, 2018 8:52 AM
To: dickroy@alum.mit.edu; 'Tony Li' <tony.li@tony.li>
Cc: draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org; 'Russ Housley' = <housley@vigilsec.com>; 'Carlos Jes=C3=BAs Bernardos Cano' = <cjbc@it.uc3m.es>; its@ietf.org; suresh@kaloom.com
Subject: Re: [ipwave] Shepherd review of = draft-ietf-ipwave-ipv6-over-80211ocb-12 - Normative text in Ethernet = Adaptation Layer

Le 14/02/2018 = =C3=A0 18:12, Dick Roy a =C3=A9crit=C2=A0:

> FYI ... in = 802.11 data frames w/ ToDS and FromDS =3D 0, the 3 address =

> format is = used and there is NO source or destination address.  They =

> are tx and = rx addresses.

I dont = understand what you mean by 3-address format.

In the packet = dumps, the Source and Destination addresses in the 802.11 Header are = equal to the Transmitter (your 'tx'?) and Receiver = (your

'rx'?) = addresses in that header, respectively.  And the ToDS and FromDS = flags in that header are both reset.

Further, the = Ethernet II header obtained after adaptation also has these two tx and = rx addresses despite FromDS and ToDS being reset.

> So the = comment "But I dont think the future use of 4 addresses in the =

> 802.11 = Data header will prevent mapping the Source to Source and the =

> = Destination to Destination (802.11 to Ethernet II headers)." is =

> strange to = say the least  Source and destination addresses only appear =

> in the = 802.11 header when using the 4-address format with both ToDS and FromDS = =3D 1!

Well, again, = the Source and Destination addresses in the 802.11 Header appear also = when ToDS and FromDS are =3D 0.  Anyone can check = that.

> Secondly, = the only time mapping to 802.3 headers is done is when the =

> DS = (Distribution Service in an AP) is sending a MAC frame to an 802.3 = LAN.

Yes, and each = time we use IPv6 we use 802.3 LAN.  Be it over 802.11 or over  = 802.11 OCB, it's always an 802.3 LAN.  Because there is an = adaptation layer.

Were IPv6 to = _not_ go through the 802.3 LAN before arriving to 802.11 then we'd have = some new IPv6 Neighbor Discovery protocol that would take all these = 4-addresses into account and why not the ESSID, and all the other fields = in 802.11, without caring about 802.3.

Alex

> =

> = RR

> =

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

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

> Sent: = Wednesday, February 14, 2018 8:38 AM

> To: = Alexandre Petrescu

> = Cc: its@ietf.org; draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org; Russ

> Housley; = Carlos Jes=C3=BAs Bernardos Cano; Dick Roy; suresh@kaloom.com

> Subject: = Re: [ipwave] Shepherd review of

> = draft-ietf-ipwave-ipv6-over-80211ocb-12 - Normative text in Ethernet =

> Adaptation = Layer

> =

> =

> =

>>> = This presumes there is an associated Ethernet frame in the picture =

>>> = somewhere.  What if there isn't? For example, V2V or V2I with no =

>>> = Ethernet LAN involved.

>>

>> Well, = do you imply that some IP packet could be sent on something =

>> which = is

> not = 802.3?  Which is further not converted to an 802.11 frame?  I = have

> never seen = such thing, but I am curious what do you mean?

> =

> =

> There are = MANY historical media that are not Ethernet/802.3/802.11.  =

> SLIP, PPP, = SONET, ATM, etc..

> =

> 802.3 is = not a strict requirement, it's just become the de-facto =

> standard = since just about everything else has aged out.

> =

> Doing = something else would require a truly compelling reason, and =

> that's not = at all visible. Until then, let's do the obvious thing, = please.

> =

> =

>> But I = dont think the future use of 4 addresses in the 802.11 Data =

>> = header

> will = prevent mapping the Source to Source and the Destination to =

> = Destination

> (802.11 to = Ethernet II headers).  Because if they do, that will break =

> many other = things, like RFC2464 and potentially others.

>>

>> That = will be a significant departure needing much = agreement.

> =

> =

> = Concur.  Please stick with 2 addresses for now.

> =

> = Tony

> =

> = _______________________________________________

> its = mailing list

> its@ietf.org

> https://www.ietf.org/mailman/listinfo/its<= SPAN LANG=3D"en-us">

> =

> =

_______________________________________________

its mailing = list

its@ietf.org

https://www.ietf.org/mailman/listinfo/its<= SPAN LANG=3D"en-us">

------=_NextPart_000_016F_01D3A656.599372B0-- From nobody Thu Feb 15 09:30:28 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED3F12D775 for ; Thu, 15 Feb 2018 09:30:26 -0800 (PST) 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 nLg7fRPnwJlu for ; Thu, 15 Feb 2018 09:30:24 -0800 (PST) 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 0735512D0C3 for ; Thu, 15 Feb 2018 09:30:23 -0800 (PST) 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 w1FHUMmB046027; Thu, 15 Feb 2018 18:30:22 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id EEC61206B6B; Thu, 15 Feb 2018 18:30:21 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id DF689206B49; Thu, 15 Feb 2018 18:30:21 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w1FHULKM004478; Thu, 15 Feb 2018 18:30:21 +0100 To: Nabil Benamar , Tony Li Cc: "its@ietf.org" References: <151869691215.7607.4477863832246767156.idtracker@ietfa.amsl.com> <4b498e61-d514-26fd-f417-184bfe36e784@gmail.com> From: Alexandre Petrescu Message-ID: Date: Thu, 15 Feb 2018 18:30:21 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.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] New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-17.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, 15 Feb 2018 17:30:26 -0000 I agree, I will update (we do stick with the default 1500, but in the subsequent phrase we talk about MTU instead of 1500) Le 15/02/2018 à 17:39, Nabil Benamar a écrit : > Yes, I agree with Tony....We do not need to stick with the 1500 bytes value. > > > > Best regards > Nabil Benamar > ------------------- > نبيل بنعمرو > > > > > > > On Thu, Feb 15, 2018 at 4:32 PM, > wrote: > > > > I hope this is fine? > > > > Thank you for making this change while we discuss it. > > May I also suggest some additional wordsmithing? > > >>>                                      If IPv6 packets of size larger than > >>>    1500 bytes are sent on an 802.11-OCB interface card then the IP stack > >>>    MUST fragment. > > > Could you please substitute ‘the MTU’ instead of ‘1500 bytes’ in > this sentence. > > If the MTU has been changed from the default of 1500 bytes, we want > the IP-OBU to fragment based on the configured MTU, not based on the > default. > > Since this is IPv6, this should only happen at the original packet > source. > > Tony > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > > From nobody Thu Feb 15 09:50:25 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B68D126C2F; Thu, 15 Feb 2018 09:50:23 -0800 (PST) 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, RCVD_IN_MSPIKE_H2=-0.001, 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 G3SNdTlMztOo; Thu, 15 Feb 2018 09:50:20 -0800 (PST) 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 B8BED127863; Thu, 15 Feb 2018 09:50:19 -0800 (PST) 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 w1FHoEOf048194; Thu, 15 Feb 2018 18:50:14 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E3BD4206B42; Thu, 15 Feb 2018 18:50:14 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C91B2206AE7; Thu, 15 Feb 2018 18:50:14 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w1FHoEqA011690; Thu, 15 Feb 2018 18:50:14 +0100 To: =?UTF-8?Q?Fran=c3=a7ois_Simon?= , dickroy@alum.mit.edu, "'Tony Li'" Cc: draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org, "'Russ Housley'" , "=?UTF-8?Q?'Carlos_Jes=c3=bas_Bernardos_Cano'?=" , its@ietf.org, suresh@kaloom.com References: <1517217856.4315.32.camel@it.uc3m.es> <87A7E5C11E9C48DB84FBE2CE78537448@SRA6> <7D76FB29BFE54E8AA9516CC1971A77E2@SRA6> <016e01d3a680$42697ab0$c73c7010$@gmail.com> From: Alexandre Petrescu Message-ID: Date: Thu, 15 Feb 2018 18:50:12 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <016e01d3a680$42697ab0$c73c7010$@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 - Normative text in Ethernet Adaptation Layer 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, 15 Feb 2018 17:50:23 -0000 Mr. Simon, In all cases, the doubts here seem to be about what goes in the 802.11 Header, not about the mapping between 802.11 header and Ethernet II header. IPv6-over-OCB cares about the EthernetII Header. That has only 2 addresses. One of these is mapped into Destination address, and the other into the Source Address of the 802.11 header. That is what our IPv6-over-OCB draft says. The IPv6 layer ignores completely the BSSID value. I am not sure we want to write this aspect at all. BEsides, OCB driver implementations ignore this BSSID field as well. We say in standards its value should be "all ffs" but it works if one sets it to "fe:ff:ff:ff:ff:ff" too. Le 15/02/2018 à 18:13, François Simon a écrit : > "/There are four address fields in the MAC frame format. These fields > are used to indicate the basic service set identifier (BSSID), source > address (SA), destination address (DA), transmitting STA address (TA), > and receiving STA address (RA). Certain frames might not contain some of > the address fields.//"/ It says there are four fields and then lists five(?) If it is a quote from an IEEE standard please suggest IEEE to clarify the phrase. > In OCB: > > Address field 1 = Receiver Address (RA) > > Address field 2 = Transmitter Address (TA) (MAC address) > > Address field 3 = BSSID (all '1s') > > Address field 4 = Source Address (SA) Source Address (omitted) > > 3 address fields (1, 2, and 3) are used. The BSSID is a 5th field. In dumps it looks like this: Receiver address, Destination address, Transmitter address, Source address, BSS Id. They are 5 distinct fields containing 5 distinct values. The respective values are: 33:33::1, (the link layer multicast address for 'all-nodes' IIRC) 33:33::1, 30:14:pr:iv:ac:y, (a MAC address) 30:14:pr:iv:ac:y, ff:ff:ff:ff:ff:ff:ff. Alex > > ToDS and FromDS = 0b0 > > Fygs > > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu > Sent: Thursday, February 15, 2018 8:52 AM > To: dickroy@alum.mit.edu; 'Tony Li' > Cc: draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org; 'Russ Housley' > ; 'Carlos Jesús Bernardos Cano' ; > its@ietf.org; suresh@kaloom.com > Subject: Re: [ipwave] Shepherd review of > draft-ietf-ipwave-ipv6-over-80211ocb-12 - Normative text in Ethernet > Adaptation Layer > > Le 14/02/2018 à 18:12, Dick Roy a écrit : > >> FYI ... in 802.11 data frames w/ ToDS and FromDS = 0, the 3 address > >> format is used and there is NO source or destination address.  They > >> are tx and rx addresses. > > I dont understand what you mean by 3-address format. > > In the packet dumps, the Source and Destination addresses in the 802.11 > Header are equal to the Transmitter (your 'tx'?) and Receiver (your > > 'rx'?) addresses in that header, respectively.  And the ToDS and FromDS > flags in that header are both reset. > > Further, the Ethernet II header obtained after adaptation also has these > two tx and rx addresses despite FromDS and ToDS being reset. > >> So the comment "But I dont think the future use of 4 addresses in the > >> 802.11 Data header will prevent mapping the Source to Source and the > >> Destination to Destination (802.11 to Ethernet II headers)." is > >> strange to say the least  Source and destination addresses only appear > >> in the 802.11 header when using the 4-address format with both ToDS and FromDS = 1! > > Well, again, the Source and Destination addresses in the 802.11 Header > appear also when ToDS and FromDS are = 0.  Anyone can check that. > >> Secondly, the only time mapping to 802.3 headers is done is when the > >> DS (Distribution Service in an AP) is sending a MAC frame to an 802.3 LAN. > > Yes, and each time we use IPv6 we use 802.3 LAN.  Be it over 802.11 or > over  802.11 OCB, it's always an 802.3 LAN.  Because there is an > adaptation layer. > > Were IPv6 to _not_ go through the 802.3 LAN before arriving to 802.11 > then we'd have some new IPv6 Neighbor Discovery protocol that would take > all these 4-addresses into account and why not the ESSID, and all the > other fields in 802.11, without caring about 802.3. > > Alex > >> > >> RR > >> > >> -----Original Message----- > >> From: its [mailto:its-bounces@ietf.org] On Behalf Of Tony Li > >> Sent: Wednesday, February 14, 2018 8:38 AM > >> To: Alexandre Petrescu > >> Cc:its@ietf.org;draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org; > Russ > >> Housley; Carlos Jesús Bernardos Cano; Dick Roy;suresh@kaloom.com > >> Subject: Re: [ipwave] Shepherd review of > >> draft-ietf-ipwave-ipv6-over-80211ocb-12 - Normative text in Ethernet > >> Adaptation Layer > >> > >> > >> > >>>> This presumes there is an associated Ethernet frame in the picture > >>>> somewhere.  What if there isn't? For example, V2V or V2I with no > >>>> Ethernet LAN involved. > >>> > >>> Well, do you imply that some IP packet could be sent on something > >>> which is > >> not 802.3?  Which is further not converted to an 802.11 frame?  I have > >> never seen such thing, but I am curious what do you mean? > >> > >> > >> There are MANY historical media that are not Ethernet/802.3/802.11. > >> SLIP, PPP, SONET, ATM, etc.. > >> > >> 802.3 is not a strict requirement, it's just become the de-facto > >> standard since just about everything else has aged out. > >> > >> Doing something else would require a truly compelling reason, and > >> that's not at all visible. Until then, let's do the obvious thing, please. > >> > >> > >>> But I dont think the future use of 4 addresses in the 802.11 Data > >>> header > >> will prevent mapping the Source to Source and the Destination to > >> Destination > >> (802.11 to Ethernet II headers).  Because if they do, that will break > >> many other things, like RFC2464 and potentially others. > >>> > >>> That will be a significant departure needing much agreement. > >> > >> > >> Concur.  Please stick with 2 addresses for now. > >> > >> Tony > >> > >> _______________________________________________ > >> its mailing list > >>its@ietf.org > >>https://www.ietf.org/mailman/listinfo/its > >> > >> > > _______________________________________________ > > its mailing list > > its@ietf.org > > https://www.ietf.org/mailman/listinfo/its > From nobody Thu Feb 15 10:19:40 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64521120727 for ; Thu, 15 Feb 2018 10:19:39 -0800 (PST) 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 66DcPH4UCB8X for ; Thu, 15 Feb 2018 10:19:37 -0800 (PST) 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 3BD3D120227 for ; Thu, 15 Feb 2018 10:19:36 -0800 (PST) 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 w1FIJVVG034247; Thu, 15 Feb 2018 19:19:31 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 49D8A206B7E; Thu, 15 Feb 2018 19:19:31 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 37D07206AE7; Thu, 15 Feb 2018 19:19:31 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w1FIJUnY021857; Thu, 15 Feb 2018 19:19:31 +0100 To: dickroy@alum.mit.edu, "'Nabil Benamar'" , "'Tony Li'" Cc: its@ietf.org References: <151869691215.7607.4477863832246767156.idtracker@ietfa.amsl.com> <4b498e61-d514-26fd-f417-184bfe36e784@gmail.com> <6A3CEA154E824B31BC110423BDB2AA7E@SRA6> From: Alexandre Petrescu Message-ID: <3a0233e3-8f22-55ae-21ce-53799e08da0f@gmail.com> Date: Thu, 15 Feb 2018 19:19:30 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <6A3CEA154E824B31BC110423BDB2AA7E@SRA6> Content-Type: text/plain; charset=windows-1256; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-17.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, 15 Feb 2018 18:19:39 -0000 Le 15/02/2018 18:48, Dick Roy a crit: > You should make it clear wherever you state that an MTU is 1500 that such a > restriction applies to 802.3 ethernet, and that other DLL protocols have > other MTU sizes/lengths. WEll but here we are in that ethernet case, not in the case of other DLL protocols. When we write Internet Draft for IP over DLL protocol then we will write another value for the MTU in there. > BTW - I believe you should also make it clear, if > you are going to stress MTU sizes, that that is a MAC frame size limit, and > the MSDU (NPDU) must account for the MAC header size lest fragmentation > happen at the MAC. I believe that's what the current text tries to say. > This is why 1609.3 has a WSMMaxLength default of 1400, > not 1500. That, allow me to remark, sounds dubious. It's as if a MAC header was of precisely 100byte length... Or maybe the specifier just wanted to be on the safe side and added approximately 100 bytes to be sure. Alex > > RR > > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu > Sent: Thursday, February 15, 2018 9:30 AM > To: Nabil Benamar; Tony Li > Cc: its@ietf.org > Subject: Re: [ipwave] New Version Notification for > draft-ietf-ipwave-ipv6-over-80211ocb-17.txt > > I agree, I will update > > (we do stick with the default 1500, but in the subsequent phrase we talk > about MTU instead of 1500) > > Le 15/02/2018 17:39, Nabil Benamar a crit: >> Yes, I agree with Tony....We do not need to stick with the 1500 bytes > value. >> >> >> >> Best regards >> Nabil Benamar >> ------------------- >> >> >> >> >> >> >> >> On Thu, Feb 15, 2018 at 4:32 PM, > > wrote: >> >> >> > I hope this is fine? >> >> >> >> Thank you for making this change while we discuss it. >> >> May I also suggest some additional wordsmithing? >> >> >>> If IPv6 packets of size > larger than >> >>> 1500 bytes are sent on an 802.11-OCB interface card then the IP > stack >> >>> MUST fragment. >> >> >> Could you please substitute the MTU instead of 1500 bytes in >> this sentence. >> >> If the MTU has been changed from the default of 1500 bytes, we want >> the IP-OBU to fragment based on the configured MTU, not based on the >> default. >> >> Since this is IPv6, this should only happen at the original packet >> source. >> >> Tony >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >> >> >> > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > From nobody Thu Feb 15 10:36:12 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9915126D45; Thu, 15 Feb 2018 10:36:10 -0800 (PST) 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 It5pPUoKxaUR; Thu, 15 Feb 2018 10:36:08 -0800 (PST) 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 A847012D7E5; Thu, 15 Feb 2018 10:35:45 -0800 (PST) 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 w1FIZeIq012337; Thu, 15 Feb 2018 19:35:40 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id AA69B206BC8; Thu, 15 Feb 2018 19:35:40 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 8F8F6206BA9; Thu, 15 Feb 2018 19:35:40 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w1FIZebw026452; Thu, 15 Feb 2018 19:35:40 +0100 To: =?UTF-8?Q?Fran=c3=a7ois_Simon?= , dickroy@alum.mit.edu, "'Tony Li'" Cc: draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org, "'Russ Housley'" , "=?UTF-8?Q?'Carlos_Jes=c3=bas_Bernardos_Cano'?=" , its@ietf.org, suresh@kaloom.com References: <1517217856.4315.32.camel@it.uc3m.es> <87A7E5C11E9C48DB84FBE2CE78537448@SRA6> <7D76FB29BFE54E8AA9516CC1971A77E2@SRA6> <016e01d3a680$42697ab0$c73c7010$@gmail.com> From: Alexandre Petrescu Message-ID: Date: Thu, 15 Feb 2018 19:35:40 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <016e01d3a680$42697ab0$c73c7010$@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] addresses 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, 15 Feb 2018 18:36:11 -0000 Allow me to top post here to try to converge. The hex dump of one 802.11 header shows two addresses and a BSS Id. One such address is called "Receiver Address" and "Destination Address" at the same time. Another such address is called "Transmitter address" and "Source address" at the same time. There are only three 48bit values in there (two addresses and a BSS Id). The hex dump of the corresponding Ethernet II header shows two addresses. One is called "Destination" and the other is called "Source". There are only two 48bit values in there (no BSS Id). The current text in the draft says: > 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. This text still seems correct to me. It could be improved along two directions: (1) use "MUST contain" instead of "contain" if we wanted to make it more normative and (2) use "Receiver or Destination" instead of just "Receiver" and "Transmitter or Source" instead of just "Transmitter". The NEW text could look like this: > The Receiver or Destination address, and the Transmitter or Source > address in the 802.11 Data Header MUST contain the same values as the > Destination and the Source fields in the Ethernet II Header, > respectively. Alex Le 15/02/2018 à 18:13, François Simon a écrit : > "/There are four address fields in the MAC frame format. These fields > are used to indicate the basic service set identifier (BSSID), > source address (SA), destination address (DA), transmitting STA > address (TA), and receiving STA address (RA). Certain frames might > not contain some of the address fields.//"/ > > In OCB: > > Address field 1 = Receiver Address (RA) > > Address field 2 = Transmitter Address (TA) (MAC address) > > Address field 3 = BSSID (all '1s') > > Address field 4 = Source Address (SA) Source Address (omitted) > > 3 address fields (1, 2, and 3) are used. > > ToDS and FromDS = 0b0 > > Fygs > > -----Original Message----- From: its [mailto:its-bounces@ietf.org] On > Behalf Of Alexandre Petrescu Sent: Thursday, February 15, 2018 8:52 > AM To: dickroy@alum.mit.edu; 'Tony Li' Cc: > draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org; 'Russ Housley' > ; 'Carlos Jesús Bernardos Cano' > ; its@ietf.org; suresh@kaloom.com Subject: Re: > [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 - > Normative text in Ethernet Adaptation Layer > > Le 14/02/2018 à 18:12, Dick Roy a écrit : > >> FYI ... in 802.11 data frames w/ ToDS and FromDS = 0, the 3 address >> > >> format is used and there is NO source or destination address. They >> > >> are tx and rx addresses. > > I dont understand what you mean by 3-address format. > > In the packet dumps, the Source and Destination addresses in the > 802.11 Header are equal to the Transmitter (your 'tx'?) and Receiver > (your > > 'rx'?) addresses in that header, respectively. And the ToDS and > FromDS flags in that header are both reset. > > Further, the Ethernet II header obtained after adaptation also has > these two tx and rx addresses despite FromDS and ToDS being reset. > >> So the comment "But I dont think the future use of 4 addresses in >> the > >> 802.11 Data header will prevent mapping the Source to Source and >> the > >> Destination to Destination (802.11 to Ethernet II headers)." is > >> strange to say the least Source and destination addresses only >> appear > >> in the 802.11 header when using the 4-address format with both ToDS >> and FromDS = 1! > > Well, again, the Source and Destination addresses in the 802.11 > Header appear also when ToDS and FromDS are = 0. Anyone can check > that. > >> Secondly, the only time mapping to 802.3 headers is done is when >> the > >> DS (Distribution Service in an AP) is sending a MAC frame to an >> 802.3 LAN. > > Yes, and each time we use IPv6 we use 802.3 LAN. Be it over 802.11 > or over 802.11 OCB, it's always an 802.3 LAN. Because there is an > adaptation layer. > > Were IPv6 to _not_ go through the 802.3 LAN before arriving to 802.11 > then we'd have some new IPv6 Neighbor Discovery protocol that would > take all these 4-addresses into account and why not the ESSID, and > all the other fields in 802.11, without caring about 802.3. > > Alex > >> > >> RR > >> > >> -----Original Message----- > >> From: its [mailto:its-bounces@ietf.org] On Behalf Of Tony Li > >> Sent: Wednesday, February 14, 2018 8:38 AM > >> To: Alexandre Petrescu > >> Cc:its@ietf.org;draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org; >> > Russ > >> Housley; Carlos Jesús Bernardos Cano; Dick >> Roy;suresh@kaloom.com > >> Subject: Re: [ipwave] Shepherd review of > >> draft-ietf-ipwave-ipv6-over-80211ocb-12 - Normative text in >> Ethernet > >> Adaptation Layer > >> > >> > >> > >>>> This presumes there is an associated Ethernet frame in the >>>> picture > >>>> somewhere. What if there isn't? For example, V2V or V2I with >>>> no > >>>> Ethernet LAN involved. > >>> > >>> Well, do you imply that some IP packet could be sent on something >>> > >>> which is > >> not 802.3? Which is further not converted to an 802.11 frame? I >> have > >> never seen such thing, but I am curious what do you mean? > >> > >> > >> There are MANY historical media that are not Ethernet/802.3/802.11. >> > >> SLIP, PPP, SONET, ATM, etc.. > >> > >> 802.3 is not a strict requirement, it's just become the de-facto > >> standard since just about everything else has aged out. > >> > >> Doing something else would require a truly compelling reason, and > >> that's not at all visible. Until then, let's do the obvious thing, >> please. > >> > >> > >>> But I dont think the future use of 4 addresses in the 802.11 Data >>> > >>> header > >> will prevent mapping the Source to Source and the Destination to > >> Destination > >> (802.11 to Ethernet II headers). Because if they do, that will >> break > >> many other things, like RFC2464 and potentially others. > >>> > >>> That will be a significant departure needing much agreement. > >> > >> > >> Concur. Please stick with 2 addresses for now. > >> > >> Tony > >> > >> _______________________________________________ > >> its mailing list > >> its@ietf.org > >> https://www.ietf.org/mailman/listinfo/its > >> > >> > > _______________________________________________ > > its mailing list > > its@ietf.org > > https://www.ietf.org/mailman/listinfo/its > From nobody Thu Feb 15 10:51:38 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4AA5129C53; Thu, 15 Feb 2018 10:51:35 -0800 (PST) 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 mWUEoA5AqiDC; Thu, 15 Feb 2018 10:51:23 -0800 (PST) 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 9367112D77E; Thu, 15 Feb 2018 10:51:16 -0800 (PST) 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 w1FIpBk5039845; Thu, 15 Feb 2018 19:51:11 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D2CFB206ACA; Thu, 15 Feb 2018 19:51:11 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id B6F4E201BD5; Thu, 15 Feb 2018 19:51:11 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w1FIpB3t030451; Thu, 15 Feb 2018 19:51:11 +0100 To: dickroy@alum.mit.edu, "=?UTF-8?Q?'Fran=c3=a7ois_Simon'?=" , "'Tony Li'" Cc: draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org, "'Russ Housley'" , its@ietf.org, "=?UTF-8?Q?'Carlos_Jes=c3=bas_Bernardos_Cano'?=" , suresh@kaloom.com References: <1517217856.4315.32.camel@it.uc3m.es> <87A7E5C11E9C48DB84FBE2CE78537448@SRA6> <7D76FB29BFE54E8AA9516CC1971A77E2@SRA6> <016e01d3a680$42697ab0$c73c7010$@gmail.com> From: Alexandre Petrescu Message-ID: Date: Thu, 15 Feb 2018 19:51:11 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.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] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 - Normative text in Ethernet Adaptation Layer 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, 15 Feb 2018 18:51:36 -0000 Le 15/02/2018 19:28, Dick Roy a crit : > -----Original Message----- From: its [mailto:its-bounces@ietf.org] On > Behalf Of Alexandre Petrescu Sent: Thursday, February 15, 2018 9:50 > AM To: Franois Simon; dickroy@alum.mit.edu; 'Tony Li' Cc: > draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org; 'Russ Housley'; > its@ietf.org; 'Carlos Jess Bernardos Cano'; suresh@kaloom.com > Subject: Re: [ipwave] Shepherd review of > draft-ietf-ipwave-ipv6-over-80211ocb-12 - Normative text in Ethernet > Adaptation Layer > > Mr. Simon, > > In all cases, the doubts here seem to be about what goes in the > 802.11 > > Header, not about the mapping between 802.11 header and Ethernet II > header. > > */[RR] No. There is no doubt about what is in the 802.11 header. In > OCB, with ToDS and FromDS = 0, there are only 3 address fields. The > first contains the rx address, the second the tx address, and the > third, the broadcast MAC address/wildcard BSSID of 0xFFFFFF. This is > NOT up for debate (at this time:^))./* I agree. > IPv6-over-OCB cares about the EthernetII Header. > > */[RR] No. It cares NOTHING about ANY 802.3 MAC header. There is not > an 802.11 OCB transmission that knows ANYTING about 802.3! You are > confusing how TPDUs (segments) get from source to destination using > an IP network layer, with what happens over the various LANs that may > be in the path, and this problem is throughout the draft I suspect. > /* No. This EthernetII header is there whenever a computer sends a packet on WiFi. The captures are performed on the computer connected exclusively on WiFi, there is no wired LAN. > > That has only 2 > > addresses. > > */[RR] Yes, the 802.3 header has only a source and destination MAC > address. YEs. _And_ an EtherType. > At the equivalent to an 802.1Q conformant bridge (cf. 802.11ak for > details), the appropriate mapping from 802.11 address fields to 802.3 > addresses takes place, No, there is no 802.1q bridge on this computer where there is this mapping between 802.11 and 802.3 happens. I do not understand why you pretend there to be a bridge. We discussed this several times. If I were not sure about it I would not put in the draft this "Ethernet Adaptation Layer". > ALL unbeknownst to the IP layer. I have absolutely NO clue why all > you IETFers are so wrapped around the axle about all this. Yes, > attention to MTU sizes makes a lot of sense when trying to do QoS > across disparate LANs, such as 802.11 and 802.3 LANs, but thats NOT > YOUR PROBLEM! IMO you should stick to the network (and transport) > layer, and let the DLL guys do their job. /* > One of these is mapped into Destination address, and the > > other into the Source Address of the 802.11 header. > > */[RR] This mapping happens in bridges whose functionality is out of > IETF scope/control./* It could be out of scope but it seems it is out of scope of everybody including IEEE. Otherwise I cant explain why this bridging (that you call) happens without having a bridge software on the computer. Usually, the bridge software is called brconf, and there is a knob in the kernel called 1q. They are both absent, yet this 'bridging' that you call _is_ happening. I just call it "Adaptation Layer". > That is what our > > IPv6-over-OCB draft says. > > */[RR] If you really care about this, then change the text to get it > right otherwise people who read the draft will be of the opinion we > dont know what we are talking about./* > > The IPv6 layer ignores completely the BSSID value. I am not sure we > > want to write this aspect at all. > > */[RR] The network layer doesnt ignore it, it NEVER sees it! Any > such conversation in the draft will surely indicate to people that we > dont know what we are doing./* I agree, there is nothing about BSSID in the draft. In the future, maybe we should look at it though. It's something that could be useful in handovers. > > BEsides, OCB driver implementations ignore this BSSID field as well. > We > > say in standards its value should be "all ffs" but it works if one > sets > > it to "fe:ff:ff:ff:ff:ff" too. > > */[RR] Such drivers are technically NOT OCB conformant, but that > really doesnt matter either. OCB should NEVER have restricted the > BSSID field to be the wildcard value, but I couldnt get people to > move off such restrictive thinking, so its in the standard today. > The value of the BSSID field currently has NO impact on the protocol > at all! It could have been used for some interesting functionality, > however I lost that battle:^(((( /* > > Le 15/02/2018 18:13, Franois Simon a crit : > >> "/There are four address fields in the MAC frame format. These >> fields > >> are used to indicate the basic service set identifier (BSSID), >> source > >> address (SA), destination address (DA), transmitting STA address >> (TA), > >> and receiving STA address (RA). Certain frames might not contain >> some of > >> the address fields.//"/ > > It says there are four fields and then lists five(?) > > */[RR] Yes. You need to read clause 9 in 802.11 revmd (9.2.4.1.4, > Table 9-3, and 9.2.4.3 in particular) and you will see what I told > you in the previous posting. / It's a cumbersome phrase. > > If it is a quote from an IEEE standard please suggest IEEE to > clarify > > the phrase. > >> In OCB: > >> > >> Address field 1 = Receiver Address (RA) > >> > >> Address field 2 = Transmitter Address (TA) (MAC address) > >> > >> Address field 3 = BSSID (all '1s') > >> > >> Address field 4 = Source Address (SA) Source Address (omitted) > >> > >> 3 address fields (1, 2, and 3) are used. > > The BSSID is a 5th field. > > */[RR] NO! There are ONLY 3 or 4 address fields, not 5. Its a bit > confusing; if you want to know the details, read clause 9! /* There are only 3 fields that go on wire (src dst and BSSID). All the rest is virtual fields and notation. > In dumps it looks like this: > > Receiver address, > > Destination address, > > Transmitter address, > > Source address, > > BSS Id. > > */[RR] Yes, because wireshark can dump whatever it wants in whatever > order it wants. /* I agree. Sometimes it displayes a certain "interpretation" where some fields can be duplicated. But it also displays a 'hex dump' and that does not lie. > They are 5 distinct fields containing 5 distinct values. The > respective > > values are: > > 33:33::1, (the link layer multicast address for 'all-nodes' IIRC) > > 33:33::1, > > */[RR] These seem to be IPv6 addresses, not MAC addresses./* No, it is a common notation for MAC addresses as well; not only IPv6 notation has the benefit of reducing many 0s to just ::. It is a 48bit value that contains a MAC multicast address. It is an abbreviation of 33:33:00:00:00:1. There is an RFC for this. > 30:14:pr:iv:ac:y, (a MAC address) > > */[RR] Thats NOT a MAC address; its only 44 bits assuming the > strange code in the last four octets are really octets. /* Right, I meant privacy0. > 30:14:pr:iv:ac:y, > > ff:ff:ff:ff:ff:ff:ff. > > */[RR] Not sure what this is??? Too many bits for a broadcast MAC > address. Dont confuse wireshark output with the order of fields in a > protocol header. Its obviously not meant to be that either./* RIght, it's a 48bt all set. My copy was wrong. Alex > > *//* > > */RR/* > > Alex > >> > >> ToDS and FromDS = 0b0 > >> > >> Fygs > >> > >> -----Original Message----- > >> From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre >> Petrescu > >> Sent: Thursday, February 15, 2018 8:52 AM > >> To: dickroy@alum.mit.edu; 'Tony Li' > >> Cc: draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org; 'Russ Housley' > >> ; 'Carlos Jess Bernardos Cano' >> ; > >> its@ietf.org; suresh@kaloom.com > >> Subject: Re: [ipwave] Shepherd review of > >> draft-ietf-ipwave-ipv6-over-80211ocb-12 - Normative text in >> Ethernet > >> Adaptation Layer > >> > >> Le 14/02/2018 18:12, Dick Roy a crit : > >> > >>> FYI ... in 802.11 data frames w/ ToDS and FromDS = 0, the 3 >>> address > >> > >>> format is used and there is NO source or destination address. >>> They > >> > >>> are tx and rx addresses. > >> > >> I dont understand what you mean by 3-address format. > >> > >> In the packet dumps, the Source and Destination addresses in the >> 802.11 > >> Header are equal to the Transmitter (your 'tx'?) and Receiver >> (your > >> > >> 'rx'?) addresses in that header, respectively. And the ToDS and >> FromDS > >> flags in that header are both reset. > >> > >> Further, the Ethernet II header obtained after adaptation also has >> these > >> two tx and rx addresses despite FromDS and ToDS being reset. > >> > >>> So the comment "But I dont think the future use of 4 addresses >>> in the > >> > >>> 802.11 Data header will prevent mapping the Source to Source and >>> the > >> > >>> Destination to Destination (802.11 to Ethernet II headers)." is > >> > >>> strange to say the least Source and destination addresses only >>> appear > >> > >>> in the 802.11 header when using the 4-address format with both >>> ToDS and FromDS = 1! > >> > >> Well, again, the Source and Destination addresses in the 802.11 >> Header > >> appear also when ToDS and FromDS are = 0. Anyone can check that. > >> > >>> Secondly, the only time mapping to 802.3 headers is done is when >>> the > >> > >>> DS (Distribution Service in an AP) is sending a MAC frame to an >>> 802.3 LAN. > >> > >> Yes, and each time we use IPv6 we use 802.3 LAN. Be it over >> 802.11 or > >> over 802.11 OCB, it's always an 802.3 LAN. Because there is an > >> adaptation layer. > >> > >> Were IPv6 to _not_ go through the 802.3 LAN before arriving to >> 802.11 > >> then we'd have some new IPv6 Neighbor Discovery protocol that >> would take > >> all these 4-addresses into account and why not the ESSID, and all >> the > >> other fields in 802.11, without caring about 802.3. > >> > >> Alex > >> > >>> > >> > >>> RR > >> > >>> > >> > >>> -----Original Message----- > >> > >>> From: its [mailto:its-bounces@ietf.org] On Behalf Of Tony Li > >> > >>> Sent: Wednesday, February 14, 2018 8:38 AM > >> > >>> To: Alexandre Petrescu > >> > >>> Cc:its@ietf.org;draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org; > >>> >> Russ > >> > >>> Housley; Carlos Jess Bernardos Cano; Dick >>> Roy;suresh@kaloom.com > >> > >>> Subject: Re: [ipwave] Shepherd review of > >> > >>> draft-ietf-ipwave-ipv6-over-80211ocb-12 - Normative text in >>> Ethernet > >> > >>> Adaptation Layer > >> > >>> > >> > >>> > >> > >>> > >> > >>>>> This presumes there is an associated Ethernet frame in the >>>>> picture > >> > >>>>> somewhere. What if there isn't? For example, V2V or V2I >>>>> with no > >> > >>>>> Ethernet LAN involved. > >> > >>>> > >> > >>>> Well, do you imply that some IP packet could be sent on >>>> something > >> > >>>> which is > >> > >>> not 802.3? Which is further not converted to an 802.11 frame? >>> I have > >> > >>> never seen such thing, but I am curious what do you mean? > >> > >>> > >> > >>> > >> > >>> There are MANY historical media that are not >>> Ethernet/802.3/802.11. > >> > >>> SLIP, PPP, SONET, ATM, etc.. > >> > >>> > >> > >>> 802.3 is not a strict requirement, it's just become the >>> de-facto > >> > >>> standard since just about everything else has aged out. > >> > >>> > >> > >>> Doing something else would require a truly compelling reason, >>> and > >> > >>> that's not at all visible. Until then, let's do the obvious >>> thing, please. > >> > >>> > >> > >>> > >> > >>>> But I dont think the future use of 4 addresses in the 802.11 >>>> Data > >> > >>>> header > >> > >>> will prevent mapping the Source to Source and the Destination >>> to > >> > >>> Destination > >> > >>> (802.11 to Ethernet II headers). Because if they do, that will >>> break > >> > >>> many other things, like RFC2464 and potentially others. > >> > >>>> > >> > >>>> That will be a significant departure needing much agreement. > >> > >>> > >> > >>> > >> > >>> Concur. Please stick with 2 addresses for now. > >> > >>> > >> > >>> Tony > >> > >>> > >> > >>> _______________________________________________ > >> > >>> its mailing list > >> > >>> its@ietf.org > >> > >>> https://www.ietf.org/mailman/listinfo/its > >> > >>> > >> > >>> > >> > >> _______________________________________________ > >> > >> its mailing list > >> > >> its@ietf.org > >> > >> https://www.ietf.org/mailman/listinfo/its > >> > > _______________________________________________ > > its mailing list > > its@ietf.org > > https://www.ietf.org/mailman/listinfo/its > From nobody Thu Feb 15 10:54:09 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A86B12D777 for ; Thu, 15 Feb 2018 10:54:08 -0800 (PST) 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 1nAWdjGD_BgH for ; Thu, 15 Feb 2018 10:54:06 -0800 (PST) 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 BFC59129966 for ; Thu, 15 Feb 2018 10:54:05 -0800 (PST) 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 w1FIs127016089; Thu, 15 Feb 2018 19:54:01 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 07358206B99; Thu, 15 Feb 2018 19:54:01 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id E5356206ACA; Thu, 15 Feb 2018 19:54:00 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w1FIs0Km030925; Thu, 15 Feb 2018 19:54:00 +0100 To: dickroy@alum.mit.edu, "'Abdussalam Baryun'" Cc: mrcullen42@gmail.com, "'its'" , knut.evensen@q-free.com, hjfischer@fischer-tech.eu References: <1506192164.12227.3.camel@it.uc3m.es> <390b03ec-27a6-43e3-3ea1-95715d253980@gmail.com> <97975302-2ab4-d9b9-d825-758bf2371dff@gmail.com> <24809DE2FFDE44A9B11AA5ACB3A0D1BE@SRA6> <45d910cb-7a1e-4e37-12c7-aa8bd4d311bb@gmail.com> <79AE367CE5524ECF9E35CBFC5494498D@SRA6> <0b5ac980-b7fd-c61e-630b-3333e1b77c53@gmail.com> <4C0B3578C0EA4DF8A40F55AAEFC5F4EC@SRA6> From: Alexandre Petrescu Message-ID: <3730fd8c-8c15-6bb4-416a-933a7165ba36@gmail.com> Date: Thu, 15 Feb 2018 19:54:00 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <4C0B3578C0EA4DF8A40F55AAEFC5F4EC@SRA6> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-08 - *DUs 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, 15 Feb 2018 18:54:08 -0000 Sorry, it may be I went too fast with my statement. I googled "FS-SDU" and first entry was ETSI. But I agree that as with wikipedia, must double check before relying on google searches. Alex Le 15/02/2018 à 19:50, Dick Roy a écrit : > Wow, interesting how history keeps changing! I along with two others > created the name "Facility layer", and there most assuredly is an "FSDU" > throughout the ISO standards. ETSI TC ITS, which a few of us also > "created", simply adopted ISO 21217 as they were required to do by the > agreement between ISO TC204 and ETSI when TC ITS was created. It's a long > story ... perhaps over a beer or three sometime:^))) > > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu > Sent: Thursday, February 15, 2018 4:09 AM > To: dickroy@alum.mit.edu; 'Abdussalam Baryun' > Cc: mrcullen42@gmail.com; 'its' > Subject: Re: [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-08 - > *DUs > > I doubt ISO has the FL-SDU term, as Facility Layer is an ETSI term. > > Alex > > Le 14/02/2018 à 18:31, Dick Roy a écrit : >> Just refer to ISO OSI model and the relevant ISO standards ... they have > all >> that in there already! >> >> -----Original Message----- >> From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu >> Sent: Tuesday, February 13, 2018 11:54 PM >> To: dickroy@alum.mit.edu; 'Abdussalam Baryun' >> Cc: mrcullen42@gmail.com; 'its' >> Subject: Re: [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-08 - >> *DUs >> >> It is worth writing a terminology draft about *DUs, maybe it will get >> the terms to be more used. >> >> Alex >> >> Le 13/02/2018 à 18:51, Dick Roy a écrit : >>> >>> >>> -----Original Message----- >>> From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu >>> Sent: Tuesday, February 13, 2018 4:15 AM >>> To: dickroy@alum.mit.edu; 'Abdussalam Baryun' >>> Cc: mrcullen42@gmail.com; 'its' >>> Subject: Re: [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-08 - >>> *DUs >>> >>> SDUs are called Service Data Units, and FL-SDUs are Facility-layer SDUs. >>> [RR] Yes, and TPDUs are NSDUs, NPDUs are MSDUs, etc.. >>> >>> Alex >>> >>> Le 13/02/2018 à 11:16, Alexandre Petrescu a écrit : >>>> Le 13/02/2018 à 02:20, Dick Roy a écrit : >>>>> FYI ... TPDUs are called segment, NPDUs are packets, MPDUs are frames, >>>>> and >>>>> PPDUs are streams if you care. >>>> >>>> YEs noted. >>>> >>>> Alex >>>> [...] >>>> >>>> _______________________________________________ >>>> its mailing list >>>> its@ietf.org >>>> https://www.ietf.org/mailman/listinfo/its >>> >>> _______________________________________________ >>> its mailing list >>> its@ietf.org >>> https://www.ietf.org/mailman/listinfo/its >>> >>> >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >> >> > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > From nobody Thu Feb 15 11:35:11 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46AF212D7E7 for ; Thu, 15 Feb 2018 11:35:10 -0800 (PST) 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=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEB9xCandTaX for ; Thu, 15 Feb 2018 11:35:07 -0800 (PST) Received: from resqmta-po-02v.sys.comcast.net (resqmta-po-02v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:161]) (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 89640127241 for ; Thu, 15 Feb 2018 11:35:07 -0800 (PST) Received: from resomta-po-01v.sys.comcast.net ([96.114.154.225]) by resqmta-po-02v.sys.comcast.net with ESMTP id mPJ6eOuVpIZUwmPJDepXnB; Thu, 15 Feb 2018 19:35:07 +0000 Received: from [172.22.228.216] ([162.210.130.3]) by resomta-po-01v.sys.comcast.net with SMTP id mPGtezRSuKMyImPGveve87; Thu, 15 Feb 2018 19:33:05 +0000 From: tony.li@tony.li Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_4AAA96D7-6AF5-452B-98E6-74AA9EA53C30" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Thu, 15 Feb 2018 11:32:42 -0800 In-Reply-To: Cc: Alexandre Petrescu , =?utf-8?Q?Fran=C3=A7ois_Simon?= , draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org, Russ Housley , its , =?utf-8?Q?Carlos_Jes=C3=BAs_Bernardos_Cano?= , suresh@kaloom.com To: dickroy@alum.mit.edu References: <1517217856.4315.32.camel@it.uc3m.es> <87A7E5C11E9C48DB84FBE2CE78537448@SRA6> <7D76FB29BFE54E8AA9516CC1971A77E2@SRA6> <016e01d3a680$42697ab0$c73c7010$@gmail.com> X-Mailer: Apple Mail (2.3445.5.20) X-CMAE-Envelope: MS4wfNx1FgqX/T5UAHmLFUgi2L4ol1QobtdNFhoh3EAlKyImKx8qvP0lkR5I1bWzUaqqK3ZcJzc6FyzIa5Jt+iEm18DJxpG1Pb4nQURtVF7uh06HnhX1DeNN KGf5qQJTmD+4bIrqoSFBKNGQdiDlNiWq+G5VPk0riCAUa/33Nnzc03GNhCB/vr1CMQ1NFimq7+NUNHLKjj/s3cwLGtyhsWKtog2a+D7iVVP9/Fki+kQ8Fsyp y32rKfzWircZWv1dvcMoZGkY87pJ7wfksctjDibm6aUARg1HaN6k6gn/eDQ+mytBTeCPDWpkfIPJjUtYs6544otY51Y9yd9b89Jq+LLmubELG0LVR2nk5DVz JvGNzeiDUUiX6dKC3allZ63McfQMRMTjxeuOOgIUNnl9BpyuqEbJtiG/GjThvwqDaQuL+1mj Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 - Normative text in Ethernet Adaptation Layer 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, 15 Feb 2018 19:35:10 -0000 --Apple-Mail=_4AAA96D7-6AF5-452B-98E6-74AA9EA53C30 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 15, 2018, at 10:28 AM, Dick Roy wrote: >=20 > IMO you should stick to the network (and transport) layer, and let the = DLL guys do their job. Just to be clear: the purpose of trying to provide an adaptation layer = is so that we can simply reference RFC 2464 (and friends) "Transmission = of IPv6 Packets over Ethernet Networks=E2=80=9D and be done. Tony --Apple-Mail=_4AAA96D7-6AF5-452B-98E6-74AA9EA53C30 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Feb 15, 2018, at 10:28 AM, Dick Roy <dickroy@alum.mit.edu> wrote:

IMO you should stick = to the network (and transport) layer, and let the DLL guys do their = job.


Just to be clear: the = purpose of trying to provide an adaptation layer is so that we can = simply reference RFC 2464 (and friends) "Transmission of IPv6 Packets over = Ethernet Networks=E2=80=9D and be done.

Tony

= --Apple-Mail=_4AAA96D7-6AF5-452B-98E6-74AA9EA53C30-- From nobody Thu Feb 15 11:56:21 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25CA912D7F9 for ; Thu, 15 Feb 2018 11:30:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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=qfreeonline.onmicrosoft.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 vWo8uLxbzIpe for ; Thu, 15 Feb 2018 11:30:41 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10062.outbound.protection.outlook.com [40.107.1.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 635AE12D7F1 for ; Thu, 15 Feb 2018 11:30:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qfreeonline.onmicrosoft.com; s=selector1-qfree-com0c; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7GDSBHdsGEZMSbx0kCYYJp8Or8Ck2ccTM2u9Bbb4h+g=; b=eteoMrjKJccHWQLvgB2qe3hd4384fG5IxdidnlanRPt5Dr4g+DnPebUg83HNIvR7kzOjyirCPlHSNXEvnZ53AAmoEeK2TLVN5eQaVEdGsxRlzoidMq+iqFVVh2FrxUmITGAqgkXATqJ/1tEks2EzyPz8qfejMpsyW038hb6phV8= Received: from DB5PR0201MB1605.eurprd02.prod.outlook.com (10.166.10.26) by DB5PR0201MB2023.eurprd02.prod.outlook.com (10.167.226.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.18; Thu, 15 Feb 2018 19:30:37 +0000 Received: from DB5PR0201MB1605.eurprd02.prod.outlook.com ([fe80::8ccd:e370:543c:fe56]) by DB5PR0201MB1605.eurprd02.prod.outlook.com ([fe80::8ccd:e370:543c:fe56%14]) with mapi id 15.20.0485.015; Thu, 15 Feb 2018 19:30:37 +0000 From: Knut Evensen To: Alexandre Petrescu , "dickroy@alum.mit.edu" , 'Abdussalam Baryun' CC: "mrcullen42@gmail.com" , 'its' , "hjfischer@fischer-tech.eu" Thread-Topic: [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-08 - *DUs Thread-Index: AdOmVcRRj5PPsu7VSLO8R7BJKEITzQAN1uYAAABNyQAAASmDEA== Date: Thu, 15 Feb 2018 19:30:36 +0000 Message-ID: References: <1506192164.12227.3.camel@it.uc3m.es> <390b03ec-27a6-43e3-3ea1-95715d253980@gmail.com> <97975302-2ab4-d9b9-d825-758bf2371dff@gmail.com> <24809DE2FFDE44A9B11AA5ACB3A0D1BE@SRA6> <45d910cb-7a1e-4e37-12c7-aa8bd4d311bb@gmail.com> <79AE367CE5524ECF9E35CBFC5494498D@SRA6> <0b5ac980-b7fd-c61e-630b-3333e1b77c53@gmail.com> <4C0B3578C0EA4DF8A40F55AAEFC5F4EC@SRA6> <3730fd8c-8c15-6bb4-416a-933a7165ba36@gmail.com> In-Reply-To: <3730fd8c-8c15-6bb4-416a-933a7165ba36@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Knut.Evensen@q-free.com; x-originating-ip: [84.52.233.66] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB5PR0201MB2023; 7:QFz8g1FavgcWAROjXvRhJBeRUjNYP/3AET9lizfsz0oRscykATG14v+Ib2rYTSIRVyF2KciiTvHeQtHjyAAGLwDVQu3ebfMaVwxcNgdh3eB2nXCiKhmSoBpVEecOCRNvOWmpe84dO0nU/0/61lWd34OAw4l8G22MOJLsn2oS4/anXrrV0/yoXFu3kIeuqXGR7t6fmNnLrCHQc196ZrVGhmqCEo8fuTgAtUBNNAfkGSw8z98CHlb9+ceLETEBgH0a x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 43c0fae5-5c60-4ee6-20c4-08d574aa9712 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DB5PR0201MB2023; x-ms-traffictypediagnostic: DB5PR0201MB2023:|DB5PR0201MB2023: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(85827821059158)(240460790083961); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231101)(944501161)(93006095)(93001095)(6041288)(20161123560045)(20161123562045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DB5PR0201MB2023; BCL:0; PCL:0; RULEID:; SRVR:DB5PR0201MB2023; x-forefront-prvs: 058441C12A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39380400002)(39850400004)(396003)(366004)(376002)(189003)(13464003)(199004)(69234005)(2950100002)(53936002)(14454004)(4326008)(105586002)(93886005)(2501003)(25786009)(5250100002)(3846002)(6116002)(478600001)(72206003)(68736007)(9686003)(5660300001)(55016002)(966005)(6306002)(66066001)(106356001)(81166006)(6246003)(2171002)(99286004)(86362001)(39060400002)(7736002)(7696005)(76176011)(97736004)(2906002)(8936002)(305945005)(316002)(110136005)(54906003)(6436002)(186003)(33656002)(26005)(81156014)(53546011)(102836004)(6506007)(3660700001)(2900100001)(229853002)(3280700002)(8676002)(74316002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR0201MB2023; H:DB5PR0201MB1605.eurprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; received-spf: None (protection.outlook.com: q-free.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: /EzEhGEfIQI6LlZHnExKgqG5oOUtl7JdjVIC6Pw3pP7vvSW79wNVBAoMGNXhhlILmsJvalwoV0dg68bZbIx8/w== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: q-free.com X-MS-Exchange-CrossTenant-Network-Message-Id: 43c0fae5-5c60-4ee6-20c4-08d574aa9712 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2018 19:30:36.9978 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 39ef44ca-adfa-4a24-8858-ef68dbe16345 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR0201MB2023 Archived-At: X-Mailman-Approved-At: Thu, 15 Feb 2018 11:56:14 -0800 Subject: Re: [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-08 - *DUs 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, 15 Feb 2018 19:30:44 -0000 WWVzLCB0aGlzIGlzIG9uZSBvZiB0aGUgZGlzYWR2YW50YWdlcyB3aXRoIENFTiBhbmQgSVNPIGtl ZXBpbmcgdGhlaXIgc3RhbmRhcmRzIHVuZGVyIHN0cmljdCBJUFIsIHdoaWxzdCBFVFNJIG9mZmVy IHRoZW0gZnJlZWx5IGRvd25sb2FkYWJsZSBzbyBHb29nbGUgY2FuIGNyYXdsIGFuZCBpbmRleCB0 aGVtIGV2ZXJ5IGhhbGYgaG91ci4uLg0KDQpCZXN0IHJlZ2FyZHMsDQoNCiAgLWtudXQNCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEFsZXhhbmRyZSBQZXRyZXNjdSBbbWFpbHRv OmFsZXhhbmRyZS5wZXRyZXNjdUBnbWFpbC5jb21dIA0KU2VudDogVGh1cnNkYXksIDE1IEZlYnJ1 YXJ5LCAyMDE4IDE5OjU0DQpUbzogZGlja3JveUBhbHVtLm1pdC5lZHU7ICdBYmR1c3NhbGFtIEJh cnl1bicgPGFiZHVzc2FsYW1iYXJ5dW5AZ21haWwuY29tPg0KQ2M6IG1yY3VsbGVuNDJAZ21haWwu Y29tOyAnaXRzJyA8aXRzQGlldGYub3JnPjsgS251dCBFdmVuc2VuIDxLbnV0LkV2ZW5zZW5AcS1m cmVlLmNvbT47IGhqZmlzY2hlckBmaXNjaGVyLXRlY2guZXUNClN1YmplY3Q6IFJlOiBbaXB3YXZl XSBXR0xDIGZvciBkcmFmdC1pZXRmLWlwd2F2ZS1pcHY2LW92ZXItODAyMTFvY2ItMDggLSAqRFVz DQoNClNvcnJ5LCBpdCBtYXkgYmUgSSB3ZW50IHRvbyBmYXN0IHdpdGggbXkgc3RhdGVtZW50Lg0K DQpJIGdvb2dsZWQgIkZTLVNEVSIgYW5kIGZpcnN0IGVudHJ5IHdhcyBFVFNJLg0KDQpCdXQgSSBh Z3JlZSB0aGF0IGFzIHdpdGggd2lraXBlZGlhLCBtdXN0IGRvdWJsZSBjaGVjayBiZWZvcmUgcmVs eWluZyBvbiBnb29nbGUgc2VhcmNoZXMuDQoNCkFsZXgNCg0KTGUgMTUvMDIvMjAxOCDDoCAxOTo1 MCwgRGljayBSb3kgYSDDqWNyaXTCoDoNCj4gV293LCBpbnRlcmVzdGluZyBob3cgaGlzdG9yeSBr ZWVwcyBjaGFuZ2luZyEgIEkgYWxvbmcgd2l0aCB0d28gb3RoZXJzIA0KPiBjcmVhdGVkIHRoZSBu YW1lICJGYWNpbGl0eSBsYXllciIsIGFuZCB0aGVyZSBtb3N0IGFzc3VyZWRseSBpcyBhbiAiRlNE VSINCj4gdGhyb3VnaG91dCB0aGUgSVNPIHN0YW5kYXJkcy4gIEVUU0kgVEMgSVRTLCB3aGljaCBh IGZldyBvZiB1cyBhbHNvIA0KPiAiY3JlYXRlZCIsIHNpbXBseSBhZG9wdGVkIElTTyAyMTIxNyBh cyB0aGV5IHdlcmUgcmVxdWlyZWQgdG8gZG8gYnkgdGhlIA0KPiBhZ3JlZW1lbnQgYmV0d2VlbiBJ U08gVEMyMDQgYW5kIEVUU0kgd2hlbiBUQyBJVFMgd2FzIGNyZWF0ZWQuICBJdCdzIGEgDQo+IGxv bmcgc3RvcnkgLi4uIHBlcmhhcHMgb3ZlciBhIGJlZXIgb3IgdGhyZWUgc29tZXRpbWU6XikpKQ0K PiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaXRzIFttYWlsdG86aXRz LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbGV4YW5kcmUgDQo+IFBldHJlc2N1DQo+ IFNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAxNSwgMjAxOCA0OjA5IEFNDQo+IFRvOiBkaWNrcm95 QGFsdW0ubWl0LmVkdTsgJ0FiZHVzc2FsYW0gQmFyeXVuJw0KPiBDYzogbXJjdWxsZW40MkBnbWFp bC5jb207ICdpdHMnDQo+IFN1YmplY3Q6IFJlOiBbaXB3YXZlXSBXR0xDIGZvciBkcmFmdC1pZXRm LWlwd2F2ZS1pcHY2LW92ZXItODAyMTFvY2ItMDggDQo+IC0gKkRVcw0KPiANCj4gSSBkb3VidCBJ U08gaGFzIHRoZSBGTC1TRFUgdGVybSwgYXMgRmFjaWxpdHkgTGF5ZXIgaXMgYW4gRVRTSSB0ZXJt Lg0KPiANCj4gQWxleA0KPiANCj4gTGUgMTQvMDIvMjAxOCDDoCAxODozMSwgRGljayBSb3kgYSDD qWNyaXTCoDoNCj4+IEp1c3QgcmVmZXIgdG8gSVNPIE9TSSBtb2RlbCBhbmQgdGhlIHJlbGV2YW50 IElTTyBzdGFuZGFyZHMgLi4uIHRoZXkgDQo+PiBoYXZlDQo+IGFsbA0KPj4gdGhhdCBpbiB0aGVy ZSBhbHJlYWR5IQ0KPj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBp dHMgW21haWx0bzppdHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFsZXhhbmRyZSAN Cj4+IFBldHJlc2N1DQo+PiBTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAxMywgMjAxOCAxMTo1NCBQ TQ0KPj4gVG86IGRpY2tyb3lAYWx1bS5taXQuZWR1OyAnQWJkdXNzYWxhbSBCYXJ5dW4nDQo+PiBD YzogbXJjdWxsZW40MkBnbWFpbC5jb207ICdpdHMnDQo+PiBTdWJqZWN0OiBSZTogW2lwd2F2ZV0g V0dMQyBmb3IgDQo+PiBkcmFmdC1pZXRmLWlwd2F2ZS1pcHY2LW92ZXItODAyMTFvY2ItMDggLSAq RFVzDQo+Pg0KPj4gSXQgaXMgd29ydGggd3JpdGluZyBhIHRlcm1pbm9sb2d5IGRyYWZ0IGFib3V0 ICpEVXMsIG1heWJlIGl0IHdpbGwgZ2V0IA0KPj4gdGhlIHRlcm1zIHRvIGJlIG1vcmUgdXNlZC4N Cj4+DQo+PiBBbGV4DQo+Pg0KPj4gTGUgMTMvMDIvMjAxOCDDoCAxODo1MSwgRGljayBSb3kgYSDD qWNyaXTCoDoNCj4+Pg0KPj4+DQo+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiBG cm9tOiBpdHMgW21haWx0bzppdHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFsZXhh bmRyZSANCj4+PiBQZXRyZXNjdQ0KPj4+IFNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDEzLCAyMDE4 IDQ6MTUgQU0NCj4+PiBUbzogZGlja3JveUBhbHVtLm1pdC5lZHU7ICdBYmR1c3NhbGFtIEJhcnl1 bicNCj4+PiBDYzogbXJjdWxsZW40MkBnbWFpbC5jb207ICdpdHMnDQo+Pj4gU3ViamVjdDogUmU6 IFtpcHdhdmVdIFdHTEMgZm9yIA0KPj4+IGRyYWZ0LWlldGYtaXB3YXZlLWlwdjYtb3Zlci04MDIx MW9jYi0wOCAtICpEVXMNCj4+Pg0KPj4+IFNEVXMgYXJlIGNhbGxlZCBTZXJ2aWNlIERhdGEgVW5p dHMsIGFuZCBGTC1TRFVzIGFyZSBGYWNpbGl0eS1sYXllciBTRFVzLg0KPj4+IFtSUl0gWWVzLCBh bmQgVFBEVXMgYXJlIE5TRFVzLCBOUERVcyBhcmUgTVNEVXMsIGV0Yy4uDQo+Pj4NCj4+PiBBbGV4 DQo+Pj4NCj4+PiBMZSAxMy8wMi8yMDE4IMOgIDExOjE2LCBBbGV4YW5kcmUgUGV0cmVzY3UgYSDD qWNyaXTCoDoNCj4+Pj4gTGUgMTMvMDIvMjAxOCDDoCAwMjoyMCwgRGljayBSb3kgYSDDqWNyaXTC oDoNCj4+Pj4+IEZZSSAuLi4gVFBEVXMgYXJlIGNhbGxlZCBzZWdtZW50LCBOUERVcyBhcmUgcGFj a2V0cywgTVBEVXMgYXJlIA0KPj4+Pj4gZnJhbWVzLCBhbmQgUFBEVXMgYXJlIHN0cmVhbXMgaWYg eW91IGNhcmUuDQo+Pj4+DQo+Pj4+IFlFcyBub3RlZC4NCj4+Pj4NCj4+Pj4gQWxleA0KPj4+PiBb Li4uXQ0KPj4+Pg0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4+PiBpdHMgbWFpbGluZyBsaXN0DQo+Pj4+IGl0c0BpZXRmLm9yZw0KPj4+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2l0cw0KPj4+DQo+Pj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBpdHMgbWFpbGlu ZyBsaXN0DQo+Pj4gaXRzQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pdHMNCj4+Pg0KPj4+DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+IGl0cyBtYWlsaW5nIGxpc3QNCj4+IGl0c0BpZXRm Lm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pdHMNCj4+DQo+ Pg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gaXRzIG1haWxpbmcgbGlzdA0KPiBpdHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pdHMNCj4gDQo+IA0K From nobody Thu Feb 15 12:16:17 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6BA124D68 for ; Thu, 15 Feb 2018 12:16:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_HK_NAME_DR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fischer-tech.eu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73uWK5AKg-Mn for ; Thu, 15 Feb 2018 12:16:11 -0800 (PST) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61C2B1241FC for ; Thu, 15 Feb 2018 12:16:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1518725768; s=strato-dkim-0002; d=fischer-tech.eu; h=Content-Type:In-Reply-To:Date:Message-ID:From:References:Cc:To: Subject:X-RZG-CLASS-ID:X-RZG-AUTH; bh=qZ/L+MvK9PGUFjKKD85EwnaMSdd7LuNVPlJxtTwwj/Q=; b=giH5CW5eBp91Mx2cXs1aOlPpSfvCk8l5hV694mw8rFeiDsqQy83S560zQGtSxmXyXv zc6iBzjbnGQT5vPC/peCk8dGrvVCnhccRMwoDPEJXbkXLDnlGeA6tUU6jzBE5yTDXs00 Goz23OHMO+yjavumBGoJNcdr1IUTnnybNoaC5883FfKrkehikmFjAG25jalgTRk88mRq 0MvKK9IpNP99Gj1Fd37epKlIgUYl6DAfVCVm1Z1oAs2Lea/n8MSqejRXkdrdMzpf8m8H CCkBBDj2zLLQrqm7Fxucg2gzDn/pUHH/Z13QGR/oqW3cMPcMZ4BZ0VsfMrCMpx09uVdC /6bQ== X-RZG-AUTH: :JGYCfFOrc/o0m7eTcArWz0wjmOawaLakL8gsnQVmzXBs/kysHP8WeUE0sQcvY8PAWSJdtjsmGi0ld1/vHAqemx4DnzRTrw16macEPtqe3BaQGw== X-RZG-CLASS-ID: mo00 Received: from [IPv6:2003:a:1511:b400:d416:81f2:3e97:9105] ([2003:a:1511:b400:d416:81f2:3e97:9105]) by smtp.strato.de (RZmta 42.18 AUTH) with ESMTPSA id h068a2u1FKG2LIP (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Thu, 15 Feb 2018 21:16:02 +0100 (CET) To: Knut Evensen , Alexandre Petrescu , "dickroy@alum.mit.edu" , 'Abdussalam Baryun' Cc: "mrcullen42@gmail.com" , 'its' References: <1506192164.12227.3.camel@it.uc3m.es> <390b03ec-27a6-43e3-3ea1-95715d253980@gmail.com> <97975302-2ab4-d9b9-d825-758bf2371dff@gmail.com> <24809DE2FFDE44A9B11AA5ACB3A0D1BE@SRA6> <45d910cb-7a1e-4e37-12c7-aa8bd4d311bb@gmail.com> <79AE367CE5524ECF9E35CBFC5494498D@SRA6> <0b5ac980-b7fd-c61e-630b-3333e1b77c53@gmail.com> <4C0B3578C0EA4DF8A40F55AAEFC5F4EC@SRA6> <3730fd8c-8c15-6bb4-416a-933a7165ba36@gmail.com> From: "Dr. Hans-Joachim Fischer" Organization: ESF GmbH Message-ID: Date: Thu, 15 Feb 2018 21:16:02 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C1AE66A18F4EA6EA5E5437C4" Archived-At: Subject: Re: [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-08 - *DUs 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, 15 Feb 2018 20:16:15 -0000 This is a multi-part message in MIME format. --------------C1AE66A18F4EA6EA5E5437C4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Right. But not just CEN and ISO. Also IEEE takes money for standards. Not for all, but this is the same at ISO - some standards can be downloaded from the web free of charge. At ETSI you have to pay for making standards. Sincerely Hans-Joachim Am 15.02.2018 um 20:30 schrieb Knut Evensen: > Yes, this is one of the disadvantages with CEN and ISO keeping their standards under strict IPR, whilst ETSI offer them freely downloadable so Google can crawl and index them every half hour... > > Best regards, > > -knut > > -----Original Message----- > From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] > Sent: Thursday, 15 February, 2018 19:54 > To: dickroy@alum.mit.edu; 'Abdussalam Baryun' > Cc: mrcullen42@gmail.com; 'its' ; Knut Evensen ; hjfischer@fischer-tech.eu > Subject: Re: [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-08 - *DUs > > Sorry, it may be I went too fast with my statement. > > I googled "FS-SDU" and first entry was ETSI. > > But I agree that as with wikipedia, must double check before relying on google searches. > > Alex > > Le 15/02/2018 à 19:50, Dick Roy a écrit : >> Wow, interesting how history keeps changing! I along with two others >> created the name "Facility layer", and there most assuredly is an "FSDU" >> throughout the ISO standards. ETSI TC ITS, which a few of us also >> "created", simply adopted ISO 21217 as they were required to do by the >> agreement between ISO TC204 and ETSI when TC ITS was created. It's a >> long story ... perhaps over a beer or three sometime:^))) >> >> -----Original Message----- >> From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre >> Petrescu >> Sent: Thursday, February 15, 2018 4:09 AM >> To: dickroy@alum.mit.edu; 'Abdussalam Baryun' >> Cc: mrcullen42@gmail.com; 'its' >> Subject: Re: [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-08 >> - *DUs >> >> I doubt ISO has the FL-SDU term, as Facility Layer is an ETSI term. >> >> Alex >> >> Le 14/02/2018 à 18:31, Dick Roy a écrit : >>> Just refer to ISO OSI model and the relevant ISO standards ... they >>> have >> all >>> that in there already! >>> >>> -----Original Message----- >>> From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre >>> Petrescu >>> Sent: Tuesday, February 13, 2018 11:54 PM >>> To: dickroy@alum.mit.edu; 'Abdussalam Baryun' >>> Cc: mrcullen42@gmail.com; 'its' >>> Subject: Re: [ipwave] WGLC for >>> draft-ietf-ipwave-ipv6-over-80211ocb-08 - *DUs >>> >>> It is worth writing a terminology draft about *DUs, maybe it will get >>> the terms to be more used. >>> >>> Alex >>> >>> Le 13/02/2018 à 18:51, Dick Roy a écrit : >>>> >>>> -----Original Message----- >>>> From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre >>>> Petrescu >>>> Sent: Tuesday, February 13, 2018 4:15 AM >>>> To: dickroy@alum.mit.edu; 'Abdussalam Baryun' >>>> Cc: mrcullen42@gmail.com; 'its' >>>> Subject: Re: [ipwave] WGLC for >>>> draft-ietf-ipwave-ipv6-over-80211ocb-08 - *DUs >>>> >>>> SDUs are called Service Data Units, and FL-SDUs are Facility-layer SDUs. >>>> [RR] Yes, and TPDUs are NSDUs, NPDUs are MSDUs, etc.. >>>> >>>> Alex >>>> >>>> Le 13/02/2018 à 11:16, Alexandre Petrescu a écrit : >>>>> Le 13/02/2018 à 02:20, Dick Roy a écrit : >>>>>> FYI ... TPDUs are called segment, NPDUs are packets, MPDUs are >>>>>> frames, and PPDUs are streams if you care. >>>>> YEs noted. >>>>> >>>>> Alex >>>>> [...] >>>>> >>>>> _______________________________________________ >>>>> its mailing list >>>>> its@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/its >>>> _______________________________________________ >>>> its mailing list >>>> its@ietf.org >>>> https://www.ietf.org/mailman/listinfo/its >>>> >>>> >>> _______________________________________________ >>> its mailing list >>> its@ietf.org >>> https://www.ietf.org/mailman/listinfo/its >>> >>> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >> >> > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its -- Dr. Hans-Joachim Fischer Managing Director -------------------------------------------------------------------------------- ESF News edition 2018/1 https://fischer-tech.eu/Feeds/News/ESF-News-2018-01.pdf -------------------------------------------------------------------------------- Towards deployment of C-ITS based on proven technology Avoid risks and delay by looking on potential future technologies. The real advocate on ITS is ISO TC204! -------------------------------------------------------------------------------- + + + Instaurare omnia in Christo + + + -------------------------------------------------------------------------------- The information contained in this message is confidential and may be legally privileged. This email is intended for the addressee(s). Addressees may be individual persons or members of mailing list. If you are not an addressee, you are hereby notified that any use, dissemination, or reproduction of this email and its optional attachements is strictly prohibited and may be unlawful. If you are not an addressee, please contact the sender by return e-mail and destroy all copies of the original message. -------------------------------------------------------------------------------- ESF GmbH Fichtenweg 9 89143 Blaubeuren +49 (7344) 175340 (Direct line Dr. Fischer) +49 (7344) 919188 (Central office) +49 (7344) 919123 (Fax) https://fischer-tech.eu : Main web of ESF GmbH http://its-standards.eu : News on cooperative ITS standardization http://its-testing.org : International consultancy for cooperative ITS -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- ESF online-news: http://fischer-tech.eu/Feeds/esf.rss C-ITS online news: http://its-standards.info/Feeds/cits.rss ESF Online Nachrichten: http://fischer-tech.de/Feeds/esfD.rss ------------------------------------------------------------------------------- --------------C1AE66A18F4EA6EA5E5437C4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


Right. But not just CEN and ISO.

Also IEEE takes money for standards. Not for all, but this is the same at ISO - some standards can be downloaded from the web free of charge.

At ETSI you have to pay for making standards.


Sincerely
Hans-Joachim


Am 15.02.2018 um 20:30 schrieb Knut Evensen:
Yes, this is one of the disadvantages with CEN and ISO keeping their standards under strict IPR, whilst ETSI offer them freely downloadable so Google can crawl and index them every half hour...

Best regards,

  -knut

-----Original Message-----
From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] 
Sent: Thursday, 15 February, 2018 19:54
To: dickroy@alum.mit.edu; 'Abdussalam Baryun' <abdussalambaryun@gmail.com>
Cc: mrcullen42@gmail.com; 'its' <its@ietf.org>; Knut Evensen <Knut.Evensen@q-free.com>; hjfischer@fischer-tech.eu
Subject: Re: [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-08 - *DUs

Sorry, it may be I went too fast with my statement.

I googled "FS-SDU" and first entry was ETSI.

But I agree that as with wikipedia, must double check before relying on google searches.

Alex

Le 15/02/2018 à 19:50, Dick Roy a écrit :

Wow, interesting how history keeps changing!  I along with two others 
created the name "Facility layer", and there most assuredly is an "FSDU"
throughout the ISO standards.  ETSI TC ITS, which a few of us also 
"created", simply adopted ISO 21217 as they were required to do by the 
agreement between ISO TC204 and ETSI when TC ITS was created.  It's a 
long story ... perhaps over a beer or three sometime:^)))

-----Original Message-----
From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre 
Petrescu
Sent: Thursday, February 15, 2018 4:09 AM
To: dickroy@alum.mit.edu; 'Abdussalam Baryun'
Cc: mrcullen42@gmail.com; 'its'
Subject: Re: [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-08 
- *DUs

I doubt ISO has the FL-SDU term, as Facility Layer is an ETSI term.

Alex

Le 14/02/2018 à 18:31, Dick Roy a écrit :

Just refer to ISO OSI model and the relevant ISO standards ... they 
have

all

that in there already!

-----Original Message-----
From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre 
Petrescu
Sent: Tuesday, February 13, 2018 11:54 PM
To: dickroy@alum.mit.edu; 'Abdussalam Baryun'
Cc: mrcullen42@gmail.com; 'its'
Subject: Re: [ipwave] WGLC for 
draft-ietf-ipwave-ipv6-over-80211ocb-08 - *DUs

It is worth writing a terminology draft about *DUs, maybe it will get 
the terms to be more used.

Alex

Le 13/02/2018 à 18:51, Dick Roy a écrit :


-----Original Message-----
From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre 
Petrescu
Sent: Tuesday, February 13, 2018 4:15 AM
To: dickroy@alum.mit.edu; 'Abdussalam Baryun'
Cc: mrcullen42@gmail.com; 'its'
Subject: Re: [ipwave] WGLC for 
draft-ietf-ipwave-ipv6-over-80211ocb-08 - *DUs

SDUs are called Service Data Units, and FL-SDUs are Facility-layer SDUs.
[RR] Yes, and TPDUs are NSDUs, NPDUs are MSDUs, etc..

Alex

Le 13/02/2018 à 11:16, Alexandre Petrescu a écrit :

Le 13/02/2018 à 02:20, Dick Roy a écrit :

FYI ... TPDUs are called segment, NPDUs are packets, MPDUs are 
frames, and PPDUs are streams if you care.

YEs noted.

Alex
[...]

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

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



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



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



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


-- 
Dr. Hans-Joachim Fischer
Managing Director

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

               ESF News edition 2018/1
https://fischer-tech.eu/Feeds/News/ESF-News-2018-01.pdf

-------------------------------------------------------------------------------- 
      Towards deployment of C-ITS based on proven technology
Avoid risks and delay by looking on potential future technologies.

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

-------------------------------------------------------------------------------- 
ESF online-news:        http://fischer-tech.eu/Feeds/esf.rss
C-ITS online news:      http://its-standards.info/Feeds/cits.rss
ESF Online Nachrichten: http://fischer-tech.de/Feeds/esfD.rss
-------------------------------------------------------------------------------
--------------C1AE66A18F4EA6EA5E5437C4-- From nobody Thu Feb 15 17:22:04 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FAAD126DED; Thu, 15 Feb 2018 17:22:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 cE_021sWhTB9; Thu, 15 Feb 2018 17:22:01 -0800 (PST) Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::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 844D4126CD8; Thu, 15 Feb 2018 17:22:01 -0800 (PST) Received: by mail-ot0-x230.google.com with SMTP id f18so1485474otf.6; Thu, 15 Feb 2018 17:22:01 -0800 (PST) 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=0VLMKEc+tgUw5oenExlUm7URkmrDaFcp/zk5iU3gkvA=; b=ZzmzNzNxTMJ0rD2yGY3PSrAnH6qowDeqioBiaJlaN3YDDZG8IkSSNOGu7KApSbUlpb ftPlhKjv6TJP6f0OU3kHoxFwPA/p1v2mhVW0K5deKkY9ez34QM4JlJgw6zIuYR7xstHr 2iNGp58t8OT0ZRyTt3A7gJVdUqPZ0Vv4rgOeBpWuuefYedHCaHNohgfmEAr3FIAgL3Ts i28YlEwz2QQORqB/R0Rxjz5RhIGKwcEGoQoQH88bucDQ6Hqh35KndRVhKEO02vZnJ39X rDHNWa5QqRKIk+aKe+gZ2tgrTuomNYz1RQUdgFO3PRnOMugRaswjGMZTAC+Z8ga8b4/G 6H8A== 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=0VLMKEc+tgUw5oenExlUm7URkmrDaFcp/zk5iU3gkvA=; b=SbKnMkrO4CcyKzwW97FUv6MAfCYywsOMLT9PI/9bVvolr212T9mzZIEBulJUpHRFF3 be2kHFeT/L2NRuXk0o2JHDi9TAwpwxqIoiF/W42M1+PQZlkwcv77Qy0Fs7YMqdnOppRc owybq6JyaNAkHz7W/IkP0N7UYRsBx4gVi90QsQP/Z7XSYoeJYLj6BoswIG0ylIAdMiML mfPL70sqR43BobOfCnUz0637rfn4iFIFEwHsOzhPahkH8daOstBUoS+ByBfflCDw7iRl zXx3XrmmP+A1hUwuQllkkTo8OPvhrZ2Ze+yAPqzADJeCQZC35xciKBiwpJ9NN89DTaDL gv9A== X-Gm-Message-State: APf1xPBxIi2JgmUvpeCUcqcB1dVFOUeqPMcRgIwnOtHLnb6dnSvDPypt DduLHNIv8jhKQQPRnD09omJUKHHZeq+vExHbVu0= X-Google-Smtp-Source: AH8x224GKD2HSd4AaY7PUIYvz3jwUOhI+BVyC/tCmMv5kuH/C+LlpzL1dVbsbMSrGJZmsgxqWx4EdS6csqhcdAw1wDA= X-Received: by 10.157.24.28 with SMTP id b28mr3476043ote.356.1518744120749; Thu, 15 Feb 2018 17:22:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.44 with HTTP; Thu, 15 Feb 2018 17:22:00 -0800 (PST) In-Reply-To: References: <1517217856.4315.32.camel@it.uc3m.es> <87A7E5C11E9C48DB84FBE2CE78537448@SRA6> <7D76FB29BFE54E8AA9516CC1971A77E2@SRA6> <016e01d3a680$42697ab0$c73c7010$@gmail.com> From: Abdussalam Baryun Date: Fri, 16 Feb 2018 03:22:00 +0200 Message-ID: To: its Cc: Richard Roy , draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org, =?UTF-8?Q?Fran=C3=A7ois_Simon?= , Russ Housley , Alexandre Petrescu , =?UTF-8?Q?Carlos_Jes=C3=BAs_Bernardos_Cano?= , Suresh Krishnan Content-Type: multipart/alternative; boundary="001a113dc984d2784405654a2b52" Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 - Normative text in Ethernet Adaptation Layer 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: Fri, 16 Feb 2018 01:22:03 -0000 --001a113dc984d2784405654a2b52 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Feb 15, 2018 at 9:32 PM, wrote: > > > On Feb 15, 2018, at 10:28 AM, Dick Roy wrote: > > *IMO you should stick to the network (and transport) layer, and let the > DLL guys do their job.* > > The problem is that their job is not done, they are still amending to get better performance (from ieee802.11p to ieee802.11px). IMO we can consider performance when we transmit IPv6 over such job. Additionally, recommend for better transmission quality. > > Just to be clear: the purpose of trying to provide an adaptation layer is > so that we can simply reference RFC 2464 (and friends) "Transmission of > IPv6 Packets over Ethernet Networks=E2=80=9D and be done. > In wireless communication increasing frames header size decreases performance. Using easy ways have always overheads. Ethernet is wired network high speed and it is with very lower noise compared with wireless. We should not forget mobility in our use case. We need to reduce the overhead, and consider performance when transmitting IPv6 over ieee802.11-ocb AB --001a113dc984d2784405654a2b52 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Feb 15, 2018 at 9:32 PM, <tony.li@tony.li> wrote:=


On Feb 15, 2018, at 10:28 AM, Dick Ro= y <dickroy@alu= m.mit.edu> wrote:

IMO you should stick to the network (and t= ransport) layer, and let the DLL guys do their job.

The pr= oblem is that their =C2=A0job is not done,=C2=A0they are still amending to = get better performance (from ieee802.11p to ieee802.11px). IMO=C2=A0we=C2= =A0can consider performance when we transmit IPv6 over such job.=C2=A0Addit= ionally, recommend for better transmission quality.



=
Just to be clear: the purpose of trying to provide an ada= ptation layer is so that we can simply reference RFC 2464 (and friends) &qu= ot;Transmission of IPv6 Packets over Ethernet= Networks=E2=80=9D and be done.

In wireless communication increasing frames header size decreases p= erformance.=C2=A0Using easy ways have always overheads. Ethernet is wired n= etwork high speed and it is with very lower noise compared with wireless. W= e should not forget mobility in our use case.

We n= eed to reduce the overhead, and consider=C2=A0performance=C2=A0when transmi= tting IPv6 over ieee802.11-ocb

AB=C2=A0

--001a113dc984d2784405654a2b52-- From nobody Thu Feb 15 17:29:35 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2AFC126CD8 for ; Thu, 15 Feb 2018 17:29:33 -0800 (PST) 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=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bdTQ9XAeEaCC for ; Thu, 15 Feb 2018 17:29:26 -0800 (PST) Received: from resqmta-po-10v.sys.comcast.net (resqmta-po-10v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:169]) (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 9F441126DED for ; Thu, 15 Feb 2018 17:29:26 -0800 (PST) Received: from resomta-po-14v.sys.comcast.net ([96.114.154.238]) by resqmta-po-10v.sys.comcast.net with ESMTP id mUq6eWoomcvTSmUq6eK394; Fri, 16 Feb 2018 01:29:26 +0000 Received: from [172.22.228.216] ([162.210.130.3]) by resomta-po-14v.sys.comcast.net with SMTP id mUnkeezwSn7MwmUnmeYMg4; Fri, 16 Feb 2018 01:27:24 +0000 From: Tony Li Message-Id: <19DC0531-54E7-42BC-811A-CF30D1DA003B@tony.li> Content-Type: multipart/alternative; boundary="Apple-Mail=_4EEFD410-9F65-4221-8FF6-6379D860BE3C" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Thu, 15 Feb 2018 17:26:59 -0800 In-Reply-To: Cc: its , draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org, =?utf-8?Q?Fran=C3=A7ois_Simon?= , Russ Housley , Alexandre Petrescu , =?utf-8?Q?Carlos_Jes=C3=BAs_Bernardos_Cano?= , Richard Roy , Suresh Krishnan To: Abdussalam Baryun References: <1517217856.4315.32.camel@it.uc3m.es> <87A7E5C11E9C48DB84FBE2CE78537448@SRA6> <7D76FB29BFE54E8AA9516CC1971A77E2@SRA6> <016e01d3a680$42697ab0$c73c7010$@gmail.com> X-Mailer: Apple Mail (2.3445.5.20) X-CMAE-Envelope: MS4wfIJx/AHfgvVSehK/lXw+BMnlCCRnfxE4QyiRrvD2tn6XDWgtFlO7hCMo89aDApKvA8ySp4WWv7JS5GIkK6WAVuT6sFwDuv2q+rJXRtQh7aT7TY76XvGY 0wR1g+wDVoLxBbocMskaQpIQPHpuCiwbV8qEtUp5Mnenq7bL3wPh/ebAp0LjRx/7+ATkxRxbD+YFXU7y6cng/qM2dVqRZtxSaDumXWqiMjXQsoV5S/sj5/Rc JMB2FAf7CPWm+LiavTqD+b1o4fIN/oCaKvY94FqJK2swqrjcxHS9ZYwNhHojIL+xzK/UjpCtkZBnjKDhk0TdEfI4uMzVkgBiTD2444vFx2TK2cF8DYy2+KGQ zvky0LMb8qo3wsiYNmpTn4mtK/CIOP1k9A6Zr+KHDnqc3NY/EsqcNd3/hUnl4Uwu2V+hQXe1E9/MQJn2/m2ibHAg3+nYDSYn/P4x4nVkjT9PPZr3WH8= Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 - Normative text in Ethernet Adaptation Layer 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: Fri, 16 Feb 2018 01:29:34 -0000 --Apple-Mail=_4EEFD410-9F65-4221-8FF6-6379D860BE3C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >> IMO you should stick to the network (and transport) layer, and let = the DLL guys do their job. >=20 >=20 > The problem is that their job is not done, they are still amending to = get better performance (from ieee802.11p to ieee802.11px). IMO we can = consider performance when we transmit IPv6 over such job. Additionally, = recommend for better transmission quality. I=E2=80=99m gonna guess that it=E2=80=99s very unlikely that they will = significantly change header formats when they do so. So I suspect that = we=E2=80=99re quite safe in proceeding as is. > Just to be clear: the purpose of trying to provide an adaptation layer = is so that we can simply reference RFC 2464 (and friends) "Transmission = of IPv6 Packets over Ethernet Networks=E2=80=9D and be done. >=20 > In wireless communication increasing frames header size decreases = performance. Using easy ways have always overheads. Ethernet is wired = network high speed and it is with very lower noise compared with = wireless. We should not forget mobility in our use case. >=20 > We need to reduce the overhead, and consider performance when = transmitting IPv6 over ieee802.11-ocb Well, I don=E2=80=99t see how we would go about changing the 802.11 = headers, and changing IPv6 is out of the question, so I don=E2=80=99t = understand your point. Now, if you really wanna reduce overhead, we could talk about using IPv4 = instead. :-) :-) :-) Tony --Apple-Mail=_4EEFD410-9F65-4221-8FF6-6379D860BE3C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

IMO= you should stick to the network (and transport) layer, and let the DLL = guys do their = job.

The problem is = that their  job is not done, they are still amending to get = better performance (from ieee802.11p to ieee802.11px). = IMO we can consider performance when we transmit IPv6 over = such job. Additionally, recommend for better transmission = quality.


I=E2=80=99m gonna guess = that it=E2=80=99s very unlikely that they will significantly change = header formats when they do so. So I suspect that we=E2=80=99re quite = safe in proceeding as is.


Just to be clear: the purpose of trying to = provide an adaptation layer is so that we can simply reference RFC 2464 = (and friends) "Transmission of = IPv6 Packets over Ethernet Networks=E2=80=9D and be = done.

In wireless communication increasing frames header size = decreases performance. Using easy ways have always overheads. = Ethernet is wired network high speed and it is with very lower noise = compared with wireless. We should not forget mobility in our use = case.

We need = to reduce the overhead, and consider performance when = transmitting IPv6 over = ieee802.11-ocb


Well, I don=E2=80=99t = see how we would go about changing the 802.11 headers, and changing IPv6 = is out of the question, so I don=E2=80=99t understand your = point.

Now, if you really wanna = reduce overhead, we could talk about using IPv4 instead.  :-) :-) = :-)

Tony


= --Apple-Mail=_4EEFD410-9F65-4221-8FF6-6379D860BE3C-- From nobody Thu Feb 15 19:04:08 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FADD126CD6 for ; Thu, 15 Feb 2018 19:04:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-4Lz_rphK7z for ; Thu, 15 Feb 2018 19:04:06 -0800 (PST) Received: from imta-38.everyone.net (imta-36.everyone.net [216.200.145.36]) (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 D7BB31243F3 for ; Thu, 15 Feb 2018 19:04:06 -0800 (PST) Received: from pps.filterd (omta002.sj2.proofpoint.com [127.0.0.1]) by imta-38.everyone.net (8.16.0.22/8.16.0.22) with SMTP id w1G30rWh024487 for ; Thu, 15 Feb 2018 19:04:06 -0800 X-Eon-Originating-Account: oX42crMyCqsjuOVh4uoDAAuS1gN3KR-k7t_1Sl-3AndEKWXV5OgmcZateMoxg8fV X-Eon-Dm: m0116954.ppops.net Received: by m0117458.mta.everyone.net (EON-PICKUP) id m0117458.5a81d01c.63d7; Thu, 15 Feb 2018 19:04:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Message-Id: <20180215190401.8B15FFB2@m0117458.ppops.net> Date: Thu, 15 Feb 2018 19:04:01 -0800 From: "Scott Weeks" Reply-To: To: Content-Transfer-Encoding: base64 X-Eon-Sig: AQLAznNahkomxrLSIAEAAAAB,59f1c2d7ed38a3bae354402d003b8495 X-Originating-Ip: 74.87.40.2 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-16_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=2 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802160031 Archived-At: Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 - Normative text in Ethernet Adaptation Layer 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: Fri, 16 Feb 2018 03:04:08 -0000 DQoNCi0tLSBhYmR1c3NhbGFtYmFyeXVuQGdtYWlsLmNvbSB3cm90ZToNCkZyb206IEFiZHVzc2Fs YW0gQmFyeXVuIDxhYmR1c3NhbGFtYmFyeXVuQGdtYWlsLmNvbT4NCg0KDQo6OiBFdGhlcm5ldCBp cyB3aXJlZCBuZXR3b3JrIGhpZ2ggc3BlZWQgYW5kIGl0IGlzIHdpdGggDQo6OiB2ZXJ5IGxvd2Vy IG5vaXNlIGNvbXBhcmVkIHdpdGggd2lyZWxlc3MuDQoNCkkgd291bGQgYmVsaWV2ZSBtb3N0IGV2 ZXJ5b25lIGhlcmUgdW5kZXJzdGFuZHMgdGhpcyBpbiANCmdyZWF0IGRldGFpbC4uLg0KDQoNCjo6 IFdlIHNob3VsZCBub3QgZm9yZ2V0IG1vYmlsaXR5IGluIG91ciB1c2UgY2FzZS4NCg0KSXNuJ3Qg dGhhdCB3aGF0IHRoaXMgbGlzdCBpcyBhYm91dD8NCg0Kc2NvdHQNCg0KDQoNCg0KDQoNCi0tLSBh YmR1c3NhbGFtYmFyeXVuQGdtYWlsLmNvbSB3cm90ZToNCg0KRnJvbTogQWJkdXNzYWxhbSBCYXJ5 dW4gPGFiZHVzc2FsYW1iYXJ5dW5AZ21haWwuY29tPg0KVG86IGl0cyA8aXRzQGlldGYub3JnPg0K Q2M6IGRyYWZ0LWlldGYtaXB3YXZlLWlwdjYtb3Zlci04MDIxMW9jYkBpZXRmLm9yZywgRnJhbsOn b2lzIFNpbW9uIDxmeWdzaW1vbkBnbWFpbC5jb20+LCBSdXNzIEhvdXNsZXkgPGhvdXNsZXlAdmln aWxzZWMuY29tPiwgQWxleGFuZHJlIFBldHJlc2N1IDxhbGV4YW5kcmUucGV0cmVzY3VAZ21haWwu Y29tPiwgQ2FybG9zIEplc8O6cyBCZXJuYXJkb3MgQ2FubyA8Y2piY0BpdC51YzNtLmVzPiwgUmlj aGFyZCBSb3kgPGRpY2tyb3lAYWx1bS5taXQuZWR1PiwgU3VyZXNoIEtyaXNobmFuIDxzdXJlc2hA a2Fsb29tLmNvbT4NClN1YmplY3Q6IFJlOiBbaXB3YXZlXSBTaGVwaGVyZCByZXZpZXcgb2YgZHJh ZnQtaWV0Zi1pcHdhdmUtaXB2Ni1vdmVyLTgwMjExb2NiLTEyIC0gTm9ybWF0aXZlIHRleHQgaW4g RXRoZXJuZXQgQWRhcHRhdGlvbiBMYXllcg0KRGF0ZTogRnJpLCAxNiBGZWIgMjAxOCAwMzoyMjow MCArMDIwMA0KDQpPbiBUaHUsIEZlYiAxNSwgMjAxOCBhdCA5OjMyIFBNLCA8dG9ueS5saUB0b255 LmxpPiB3cm90ZToNCg0KPg0KPg0KPiBPbiBGZWIgMTUsIDIwMTgsIGF0IDEwOjI4IEFNLCBEaWNr IFJveSA8ZGlja3JveUBhbHVtLm1pdC5lZHU+IHdyb3RlOg0KPg0KPiAqSU1PIHlvdSBzaG91bGQg c3RpY2sgdG8gdGhlIG5ldHdvcmsgKGFuZCB0cmFuc3BvcnQpIGxheWVyLCBhbmQgbGV0IHRoZQ0K PiBETEwgZ3V5cyBkbyB0aGVpciBqb2IuKg0KPg0KPg0KVGhlIHByb2JsZW0gaXMgdGhhdCB0aGVp ciAgam9iIGlzIG5vdCBkb25lLCB0aGV5IGFyZSBzdGlsbCBhbWVuZGluZyB0byBnZXQNCmJldHRl ciBwZXJmb3JtYW5jZSAoZnJvbSBpZWVlODAyLjExcCB0byBpZWVlODAyLjExcHgpLiBJTU8gd2Ug Y2FuIGNvbnNpZGVyDQpwZXJmb3JtYW5jZSB3aGVuIHdlIHRyYW5zbWl0IElQdjYgb3ZlciBzdWNo IGpvYi4gQWRkaXRpb25hbGx5LCByZWNvbW1lbmQNCmZvciBiZXR0ZXIgdHJhbnNtaXNzaW9uIHF1 YWxpdHkuDQoNCg0KPg0KPiBKdXN0IHRvIGJlIGNsZWFyOiB0aGUgcHVycG9zZSBvZiB0cnlpbmcg dG8gcHJvdmlkZSBhbiBhZGFwdGF0aW9uIGxheWVyIGlzDQo+IHNvIHRoYXQgd2UgY2FuIHNpbXBs eSByZWZlcmVuY2UgUkZDIDI0NjQgKGFuZCBmcmllbmRzKSAiVHJhbnNtaXNzaW9uIG9mDQo+IElQ djYgUGFja2V0cyBvdmVyIEV0aGVybmV0IE5ldHdvcmtz4oCdIGFuZCBiZSBkb25lLg0KPg0KDQpJ biB3aXJlbGVzcyBjb21tdW5pY2F0aW9uIGluY3JlYXNpbmcgZnJhbWVzIGhlYWRlciBzaXplIGRl Y3JlYXNlcw0KcGVyZm9ybWFuY2UuIFVzaW5nIGVhc3kgd2F5cyBoYXZlIGFsd2F5cyBvdmVyaGVh ZHMuIEV0aGVybmV0IGlzIHdpcmVkDQpuZXR3b3JrIGhpZ2ggc3BlZWQgYW5kIGl0IGlzIHdpdGgg dmVyeSBsb3dlciBub2lzZSBjb21wYXJlZCB3aXRoIHdpcmVsZXNzLg0KV2Ugc2hvdWxkIG5vdCBm b3JnZXQgbW9iaWxpdHkgaW4gb3VyIHVzZSBjYXNlLg0KDQpXZSBuZWVkIHRvIHJlZHVjZSB0aGUg b3ZlcmhlYWQsIGFuZCBjb25zaWRlciBwZXJmb3JtYW5jZSB3aGVuIHRyYW5zbWl0dGluZw0KSVB2 NiBvdmVyIGllZWU4MDIuMTEtb2NiDQoNCkFCDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCml0cyBtYWlsaW5nIGxpc3QNCml0c0BpZXRmLm9yZw0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pdHMNCg0KDQo= From nobody Thu Feb 15 19:13:12 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5C6F126CD6; Thu, 15 Feb 2018 19:13:10 -0800 (PST) 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 13lLwp9vd5dY; Thu, 15 Feb 2018 19:13:09 -0800 (PST) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDB4A1243F3; Thu, 15 Feb 2018 19:13:08 -0800 (PST) Received: by mail-oi0-x235.google.com with SMTP id t145so1393407oif.8; Thu, 15 Feb 2018 19:13:08 -0800 (PST) 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=5bjpAo2q29YttaQB9q4gakKbei22fMU59CDxzKbXtHk=; b=kHF2EI6ZEYlBusbEExPtcrSsEbDhsCukuihIx/VfBGku05pafedqcncvhmxnofYkLi 5gDk2ywXJ4yzbzTqM6jAviAvLwu02b2opD9mWPshjkQfXi4AaC0MLbMUQFUTMpjdpywj p/g4UMy53gQh7t6mGkDmQngwK6mpQ1KVmAM8c359eTXtWuepJMZ3WG3cOqimkvry1Ci3 o/OAwmz1k95v4KGJNQyWTb5gFcTW9aCYtqxThgjW8qiTHBXpEsDEqi84vQL2pYQEF0db TpxNzOHd1HmqB99kcxWckcLS6cQOdbYgZppps620r3EFIBjKK210M1BR0b/10BoW2kwT F9EA== 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=5bjpAo2q29YttaQB9q4gakKbei22fMU59CDxzKbXtHk=; b=b1XrD+CijrlOHFz+RqLCYL3grzrO6e0iybdY6RHi55whzOzL56SzvYQ6ITPuGc6cII qGUvOT6ErrDefBDDFrCDJUKxIaQKPUvq76ZxuzN7d0I71+DxTb7UV688ZG3G17VUJ1Sn VcTrTXTCGSwi6XjOHR+YkZrGLaFlFkM2bCT5k0uovvEk6HQkHXRknAd2ZkPEa/fKsEeb 3xPMs3Nr9Ri4icUShXLvFkAANrEIBa31e48V3thxogj6OgptE/yQajhaTucH+TVWFQh9 SCW7Q6k8wEUST8tKB2oOHwhQnm7Oc77QXHVZ37WBN9uXAciJ/6bnrgQZt++ff36I2lur kCUA== X-Gm-Message-State: APf1xPAgcPpdacjRg9pRPjQQSnbCq+VLflWyRLvX1UF20e+PMaOAzfIb w7Kvpfo2n7UzP4uuXFxBixBOE7ibBxWMp0St4urQTg== X-Google-Smtp-Source: AH8x225tAx/FDCodNAEqGpyw8oTyVPl5ySvEIt0LDpkPcC6wqXHTWCsunnlo3YADUAlTmk7SnXq1wm+w3HALq+2k6ZI= X-Received: by 10.202.80.200 with SMTP id e191mr3160931oib.333.1518750788222; Thu, 15 Feb 2018 19:13:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.44 with HTTP; Thu, 15 Feb 2018 19:13:07 -0800 (PST) In-Reply-To: References: <1517217856.4315.32.camel@it.uc3m.es> <87A7E5C11E9C48DB84FBE2CE78537448@SRA6> <7D76FB29BFE54E8AA9516CC1971A77E2@SRA6> <016e01d3a680$42697ab0$c73c7010$@gmail.com> From: Abdussalam Baryun Date: Fri, 16 Feb 2018 05:13:07 +0200 Message-ID: To: Alexandre Petrescu Cc: =?UTF-8?Q?Fran=C3=A7ois_Simon?= , draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org, Russ Housley , its , =?UTF-8?Q?Carlos_Jes=C3=BAs_Bernardos_Cano?= , Suresh Krishnan Content-Type: multipart/alternative; boundary="001a113b02b43c060605654bb959" Archived-At: Subject: Re: [ipwave] addresses 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: Fri, 16 Feb 2018 03:13:11 -0000 --001a113b02b43c060605654bb959 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Feb 15, 2018 at 8:35 PM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > Allow me to top post here to try to converge. > > The hex dump of one 802.11 header shows two addresses and a BSS Id. One > such address is called "Receiver Address" and "Destination Address" at > the same time. Another such address is called "Transmitter address" and > "Source address" at the same time. There are only three 48bit values in > there (two addresses and a BSS Id). > > The hex dump of the corresponding Ethernet II header shows two > addresses. One is called "Destination" and the other is called > "Source". There are only two 48bit values in there (no BSS Id). > > The current text in the draft says: > >> 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. >> > I checked the ieee802.11 -2016 doc it shows no RA and TA fields. The Field-names are: Address 1 Field and Address 2 Field, as mentioned by Simon below. So as Simon mentioned only three address fields in this OCB data frame. > This text still seems correct to me. > We can amend the words related to fields in the frame, to make it easier to understand, > It could be improved along two directions: (1) use "MUST contain" > instead of "contain" if we wanted to make it more normative and (2) use > "Receiver or Destination" instead of just "Receiver" and "Transmitter or > Source" instead of just "Transmitter". > > The NEW text could look like this: > >> The Receiver or Destination address, and the Transmitter or Source >> address in the 802.11 Data Header MUST contain the same values as the >> Destination and the Source fields in the Ethernet II Header, >> respectively. >> > > NEW> The Address 1 and Address 2 fields in the 802.11 Data Header contain the same addresses as the Destination and the Source Address fields in the Ethernet II Header, respectively. While address 3 field that contains all binary 1s AB > > Alex > > > Le 15/02/2018 =C3=A0 18:13, Fran=C3=A7ois Simon a =C3=A9crit : > >> "/There are four address fields in the MAC frame format. These fields >> are used to indicate the basic service set identifier (BSSID), >> source address (SA), destination address (DA), transmitting STA >> address (TA), and receiving STA address (RA). Certain frames might >> not contain some of the address fields.//"/ >> >> In OCB: >> >> Address field 1 =3D Receiver Address (RA) >> >> Address field 2 =3D Transmitter Address (TA) (MAC address) >> >> Address field 3 =3D BSSID (all '1s') >> >> Address field 4 =3D Source Address (SA) Source Address (omitted) >> >> 3 address fields (1, 2, and 3) are used. >> >> ToDS and FromDS =3D 0b0 >> >> Fygs >> >> --001a113b02b43c060605654bb959 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Feb 15, 2018 at 8:35 PM, Alexandre Petrescu &= lt;alexan= dre.petrescu@gmail.com> wrote:
Allow me t= o top post here to try to converge.

The hex dump of one 802.11 header shows two addresses and a BSS Id.=C2=A0 O= ne
such address is called "Receiver Address" and "Destination A= ddress" at
the same time.=C2=A0 Another such address is called "Transmitter addre= ss" and
"Source address" at the same time.=C2=A0 There are only three 48b= it values in
there (two addresses and a BSS Id).

The hex dump of the corresponding Ethernet II header shows two
addresses.=C2=A0 One is called "Destination" and the other is cal= led
"Source".=C2=A0 There are only two 48bit values in there (no BSS = Id).

The current text in the draft says:
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.

I=C2=A0checked the ieee802.11=C2=A0-2016 doc = it shows no RA and TA fields. The Field-names are:=C2=A0Address 1 Field and= Address 2 Field, as mentioned by Simon below.
So as Simon mentio= ned only three address fields in this OCB data frame.

=

This text still seems correct to me.

We= can amend the words related to fields in the frame, to make it easier to u= nderstand,


It could be improved along two directions: (1) use "MUST contain"=
instead of "contain" if we wanted to make it more normative and (= 2) use "Receiver or Destination" instead of just "Receiver&q= uot; and "Transmitter or Source" instead of just "Transmitte= r".

The NEW text could look like this:
The Receiver or Destination address, and the Transmitter or Source
address in the 802.11 Data Header MUST contain the same values as the
Destination and the Source fields in the Ethernet II Header,
respectively.

> NEW>=
The=C2=A0Address 1=C2=A0and Address 2=C2=A0fields in the 802= .11 Data
Header contain the same=C2=A0addresses as the Destination and = the Source
Address fields in the Ethernet II Header, respectively.


While address 3 field that contains all= binary 1s

AB
<= div>

=C2=A0

Alex


Le 15/02/2018 =C3=A0 18:13, Fran=C3=A7ois Simon a =C3=A9crit :
"/There are four address fields in the MAC frame format. These fields<= br> =C2=A0are used to indicate the basic service set identifier (BSSID),
source address (SA), destination address (DA), transmitting STA
address (TA), and receiving STA address (RA). Certain frames might
not contain some of the address fields.//"/

In OCB:

Address field 1 =3D Receiver Address (RA)

Address field 2 =3D Transmitter Address (TA) (MAC address)

Address field 3 =3D BSSID (all '1s')

Address field 4 =3D Source Address (SA) Source Address (omitted)

3 address fields (1, 2, and 3) are used.

ToDS and FromDS =3D 0b0

Fygs


--001a113b02b43c060605654bb959-- From nobody Thu Feb 15 19:40:41 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE5D12778E for ; Thu, 15 Feb 2018 19:40:40 -0800 (PST) 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 7Qi5t0sQ8WUO for ; Thu, 15 Feb 2018 19:40:38 -0800 (PST) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81C86127735 for ; Thu, 15 Feb 2018 19:40:38 -0800 (PST) Received: by mail-oi0-x22d.google.com with SMTP id 8so1422646oix.7 for ; Thu, 15 Feb 2018 19:40:38 -0800 (PST) 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=AUHnYhydIpxHePAcE0bOz6ygh0bTWuXB21sJ0Urx0uk=; b=dOba3CduKrGVmu8jS/KZ6zsfk3ifldRFoGeJYrsmg+gntsGgusRsUMH2mhoC9fcSwm bx/6iKRirymeJhFWu9e9ow5pgzo2Lx/TPIauCWnrP7Ft9qghavL3nshMghhi1H4JbPe+ M6+9l1Qn19hcc+HJOTeOljvCs9/KPJem0exAUXWmt5IamRFLbz6iokRXQVNau1TSj834 ZhqCF/KUfQuNQTkCIyjArG9ncz92qmNDFSbt7JVKPH+gnSr7NisdDsz/Hge+0AaR+78T h7JL2aUgOATEPC6kdcSL4TC8BR//SB14YGOx7/iPDeA+rytN22T+qh9/akq9sQ35xKs9 EWPA== 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=AUHnYhydIpxHePAcE0bOz6ygh0bTWuXB21sJ0Urx0uk=; b=tdTtL0hTvRhsHkj5GgXEEWYsViMb9zsvXfM4KzF2LfromJERyDSK88J7VAWV3bJBha skExa4oTpEwHYgRMVwiIPLQDkJYYNias2GajtNHh+wfPKNLrYwbv0cOE27rw8eIUQuDv Sodf3N5wJcFQXa7nzKSpq5cAyWppvj1oGr9bRBnh7HocBbZayDYOLbxqNX4kRsP9bTHl X4frLZCXS9VVl60ozF2cXwSN70Ue0m33Ue8xM/WKXGOB5JT7G+5uw16wZIuOuzT+eSFG BvEvhCvTCTOJdmBZsd1kzxY6t3AoBuyRzCIdQ6bcvTqCDVTsOFudlXnsnrExSnbPjplc xHMQ== X-Gm-Message-State: APf1xPCcWa+MlEsJBdI/wJ9FSw1bYJZwMIroiEGAhU5oUjECbXFqWWmp gadMeMyRTWCgNTewOdkyzMJHOgcEZRX0f4mZ1L8= X-Google-Smtp-Source: AH8x2252QfOLwKfgIUIcyrEkwS8pjlSuBh9etq96E+2dkp63FVv8cGnqwCA9HpdopEqUcPB+/TwnqdusER/mmnBIfI8= X-Received: by 10.202.204.203 with SMTP id c194mr3506954oig.156.1518752437944; Thu, 15 Feb 2018 19:40:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.44 with HTTP; Thu, 15 Feb 2018 19:40:37 -0800 (PST) In-Reply-To: References: <151869691215.7607.4477863832246767156.idtracker@ietfa.amsl.com> <4b498e61-d514-26fd-f417-184bfe36e784@gmail.com> From: Abdussalam Baryun Date: Fri, 16 Feb 2018 05:40:37 +0200 Message-ID: To: Alexandre Petrescu Cc: Nabil Benamar , Tony Li , "its@ietf.org" Content-Type: multipart/alternative; boundary="001a1134f34290c6a405654c1b44" Archived-At: Subject: Re: [ipwave] New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-17.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: Fri, 16 Feb 2018 03:40:40 -0000 --001a1134f34290c6a405654c1b44 Content-Type: text/plain; charset="UTF-8" On Thu, Feb 15, 2018 at 7:30 PM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > I agree, I will update > > That field is not sequence number field, but sequence control field. Each sequence control field contains two subfields, the sequence number , and fragment number. I think we should increase the fragment number within the sequence control field. AB --001a1134f34290c6a405654c1b44 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Feb 15, 2018 at 7:30 PM, Alexandre Petrescu &= lt;alexan= dre.petrescu@gmail.com> wrote:
I agree, I= will update


That field is not sequence number fiel= d, but sequence control field. Each sequence control field contains two sub= fields, the sequence number=C2=A0, and fragment number. I think we should i= ncrease the fragment number within the sequence control field.
AB
--001a1134f34290c6a405654c1b44-- From nobody Fri Feb 16 02:18:52 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74C17126C19 for ; Fri, 16 Feb 2018 02:18:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 N3uk5kxIJgG8 for ; Fri, 16 Feb 2018 02:18:48 -0800 (PST) Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::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 CBC531242F7 for ; Fri, 16 Feb 2018 02:18:48 -0800 (PST) Received: by mail-ot0-x230.google.com with SMTP id s4so2276265oth.7 for ; Fri, 16 Feb 2018 02:18:48 -0800 (PST) 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=MrfS5gduM2CLXT0UPhQrvhTwv++apOp1BjYuhVozIjg=; b=opTcQ76IlKzJZW2S9h5IElSGh6Fjb5MDgTstZE52p+SkkFI8VqADRJf/3uTSrdFzRZ VrqbAcY8KE6Ylb1Ah8MbkN0wWHq+16bzso65u68BjakNmIYTnYTmOvMtvZB9nSEjfj80 J9iTOOiiAzscZf9ecDE/+H9IQZYfNNZtAESsKXEt3mfKd+8MbCJvYrJsdGnkp4xEUyQ6 SkF4YKDV9hENenOboZweYJBfkBMkyn/cLT7o2cRpajdvKIQ0IPQMyBnaEmxEoaGn0/n/ VEJ0fuC+CNuaomTCZEdi1xNsGNORmzALVcHGEo0yXJPJSALqwKfFXaee4BmvPNJ9uHfV 5u1g== 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=MrfS5gduM2CLXT0UPhQrvhTwv++apOp1BjYuhVozIjg=; b=YPEwQbvO3L1TB0fKRgmEp5U8KaUknRTZ1tAxWECzde4BnaDxnnNm99clTpg/GQmGff izyVry4yqu0rGL06B8ZsrwFY+Z8e3PaDoj1HQGztX7s9SdAQKjY3JlnFTC3LsZWIYaNw XrdR9eSkB3BKlQOVokOhsRx8QNQ5YJTUNKiBou6h3lkf2SNWHKwF7cAl5ZFWGaOIqWsG WqJYC6GVnMOE/L47aSauA5aCgBqpSnJs0+3mes9eEultNuc6Z0C4AiAkLR65uQh8L7WP Ee46xNjbdMWl4cCkDCWgvdFNsHbhMEwjTa5xAurYXvkdMpUwTOVoBdIUG3d0jakiyG9v 2pHw== X-Gm-Message-State: APf1xPAwbmBaNm2GZFeQp29Z5o4tU8y/NZ5NmuERxYYaqt1meOU943HN o2H6F2mtpC6WZ0oGYq/Md5Cq4i9qACa0T5d6r7I= X-Google-Smtp-Source: AH8x225gJmoZRNfmbwc+tXV9gchdUAvXvVPfN3MdvZo75mc/maDRxDUd1NCN+pOiLYlXkWzDPHVqgPRktEZ+O1p4+rs= X-Received: by 10.157.84.8 with SMTP id j8mr3861314oth.350.1518776328119; Fri, 16 Feb 2018 02:18:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.44 with HTTP; Fri, 16 Feb 2018 02:18:47 -0800 (PST) In-Reply-To: <0B193B500532444F872E6666340A2F99@SRA6> References: <151869691215.7607.4477863832246767156.idtracker@ietfa.amsl.com> <4b498e61-d514-26fd-f417-184bfe36e784@gmail.com> <0B193B500532444F872E6666340A2F99@SRA6> From: Abdussalam Baryun Date: Fri, 16 Feb 2018 12:18:47 +0200 Message-ID: To: Richard Roy Cc: Alexandre Petrescu , Nabil Benamar , Tony Li , its Content-Type: multipart/alternative; boundary="f403043c62e887efa4056551abd1" Archived-At: Subject: Re: [ipwave] New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-17.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: Fri, 16 Feb 2018 10:18:50 -0000 --f403043c62e887efa4056551abd1 Content-Type: text/plain; charset="UTF-8" On Fri, Feb 16, 2018 at 9:10 AM, Dick Roy wrote: > The field in question is a MAC fragmentation control field, NOT a network > layer control field. Any thought that the IPv6 protocol should update, or > cause to be updated, a fragmentation control field in a lower layer is > misguided, a layer violation, and will not work w.p.1. > > > > I highly recommend you not do this. > I agree with you. My reply just was to answer if the WG-and-authors insisted to go that path, AB --f403043c62e887efa4056551abd1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Feb 16, 2018 at 9:10 AM, Dick Roy <dickroy@alum.mit.edu= > wrote:

The field in questio= n is a MAC fragmentation control field, NOT a network layer control field.=C2=A0 Any t= hought that the IPv6 protocol should update, or cause to be updated, a fragmentati= on control field in a lower layer is misguided, a layer violation, and will not work w.p.1.

=C2=A0=

I highly recommend y= ou not do this.


I agree with you.=C2=A0My reply just was to answer if the WG-and-authors= insisted to go that path,

AB
--f403043c62e887efa4056551abd1-- From nobody Fri Feb 16 02:39:59 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEC14126B6D for ; Fri, 16 Feb 2018 02:39:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.634 X-Spam-Level: X-Spam-Status: No, score=-2.634 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, RCVD_IN_MSPIKE_H2=-0.001, 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 q9GW6LMaPwv5 for ; Fri, 16 Feb 2018 02:39:56 -0800 (PST) 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 D034412D878 for ; Fri, 16 Feb 2018 02:39:55 -0800 (PST) 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 w1GAdn0q035892; Fri, 16 Feb 2018 11:39:49 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id EE514203B46; Fri, 16 Feb 2018 11:39:49 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id D827C203AA6; Fri, 16 Feb 2018 11:39:49 +0100 (CET) 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 w1GAdnaL009522; Fri, 16 Feb 2018 11:39:49 +0100 To: Knut Evensen , "dickroy@alum.mit.edu" , "'Abdussalam Baryun'" Cc: "mrcullen42@gmail.com" , "'its'" , "hjfischer@fischer-tech.eu" References: <1506192164.12227.3.camel@it.uc3m.es> <390b03ec-27a6-43e3-3ea1-95715d253980@gmail.com> <97975302-2ab4-d9b9-d825-758bf2371dff@gmail.com> <24809DE2FFDE44A9B11AA5ACB3A0D1BE@SRA6> <45d910cb-7a1e-4e37-12c7-aa8bd4d311bb@gmail.com> <79AE367CE5524ECF9E35CBFC5494498D@SRA6> <0b5ac980-b7fd-c61e-630b-3333e1b77c53@gmail.com> <4C0B3578C0EA4DF8A40F55AAEFC5F4EC@SRA6> <3730fd8c-8c15-6bb4-416a-933a7165ba36@gmail.com> From: Alexandre Petrescu Message-ID: Date: Fri, 16 Feb 2018 11:39:49 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.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] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-08 - other SDOs IPR and licensing 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: Fri, 16 Feb 2018 10:39:58 -0000 Thanks for the message. Le 15/02/2018 à 20:30, Knut Evensen a écrit : > Yes, this is one of the disadvantages with CEN and ISO keeping their > standards under strict IPR, whilst ETSI offer them freely > downloadable so Google can crawl and index them every half hour... I agree CEN and ISO have most (not all) of their documents 'hidden', i.e. have to pay money to access them. But it is worth noting that ETSI ITS standards, while publicly and freely available, are also covered by a number of IPR and licensing aspects. For example, ETSI ITS CAM message and GeoNetworking are IPRed by several enterprises and the licensing scheme is mentioned in the publicly available ETSI IPR Policy. Also worth mentioning that ETSI ITS standards under development are not publicly available (e.g. currently platooning). They can be accessed only if paying member of ETSI. Another problem is when a publicly and freely available ETSI ITS standard refers to an ISO document that is not freely available. Without it, the first is hard if not impossible to implement. Alex From nobody Fri Feb 16 02:46:41 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5F7212D7EE for ; Fri, 16 Feb 2018 02:46:40 -0800 (PST) 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 NxbpT0b6xgD0 for ; Fri, 16 Feb 2018 02:46:39 -0800 (PST) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19F6F12773A for ; Fri, 16 Feb 2018 02:46:39 -0800 (PST) Received: by mail-oi0-x230.google.com with SMTP id r144so1973506oie.6 for ; Fri, 16 Feb 2018 02:46:39 -0800 (PST) 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=7Lw+B5Dk1Z5dddHjlwwAaVx+q5MFqL0DlO3vtCtan8w=; b=iZjh6gtDV4fDfIPV8+Y5qE7SAPy5OQryFSN/AxvRdTZ/8ZEomOp0moiH5h+5jKmkZh F6Y6s3n8eFXsPTwqpQaruj2C466DcgLPzCXvFdKctW8UDJstjHFfs/NW73juFi5y99D3 hiSEIkIcBqgawwV1dPt6BRhtdhEi8tz6R+YbFlonfew6XVcIAM11vDHtyz8rlk2oah8A JLgwkld1r2BGanCWrP3e2fEADZfwMnd/a5Y7pS8DT3nJGmFP7FFKOTnJek4SWFxS1kb7 1kjZJUC+LLlXtDlfGe4+iIN+a07ECc8wvKVmbcgDKx1K4MD7QaA00PdVJzw6PEkti2JE lj2A== 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=7Lw+B5Dk1Z5dddHjlwwAaVx+q5MFqL0DlO3vtCtan8w=; b=lqbopY6wdrxrzfK6bKlTcn06mW5foSY3vsIUU1/ssxP5XrCYbo3bNaHut0im36Dktd c7Ff4NIHiu50xYRMOKd7DP5B08jBeVtCRx/5x4sQp2vDJd8Muo62q03MEe6s85DAQBfi Zxld8SKEys/M3WF6HuZDTF8H169ew9FBjsImi53i0Hzk8wNzkOF+xYnS5BH3kIEXbx9F aM/7w5wjmlOHfLjQQmCxvQeURYxeuvt8fWkIRoX1Z4uhohq0uXmse6++qKuE2FEuM80e /96iayf4K2IpdxXDfOTtmeJvfgyQbT8ngFbSOxe9HQClI8zcr/2kEZTT0kf4p+h+2eEv uT1A== X-Gm-Message-State: APf1xPDQ5vh8pWwGhVeC2vnTT9cjizHDFQsVZ1ci3u1/LSBct2FGF3yu JVz9zykjqsgD4kKqmrIbZTIQR2QOr0HwWaujMpE= X-Google-Smtp-Source: AH8x227U1vy8Ucc9lKUc31Bm2+Undc6DnyiYwf7/0zzqYX9lzGU5uxvOSvFdOsRjUyn22EPVfmVv/H26ObqERaTcsD4= X-Received: by 10.202.204.203 with SMTP id c194mr4070790oig.156.1518777998515; Fri, 16 Feb 2018 02:46:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.44 with HTTP; Fri, 16 Feb 2018 02:46:38 -0800 (PST) In-Reply-To: References: <151869691215.7607.4477863832246767156.idtracker@ietfa.amsl.com> From: Abdussalam Baryun Date: Fri, 16 Feb 2018 12:46:38 +0200 Message-ID: To: Alexandre Petrescu Cc: "its@ietf.org" Content-Type: multipart/alternative; boundary="001a1134f3421824d10565520fde" Archived-At: Subject: Re: [ipwave] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-17.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: Fri, 16 Feb 2018 10:46:41 -0000 --001a1134f3421824d10565520fde Content-Type: text/plain; charset="UTF-8" On Thu, Feb 15, 2018 at 2:19 PM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > Hi IPWAVErs, > > I submitted a new version of the IPv6-over-OCB draft - the 17th. > > The ChangeLog is: > > Susbtituted "MUST be increased" to "is increased" in the > MTU section, about fragmentation. > > The phrases in question are: > > NEW: > > If IPv6 packets of size larger than > 1500 bytes are sent on an 802.11-OCB interface card then the IP stack > MUST fragment. In case there are IP fragments, the field "Sequence > number" of the 802.11 Data header containing the IP fragment field is > increased. > > Replace last sentence above> In case there are IP fragments, the subfield fragment number within the field "Sequence control" of The 802.11 data header containing the IP fragment is increased by MAC layer. > > AB --001a1134f3421824d10565520fde Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Feb 15, 2018 at 2:19 PM, Alexandre Petrescu &= lt;alexan= dre.petrescu@gmail.com> wrote:
=20 =20 =20

Hi IPWAVErs,

I submitted a new version of the IPv6-over-OCB draft - the 17th.

The ChangeLog is:

=C2=A0=C2=A0=C2=A0 =C2= =A0=C2=A0=C2=A0 Susbtituted "MUST be increased" to "is increased" in the<= br> =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 MTU section, about fragment= ation.

The phrases in question are:

NEW:

            =
                         If IPv6 packets of size larger than
   1500 bytes are sent on an 802.11-OCB interface card then the IP stack
   MUST fragment.  In case there are IP fragments, the field "Sequence
   number" of the 802.11 Data header containing the IP fragment field =
is
   increased.
Repla= ce last sentence above>

In case there are IP fr= agments, the subfield fragment number within the field "Sequence
= =C2=A0=C2=A0 control" of The 802.11 data header containing= the IP fragment is increased by MAC layer.=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
=

AB=C2=A0
--001a1134f3421824d10565520fde-- From nobody Fri Feb 16 03:03:47 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DFDB12D7EE for ; Fri, 16 Feb 2018 03:03:45 -0800 (PST) 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 veXp-yMMN76z for ; Fri, 16 Feb 2018 03:03:42 -0800 (PST) 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 9DAE9126D46 for ; Fri, 16 Feb 2018 03:03:42 -0800 (PST) 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 w1GB3elG007278; Fri, 16 Feb 2018 12:03:40 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A7ECD203B36; Fri, 16 Feb 2018 12:03:40 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 90C41201D36; Fri, 16 Feb 2018 12:03:40 +0100 (CET) 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 w1GB3eto002040; Fri, 16 Feb 2018 12:03:40 +0100 To: Abdussalam Baryun Cc: "its@ietf.org" References: <151869691215.7607.4477863832246767156.idtracker@ietfa.amsl.com> From: Alexandre Petrescu Message-ID: <02fbd867-9694-e68e-a328-6154d6ead9d9@gmail.com> Date: Fri, 16 Feb 2018 12:03:40 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.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] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-17.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: Fri, 16 Feb 2018 11:03:45 -0000 Le 16/02/2018 à 11:46, Abdussalam Baryun a écrit : > > > On Thu, Feb 15, 2018 at 2:19 PM, Alexandre Petrescu > > wrote: > > Hi IPWAVErs, > > I submitted a new version of the IPv6-over-OCB draft - the 17th. > > The ChangeLog is: > >         Susbtituted "MUST be increased" to "is increased" in the >         MTU section, about fragmentation. > > The phrases in question are: > > NEW: > >> If IPv6 packets of size larger than >> 1500 bytes are sent on an 802.11-OCB interface card then the IP stack >> MUST fragment. In case there are IP fragments, the field "Sequence >> number" of the 802.11 Data header containing the IP fragment field is >> increased. > > Replace last sentence above> > > In case there are IP fragments, the subfield fragment number within the > field "Sequence >    control" of The 802.11 data header containing the IP fragment is > increased by MAC layer. Is the combination of Fragment Number and Sequence Number subfields called "Sequence control" by IEEE? Alex > > > AB From nobody Fri Feb 16 03:15:28 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1BF4126CC4 for ; Fri, 16 Feb 2018 03:15:25 -0800 (PST) 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 1QN-2TnBSGPh for ; Fri, 16 Feb 2018 03:15:24 -0800 (PST) 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 0D44B1201F8 for ; Fri, 16 Feb 2018 03:15:23 -0800 (PST) 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 w1GBFMS6011315 for ; Fri, 16 Feb 2018 12:15:22 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 65DA7201FE9 for ; Fri, 16 Feb 2018 12:15:22 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 5AA06203BA7 for ; Fri, 16 Feb 2018 12:15:22 +0100 (CET) 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 w1GBFMpx013827 for ; Fri, 16 Feb 2018 12:15:22 +0100 To: its@ietf.org References: <151869691215.7607.4477863832246767156.idtracker@ietfa.amsl.com> <02fbd867-9694-e68e-a328-6154d6ead9d9@gmail.com> From: Alexandre Petrescu Message-ID: <04bd0889-8c37-e16f-f72f-acbf72352aee@gmail.com> Date: Fri, 16 Feb 2018 12:15:22 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <02fbd867-9694-e68e-a328-6154d6ead9d9@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-17.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: Fri, 16 Feb 2018 11:15:26 -0000 This is the NEW text in my local copy. There is some issue with the submission system (wrong date, and new Trust 200912 instead of 200902). I will submit as soon as the system works. > If IPv6 > packets of size larger than the MTU are sent on an > 802.11-OCB interface card then the IP stack MUST fragment. > In case there are IPv6 fragments, the subfield "Fragment > number" within the field "Sequence control" of the 802.11 > Data header containing the IPv6 fragment is increased by the > MAC layer. Alex Le 16/02/2018 à 12:03, Alexandre Petrescu a écrit : > > > Le 16/02/2018 à 11:46, Abdussalam Baryun a écrit : >> >> >> On Thu, Feb 15, 2018 at 2:19 PM, Alexandre Petrescu >> > >> wrote: >> >>     Hi IPWAVErs, >> >>     I submitted a new version of the IPv6-over-OCB draft - the 17th. >> >>     The ChangeLog is: >> >>              Susbtituted "MUST be increased" to "is increased" in the >>              MTU section, about fragmentation. >> >>     The phrases in question are: >> >>     NEW: >> >>>                                           If IPv6 packets of size >>> larger than >>>         1500 bytes are sent on an 802.11-OCB interface card then the >>> IP stack >>>         MUST fragment.  In case there are IP fragments, the field >>> "Sequence >>>         number" of the 802.11 Data header containing the IP fragment >>> field is >>>         increased. >> >> Replace last sentence above> >> >> In case there are IP fragments, the subfield fragment number within >> the field "Sequence >>     control" of The 802.11 data header containing the IP fragment is >> increased by MAC layer. > > Is the combination of Fragment Number and Sequence Number subfields > called "Sequence control" by IEEE? > > Alex > >> >> >> AB > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Fri Feb 16 07:22:11 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB0E12D87F for ; Fri, 16 Feb 2018 07:22:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.624 X-Spam-Level: X-Spam-Status: No, score=-2.624 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_SOFTFAIL=0.665, T_FREEMAIL_DOC_PDF=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3efTRDQPlKT for ; Fri, 16 Feb 2018 07:22:07 -0800 (PST) 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 9C99F120454 for ; Fri, 16 Feb 2018 07:22:06 -0800 (PST) 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 w1GFM08k028450; Fri, 16 Feb 2018 16:22:00 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2359B206EBF; Fri, 16 Feb 2018 16:22:00 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id E078D201661; Fri, 16 Feb 2018 16:21:59 +0100 (CET) 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 w1GFLwiB002756; Fri, 16 Feb 2018 16:21:58 +0100 To: dickroy@alum.mit.edu, "'Knut Evensen'" , "'Abdussalam Baryun'" Cc: hjfischer@fischer-tech.eu, mrcullen42@gmail.com, "'its'" References: <1506192164.12227.3.camel@it.uc3m.es> <390b03ec-27a6-43e3-3ea1-95715d253980@gmail.com> <97975302-2ab4-d9b9-d825-758bf2371dff@gmail.com> <24809DE2FFDE44A9B11AA5ACB3A0D1BE@SRA6> <45d910cb-7a1e-4e37-12c7-aa8bd4d311bb@gmail.com> <79AE367CE5524ECF9E35CBFC5494498D@SRA6> <0b5ac980-b7fd-c61e-630b-3333e1b77c53@gmail.com> <4C0B3578C0EA4DF8A40F55AAEFC5F4EC@SRA6> <3730fd8c-8c15-6bb4-416a-933a7165ba36@gmail.com> <9FB57A61ECEB4E14B8907B22C7CD5AAA@SRA6> From: Alexandre Petrescu Message-ID: Date: Fri, 16 Feb 2018 16:21:58 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <9FB57A61ECEB4E14B8907B22C7CD5AAA@SRA6> Content-Type: multipart/mixed; boundary="------------CF1EC0345B9BE4B0480D3D89" Content-Language: fr Archived-At: Subject: Re: [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-08 - other SDOs IPR and licensing 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: Fri, 16 Feb 2018 15:22:10 -0000 This is a multi-part message in MIME format. --------------CF1EC0345B9BE4B0480D3D89 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit The info of IPR on CAM (EN 302 637-2, among others), is publicly available on ipr.etsi.org, excerpts attached. I make sure I am telling: I am not a lawyer. Alex Le 16/02/2018 à 14:56, Dick Roy a écrit : > Alex, > > I am well-aware, and painfully so, of the GeoNotworking IPR. To date, I am > not aware of any IPR related to the CAM application specifications. Can you > provide a reference to such IP and the assignees thereof? > > RR > > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu > Sent: Friday, February 16, 2018 2:40 AM > To: Knut Evensen; dickroy@alum.mit.edu; 'Abdussalam Baryun' > Cc: hjfischer@fischer-tech.eu; mrcullen42@gmail.com; 'its' > Subject: Re: [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-08 - > other SDOs IPR and licensing > > Thanks for the message. > > Le 15/02/2018 à 20:30, Knut Evensen a écrit : >> Yes, this is one of the disadvantages with CEN and ISO keeping their >> standards under strict IPR, whilst ETSI offer them freely >> downloadable so Google can crawl and index them every half hour... > > I agree CEN and ISO have most (not all) of their documents 'hidden', > i.e. have to pay money to access them. > > But it is worth noting that ETSI ITS standards, while publicly and > freely available, are also covered by a number of IPR and licensing > aspects. For example, ETSI ITS CAM message and GeoNetworking are IPRed > by several enterprises and the licensing scheme is mentioned in the > publicly available ETSI IPR Policy. > > Also worth mentioning that ETSI ITS standards under development are not > publicly available (e.g. currently platooning). They can be accessed > only if paying member of ETSI. > > Another problem is when a publicly and freely available ETSI ITS > standard refers to an ISO document that is not freely available. > Without it, the first is hard if not impossible to implement. > > Alex > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > --------------CF1EC0345B9BE4B0480D3D89 Content-Type: application/pdf; name="VW-InitDecla.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="VW-InitDecla.pdf" JVBERi0xLjQKJeLjz9MNCjEgMCBvYmoKPDwvVHlwZSAvUGFnZQovUGFyZW50IDIgMCBSCi9N ZWRpYUJveCBbIDAgMCA1OTUuMDAwIDg0MS4wMDAgXQovUmVzb3VyY2VzIDw8L1hPYmplY3Qg MyAwIFIgL1Byb2NTZXQgWyAvUERGIC9UZXh0IC9JbWFnZUIgL0ltYWdlQyAvSW1hZ2VJIF0+ Pi9Db250ZW50cyBbIDQgMCBSIF0KL1JvdGF0ZSAwCj4+DQplbmRvYmoKNSAwIG9iago8PC9U eXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZQovTmFtZSAvSkkxT2JqMQovV2lkdGggMTI0 MCAvSGVpZ2h0IDE3NTQKL0JpdHNQZXJDb21wb25lbnQgOAovQ29sb3JTcGFjZSAvRGV2aWNl UkdCCi9GaWx0ZXIgWyAvRmxhdGVEZWNvZGUgL0RDVERlY29kZSBdCi9MZW5ndGggNiAwIFI+ Pg0Kc3RyZWFtDQp4nO19CVxN2R/4fUUZgwZlN28sTaXJ8rOEwY2ZUA0ppCmmkUExFS2WqBtm xniGRlLG9pKSpcKIlOXZI0sLilYkpZDW19vu/Z9zt3ff67Vq5vf7/z9/PqfPefece+49537P d/9+D/GUeI58Zj3dajrC4yFIGPiPEDjS1Xupp5e79xd2o0caEbnIN0inXn0G9NH/YkC/AUMH f/HlyDljRn711UjX6dYT5/gu81/nvWyVZ9CfFw4E/R4v8FwVkRMZf+Xmw/SHG/e9rHp+58OF 1Ie34SC8jx7kKtK9k05Oh6favMGIVneedncecRPhIwivI4/8h9D/eFraHTrq6Hb6pPOnoMO5 zxAtnra2Vgftjh07dACtAaAd6dC9Y49Bo6bq9LRbrDt4tf5/Nu063GnItDPXDOwzPgwd7eq9 +ZPOvXr36dvP8EsjY5NhY8aOMx8/YeI331pOnzHTynruvPkOCxy/d1ry09Jly93cV/j4+q1Z u269/5Zffv1t6+/bBCG7Q/eEhe/9a1/kkajoozHHjp/4+2zCufOJF5KSr9+4eet2yp27qZmP Hj/Jyn76LOfFy6JXxa9LSt+UVVZV19TWieslUjgvHqLNY/5pnFd3MC+tDh20O+jCefG01sIO 3Tt0HDRKp8dUO93Fq3sO/s+mTvrTdh0+c+2TIaPtPxi4emd07jV0zAvDSjg1cmYtm9jmNs2M nZhyXjlIF20e+Hja3REUEUuNI4M6/zeLiYkbEikwbqZYI04aB4iK6Nigc0jYf3dG1k6tm0mP sGan33CAVt7UgqJp2Vr2cf6xwjNxb+QFoqI1Q4OWhmXRGult2wFzCoErN+z3fYNn9hg05NTY 8X5DBm3iO52cct0ITD1qsaV+KJIQmjCHR1bsLBH95sr8gNI+w4vzNizfd+Y7LYFxFLhzDlO0 3VfbqHY3NFO2/veLoVnz82u2zIrQtbOyseg4Mmi6nnXA8hnG64dOlesaWE2WdYr6Oe6u0b0B 0nm2Sz7txrMVzzY9EnmuJLwavbRz/rMBQY8eY/fcsYkdd5ukLrwzefSiAPPKk3W7K+p73vs8 ZfBXs/P6CgfaXjZ6GqW7fevt8QZP7TPeGRZ+6DbPG/0pVFhf/3PgmP5WZwiEP2Jf+fGEDVbr A66lio56T8v8ESsqPpF0Lqlg9ao10hCfRefMPs/8wWWV9yn00stZcRl9ZDPK3GfFpU1dtbp2 bI793LqQKtmWPesVJb3Ohw94/WpLbsgK7O+87g/uBfaNTxb8wNz6asoDn4LnRZXHHsTd5Vd+ wEYvOqgct8gyLmXDbsk+r2eeaMkrfNlFa+tAti3w7uoU6VT5A6s652CJxCsrWWpCve0lvDpE NjZFLj/3rYdnJwIJ3i3NXmo1IyE8PG/K/BLxgc3PUtHiYgJx6nogikBS7uGiokW/6m+wWuuy KmlBzcNJ398jEHREcIrc/eitu6+Ly89EH8mxSQaTwb57+VB4IFBRPaPOm0DSlsdnCgKzAggE eRW85GHOs0EXN807c/fu0OzIBWbm5h/0liyaZdB/hXnBdcHZNe/1QxMWDLpgZ6mPcIu9fYZF R327/9ESOgcxcTcGRCBEgDiZkJWQoIFWs6SPjpHbPzpSgFgHr6o9PmxyxIBNWyw69RlQW5Rz qNOQIdFm0y0GB30ZuX92BNi8jZek8o0BkUX8An5qcr8SszN123euzzNdJ/9PjeK7gtLS0kjB 1XSThDJjHigRWiHwkVHRER2iI0OCegmsnRBr8FY8N3BJKyRMgJiAl+W5wz8mj3OcSEQ+wUpU hOsdjo9Pcg6akqtbtGi+b9qLrYf/WBt+zM7S4P7PTW3BZnGKlc3H7nG1cvCNW5PL1SEqGpBk +EdL4ATwrfXs2p4HBkV0dOj2n5jBUbE/GQ4aunbSvNvTBusOSNfZ+2rucRM3sDqRcK2Mqcr+ 2Sequt6Z7qa1YltSn4ErR4ZXXUv74rnscfTvOfVlE/R5EUkpk1c4eUxsnP6WmJ2t2/4Hgaxb MGOh4nyX7A78l/ieS4F9/QOPevn6gmn86MYuHFwg8ge7UoAEaNlngIq9fTp3LcmL3gtcKsVe wU7lK0OTwa7dj4lF15OTy8Kv6X1jcGmzwDh+7o8s6XLT/HrtT7g/opBkFPIrsNIjcnHSzIfD VsSneI1PywwyDsVM3W772BpvPM0rKTi1udOditkRiG90ZFhQD4GTMc8Y3gIrw3q/0Ms8GhXR 5fDF1Enes6znvZ1fseCabvQXJQfStYOuah1UwyhkgXQD7mCfNaLyeLQwPiQp98dvs5E/Nj6L /x1srtEbjkRGCkwPpBuDDUwWuIVIIGF+wP0EW0yMyRYnhO0KSvEINDsXE+EGT7KN/FcbJtX4 l5uecOkwZZnpyz/BtkptZFtZWXz6r22lFpYGexy+yOg+A+wfHYvocLRX5//M1o37esDckbMQ K5v5T9ZIAw0mI2b69nO0MuHNX/R5M5tERwKV5VEvpofOEYjz6vIryf1ee+h8eYFAApOHfLjz 4P3OfQCofSy43CeJb6M4N5PsKIMDONCtHXKlr5uuzC8r2xTLHCG+5Tf/0YjN/NEGlTPBXa/H 9dRPaByzf2KjCWhUgAdMMcPKEsw1NIG+Sv7gXLW3z4S/bP4dWmRo9kVRNHiwxiYNdNQn6+pX 2X1wha9BmlPJgwtp4nJAVWi417bg7lCIMih8wogWUczeM1bjgyd8jXeYcXr1oqXe/kGpM/D6 +L+To+XjN95fcPM6Fzs1Lo9Ajj+K/qgU+x8i4AgcUEiwdlKXYUgpDF7UJI61e2lMFmymXE18 uXITnoVZF8aOx4peYsfw+QxR8LSzNPzRjYYkwwbfsHFgBLA1YOdhYf5aSXl8vIOswgLNjT9B r/itL8CHDH2qvtWsTdwiOkQC3GUN8JZOF3F0DHiAJQCQUAAgn1j2oTEb3S0EfARYETgB3oG5 0doP9KY3D7jVEDGf8rgMfBST/4zeWVP2b1GPVn6GlGB8ytLP7zkbbO3de67f3WtxSxIud9pw aq43mO2d0xTHAPEHhDAu3NEyKI13lIIhyeuFBU1wzvjLjEAK408kOafVnpdj/FqDJwu+u9KJ +QJ7yS8AF69JNu9/uYQInJrE3sYks8m9CVBDk719H06ojXliNSfZo9udAId93Vf8+efX2eO/ OoIGvPLBH80/9fe06Z2XV8bF8V9jqyfWyWd53CtDJ259ADine5bysm0JQaAyNqpX2POSVKfJ BRXve13eFTl02qqBPrUnXq/bc/4vff53jywvDYmykczDlm4ZKrG5++DzEvEWl0GzHiPP7yRJ H6M/bxlf3dGxV3qw5CfRnvFTO0369oBs/gZhQe/Lr+aZ/6m9QyLtfKqu1HyJUbkgr+qRbLtk 3iaLCUjgvFPd0ir4l/MDbo+/FBQsCj4Ws/2YN7IiK2dyx+G6EccvbUAv+Yun9yv4trCAb2dx 6Rcxusfz0aqvN82uxBeIt/9Q/n5kTp0Bf50wekZd6WRbW+uCHFE+f0//BbIjVTHrMFPZrYq1 Lqu31T31EQcXO0zJ1hOnjD0233Y+f8/0IVMzeldFr1uDrat9/8eR9Qg+MfzdnJLPf3ydUHe8 7EjVsftu/pH4vA0HhQX9xJaD/HhGPbqZBD7qNvr18GEug/mSV0LxnaMB+2BlD+oju1axXjdn 0O2Nt1KyDhn9XrMLm7j9bTqWZig//lumNoF8FSZMUrzYUGB5ZNI3sdslj+RPCaQkEvcT1o1H S/bKy0accSYQn9oxGw4Wi3UvP+u/KbTmx8DfouLXvh1Z1wV9Pj+lYPoXvjN/ybQuGu9QE+2G jZZtrnp7pTrmyovnXjPi/75k+1DPS3/TK+9MD8ffS4YUXB73sHTRkIG/Duy/0uTtihhPx6iK xdPFHif719hZLTx6naKaNN+gJKr/q4V82xZRZUPlbCikqWFqZAOk0qEs52VDYmXeJwPHK1Y4 wT0FqS294ShsAjEurFwSz7+80s/xSJe+0gsL331eUFs6L4H38tWtAeN8roesH5mkd8Enzb+s 5tLFhWkJv4R9F79BUGFM3W7MYD0B/QCSyJvQqI2hxw1Fif+yWq5hAbiaZQudrBuiMFY+b9DA ZSThEFoCE4rHp34wXCXJd3C6O0EmxMQtittFoFQFsKMxVzm0hX6Gu5ragKn809KWceyG80sT XWPnveqyM0+API08feV+YXW1+Wv0evBZc7n8gST4Q0TXHFO9t+8IBB2NFYle2NStIRDhX6LK QtBywumm7GsCSbtfWF9RPzfwIYFU15rjX+P6vIuWruv12HteoWAsAtlJIL8iHnaOv+mmyANm Ub/N7+xGK2tHvBK9sOif4KD7rBiMnoQZEkhnl8EuEml4lQt4Tpn1taovQcNxtGIPaPHaZS5X 3CWQjafq5+hOtfxxfU8sLU8oTgXDGe1C5QqR4gMYbmBHgzRJT/B2uYAkf4rrr+fUeemZC9BX tuAFvcAwI+rtuR15Ikufgm/BXOoIRHwdDDpz0AG/5CUEgriQq9EzVXgOPP1KR6M9YF5C2fM5 OsUGW4vhaEZ4vf6h+SlyOYEUbQ4yd4tFh2ESCYGkdDRPBYKMUCj/zVjbX3CjKob8scqueCGW loaPN9b2FlytisdKirGKQgL5IXhYCR64AFcQSG2pdqBKU6ilD3iQKZCKCERaw7tsufj392jJ C1vFWQIpz5Ss5Vd/EIkrCOSURX9fB6Pw1aDzp3TnK4tS5GIXmZhAssG3M+19D7zSoXK68RBo lI9QyMAo6Tr5Br8sSXq3ihpoVtV7UckLtCIbPD3IvDRWb3g5HtiTfLk3Gy+eklTw6btqDbb/ XYJvmAFGTKvPfJsERs8AS3oWH8M7a+n6c/K7MZj4LYHsMF+aLa/bjiuElXA5P2V/RT/zI5DJ kQQiWi53AytyPXdtcO1pagSPi2C0P+nRLlouZn/ryt1XrwW3DQJfRK8+HX6K7aKKG+Cz8iuj bxWKX9DX8znXo8D15/T1WsMfX1bIPmDUQIp6tGI3+QTXl+Wo/wAsGbsd3nvKaXx60Di3WJea U47YkO/Qle9eBSbAt8CiCeSRXpZw/6mZ2GiL/vMcxnmKLuoparDr+/efeg8eFsAHIJNsqmeO 5W3FpeiL6Z4EkqSrqMOuB5kbx07KJxBvvgysya9fm7tUP6SqcIvsjwf09wAq/gB+948XMVXE I8MxV/lz5LlseeVWHOfjX8LhBopdqm+PkNVj18MDsuUftoMGEmA/vZ8MFqs7WKw0/JzRX2CR p7whEAyVPgbg44OD9ZcZKcDnLLd7nY+l/Y0VFuLnEF99B6O/APRMKae6XlmaIpcFywAwZ0Hg 0QNSonyDnqwevR7+AIK2l/x3Y21Pwc3/PESLnwrr+0RVx6TI/YWyt3B3bCkBu2NKHFiPOPTh fjxgPy5zQnKjY4eMuYEvciSQq+Fy90O+hdVlYMflAAhBvDIcN7tvyLmDPrfBx/R9xa8qN3ot KoIgzRcayaX3JKfqM9dXYWmxon2wu2eGo9ANk9TtJ5CBBNJvSjrYve8gJhrDS7RcrDgsKsnx kq+VuwemF4Lrr6iRjHL64wFH5VvrHwVmgsvoK/Q2uWUTEuWyWRK9yuNT0rGSXwrFd8CIADee uZI+Q356Py45GhCD7wXoa+McnXcGwXWbCGQSAIMrXY1yZsir9uP1ENoXK45jJaGF4rcZdaDt 0Fys8KxF/1DwyHB8PcCEgQ9G5CygarlyY+0Vgpsy+27HzRVSrw9H3tkRyBoXWV3hC/iSvXOK 8Lci8RvR9fB3q/2t6Bu8BTdkC38IwQrPA3Roe/4bvFAh8yK/dXfPF+sNtMe9fr50ZtobZ992 YXAcDEvkG4TicAKZZpDomCisfI8VuLw21l5Gsh3uGqSEsJCmdTxUCaNUNWGqRFLV9PdPqih5 kOeBVFZVodFE0e6F1YIlr31EIEvHnnMEKDc+EQACgZR+ef5Yu7xWrE1avRitGIH/Yup5ugIt yiOQSyLpZxGf/me9TORXDOjwygknhG+wmhu1cWXG2rrmgX8GLgs3x/JJ9OIcmtDl+oNCMUSG wfV2+0XvvyFxUFyqE8JcT6u3X1Yhg6hzudzUXzBtwrtsrDqVD9HGDjFWfZusJXcedsXCR/Ye YKE/KFwzXCaSFPVWyNEXizrqbwy6WgiQ7iRXgKu3yo05ddNAwRSLH70gdh6FFd7A9TfBMX5x EdeAMXz154zWBaipkkRNR9haXJn1tJHmABmmdRJVAITdeY3slOQFXwHIaLlDrT5v0+tFWFon AqkoIRCn/fBHMgZxme+YUF7a+nCX6rdCMaBqcTP2Q9wGaDOGSZ9k2FkMqOBceHzIo5BBdAtm WA46ICYb71GN6xPBKCJxNRgFzO9qiTxXKKlzIdHdUQloKxORT1g0UB88MRGtLkMrnkNWhBzj JBhjRj0YVGtC4cQSPGCGQq5PIOOK8ABR1RdxUmNtYbUnWgLo5+DOa/dDnFoo+YyaVx6Wloh/ q3/IL0UuJZBXU8GzeWmSbH41wLq7On4OLwtl9aYRkXvv603EJLWo+Gl0NWQeHMCXvOVlN3N6 nzDv6R6/E8gmQV6zG64lRV18b02x1qwbuClU+Ilk4NtNHZvouBtwFOyeKW0fnc71ywQSDLiY 9f7YJdM1p09hRYWH3h8hkM8BI0paVfRpQwpZsbNR1WRTF/QTQhGqYp9OXiGtL3at1rSrq+2b tW43oedvY9EBwFdZ6YED4E2f5Zk1AP7ywivhL490rYz2oAgGFdJNuBQrnZa4ske1whpwlIBh Tof8Cauz5Ii2TdptKam4OTV7OxRGTdl0gar8JgdS1cn22Y2l3BLJUijgzgSs/n2+Az7/bPvo 8RcX+HRm1tbTYWChFDAT8dsI5HBnwD1B2y61VZwQE2YrAImXJG3Qfkn+oLrtroxuKOMqZd0E dTUEmKSZIf3xMu2agdBmQLwN3iaNe7242hAIfyR2VbTHI+srUWW1rvxTicOTtlu1uJZVx3Cs 7BGebETS3lPokxiFn62i05yOidXiwLcpiYoIn/mizIvr0TgP8N1Fb1xqUmqjCAQA/1FwKcOi j5C8FINF+38j2fcsMmhUtY/iqWg0rr+sRHYmEFBbVwFyA1DhxSR1tn9dTlLhGXJTz7CgkdV+ ijtYxRFc/20+RssEP2em6wz3xJL0oLzwB3sZPv1ZMv4KFT8DFMh9ZXwGFDSEH+KSjbU/9SuU V28lqStbi8vhXo/xhMLAKvBgcNfNrHx93vbkcnw94BMwILD3tEkuwddb0j+cx8zR+VImpOm+ 1ZUSfF0KbKp3KNbnbVP+tOO05Lewxd4riRZKHuEGSZaIz2ubWLB7Li3HgQBQe6x6uKikAJUB wTIrfrMAKZHfOyURB+M4aDtesDRNLothuYNfXy8EnAPFEXzOaXrXsOmDLUnRyRW5D54v9AVM i1CxYtI9oUSsbOtw10ej4APbACnHSp5hJCtyENLvC9QQBZFBIy/lBkvEfPEHe0kiv/o94BDi UsGDSPEIUH2s4wiS+BfheOc80FtO9567EVTqCOTO5sRjEV1CQ5b9+HnXI9nrxsa1Cm9pRLf2 3XdtoTbvx5qMl7D77me472o/dt9xisGv6/F4VFomlH4Wl3P9omwXwHjzSGriyVLmudNnzN0X YAj2a4bSQtU1WoPnXesFho/x0WxMZmCMom2RAbR7uNTLtpQWpp4v70bVMhPbR+aJ7Z9Wu5pZ XS8Hg8K8YDw5plqfl2QDMb4hzQ9lKK3XLbFXN0Ux/w2DN9SVt5IX4G0dIQ+cWuP1xnnPNiN5 4Dd4OWad2yamt4E7g2m3ivczCGTRXElW8eJ8xVOAiU4QyEQkj+Vq/w2NuWaf1H+vjHwFOPKn WD5c4d8A/ynTk+1QmHq3z/g3LsrOYNnzcb8kx3CXNV9hafNxX945pd2atJ00AnhtAJY2lhkX PHMPzXxorGXd0D/hI2Qd9YUW4mgkgawW7Y3LuelVrwjGkxKrDRLbZ2e5Lgp4KioHw0/MjXU+ dZGv8HUpseg/JsFeFU9QP5pZkKZ9N5sx8VE3k4jGsHGDIJdQqkoTH4mG+tgC4pcBEOc43DVx pYGoSIpKXxc+WLmifeD5ZjKEZ0vcL9ExcdFgwOFvl5dqr2D8NxsVq41JX8XGUBPj6tkio36Y Jg1AY4/lOpA4NdHR5PKbx62TW02xlDIMLPJK5/m/F1bKhbV3Rfuy8tuHydjmlzlCWiZ6eL68 R3mUS+0T7CAUVilMQaKMpoGFJXKGlGU6Q0NvGubMDwitEb+WkEwWXf07GIkifdTKPgAII/m6 Vz2B2EpfFd53eNc+q7wdrnLpuXMMIFv0n6dB0UE5tTauDQlFGu/wb5fWqWd0BgG6Vwxmvlwi yI0dAtDGGwJZuF8iyG8f95szw5OBcLbIAUIx/j1AGhFdT3BRCS3+A6b2T9kc7ePuBzLTAZrO CVPtQXIHJp0eQLndinZtYnQFDRkc9qIJx+O1ZRiiCWUi6zJL+i/AkUhfdRWcpoLDGnnYDbRS Lqq9QyCjnPf8jhVJsPK/cNcmFYut4Je/PiVZApc70bRbOe4ICICdRa+BXy4z/LLz5HHLTpLG VpS0yiaaGGur2lMzBqZMuEAZW6EU2CXFZ+dwfSwXxS/PKM7H0lIDR2G15dikost9+6b4A/n2 okgiCcYVGLSpiiT1ZLU8AhD4cYuACLtOVAHoTz9uvVCtbVY4Vl0wQlaD3U7uDMTUZ9Ao+hLI poAZFUQpf8lXHo4MmqBgO++ANT6o1Z8oNY7oYha+Hky4t0KGFs3sUSEsnIa9+4tAXp70FyDX P1kbXJuBUdbYd1+hpC3XM8OiD8+zEj8/AEx0ND7moieBlERRbV6AcjqTv/nia/ANE7HqTD3Z c7rpa7oJdu3P6QYl6TXQGDATrdiCj4lYJF4HK2MvWiKuruWTLqFkr2nDZZNQ8V1Qg7J05VpF KVaxGx+blKOi/IIQGMJcMY6k4iCMaSd/hII26IABm2BQlp+hPsVk6Ccw3AaUimwYTgdWgDzK MCKF18Oo8ckBqA0SwgkgoLwnjfWRhIRQrlylkZJwcPRvWJECK98FuA3TzwgkpQqurfyWR3pr qKlGj3FSF+e4dvJigKKOSIGEkvfHXqz8GJ7AS2Tw8hifBxMp+OeZmDxWDU3QWqsUd458fTZX n2eof+PQU7l7fhJga6GHKIlmoml3UcDs6tpzsKmRv5MGqcnJ2sSNZ3z0QGWQyWPEXo1xJ2mq /YbGmEfwUrxetehNdGIYw0h7eq+LUe8JdfuWlEeVUnk7d6busTcW3SIZD9eoGMjXfqnjU3Cw IQcoqpKj5cLauBM3CSS8QrZcsdKznZi/pHI9hS//TtaTxYsCSlHwLaYHmbtRgQ3WSiOpSiEb aAuqRlMr48u1Wz+hOdhIAGwzAOyZ60kbSaYv6fNLP3S/wA/Ao40VtYIJoXZcbsVMaSoxVC70 HC2qhbSdWDWUvez5K5ycEGslmFDOx1SFikhyi9B5dCwyaBRWLMafEYhTTqyLJACtvY9NzGkv IhpYw699jA1x9tvqI46AW0HSD8mlQJZVqlOKdfhO5A+ISpQklgX1qL4VFp+SWEGFa4A8JWeZ Z46Pgd6M9pmclTdT0WZl0t8CXrHKPEhvN1WbVRMVM/2GTaHUp+M28ayaHofUsBPIvUqwJljW +ZP6WArgX+KXSLKaUPWpBSc1WRwXoP560jJ0V1zO9WRZOpZtJ99Bq/nI+XbftWU2Ga/FUaOF CTgBPpwK1U9jUyQVGUBdgVEEoNLfRn3KzWBMyPlpMG1Q5gzY0HDiLYzWVSuL9QAbjtbewUY7 n/sdLZKIyv/El7UXC2MqvOwFKPqMqrEX2cWP6JrDOnYqPQ5JR/ewIGUIBXuF0VhFRWq+gUZl JrQrI+nRQXlFutOLr7xLDf99pH9HA3Va8/o17S5YSjWWPUj+wNPhC8CtvwYA/o1kX9vUfw3K 6fhAhUjhB/D5u8ULFTJsPVY316I/1EyQlCxUdcerqKzIPlYk5qARgQ2t1PiE0rbYaLiV8hQm x4B3QeppSGOWrhU2XKW/fQMzHgdaqUhDDbIO124ABm5bqPbiYADgmPSV6H5WsatePU5V20mw T8vHYs+DbyiSmcRvPu2JZTlj2S6K0HSd2ub1fobIlyaP7TQERRnSGi0YtsVTN0zbM+tOKZ1U VAP0NyQ1WmxcjPoALbPotFFXtRIInWlA6AyX7MuLHQsAHIgg8TbynHazIQhrwwprswlk6YoC gF1qwwiE/AWdJrlAE8olLtCI3JFkF5TcAYckjQsjSS0TVMSEGVHEl+YMVCsmbCiSkntoeDsb t8TczvIdTDND1ns1DGwJCepWY1fQEGU1qY7NxtFXYL1XQuzSD7DuNcLaB9h+h+L2gfVfffC/ C/FkAnkb53xuK/vjaJC5qmIwmiu2cwRua6cWWzM0hPE0KdNzdYgmWzddfTBFKd83G/NJdaQ4 LUrH0MJy06Ue340nnaoem+i4DQD+30BSGttm4nl0n5/a5ly8kEBiEynsEpdzLYlAvofUlETq j9v4FTX5Q4ANomQmlOoxKgdII6hZHYmT6JmDo+20Q9Y9X23RoznNfGuxUR8rsNCZ1EInruyK FtW5iHsDZKMGE9YWPkC4ahvLAjEM6WMJeBZ+eZyoPAZPhR7hMADF3eRSSU4Qn5w5yYEZAvEa ELeOZmxlXBhHBudK/Kx4Tov+sOkoqSIjJfPlk5l7vPydmGAMLstjTVeUeR6sGXbHhAk5oSI3 rNViOagmdYZKhW9pOUdkjdy0rVfsV9zCzyU6joJYpvC9UW2ctB3c/wSIaecihV+iwheVfgKY 9AsA2j1A0cM3u2l7Bl8/yBE2pt079Cpg2FRSWjGcCLDL7JoySmlAoXnymipWZipH9wWwNnyK j9eaJOsXAGhqTseJTFgpy+f88pPrQSuLzwyMjnSvnw/RFCmqz0oDUlU6S0i03ZFbAOd4mrir xKZuPgjJC/jpYQaHCgVvuLei4KBGoqOTueal0BIZuXzAo+NuTZlImi8lf+7aYN634wLh7HPp WUOxSom57OTH6wxo42Fs/+DausLadOhDmXhSh/1eEV3LKD68AQPMG2WjzsBoYkxalmClDfF4 6jimUWc/df1PcwZb3ja+PHAWXkYgTrmx4wmkqAoTL5BmtRO93bIav5KrqCaQiH0F8YHPCSTK KbguDW6FiLbKKm1JxqHBPEwlymg8xl3tMQ078hISwOZRZhdpirWnBV0dAMdiNAOL88ga4ELW 9ni2TR2pKmSDykJFinyjM3YFq+m5qKOPmF9ZvZJyX0V8Nb9VA+EcXKDYTvJdWdpgBomomliu KZtKs+AQ2qwmrXHNqyFJmlphStJh19dBH9RWEwgPn3+xxRRa4+5i9/aPQDrgjyusMMc3r/Q/ HQMkhO1e4mAI1CSBpVSyrRd9SaJnzJK5lonstIqAbWVDTRPKVA3NxuqWKVJrH61uS2JYyCYt 32qWpBvb8SlgFYIIZFhe7ExRURlWr1cVl9xKwqnOFtPGMlMdrF4CxNN1FK7uvHj/fsy1MDVo qFvfvcKE75LedrqqGMY/ay5X2EpO1UN3xt88CgH4k2GUouUboUMxjK6E3pM7OHGUY3JFK//a qqjGDRKBfK04WAm+6dzluDaun3b2LoGg9rgNbiCyRH4MOGRLhVEeeVuFpT0WhYCbvTIs+qDL w/HAaHm43LjKEIZWkjGX0PQi34aWlLncxa7vvkP3MF0jQK5zek3ahoEesmLseqJbRBf+YBeJ LByXuHyIpvuQQZr5YKiNoON7smM4ORaBXFlAjnaN25MM9NwNByD9MmHPKLIn/WZU0Gd+VEQX W7ZndNVSZVMufOu/RCVltvBRW7rkx1P3m3oDAYHbkQwctSIDRx3e6SNbomlOnIozJ/UmqnYa FQcX2vTD/jAzpLUyysBuqEon1bycW6k2dWMSo2CwYwxKmTSioZ3nGec7mtY2IIt0A+/X3vKA POwqwBRZQ10qq1G5rsQhn4MjPwI5O87l1+xffeid/OSa00YAS5z0RLeJano2Jfioqb2ZYmNp yC6dCubNZFFyJvODeenG6BHXw0uZq0RNt6aiF2ukQuvibay441D2EDuqYt/wLtDUZxXYk09S nkDkPACtrF1d61LsHNou7hkOHUoUw3LLClMTy7Wweul5aWIVYOko5QWjxSAxJW1BYS8wqg1W 88HqOBheQak8YQZQqlRUblKmeVHepCqSq/sDUEoFE7q7k4qXAAfVMiEKrQkv6mKMFZUVlYlS E1d249dLLkhPVcWlto+UIxTiU95diZOfjIjtC3B+IVj1IPNjjJEHLlk0jdc7s/laTDgrwXgr kB+BlCZDaMbKndR40CZomhTREidlQDKBY++dqT00yJhXE5r3R9GknY/L6EBKTkRlR5YiUl7G DBcYxc1MQ3YRUOmOKH6Qo5HvwSri4TwGWtJyG80ANWGsAB10hg5RDC5SvJD/Crg9tLJyNf4B n9ZeOkQTuOJ4R4hZXvPfOBDIhxHFFv19qUe7gjcFu59Emo/c3d3YVBdO1qRDSAWDChOYXUda 0n/yB3L8d0U73Wta5Ab14Ic7dkvm7zky/KlkgQ9/8Q8bhu62XTLsUnDV7Ihedhf7Dlz5ZNkm o9yLq4Z5x8Z0cHA7vcl13ebz2V8H3/cRLkzXNfu8fviIg/Gdcnq/Xtrn4fhJ8/dPeG1eMPdS 7G+TCy9bxEx4927RkO+nFYs9p7j++vOZkoF6WUKDKDub1/HVg/p8dd9qcJC5e1ez1shcLWT8 LEqiSaI0I0ttnwEYsI0zY/Gx6lr8qivfuBC7hNZ0dz63XVcqCxZvxTebtpN347W9WHQugVwV 7fFyGEBHDszRySffeIvgO599ar5ykLBpyqhiqP+5G7Wbdn+IDAvqyabQoEB+dg2XqydNIA3M cwmcnCqaRRy2fKc7eccUAeI+/u0sqDewm8mYwKLVxKqoI5fNSOPKJ48O+MycOfBNTR4AxEx7 MYXpWNUnwKNf+0ChBQy2z/gNpHIJSI6TsUqaqbCgkRETLiQBDgUrHQxwXjejC3S9jZtNJbYB vC2F6+DO8z9dDGj6MfS5S2rQuFJN+lg965ZKq6qJ4VQo0+44M5Iv6II6/VBTZq3yBFYbTfLv pB4Iyh+084JO9exGmWsNChkmqxZJwXpRFaaV8aFwMuYlRWRmUH4Kc6feiaFcFkgZzfUanlyk AGx0hCAndjyanQdYSLgh2k7ZVXQeZNzaHCpuDe4CLwLRwueRXjeaZVBG9dtPuUhgGtSsYYVR a9FEnSLfoNP+gqCBVqznBakfY34wHgHKCtxWjJKOtISwvIYx90Oqqu9YpoN1l6B5BxIMNtlQ 7By1B1U5Q87+g9ahTJqp7dMLRqj64PVA4Lf0yjIQSWVCcQrAQGvaw0RszDPt4VIv3QKB3vs0 kEGCL5BAT5lMVB0M4G6kZVKug0EUWB3GlUBla1k7NZ5clXx1NgSI2YgN7lCNIKLVxipYRoX6 N7B2W9POQE6M2b6p92HKqC8IZNFqasE9sgaKpOXB0tKPg3YVPhZAuJhHIBskDsWL7wHAXwUB H/FUN74yshXrXwfwZgZHwcj4VmvUAVKCVyMNLD2MbsAtMancqXyzLA+lhiiZi+rAx2OwSceG tzVhFnyXUhGvpxjDl3aKS72RCPObgg+A1tm1eMHN9ZGyph5yPRywswQCADtxZWc6fgz6kTW0 ryl5VOW0aEGB9R4WcNhVY9pZktvQKySMa0dhPCBV3siJsbuEMKM5kTmoGwwlYJwl1Ssk/0y7 ZjJ6nUgVy47GCtc8CJd6FfomBk819TwdRyBZeVi2rSK0vdzdt4yQB+Qq+ks6F8SaYEVVekcw aySPWTnmrZWLrlxjjkaXmWRnJw3RZC0pJkoJrVHbbAjti8r4X0aqUU9rrmOmCSvStCQGhCm3 wFp/z4D1/G1e+N9FeDL2NrLVtthGgqEghD+XmtfE5dwIx1GAwPxE0YhHZiajxYbfJM9nttpd 9LYncS7pUdnwwAoNXknMrcrEMBSLw8mER3OCGhTrFAKOUsMQjar+rZ3UkQrDZlL5bxvHMKPM AEAvpAA6f7EzFnuBNFQbx+U0DgqadJSNysjdbOvlWxRZ+J4kx/8QSMor/vvEGpiNjZ6KMg0v I33Snl8MT85SLhXvL2vGQEom77V2YtI4s6jamkm5qvx47DJrcktTUyMrk/+SN6oew6GSNJh5 P4p+av6cmop2t9yKPNLLCNA35wBZsLScQP5urxiP01GAR7mDwtjJc1uM5IE38CICsUbyGS1P L4bL7UEaMLl5mDurerwweF0Fqo3HU3Pk5I9oyDKpQion0YQ6H+gE7aqGFINHBRFz/VofZYZx mUl2MBVPcYaXJMkDiXoiKX5TfWW6OHtdRhW+6B2HJ67OARICKY+paW2ooyaOgWTUf7wL+JTT BAL2UGbiSQD5iq2KFHylRX9f1msXTsjGcuAxhKMtY+zKSgaXqwPl6ikLFCbuLHfNatrcL1Bf IypaxRsaPmDqA1X7ud6QzIMc0w4rI3P8z1TTmHOCC1Sd28w4rvDfPksZuAKgIN3mfIPIL/A1 /AJ+4AsUu+YGvAFf4DA+rb0yX/VFi6R8MV/qULsYlWPfQKgfG9E1RwV4aAUXg8AbO5Sn6Xha zQIFi6iV2Et1mKbkEJUNo4Fn5JCYFoR/a/fKrbCFThdVBuccs1LMzBO2Sjo/+wiswiHjpp8Q CLnOkjgPwQ2sHodg7hpk7s6dgKD5d2yqNE7o2IZt2zrP7CCcag+o95poVSYGciNcvkOzvllJ w6goH65egMGSWkqOpiE2UYHrlYFnsexv5L/+nGWY+L2o/LCa+a/B/S11BzHtCFd7BBkt7H86 F0ePABLtIc8KGveGpGn7bSi/JdI/knFgIpVEMNriU0uVK0yFcqakCntBeZOVJe0Hpc+5qvYU ph97JzMm+DHo4fhyKqaBNVexFirVK6qGMkN9jm2Maz5j0jhzKnQcN4mgeNtWEogZVn7EId/V iUDueUnLnrRPAPsnjjvYwO2Vznt+L6xU8BU+Xq9htFODZaN9BWirvSX3h6bjs5SntViaUQZ+ VrfCOFXQ4Rv26TylQiaBvYH9Q/tBdFSN4aD9ZFlTGRvUkUD6M3D0lUoNDxMyojw4huO10EDF 5Orstx9P5r9x9tvhkekiLX3SXkmrEuXYDDLqNc7ToT+WUoPBOO50nXwz/VA1yKMqcIGYRWRh VTP8K2HaXn0cpQ8g906lV2CD3UA3U9pbcgg7S87AdtwLjDlSNW+cpZlm5XEDoKE/g87YRCsI 5w+WOPuG48ljf254W5sMtR4AyisBlH8JofyXQugLoPCGYH6xNSEpJKRqiArgBMuonEykOTce 44djp7xNi+RAMlTWgz3gTjmOcjuoQ6sh/HYNMxg1Ea6wJNd3N55sXh0nSDn/xkjh61Xi/PFq LVK11RNLkWLkSp8TYEW1aPl+bJRF/3lNuAcpd6JyCs2b5lvmldRsaZkPAIlCWuYsQG+EJU6K Z2j5EWzis1hnl4vUCs/7iJU1VDKzWf3pJWaiX2FKCNegcaXqqh5A+HePgahQS6+5hAuNFXtf iBCCXi3PCqM5BhN1XYpGIVlTI3UQVAgdUdyo2zvNzqiFurdA0XLrnOxvLHs67gd4QtEaW2lp 4cPzH8WmseyaqT61zGDJz5d3FxVJ0PLdJFQ79L2wmkCGP+LLSuRuvfUIZMojrAhmTw514Ofw 0Uoqx3JFgjnMmDyiPl3nicH2ut8IROguMiTzMLPplueBGzSkWz4WOwKmW7aV6FUeeWcGx8e/ kbtprxHc7K2LB7wGvR/fG7VM+27o8iRt/sOgse7u3Lz4NMvegN/m6As0SARq4r+yqGjdTUgT AKvrAQMeDfb3U6qX2UjYUNLdRwWIOQJYph3XlNlsckl93vaV4p8Aj7hDXr7ijEfgW2Fthuig x8fTCJJOLMfRcDyJ/9rU+3SaHBuh8EbvzwFk2ZAmdHPdKXWLG0f1q5JQkt19dLYIjp4zmml2 5+qLqaseNJlknadmRXO85wWMtwPpV8+qfji5KlWOUmAuKL3uWc989kAGruc9adBRHseo5PuU C6NjdiqfohYnwB4LwbJn4MvaS6gdDWjxPcAMBVcbJLHrDxOlAxzx2H7uqtGHalQV+xz9OEAi GuQwatmjI3RqYigGBkJd3oFdOye757tRt8AuPfvE2HPEBJa94XI/7FUOM8YVFfS3xIxJUBpU SECZNXl8uQ0QD8A3pE+0oHWh7C6Mok1pHdkT/dS3IWtxU9FmxgW+IqEdyGCHU1GFL6bo1F4x ggI2McjJLnQ+hSHyW9AgRW3ZrkMm9fNj4605ftE07ab5OzqujRtywyGLY7p0g8GEXVMmRDMB yN/NPUbHJI/adAsy73tvQW1Rns+hmjJaNHVDfCtmA3rCS6GUN6EJSN7LsMbU80eiGXc0q53u j+fw2Fw5JP8BP6smxs6MZepaRuXBhsjDpKUEcj/riatTQArAR8EEcrhfIzGyzQvDasroM7by wGDpa2wv2HBopRSFXyZonBK3K6OQjblnvnFjZCjHJk36HuY+9jBVkrSqJbXi6hBabXRpiaas paWLjS30BVjEJ5BpYxMdw4RlhXgyiv/yEaEiKuQw9huAgG7gScISZz+wC+qx7NHyUpi5X2ME vfI8zSjaEm7i7qaM6GnMa0a5XRixVXtDZmaGmn8mRSwzWs+lKUNtNbJwzeeeU6Gv7ngcgZQf IZDS6edP9stWOANkAMTV9B0fIY1xZROD7QQy4gi54vPZqkX/MSQFfFhTxqFe1txwsih6pwAS ZYhMFFhzvNgb22CUb2aUJgOtMgUNvUH8PvYYLYD3Eji65BZl7KO+UZ/zwrJcCqoBT4M+EVG4 vZ2yxwKoroFQDfglJmMI8ixS0IgC0b3Fh+9p4Put2dwfTkxirBAm2oCxiNPfowF6+Zi8+i1E Jc62tbMYVHLOESz6foUYAnZ7sY8ugG4SyM+iOM8sc/kVAslFyy3662v2sWY3vMY9O3dGoBvv cWNfVSVyXCUnPydLPzfPSUOiR9E5DV5VrchV0rCoPsnVCTvuBamktHtc8q0EAplXWCGCMN5C g0MTAllXMk0TgVRJwHoTSNzPDiPYBZ/XgPdo5P3mhVkKxu2qPjd9ts6KOxP6xqjlKWg2FWrz ccGtQ72aH9JKgtAnDCuzlVWQ3EisDVprRIP4x3xWDogXVsnoFc9ClSCuCpyM9tVSuLfbbY0J 82gEQKFt2vWizQxGSJgm+4W64qElOCKktcH1AKbtsUKSD3f9nkCOoyR8t1PiK8BVht8nkEdo ubPBDkAnRXVp0nSdB6pAReVIo4I0bGZNnrgsTB3JsgydNX0KAozjPRSaYM/bdAuZGBJ2+Efv UTsvl2qtILnFRjQGDa2Abdi1jZbWJmMeZYY+FooLaY5QCe/tQynOiIprAMszSl6+jK5CGB/T AMZDEwpqyLx1YPVn+s/RXuVz4FEpJXqSMDm7BmY+eWRr7cc48plRVmlmGDPDQTG0SGVGiykc SaQRHTTbQalTpy+0KACTEzXU6mw1rjkYDeErzsSxX+Bs434DrdJuLsHuvaGyaq3sj7vYKnzw BN5ZVW07azFKoC1CzLE1lA5cTRmvZWe102c2zV5E0d4DbLYNE5WASTaRJlcWauoo3wYYSMUs q/EpagrN5tkr7V6PYDBeAIHUDHH22+GOw6i9QkBM97UKWTZqeuVTy3zujOMNHAU1/sOgcaro rymeTE0hS2JgxrZMBfYczaSEn0wODKl4tFKbQIUyWxWOIWts7OAnyhHokGayKZMzHm1H5Zg1 yWg3VrHYMr6eRy8wya7sSzlHIHMJRNsL4PZbje6ILyb01U9ohdjgAGimUFqiWOl6hkCKP9Co pTGtA2V0YE2AcO6G+ppsfZRSiozpZnRWYOWoPMGM2ZpjseMtejUz23fnsSuxq7/b6Vg8K+PC 6rIJ8T9IHi90Nj3+U4eLyOg/VnWbcvSUk4n7sv3uln/uiPijB1JuMZA98QaOIfzqww38/LzZ 9V/Gn9SZkzpV988Z/s9zfnKW5L9cm3P4sxO9SvoOqTXI/P7b9JxItOsfu968s+jvqx7iSMY9 khmkuCcq0EGGjzLDL5NpRqnWOe4We5Zof7V+yo2sU9lf/zx6tXdJhden9cgo+QPEd+x0k28P fxhpJ9hVc/JJ2vcb7311MOrPvxXj+ZlBE4eZmHBCpCi9qZo3oYai3Q9svhRxLoniHMOWi3XR wnZUuO0e+lXmtl4O03S6IRPk5U4hQaM2/nWWQPgjyODbeVfmiaoBeJBHtq60s+j7OfxdSP78 OnU3Hsgno4GdjLWN2F9HUsPxwP7k9RXwOvPr6N7od6sKxXfiwJz63DIff8HLK9R+/dwl+BRn 9H3nHEBNu8xdk4SKrx6VAIBPIw9uhUlrA+cRSHU1gezsbAvPaAUdYPSxbqoQD7RVfDApYJvJ o1qOE0hJCYEM0L8Cr1fC67nk0GDI2+hzrfBUIb+SvAyfuPE4uJPPr39+RO0yGKUIjlIx3EtS D4+F/RlwtAXskJOS6A4GZy2RJet9wOAp+HgT5eVzgEqtn0tdNq6KSZFvxIo2n39jrN0fvjda ec2KPIYWrX8ODwPSgxexyms25EU+dbEn3XMGPLwW3l0a0QWuAPk6n8NX+YBWbHL2naNjRPcI hq18sD7k3fAwm00EEnjrc5WVmATn9hwr1Aoezul9DzxLF6zmxiS69fyxiC7osCLqasFC5mnz wNPCwdP0ZM/tJXDaV+FnggcdBcLTdPVkdcZV8Sgc4Yxz6BzdUXXulyrM3/HH5YtW+Z5kusBw 7xtV76lus6tKUqSVMHiqtnyFALldVcLJzZw2vAitZDI3G7NvJNNfv4DM6Pw0LtW4+31LjzHO lau61eV5HySQiUnFeRh8LRGm8M+N3LSXc14ueepuPnU8L5ygC1iC9yJxCjzId3gRvuEU2Svr gRn9Tf1gaJG0ppDTBqP74QP8qAdMuhgMR4Cn78IzmEaEr87R0DKPbCGQydnUYbwdOK8Bvio6 vAQtf0Q1rVlYpPDHCkX4ZXhQ1cXhWEkCRg4y/V6w5B11gG/WE/ASfxdRB/jCZfr5An2CL7jt Z3Bb7nBU020PVG+r/Wxn+aVKoWw5zHxdZqzdwTCdQMLAhZ+w20dzwfwnw5MiQasAbtneHmny Wnj6Lz5MeL4I97eEhwcTiIFTzRyd6blCyRuYilo+f57j8u8H3jyztFKYf6jww7BSsMq6O1+k Hw/7Qk+3O7g36pNVEbyhX3RD4A84+UWJLtVZfFkdVn9iViKQpL/vhuWhRRCsvxwuggmqYQ7p hQAAA/lkQmo4v6dJuJxqGOWnqMdgzmm44V6WyD6QBw273cqmjxOGS7V9+yn2mOE08rptPVyL 3duDK8AsNgorj74syRpxBw4OALk+qXZ71RgsSnpL0u8p2DAEkhngKt/RB14eewZsdwIh29BM 7E14ubP+HJ3xMlvMtDYiIEa0R5p1CwyM73rT+7W76M2UXYHLzgOwDa4RzhSNttoP/+IGcAz6 oDETH+rgMXhtmfPtDMtzd8xCZk/0toqbCFkbtzR/v3ZB860pbTgFrhE9a1szsajrSTS+UWtc ND5+Ki1ev3Z6GfahGQd8sg5+xIdkvd/+ySX6B4pGr5qWTqRtLjlzZwzZJVDbbxQIq7rx/V9R VKBWUxoBzlo22vDf/drtvNHyupRoT0mgbPgtOEFas0sKx0W6TefR9VA/NrtBUfMk4Jm4Ny0f NChkbkxVtfBHGJSaT3qgQbfcnpkSNBoYVcpHH13XDtrxj7LTKYv5I/UkC60rGvKJqbs6NVY+ 0ujYrFqtnUGh8byEHwN7jSsPm5oBe9xZC17v3y0cZ83MVq+Luhmq3YoKqBmqxUKRHehTtxo0 /D9QWqWfJlGbBvBqwUdjdkPmfwe5/bN4Q22W/xqg/HuHUmqYlPLhLQGGVhA1TSizVccysknY Wrn323uhuINrfOWrVsiuLW/e2LbA7NGKgPrWuaE1E8vdXARcW4qK41xLH9CieLw2v4VKadvx ly0tLXToadvg7QERzb0YjDFulScjx/r3PzXt/2vKUd7dMdIWrGEze7l9weQfftj/L20vJsjV W+3IGvwvMb6f1DSKtv+HS/t5fv9Du649XdM1Iv+GD9DA0fzjzEabl6dBMtt/q7SUF2nTajTn J/7/yz9fiGf/B+3JasIKZW5kc3RyZWFtCmVuZG9iago2IDAgb2JqCjE1MTIzCmVuZG9iago3 IDAgb2JqCjw8L1R5cGUgL1hPYmplY3QKL1N1YnR5cGUgL0ltYWdlCi9OYW1lIC9USTFPYmox Ci9GaWx0ZXIgL0NDSVRURmF4RGVjb2RlCi9EZWNvZGVQYXJtcyA8PC9LIC0xIC9Db2x1bW5z IDE2OTYgL1Jvd3MgMjc2Pj4NCi9XaWR0aCAxNjk2Ci9IZWlnaHQgMjc2Ci9CaXRzUGVyQ29t cG9uZW50IDEKL0xlbmd0aCA4IDAgUgovSW1hZ2VNYXNrIHRydWUKPj4NCnN0cmVhbQ0K/LOI BC4ZzwpE2dhVLPqGfCBniJAEFQM7wU0B8YT7wsGdpyO1sfvv77JSMuM6CGgpDMoLIEPREH/1 6+gwmmEHkhBH4TfI+fBX/poNU/73vnyJxkIfJd0309U/7/lxmB4QYQMEGEQ9OXDmwhOKaCk5 ZAjPFjyMeoVfwxr/wmmg1+0wgwgwhmBmyMBwQdnzI4zQTSeRu1kb8gxRMh6cJfpqv+mna69q hYIhnf9a1/h8f8jHcjHafrSen/p9+Go30h9sPr9JinRFdmCj5G9EbtEUeiKP+Lkh3fjJD//h vr/bGn6kW03XTdfyFHJRXkQf6/LfIOyH8N8L+pIchal9V6k4+n+R364XIo5x+vj3khEH5GP/ jg9+uv4//bVvbofS/v4N+G/9h/wvfj/qP//S+r9GZP7f+H/ktf//8f16X/9f7/kdb//+Q7/+ k//S+5HH9/Tf+bjjODtf9c2cjR/5HtH7fS/ryGf2wwl769oX//e6ZHI2T/+bk//Sdf/x93Hs WEmK/tK+1tdfQMuX+vX7f6a9t+Qw4/9jio447Y1RHN2l+iC47rtftf+001+07Tvte8derHx9 wwunfaaa+mmmn69ev/2oiIiIM5MIGCBghFoNNNO+wn+v9raiIiIiIiIMIO0D1vW1tRxGR7OC EMKEsRr2Fx/H///K6BTwZyGGwpBnhToM1ZcyXE2gaBpphTgGCQDBDAuTghoDnUU6BmGxTqCH UQkClWCFAZfhw/8IOHeneCB9hBpkMQhhmmAyzYOaAhwMs4ISBTAZhGn7vv07/8J3hPX/7uyT ENQhIFOA3KQUlxToCHasvd9+nfp+g70+/1/1vg1UIMoDLOCEgUoByGKcEJAp1BDssf//TvX9 Pq//+/v78J64Qa+EDKsNhDDLOgIQxfd9+n3r6d6en9//336D70+8IOHYQPI0IagLkuKdAzDg zqH8i0yIj/IoMh/yJT91yCR/ff17+779PvT7tOHhPuGnaYIGQwhQJ8Pv38JtIN/kuJoEDd6I Tp0EyXEkQ5qfv1+/X9N/TvTtb/T/V/9+k++q+k99Num9DfIgTkgS75E/6ff96d6fdp+EHf99 /+m/+/pv6f//vpfwb+Qn5FUdELbXpbpOu/pP//9/v9/9Pfeqfev19+/pN98IP3oh/ci/5Dv1 /07/Xr36T/61pf2P//fp/v9Pp9ffCD4NyIoCBvuRKNPu7/r//3r8ijv977//r779v6f/39L3 0E+tB8lxNEP3/hYYLV8goz6Wq/9+yDq6Ig//7+RR3f/qwXfb99Pt9N/v+gg3f44r/rj+m/rv kCC/vkMWaj7v1/3/H+x/Vgt/a79P6e/13f+1evr97B6T8SPKyGV3/v/62+D76FfqY9f+qb/9 civ/+RR/v/yKP2H9//fpN/3/IGPewf/vqPfp+k9/qvv/S9e7f+9vr/+RR3/3//ryGcPfvf6I g/5FH//+pBQr7H/C+RR6X/74b1de//+5FHf//ew9Pr5DKz/hf/bv8L7f+C4/br/vDfV/Ig4/ b+n7//5EH7D5EH//9NxSt+l/5DOGRLf8iiH++l/fsZAwxq/8guP9i9ff//7w3vfmgMf+v//3 +RAlv3/kTA/4//ciYfi3kQH3kQJ9JvY/9fbw37f//7dJN/8ijv/t+/pbf939eH///fj3//3w 2u///pdf3//9v/b9vrX9dzWK+n+6+13/XvIoTGRgI/H//7cJJ//b91t+/+3v37fuv/9f+u+v 2dH7g673/IgP/Bd/9sf9/+0t/1+19v0//9///5FyY/Ptv///Q5Fhr9f/9v3212+v/S3v//6/ T3/9Pb3MCP75qE686F3hhxf/v72/fhhdv+RCH7DXe1///f99L26x3/3b9duD1w/7fv//7Yr9 9LrYYJe2uiIG19r9v/1+1/b//X9f20/1/Xt++1t/7fx7x/8hl3+QYHImfREDe+F9td3tfdv0 u/vv+63//vtf+v7W7Wrff8Xv/vFSGHLHNeDBL3tf4a67aWu69uv79v/rb/q9Wvrr//31b+oi 9ipDLvsMJe9guvYXvbv79/7fvhrbutXva3DWv+//17/v7x+7HFSGZwrRED7aIQj1YS31//QY X79e4YXtdN/1+/2vC9r3a/et5DKf/X7DX4iIiIiDISuHppresGFuGE///9avvXtfte7T9at7 e37FbxERERERIwxEGRNk0Gmnf363evDC92tXYVYa691/a3iIiIiIiIiDh2QIArhhftfhhQtr 77pvtr4iIiJEMvF8ubuGE7uGFCwwo3Vj/a3iIiIiIiU4gZBeuDBV9X7XxERF3d+gwt4iIiJr EBpqIj//8+ZsOd+M7R00QYwgxqSmSmDMyIYYNAIkMCC6iEGE9SJvCPfFtgV7vUJ8NUGFCDPg wEDJApoM8MuMIGQxmYaCORmFNBnyOpnM9mwcghe79PvvThhPvwmnGEHeoTCcPO6hkci5/v0+ +9PTX9P0/1VB53Nx3qR25L/yLD7707W7/9O9KoV6e39/9IN8jzI9CPtIi5kvoiW1/kV2mSAQ jjREh39JPrIx/99/p12/dab3hB+/QT8j/T/pclj9//6+l9P/7/Wnf7p+k3esHB4c8KTi5wQh mbFOhbh7+uv7v/+k+qj/tj/T/X7hBhB4QZsECBmAXCB0r/Sjj/3kGLHX68kO7+D997/+009O PjX8ddffdL3Fa/8Gv1+v/d/d0lfqF//1/5sP8ewck7/7969Eb0Rv0Ru5Ah8ij5CjphfqF9/8 L+FWk34bX/48R/b3w08i3fcMEIv6kh3IV9//VfX/JD9um/+SH/FdDitD1/5HrDcl//5HoRu/ 5J98X+UBUP/j+PzwXNA/3/2/0vX2162/XfB/X5GP/8Fwv//b9v/9vddvJy/zBvf2u9f64X// /2q6XvV+23p76br//8kORUdf+v+39hLwv2trva+/r/aVP6tZsuRx0Rx//7fsUyDDipDO9vYr thgslP/DVEc3uwwu9qFswVp9fX/79/a699rbjVvfiu/Yr+K1uuwva/a9+/a/7prba/fdX1a3 6Y2Pj4/g/Vb7hrhe3teGkv9qv2vd6rvf+oiIiIYIREWmgwsOGCd93DC93a34TQa3/34iIiIi IiIMIREQYIRyki+DQawyMe0GRvaf4i2IiIiIiIiTr4pfvW1h6jUf//PGduZIZQ/pqZamQzKc y5mVDNYT92R619MIP94vX4T/dWv6IkPkY/3r00CDezoFPhzwTvPBDjI5GBmg/Pl5qZFs7Huv pphB/hNCIYQZ47SCD8wQIGXM4zhmApmHPCHgQUTHaT6TX77099P1TtNUwoTT+oXkoyQ9Eo8m O9Eb9EUd+qfpL/ap2l49JtBB6f74TyUEcOCbFupKPFScMjn0iUZJ8lDkcdtL0/j++17XT+lf VNf09Ok9f/iPX28Vr19Kn6sbTUPpPT7pXmYT+eC/58L/G3/1Bv0K/3/6f8L7GF/9f7g/z4X4 64u/yY/X3C/71/hhx4L/65OL8hnoiD/eRB/tSEHO6v/sNxr/+4P/5PP6Bf8nsTFfyY7BtkUd SIP+TD6/7OFa6+8Jfuzzf/zbD7oln/5Ojv7e2uvvf6un2vtq/0ra59/7a5BgcVHH+2Fv4am3 tr72r1a2rafrdr3e/eP3YpWor7Yr2NjhhK+nYYW0Gg7+7/te17b09ux/2xCiGEdSDJKZFe00 0wnaDXu0+7sL0sNROHQiIiJPCIMIREMIRDI9DDw0IiINbxERPmOI7C2timKtcNNRBhR///// ///IYp1HBBggZmM8MjhoMxnUKeDOTg5ODBcM5WhCWjO9R0079MJrDVTMUzGYGEGdQYBAzMCD oMkECDPBnMDPkeDniNjPmaBTWRsj5GwXNAhoGDMQziWMpxaaf+g+H6+noO+0H3p3aYQPT0wg 4OwRCUIs2RxggZmM8Omg7/X/v09f0+9P9P/Tv9dNPoi20RL+fBE0RHfe/1enfr+nXr36d+n6 f6D097JB4QczKS5yOChyhwRQNfRGOU/REt/oiDur5EH96ffSf++n9Lpv9Uv3oRH/xeRhhPJT daCBuR6+Cfvkff5GGRMcj52qkMfItu/s+Lv739/T/fSb/6fv3/Sfv4T0/36T38d7/ofvr+GP /9cF34fv37///+n8wWu/0/+Qjk6ZId+wfT4S9If4Me+h/0n0vX6BHfevrj5J6/x6/wcgvHj/ kCL8gk/r3yC8bsjh1WSHfrd3//1/++v2D/r/vYPj//44//H9/6/f/6v4b/r/jYf5wPx/1r/8 V7+Rj+v/r78P/C/5IeG9df/rpv/x5mV076G5o/5CVUPwbkZH/68H5GP//4Tr1/+9f+4f1JCN +D9rJQ/c0OR63Ogu//Ix8jI8k+QYHxf/Ix3bW/fT19f/JBP/t/aD/Nt/dycfv/hh+v/+0m13 9tf/T9P9dv+vcK/9/+2lvJD/90t7Gwwl/Ix3DC+F/9/YaW/tr72vvf79/f9/fvait9IzGxSx Uhn9yU/IMDhheGt3DI58V/a+7DCX/YXdfX7X7TX+2116t9kcCNituIO3kM8N4/4/fYrvrkc3 7DCW5grTW+u0/6/+1t+17te73t7W3vpfxXrBhBrfrDC4X1+wtr/a/a92v9rY/7vD78TWxERE TXlJPTvVAwqDCp+gYLp2vwwq2na3439hO1xEREREREREREREGCERBkYSGVVEGCDskOCNKSHV U0GF7xERERERERESGxEY+ACACAAYAMAGADABgAwKZW5kc3RyZWFtCmVuZG9iago4IDAgb2Jq CjM1NDIKZW5kb2JqCjkgMCBvYmoKPDwvVHlwZSAvWE9iamVjdAovU3VidHlwZSAvSW1hZ2UK L05hbWUgL1RJMU9iajIKL0ZpbHRlciAvQ0NJVFRGYXhEZWNvZGUKL0RlY29kZVBhcm1zIDw8 L0sgLTEgL0NvbHVtbnMgNjQ4IC9Sb3dzIDg0Pj4NCi9XaWR0aCA2NDgKL0hlaWdodCA4NAov Qml0c1BlckNvbXBvbmVudCAxCi9MZW5ndGggMTAgMCBSCi9JbWFnZU1hc2sgdHJ1ZQo+Pg0K c3RyZWFtDQr5NgQMbO0MiDJm8NVskhkNnnk+rWqt8NhUqVb7riqv84EPjLxmNUirgoW/hNCw g1zBnzBEJxCOROL4iII9a/1VOTHpapxDTTNg+rfWRu0Rj0Rjsf6T9O5Y+TH/CULp0E/3ElGR jlDk4eiMfjj3jaenp/dBN0O/Tclb99Cq+3ryY/rBrSff/CJwtcfVr3wY9XX/k0//3iPh+//8 L1/yY/Ydf//kb/k+KB++sGH//30E7fj7HJaQ36//6X/68Hvr//ra5493c8ebN+//r2rasNe+ 9b91//xxx/TDC7a1a//3ba/iuK4r/7TIrw7W7Qa2tr/SiIl4+QjYsINBpw11/h1iIMEIMIRE fq2IpYp+9pWtYMrfuojUf/88zgIZg+0GgzqGCVsrbO6z9w4alUrBMyHH7u8KqR2qmCDPmQwc hBkg/JzcnTJ+73rQfDCDBBkNngXPCmrIgZIIkF998N+MFp9poNbCDCaBggwQf//PmdXX6Jd5 PmiMd66qmmnX/2wiFmHnAh4IYCIMhjJAyMM4WaXt+G4TolDTeSHfJD7T//6YQeg0LTI5hBmw wSAoQYIGXCHojkYEPMjimgpmPr9tW6cKajw6oJtErclH667rGt+n6D04tBxYQYQZwvBr3r9U krXenSb1rYX0StolFEh3IxynJDwwguiMdyKPji4u1T+x/D/dJU6/9P4qK/enoHaGgeh6fbkd k7YMm5IfIrkh9ojHaIx2+w/sdJ5nr6+1h13UL6dTQhrDX9PCekn6PHBYNyV6D0HDC5Cn7peP Xqk2Kj3qER1xF064r6t/X/6T70xTY4YPX/1/9JLyVnHCk7f+eCpE4X66/LhPvrrUnP2H+l/X r/VaEcN/4XC//8ehrF/UeDf6/r6Ix/qv99ExyQfXXr////86C/kcQJf16C/QS/79/RHHRFf3 /9ddf+H2kLQX6X+bCeqCv7eu2eEr0C9df5PXJB5KwX8mjlzf5Mev/xEHHhIJf3/PHrX/91// 4/Z6x/7wyrSWv/6SX+8JX369Lu//nj3PHueP9D7/URQJ618kGkktfbimOOwnthftf7+1/97P HuvX39cmPfQSC17008fHD2P9hhdteGF+0SHamHw19JdftTQd/V97gnZDj3272F+xXFbFexxS ewwlILjjRBeGvvTWqSCiIg0DPOGSHCBggSDCI6ZHEOyKPff98O7+0/sfVsVfHsNKQXchjxER EREREREREREMEHYJoNPTCDTWwtguva41TiIiGdwhE6IMmOhEMER0ayZQ4IuqDtbW18RERBxE REl0R0XGGVYQiGhDvxERERJbiMfABABAABgAwAYAMAGADAplbmRzdHJlYW0KZW5kb2JqCjEw IDAgb2JqCjk5OAplbmRvYmoKMTEgMCBvYmoKPDwvVHlwZSAvWE9iamVjdAovU3VidHlwZSAv SW1hZ2UKL05hbWUgL1RJMU9iajMKL0ZpbHRlciAvQ0NJVFRGYXhEZWNvZGUKL0RlY29kZVBh cm1zIDw8L0sgLTEgL0NvbHVtbnMgMTQ3MiAvUm93cyA3Mj4+DQovV2lkdGggMTQ3MgovSGVp Z2h0IDcyCi9CaXRzUGVyQ29tcG9uZW50IDEKL0xlbmd0aCAxMiAwIFIKL0ltYWdlTWFzayB0 cnVlCj4+DQpzdHJlYW0NCvy3VAc+zJYZDZAxnZES8QSO8ilA5sCDwhPmtna2PDs7BImcuqpp hSRAhYJpgiDzJqR1IM7SP//////9NJQvr6WsgQOk1TwoQa5P/9DJ7101+8lD7rT+G/11xpZY QugQb5P2OiXfXS/6+vvVPpN1/PCmghmIZikuZsVAzEcM3EcyPmBoOQ9RF0DNikgzhGyKcfkD GaiOpk4yglz49a/bNTOGQyU+VP11CaaYQZ0ChNQuhEWFs4wmE0zwNaFGGcPI7PmEGbaIJAYQ YQwgaDPv7dVzDMBQgYQYQNBnmRySzwh5kcZoKfCFwi+tMJp3Sf0vapsWoX6vTVVTWgmtVY+/ phPCcdCE0LCDVP0uiN3JO0Ttok9AkRj6rkWCKO2kRR/Ju5EHJO5FjJD1/Sk3esijtUu39h/9 LFJ0qenF11pBOgg+6CDcJBBtgtYVOwVP0HZdp6RHBKKT9L6QfRO9OiWNErsEiVxRAg9h1Wsl ZK2iUEhwUlDRHrkoyN6I3yOCOPy+CXT17S9V/8L66/SbhVWk1/pfW1XXT6T2rD/0kE6CfSeq QTdOgm6hOtCK/Hsa9J9ev6+GPX19PS+rY6XXul9XWGGq/X76XSngq9dPVfpUM8HYOOo66qqX pYa1paXWvT1B/9If1XVN+teR7oap/Wtf0h/BeCTDVf9V+vYf/XS/+rDWtL+lXlhIN/+hGv+c CfHSoeaB6y61qw/1pfXXww6X1/+lumH9axX+uG6rVL1rSXJBr/hf8mGR3B5MIpMOvX1rQb+q 69L+MHr/kPn+tTRv6X9ev9f9BVr8Fl4MfX/X+pvB11/X6Xo6Yb9a5Yda1/dVS+XpPuvxfk9F yemSxfXPGqSbnz8+daS9LVab/rS+v00mx9dZm3S/qta+vM7v0q9+tUF1/XXkx6rarrquvpr6 X9aqvr2FXsLqul9/QS6tO19e1z5queP19U2FbC2lDCXYS9f/XtabC66trhJahrHraw121XsJ dmwirYW0lulhrYX219evFRsbFUxUHHVcP6YrYquuNj6Ykx0/sVHDijByGj7HxC9imOGx7DI4 kV8VTYVftO01tb/X++1/tftb1tPbXW117TV1sbVb8fEQwTIyAmEIYTTJUCGnYTCEMKEwqapp 2RjqqDWGWOumEGmgwmugwqhVTCYTTCoMEwumFvURERERERERERERERxEcREREREREREGEDRo xDBBhCIYQhkzbEiUtRERERpWsFitNaaiMrA5OBBHDQCDMzIqKZhT4ztYZBGQoyXZ2OC5TkSB mgygZqiMCkrZ1iLGRVkoZhkSCEWZ3QHrp4TCaDO+a+uE0Ggwg1CempSNVUJqFOxNmYLnYYyg UgZlbMhkQj1SenprXVaYTCaap9Wv4Qda4QYTCBkTYQMIMEGfBCXMwC5GMoFyYMnQnzpEnwkS f+OiZMkO5IfJD1WTx4rjTCkcekpEHqqqmmnqunqknVJ5ZCf19J0E6CeTxhUg69YoINrL2W5e y5J2iMdokO1VU/woT/v061euuk6vtpYXel9BPql08J0nVEoyTtEoomkRDGsk+q/pDpOS4QwK fZ5hBmxCnBDgpoJkNnDPCG2fFzgpoJVXQpe6XnhcjjNQssdlA4M3lQNSQKueGTjzw8iGcI6G UGUHqRDIKdN09NhabSdJ6WgkgvXY/ITuoQeqYTCQQYTpcJ4J4QYTX0t61vCcWcYQa54EBQUI PLmE6cINDCZszZ0dQoIM4DhAwgaWagpgzh/1paVPT16pBUn+3yH8OuL+rVb/TVOk09LkPixW THtig9U619P08U0gnpcXhMJ9J640P+uOkKqkuOQYOmDSTTXkcErrhggiV0SiiVtE7a9Ijgcl D0Rxk7/3qkOw0SiiKO9ErryN7BaJQ6qThpIlFEnojdulyOCN3Io7VNLVtBaquix9ayH8h6yY 6qTHpEc97D7knesKn66bp0m6frhOk6wm95BcPp/0wdPCfp0um2qSf0n0E2gnQT3SIYxQnp0S wSea0SxuuEglWtapXaWlCqIdcMPkcNBB/0r+t0nrhsL1qWOqfSfHqpHDtQlsNJ6+unr1p1W2 q9XptjhpU9VVOsgu64ohAwCQJel3mYqaeqQ95IvDD6cXqkq6XSLhOl4Y16jpfrBqvT2qSgw6 /oVXWl6/YY6XVfXQrXTMP0lHaT/pJdakV3JXS9bwsG6KAtPH/+sdcbD1/+o2GQwsmHWnY0sO ulWcBFuv1/YfH6FNHQCIWaB0tQYvo+FrbbS0ttbhPCbQVJaI7+g/160utevQYa1VLXqGH/1t BLDf6qFj16+qYehX0nL1QS/0pddojQQHB9UuMG6cddLpuuaN1///6RDuC1kOG//1WQ4b6690 qNc9f6/116hvIYZf+uF1qvCrJjLfoQ3f9Jeq+v46keVJdL+TB+Wo+v/yYSOVZrqSDQWr618n yWv9VwbtEIHWTqZrjAmsln+WESojuvf9tPXoQdf/v/h//S7mdpZmy5t0tZ8TSrPsu21/0klv /rSVE6elX/Lt7/pMRrQSpeffXBd5+yPelRLn/6r/9atLRN2l6SquE/tf9dEx9+6d+6VqRzVL 1tJev9V+0q93RMeeLSs8a9V9a2eNfpdOrryBmkXP1I7SDX/6hhVtbXWm1te1bC2FtV1tDwva Vr2tpaSXa2uq6pf9a+mthJtJtdUTd/a6361WqJjvbW10shn633kY0vSohonYrYpimKOHxTFb FRsVFSDA44kx7FKxxVRTFRUhiiYMJNhL9jr/2GEtKGrDCVrYVhhJLVbC/YVtV7CpOOura1pN pNraS1Ta/a2mq1a4dO01u1tdNbTtLscVVet1UNYpdimKYqONW/Y/YqKSWNKzZsUxUVthbC2E mwv9pawwqaYTVU07sJphBrpqmqDCDW0wmvYQa+nr/2vaaaDQYVf/TTXvv1TSxTFRUVSrHERE RFxOuDOSH1BBghDLqBCGCEMEGEIYQYQYQiDBBhCIhklpCGEIgwgwgwmSICENQmEGRumE0wmF TTIo4hdBhBpraaDQa/aqIiIiIiIiIiIiIiIiIiIiIiIiIiQ4MIWEGEwmFTTQYVIREREREaUf wAQAQAAYAMAGADABgAwKZW5kc3RyZWFtCmVuZG9iagoxMiAwIG9iagoyMzIwCmVuZG9iagox MyAwIG9iago8PC9UeXBlIC9YT2JqZWN0Ci9TdWJ0eXBlIC9JbWFnZQovTmFtZSAvVEkxT2Jq NAovRmlsdGVyIC9DQ0lUVEZheERlY29kZQovRGVjb2RlUGFybXMgPDwvSyAtMSAvQ29sdW1u cyAxODg4IC9Sb3dzIDE5MDA+Pg0KL1dpZHRoIDE4ODgKL0hlaWdodCAxOTAwCi9CaXRzUGVy Q29tcG9uZW50IDEKL0xlbmd0aCAxNCAwIFIKL0ltYWdlTWFzayB0cnVlCj4+DQpzdHJlYW0N CvnQie6Z2sGThoI5lB7/zd//T9+ayaX/4/vPCE4zBE4yIGQzJz/94TNgoCDCDNg4Q80aGcEP n9PTTtdDCfvkn2iMeuvJj0/ek8jcjigm0RxkcOSf7JD5KH5Md7XVdPC6dJ36dBOPfHqvx66/ /+3gv6Fgv71/3/OB/8hh/9e6Q+xhf6C///90RB/8kD//9kcF+8nn95K//f8mxP//6/////// ///31/s4ev2v/n3/X9tdfbX97XvF/xxfx/7DCmz7v+1+/sPYr00yKPp9hMiD/euNriIiIiIY QiIZMFJEBDERHIP8f//50BMGd0zvPYTC5PHrwb/t/88KfzBE4pQ1NCMEUGQyurhNCwgzAZyO CIMEDNg4QZc/p2nxp3/bRG7tEY/tY/8J5KMJ5HYUlBG+TtyOCTgmvFN771XTpPXj/qx/r/3/ HuC/1xdf184Hr/X/yY/wvf//+T06Ig/++QfP6X1RLP/yQf/Vnrql663/6ug7X//zx/4qGqa2 F7/Ya/6YqKY+H/H8GXPCaavf9r/lOKGFQZFHT++Gun4jL2SRqO/7Uf//yMIiGQz2n1//T/kO z7+aAgIZgIYCHwh4Q8dE3eqFphB/01kKO1/6JRknyOyUZJ2iT+k3Wk9UG6apx/vXpeNjW0q3 5CPg4eP/qODZCpsU//ww2HT/7oNhvJz//Jl2D1tv186MOR4H0/37Z402L69hNte10/2xx7FM SY7CmD0+/uxX8NB2g00/EQZZBNQCDCDBDEREf///lAaCX9hMi561LSKBkelOXlpCQMX///JA ucEPxHHIIcjIJIJM0XJtNRhB6aEOGEzgOCDOF9PT7Qdp+Rgvkn6I3cijuRB6yKO0/BMwRsZH PpN8J6eCdEr08lcdO6v0+k3V/V06CvknulXS/6f9695B8TsY+Pj//+O32v////jdf////BWv J6ZPT//yQ5bNKCdd/f+//0OFruePs87X9fz71T9rundL3/afJXT7a8MLH7YS9tI2fX1itiq+ P419U7hrap9r2v1RJ2bcQwhDBUIhhDQYTXGlacRk9nCHY3+IdkV09cRER/8f//yGGchTMPpp /y0iuJEbZHeTMk4UKhIfCTSKsf7//fzWHI4p8IeamH8nT9C0Gun+/7W//vyDFkbkUfJR6a/8 hnuqdLrH/19NYa+/0t9fj/8eOTq+eC/9f/C/9f/X/hf/REH/8nn/8F/+3/+u/9v/+v37fkM7 /i/Llr//3r2Glt/9/adj25BeCbSCCIiDJNI0X2sQ1t/DCEGgaYUREf////////////////kM zslM7Kogo/pm42YIGcI7VxBsiopqMlIa54KfZ0ZsENAwawciV/T09NVNLsJ3cHDQZBmEyCZs yUguSkzJzPsi9/XRG71VIJ+n8NO/Cfed2/hm4iYzQGDAMGDMGdDNCPhoLgQfCGpmWfw14QQb 1WTI8gRZhyQ6RLn8nGSHckO+vvXVQv/arqEHZWzIuZBiHeoEEczGXiQLycyXZDjrY/T0oX+T Bx3/MyonOjMsfk/f+/f9d+mvpIREi2GeMlzKkyIMiz5gHBAwRC8DPCHghcEPCHmRxTMQ+LyH 1T58ZMETlqRB/lz+v9+9v/Df9DrJwpOC5+shkyfhIjt/1p5DeRtpmHZApfYQaYTCaqE4tMJk gzZmyI4Yhq+CDNmeMEGEDVQgYQMIOIZ8T9//e84LkMQwzOQeRxmg9z5Egs+RIM8RDfr+ND+r 4wn8PBSWEUeiOHp660F/et3GmmE0H3/Q6f2msmPT+wg/sf//CDy5hNMJrFhB9hAwgeCBmwoI M4CBBkgKcBzwJnBDwRBnB3/3de/j0JmUIN/4Nb/5HFEoyUNEoolDkY5TknyTuRXyT0Rv+pMc SMd/JO/RIdpqOnvr9/rrWvodLae6aenp2mna0E1NAwCDRMf/6Jj/3kEoRTkcEXpHIlpZpdJf +OP+np6en3xV0np0mITtr7Ix4f1f95O8mP0SiGCI+wQJSOHJQ5Bg9kIj/paUk7+Sd4akUdok 79V+kRj7I4ieq39///d+MMJnAqDizZnjJzLg4IGCBngUEcU+J+/5HIoL/9Y6RQROXCrDT100 369V+0/0wkg2F/fHGtBPewf5cLHhVf0nVqE6Qf0StolA0StyWBNyUQ8lGShyQ/RJ3Iwy4SJP Sb//f4doPTh694QaFhP7HCDiGCDCBk7CBk7NiBByCUIuzT8F6pvpxX8nPu6+tbDCX7D/X033 T7fhh/FVFQm/plj69+/3oMsfX708Kn3Seknrhb/39JfshE5FeiUZHZJ3Io+6/7T+/tPQ1QcQ wg/50D//58L6xx//4gvwYxpev/x1gw16hUv+LarXX9XjjVBhL+PXTrT19CtyGMIYz/8gxwOE 9N1Qenf5Icp2YNEocjslBG+Tj7B9af66f8L//gv+x/W9HAT2D1Xr6/kwcG/hSUKC//r+PiOs FxCr4X///g9//Sb9g/SfS6b18X6eun3kCKWQ84YUldErhgiOpJwXJwwycEbtEb/6//6/8iDr /yR4Xww+IP///D/J1IPJ6r/f/+POB80D/nUPxv968HH1//huv62/uv9bqq7H2D+tp8a/a6eE 3/kr//6I4/yU//faB6+GJNH77/kPVzMw/+3//G/+iY/C4L6hdlj9L/ww05PUur6F8mr/Hodb /X0//D8G/8HX/x6en/peeCnAqX8L9zwgv9e/cjv4OP//yYT//d//1/JhPJEdf/X9fr8MP//X B7//1///2DkwcG/8Qv/B/p3/pW5Mf/a9f2eP/+66S1LsOfiIIut1r//3929v/PG//+2euSvo kOU/+RB/H/94f7/vzqw3//x///7D8H/zgJ/wf8f+1tbRIdrtrr9qu1/2vS+naDcf/+zhfa/1 fr//+fern7jr8d/RMcF8mP6/fNwOiXv/0Ql/v+T0sin7X//+GHeH/wv+GH/79jY2Nj47CfsN Ehw1f79hhLtOwraJu1zx7aX6tpew0v1fuvta/tPStPXXr98V19b/03p//k6f//gv///vB/Mz /9f8N/1/uqrdj+Niq+PYrjY44r+O4P45DPPH/t7H7DV/20suFbVhokP17C/2v2u6//+v/f2v 2efn6//7X/MQP9//I79+Df8nL2n2RB4YQaDW/7TW++1vtNftb+14a/2+viuH8cVFR8Xxrw4/ Y+K/hqk3/6v7aXun2g9Wv96+tP//+Ev+XYf/iIgzxDQhggwQhk4hkhyqAiQgYQYQiLQhhNMi vDTQar2qjdr2q99w/tNR7VO1+/237FP8GRwfv+QXfXyGdwwvw0thhK0v/tf//bX///V/7POI iIiIiIiIiIiIiIiIgy1BYohBgg4NCIYIWCKEIMLZKMIMKCDCDWGRR+7++7sL9pf/+/Yr2Pjj f/Yr/hhZDPOwwvf2F/7X97iIiIiIioiIiIiIiDMNIMnpFkphBhCwTsEGE+1X7tYafaw1Vf// sVfFcP44fD2K/hhdCIiIiINCIiIiIiIhghEMIQwmt+sNSI/2va/3vv49iqiIZRkhERDBEhiI hhEII0DCafd3ab2vagkKiIiIiIiIcQ0DQMEGSBr0IiIjoFkMHJZClhpnaDO6MzZFjJYZQC5g FzbNs6xDjQM5gGD4hXEE1vO4emubaaaadpgmqoGcM7NDIGZcwpqMrRkqMwDmgOQ41xFYcmO9 f9f/71Cedgr+1NLI2zo/hoMLZJmEyJmdmplBkXPmZe9JesnoS0//I3en9JJ6r9p9/rkDeUpn IixEpM1M2GDwMGpkIKZHH2//Hvr9SGclUCDv+Hgl/+T5yEhpPv1rqF9YcPU7PGzBBmn88KUD zwpQZwZDPU8ZBvpV//63/xr//DcnSlePh//+/wqoMKQjOwkRBdwgwQeEGbChBmwcIHQQM6hT gIfDqcEPBDQ0GYCf/p/6moiQZsZQRQRDLkKgl86H+XZ0v/99v7H6/5c8s7WXsNNKqhVMlB/T XXTuKCaaYXTWNOTHf/yY/8UiQCHAqBggYIM4DhBwwg8uYQMIGg4gzwUIGEHIP5Eq79pHxc1B yGRILPkTkUESHlW/Ma/6ur64olz+v7ckPkh3yQ7iSH8hJ1v0/VL+vX+2k9NU77T8J62nxaD/ /CDbClyBAwQPBBhBhAwQokGXBwgcSXEROQliGeGUDkOckQTH++/rT9a/0EHSfQQeSwJuRwy5 ycZO3I4ok+kRu5GGTcKTh//9N/BjdIkPkh3fVp/e+nUiD0/+lX+1000179BhNMEDCDgwgYQ0 v/MBwgZgQ/EcQjilxmg86kdD/1X////////////////////////////////////////9un/9 69J/p6daev2lbkMWQxn/5AjCHUEoyVoNpOiV5K4YUlFEr+iVwwTCkcOTuGEGFI3olH11qTd6 JD6RIeiMd9pr/2nfp6YXpaWk1TQiLBBhAyOwgzgPuEGbCBAzYh5kcZcUzFIZJyx2SCJBkO/F ajj0PT9iNer9X/jX/6X4YPeqfYVN9+9N/Tf17/T034Sj9+n6D0+iUZOKJW0SfyVwwUlFEool EMlAJEnayKO0Rjv/1W4vTjCfZIChNMIOIsIM4DoNc8CHAQ+ENs8ycEI4pmENuQ5yNHHWC4L+ wfXXSvXw///vw2lfW2KXX1dfpfVOP9aT8cLx0n9hU/T7VPT/9PTdPXTydiE8IOiUaVVCXI4h k7JQ5HBG5FHyT5EHojd2w6Tr09a7sJ2FiGE0zhQwgfXzgfNA/8GU4T/Wv+DQuv+/k1b30Lg4 v/YkIO/j/1//6rtv7sUh1bsajfr/Sd/6dJlj3Sun8JRXXpOlUJ0EG2C6eRxYYYKTyGCCI4aI o5FeiN6Ig8MJfVPS7erTrJj/C4X9hgt///sPk9Cev0L8H/4P/4//84H/4+ChLIQ/fg/rg4r/ 6/FfFca9/WKqq+uq+v0m62DqnqE8JrQQbhcJLkoyOMldupG5FHolG+RR8kP/Jh9dfwbX/r/w w0///Df+G66+v/8L//J1E8ew/6YP/Yf//xnUL4L/EfpQWtUk9JVj11pUGHjrvVf1/pdaCeKq np9KE6CDfXz9olnRLP4NojjX6/+TiyT//XzUb/yVbkg/8hXNPycGp9V//9vDD/ww/8MGv/34 XzwJ/T8FL6tf/6nw+kl1htScJqYE6669J66/aprDW/t7+rPzaH/S/lEHhf39r9B6Mz/+Tn/9 fJcE7/H8f9Ed/+TUfbwb/wb/wxJEf//C+F/+pOqH9VrS6zAY/9QfPA/HS6H9d+lSFtfiFvrS +rp/S//p/f/vX5g3Sb//b+163JBuf/9E3/f/C///fB/XB8+/UH/7/kwhHH5Ff/JkV/v/16XV L/w3QWqX9KsENf+vz4V1+LxUMLaJD7XsL/da+2Fq1/tf/9L/7Xs4dyQ9B/2ueP3PH/6/9nj/ tzZ635HN7Q7yOwyY9v//tBfon3PBP9fbr/9fks/0lkh+iLCWQQf9fr1Wtf4L1/pimPY+P4bH H8asf2xS3/ILv75DPAMJWvYW1teu+1+1u/1/21/b7qnXvfek+zh6/67njpf1/z7b+q9Kq0v0 kF9a9b8F8vTrJ6V31+Tq/rH/aaa73+6f369h9P/6v2xUVsbFMV8HFMfsV38cOH8V+3trx7YW GiQ+wratra//2uv62u2na+trqtrX+kvrrarX5naX/SJz/XSf6I7tfJVhgg0GFQZFH79OGnfe mvsjh///v2q2mmv6a9qm927j2v/j/imK2Kio2P6v2OO+1bRIfw0m/Xf/9dL110v/1q00vzxV +9a+fNP+vv4iIiIiIhwwTJjZIuCEWgwQiIiDIx0LCaaaDChUGE01TvTC9rjp3dw1+220k+0+ 000/8fTsODI4Yj+ONL7/2K69hhfYa/DC9r2F9K1WlStfq1RMf/W+rnjiIiIiIiIiMmvQtQfS GWoCERHDCwyN0IaYVBoNBhP7sjH4af8NeGn/evqteo4PiktiocaBsV+xWuvpa2qt/2F7q/iI iLjiIiIiIiIhoRDBMjRDhkYaDtMJpqqfqsNV1v0101v1pbXwdf+xVf7HUbYXdpCIiIiIiIiI iIiGCEREMlRUGE1hhO04YVdMKvX+qaSb/t6iu9CIiIiIaEGgYQiIYQiGhFpr2FTv71TXtRER EREREREQyekiCBhabSHEYvSURCztYZ2sAQfCFAU+DBsyeMBoMRDwltQgwmncPCYJmhkuRWjI TNmVKO3M7rMlIa5wKfMoZOzRlZjskHVdNP/078LqVI8rDOjVQn2E1JgwpyJIZqMIGbDQZkaG TmYBzUZODkgIVYjXkqiO2iWOSqeGZ1+1rr6r6f/6pYT1vg1QM4DBQYQZsyZGfMioZy4EGgQ0 ihmDImKTMY+qfD1eMmf0Pjr/yYMmclj+/1puRu/vtO7ST/TwgwmnZoZswgyQM0MIGeDB8CDM KZs2DBuJwh2OU1ClBnUjAzQWQ6CepiCzLTdff6f+/9ek/r/q6CDZod3yfPkubdIjht9Pp/fh B+E4ahB3aYQZQM+GguYIgnkjlzL4hcLFAmcCmYKAgzBnjYYQMzCmwh4OXFPie1v//kCi4yMI 2LnhLOgpQPMxkYIufIoFNC/I5FB/V96X9XT6/hu6DyftUEG31JacmnJY//RFeuiKO7019P9O 01Cd0+1+wmmg4tB+OPf6JjvJckIZIChB4TCDI5hM4DhAwgwmEHggwgwgYQMIOIYQP9rfzYh6 I4U2egzgh7MDLjU+Nv/v3XfD19/6T9X6BBu+EDcn+SrI78nrRHD/Cf6fkh36Ix3a3a+nwcP/ 9/vT0/TvTT9BqnxYT+x+WP00NdMINCIdAg/HRMd37f/a07ZrFKBmh9HiIb+m/v1b+n26QQb/ QQdMhnoj53SSJc26QeSDJQRxhB3qSiiUZKBJw5KCN2iUZE0BshD7//5FHyMdST9Eb35IdyMf SIx3Ix7+iMdryIO7+H63p6/633/+6Ju/3qxwgzAOENQgzwT0nq7+tdffp/6b/oN31Tberra/ /eg2k0/TpNyBHA2DkCLJjvfSb6hB6FBBvp2C0g9BwwoTwmwwtEr08ncMIMKRxRKMgRSyFPv0 kRu5HdBYaRJ3Io5FHfJvbh+3f//2rbYW10Gn+P/0GpMd+P//rp+l+v/frx20q0uig7r6fDDD B+3////tf1f6vT/TdPtV06Qb9g96fp6iuEkHhU+k+yH0pcmO//135CB5J3a0tev36il7f6Qv 9A1Jj/27td7r/4L/Eek/XmLoGGDdf/X/1V4/719WKXpY8Mfrr8MP1vq+vpvafx2H9/+k3H+w fTyV0SislDkYzmD2+/++Hrf/j/131Yv//OAl+//8Rcmkg3J129dC9v9Dz4T/79wVeMFYf/HJ Dk9YN/+r9f/6w8GHpPt//X7B9PvT6T1xIR1HJj/rfZC01IY7+qTf7/w//+sV//fWGwf2O/// wW///IYf82CQf/0ODe/pV9/H/shKQb/2/1uF6g3itf9f/7f6XsHHB/IYz/68mO6Vg2//6Ig9 1RC6f/kE1Z1MORzf/VPX+tf//wn+oYf/+D3dP////DsH4vf+OShfnUTNYT/S7+td/9vDDr+/ Sv/2/YPv/6JZ/wX/kwn/9/k///JB0RB///qr8kGRB4b++TCczN+OP6v//Bh4b14/Wg+tA+C/ v/8nq5Knv9DyBhKr6/7/+6DB/X/ra5Md6a9fX3+/q//vyea//+StfolkoL///3/v5MP+HynJ +9/vb6zzfC///777H3eDyY5KhLXyWnj9/b8G/f/69q5wruv7PH2uvvvTfv+eP/9eu6r9z9WX N/+/vpqm1uTH//50P/k/76UnP3+n8iv/6//KD/fckP28f63T/9jzWL2K/7C9rDVtV/bXbSbS ////v9fv/bXT/T1//c8f6/3+39nj/c2fTa6T/qvt6/6Bf6r//f/6rkub/kg/8kPr/fD+v9i2 opiok3H3xUhngbHIZ4v63ILnr7DC9hb2wvfa2vwwthYa/Xa+w0v9L2/df+/uvvf9vb/b+l+/ 6/tL9++Tm/f21X9Nf1/OG32v9+mmmv32mv/p7/4ri4fFfBsVHD2KYuODh+xUhnnY+nY/vuGF /7XMEwwur74SS/UJN6+v69r+3/t7rv39f/fJ0f3W//DCF2g7Io62mg0wtrDCwwmF7tf7X4a3 fa/ae99p49q9req9+GxX+xrsV1e8V3bcVsGEuGvtrTDX9sJf/aS/pfaXe2l/trv3XERERoRE REREGCBhCIiIiIiIhhCyKeIYQi4YTIr3phBkUdBhbIx+01hhfhqt92v7ara1/qn262OmP41Y ruQz2K/fYMLVqe2GF7bX/SW77S/dfiIiIiIiIiIiIiIiIMEIiGCERFwwQiLhhbhhU0+8L62E 7CX9+v3/a2KV4g4+Q0QK/ZEH0/sMLb8NeoiI4pOIiIiIiIjYawyOI0GqDTVYYT/7XGGva62K W/YrduKWCTelioiIiIiIMIRERDCYQZnhgtwwmvYX+1XhqqWlvQiIiIiDCERBhC7WGE7Wwu03 1dCIiIiLYMKo6QtritutJ+SDJBkLZ4iPCL1aXyVSYQsgRkgyLGdghkqZrZsMHgXNbIQU7Tsq gQRbS+F/yBvK2Zx6rcHqd0ahM+yEjsJEQX/6RJ16+v9yO666aqFV6j40OP/+ic3BBvk9kRRH D/xH///1uofS4Qbr05Djwc+KUCoOzoRQFKsvLmUMhC8pHl4Eceu//0+tdNQmcB1I4bAgYUkG XBwg4hhEJUGEIZsKCBxI+ISY//y5kcYQMwIfiOIXGXFMxUGXj4pIL0DOC2fGSCMDNBkM1UkE SDKC6pp9pqt9hNNNNB2g0+l9KLUJoRFhBhDCZwEtoKCYQYJnARMIM4CBA5Y88CGwcIM2zh9E h6JQ5FH8mPVf7TVpV1X+l+L09O7HTVBxad6X4TtfQenoOGFhk4olbknvJQwwpHGSjJQ2SsJE oojfI4yUNEnpKqroivDJORw5HBFHIo9EcQyMeiUNEV7DpEcMjioij9EbtddEUd6el10m6/6p 0n9zF06T1v08J6tBPTXhKIXT1TpVTwuC0nrg2ChOwoTcjcjignkcWTr3TyN6JZbr0/v//19Y /02L+PjXsb8VXXoLqFXX9dYYe16ToKuuvSeunpuK/x//oRv/1xgvhNL4r0oSVL/9Y60k9YYe KXXVUk9evWl+1//////zoHXPAn/8JE+X6VdLpHgT/8G88CJIfrGlXWvSodf//+QYH//fgvrf +snVfX1+vBdfSw3hf0v1pDpL+v8np/+SI+v/JhL4X+Qvevb6S/S66rpdI6YdJf/X1/rr9/// ///ojv8laz/8mR/26//10S6v/hP5LPJhr5PT6/8nV+tnn/+547Xf/4S/W6H7f1Wv1pf9L1r/ 6Cqv9/5P/qlp9tW0//73//7OH/62vZwtPVf9ddLrWluq/rXz5+lnzqtJ6/zxp+Owl/fthbX/ 9tcL+tokP20rVL2/9tKvXX9VptL1Vwul2qrVWqX6omP7sfx9xTH/D9jjhw4tj+Nj/ukq4167 C3sMJawYVNsLwwl/YS9V/6tVbOH3a+vaf6j6e7I4Ya3a/39dr12OHxXsVDjg4pL2P4Nf62Kq 7iGSICDQaDJVoNMjHVU7Ix1hpkQe/tdBoNdf/TC66/a9p3pr6YXvX/tJPxEREREREREREQYQ hlpwQiGCOkIiIiIhhCIiGSOhDCEQYTQZKkMIRFhC01T1VbCp6iIiIiIiIiIiIiIiIiI///// /8nDQXZKQcljLceMhx44NM7uK2Z8yKkbiJjJwYLgQXMwZDI0I+GwjhnBAyDIpxlSI7BjOxQy MeQ0D7wv4X/vT9NLXW5TnyfOvS+6r/fTS61v+G/8dZPQnr/OhydZLml6X/L29/X/1p+lpJL/ 4kfkJpbOCGgmbCHojkYCHGRxoM6CHojimYdTwygrPDv//6fNDy5kNkh5Vn1fsJ7hMIOkHFpx DTCDQhhcIM2FNGEGCDRMf/f/YpAgcWfCAiFuXFBAz4YPhJB5kJxLCQZCeSHIuSOR4ZHI8X7+ 11ST6XWk9Dvtf9E3f6p2g06VNMJ2EHapxa2uvkcNEo+iUOScck+R2Rvkbt5J8ijvVakh0iMe r///sHS2qeknp66Sf9f6en9J0nSeqenYVNwnRKOiVuSDsKE9eYf7pXyDHEKnpqmqFJ6ppsUm n6X/0m/q6ZY8Ne119P9P/VdhhdxByGM179sHSIr5EHoivRFfCREfIr5G7kV8ivpEV8iD/+vX r/44+P+K1/VP/YpP3//hvqFVU9VULS1f0na26qnSx/x/H58LmgX81heN1/9g8j21Xet9Aw1o a9ca36rp6vrrX///+CuF/C7LH//fBoRcnoT1/HyaTX8RXXXH/tJaX6X//rtdfwuv//hh/9af h9UtU9ddLrr///fJA6yYfREHqiK/9EQfx9f+Htf/86m2v/r11r6/9RS//rzwWC+F/wXyQ9V/ 8kEiU//yc/3/1I0f15Iv9Jdf6/+ePWzzvr6/6//tfzBvX/qt//mC1fMFIx269et99UkvX9tc JOm66+n/r9rX//3/9P7den9lx6f2l9mCT9Jdf2lP3+Kjio7XsL/a+2qtr/DVX771vuwuxHxs UlcesXFRpsUv+Cf94Tsgg+Pj+Dj+PivgyOD9/yDA/+Q0OKeQwOt/dpLa3RGP/6pfW1TTW+/7 ++1/VfX9P77C9pr2vahNJNtf61ERBhCGEGEIZFEEV0Id2RXh2g1QYW04aoO17TW/QYWGqphM LdhdNU0lsKqqq4iIiIiIiIiIiIiIiIiIiJO8REMEdIRBghEMEQhhkikIRHSYUcREREUlG2lX BVvSC9JRaKFEf/ncwYhaCoKlShBYUJUpLgwYzkXBvNYLGFrWRBzDrBCQgY6XS6C2vSyDjnDW Ia7Xrkh6+/uvbX69iQcf2FnayZ2pmdhBTXErjgISAh1t+dqV5BymkE04M4BAU1skzMGRIjs1 MoMi5nZaZKjNTOA58MGtlQRkgffT9NIL6drev5Azyts4d+g0DsJnZ42YIGZxUZ2Cn4WvrJkf vpvf9dV/u/XTChTsu09P+NfXJfk5tLwwvBr7619aWk/X7WTIiHf/+3vt4+P//J0cmfUvYcZL NLr6wQM2FLhAg5BJkTUh+ISCJxY5HhDHETAZsU/EciGIEDQeRxmgvvukfHmsKSBScXPjNBk5 FBZUD8jkUGS4/MyJDyMvrp9eg2vr2tdPsJpqmhdhNQg0LCaoRDCD//CB4UwaDQeCYQYQMIZQ ZcMIOIYIGEGEIYIMIhHIP5Cf/XzDI4wgZsUoELjLjNB50GdDrzQ/+13Sfad6d96dJ9r/rq2u mF00019bTT0wnaa0v9RaYTOAoTCBhEMWGcBOIMEDCBmBDzI4pHFMxDzI4wg1JBEgicfrRG+C RKIakbuSdyKO5HhJ3Io7kblD0SdhhSMfBEfkY8NBkY9Ebv0ukr1+O1T+31V0401XrXTpBxap BO7IYRNUHEWE0LWTHngQ4CBBmDOH34T1huqdIPT0k9PQ6QeoTdCk2woUjvTfhY+TjyUdEool FEb5KMlFEo8jiwpHDRK2iOLJ2FJRRKCDu0Rvkn+uFXDEk+RByKPTf4dLSdp3pd2npdrH0uq6 6fq6f69Xap/rSfjr2FaX0wqem6aQTdfXVdO1f09MLoNpP4WK5HGThOgVSK9Ed2TiiVtEV7Bu iOIdEV8ij0RXcij2qvREHq2l6wtVfx39K/199X1/9fXwxevhjgyh1Twx2N/fp9sNfhrUnJ0u vQpKq+F9Quv0nrYcFCeCQK4UlGE9PBLyOMLRHD0vWUoPx3x19ffx/r//HwoKofvsGkP8HH// xiF8QtV171VLXq9V4MLrrrDDw1+6VaWgvS0utBOx98L///1/////yVRO6sH/wfrsPf+/zoH8 +F/j9akxwWtddJVTrX1g3iqVddV9fwv/a2wteq5Mdfd//V////7eGH+kG/8MPX/4wvgv//BZ 4ulS/9QX6/DdHwTQ+tDpdL1qo6/yOPJhPyQP/9fJ6f//5KCnKdft2H/w3v4bkFx79fyGfX6/ /8utP/0v+uq64bUL+v/UfqqtYjhff7/ut//1//4iP7eDf7ZOWfe+TlJkV/rkxyYMle9Ed/5M P+rf/6WlohB1X/RDb61IO+uv1WuvX67njv88Vr//2edX9r/5579ubMP2uRze0L1I5vme///1 /CWzgTu/Xta6/r5LK+tKvyfLkw+snprtUvkS0v17X+1uqtK1/T212//bT/ftUn/37r7CDte/ +zh69e/uePVL3pa7X+qX+v/SVc/aXpLonP/yer8Xsf2w0o9jivYYSu0uK7+1/b20u14aw1bW 1bSbX+/tdftbXtW1/v1XSpddLS1+1r/Qf+eL6X/8+a6faY9iq6/YqGx78exX7dx7HsbHGxxx /w/Y47iNj2OP9/9hhJdLtfYaS02kuF20q9tf6f0qbWTHcX2varDVe7tPW+1/btb7TIce1TT/ se07byCD+n1Sv/j/44fFVxwbHDjXqK9NL61sJJPDJqwgZegQakxwhaoRDCcNBhAwg0yQYQaE Wgaw0k9NBpoMINBoNO19Bp7kUe14aeq3r9hf7xtatfbXq0vD4r9ikrNnEREcRk1wtjkQhBgj qhKMGccEDNUdYLVnCFhoGgyWoQiGEGS2SoQ0MJ2SHQaqgwndprraqnS/3S199CIiIiIiIiIi IiIiJIQiQZg0DJkQYQiIYQi4lPMIRYTu1vbURERERERER/pa2+7TpRER////////////ygNb /5KC3KgrPERIZ//1////lF/MrM7VGdhBlPktjpHQU6/87LGdHqQcFJ4JhTALngICZqMkzLkR MyaEUGRqNmdgjJUZqZwEMwwU8VAzJB/1Xwun3DtJv/1ylM5J2qBoNNTs8bMqQc0jI/8f/k3S /d7/+uoX/h6hdNSEjsHAn/8fGvk55H9bx86r+/7+T2R01ChV+RMZIj5lREN6//7cJ6/x/6+T nkz0qxkxzDv+/ggzYUEGdAQEGEDQcgkyJqQ/EJZF4h+IQc3kXAZwUnIhioHDyOM0F/9IzG2a zyGRILPkTkUESApUFeRzIcQZL/pOr6ekIf9fpoXDCfFhNNQmmhYQahBmAoTChCIaD//CDwhl zCBgg8IMIGEDBSgy4OEHEGeCBA0IZgKZiSD+RKf683Fyo+MhmcI2RoNToM6e2vr35CjvvkQd w707110/Cf/qm66p4TVNLvsIMLphB2g1S/XQhhEKODNg1hBhBkcwgzjCIumIZgIEGbEPMjjL imYpnEcaDyGRIMnL6JDlPYIEJOMkOUPRIdhgiOgwpGPRIfcIISbvkY5Q9Eh2GCRIdyOMk7Dh kFx3JP+taW10SHaIx3yQ9Eh2q//fa2mF9f9DtP04tsGUPCahBxFhBoWE88DmwQIM2zh9ceg4 bxfB8eg6g2yV4J3kcPF8H8PirsFJwE6CDfhZCP5O/Jx8PT6t7olbkb+RXYYIEpK2iVtEbwyY 5Q4QKiUZIcSMeiQ+SH9LQVJEV4ZBd3IrkUeiMd9KsMe/1TpEx92na/BrpL9L+un/SenrQTfT dVf7/xxXsEXWr9MEXST9N0O9Pwnx/enxod0g4Pg9B9VQ/2XYT1skOUPhBQ7JjrRHbkcWGGXZ K4YIFRIdoijkUeiN3Io8NJPIo9Qm6XxBeLrq/+tK6q//9L6f/W+oRHSUMRuvthDQ6XZxUxX1 9RWP4+Gd1pN7pRCrhapN1Cx6HxWutg+E+wgeEwnQTwngu4TyK+SvddyNh//f/j396/j96X+u OqhBR4P35Cd95CYP/+THFgvhaH60vqCI66+tKkFj+k9YYaj1t/03XpdVTpNsV8L1/////1// //8mOZwUnj2Df9h/Ww///wXz4frj/qTtDX69V54P9fhvMwqqtJfrr69L/1Xkgf1/5BI6X/// 9f/3iO3hv+ww/8MP/X/BfC//6JnVBpUqr9dQX/Sw3gvH+h6WvXWhsL8lf///kphD/r/yLa9b v/5Ic1r9vDf+G/8MSRH//kgf1//8Vb/XiuqVJJJdIHoL0lr18etf5DPhs/v91/0P/3/BD/v/ +I1/g/+D599qDIx/+/xyQ5x/ojHOP/k3Kc2dfb9fRMf+iO1/+SG2shB9fVV9L611iOl88fbr /2cLXbrX7PHt1Wv+54/22zZB0tcjmHbXeQ+c+//+SHqP8IKPngniN9f//+vC/f/9ExyrXL0r yTlQC/VL1k6n9eGF+//bW/tbX217XtL/vv2+/tf7+/tMjmn/9Z46X8Vu+zxuvW3/Wv//613X jrmd/QjVLJuW/r9fF7H7HBw/iorY4r47Y9j79hhf72wux9hbXsIjdq2sNfX+Grr9q2u2trrW ktLpaWlrXaS+ta9hNLrPEq6jev59p99r64966/ah1vx8f77Fb7FMVsVFRCY/4P2OLhw2OPYp ivVvpdhhUv7CqlaWlDC+va+tr/C/qsKibuGW5Q5xyxyhzjlWWOU9kV+wtoNP4arDVeGE77W+ Gq9u3Semmt2mmvpj2ni7ZBB11r//xXrxwexXsUgccNj/Yr9etVbC1xERERERDQiIidEGVEMr 0HZQ5nChEdBpgiOpEhBw7CDhkhwgdgiOg0yRAIMER0GEIi7BYZKsIjoOIYIjoNBw7TT7hhEd Mij2Rj2RB4YQXw0Hr3/w/1u+1777Wu18Nda+KVzZxERERERkyomuFxxERERERERERERERERE 0i6Bm3EMIRFkcwhDCFkUcE7CDCI6qgwRHTvsER11sKq6f/dK/faQiIiSnERENCGU6ERDPkQy qFWVCDKiaQUQ0IYQYQiHDCYQsIjo+hDBU/98RERERERERERERERDQiP7SG1tpRDu1ER///// ////////////+ZR71HkNngpriDiBjKURUhnfkZUoTBAzgMBMhjBAzwZy4z5AgZ4ZcU8QIGag wZhnBAz5EQMnBchjMwzlyMwpoM+XtB+g+8IP7QcPCDVNB3GEHa+79f/vCcP/tVT//6fen3p+ nrdunf5Hjkf+kRIcj0eiLH6kSNyIGRYferIED0Qju/7/8J6+m++EG5HmEkH+R/yQPhBv//+k 12rtfpVt9ev/pPfrr/x74Y9+DC36YX+n9f/WP6svRw/0h/UdPX/e/x1/EiRkH/f7yBD/ikRj v6v///sHx5wL/6I3f//H6gv/Df6f//SV//6r+pIeH///q4VP//hMk7+zRyTlEXJATkY/9a9D 4/vkh/ketv9B4+H+3f5HpNCfkcNP/3/t/r7lyf3s0H/a6e3/pf9W/b++397/9V/T+/f+/wwl e9r+2uEthrp7f7aq/+5Bh7HIZ3vYX3hgschngVIEDkc+3I//DCX/212v2P6Y63/9Jv2N3+7f te7Xu1W1FN7H+wv/74YXu17tVhr9r994iIOHDgwnrDCfcGChYYTW7v4YW8RERERERERERERE QZNtkxlTo///50y3UOEzslZ2VGTmTAQ+Z2XIqIioprZLAXI4Zz4QioQkBSoLqph4QeEGqmjT BCwmeMhmCBggZ1BcgzLmVUyUhglbMnZpEXZ24zI1P+unprr4T+Hd3ZLXw0zuHa2biJjNAYMA wYMwZDI0I+GguBARC6k0swuZkA/a9EdvTTgupAh1I3f3d7S9666f/69hB4WGdghkNkXZF2ZY /j6Cb0Stha+SLk6BA38nPJzyf6H5P3/63/vfSf+qaZ2iNmSoQ1GXMlj5mMjBlBE4zQZQZwIZ kQzJBki8u0n61/rr/fb2/8N/40snqT1/nQ5Ool3//X/vmAcIMIGEGEzgUFBBnAcEDOBCGzhm zLg8Q6fOBDjPGbCHxNpIjBAQMIOQSZE1+//vucFzoM3XkcZoPc+RILPDKGfM6HlOzq9L/9JP 6bXHv10F/7TCaacadpoNP0IeOE09NBpDp8Q0H9j//4QeXMIHDOGE4sIPsIGEDwgzYUEDONAw gyQHNg54EzghwKaNAzAl/3//l7/r4L68jenIx6p6emumul36aeRymen6ft/+tKn2v9p7pp6e nF6drhPjCaJj//RMf+MQZ8Q8FMCSCWT8xBrImErIpMjIJUI/kc///H06JXQTEnbkoyVkoyUZ HDkoyUN/knJwRw/RKNck+ThxDHRJ4YIMnBFHaI3/IRH1/qRj/RGOL+0/TQ0Rj6T/1ST+9vr7 2/u0HhB3ppoWEGXI8YQYQMIOIdEcjzIYIcCGgmeCHAhgUnHDyOROWZn/ra6ZY6aSbqnp66Yp 76fr+nfp0g96Tb9B4TcgRSwf4SisKgm/hPhhSOMlf0SvJ3QTyWEoyVwwkSjI4ck/kncjDJuE iT0v+v/htpx3r0r6YVO/UKmE8JqEGEGE4hhAwQMEH5wQ2zjOGXZhkcUzC/x8ca+senUnNv/6 fwfvsfvp/rSf2D+Ooqn6Vkx6XTpN/Tq0/09fT06T1T11T/IPxB+9JfIMYQqclFEoyOyUORR9 1yMc44IIXfdp3v6aevafhPQfhB3fcWE/4LX+uC/Ubqv/4qvDXkdv///wb+uv+hv66/26DKeP Q/49daq9fY7d3/t+wdPTdIJ4Tbr0NMld1RKKJXkoyN/aok9Eb5JxyT5HZKHJD2r2P71+1/nQ E//zwf/4r/88F9kLAun//4uTByME+FBV/7r/H8eOFwX9f/r/hpf/1+GH6T1vvdfVN9U3XTwn +qeEG0E6T0k8J2FJXRK2GTglD9Eo+vI3yQ/+v/+F/4/+8Ffb6/v//D/J1k8yev/6///PBc0D /moL+/t/sHF9frfg3XZHvy8nX/Wl/+I/e+rX7M8NN1TqPXT9P9Pd106Qf+v/+v8JkQf/uUHr 4Yr//+vNIP/t//x///gnhfwX/S/9hrJ6k9fx8mk/EfEfv/xdqk6gu/a1qCOO8cV+4P+r0r/j /rr/olmzzz9/3JX/kwnX/vkcfBkEB///kwnT/+//375MJ5Pl/r+v//+GH/+n4b//4/96/Ogf 96+I/PB+Ng/0P39Jkx6r/v/peNC/b0vWzgTr/tLQWuYgb/6+v+//b//Pv/9LHP1ola0Sz/JX //X8G5G7//86m9/19f1H+F//68L7D////j///92q+uvvZwq/+/pdU5MeeNte1/7PH//7ff+n X9nrX0P+v9L/X/8HQI0P/uTn//k9MmH3/k6v6/x/+l4Yf9f/8V//7wrYRGO5Idrw11+0SHav /7aXa/fa2u/97r7a//6+3T9eg/s4V9fr/S/eldfmD+//X+9e77//r89Ijv/XyQfXkxn+C//3 ///HFRUVsbF/HFbvfse2rHYVjbSNnw17+GshnnYML/sPbS+GF/21wSbSbSsJ9r/a+67a/37/ 9Vf6+54/PFq1/Z57avEJdd7vzwSSv5CF/JqOv/Ig///7tNNb+7TVVx7C4t2KpivYritir4r/ fj7YqofxUVHEmPj4+4bF/HxX3YSX/yOWr+w0vtabq//dN+te/33PHrX59lz/2z/3X2vX+tqE 0yIPDQaDCpp+g00/vtb7Qaa9r9rwwv/2vd49qmmt9/v9in+GRwer/iQo/vkM8D+K44r9Ya1D Cw1C2ltWtrfp9p3/6D3/fr/viImuEniHA0IM2hYkEDCDQiyQmCEMlYQZHCDQaDCEQwg0GSdC GEDQhhCItA4hhO0wqZGPoMKCDTW+/Tv7te2Rw+//pP7XtbW1+xWxsRx+xsbDRIfHsMJWEv4Y XtftJ9fbWIiIiIiIiIiIiIiIiIiIiOS6EREjEQ2IZMITA4MmDQZJz2gwhDCaDCENBoNU07XW 01hrev3aaaZDvr6qP9imOD9j4/Y9r+OkIiIiIiIiIiIiIiIiJPCIYQgwRILERDCDhhBpkQfT tBw0Gt9pr9ra+v/eoiI0IiJniSMcMmGEGCEMjCBBhPThhYYVYaa38PBVEUhEREREREGCEQYQ iIiGeOklESSmK2gUFvi1TYSkYZGEVIjsIZ2KnXHC+qnYMZCxlZIwRLYgZHYGR2aDLjIuRDIj GIMJhUlXX9VVfVbEGFr1+lwv0l+NL/pd19Xr6RodGKqpfGq8V74IHEGeCGgilxSGIZkRxmYS QShE8lhIMiTLgjyRyM2QYh6NjMx5DFkOQR1E4Ix5TkTjUzLI5kgqLmTkamcMhH6XSTTTCD1C DQtOwg01QcX2CYQaFoaBnCNlBggzwIEKMEXBcIMIMINCGCBnCODNZGyNg3CBmwcIGCBnAc4D 5cjgQ+FkHycEs4Oq6afSdhNNN1TT/TtIJr6aGqhNQna2EtVTiwg000lQaDvQf6T01pJftXST /S9V1TT/Q09N6+1te/CqnputURR8ivRFfIo9CpFHeiKP7il66RG9V/1/rtOK1RGPTkOPW/7+ l/VPXWlwknREfTyK9EWLCkV3Ig9dL5EfI4yOPyK7kV8hXI3XIg+RuRukRR3Ir5Fe1fEij5G+ JGPkUeiK/rVEUfIg9URR/XUV/oGF09aV109JOgvfKj60uGKVbFNwSWkgsNdJOlpXUaIx06To iQmwZTp95HHqRwgwQJPX03hheqqPH+uOn96+vSY6rqH9SQ60t/wY6rrp2pIf1X1WIha916ER Wn0vGvqtdfWvXX1f5LhjWtg9Uv6r6zAYWP/piK1jqMkA9aX6moP9Rpfr/1pfXWq+q6VL9v/r 1/pf///8Jf+uSAwlr+v5B3X+vC/0+teP/w9ev+lXr1+q0l/qv9dLr/8wS8jIm2nf8jEUvW1S 1pEV/+Dar+l/6yK/khH6WvkqJZIQRB/Wv//Ief6ftlx2g5GO9L8wSfap6/1X1amhB+rW9L1S 6rvS1v6xrhev9Ztojj/Iw/YrSjj3j9i47STtL9zg8LraVrhVSsJdhf8KrmCtdJTg5EHWtmC7 MFpWqaSraD1tKswaRwv+9Jb6VbGrH1VcUlxxUcbHsf8cOLimNNfrj2Ljio/Y9JD2L1u0uwmv aXeFSI3bWq/+79NdevddBEUd1TXv1HX8dLr7YVU01u1WwqDCSdqvqn/aaqt66d2kE0k++u1T TX009b18kQiGEDBCIYQhoMIlxtBhCGFTBNbh2pjoMJ5IdBqq6faDCw1T9VVNYYTIOOFCrYT+ 0vxERERERERrEROmDKcIRBhHWERETOBhAzkwhEWhERBhCdWGT7I3SI4CEQ0yUIM0Ag0GFQ8J KIiIiIjiIjjiIiIiKVsFSCSWvpL9K+wULzppRhCPXUa8YiP/zsUzASEOlCUJUFQVBUqVKSsF j4WrWSA10qpeuEF16WQzoW12vT9ZGO17r9exIOP9ZWA0EWZknjtYLtdkCaZ2iJUzpJkSzVGD JUZgFzgEE5nUirIuZEyJoZQRGs2Z2CGSozUzYYPAua2QgzsZFVF7Xrqq4TC/dpP/6fqtoNNM 7o1CDM4qI7B5Ln3wyhynJCnXX/7tJv69b3pO61UJqFCpmSyfhYi9V//8n+Snrx8MKv+5OHpJ OmqWuZFpHYg+////+3Tat1ePXrJ05OXJ7IjJ/9f/teSBEHIJQipyJhcyxwzgpIGtyCTImeQ5 yOvvukZjzWFIYygs8RQRQRQeVZJ5HIkP/6evpv9f/XhNCGEDThhCwgzYOEDCDsINBhBwwg// wg2wpgwgwg6CDBBggwQyQZHDCDiGeCnfBJBPISfrXU3FxhAzApnEcQjjMDMxYZIFJBfnyzQ/ 3Htap6p2qd/a/af+unrphB6aaetraadprS/6FqEGhEWEGCkcwgzYPdBBhAwgYIM8HI4h8Q8C BA1PsjjPRcZmKej8QgpQZwZEESDyOZIZ1v18k7ZFHIo7knaJO3RGOpJ8jHtB5G+Rjv5GPRGO /XS5Ifp8kP9OSHojHa++mnaa/6Xxaafr2KhNQmhhO1lvi0LCDTChBmwoQYQZwLEMEDBEJhCc Q45E8iJCJxnI6TUZwZII2ZQRL3a9J2FCdIOkHYppJug2GFBU2k4YQYWHhBv0rVJJvko6TaJW NEraTwnRKPI4sKRw5KKJRkb0Shok9ddeRuwyMcjdyOyMciD0RxfRGO9h+1enutp2m2qemg+0 GE00LCYQaEMKUBQgzYKAQM2ZcE7/T+/11VP/+wv60vjivYTdV7CqTH/tJN79P06Cbp6eg+/h KNaeFQeqYXCdgtIOiLGGGCRMcqLBEdIleRuRvRHFEcWElyK+RvRHHqSHxJjte1TT01107T4f /7+KvtrS6/rH+u36rsdJ+xx6ex3rr+vfD190+hSCpKqS6Srr+FwsMHWLeKTcKuE38L4XToJt ikEHkrQeTtyWhKKI4clGSdyKORR3JQ5KHIo7RGPpO1/sL/+ONrj/+jMJ/x8KFsH/sGv7BxH/ 18aj6Bx1VQuta/6FaSSfUN4YX1pVpcL660v6fqm1/bp0mKeE06T1wnp5KyV5G5HGSjyUPv/X yY//3/wX/+TqJX4f/Dr+Hv//18VrCk8C9f0qSzwdf6ww1EjhUkPrj+l/pL2h/enqohdMp0/V VbXvT1vTXT+/hf/XVf+v4X//pvBg/8GD/wwf////8mOVYLDf+l/4L/1h8F/XWq0NL+OiBBOP /Y8fr/HrWum63H6rtb//JDlDCdT5PT/6X/Igj7e/+Hv8H+67+ThfyDA/6Ea0kq/69a/Tw3hf r9dfS9XBf///+MqAv18f4L/iP/vx77//k8/8mo+3nQf+DZHM/fg8mRX//H+SId+rfqlpUulJ Yr6WqJBvyQ5Uak9PUh/rSfpVqv////gv//5wP/+1/c8eeNdzx+///+ff/nDfvyOb6HqRzYt+ v/7OBd36X///rQS0l+v0ghrpaWSD+v/IodEV/Jg/8gx//6X+//C//fv77tPtdf/X/tV9vut1 77W/kh5wr//7OE/54/X2//Vf/Xtf9dVs+/6Pv+Tnr1gk4L//kJp/+TGiOP/yY5XAvVf/xV+x sMJIlDthr/f2E/9tftvtUoa9pNq2laVq2F//bW0SH9ra/617aXr6/pV2l6+E9fTrVLWvzxIm P/z9f6Ju7OBF++u+/xH9Ed//vH8fcOK+HD+ODh+x/9sex7HEkPjY4qP9h/FMfbGx603S1Vhd L2wvthJdsL2u2lXTaS176+2q3p9oPXtc8f9/njr9/z9/X/KmiXROthPhhBhJO4fe39+Pa+m3 ffpraaDT/x7te0/S/qrFfpRw1j0mKhscOKXWPWGl+tRVPYXYaTDXtYatpr/a2v2vaD/1/iIi GCDJwhDCDCEnThgg0IdziDCDI8uyMOGEJ9OH2CUPhhBhOGEwmER0Gnfeg01tMJ/3/2FXW/TX tftftfrf+0lcfGxXGxxJDiv2M2cddrtpfuv8REREREREREREREXGhERERERERERERBoGT2Vo NCGg4hkbpwcNBoNNO07CqsMKqeuqraSd8NP0001W7Sv7Hx38X/uhEREREREREREREREREREG g0GCDQdkagJguEwgwmvpp39rDX7/3UREREREQZWwwTskNEhoJhU09U+0hHESKIREREbeo3hV ERnUHNBSGLKAzggwgzwZy5E7I4aC5mgzQyXMyExDUZKQII4aDwQzZQycyjIFEJHdQQ4CEcys /QYQfa/+dmlRO+MINO1BNNM4wg4s+ROZOZgFyGRoDB4FyZGZsigbCOGczCn2UM2ZOzZmgUhm UMkxDMEOsejQUkgzuHpEV6Ir6//wqr6ff+qfd9rd6+EGt3dhNNQgcGcDOEDPGYBgwYQZDI+G guYIhaEzlkFhlqRuIQ3Ik6wQboNydTzMtPa5MPyeG89kjkrfp1+iOHrfd3f+nr+n63pkcJdh B94TTW7JTJpkDMoIixnYK/8J++vx+vEXSffX+g5mV/J++T5yfvolpl3CREf99Ijt3oiwHeiN xMPrTTrQf+un5A3ZW2erJSZqM2GDwMen/v///6f7r+nrvw2uTnhvXGTrJTf36QbXhPJ+5KsI MLk9UiXPOh6I73frycL11C/oNB+xx/9Ex3kuZcEOgQwEPiHAQzENBAgZDFCBhA5BJkTX7+ub FKA5g9T4yQMwX63/f7ZqIhmUPyrvp/T+F3770k9X06+gg3ePjn1j/+l/u+//+4tB2EGhhBqt hP9+/QZwF08IMIM4CjHv91/wQMwDgh5sIcC/+/+/179fWr39N7/j/6/JzydPhw+TH/rf2iFH a+qe938Md5MeqdL6d3okPv7kx3+62tBP9INffqHT8P9pP/X+l3kPOAh4UkDvOpFB5Vn5Hv/p vD5BjiFOQtCDF7/p/kb5HZKMnDkbtEoaIxyMcIjqSeGCLphSN6JQ/YP1ukRj9BbojHcjHwfX LHfvvr6dqvX4//QyY/sf8f1FEx/73hNQgzYOEGRw2AgwhkhlwwEHEj8iJyEgQzwpoJIJQjR/ q9sGwd2Ry//6b6b33p4T4pNuLSTaTyBFLIf119NyOBW0gnpkb2Q4fb7/X1+SjI4yT9EnckOF /rf+/B66/+3/f63fpqnxYQYTsEGnDCDC66/DDDD++9b+uknxrVtXrf66v2H3+rpVsKnqnYel 7/03FfT09P0Hx5AiMckO/0vYPSkCH99V+k8mO/kh6JO5FHvJj7XuRB+n2nprX/oGwbrf///+ HTddD1+9b+G96dYV1XffWGH923+vXh/10u6///72Dj/kMZ1v/79J1em2sMnFEcZJ/IrwwpHD RKHJRZKEiT0ScWmq6WlkzE6Dk6kx+h//HB/H/6/HJg4N+t1v+sf5Agmv//wXitdPpP/7t/q+ DDr+/3/916eE9PC/hNoJ6hP103TuwqD0yCRkcOSf64Xu/39/0+wf//6/4N//7/r3g/Grf6Fy N/nUL///J1ZEvt/x4NwpJzn9et/9t8ft1/6//+6Ttf+k08J0n1CUVzU2yObfvX//hv////w+ //9//hvvY9eE34Lf6X/8EHVj9PBuTqj8m5Xfj+/bI5/H//Hv19fiviuSD166jXpsb+0+v/yQ x/JWC//+RbXmZv9MVr38lC/Ig31369v1///7KHv/ZQ/D+/iPa//+//////GdQvmgTriN+FIM br3RIf//J0f/0D9UOff//BD99x/8mP6cf/5Od/5Ob29ZK9f+v+nXvuneS5v+UF/lB3+lsf// //f/gvgv/rCk8XurS911//bPGRzfWzxtoevv59//917f5+/tfb31S9vpBf31f+/7v+iU///+ 6yblDnf7+/yc1//J2bv//r4XvkGB/yxz6IN8vwwsNff6v/W1tbVteTH39+2n7aW07r7f2g// 0vfS2/1191V6/tL/7qvv6br+6SEf7WuTHrj//j//8kDI4/JR15MP6jt4kPYpipDO9/3kFz/7 CTFR2EoYXYr14YWQzzwwtfa/7bDS/NthhL7/CS+3gla32va/trqr7YVb8Jfa9+vftpb/2ef/ 969f+gv0nz4T/9ftBr/1//Y+mKYqDfY9iF7FfTFe3w4/1YrV94+9uKY/jpj+Qz2DCX78MJby C6Aa9sMJfsNVf2137XX/9zx3/97njpf1tezzta9vsINbu/X/uGg1TTTsL9rw17v99lw/W7XX vSX9XW61+x/+xVXbFchogV1sVV/DCW6sbDX7/sK2t3/2tr+uu3b6/xOuGVyJAcRENBhCDLHK GIREMEGChAwgwnDCEMmERGBgQwgwgwgwTBEdC0GnaYVO1hhPT01Bb7wTIg98PhhfhgiOtpp8 Nb0/hr9rfwxX+x/D/YqP+H8Va3dqw17C2vW3EREREREZM2M4iIiIiIiIOIiGTcIXEQ4NCHDh w0HDQaDQcMINOGndwwv9hO7h2vf93/j3YuHDI4LsSQ/YqPX+oiIiIiIiIiIiIiIkNg0INCDB CIskGCDk6f3YQaaa2sNO7u17T1pN/EREREREREREQZlAJkiLsjDCEQwg/XXoRERBggaDCDPI viIiOozqyEFO08VUXandJMEGZxUR2XZEGdi7JUGCVsyczNkWMlhk4MGAXNs2zrFDNAIOAuZi UtUk1VUzsCNOHZ3drm2npqqYThhQgzs7NGeZlM+ibpXRFHarS/eFv117v+0Gq3nSOxuIZnZa ZDZA2Yfxxggb9deT5/S+n1/fSIr9W8KmvdpmQGZUjIZkIzR/6f9fw390PyepPXWp0OTrBBtJ f9/XyVH6l3fMMjjCBmBTOI4hHGYGaDhkgZ0L8+SnyOhmzKDOr8hmQzKD8uyHYf+tfr79dIK3 +P7/+vSQtQgaERYQYRDFhngS8IMIGEGEGeDhBhAzgIEDU+0GcaDCBm2cMIRBggfZwQ0CZwIc CGAhwECBkgIcZHFMwRTgh4ITsIMwJbf//TmoZORwtcjGdI8f/4/8f+Owmqd2SAgTwnFhO1lv i0MJ2thB7hBhPCahNPQcQwug00MJyY//0TH/YggzYUEGkrZIBDgUIGcBD4U4EMBD4IEGcEKc iQRsQnFTIMzxnCIERIMoLL3/iiY/9hkUck7RFggwP2RB6Ix2rDe+1T2ltbW60/VDWLvX9Ou0 uv/v7TQh/3F2naa2mEQSGEzYOmTmXDYEDNmeIIMIGCDiDzgmXj4h8U/Fxk4zMUnIlBE55mf/ +SvBJB6koCaRPmwXQeRxhsEiWQy7JXkbkcZK6I4sElyOMjiiVt0gyTkcZKPyUOSfJQ5HZKMj iGCRKMjeiT6RG+RjqTcJEn9r/q/sPkKPwyo9yEHdpxa6axd/p3phNO8IPQaDCDQhhBhBggZI M8ZcHCGCDPBAg5BMLwiTSEhzkZyM5JU6qq6qv60E3WGHVek3VaT1/1102x9Ok/pPQen6ff3p unWnx3p95DGEH79fIMcQtZK8jslDUfkb5KyUORvkb5KOGkSdrIQck/+PpNNb/1T01v7VBprD sJoQwgwQYIHSX0npdRrS+sMPGlrqur/S6696/pv6tJnHtdP14a61fq6+xSu7/2/YOtqg9bdP VB6bhPTJ40RxhbyUZLE3JXYXJWR2Tt6olGRvkocjH6JDv0RjuSdyKO0RjuSHa/qv/dp6f/// /////////////9//////////////////r//////+v9/D/////////+l/6rPhV0v21MwvH9Id df66IR7X//vjitCv4r/0r/w//9L8Nj6X/X17tek9ek3XVfb9Uk71vTFPTek78J6D09MQg3Jx +StyT5KHIwwpG70SdyY5EHIx6JO0SHckP/rqlrgv+lg3guqWvWqHVVUdV8fx+eC5OF/NYX6r r/YNDr/wRx/JqGC8f+3r1ivx/Wk+PT/1t31aTOH36v1aSunSd9r/p0E9PT9NJMKg9PTpBv16 X14X/1Detf8ddquvX//4XC/gv+v/w+S0J6/Qi/JgZ0D///H54Lxv7/gv/8eqviFr9/od66Jz 7H61fbf37H60m8MKn0tf69SWa6S6JDekRYrJ6a5CTrr/0v//4XX9Lr//ww7r//cL///4LyDA ///MwT//f/Oof+P+P+Lg/+vX6+Hv+9j3X60v1QVdf6/L/1ry9PX9cut78mErJh+Svojj+iOP /Xv5oKv//nU3XkPV//9f//8L//9fhf//v9g//4//YOteODj+q/XXqq2qVeqpVZ911md+ic9a 1menf/XnjI5pegv+F/et/4eTn/9Epv/kr8mE//JB9Ed+TD//9f/ycHOP9f///ww//9L/Yar+ wf/21XX1/r7X/011tOqVL610Gv9nD1s8f9L0v/9v7pL5c21bv/r+9LW/9Lf4X/+t+iV//8X+ 0Rx/kwi+TD/JjH//X/hh/+GH667CXXtr9rq2l2F20v8Kv7qv2FRN3+36WraHr2r/r9r3/31/ /37a0u547//PHaWu2eO17p/r1X/p1o8F//8/deCg//8mH/w/vyadya0q+xWulHB0xXxw2NA4 9ditYaV/8UucPXjimGlDWwvr92F+1SbC/2l3/er/aVr2v9r2v69q67ra+v/9nCfq67Xz79tD P32mQ2H1+/v/KAv+D/rpqv/2vav2v6+/9dpJvY96jYkh8exa8OL9j4r4ZHB1f+QXgVfIZ4Gx bsb6UVsccNe1teGrH6//t1Vq2mt1tp/2ne+eNP/3Wzh/+Rz/8hsPxara6qmRB7WwqoMKndhV VNe0l1VU1XyMftUGmnff9/fa+yOHr//9r6/+qj2KY4OK+L+Hrx7HEcfDST4YRGO1+01bW1+0 3v/7kx+vZwP544iIiIiIiIiIMEDhk9EGEIiDCEXERERDCEXcRDCKuDCDCaDIy5HFhC7IsWmg yT6DTTuwt2v5Me/hhMiD8NX9bVN7Xhp9/b/fpkEf8fsVH7EkOKjY/jiv/ta/bRGO1hrERERE cREREREREREREREREREREREQYRBwiGCcUoQgwoQZHChBhB3aD7Io/a6fYTQaa6w1W019O1+7 XH7EbHxUbHxEfkyontaN8RERM4REGCEMEGEGRhhCGE7TQYTWGEwmE+001/shx/hppqk3Xw8R EREREREREGEGTGiRCEMm6hNMJpraaa1r9qIiIiIiIiJRENxbS+KEZblL/35ZA8PCrYUhBqkI iIyggRBfCDCC6iZoeTluju2bZQZ2EjqyMjurE7Sy92rYTUVTN2mqYTOyQzspM5mzBBniOxAy EZFRTqZKgYMAQfEM4tA3e7Sfu8Lf/6eEHhBqppaFgg4ZDMwC5wGDqC5CGXM7EjNbPGZy6k/c nR1f7XX/66emqQX7+4d/qCBpkoMuZcztWZVGSGTAQ00/vur9Y4444+iXdEY7WTI8hnHSI4f2 3f6Sbar9m5UGE0ynFIN/f0jMrKciGamjId//6TfCdf5IuTOEH+T9yc3J+8ft2v8LYTsHCDT/ /gg8IM4CIMEDOAoI4h4Q1BTjI4p8OdQh8U8CHwQw0GXZ4U/FxnxCQzq5BKiLZDpyIclZGYIt ZEOR0IsyNBPCY8+KUDJyJy8jlT58iYZDlcL/6V/h98P6SJXsX/9EV3g6r//tsJp4Tiwg04tU wg01VDCDQhhOzZrZswg4YQZsKEDIZlwwgwgwmEGbChDBM4DhAwgZQZszjLmEHEP8EGbM8YRC eRNE6lOIEDQkEoRavv/7+fLOp/Vv+PSCDdDJDtfrqkn99+tqmna+n3/ena0vpppp63phe0I7 SHT9MIPGTHoNUGEGvY/6+4IPLmCDLmeMuZ0CnA5mHS3sl7zURORDM4/4T6QdfpWEuTjolDkc QwkSjJWSgjeiUOShyUUSfJxknslFEnWGSfJPkbtEnevI38jHyN8k7gkRjvkb0SeiT0RjtEY+ kSHojHdrJDu+THJD/pP1Wi5Dpvp/f/rqn6F+mgwu/ZoaZsyOXggYQZwG5wPkcjxmbOM4ZdoS D6Xs4ISYygqsJeOP2um6foN109VT706TpN70/Wk3T01dpU+gmKenhUG+m6em4T03JYnQTyUU SsUG3/DCkr/J3+ThyUNCHojeGCDJwRw0Sj7D/X//X71xV7X11CdoP1Tvi0msJnDOGEGEHivq uxb/9L9+xHS1farr3v6fexf6+mWOun6f+nVjYp9Xd6fafVJ+v9/2km76f66bkCKWQ8/pOEtU Sh+iNyQ9KkSjI3ck9Kt9f7tP39VvHTXTCaX6guD1evj6+DC/+O/r//8P/9R8V0vrHooMoO6r FfonP7//x/xp5Fd9X++/sP44qKp/hMXjT70+v/volFEoyNyK+RXfdP8m5JyK9eSd/JD7yOMl z8nUTvsP///2GU4f66r///9g9P//NQXi/zUE/f3Bf4u//+wvyJwMEcfT6v9aVvhh/Va3+zx2 unX0u7r+npumnhPut3XUJ/Sf0m0StxD/7ewfX//7BhX/X/r//2GxH/+F/8F//zgJ/v//5wP8 OI6b//45MvKcJ8KFC3/F0hX6fVt1X9If6/////a/2FT//bwb///8G1/+///X8MORB1+/hVr3 X//C/1Ef/4Xww93//+sH+TrJ3gq//KsL/6X//pP/33Tqv1+P9ilyK7/7eD//yen8Nojv///9 f/g3//38mE+iIP///+SBr/sodL4br//+vf/bk9f9MYX/wl8V///vuvH/9AvsHHCbv+3nGH21 v7/zEDwv7ts8E/v/f8H//P3olf/0SznxD9rfoln8FZFH/7p6I7+DEmD///JqOZm/+3//QWv9 Bcb/+//xXX++cBPYfX//T1/9zx/6fr7/a+/f6+Rz2v/Q+vbPP+l00Lr1pf1//+4XqXYfXdf+ /v/29v/5K//pb////7H/5IsL7B+//b7XtL+1/79ftbX+1/vrv2u+1rXu/9bkx9r3/92cPf+7 S9b02zhdf/7nj//+/X7PHpd/6XIg6X8/f/pbyIP7+0Ha+Hkxy4C//t7FUx/bH/xVhfY2wiN2 EvbT72wl9pf+2vavYX+1bCw0SHa7a4X201qv9hq+uuiQ/bXtK/7VPbX/fuv1fX7XS//tC1X/ /r//kr+ThxH//tvtfDr/dj/jj+Pjj9j6/iSH8exX7FxTFMVscfxJuKf4fsVxxsVFRmz2P/tZ AimGl/36/fWvtr0tf7//r1/+3XX5HNv6vW+wkmq8Nf7T+0wmF704a9p/9r32v99r39p9+Pa3 d3a+qj2Kh7H/t7H7FOeNtfj5BfL+vaaX9+7X/2F9dbkh2cO14iIuDMeGCEQ4YIREQwTIwMkX QNQQhkhwnZIdMLaYTCaprDVOyK+g19MiDoMIMJpoO/tMLrfYVO7TTXtb7Xtf77X/xfva1tP7 Ek4/4rrf72wlWra9atpHK9jiIiIiIiIiIiIiIiIiIiIiIiIiIiIiJPCIhligQskGTDBBggwh EMIWSHiGE+GF/+14YVb1u//vtNf/9cexXHGxsUxp90hEREREREREREREQwQiGFuyMCIx1tJN NV7Caa+t2va2t3a2lrdCPiItjiIiIYQYIRGCGhYTTtBhO7tBpp+2qSXQjJKIiIiLMnPUCBgg whHpLuuoiIjDtBKrS0ojQt+CyhnRkLGd3EWHT11TTCk8YMlQa4IGeMhmYBc4DB1DBUGXMRFp hf11T1u4fiPagk+Qzj0Rw/u78tdbtDXyRcmcJv5P3Jzclzw0d0h/X6vvvh6D41kP5uIqci55 BKEdXp/3/zN51lw0GEGEGgYQhoH+Ov/4IHlzBEKOT4mmCq/T8J/f//p+h+RR9Ik7kh7sijuS H9sHvrr6a6a6b6dIOGCYUldINyBFMh6f9dUSj8k+tP41f7070GHrFRUVt+k2uvh7/6V+w+qr r+igv/Bpf1xokXmsL9QUJJ2vevewf//2D9ycApO8ijgv/1/g3//+H/HYcIfvWK/hv/+SB6Mz b/3r1/9YO3//9/+3v+77XLt9fvc/P9f7fa/njrf33/9prtr//f374rhhWwl3XYVkPphr/t3p ew1z9rio+PYqQz/Yr/b2P4qk9bTC32va/72umn5qMQaDCaZIfCDCrDC2vemE1tfERERERERE RERERofWCVdWZMEg//mSUC8FoKlShAqVKgqCmVgsQgvha1kYEvXS6XS6XSyGg+69drkh/Vtf r20Qcf2P9ZJQyiGZSGdghkMztDK2ZQZCmdpzOx46Xrvv1Ik/TwqDIszpEbZgzsWMwZQZWDK2 zsSuH36/X/9VX1MPIUeRKOjThnZMyIMuXrJmZmQj/7tf6/uv4VdfyuHHZz7X/34j4/+ONf/+ Fs7GP19FzNZFIz7PGQNnQyg8vZJP/1///38el7XxDNmEDJBlwbhAzZHiBAwQM2FiDU2EOrPG XBz4IcCHAINhMwMjmXBzwISGcEOgIRxD4Q+HPCGsU8z7kPWRTkWGgzw1yOROMiBmgyQMnfmo iGaeXO//x+196+g/TTTvQd9qE7Qel2ug4wmmEwg7WGbMIMIWmEGhEMIMIMIM2GAQzAYI5hBn ARBxDPBUGEHIP5EmRJkXQ3G4uCHORpyM5Igl/Opk5mqJB/+u9PjdJNU71X1tJPS9dbVbte9N dO00GnarhNNbTWLQYTCBoOHcMEGEGEDCB5geXMEDCBnAcIGcCHwhrCHxkdmIjkbGUCpnhkuz xnQyIiT/wvkceTvyOyVkcO+SfJOJKMjfydv5HDRGPRKMjwJEb4rkcOSeqI3cjHIr5J2iT0Sh ok//kY7khyMeGkRjuRByKO0RjvXX07fT7Tv1XVNMJ6XphOwmmmE0OLCBhBphBnQKCBggZczA IbCmBDQQ8ECDNidr6f2uqp+km0g09N6T/XTpN109daT9PTvT7ST0/yOHoJ0g8KFThhQnhB0S gSduRxknsm4LkoyOLCkcOSiGEGTgivRG9Enok7e+Ru5GO9EY79L1vTTTVULT04hp92gwg0Ha D7//Y9dW609BlYv/b+np6fwa696/Gq2tLq8ML6fp660n60m0nenSf/enqnp66em6dIN/SToJ tEowg6JW4r5JxJRkoyUZKHJxknojHyLZJ8jHenIQehp0mmnSfa+vg/0P/xEFp3kR/+l2vitd e+wf49PvBi/+sY31f/5Od/v+lf9YNf112NPa9ddCldPC9BMmOE3ukxT7pNwnpJtBOGFJRkrJ W5KMivkeE4yUZKLojd9pv/YP+rr86B/4//43z4e//4fWfC/Gwf18V+/8dfXX/vX+IX/V4fv7 +8Pfv/Jz6umd14hrXqnpvp6p0naeknp6dhU/r79h/7r+F////wv/+wf4L+w1/5Bgf//////X 7fnA//7Bx+l/sHER1/H+PcGK0+le+rapdFB1f2k0Gvp//+Df9R/r///163/9g33r+GH//1/9 f1///f+F//Yfx/7D7//44MjAv8RH11F+r0r4iulfaX/B/5Otfn+Sv/Jg//yenRHGTHf/4N/o jv8mBf/kw///Jg/////+v/WGHxr+GHV//+wwX////681BePEfXl2H/b/0K///b/4Vf/rmMP/ C/w7/9tnnfr/5+/////0R3+vweTCEQf/huRaEuKHX/If/0Da//91//4L//7/88fa3raS2cLX /s8f/t/34Qf/q2nnzJzf7Xc8fH3/2edoX/f+2vr9f+3l4H+n/B4LEZMd/giLprkxDRFf/JBk wn+RUf/9f//a/w1adJtVtdv/7Vtf12/21//19tf1/vtd0vvTfX3X///pf+1T7PHX+pOb5+c/ bf6f54IdMPC7+vv4L/79EIP5PYt/8f7HxxJjjj4pj9jsJfF/+x7Ffw1YawwlDCxw0tsK2ERj +Gv7DWGiQ7X7X+0v/tf/SvdX/v+0Haf/anj+88YTevXbPHn71288E0vXPhPu1/tftU091tf7 Hw/b///Y4pjY+K4qOHBscP2KYqK+Ph7H7fx3fsdhYYS/2wlDVtJtdv27X201tdW177Qe3+eO /9+0l3PHHf2v2naYTIg+mmn9oNdkcMb/h2muvdphP7TTewo93a99va+/eHH0xse18bHHH/xJ uK+JIcbFWFY+wrYS7S7VtbXtJtNe+IiJmxESQxBhA0GhMzEGgyQ0TDCFoMksneIYQiIZGQSd BhNBkZAWGgwndp2mE0Gnw9e01x07vtMJpr9ppprb9p/aa2P2KjhsbTFRxWx2mu2FiIiIiIiI lSY4iIiIjiIiIiJCIREGYvEGCEQyZckHZIGgwgwhaaEMJhBoMLb9phbtNBrD7tWwlaZBB79M STjg4rDSxEREREREREREREQZgwhEGEGEwgyPQw8NBhBp2ncMLrDTT7WwuIiIifY4iIiIgwhR IcIQwgwmSRDVjBYajiIiI2ttLhhVHxFrlOZkpkGF0ynGQsiXIpYwgztyMDIsR0IpzFql6qqr rY0Fr19Lv0vet+ul9CgSQ13SMx5HI0GSC8jmSCopzyLevwg4sIMEDowNCGCDPEbGUAQCBmwc 8D5gjgQ+EkE6bCOfKknaaqFtO1UJpp0oTCDQenr01TT609Lu/076T+kiKPkQdrcVpsVS9+q3 p2vrrkbtEb6REHaIsaknCkoyOKIg9eRR8jfIo9URX9VSYVUk+woVP7XQYX9P0k4a6frx1jXp JD107S4hCnr+hFUuq/0vHr/150ByOPr1yGD/xr/r+uuvC/6XQX1X6/1fWq0klSr9L1X1XpZI jpr6fyK///RFdX8j09suP7N9lxoij/tJNeEqa2lS5gcLVfX6r4QPWrtdV/9LX79f3NnRwrxX TGx/FRp6UccV7HHFJRevfXrdJpEUf/Srtfuv2FWwmqvaSbr6rqtLqvhqmgwgwq5IcIMKF+xU KthPVBhJfEREREROkIiIMuZG4UlCEQYQMsYEIMLG4jjiIiKW9UuuvrQUf4iP//////8ioa3/ +SSf//////JgM5dlkLT+hZKSI4hKDO+ytmfMixnMi8TgwXAgwZBskRmGgjhnPBCuSH/i8J/h ME/UwaYJxohjZWaVztIZCjK0Z2iOBg8BB0ZDjuZkKBPhnsnBY+9f9f/XTC5IPJQfw0Hdw+DJ SZWokv8ceTm/0g/cnoS0/nUzM0S7//93/DypHDQZXeI6/1t3+P9P9/Tf//yX5OfFqTx5Fv0o /8g/kJqnNhDQTOBDgUuEOMjipnQQ4yOKZh0jgzMIEGYFX//9zqKTmcGS4ycspzJDPEQzJBEh njIb7MzKiPRIf/7eHxwfSxr/2g/TQeE9OLTCDiGFwgdmZ4QcmO/rpEx3+ITNhQgzqCBBhAzQ EOBAgZsEBBmwoQMENBggzoCAgYIhbmyNhAg5BJkSshMIJQi4XMuyJUt/yrI0IhkRQid7f6/+ 1ttNDuk71te0vtL/9L+09NNPvCdpxaqnFp6oNCGEGg7CDTVPr/JBggwQZwHOBTZlwcIghFzm RyJBZmRPl8IGEzGUkkSvJ7/yOKJX+TtolFEoyVkoyKPDUjfyQ/RGPkY/Y9v/v/ZEEOR2RjuR j06vkh9ojHcgQO1dPTwkrIg9VtN9P1/007T7X0IZ4PmAQwBhNBmwpwHzYQwFPBwiF4hbIYss ckGQQci+QsE/LQQ9CPa3/T03xT77pU8J4SC5K6TpQm6HZNyd/kMWQx39vkCOByd6hBug2iVs MKRvkrCDcjhwnkdoPJPYKShyUEcZO8QkSuGpHDkock7kUdyT7VEod2uvojHEkO7XwvaafchR 36d1aaaafFxadrYQP/X/6TO8MF4frx6en1f+wwlvtP0v2QfS+k9dP0G6p6feoV0+l9e/TdVp PQenSb6Sb9KP4TCDyOMlHkcZKO6I4aI36JRggQknhhaIx3Io9aRIdyQ9VkUdp2m/af/0L4O6 HFaFf//6/4Y7//t+Div///r+PSuk/T14a6/p6bDXT079PxVert0+/XT/CeE/Twgwnfp4TfJW gdINyUZO3QeTjJQRR8lHStEbv//yxx+eC5OF/NQX96/9g0LhV+h8krZqC1H1/Xx+C8f/fWIL CQv+MQtf6/1C+ic+ux6/49Rx8P/Tf9VbT59K7XtcJ6e+SvCf//r+C2C/hP/X/2D5PQnr/6Bs L///9ZsE///zwe//Ogf/b4+FC/i/YP9X4itaFfSev9x7Gv7Gnx/qN//yQ57XyTluuldf1//v 8N/f6fmucL////rf/1+Fv/wv/dfJVE8f/8H/+iY/PBcnC6//xmYjB/XB64V0ur//iP0I/JX5 K/6JOcf/1/4Nom5b//khy3+m68mdf//JWvREH8m6//fW5IdfyCa/+Pqtv+vDD/r+QYH4Lgv/ /5sEh+uwf54O37H/96Xs8Il9f9B/1Xr8xA+N/9UN/fJZ8f//xvRLPj//6JZkx+P8mDJOU6/2 pNQ/b/kuXg/xr8F66///hQw/8MP8L/4/88apWcN1pev///v/T1fp/V//Xz5/r2vnn+vZ53/9 9Ltv/0K///v+CQ+D/JDv+TDn7kr3Ig/f/7k4KcJEIPBv/Df6x9f+1sJOt9qthf9fbXdf7qr/ +v21pdtfv+t71/dN1211//PH/Zwu7Stezz/v7TPH5HNv/9btDS9Av7X/xGSyD/4P9oixrkJI f/Y2ONjYvj+4/jSiv7C7/yC7++QzwGErXhr7aXa9raWvDW17X/Xbhr+32t/u697++v//a6Tn jfpel9/r8+6Uub3+XYf+C31/7UJqQQf99w399/hkcHX/9X9imPYr44cexUbHsUxwcV/H2xw7 4442KqGFr25DD4YQa/DS+m1wla2tr6/aW/Vp6/rff9a/Juzx/fahEdNNbtP7b++012Rw9X// +19e1db1e1u1++7Ue03TWx/3exJOK9j/jimKYkh7Htr7H/tpWtq2v2v+rVrayVI2iOi6I+R0 bRtEdF0VEIiGCKtEdAkINAwhDJjlHQZGBWStCIZIuCEXDCDmpBoQ0ZhQwmEa0LhoMij3DVOG nhbCpkQe04fa2t9tqthNVTTX7fu/1+9dd8XD69+ONjivj/j47CxERERERsRERERERERERERE RERERERERk3QkhycBAwhEGCBll4MIREGTAggyeqBoMlaBlDoGg4YQcGg7u7CDCeg17hkh8Ij oNBrfeNr7w09Ne1+9UxVcRxEREREREREREREREREREREvDiIYIjoMIQyYQkQTIiO7CZFeGg0 1sLa3emrV8NIREREWxBhAwhBn1KcIRBghEWSHKIkuQYUftcRERERUR1xt19rMioSIhpuoME/ JmyIMhZkgyZmUGQUyLs7BWStmtnAQzDBrjozv4qYQ7LYRYW71zBrZA5MpUeaqqDQaqmEDJWy pyZJCO6GNa319PVe+7X7VUlb44tULS6rfolzk58RT1ff441/6VB1DfJzfitzoMmCo+MjCJyJ B5UEQSzW/+q/r967eEGbI2GhwgzZlwcIGEMkGXBCgzjOGRwai4IfDkgzAIhIPMiVkLAhmApm EkH8hJ+v8hs4IfFPsuM+IcZhkcZmMvbnxScVTgpIIwKp0FJBKSCJBE5XT09PtNVT01009NMI NNNNO011/pUwg4sJ8WhfYTCeEDNhQg0DI7CZwHRMeeBDgIEGbZw7ptyQ5FHqiTv0Rj17v5Bc fr22q0qGmv9a4TT7W1S0wnrFoaf92E7V6I7ulTfT8lbQTcnGpHF+pLLJPkcNEb+RxDJjkWMl DknhkbhSdtEoIO7k7aJO11UJfElGRvRO3oivRJ16Ix3JP5KHIxynJD2RB6I3eloij1kh22gv XFb9P77pO9Ppr9dPCf33dBPT1/TCdJ96pKPpE+CbQXvwtJ/QQdBBukE6CFBA7BaCeSjT08ji kH/029eP/Tf/////1rXtsF+7qzD/0vjpV//r+v9+t/rrp0tbrrSbYq8bXeaCdce6/fVf///X qK1hpca1in4UFWkH64YaqteutIOo9D6X/9dddP+uzYJ//fv//X/X+hnUJ718fpSbhfhj9gx+ qrpCMc8HycKul1pf/G11rrX//+I/////wW8F//kUNHz61rYar+q9AlR8Mf66GlVa/khytX+i IP/kw/X/9etf1fS+v8gwP0oLb1rVIN9LX9aqv/Veq/9xTv0Sz//+1f9///yQMiD/RGP/kvBf 1/8nMLwb//SkkVRHfknOPqtfv9KTHLR+fa/VL/mfa/yKP//e//3k8/CD2eCeP67aXnxB8u3r 7SrrPvgvQQ+v6onP/4p+00SHdr//YQf/7/f9r//Zw//3Xc8bf6X9qfOu2P/ULnjdD6rSX19L +vPGvbS29K7C/tpNr/1X37a///r+t/far7f6JDsKtel2ulraJD8Kuv6X+l9aaa40uPj/jj/a /vrj/YfsMLYT+wthdhhbWv5BcfDW0tYYRIfpMcVYW0krXtfbSSpL0lVtKTfRs7STFU/7Tv/+ x+/8exUcOGRwwxJD+Nj/bimKivY/+ExTHx7HD49f/4pL+GFVO/0Gn2va+nw//tO7G1WGmuq5 Bce017VeHpqv/2vX/2lb+DKUFDkghRYVskLFYiIZMIER0GSHKuHZKCQ5RAQKIhgiOgyMdBhM ITWjoRHMWgYQYQhhCIsodMEwgwmgyKPoMijp6DCqoT1VbCBYTrxGhESraiIiIiIiIiIiIiIi IiQKEHERERERERERERERERodw6TSrthbVdRTFUVT7RN7ml4gyzeaDSXEREf////////////+ ZhoLxZHMySH0zsEipxsztWZcyQZgzcdnMEwTNRkMyYM2DnwXOpkGKd1H8Kv/r+aP9Bw9Tujs 7NYqI7LxWzJBlzO+MrTIsytnOpev/roJJf4f64TCp3+qZU7JmZAzLmSDMhdkh6/HHH4KTD48 l2T9vJ7Itf//hf71slMYMlJ//+//w3hsfH/xH///C/5BJkUYRPIvFjkXyLgZgQjx9nxYZDFP MjjJYLkM9TETAygZoHNZlBEN5mRIM+ZsicZIIoI0Igy/I5Gs//JN5nEX/9/8e///2EGEwg4t BpoXYQsjmEGhDIgz5hB5cwhmA0HjBBmAwEiQCBAzgZwQZwGsEGbBwQYQMEGEDCDiGbMED6fc kMuDggYRCYQUDgzwUIMuzwhwHOgQIM2ECDNhD0RxSOIfEPMjihBnQQ5FxT4JnQZmMhkaDIwi dkGFMzIZ54ik/9f/9ppp2n+uvap+qqnrYT07TtNNNPvT9aVbwmhacYTtB4TtBoRYTQtQnFrl zBBhAzYOEGbMuDhEEDggYIHhAzgQuFCBkdnhDwIahZBJkJfkEOSEE9CRgkQXMmJ//yOMnbkn ck+Ru5N2XOSvybhckO5FHb1JP9ZIcij9Eb5FHa3JP7v7RGO1a//r+O9O0/09e7I4idr6adp9 qqaenoPtNMIOGE6psIGEQTgzBH2CDOAXPhDMPIJBPydBIJMiazwpGx+rSdJim6dJ+vSZIdaQ eg96T/JRdhWlTtB5KMlFJuSwEiUZLCUEoolbkraJRhPJQwwQYUlb5OPrYS5HBKASJRZKyUEb 5O4ZOMlGRw0TiGCkohgkRu5G5G9EocjiwpJ8jeiMf8k9EoyMfJv5GPVNNCl/0Hr/2moQbqna YXtUGg8IMuZszZhB+n+mZ09dj/7X1derX6X77XXXvT1031u0+9MU9P/+1xUV0/T1tPv9XXv0 /CD1TpN7uk9PT+kxT0HSfoNolGSjJRk7yduSslcMFolGRw5OHI3aJQ/kY7RJ2venaaw39dP7 T/94/7D/1H1et6H+n+6HrV6bpv966xWtSc20r+vseq/9vrx+knp7HH+97p68NddP9MsdN12P 9PWgnV96r+m96qnp/p0nk7ydt1k8yVkcUStyT5G+6DJORu0Sh8k++pIf9JD/+D////z4T/98 pxPr4j9f/BfqPf/4PqF16Wl+F/vWHr/X6/ivr/k5/31+rW3RQYrj/9djTtf09Olr8U3VPT09 PrVOk+k7pqk3///YP///7UF//0jqCJ////5wE///9g+SqJ3///zwf992DzMLof8f5rCf/8X2 wfvvXH4XC+rvw/Fb+9ven5Mf/+r1bde9Xtf+wvxIPp/oG////el//jX//6/8Jf//+w+tv/+/ wv/7DwX//8F+v/9g///88HzQP//IXOeC97x/9rH1oRXvr174/dNj+Q4P/g3///8aI4//uiOP /yF0//6Ig/+TB//wf9vv//1/XwYevX/+v7/17D/r/8Lgv+uw/Bf//3///f/jz4S/g/yQ/PBP zDD/+eCf+8L+/6QX/8mP+1/4L/P3r/4N/v///oln/8H0R35IP8mH9Ecf69ZPTg///Jh9dL/r Bv1///6//+K/8FYjYf/PH3+v9q67r9f+vv/t+ln37//X7aGfrr/yOYf+7/b/+v+vKIP17/3/ C/bX88J0Df1a/5+tEs8jj/vg/ojv/yZf/HJB/khyWf//1kQeGD/2raJDtfv/7kx/e/6+//r+ t9r9//p/2g3X/7/2/+0v/X7X0/pfPH/nj/1/v3s8flzf/2/0Ol4X+t5Ig39dev/tV+4/7/yQ OiIP6D/2OKivir2NsLexV5gntP4a906/DWwra/aX/r9okO0rX/20v7/7X/19v+17Xv/df/+1 +1X7r1tdbOFf//vS4V/pf6z7tdf/79a/+Ty+Df9p394fxUPr+o/Y+HxfscVFex/8erHGxXD/ j9W/9j/44fFfHcdsML/DCX9hP219tEhw1+17tjtNtW0rXwv2v2l+v2tq2t7tnj788brf/54/ /MG992mEwt2n3aY2q/f33d33p/a/2/aarj9r96r2v9439qGRwXhsV+xXwcfx/GxXsf7scVEm Pj4uHsfsNdbW+0m1Y21q1/tbTtJ/3X1pq+IiGCBoMIRBgnEMkGEyToMIRDhhMinQhkqJ6ZFd NOGSH0GE04YXT01tMINBraa2vaf/aa/fYXTTu7X07Xv7+017XW7TT7/fXx+x/HHxWxX7Gxx1 fw17Cf2lERERERHERERxEREZM2SjKZYZMMIRBgg4ZMiGEIiGEIhwyQGSVwwg1TsJ9oMmPcMI MJ3p32mtrfrpp2n/2uuPYrjfY6S4iIiIiIiIiIiIiIl4cREQZlZYcQYIRDBCIZHCDQaNZBhB kx4YVBhdbQap32t+mvXDUREREREROkOIiIiDBBkwgVMkDBQmRXtO1o7AxO0kGoiKiIiIiMa2 NtKrXUaxENNAlI0M1sWFwpmDAsLSjQKtSYCAX5DFh5GEbFJBE4zQqDCDzqFCDNg4QYQdPek7 TCDok8NfJPkY9EY7kY+k3BSCcStPQeExCb78OmutWWOn1/j/Q1/6wX+L/y9ZmH/X/4X+v/r/ JJsC/T5K/4Jb/6/0z91/1+7QdtL119tNI27H/F/Em4pbX7+0/YTtNMij9w0wuIiIiIiI/5pG dQkXdZMUJUJhk0hCaEzkMHIXeFhkwMimZexBe1ktcwRtTP/CDThhMpbT1s7Ils7LTJBkaMkG CDPs7UMnCkbFNRkqAgjhnPBT5kNnA5oCEYH+n6D7TX0sL/6oNNU80ehYT1QNA0DIQy5zqY/o llOR25K3/Bf/7p6qq3p/d3/X0m+EHSDfQ1+I+KJc9akyPJTMcmcjh/d3/IZENnzOGaEQI79J 13r//9J9ZMo9UOgg38n7k6OTm8egZwFAQYQMhmXB5Y/6e/2jUKeZHGEHIJhfEUMGbGfiORHi 4yOLIehEwuZdkXUOQSZFLkoI5kQ5EORpyM5MITIJ8SE5mRQeVZ09HxkwZIgv/9f777/CaFr2 v+KJD/sQg0Iaw7CahBxERDhhBpqEGhYQZDBQgwmbBzBFwcIgiAZsKCDMGfCAoIMIZIMuD/hB mzPGCBhESqpCBAQMIOQSZE1+/7/54edC6Ix33+361+2u/pun3f3Ig7TtU71C3p2qpr6Q2n6Y QaJj9PiGg/sf//CDy5ggy5nj8J5HZKCOKJ35KKX9besHJO5HDYUjh8nDDBIjHyVkbkUfI3ol F1RJ28jfJPkGB6JQ0Rvkb+RR3JD5FH0vJj1RGO179f7HkPq30/v//0/Q16T117+/f9eEmQ9Q T0716VdN9NBunp7pIOwqbSDclCem6en6DpPTclhKG/yUaDyceSh/JQ/RO6JR4aJRDBBknI4a JR9g/111T+/7fVdj1pP+vGGD7/p+x0nrrrffq+uva0na/66enqntenStX6f6/3Sb06fqum5A ilkPPeEo8JSUfRKyY+vHX8hKv//3QbSev/YP/rXxXX/fuu/Hq///St616en+vH+xp+Rx7+nS fww/jqOn+u1//sP+L/Q5BE7//+H03/+fC3Uf1H/GfCf170/v/8f/+C/ITh7CdJ///DD+oVLf qPX/8MP9eruTAv/X7D//fwr//++C////2vX//5sE9h+P//FyYORgvwUKFT/v+THOf+G//3KD XOpv//4MP//8LH+tfWvW///vX///hLww///68N/J1E8yWn/v+P3lBfyc338nP///4P/+vyV6 kwnuTB9ZPQiD/e////+TD/+SD/w3JgX///NGH69h1/0xX7/Lm/6X9r33tr/+Xg36//pb///y ef/1tfWP//9tdEsfk5ee/X/kwnX/2///2cL///v31fbXr7/T9uv/9fPv/PHf2eP/X//umtvz 9/9/S6kc39A9v/////1+zz+2l/2v6vrDCVX2tr//ddr//rVp/2n+66/r2truv6toNtf9L//s 4W63/7Z4/v79vuvdNrsf+x/1yC45BggUr7DCTHf/sNdtL//V20v20q+Glhfr2O0u1+1tK1/Y YXwtrat/aWl/2vtr/9tr9/2v+v1b3f9imvh/xXH/+xdMcfFfscX/7x7FNbGxsa+xXGxscVsb H37YSkM87Bgl17fa+2lnjsJpracNVTtfhhV7Cafj9ra/r3droNe7T/1vW17tf7C36a2muPjv iv9umK+N1iIiIiIiIiJGGIiDCDBCIZMDCEMIRERFkYEEGSBhCIhhMjSjj4VBhNNB2EHarDCa ZEHuGg1sJhb4arDX++17VcREREREREqjHkzYSLUBCIYQiIhxDCqgwna2liIiIiKQ7X7HrawS sLqI8f////////////50EKgSCDPECDPjPDNBmYZy4z5GAIPARTVB3p39rvX/++unff/5HfRF zepIH8j5yNgqp3pv9/39+k1en//hj43//9kPTX/+F8P40Rjv+KkCGANh+cD9f9cN/6v/C4Nr 8kPq/65ECvfuh/yN3I+KYEydhtcP9r+3jCe9g+6/7f9X9/138MLwwv3tr32K2PdEc/HtyGdg C+v2+t7tbWxXv3wwsNfu1scMIQYWDLtB2gwmmSdRERERERH///8nByFsi7K1HWIHHAQkCELG ZUFpqmQtpppoM4BB1NTs+bMIGROOwcVsyQZDM7wyFBglbK2ZUhd+v8O9QnpnGq/8NSpvSLfM 6xsyJZ2dnac8mOVBQ7dr/75MdeiN2qr/3rqE1wqnaHnYcbMlRG47NTIZkDZBviLYj48nNydP jiggb/9ghkxysf1Jt/r+uvqQN/ZDaf/99/6//HFvx//9elX9f5HM+ZQIeZwOYBDjNhz4pHkH IJqRdf/mY1PkSDPkYInFU6kQy3szHmZEMjZE5nQspyJBFD8qzKDIZE5kuyRb/r//4/tf+rVB qnaoNC1s2YT//LhgIGEDNhpAmgyOYQZwHw0EGCDCBhAzYIEwgZwHCBggzYOCHkMwgYIGbBwg Zsy4OCIIRbNhDQTOBTgQwECBkdnhDwcIGbFPBCOHI4pBs+zwz7PMkRHI2Kfi5FBGBTQZOMhj /I5E40yJH//4/X3pdb9e9P//1u/Tux104sJ+na+E07T7XdMIPVC+wg0HhBxENNQg1uLCDiGb CoMIGgzgOgwgcQwQYQZoZ4wQZ4zhyD8QsE/J2RAw5BKEVORONoHkcicZIPyd5f/2RwmskO9E Y6kb/VhfJj/XXtpOQIHIg9Eh36ewbojHdLIMD0Rju3XX7TtfX0105Cjv+9PfT+LTi1CDv9Pv Qf2neE+GEGEGmeDEQwgzgYCIY4nMGYCRJYTcg/Qg5BJkTYSKuoQa4T0/JW5KLyV9Q/pSI/kd wwpO8liYT0HDC5O3JXZCzBUHDCRHDkoT0HkrsJEryVuSf6JRk7yOMk75HDkn/JQ5OBolGR2R vDBaJQ5FeGCknyVkUcij9USh/IsEn3Ijkh3JDuSH3vIx3JD31X9N1T9e+0/XQd9rw0Ht+w17 /70/X0GuOK69K+v39L9g+vp9p0m66d96f6Yp6emunSf0E6T78J/+F6T8Jp7qv4JJuRXwSQeg 6CDclcMJhYdIO09SUP5FdyUeJO2wpFdolDRGO+THyN6Ix/Ig+qW/X13rBjr19f/8MaqF/711 j/vWG8fpv+v8MLrSf1Jzb/Hr3/9mePQ/0+/TdVW/v/T09U+O+/Vb9a0/wnp7kx07108J/YKm 6bkrhhWoakocjd8jhojeGEFkcNEoeS9t1B9f/W/+wfCr///NBP/wbwXQ6+P8TAn/9R1yJ/6/ yO7x119W6///VJ//r+7//rDXV0v/hhbr/Tq27/1pPXv1T0/XCfGtJ9P7D////9g7kxyrCk8/ //5wE//KgefD///nUE///4f//EfngtE4X6///267/Q9+OQmDr/xBd+m/rEF62+usVr/r/619 +n/32/xg3////4YfiO3///r/++F/7/1///ww///8Lhf//////6/Yf/+cD3r/+cD3of8ZqCf7 7f7f1df/9dfvDff/r/+H/b///1//KDfXkjr+Tp/X//k8NHw3//wXrhf///+P///DD/X8Lx// hXX/wX/r/9L3/63/j+0D7/f3r/g////96JZ///k8+Prj+iQ///P2I+G//0pMPojjyT/1///f /5N+vQYkh//6Ig/a//X6/wv///H//qv/+skG/r///5HN/2////X/7v19//+gf7/tD8uwf/XX zwSF9B/v///rS/sb+TBxv/4L/X/knKHxUkE/JhCOP+v//////9Xte16/tf+/9v/tf+v219tf Xs4fu2eP//dfezhem/7f+eP/1X3r/X/2/Xc8b/n2RzZMefva/r6uv9Id3/0v/vX9r1///5PY 1HTDS2P/2P/tf//bS+u1+0urX121/tf9ftftEh3X6X9rhJhq2uvrra/3/76399r2hfaf/+tO 66/S1nj/s86XX3br/7r/3X/1x7/+8P9j/b/4/+OHx+xUGRwXhx/sfwcfscgu9jj9j/Y4444v Y72P9iv82dRx7YVNdsIjdhbWtP/X79fte1/bTpf/1/fdbX+/+zx4TTW+7fvH9fv/tf7xte19 v/C93/+n9/+nZBB/3HX//+0/HFccUxXw4fxcHUVH8btr/YW1sLf2vfXa2l96/uscMINA59C0 GmEDMPadoMKnd6aegwn32RR7Ix7CI63DCbI4hHN2F9BrffoP4aYT7C/DwTCYW+7Ix7X7X77t Php9p392/3d39umOH7FRscP2P4fDio/2O74YXiJhnjEREwxcREREREREhoREQyriGUDiIhlE yshoMoeSEIiGU4IRM4Moc45QqUCggYIRDCI6ERDKua8MIMIMIMl0MJkcAnEMIQwiOhDBEdCG ER0IvQYQZJwTtU4YTQYT7fTh/DCf3dhR7Qff2F1b21/vfsVStbSERERERERERERERETONZji IiIiIiIiIiPiIiDClwEINAwQaEQwQOIhlV6DQZIWI4QaDCDJFwTI3hkY6eqet6dqvd4rahYa 2F7S0hxERERHERERERERJ0IgyhNYNAwRCGR0IiyQgkDChJimKFjSXURFRERER7tPQLglVhBk iUJhDV0W4oJERBgi6YVdRERFqaAuSozIdmkSiOzUKYjAUhxW80z0aCjvO7rCpm4ihE4MRmDC ZDM0I+GguGcIGa8iUbMr0M7LTOxMzIrZDZEshx2YHvC/qv/34TCrmQuZBv82zu5NQnDI1GDI Zrk7Kd/+t1/q9SOGq+v2oX/C+vEN/4/J6E9f50OTrQf/xx9r/+C7Z9/paf/p+lf//i+GvD18 IhJkJE2FOBS4U2CIM6BDgc+CZwQ8EQMwL///T2fH5HInIlzOEQyKCNjJxk4yQNTMdnUiGZOR EDIbKDzWZDjrHGVHlH+Pj9wmE9PW0wmg101NAwEGiY//0/waCDCDCBxDCBkMKEDNg5sOEGEG EGbB0GCDCDI5hBnAcIGEGbBwhhAzgQ4CBAzYICBmzCEGRxD4h4EQMuEOgc4FMCGzPmR2cDnx TQOQ82yONPI4zqNT4ygz5my+n6cXenrSf33/rJv+GOn2np3Saadqn6app2oTTi4viwg7VNPT 0NQg1QcQ04hmDCDCBhBmw0v6Ix3yN8kOYcmOUP2CknyMdyQ9USfIx1JjpEn09fT/7De6kY9a RGP+SHaojHdkcT9O1XW0+/u47071TXv9PT/yVumNp6HF5K70+HV/bx2FuvZcf9K/IMcQtYJE bwwsOiOHBQm5FdyWXk7oJ5FewkSuGC0SjIr5Mcp6JXkhyh8jHokOUPkxyh8guPkhyhyMfhk4 ILj0SjJDwycEx28kOCRIdvJj0Rj5IeiQ/kY95FHfJD2kRj7+k6TsLw117T09Okk9fTC7i5DG fq+2Hwn66eknr0EG+qenev9thPj14vCehYxbkoQfHD/JQg9PQP4PJQ8aD/06QboP0HYUJ9BB WwwVNyWEoJR/XRIMVx/xWun66+xp1//9h631113T/2O3Xhhf1/Yj1rqzun36a/30m1/FJ9Xt enp11r9+x6frf8fnguC/gv/7/sGv/63yY5oQN9P+h8f1HBx+ohfV/g1+nofr+v6/6+D+qvrX Xp//+9b///gufBPzqCf9f/BoXJaF1dY/EQb//v6/YPrz4X612DNYX/////+P+Dr93Xrj//r2 D6euv/66/r/rr+GHv/r4P////sP+gX/9hhf///X//v2H/91/+1//Dv//rJh1kQfoiD/0RB// /+G/v+/Opv//IJrkEz+G/9f/w2v//////+G///////DD///XnwiJZ4X+gv///B7X///v/kge ToVH5KaDKHyUwvuSj/+TjRK//////9P4ZQ7/1Y/5JzuC///b//+ufO116/4S/ql/5gw6JT/+ iU/37r+/jf0Jdi9D+r+2vl2Hr/88E////k9Pm8Q9/1/4jr//g36//VtXWl6X+l+/bX/6b/+m /df/88fZw9ezhW9nD/pf/7/9tW9f///s8f6b/2rW3ued//+RzB+6/8VDCUNbXsL/a+2F7X+1 X/9f4aXaX9rtra7fatr/r9pffr9raf///7a/32u/9rdv//91uv/pjYkh7HxfwcfxGxXwZHB6 v+QYHdXyGeBw2OD9j44rYqOP2GRwxD2P44v42JIcV/38P+wl9wwlFcVW2rYWO1/+17X/NvCa a73/f2v3pf/jf2ra/a2v2mv7v/af3pr//j9j+GRwSt344p1+H+xqxX+nEMEGEGCDJAyLkWnZ FPoMhXQYKqwwmg7VbTLddYYTsJ6dhbUJwwgwmn7I5keI5vhgmtr92mv+vf2FW7XsL3af+P2u v/iIiIiIiIiIiDCKMRERERESIxEMrYuTcomUJFJRURDKWifxEhoMuEDBEdCIiGEIskXCDKHC EQ4YKTHBCGER0JogyRATJDggwQaFkY9hNMINBhEdPT01ERHEREREREREREREcREQ0DQOIiIi IM4qhEREfiIiP/f4j////////OzM5oRoYKVVkrMhUTYoiHHdV9SCV6aYUqhmZBEI1lO+gv/3 fvgv//9/4/usm1ljz4yQRsygiDeah+Rz/7S3hBmwQIMEGaggIGEGbM8wgcQz4Q4C5HDBwQzB CQHMxDwQuEPiHwQ4fkdno8zgl+YzwhmKeZHGaClBb04tNB4T0ItP0GqYQaFoNP+01CbrhNMI OIYQZsL9EY701/tP01tZCjtP//T5Md+n6fkx3wnkbkcZO8lDBgkSt8k5OCOKI3yO5oSJRRKM jfJQ5HZOMk+Rw/9Pkof6WiUNEncjHaI3yMddv3prVun6/6em60km6em0E9bpN04/ekk7aX9P Twg8J6H+K19OleP1v0/rT/vt9jT//9N+36TeK6Tf28F+4/wX+v66iP+Oof1+6+v/6wf/XYzg J/750D79/+lvX7B//8celpcbBvx/cL//hf//0v/wwf/7Fb7/w//6IQf9SYOuv//6Uh+/yH6G //5EH8f+DD/+8ln//kr6f/+lJh1+TDYP//8mrx8mI/J6e9L/Z53XX//+l/f5xh/+162mvIbB /v//7puvp/r2vq2cK/Wzhafa++12cL+zzv9zx/ewv8NYa+thf20vq1bW0m/bVtfMHDCW7/7p 2v2v3Y/2KYrjjh/HxILuKjjiuOK/iuoqvior7CX//aa3ePa+npraa/f2traf2PtA7Ir3adhN UyKPZFHTIx1tcsdBpqg0001+GE07T+7VbXEREREREREREQYIRE0jpSbghEM2gIREMIRBhCIh ggwQiGEMRHEREREf/7x/5Zk+P8lyO6FPhoI5nM2YUqpkqMgpk2MzJzKkyJDIYQypk4nwnqS0 9f1ChAzsUkGbBe/8Eu//pp9zqY/VY/3Jhkd17/1/76Qbrk5voPPDIgaZ1F8jkTkSDJgiQeU7 JBEOOGdYhn9cL/+ZmuEDCDCBhBmzPBiIYQZwFy4OEDCGSAQIM4Dc+EOA5w/OBDMIZhzqEBA9 zwhwKRw5oKeCGAiBmxPev6aen9p6pqoTtO/0Gg1T1EJxYQahNQn/9+SfJDupJ/Jj9PdVu7T/ 1VU+rte9P1vsLSbSDgwkn9gpK3JQ5K5oOShyT5FdoleSsk+ShyOG1HJ20SiiT5J4YLRJ8jsj eiUOR2SiGFJO///T1e1/1pf0gnSeE9N1TVPTjpPvTpNv03VN09U9JB/CX/S98f/6enS26/S+ xS6/x96f1f372vr4r/xpeC/9d+lHvxHw+/1tUv/rqtJ6Ffv///nQP//+l+0+we/yZ8ZwL//v /+UBOPgv//hf//0v/2H1/4X6/7//Bf5NqGv/Jg/r//+siU/IMfBv/+l//JD1//X/rr9/JX// r6kw+nLHJ6Qb1/5IMjj9+2n1/+iOPJhP/2z+2vXr/f6X+t5xv/+9d////a6C/++/oP/W/9/0 rOFa+54+3v/88db+vdN/av9fn3//hq6Xrrf2vq2ratra+ra/9+tp3W2Ftfq0vXtfrw9io+LY 77ivkFxxUcUxXHFeYP2Owm2rHwwla8NW17C2wwv/jdrfb9/2n/af/6jjrYpiuOK2OHFfa9pr 3jaYX7T0Gtpr/w7u1hprprtsjgnxEQyYQEIZPUsgmoCERDCDJVBBhCGEGCERaFgmRYhoNbCY T0GnDI4uGnqIiIiIyTKrJtUEf/X/a4j//80DB4zuYIWjCw9AyTiyFJmZGZlOYU6Gd1CE4pOZ sU6xoZgQnGQ2Zg++1/10GEHhMLhMIO08n3tbT+Fp6SfVpqvDfJzf68LRJ6JO+SHqqIx2iMeF fv4ffrroPT0gm14QeE2prP+cCGYh8Ts4EgzYh/1zg9M4PI5ECM4fa67rS3uqX8JhBhPdMKg0 H3hBxEOIZszxlwoRBBF/1160tUv96fp67eknf+oq6+3qP8mPXrojeiMdyUPtEb2kRjv5Mfr3 8dX1WvW2OlwS4T09P9OwoQcdK+ShybknJw5HD+R2SerFL60v9Y99JpK92vS/9J99qv6SdJr9 VS/XWPQ7vj+23WlX9jv9VqE/0Rj9f6ws+E4+gXj1b+/g6/90kRu6+ukv/J1QX1U2Cf/7+wf/ +lTa8Vql+l9f9f//9v//Sp/iD0v/6I48mNdEQfybIKimK11Bv//CC//S0tfoLz4msnn//wb/ /WvSbRMfSC/r/tpnnpf59/1uRzD36/pf+DSpX//C3Jj09de02nbX79f21S/8nPSf/7HYWKMH FWFthhIwfVr7aw0rC9qbchiGklYS6RBeGl/7Yp7qLhsd+xXxUbHsaabHsetsel92mF07te7X tQvf2tr+viIZLQIGEGinYZK04YQtBoNNUGmEGnDvTVNPVBqniI4iIiIiIiIiej5tCIiIiIjV NJdQ14sdWhhhR/ABABAAGADABgAwAYAMCmVuZHN0cmVhbQplbmRvYmoKMTQgMCBvYmoKMzUz MzkKZW5kb2JqCjE1IDAgb2JqCjw8L1R5cGUgL1hPYmplY3QKL1N1YnR5cGUgL0ltYWdlCi9O YW1lIC9USTFPYmo1Ci9GaWx0ZXIgL0NDSVRURmF4RGVjb2RlCi9EZWNvZGVQYXJtcyA8PC9L IC0xIC9Db2x1bW5zIDU1MiAvUm93cyAxNjg+Pg0KL1dpZHRoIDU1MgovSGVpZ2h0IDE2OAov Qml0c1BlckNvbXBvbmVudCAxCi9MZW5ndGggMTYgMCBSCi9JbWFnZU1hc2sgdHJ1ZQo+Pg0K c3RyZWFtDQr5bhVCdaWqXrK6Qq/1r6/C666r/XpL//4dVWbL//0v//6Xrvfv/Va1/9f9fXdf 6+v/r30uSoq/b91VYXWv+SoutYT/a/7pen9/hKv/X/X9deuq+RR/Uij/V+v/6r+9Kvul+v+v 3pWtJJ/j+pKD3+l3859en8LSpf6/9SKX19KtB3W7rdV+FrrVP9Exa//8IP11T/aa1952WVaD 9Klr/XW/6XvpX6QWRR6//0vS0Rj/9r/+v//60uv9d6r06Wv9aqv+2//f6ke8P9eRjs7f9esU n97+gf/3/r1ynMFpJKu0v9L6f9dXv7X/Ixr/rdHJf/Tap6pLrhd/Xq+n/rTXiCX/W7X0v6r6 +qp1rWrqJF/3WlMP7+vroh4IH/9379d9VBJNf+N9pV+l1r6+l430lwtJhPuv/ha66XTqnXqt Pr1ql/9fRFHC1rXpURXf//w612vulr66VOn9LpUutLr/4NO+l+qtr/+RxyQPa/60nW//j69P Tr9pev//XX9LD/+/9L60umwl11eQcj4I49VVfXS/1yQ/9ev/oN1/39fY/S4VBLX164P+Gl/C 9LX9f68LXX+2v+t93oEcdevptPXX9fX9f0sK3/cO9fWhVdbW1pfwv3r660Fa213X74f/6/BL Xrv4I48K+lXqH+0v72ev6f/XrS/zjrrQ2PXSS+ygXweuP7zv18l5eq+0cenX/xr10Gkl/WNf 1wXXfwmvfSpNWl1vvv9NBeltYJOlbra/fuGqSXb4I4+//tpOfn+4S9Ov7hLrvhW4/TBUutLH sJdf1f3CI3DCVOurpNr61/r1DFeFwlZmLr198KT3e/9pathBf1inCt9MJdLXQT1bS69e1DCq 90tW0v3u4fcJBr6wlfa9XWrBeGpqzaS1jnHhJtfX+uxQiulTEboLr7t/94em0v2Eq6w0lrCD WF2r7VrbS6UKm1vV++7CSfaahpdXVqPBkt4tINMJtBfug0+K2oi2u0tR7p1dAiOrq3tOugmM d1a+lawravTvTYSaugo2rWNhb2mtJprYS2nphBhWKaKUrBJoGclcNC2oYQ6abhFYVpp8YYIQ 7Csruym9BEMMY/ABABAAGADABgAwAYAMCmVuZHN0cmVhbQplbmRvYmoKMTYgMCBvYmoKODI2 CmVuZG9iagoxNyAwIG9iago8PC9UeXBlIC9YT2JqZWN0Ci9TdWJ0eXBlIC9JbWFnZQovTmFt ZSAvVEkxT2JqNgovRmlsdGVyIC9DQ0lUVEZheERlY29kZQovRGVjb2RlUGFybXMgPDwvSyAt MSAvQ29sdW1ucyAyNCAvUm93cyAyMD4+DQovV2lkdGggMjQKL0hlaWdodCAyMAovQml0c1Bl ckNvbXBvbmVudCAxCi9MZW5ndGggMTggMCBSCi9JbWFnZU1hc2sgdHJ1ZQo+Pg0Kc3RyZWFt DQr80RdQhdB1/1atR+ACACAAGADABgAwAYAMCmVuZHN0cmVhbQplbmRvYmoKMTggMCBvYmoK MjUKZW5kb2JqCjE5IDAgb2JqCjw8L1R5cGUgL1hPYmplY3QKL1N1YnR5cGUgL0ltYWdlCi9O YW1lIC9USTFPYmo3Ci9GaWx0ZXIgL0NDSVRURmF4RGVjb2RlCi9EZWNvZGVQYXJtcyA8PC9L IC0xIC9Db2x1bW5zIDI0IC9Sb3dzIDEyPj4NCi9XaWR0aCAyNAovSGVpZ2h0IDEyCi9CaXRz UGVyQ29tcG9uZW50IDEKL0xlbmd0aCAyMCAwIFIKL0ltYWdlTWFzayB0cnVlCj4+DQpzdHJl YW0NCvk7vDx8AEAEABgAwAYAMAGADAplbmRzdHJlYW0KZW5kb2JqCjIwIDAgb2JqCjE4CmVu ZG9iagoyMSAwIG9iago8PC9UeXBlIC9YT2JqZWN0Ci9TdWJ0eXBlIC9JbWFnZQovTmFtZSAv VEkxT2JqOAovRmlsdGVyIC9DQ0lUVEZheERlY29kZQovRGVjb2RlUGFybXMgPDwvSyAtMSAv Q29sdW1ucyA1MDQgL1Jvd3MgMzI+Pg0KL1dpZHRoIDUwNAovSGVpZ2h0IDMyCi9CaXRzUGVy Q29tcG9uZW50IDEKL0xlbmd0aCAyMiAwIFIKL0ltYWdlTWFzayB0cnVlCj4+DQpzdHJlYW0N CvNjMBg8DB1IwM+RgGDMKaBg+EOCEiJwzlzJxCCi+HD7XCDQemCDVMEGfFPECDOBoPimYaCO BBcIcCGAIMDPjI4aPf/pw//T7T9bvu4/336f0n6d6en+vf7v/Tv97T6v3r/ryXZKfvktCPsj /apkgeiJbvkcQyoI3KjkMclp5G4K5J//+/V//rp76cXEU676HzMf//+m//6p/3//7//a9/Xr 69JPfDDWv693+1iv5DF+Kjkh3/d8GPJDv///FfHav693/sH/yDEeQYt/+F/9e3/xwet3x8f6 hf/XX/4b6f//1Ix/JD6dYWv/4fX//8j0t+8kH5G74v/kY8lwnF8jDyXBSMf+tv/v25IchB6/ /g+vXj//b9/S2/79tLbJy+//f/t+/a7f6/rvf/67///2Gv/yP/w0ur9fkY5EH//9v3titv/b 9j3j5H75DOP+Qzxf97f+1vtaX7W7Wk//3v/396a7/79r3////tNV++1sfFP7W7C9v9/34iIi IiDBHVAzWgYRRCGVUgwg04a62qenfaqIiIiIiIiIiIiIiIj4AIAIABgAwAYAMAGADAplbmRz dHJlYW0KZW5kb2JqCjIyIDAgb2JqCjQyNgplbmRvYmoKMjMgMCBvYmoKPDwvVHlwZSAvWE9i amVjdAovU3VidHlwZSAvSW1hZ2UKL05hbWUgL1RJMU9iajkKL0ZpbHRlciAvQ0NJVFRGYXhE ZWNvZGUKL0RlY29kZVBhcm1zIDw8L0sgLTEgL0NvbHVtbnMgMzkyIC9Sb3dzIDc2Pj4NCi9X aWR0aCAzOTIKL0hlaWdodCA3NgovQml0c1BlckNvbXBvbmVudCAxCi9MZW5ndGggMjQgMCBS Ci9JbWFnZU1hc2sgdHJ1ZQo+Pg0Kc3RyZWFtDQr8ncFN9A5GOXxMbMORLMIMNnOeVRtjEIiG R6Ikd4kOYIOXMOQpKQxukQyIBkJOQNNC7yDUOHSENf1Dk3IOOgRDar/l2QQcm+Z/Ig7LhnRA gc9/+UIviIw6mfom8xIhxzjiJxyx3yI+T7xzTdxDS8jHptJRtol+T//wm+Nkd8Z1ZHEjBh// 8IW3aERSgynC3f//IN84VRYMN//+Se2qINadIg73//5mIDDfqqht//9E3CZs+zDkIOZ0qISg af//xHf3GSBwiVo6Bs/r+9P4YTWkIa//IED/38RSpr9fKgC/2/6p//UJ7XXXVr/egn9a7rZF r/+iEoU4P/3rkbXv+EhB/hV4MvEcQwXj/rwgw+pPe1ERf/vugRmFDfc2CNJYf/7fSBBv2lHz qBjX/9QmG/hQXC//+gk74qbqX/79UkQ8N/IIPCH+//9SSG32ENcznH9kwRg//9X/PChOCEb6 H/79O/M7119f/tKP8XZe1CVw1//+/EQyOF5DYP2H/9/v4vaWG2EQ4//rpr4RDKh8fBoj9f/7 JKP35hyC49hsGeDr/38ECfkuhvyGhtiv/7VERyN/aIYv0LDpf/9CK+D3q5oZHBgEC7/2/7b9 sOKX///u/sGyxxX/1yDA6/+rB1M5GOv/25LwjQP+/2Ooq9ffxCfX/DHW6X+2v/5BOOUiE3Bp L23gvf7bI4pwmuGF/eGl/evI4YDCtgwWvtiR8q/8RkCBRsUvVv/19kCBK1r9Jf+pIeRYS2q9 hnwdL93hp9toLVthkY4S49tEToZcHHL+3DKERzS9hiIQXjYwhGodhiIJXhhnQLw8RkSnYMJM bIYgK7UiD06ZDAaoMVaeKjYr7J3BoH2sMLBCQNu0GqIHm82oiVaLoojQO5UgMAzDlb1ERDMW IrIYEYhm2alyFhH+ACACABgAwAYAMAGADAplbmRzdHJlYW0KZW5kb2JqCjI0IDAgb2JqCjY5 OAplbmRvYmoKMjUgMCBvYmoKPDwvVHlwZSAvWE9iamVjdAovU3VidHlwZSAvSW1hZ2UKL05h bWUgL1RJMU9iajEwCi9GaWx0ZXIgL0NDSVRURmF4RGVjb2RlCi9EZWNvZGVQYXJtcyA8PC9L IC0xIC9Db2x1bW5zIDI4OCAvUm93cyA2OD4+DQovV2lkdGggMjg4Ci9IZWlnaHQgNjgKL0Jp dHNQZXJDb21wb25lbnQgMQovTGVuZ3RoIDI2IDAgUgovSW1hZ2VNYXNrIHRydWUKPj4NCnN0 cmVhbQ0K/nQq7ryKxWXUmBuRseQcRkSuKoF4UewVBhAyVOQwdb4fwZDFBZDRmCB/ahU1uF01 T1QP+nr2gaD19/fatv+1X8L+39VRCD6fyEH/+h5OD9L13kW3hTqJ4Wnp1vItvr2//+/wZQ9+ Gndr/pR6+ta91+vr7/6/71wa/v/6vQ/vXvvXrt/v+uvg/9dEY+//Wsd+iIP0utLvEff//+v/ 0tcgXH96Wv8P/9fpbeRR176//ffr1364P/+v68P0qTf/1360GFuF+und+PS//7/r/W9a+kv/ //r+uio1WtPr+uEH//Wv+92v1/63WOn16/Kev+RXIx/X/cY/xfX3/XpJ/fpXf9/bC/aa/9EH c2Cvj/0sQ//VV91+F/v18qjp6drB6eI01XVdWEIwoQMnWniMijkylVBleEIPER8AEAEAABgA wAYAMAGADAplbmRzdHJlYW0KZW5kb2JqCjI2IDAgb2JqCjMyNQplbmRvYmoKMjcgMCBvYmoK PDwvVHlwZSAvWE9iamVjdAovU3VidHlwZSAvSW1hZ2UKL05hbWUgL1RJMU9iajExCi9GaWx0 ZXIgL0NDSVRURmF4RGVjb2RlCi9EZWNvZGVQYXJtcyA8PC9LIC0xIC9Db2x1bW5zIDI0IC9S b3dzIDIwPj4NCi9XaWR0aCAyNAovSGVpZ2h0IDIwCi9CaXRzUGVyQ29tcG9uZW50IDEKL0xl bmd0aCAyOCAwIFIKL0ltYWdlTWFzayB0cnVlCj4+DQpzdHJlYW0NCvyQ6d9f+37x8AEAEAAY AMAGADABgAwKZW5kc3RyZWFtCmVuZG9iagoyOCAwIG9iagoyMgplbmRvYmoKMjkgMCBvYmoK PDwvVHlwZSAvWE9iamVjdAovU3VidHlwZSAvSW1hZ2UKL05hbWUgL1RJMU9iajEyCi9GaWx0 ZXIgL0NDSVRURmF4RGVjb2RlCi9EZWNvZGVQYXJtcyA8PC9LIC0xIC9Db2x1bW5zIDMyOCAv Um93cyAyMD4+DQovV2lkdGggMzI4Ci9IZWlnaHQgMjAKL0JpdHNQZXJDb21wb25lbnQgMQov TGVuZ3RoIDMwIDAgUgovSW1hZ2VNYXNrIHRydWUKPj4NCnN0cmVhbQ0K8g/mrI+eZVYqnJwI Mw0E4MFAaDQNBmGiCw0GmtmYbDN7q/XRDZMhsORFR/a3W8IGR2Tlaaaaa/uIaINyCGZHFNQy PGoENU0agdp/u00IiIZcGVmrBVXxERESDFOgPtREMsdcRIwSPgAgAgAYAMAGADABgAwKZW5k c3RyZWFtCmVuZG9iagozMCAwIG9iagoxMTYKZW5kb2JqCjMxIDAgb2JqCjw8L1R5cGUgL1hP YmplY3QKL1N1YnR5cGUgL0ltYWdlCi9OYW1lIC9USTFPYmoxMwovRmlsdGVyIC9DQ0lUVEZh eERlY29kZQovRGVjb2RlUGFybXMgPDwvSyAtMSAvQ29sdW1ucyAxMTIgL1Jvd3MgNjQ+Pg0K L1dpZHRoIDExMgovSGVpZ2h0IDY0Ci9CaXRzUGVyQ29tcG9uZW50IDEKL0xlbmd0aCAzMiAw IFIKL0ltYWdlTWFzayB0cnVlCj4+DQpzdHJlYW0NCvlTOdT5oC4JYNcNL+Tgt2wri36Dhrtj V/d2iWs1W7OjCB39ETQGvwQd/pB/VZG9MP1puQmRuqvCb6VNsLxoIPXr9/v3hf+sxf5J8R9a DC/4N/6v/3BF1+9kKOEL/uW5QPffFf//b79P6Rm7vkjtet4TtV7bD4Nb7drG/2yOJVXeOTHQ 9wws4cRDTjDMnx/X/2o/gAgAgAAYAMAGADABgAwKZW5kc3RyZWFtCmVuZG9iagozMiAwIG9i agoxNjAKZW5kb2JqCjMzIDAgb2JqCjw8L1R5cGUgL1hPYmplY3QKL1N1YnR5cGUgL0ltYWdl Ci9OYW1lIC9USTFPYmoxNAovRmlsdGVyIC9DQ0lUVEZheERlY29kZQovRGVjb2RlUGFybXMg PDwvSyAtMSAvQ29sdW1ucyAyNCAvUm93cyAxMj4+DQovV2lkdGggMjQKL0hlaWdodCAxMgov Qml0c1BlckNvbXBvbmVudCAxCi9MZW5ndGggMzQgMCBSCi9JbWFnZU1hc2sgdHJ1ZQo+Pg0K c3RyZWFtDQryirDUfgAgAgAYAMAGADABgAwKZW5kc3RyZWFtCmVuZG9iagozNCAwIG9iagox OAplbmRvYmoKMzUgMCBvYmoKPDwvVHlwZSAvWE9iamVjdAovU3VidHlwZSAvSW1hZ2UKL05h bWUgL1RJMU9iajE1Ci9GaWx0ZXIgL0NDSVRURmF4RGVjb2RlCi9EZWNvZGVQYXJtcyA8PC9L IC0xIC9Db2x1bW5zIDI0IC9Sb3dzIDEyPj4NCi9XaWR0aCAyNAovSGVpZ2h0IDEyCi9CaXRz UGVyQ29tcG9uZW50IDEKL0xlbmd0aCAzNiAwIFIKL0ltYWdlTWFzayB0cnVlCj4+DQpzdHJl YW0NCvk97x8AEAEAABgAwAYAMAGADAplbmRzdHJlYW0KZW5kb2JqCjM2IDAgb2JqCjE4CmVu ZG9iagozNyAwIG9iago8PC9UeXBlIC9YT2JqZWN0Ci9TdWJ0eXBlIC9JbWFnZQovTmFtZSAv VEkxT2JqMTYKL0ZpbHRlciAvQ0NJVFRGYXhEZWNvZGUKL0RlY29kZVBhcm1zIDw8L0sgLTEg L0NvbHVtbnMgMzc2IC9Sb3dzIDEyND4+DQovV2lkdGggMzc2Ci9IZWlnaHQgMTI0Ci9CaXRz UGVyQ29tcG9uZW50IDEKL0xlbmd0aCAzOCAwIFIKL0ltYWdlTWFzayB0cnVlCj4+DQpzdHJl YW0NCvyuUxV8yWCP5Vh0QmyyjYhpAiIN5kFiAiKcECQYMivBEXwjMjYQgsVGR0wcyKgqCQJB CdcMlboEbEPmCIu+B4I8IwoIi+SpMCHYZHBLI9BIwEBEhwgSO8gwYMMIEGDpMEkKBW4Yw3Mg IKXCnhUE0YQcNsOkwkCBBDYbI8www4IhMBAkEEyc2wYbhUkgSDDcMNulSCQTbJeGGHOwOBHc EkbEQTDhsM451DMLg1mYYOo0KBAkkEGG2Gww6GmTh2Ekgkmww0GyMTUwChaSBIErbDbCI/dN QiQ4QQTBIIMMMMMMGIdJaNeEMvpNpNtt+k7DBMUCKcEEEww239OgkCCQpIN2G3xqgl0mGwRH qI8NLSSOVJNvb+Qeogrc8otUkCSsHI+xen6QplDhIaTsYMod8pAc0BGlpdJIMNp61Y6SEJKm nI6v8PRx0qSWR0xbeQyw6IbA0s46SRxyh0rF236ZAvOsUkGLUHbUkX70LpUgm22E6XDpqjfW HbB0cf1vIZLtUnzuxuuH6UQinSQO2qSd9taoEKVh4OR0FrT9Kq7De/pA30kHpt6sN5BEkqAI SuTHVUZa1hBAthfkwGZwQIUl8w6FlDwYdJIn2QQeK9LjsER9/yHmt6BHHKHpC2Hv96uww/tN 3RBpP+trrG66x30Lr3+qEfF/0v3SprHfrXV/eucf6aqQ1Znwi+ba2OlsLQiJA8CC3I0mZ0GC nfrERKtCOSTjQ+eA8Ns5eN5So+ZjMZgy4ZZ26NoujaI6LojoujaI6Lo2jRF0R0XRHRtF4uiO GUXRsNERERNYcq0IiIiIiIiIiIiIiJ0CZh2aJNqxmL0zVmpGOGr7J9feCfDc8lq7CC4ZIexn 5Y8TFEdD44fXdvao3nRBVphf8j5HcfD7aapRXOOrQatGHVDSgirWoPY9eIdyOgyx9w6NheU6 ow42kw7hQwklQVi4wvukCBRcN9zDvpVqGUPCbj0E8PVQ22GUOwRx6SVPFW2xbSUKt97VJIxo KIbt0qSQ9uw+kWOq3fWkqw7baQRQ6XW22HSiEGISVljth2kFRQ9EnUyei3DaUJCmK27baRvq koYYMMGcduR0knRwICC2G0NjSQoNJQQdsNtJI2F7bYbbSSpKGGGHBwwkkERjgiOkCu4ODYQI joElFqG2QsB2owSUKwwbBsHI6QIJJBYbYbDDpIJIEFDbYbYapIEgUMGDDDbDBBBAjwiVojoM GGGDhBAkkiKSg8m9hiCBIk6CI7UGzgoMNBJCEqgyLAMMMJAkECNhdgww2kgQSQUGw0R4NgiJ aCJYChsMWDkeBAiOkS8EECmQkMGDDlBpCCQQQIiuoZEgMOGRS0EYEBAjYUZkVMzYmsIRsLPQ ECImw4ODIQoI/DN5PacREmAoigUR/gAgAgAYAMAGADABgAwKZW5kc3RyZWFtCmVuZG9iagoz OCAwIG9iagoxMDU3CmVuZG9iagozOSAwIG9iago8PC9UeXBlIC9YT2JqZWN0Ci9TdWJ0eXBl IC9JbWFnZQovTmFtZSAvVEkxT2JqMTcKL0ZpbHRlciAvQ0NJVFRGYXhEZWNvZGUKL0RlY29k ZVBhcm1zIDw8L0sgLTEgL0NvbHVtbnMgMjQgL1Jvd3MgMTY+Pg0KL1dpZHRoIDI0Ci9IZWln aHQgMTYKL0JpdHNQZXJDb21wb25lbnQgMQovTGVuZ3RoIDQwIDAgUgovSW1hZ2VNYXNrIHRy dWUKPj4NCnN0cmVhbQ0K/k/T8fwAQAQAGADABgAwAYAMCmVuZHN0cmVhbQplbmRvYmoKNDAg MCBvYmoKMTgKZW5kb2JqCjQgMCBvYmoKPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0 aCA0MSAwIFIgPj4NCnN0cmVhbQ0KeJztlDtuHTEMRVPPKmYFikjxI/ZukiYI4BXYRYAAQeDs vwhFzU9KngH3o4IDCO8d8fJe6W1h44Q5rznlo1aCJHXce/21fP76Bb69/IT16ffyfckJCNYf y9tCWVOm8eciCX1LLAH6p2p8G+R5hGCmgABzYhwh6GdIXovUJA5Th9Z8peBOKVrWa/3TkIVL wkkGaGwBWLQM6koHZDmQwuu1BpIcCVOXxNIlawwSsYb0E0k7kn1gORG3qgIdCQUTTV2SH+mn WAdDtVQHIk+6S6tktRPZ4RMv5gZWkjkWSwnxJ092Xu+NmLc+H/AwVe+YDMKywnXyRc+IWHfX rbQJopGxPSEAYczJqMfUsvg/pJhXg02jUcqztX3uiJjUiWqWaFBpO9Eqrbsb7B0GcWtkIErY gIWCrCqJBp2Qd6R6Y9mn0KrtyEdGYLYQq4wz8LgXJNpUd2DGDtQa0v5DpBIRUZYpfHDcEZY2 QanYiCidiBJWDqrZ8+5IV98sU6aYwgV53BEqEZejvhuX4oY0MLNGbC5AOvPHZ/5I3wcyUrwP 4nlu4AuQz+elRgAtx1wGiAV3811rnid33AqMmZ31QVfdggIU3dV/3gHYrsWne93rXve61wfX XxwXHnwKZW5kc3RyZWFtCmVuZG9iago0MSAwIG9iago0NzAKZW5kb2JqCjMgMCBvYmoKPDwv SkkxT2JqMSA1IDAgUgovVEkxT2JqMSA3IDAgUgovVEkxT2JqMiA5IDAgUgovVEkxT2JqMyAx MSAwIFIKL1RJMU9iajQgMTMgMCBSCi9USTFPYmo1IDE1IDAgUgovVEkxT2JqNiAxNyAwIFIK L1RJMU9iajcgMTkgMCBSCi9USTFPYmo4IDIxIDAgUgovVEkxT2JqOSAyMyAwIFIKL1RJMU9i ajEwIDI1IDAgUgovVEkxT2JqMTEgMjcgMCBSCi9USTFPYmoxMiAyOSAwIFIKL1RJMU9iajEz IDMxIDAgUgovVEkxT2JqMTQgMzMgMCBSCi9USTFPYmoxNSAzNSAwIFIKL1RJMU9iajE2IDM3 IDAgUgovVEkxT2JqMTcgMzkgMCBSCj4+DQplbmRvYmoKNDIgMCBvYmoKPDwvVHlwZSAvUGFn ZQovUGFyZW50IDIgMCBSCi9NZWRpYUJveCBbIDAgMCA1OTUuMDAwIDg0MS4wMDAgXQovUmVz b3VyY2VzIDw8L1hPYmplY3QgNDMgMCBSIC9Qcm9jU2V0IFsgL1BERiAvVGV4dCAvSW1hZ2VC IC9JbWFnZUMgL0ltYWdlSSBdPj4vQ29udGVudHMgWyA0NCAwIFIgXQovUm90YXRlIDAKPj4N CmVuZG9iago0NSAwIG9iago8PC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZQovTmFt ZSAvSkkyT2JqMQovV2lkdGggMTI0MCAvSGVpZ2h0IDE3NTQKL0JpdHNQZXJDb21wb25lbnQg OAovQ29sb3JTcGFjZSAvRGV2aWNlR3JheQovRmlsdGVyIFsgL0ZsYXRlRGVjb2RlIC9EQ1RE ZWNvZGUgXQovTGVuZ3RoIDQ2IDAgUj4+DQpzdHJlYW0NCniczH0LPFTpG/8plWor2y7bZcu0 q2L4FUIuYWpbZISMW0mptDHaEipRnEqtXSsqpNymMMZdF0KlScWkYjJuRRkhQshlXMZc/u85 MxiTWtr9/z//3ePjdM573vO8z/tcvs/zvO/Bf8mvg77FGxobQlOmQNAl8D/E50Fz3X876Ep0 X2ahpiLPr4E2QjN/WLhkofSyJYuXLP952UqVLeoq//ufyh5DvM6Ww/u8j7nvO3Tw5PmcqJN/ pgccPHS1Ojb9/uOSFyUnIuq76558zHlaUsh/AH0zc0b1tJdTpsyH+I8hDARNmT4F/Q8S/jdl qsS06TMkZ86a/Q1okPUtNHWKhMTUaRLTp0+bBu76gPvQtPnTv/tJdcOM7y12S/7sJr3m1IVr M+V+uZEvQyj9uFxtj/vpWbN/WLBw0eIVK+UVsIrqGms1tbR1Nv5qYGi0yRhvaWVtY7t1m53j 3t/2OTkTXTwOHznqeczL2+/M2T/8//wr4GJIaNil8MtXImLj4skJlMSk5Ju3MrNuZ+fk3nn4 6HFBIe1J0VNGWXlFZdXLV9Vv6xsa3zU1v29p7eru6WX19Q8MsvnV0ExkPDion60QG/D/5sDb /f/YZYh6poWBtOAgEEqHT//5MDaZeNsvHStWTbRtaOZ/9tL/H4/QzP+us4kz9b94OjRzWHIE v40NJt7Bv5xRmWjdhzP7w1Y9gebFRzQXD/Ih0jZqF7Mr6WxL5wFN3jqe+qMTGzDvb8EN1Aa8 65+4rnb0ok8OH6JnvvGRHCjjVeOaa105nhyXuy5T3O7U7g45VcZxcfPhQ2ZlyFNGNf6coeJB qa4En5y+rEg+tJQPLdZ/zexpQ3uiHsT1tCsjZ8xsTQ67mA8F8aFzRn1cstGr334MknzTNliZ QZLnsJ8NZgyUNhfxIf2bvP08da9umJ5KjQBtlUfu9v2Fa650KIYLQ9q/G76ra8ZtT8D00wcY g53gWZSkDdF8qLkaoZlYexwM5B51oHOA4YXcZ/AhhOYYPtQjGKnXyFPGzVTOkKmAPuXRBvfF ehAMGr2vPLYDkV5JzvBgn5AXuv2A6USE6YnnKhnX6sI2qthHOcp3pY1vWr/CZsWTx15oyuBD 5crcww7N9k/qSTE6hCNtJqYJFdg7Rnxoxw+Zkng7ew/z9s0J5Zt9nd34kJ5Nno54nw/v8SFb DPeIOXemTft/qMWiqmOrAfOuwW2xsKo9yyBis2cSlmpHkb7xfNY5P8c0A9xUVT5k+kOmwbq0 VRh/aQpZkrzeiL6Ae9iut1qMWKXZPVx7mFWB6/1pe+Z/aSZEDvvCa8PEvlvaMh2b8G3qzF0z dXdVzFxmckRJtsO7kRXre+IeTDdIW69NqY8rMKb9Ymp8KjCw/mp+YjDz7+xOm7y1n3D57v8d LoseHpp8qHUB7458j8zzwAhPslpVdXyC7TeeSo8O1VrnE2c1/e8ghuuS1Ze0qD5gP7zqyinJ G+lv3YLM1DbNkJKXUXIL2hAvEXUat/hyVGLJrOToW1u+8ywIHmyllogOB491Br9TlegsIhAx Sz70i8zdzxrDCZJO8CSPL/C5KXyI9Q14z4LBgHdAwc4TCARPdtnp1X3LFFaVN6RZ5Uj8/utJ t2X5KQ0R50+v8Q622+w4NfqB/KHlMaFRJ9UsYrK2/cWU4h5xaN5JEjevNnOb2cD2tSXD73/J TvxnVfuqIzdSZABDZS06i4lNgUPWNzfgjt6iFD4p0XmyruI60c2vSO5jUujREr0WNV5pklqY jFW5/JWf+FB6yk6SOLd274RTgnl3KLwzSkf/YxA1DturVFRDTNoMNLU4CikYrHa+7MObHVLP MJTLWYcx3sea87YX1m4oPJY8uOiBRFfKtHdG5g+T52+JcvVHlEA/AIsKy8iR+iOdBaxQlRUf enHW9XN2Q/pr1FoEsNmqJcKJDuz31Oe26qrFP9UHOCeFOp0+pCCh12WVPuPXE6wLXhyXEq16 8pMOLK0j4BdDL0yYcWHpFlkDW9172nwoJmVnnIGY67aRaX79ZaaLDXXyh1IElQ8FHwGT/hen wGNrI0PWQC1P51K4HCPJNDoRbonlQzp35hpHFxcV2CmqQMvKFy3rlqxXNJym2GjtaE1nP4Hb kqsSLcSwq4yfFy8dx24lsb9Na/08pei1rxiCUEmasqQG+jGsUmCW7Svk8TMT/IrIS2KuJB3D heObZau1pi7sl4o+tiqqpzLbn5F63lMW6xE2NXZZY1NCs6vG9F+NOhFZ/3tnpLjfsFnKZGeC W0l86Nrs1+NQcPGS+LUNvV+ht01HEPo7kem9AjWFVIZ3JTBOkdK2bZmSv6ivN/XvUw8dKZfv 7cuYfSXnYK50jmx95ED5yUbHPPWAWGYbqqectvIWMe4pzevk2sECYT84jtB+Bd4b5o0Ijzzs /DnHg/urEEP8zIkRvUlS/Uh8q8sWqd0RKVqDcu1DBbwjjhnSHRzL4KU9eMN5G6ZZhspm+mts 5kOpf/PuZPRkbIkdZuKwADwGzsqGhE7n9sOT1L4JHqFZz10wXR9wTAfuTFtFnfKXDbWBu6z2 hedpHXJJ5cSf4EPPDHhHfj+ssdpQNcCVrJm3Nf/9huSm5JCeR8Au2eSZiU/89Q4+VEERONh3 IywW1eHJE/nJ4bEYMFuqvwxhdrECi2LFfKidXO6XhluklwxgVGsI745yT8rP5y+YRHgudce+ qrNUnKp/DCgm0F3WbHGF/5J8/PvwTiAjthqJMA24OR/4cvreJd9bNi+PjuumqEpeyNe7wUiR zZJ1cSs8znUJbGg0BxazJK1sHSsuwpysH128numLYSPO/5dLF8UEZFxe/+MxMqSJBVUor4PZ 74HlSicarUzd1fuE3RT16KAkxr5iY7FR4DzFl4vsmyVeVx5unr8S1xwbXJlA7jSvK5ura3nX +uiiYa7riFu16xm4CtoY6DKWnhWr/k3IOCJkAEXyIdkGgMYQoyIZYjnH6UKB7vn1Dwqs9Y5R IOM6q7Nb+3Bh+3ZMvXHtm5Cm1TPcalO8QmA6mKv7LTUA7JBgjm+UrOtgP6b/zU8Xkd87eu/v fcyHaFQebv1Fh8E+cNq69uKBLt86ONX+BOt97PZAjwPAhwQ4rG3Iyub9Kt25FkZbFaibuNXW 8KGfZzsMX5E9QOMMwQ31wcgFXP/LuGISzyeY26fQ4wRe7QgEJkC3BcRWL/kQc094cSR6E3vi FbX5FbXzhlGkJmdIE1zQbRFcMGkC4Z5+MfqYsI1xs+nIJWEro2jhYyeEF0x7EsDbbMCQqzhE 9H0V1M4sAPSKci7ZbH20/aaUhvb/cPf02jJHzLvJZ/g9qQOI4vAkyzxrxXR1UIGxu5zu7BgV EblQ90J7bZTbKT9amYzVEcqRpPUrb62eMdWJ573KfqkCXeOnhNIYNZOCX93uC9TDUNyZPBKB +hPXjs8fozAa0BwqHK+taiKYxhwELSC+8V2hWmCXzSbtZR4B5xsyepN9sHV7u71SdvuS+l+k PiM/vCYRrHq8ibzU5dB63SkDZX+V6FhJ5i1rMWHEakkJ8HGcOC8B5BnFx+MCgzGa9akn/vwB 2g7Hvkrh5biG13DVr4gVdK8LHKp4U6L92qufkv1mSVMSxtuMov62c8trx2fBmJ5SOBq/rj4V xCnFm9xOGuETnNvN6AsTZw6+RZEy+VOE//bx5+Hm11tYggUiPgCnCmfGnR3MOZ7BPQwm3FYl bmVa+4Pl37qZ7ZNf9HMSKQ2qa8pYoPTSY5tHVCwgZtUPaVNCbNbedjc0r4xeeWiNissVdX/y ChCur9rTf2F/OdFZLC9w3VXEXOV9ia5Jm61PtACHBr2xHx9blwYGNi9t+TCjtMSoTGYTi7zU K0WLXfn74GPHhdw63pE94ZLZGj9Ng4ihf/gBIHHpfCD8zCCDIB4yKU0djdZ7v0Qy8vuT+fji BBmbGBsIAwWZ561L1gMFBh5ux7GVqXMuru+NP2h4rDnLRj2v9Wldc2DD/f1rfH9xvHrB5UXK y0Jfl42sYoJ6RzkTvxtzzx/TU7G/PFEc/D4QSYpwv6iTkz1GxWbFqhHBaVIKX+ryYgn3LSvR 1Ag/w0xxs2OWRc7C+Y3w4orzx624XSZPtOQgq+Vcog6jzEz3M1CfXsuHhkPDq58Fy18VqODt hI9dvHQx99xGnl4VgnTSd7uby/yOlT9L/q1wnqrVwNXZmfem3s8KO2Qo194TxHLzDdv/rlf9 4bwpNJm5ay4Bf3jp+ik0CWUjbi1Slai5CLubt48y9h9N+wQ0WARzyADAiWRHANn2R1ps7sTM 4hC3OsppJzuUhOuWD9p7Fu8rcb9RBz/bUJkmZXcrxkfxF/e4cmvL3jgJ6eq/eXb5wYPvs1pH kk7Dv22WvnxaAPTTdrDy3VcS+Vl1FrwD9IBmdmwFLPdmN2dtVXzWH/ri0cInyceaIhSf9CV/ H5jqxIuYncWueN1RpJUQs77FqsdkoLRQETe4X5J7BFOZZyZidIf91Ns9gtDF/ZMZRzT5a0sq IgKGWHdhevLqkohwWUBYQ8AfEVAaNHP5Id+sK27nHRt3PZGU0ZqaxtJ+cO36sUIpb/IAwVc6 pykSWMRdgLw4dlWSuCDYLH3xeZ6LWLXxjzG6K479Ri8Z25dcC/7JA8jrgsEqBZ2KF/F+hW4F c1/stcbZuQf2FZv7tVjJA5G2BxJTsG2alPct2m+4aPWGqSkxmVH7gqL6EvyG3quBx426NVrV xYYg43/40M8jzP9PUk2jOi7sTunSCPNvslgpx/NalQuvycVkpuQv0krZKjlw9rfXbu92NX8n 1WYbft/ld4na88Heic4SldEBzpj7J+GyDZxz3mHihtlmLnOTAFnXTsJ4/HOrBEapybC2IAlY MvBF4CVN0nV9KYuK3mO3/SG53if5Qht+3UW3dkKjY0zYL7uDlSnsfM65bZ22Zka7N+tau/sM lR27ynXGtNUB1voNLmYtFn/z4zuFP9M5vXY1wrdOnSXH+CTD9lUHCDVHnCliaSx5d1a5Oyal BOptSritsq7CrLzW5d2+ErgCrgKM3bnzj3gOMRU3f8sLYuacwY9wlQXgdrS43O6xB3GwrNtQ KQjDjSPsxqIsLJb4BVMuIgjDCi2u4SOdvWNJsbCCdJ9CnkulV/5yqwOkR1lWnUZ2md/Mmad4 ZpBbe/wJ7kLKrgsmITTp+KYrrHjd2RsjFlwZZrQdXoQYtN/r6dR3wdwj4yWHRwXKUq0E2ztJ PoOHq48I1dW92p8diqSO7G9+dClZQ3RIwEVbxKfE3lptFfbnDMXNfhdq/LZ4ufIh3He+pLem 3SSe73Iu7mF0I3X/Xzjzj/HdTMGFyHeanP6QXj40O+QpPDiAngX+WngMhuXXTInRqhuyTfBB Kk2tSKUJq0+X53AF5aOzGKcQni8IYmjww5AP3TC9nHoRXJW/AFqYDCoPELgx5oPs8G6HjxSv 74bvyv5K6mEpN1LfGjcaA9IIPBOe9P1fqYJrRheUOVxw+UTGAGHwOz5ELyf1P0W7BNdN0OsW jSbIYzBTiSftJdJEFulDntst1skasU6MP+kk5lem8EHT7pUgIMvFdYYBDhRHYGXerlqn1SM5 bQrn7FH1T/yTyExa7XJsdcFP3ggIyglAGHNNjbh4uMogfbeRPstJttz/erv1DYvDKQ1t2yxP Xc5rxDypuKq4Pr6vbcNC9eeWx8jtpg4DA9lg7kkvqpJLxW3+7h1zLsNtibwsUfEbW5r9nA/4 h2OkE1ssiMCSANya/c5qb1SX7XWjt1tk526I8baEZ9/ddos7YORQK9Xo8nJRykJ2mbnLn70J lknJqm6S3MO8P/IIAEcFjPXGd9qkEEedPY5DVZiof0gI8kkqH8fjCWkOK2rFtcYBnp3OzUpZ pKUxa+rVn6NUvCtKX3RFFEXtjhUo820/kss9tRiphs27jOziiccK5CtDYVoBFSXcbKxdAb4+ 9cf066j5OsgQZetIJXyUu5OGQmgPiLte4R4RzAbsbruavtXNLKHpYoRHdfqcSmAdvZfAdGBP d1gGZa1+G+SvHpnTl7DvYkiWIpLkEJCMB4wWUCwweHg7pRltqRhWOSy3fRxmifMuczIkDyuF QDqSUelQK14n/zFxqIlkWjLdYW6gI+7tNsvGzG26XoDXlz1sH8jmJNxgaRdbqe+Lrr4AN9Qz eXfgjTtTxBkW5n+k/yoCiAYXvxkHaonB+pEpmlhcPtzqYu6OjVwrmPXCdjn2VYJHgKf6vgyZ fplwXO0ZuMz8vctBH6X1mN0WqkXvFW/QyUvKego04IYmKXYLd643WYwXMn4jBI+LFb4AC/4R EI26Lg0MywK4VO7+80vKktxMKq/Ynv3NlHdztcqvgL334nBnt9Vfrq2wi2SEozJRfB/XTOnV aA0drR6DUBLh81ZbB28pdivuQpp40flfHsMzg1cKK8dVIIV5SVb65tlHpKvtLqv0akSqnfjI hxBQ4JxUsE0ixgy7cF5hyuJ9ipvdNjsMDA6bOHFR26rp4A0kJbhxv7c44+LJ8bGTyMZ8yvrh mcEjwADJoAD2hixqijaNm2aptJHYElAQdeKFgOYd7bZuHQq7jBYlU9QtGBck2aYjdmKs5F28 3uHLogIL96RytP4t7203Hqe+gsPCgadbWvAhawz3MKYyV4VonNhjXmx0wU7PK3VbkdRMPpRA elHxwtRBIuLsH1J6Lve9WjaZS+cupPzEh4yzMb1l7MUs/KixFdAPbEXndjBWYOBcRwTmi/o/ OSyDPgOsBZzyN++OVJv9pXlEL/0oC7p0rc90rdWmOxem5tLo8yQ5mbw/0pe12d4oxEckMzdb u2PPEC70FujhGppe8yGgmvsrxuo6mMPUHzPyAPbZAQKQvFH6rjSLF1hHiJ5cMnUE7j5txbTW I76DXbV8jYeZeu0GsjprWpR1V8xJXlbYoZmXIHNOJh2zkeBRolhp5mG2/AKn9Uaxup8pVFaG IwoFPEnMWRjInDrS3w5MfiLPMDvJ+R+Ngpg7nZhKKqSbW9Qr0LnqQFzWe5cWdRo6F+MpISE2 x4owYXs3m1+RcmABM3JzrvOMJ61YyoWIROKV+vMYb29MbySMGr00cQcxvl6OY7zwY4R9IqI/ woBcU4GRhu0aT5GLlzUF9hi6vbCqSVmz739dmG2S3RqxV0Nshno5SfFvTW3l5QN2q+deMx/W TMJY04BVSFUaT0zEpfRrnLhognEYegAhwQbNXRNoeWMTdmZqy7FjcBuwx9dzp6aeXqPisrIO SDa0lPjAe4sfd+WwJ1w17IgFvYVmAdFIE4rGezHejIr/10TVgseEE9TA0pw153fvWTMOqbXZ r881N6JzPVw/Jvhcw9U0c/140j6xOGNc5x8AKZtnyg/B/fngzKlajtbVwH3Ek1FGzvgQcy5P xnDbi3u/SmqdIJ1nL763Wo62jg91os/r9lB5A7i3hB/P8CFX3oDrx8Tix8d4uKE6JLIgBpcK 2vGhTAro/hF81jBclRsr0bNL3/yJj1SWt23NbsSm9bdQH4a3n29eGIJjFVEfhrRfRyzCUC/z rXHfe1wLhTvk+pG8YOSikfCpdurD4Nv5bfLI7SSD18uPuA69pT48X/uL6rMeHniZcs1PJSB2 QN6rXP2WjlRppAYs+nJ8tiM0G1W/ZbmihCqPnGFc/Cuo6MjSMZ9tjtkvbETaf6Z/uIdrYjdl gvUeu5v8nmx2orbVyHFH2AgYQ03UeHaKQGB8zZpdY/uYa/0/C4Dvuw1yuXHqe/3Ky2bp9+b2 q1897x3h29AK6xw07iDW3M882JB09eLxsnWeSWvcKi+qRab4UmE+9BsKJsa+GxgB37FGYCSB +q8O1DELvXPuUhOulQMwAnL2fy6xyqkPdNusHvqBML/dxNhQKm9d3k9kiAHABjIRnXxo484b 4ktRty4YJtJXtPtRY4SqwWTqOmLdgEPpQjlcUSAwLk8DQxhk7Y6ZiYNN0cGFERskqiPbNrSs L16ahOUmqvtmynN8tndx4BdVKZ/k++ZWMbPHIskxrk7o/r+OpfvetirihcApfSOBD9kicdiT qrU5+dPKghOI83RmH1rCxT43ZyTvZfRcMG7ZRNRPIHOIxy06TYN5+u3UWtyTqpQy4wdFlNIx xpEAyGY/c2W38aGbEcwRKfhC0mYyo4hP2OU9+6LwX40amNx5cDOwh7kW5RWnyijSj8zi9RRz OdiEQLeAo3MxYesyyPInCGXAAgffPYSjAs+VtWKVSLYTOXYBJJF6G/CZOoQVLha6GCAiCsLD rHfU400mOhKuiDYxNnC3C37tj0peOCvp+KFNlLr6898H5ZD1piTTyOq9cVFlLblxt4nNaStN tXEN3S/50G249/udFOPaaLFX7toBj1DMVvinnNinovNPgixYFwWk2LcRhwSM9pdTUvy1cWRs 3ZHC41Ze7QFSG7bIYnPp3nYHVkimmZq8sJQDHH4G99N5p/dXtNxrijYZa662asqt2Q5XOXDD Urw/I7tfv5VBkFQA8D/daFSOFXI1HD9ePa1q1hAVQOxLnKWB8Q1lO60M3UeKcS6qjy5KeIwr WyUUYo8SFd9M9jAHhYQ9zK03EUhx1kHBQEKH4/KJg8Uvg8jQTFtMEpwikInQaX75KeuHytiy ueRmLbmI/XNz6HYppp2MUG/LDUmS+APKLkfWqvEiXXnAvb4w9S7QzNMZDl+Fv3OHSKzbTFYZ Yp1fCN4jnfkldP4VSz5QmufE6zb0A7P0TtXmRtCmxL6L7pLvzPPp+F/maWs4ZNvt02tZO8Ro 7wcGz5sgmbZuyZGWTUZ586V6gYQEAwmpJGKJY8X1+kGjzjRqG4X3VOg64mMD7P7D/TIousld ZdSBLKMyxMnZ+9izQzYsk02IOnQ8giDpWA0iTzh6UXzxusCyW5tM1SMOG3HX1HAb+NDVCJa3 eCLqYQ7o5Xe45RoyEcPCYTGSyB+r+V+68EU+AyftS+5f1hcK9C+5sVfD6f4U8kGt+LYNCzu3 7IvsTeBiy50iJNN0wgMtYwXaF9yt0ZppYTJ298XWBfL9lUwWCFzfr0RhI8KLADtxgzBaJR1O F02Sw+kbLYaQjBjCsnffUzVwHie145d1NAecnxM1j0gJfpjSEGBmIJ3Z6sqIDuolhelgBrjA ux3jQ3I7MwzEgrOtCzBt7dQ2lMGupSOS/F8JseAIo7U6HJUSOKrGjd5WNcWaXvIr4+eyilVu mycmNAccNCPmql/5OdzT3MVNl9ARp1+hbsRd+9oxl2eYtxO1ObEiacF032auTzb3MI49K/00 ykJwizx5F/dFMQY2ToTNdwldLUYHQ+/3ks4q50q7tWymWAZhSWeNg11+IXZhgLqlwHLIEpdM Yd5HKIAyfm68+zW8OxjutEqWQNhCJ7itYEIiLEgHmoqS2tiyIZ5OXk28UoBLbDMZYBy9Oj9g Z2goJ2Azu/x6YO32IVXcQEuGZSxiykXhXsADoGsO+4G+SQHD4SvIeSDGQUGUsWNDy0mKLurs 8Hb4Bg2Vgp9m528vXrjcCYNNl99L7XmF62TyoZ2hy4Evtif1A0CZsfmVJqfPfKifD1VRDkTy joM4AoRkZb8U8yE9Sx6XD7Fa8lfS2I18iApzvU1vwfS9gtPw3ymYPMGDiX0moHWIoHXNvs41 MJPKy/vJ2J9zW9Agbi9z+N3RN3fGuKP358cz95+cFbrWTCr8g09b6b27GYOD5kMs0Dy+u4Pa /BbXWYW0f/cGpj+EmRm8PPnwI3wIN4sP+VLZvV6eDj0fSf1A2DNMRpsojzThQ+ze9nAtwGwM OiKGl+dWYFX+BDAaISP8NzoH2G6UYl3w5k5Bq7Lb9nyI7gwaveJDi13DjwSzkOAPULtu9IH3 r5BycoOQI+G4nlocOsr4+a+DB10XITCH6330GWm4U8bvuXwoRtjPj6vh5nswynqTm8284zQh rXfB9UzB9a3d8Q9by4sUr9cemxX8Vp/1qnTUXX+dZRhf6FfI0FxGDMY7f/x6qWucRJpeK64k yC9vXU98sU5QealZpzGLIlVIOQmCzQd6NYO2whQmiNMYAtMcmhkmon9cYbrfQtRzjJA+mY10 Ip5DYN6KXJYuQ0Giki02uDJm688XzaC29Y0+LqtDq/FzdS3aTNo3GSyMy6iM9+fhDvAoSEFz 2P4LnQM5NrcteGAwiw+dQPzHndkCaIgfrzQzORsnpqTx6ZoExFg4cEOr1pxc0pdyebq33wcD jRs0jRgjqrRbuxnkXdpZqPBA/fKDeHZ5qL90dLIzrqHv9VSd28DGpaDJbMuZdCSrho4exKaA pR7ZuK6e/bxBxI8cthJsHxVh9edKY5P1MGFPBKzOg+tW5p7F4O9I8yFPrX6yb84yKZcSTlLe Xcuho/Ecg3VXl2J12HuCnwY/DemO6yYDvqexjwAMmmphjJLMGJaFFatW7HoN04ozhpr50AaA 5gTp+rFi8omMTh6cEizsD8YxpNgtiEw3+ePvXfuzfaDi6Izk8x6mU0l+xsXqEiZm+eT2De2m BaYz+ZBZNju7e0wdAbz19UmvnwHXbeY0aK5ldqJSLQS4FuJJtGE3PiYFPinJuZjTbsTbAcwE pVejeCrURgjyjnCTWOpyIyHKkg8VRlaTqkMWdho1GBdIXqgMUtzkdT+blgIrsnTshMkxob1H cByJp3+AWuuKuEFxgsfZc/BVh2k6DjjAcDRt6h7mqv8wMiL5EDEuppcPuZhhmefUKN6wb+aZ IUZ/Ailtmx8QCD5U5/A0Dx9tbDxgmYgoIjaq+Ta6XoBA+E7S0iyeozQDHhgE8Z8Xtff7HdOF lIdmjrM7GpWZMUIxGQwaRnPBdQMLuwN3Lf03r3ZGCEnlY41bu2VEKjFsWbE6F2ugrF7iYuZm bNxiCYA1BpBkw7NuPSzIVskSAcwfDkyvOwFnEumKwn/fEZc7TtA63rWJOnKF9HVb2tBKc25+ oRfl9Ka24DRcV6LaFgZP3SlArTYcVxJcGBix0y2K4WGZLyD4o/K7nWQgllZ79/qF0PKMLc57 zlkyr0EGXehKKF8XvqjYFGHGrhKYIZSVcU32vz+AKp7jQ1txaBR0We844byBcaCPy/fBFluC H0YHuxkea8Uy/0zoa1XgJMHzDX0KJGNYexAQ3TzEfIpsVwj5iMLN+KtIRRpxITJ0YA8xApWs 2jhmmdcYTzF5yRh9HlmvZ4uBi/x4d+APCbmnNu/7JrA55NSpiFsBqcR7+6IvBJipmj6hfDxG cTOl+BDVLPOLP2CETEeMABKYjazRSwVIpKG1ppX5NFuwrSjSROAAx1m78JVL4FHYvxRZYkca wqbv8ky6LmVfZt6wRTaaGDov2nTp3dKAkJjQ+6GPInTYDF6WOqZryJUPTQViLQDJoRbGxavQ tyO6ZTOHD3WxDvB6YGFwhQhw7iKa9xHxFWQor4UfMPgaM22wwt2WO0L2ksUhy92lNFZ70Jut 6TLfqseGvpCSbj1ILIyjRFyaql8D8aHjg7aJAHLEuBmM2dlhA1xTV4+Q4kQBxZ94838VrmBB WJQ7d2MqRpCIeLarP0Xi1MUpcbdVrZ9o/KBTdlK9LKrswc/hmGb1nJZNBusiNlu9cGq/jumn hnmHrUJWmAt4G4WIMeDzVjU+RKvIrghu2V4uYBzSQlwc/sXC9lDwEvuDV333C/JXl/4n6fLs Ynet/jc/uBo03ZY7VBSdevdkHUv6oVfLZvbsKX1x1DfxktWh3x63PNVHlq+OjAoKdapO2xB8 O5+GjOEcMoZVqIQi7nzFSm3dMsDo/EiefjsvjZPiLYyv/4WlE50m4VxhwY/SuXKdGgCsNyIR V12H3HePn9Cvf1+lUeRzyXnRIsdt1j8e3eK+P89w1UKt3ReiZDPvsRILfVo4DMauFz5z9UMu +hC1++NTjgIBGZLkfDNoi6xAXbFqxeh4ANdtcdoFb7IrqGGHpRH7B0CWcCHB8DyMY1nEZupL BgVAIETcbZcmHvGTGECm4+9wp9DaPe/WBdTp1hz65tcVf9FM0/LTeW+u1Bke8pxfXpFuJJ3f myTJCJGUCIC0uM75NPz6dQ1p62TLPVo2baDhs2b41syAq4ECq2cKVRhoobHAsMiUmAMLeYkK 3FZpKZKEAPZBKFujhTfR5MNkpQyIKhiQ251T+X7cHjRmV9l/1tDzqNL/vn17v2VhervE9B0l 6Ye0l85VDzJVl3I5Og+i7HqhvWT2bxIdvUnzjsWr3yvvAxPClSoFohUNjK2lxwdir+immF0g 9MQcRV1vHjIoY+SiwNSPOx9ftECaMR5mIljr0qiQXURAupqFllBLwiUD6rbFERemJd/h0LQb G9KOflyjruD4o1WQJBnvLBmTENhVGVx4/vhiV3yoo/RiJ6r6h57yij9xDTypOIDGgPiLlYYe XobJQHgfUMMOliLkm5KR9Rzi6yn+jVkCP/eqMImQHRMNvapUhghrjxZJpM/Y/+yvzAvR9Kgr 8o07/TlKZaseDOmciNS36G4mb1tGOCDbe2BhfDX2EHZtgMq6CMJ0tV2spLUBN6CCDzhDnnXL iJwQkAgPYeLuZ4ICFHBz29EamVCBxjqDsYI/SaO1Avy4RZx6tL2ODy1CohsPL72U4rnlQ5dT kxZfOghJLATxeK/Wkrw7amuNtxhrrO4gbtCmOMVkvmbsZTRH2A8xfNU/dFXGLa/IkWL/jjrk a4KuNzdXjywNtlkex1Vk8qZzUtyFBgf5//PQ/JOp+ocN1kAKFOLj6VpAroaAlHeSwKzMVa/d bPCwsReqtF/jlf7i9aNFWrUqOlWm3YlTDKGlimsMiRuaInMOk19jN8S/nrmUuFGi/CilkdCc tdrl8bQf3+NQ8Cx4px0y5wpkdGHQ9ZVad7P736DmV5DlHG/pxMVLQmo/M8rx1hMPcwY5yUnb 6J8tDJZzcq9ti1M0qx1MxVw/OXSv/02rEsUiy+q77Uv29l/lTlc/Xh+l00uZ4z3bkyq9yzFL vg4b3Yq3DzyMGuBBSUTfz6JiVYr6f4GL22UqUHZEtATe0FjUAI+IE8FCtAIzNi39D7iVgPyy N4xDlqEwkWTm/pDqyAHL3N6EtUYuziXeVqSzKo1Hk7xoeO3eeN2++EaPAC/61YTAukOK76gc 33zaPmBrkY6Eoi8dKsh92HOYXf0CLPVCqC1j074iGvIVURfiiRDCZROvPZ9tDN147/ayakVj Rj+ZD1H/8PsO9nYYGiDy8ILfuvENTeE8XkRwEeGYF9z5NmmaoiQTXFjssMJN8MSVRorgJLxo 5913yEk00hmNe1g95pfDTE0uR90Ly20Bz5K7Le8ChYfnmsyZ6br7x8ZGTU6mdobBkCJMN6Z2 tsHnlF9Z8rzBvMHbOUT9p6QehusQm9lgJHLVd+SqcZ8VH4oJgZmVQH8dblI4vZE8XvYAw+cC rjme2c+iFkaLtnB69T3P2xztxHnoZ/BCoETgjbgPKXxIbyWgOo2nzrwpP9wLN2y4l+CRrktF +zMfr234hyTR3oYfLLv/lDoe1c9V/ud5/lvG9z0+zatqau+wUWiPaOKoumHFam3jWOt1jC8u bECF1Nh+5zXeTabAsTYlvQHy2Kz+kDgln7IvbmW0CemRenTLq6Zw7YKfNNyn/P3e9xwnpawF SxxbelQiRfJwq9Cg+85slKbYcaq/41iKCS8xxQITFJtTvJH7Ww4fcuZDcvb33Vps1oa8IHzr UZ1CIqscP2V4fBdhaJdFzdW4j9K+UOmAh5nki9m+Pme3AmMS/F7vaHZvhgVaTMCKFE4vXt+H 1LXhgQXdgk8tjU95wkWo6OqSwIAjX+FrUBCEnNguSPQZQitMxUFhyxquPSDvWrekYt+iRLZl bjyZQnBkBO4qKyEWpgIXTutF/WKvmHrLnFXm+OSj+n/XWGCdkKQXYqSE+EpophhrVJyXHMKW C2d6snEeQq+abFNO+8ZOQMw9+EK6s6x2ypTwqHR48RmW1sK+xHOa6pnPu/AzsEQDrHya/E4i l5v8GtPFhySH0rhKZUlr0Hdnjr5Zxk+T4yMAJ64C8zm8DdPYRGhQvzq0E/ayAjGUWQWtS4xd eYM8w9x7ZUmPMuzSTZc1hatfqQ/RIhevNiQaq++LMd2WjWu5Dt+pAAweXkgp7Gbr9zANmOBv BgWbNwmiEzC8veuTmPQfIa0Iul+B/Mv+4DVkgTNSuLO/3lieh1vs4X5MIiLVKEtzYT+ZoxUn PcU4CPt4X2hffXDaukUp52HaB4xhhhkKHS6JooHmJrRuicqvwEiQR82DeIJ4slvzkNoc6v/T 1bYMfTw6GNydvutIyhJZN9PlTSkhncUrTbW+Ny1ixU+LCFkZot/7vSHxdUPadj8e7hpbsxuh NqHOSauJZCyagDDeagnT3qAcZqEzbiD9WWf6NR8rRH2YTEErpm3VAE+OkxIpG9pVVR10pcD2 IGfLXGknCbK8dN4Nk15p9sYXURYD1s9O+NzB7EBlFutMHoHrKJ+UproODAHzcQpWZKIrRBRi L41T9x01x/8c9IsCOQSboxCuQUOKdYn3HA7z2Bho9VzF7cKA5ZP8QpfcpivlBFmFtsqL0Yyo 6SvXWV7HvpTZJzXA83tf0QJ4YyLCJwA0p1G7Bl17XRuVvBHABl71zwtaJnGgowfYrDOf18Wz Lk43X69I0CbLTeux/uuqDzaXTJf+ftM877KeJ+R43Fld74q77vpvpFBbgMJIAVOFBKFxPOou kM8DAHM8bHTHOTYwLk1iG8uwWUd+1WdNGapB7G26jxf9GeHURcOygp86C/WztvIhRfz0ddWR dHsCY190L+UIxc1mmfZ9P24VLwwwVmw94ChjfYVF0i+RM9nFeijqxdvVZ0mxbnP40PewYvOM WdpJt0rcPdrwxvLLm5K/N9AiyGbuCziy+jjBVz2XtjBlC0zjYDqAQzMlx476UEHNNz8cuGLe Oc5ZV8bwqqkvqNBkPQOyVxEARLNrvNvMVubT3CytpBrdQ6qmxbbqeR5GZpmdZnM1ewqW9Rfr RNeG9lIq/oYH+JB/8FvXlp1XTAwEG9jRTBNqEjzKYFo7tZQPkQ+rC4rrFgYTqhlM0EWgYbyb Jx9qO4BkjaKWetho5T9ptIabN+vpWPoco8zrfT1E6OMo0PUUktRoeM/b2DMVz3xd3/KhI8Hd GZtRY6sgsiUi3ddhgJvNxvWmnxaU+JBK+3gm9evW3aCygFX6uxxX+UDPBEjCA5ZW0snmztmB LBzj6rIu03xW3Ixz9yw/wrM3f18dn0+WI8ur70mrgWm9Dh2avRkmI+BFABTjY6+vAO4BKIED G/izTEEu5Z+mfMvK9jjPnSy9CVtcFIRY2K+Mr1l+8jzt0ltDc3wj513nEmb/hzJdVss7gOx9 izfJOww2a3KH1BdV8bye6j3fd36zvzYA96/IPeAC2kSzZGdXMY2rpt6pB+dqlj1TZ+odG1xB 53qo96zhQ+6uQ33EE+9a3hUjbY2aMzB3w3nciBC6vTtAzbcsHx2K7fvZMbwjm3NLv+I9zsUc eR3b9WNcuwkf0k0A0NvUqDqc54U8HsnB+pZTe0pc0VXNo1cVhggwXZvaWQafxbg4jHQAQgLd JqQDnjR1pN/4IQIfEjZWrg4Zpwv5Ma8jffo6rP7IVZO+eAD/PWAmIHT26GXj8S+b9JFHL5tn yXN6InlczQGb3Vf23j853e0sfC/e27tqB1oyLx353IXYnpkxG3knYlRHvuWUCfpz0/Fn18Ap QEhz47XpWcrqZSTvna/LbvpgowKcOcRmHN6M2KznXEQuSjn/fd/7GbhTg5wUhnOs6LcEkKJF MxhJcBsiobYbjUkudkhKaxx/8FVfPBWubAE2uZxg6dFuf4APsV/qA0tAmkoKnNPgZziDeNdl iWVXi0l2m9lsBdo7i3ZaGk6ilpRJcKxNfSBZ8xb3AajVJrJo4IWsu0xFFpdiEK1qF+atJlLI mmhEboz2Z289+Pi6z/ZBW30KszepO6eVid9Y5Wf9l37mFa229fKV4eq+6s+7KkkhJiRv+67K 6BjFYqrmCz6Uw2TkrQacFeEy+JdSTCgfoqzHvYJbdkyXHmtrxbzAZ4zraKNxx0FAf+x/G2Zx tNWqF4vv3MjecabcTIX2rsCSliWRTnxzxyLYJVi2Yq1eEvb44TjZ8py+lNsNC0phhOqfL0aP 7dNWTwEplwNrLOIiPmPAVoxb5PqHA9kVYOnuM9cYQMbHADLukm0HlC/64OL7+jt49p+sts20 EwGbD3nFdUnLGtm5NtTGY+xwi9cdoXiYDFQ8+517ezV8ikr2NpUWWzlgq63MgUGwc4cPMe4o DudpBVH8OMB8YtIshjNQf6TIh7i/Y2x41iVJRQ8wZ83m4f6W9mdGZERsDjpGfkJxCgp1ClAz qgyXYwQy+lIqkSz4gqFzXKXS92S0i9HPs+0nhfBwdXzIjQ/12TFjBQXF8Z3bVx5odi+gQXng khRiNqTdjyXp5VwN1DA01/hWndNbjNUlzDt+lCypl0jpb9mgu0UrxWaEXkai2L5EpanmAAdz abww6vBeuBVouDk+2pmQfgLNqx19iwBDHpFiIUpo851j1GnioP3h5rbNutm/KMq1FWu+n2tM u5bYQ9toEtVTvKjT7El/nH75B65ze206GsGjLnnTJ4twm4FFDx7AvYa5l+7MdtXuo6Ci8zyw QU4/lI0XJnsFmCNyJOEgEHHxmt0X5HpYZxkWiGQveYYUo2xmUjrk89S7XX5WaDExCTKQfpN5 zyq6Jd7yTxn3Gh5uT0v/j4MBvd4HdMTyMrktkuwTmA4c75mI6Rj9GpH06O+Jhu6fWJAV4Mdt cTD7CZJ7zr3xcl9qc1B5WeU17WJ5rUaGr3pervqVJD0sluuMs7OvuPu7zx3l/h/ZtuRRGyak w4MBWA/AMQLRAtD64EiWesze83E06p/c3uiDQPz+LMdVbUATMfQMDefT8BkpssqFuxRda/dj CftOVYcH4I8SXxPcIkKWzdZKuf1y6DDMKqZezjBMPKW97AIty1xMTHcBiIFBNvNq8vZv7xUw UnS6PzG+xqNb2yYoC4Kn3Oz82S9RJr8rPOQCh7+ov3CD9DBlyWxJ/EGjNGXpDuy92fBCyl5v hlubSYGzHeDmBwHpBvGibhDhSqokIsnH+NAlV05l9vtY4RYCMTaLfoXgawpR8UgkJzEkIPpt VPmjaz/+SdZe2u0iUaByJDZ85fnDV8uSnMl0mWvAvWNukNj7mM9tY0vFVv3ZfIMm1VgAeEUg K5UE5W4hNPqPPgcO1EKmwGVJ0Ux05YBOlqZWIbaYtJvmkk68yijzwJtrKOthQ3m9oR+6bNPg hj4cuwkhlSD8+oEwAjIxkKEXCaQhhw8V7786vD4XtciTEt1/OPBK56h8aDtap16rVk16vS+I EpNZMlhsZCiZty5rJdbNmBHfadqST25jZK6CG1i4tkhYdec5EdaiMjqWXl9BvP6l5O7INwMm JQ7xSPqBuxf3Ufnd1p+jY1RNtYrXG+iEzwhZYpnk3GaUt7SF0yxzFBiyEF5udo/Me+DcS0eU B1Wb3YBAs795udQeuxoBEI0fzZaJETP5TXcju/XfZskwl0t4KNe+8+5N32RA45wwGQz+SLkc zOGYBCcCxO4AYA39MfMyOA1+iuvpUm7CPQx5KsfbuZJDG7B8bJQnuGeOpTbXOzyHz8paOv39 F6yK7Of8X39OeA/mrel8zOAAcmKmuoQPZUTKXgHXuoOPo606sbfAfHzX0Ip7SMk+k9Xqy3PI ed3olNiX3v8ByD9OjecIwhQ1mP6cDyHvcbilyeHQAYlx497Wf87s6cEBEsM/tCO3fffzpEn7 XAcHSeD9Rq8ieb5OgGyLvn18iHSFDwECfK5Qm5tgQDjmk2YELnLPtRh+GDz81vjx3hX8ZZrM P72tGPHY8X7wmru89vtdsik7dqwVgMnQMd8S+bTKN2k9F7WhpUFEVRNTrSRV41PGNDzxQfEq ZTcCgdAg4/sSRr4NkHCAU+A9bMdXjFjsXVQObMCH7GsG0w6WClPhYhAcNDMt/uQvLkzqUAoo x1VuDO6jhnnoNleH3yaWM82w8GxVuvrTmW1mfEiP+KZFP3M+z2NDf5qSJS+KJPBQ8WTRzQHg SPfhQw08DLsJ1e4AYSlqnJ0vo4ZlQqBxRF8EsBhbUeCCQT6JfQpWfCDZQnDUPWWqR/wjpJsc z8F6Qb0Jvb1J2n3qs3eG0p9m1MC0brhqLW9P3nchP0eLLUbeihR4S5Hb+7eHfjYJNnE0Ne4R VsDkQ2n+SGE/GhO9bRBXnWi/+075r8fLDIluxn5tJsHeRxSkM6vx5beBl3w5CLwkIgxLgRCM IUbmDLMLkMt1d23KyhWsORnN0fxXf6fC2N7mGu82ZmBBd7qXka9i/hKftwFECc/birk09bgE rQS3dpOaLK3euGt62E2yrwnBO7E5LXifY2nf2Pvk4tpCgNH/22RERIVYZHc2BzYCQhw5mHZA KMRikER0v5HlzMYlJLK++PegJ3YIwhzcR8UHO+vJ0xw7eJlVy7Ilsmzl8xbFx+laVAdFWdLw 9k0RCsUoYBFKxuIAuxFnKdwP89B1AEwGL1ezx07wJRy8Quw4Sxj+jSPAKv0F1O4RCg3PxOQU JT1sPh/oGzZriLbMzzppYAmjIWCzh8l54r198Q/6KJbHrla0CYlCfBYC/VpHNAhN0FyP5OEa +FC6KcBYRBRJ/fM3WiYdteXc5UOs62h1zuOkR6HLy6cX/sBEq966S8KnGiysD3QzDsablee0 m0vf6zLZZLAza+F9cxS9xFmIma6wP0bl+a5A78RDdjGpFtGGiX8fhWArkwin+b1nMq4vWN6t uCU+cLo65c0mja0kSoPhsX4yXQ+b23DKrOS4RVTZX+pzugzdWkwiXmThWopQkQ3oVUSqPSJT fDHgkYhwCDb4TWRP8OQOvB0aUXJ/ZNtMDRpIUuvwwL96Q8cn+/4RIindUx2hddUH+7r+fC9l vpHLkR1Z9Vw1PqSLkOtipxA7BlHhx8jyJZEVwGMr3MPHyLJ9cZH+AggT8AWh+IUPoHg2q876 3QrvBHNGcgzX5b5+bHBJgL2UN05nnWexZptZWy+lIUvewe5FFqCrEZXYAu9V0gTLxDHEfKKD X+LyV3764GJOZNeV3WzN3vRj3hUnvXuMGqzpdk4NhL17TgXsLA9lq5l0mrCbMg9QGwZh1Lyd AraLIBpMImaZR2IVUSMq24cd99jdUIQv/GuiPuQR8HjXAJmpy9xq1LnMD2WzmskqrBYTkovr WxPzdkb0gNUJQv975ydxH9OUzAHfHNiNoiHDiD6hLq9FINpvRgOGsZ9cG80/TZSRn0hR+s/A Eh/GGfLCzkjJzC9ep+6fhjmr0OT3oNMskW3lT/F2SFuhDIIFc7Y3CGZXAis8bzQoFPaGf+w6 wDNHBmLzZjSdMFr3+WSh+ifbVifAbILtfF81dYTQkyBKTQ70WC99OT4/bmmPyWnneIks4yCs V3w+GQS4AEiMUoosphMZ8g0pDiyPWDKlgwIp/fzSvfG+eDExVuPrWCtn/W/aacMfr9LJ7rCz ecczPnRisYOeavRNmDkjnG72TJ770QWnp9a/lw/dn6vZruoXaBxSs5sy2MJ9hev0w6/+lg/N IfXnJ3Cv4e4ibc0zDd3OhvAG1Ol66AXiifdDs3CdryheLbSilfBr9c7Mn3iLpDhQRdv+swsC albQQg2nLmHJvPFJwuWixQ3KyFlcuzG3SFjOCBkKEZQcPEdPHTIp/SsEtRFmlnz/SsEpycW8 w3Sk8vEarU4QxulTebQj/eF2Fn3xvEYm8mma6L5QXiMVOQsRecJ26CIfYt5GHmFQkUeyBwg/ hgnqIbeMqm0F1ZVi0eoLk+iAklPDUdJb8Z1DukzhzzivTR16+5MEZpGIJWa2TlwLJqQ66XJb kC23pVTyrjmlF93V2GWnHiTsrViEa2hS7t/OtgnaROG8adWNaQonOVQGRpx34kSY+Tg3cyKo +4EuPxt2U3ZiRjpVDtxtA3eDe2TuClOfY9LP//CNys/rDlrHGykJ2H4P8+5j4mD8gwRWuxkG v88nRY/O3mwPS8CqdgFeLQXb9JK/U9mU6KP4W/5SRbcHcjILuqx+rTx7rXhYn74LEFuejH+E 6+JRWU9AjCj8E2yhFgaTX6X4RWhAsJVKhNP9uZW8sNNTaImJLfDsA07ZC+YH920fDHhpQTPL 8mh1iZsT4d9WTbYMuH6vOWL/nLWS3Qm7YubBinkuuLIqxDPJvLdCt5oaiyzkvh7MgTO47rjn Nu/GqaSaLuoUtMWvVzWbzIc3PzmU/ijXjkAY/3CpjuUhH6zRQWwe28ZDqvdPPvQamKJtara/ XFyjeFs7X0Zlc699mdvpY/Vk2ZNO+lmk/x3AVi937gkMa9vqb3YGXnKG3ZF++qGcDI+pEe+g 0OBp8STDAs1Hi+6b+ESgELg2vHbg307N6By5LWjof8GH7gDAZmSW+WGIcViPSNGPvUXi6Ts2 D/w4GFBpH+Wu+IRjoIbTXBmZ413mvzyqbAP9rblu7iJKr+63brarQBjKcT/2J4sd0PEeXdgu uhRndHraR2L9T7ZViO64nLjDFnnWdi4MuPUtOo4b6yyPH6HMJrZZLadVAya6US+nWUnoVkTH pbv8rOKbtfWUzbcKrWY+BlvfBPbTvc+efLOlVyNuf/FHeZ4XpkmJCgZwMdp4DOaAG7hw2wXe nmwF0ZzfZzDaF2RszDc8xRKyWKU/qQBIoGtzvsnCnIXcoiw3JSvz7uOQ9H/lzuiWl0WYtYqr 81z+5+PCCPK2une4KW43k1QSS1uqyErkQ+YCEHKNMbxWf5ijWX/ACJ5C6B8T23/eG05uNRpa rsbXZ+TkoPp95l7ZE634916Jf2mnVgFIefkmfApMwbKXOxf6zgg5alQrXedRaLDSZxusYx/I fWvOpDMx0erXW7cSOpZ6SpWkV9/h5vru5oERAfyXC9/D6Whm9Ps3G7J4Hzktnsrg1DgPubrj GfftYKmgwbhXTZFTRodDp1TJOfTUFT1tQ0/NO5WbDXt53bzD6Klxk3x/VU+cN+wF62hSwGmq T35GFVGy3+havwwVRaETWAI5SbRJsLA34EPsAfiNa8vW/ZVpkHeMgaHXwfUy9pXLE4Pdvj08 Z63mNCdGutcPAGJayMJvEmYuo7HP4D7ON+k7NrN+GoAdRKaTH6YVSPl9rC99Bq4cRP4nygzu LX0bzBukeH0bPOi4iA+dnO35qg7ybdLHvUrpq/z444uEhV3vQs7Fldt69W2HB98u4HYrDK2i coYKwNOzHW7W8CH6TGrnKaNXB2ic63/zBqRJe4FfJx0D18yQhh+DkWu/ZQPnPr+H94A8tCqH D12aD9z/1Ct9Jq6D/cgznSP9mKBvwXA/Yql7s8f0g7TzucTkHTNA3uz66gAfaq5VHqqz6Nsu 7MXnIpPnUw/GNx3z2/CzRmi7Mw79D+I+ALp6OhdwPyqM01/J1rggjpdz0uWgo4GeMuXDRmPE I49dZPqV26GRaoXMYwc+lIFK/x9z7X48HjJopeeVzOlLbRZ8ZwLxD1sOx8t1J5WxelMgp5xk WlKB+mzsI6066yF7bu5wsCOseowsXl2xZz4vSuiZD4vJ1krtT83MJ3qLVRv+Kt4XXEZoZlgB E8444/0HLyxImxK8BYcntrVv6YpR0u7qE1JvFFtqZukXVd6467B+b7SxXAL2ssa0tpVrHz/9 MWh71GzaD2Uxpm0z+JBnwPv/Xdx7/3FJ8FDc6TjJxFYlhvhf0cM/HoUboSN/OeVLDJ7MZAzb 7MdMZEZkz3GVVriVuLygybnJbIkqX86Homz2R72m0T4CNJGgXZ+gRdtgHJTDs/5J/qAmhqz1 8WVfXOA8c8b54MgMjV1TVUPplam/GJcv0KKHvtFP2VEg9kaZP4Zdw+33Igt8vw5hjDuBWKJS AFINmqcHIv01vcXmMaqVsR1eiUqrzQcGgjHActg9Y6TVeT5J8CuSUZnmPt2Q6R0uR7oUWdhw ofqylMPOiqNMjKs9ZnAv8A3HxVM6Iq6NOGaJ2pe8wyTdhNJfiF+TBIDbcdUOSfkkdntycWA/ 5qyNfNu2jFNuCxCHt8Ot0+ZY50Vi1MH4doLmqihZrJnqeQrGbndhQ3U8HzplnYhr4DjeM+VU 3k0W734OH6KxAbaV4xQcFO5LXTWRJPJw25ErBoFrjy8eGy9+8iW3+k7wpvxeYK9b50lZWkol SVc2dllf9viwfxWN/atDR3Zv2pm6XftS5x0PIC70KHGxr3Py1A9b4B3yDbdDPzR61sKrweHL rN8bKr9gP4Qvp1d/8kcP6SNo9t9+nuEzB5ogT/d/D4BSqJtl0Kai+kgm6WmK4/39OkCi/kZs 2M3Mq05k3Y/MswryXFJh4N5TJ7ENcoEBu0vqDdZh73ac189y/z6ykc7pAoYhWxzcKH2LpHoF 83Gg9FP9/bq/BvvZQdyUbm+0jisx36IilfWL2125gAyr5U3HEI9qp8S24jgm0cnrtF0fhkie palzTjRz+hIDLhAuZOUm5tBPWA/gGrhTdAdNOQWeY6lCUjdGPBwIOgAiPPrFDTFfuRIH3TyD JtDRtM35nGoPwpTAQMaFErfq5MPt2zIAnp3vxlnFVbL2IMyTSnfOXx6TpUDL0+0uvCYZ5NGb dN24/ty5KMeI7CkI9DPHUi+nN4nJLHaMbowqxH8UPxgXCNZ22S6AeXeQyKho57rZUfP9uptl FjUl99NkIuU5Jwzasqhkl3SXg9EGCm35Bcoe9Ba8Nyt+tnHBT0W63tbbtj/7837hnnXKlna3 aZo3Php1bM8AsMRkZPOJ8F1bnXi4cHQ23P+5fj1RI5wQYqrrsWURpNWcrlghsujO2N56gIvs 9AkLXNdjGegWxbit6e1mfW4fUk9XhUGMkWW7sFiH3ODGtvJqJ9TtLV/KtvLzGzjKtg1dtLCm c8ixk9dktj+XsSPo6nvGoqmF6+UzLHYWi/PfBkCzYBaQY6PBgJoEj1ac4sUJED2hgZUtnKpi 6PIHq/WHzOOWSSPMwCoF3hcmP/ZitRry1smnaUXdaLqqnYpsxrpMBVqzXa7NXIIE0PNxn47c /sRDHoEeNpvW3SmXDOn2s6TO2a+VP99n6Htfj/NK+JfTqQshKWywxJJ3+6miIY1gk8YcoR1Y KRJ3jGqNaGVfWFX5pHwyfniFxfon7F/nMeWh1NPMDdP2kExGy4y2P/oIJPGZ/QFtDhZaWKSh /W5gqcsyva5tIdDqPUgwSHaeCrUYGmUtdW6viojUphcHBB5aM0/x0ZLbPslzz733Sjnv5ktl FSHqJPq1QFRfUzcCARBWKmrGJzcyxm3s6rAxtu+zJl0tTwfhQPSnQylq1aK0/06I6uBgf4ny qaZH/v3nzZzB7WyrNwbKDQS/gPOqsmFKKvLVyazC6TZXpj3L6olqVNFaVqmadXlubPeO+1w4 2nXrg/PMuanPN5tepC3vViobE6Ai4xtNqLoI12QV/6sNq+ixNhpxxIJv0gqGtFQ4pMKlWi2E QHe1Apm5tpGRf94iAY1Ka5gaIn11Xn104bqym3PVWozxOtZ34QGeIKj1GpOPAsG5zJiYdpxM 4NfgsMggYnkoodTitip9I2Fk+DKFDkJfc0vmxoOpMfYxDyyDGJvoZJU5gT9MvZG+8O/LpxU8 su42MEJ1X/IhgiRnjuXfdD6kK82HHrRcawJBkgRviNIRiWmV5PZhI5EL3/AhGMcudyUtWX+P D5Xhd5RF7ZnOh6gkrotvy9D2DC6HD7VZVXbiamz7lUircpg1ctV3SWvgwTpqfw8fSjNj6iN/ CQxpRegk8Y4JHrC4Dw/WCxoYDoIIKQAEZHRe1mr0HGbCXBdNhC5bHg9mJd1tprHDBK/cAZ6g SwvOJUZbeCKnljzku3UE1/FeYoKcktBTU2Uc56MlHzoARhXZgUNeh7x5KHi4geHoqSnTDXT8 veAdr2H6NMGbTfsxPfm4ThAy2Z0bPU2U2+TqfzmAekfrkZNusEsrVvz7qmI+75N/4RU+B8wF iYuNT0ZrIJH2Pv3sl3CdA+MGLSdJ68GgN8GpqcW8mUti3CAX3flbbmA72+aSm9FbglNQ6OlI AC3ydKKL0Z2sjQ28bSCkeDO2AgQA5m7S2KrKp8eIn5uEXx6TaVjh5skU1Ksu1JIlJfz8TE5v jbnnSZ75fI0kxq4k7OgbA9q67WzrVIkSbbKeZN6KpcmbZUM/7LliMlCRAgvJA05X9M/Rijnd 8Rn9VceYxBm+wfVW84Zg4GovUSRjSPhwbS3IoxW7Rq1K11K6LnCtYtSjBd/2cOaSGGnzXMzD ucm/uHv7Ssct2+soG9rXONTAuJofr0c8bv3MddhUeAq+dSLyUQpkGAIkd/DziwrG2ZP5pWEI ZGd0s3dszrNO1kekfryr5cnC3qT1jd+u1/vDucGTIn15+YGFqblwQxOmH9z2xx9dMNTQnaRd pJhbfyWsobG5TENNIsYl29vnp5Qf+BASGiPOpzvADq8wZpGySGhg0HOwPZs16tf/xeQgQ4jr NEcKaJHrW4bz6hcD6juvO/npg/BZYZ7OIUWPwN1eRXT88SWyNNxbi1M5zT/tX2vJC//BzBfM 3GF3LPMkBZNHW4p9FvbeQO/Pdsa1TlOKdaTQfLO/BaNByuQXL40CaQE8YHsB7PNatAY+dk4m /ane+E5kM25CmZA34Pn0tf3cEzgQmKVm4dr3JGjx+FCLZdBbFaOlLgnS3dtJ65UUN/JCfpBE EgKJa7wtr6s+jfDwizpVsPGPb6IOHS/3115GcFpKzK2PUrM5wIeElekdFahomaA6LtDbPZgB HkaQ1rD6F0uYxD5oYaE2fZHGtxc2lbg80ZYWLEIRbNBROncfSRcjUC5J7jonqWFRI+Zh6pKg QzNlMx+o0Z4NVuqe4SbrM+VgPGPnvYAdxVEd2knUvzv6WjZLyF3iYNurGNeaQlZG1yZka5cv 4OVk884o3Y9FtqjGU4b9PvKJKn8ezp/rAaTuzReAAGESC6OQAdaGSUTNM5JlGewwHjppczEq sMu8fT1lFHG4eVK7umbyod+o5C07/ZtobzfN4rH0bg14Jh6XldJT9AOyU44uf06zbjy0Xr+3 6+7C13Fd5Pc03UAYnzqz+V3K72tcksjkpPb8oUMChN3xHtl6K7rkWWkh6OY9uOs0WFn8+S90 CPMEEw9bjS1UH9B3VyZ6xfxlafj8qcm5e71JN38M3mgzKuHpq/sxRDRfGHVX5zY8O3y+n9+d uH1FTzprNJy98sJy+dC+6/Z73kkOzeUUEAO996W5Rf2OiTZ8/EejrzQzZChtwMp/aXLeWtIF VCYHYCTC87RCCRApXJzjQ8pxPNCZ3av4WPG/FiuwGCOQfRJ/cwGrEB+3qM0kUCQ+s7fu5Jx4 xGuD8fSGRXS57DQzz13nciRlvsWprNiQyHaS0+1PVgbg2QLZCPXc5nKJ1KKrSip13ym6q7wE rTfQ1jdj8Ocb9FqV09St7llVMrvYOATd3Y0Q7JkeYR3erpAPhZcCDA6QxO8M8e8EfFaTxjvG PGbKwRLPHGaXiaYrc2qYwpTIhZiow1cjbhoaN8+IzITh3lRKfStamCnfqRoTrWYoafooIKpB nophnP9hyW/wYtuhN+fWK8S3F29HlhmWCsp4r9EFFaKSZGPOyeNDNbg2u8x/XLYyqluGs7Tr An2zVnwRFEiXtZuI7to1NnALv/f6UdsNKtnpoKIWTb9il9ZSgAwPE248k/WwNv0tm3OCMnSO U3BAOcFAzdHxRxgfIqnrDePT/AIbgu1uE0NDL6esHZmXANQ5idYrXQd9MCw6u7Lgv0jwCMlW GbJ8LyJ4Da5mq3/iQ0eo5H2Bsi67Hh+W605M8teIQL5UCILp3cAe6KvS1d/NDZonWRm/R8rS 4pDW600pcwOj5lhhzuFCqmQWlWihHyEaHUVIxJExM4Lj3IfBhGz/yq8wjjeMMclImYJaYHae 4zoAXOs6iVWjacusVDVNpSEBuCDXbv+dDmTEiLyVu2yLVUh39Mv4l29UK0kvrA7zQstsVlEb egXajv4F4kcFWMroq7bhuvv50O9AM/ZbatOz9CcEdT7FA5+61bFfuNkfBITWAU3cKk/rlVGt fXSe6FZ9LbUS04LlNcCqdjn1EcQ8oqTMspbiVfJ569JQhCxUgppSg1Vj/cRe+Fkz9xYvK21U XzcvU1kW6JdPGbtvbOyXxiZyhI6B1sb2B5qFVuo5fQODbJFTd1uyMgF3PEHxtl6K4i8/NK15 PCfuCDvg/lLV/ipK/1mtO1P6y3j/p7sjjWrqSsfqGdSqHM9AAUUiMjMR0IICHmCAnGqnuA2x hE2wpBKKEHQgRBQo8FymwzRIUhYtwxYqq5DQoZgio5LSAoGD7DGAgtGGEjIIGCBmf5mXBRqC OCCcmZ6e8/3Iy/3u8u6333e/e6XGFjOgFOAcTBuj1FNEXWWSdDIXJRv1jv9cCXP/7bRRfSjA gZ7RtYWgoxJW/9mxqD3AOfg9jDA0VmT8WFINRVd/ko9OY0EpeD5e88RPhELFeka+xVmAg+nI bCfLxiTdI0yFECpp0SkhH0BOfs3zzIWrvk7qYI1OW822lgS4ujXqPvQvUr9YPYLYvCpa/Gcf Axf7ZexW5x0bpOj3EOLDUtbiSWKL7NFfFOad7O3tD4+H9L49+SUUOsV9Z2DlLCqPe24zsd5N WKGEHW3Jsh1sNDu0Oa3BbMLmBdENvw3g7Mr9yZMsjFDCEolR1+GYvcjJdM/rJuG9oASKUW3c gEqUbBh9r5wpr1H9SMyWStS4eCJSMkIRtdyiPUsdLzTttTgJbv23LX1qFxRvq27IJbr9ncHL gJon74JLhiHEopYUMB6hmNqtiwIsgmKpj5KpLbJOXLTZBXVe2/NsK3ZalFQ1is2Vm79/1l/B uPt835Na3N7CvGlJTs5SBHl5IYC6Oa7dbJSSvN+d/9Z13tUZJxcu8ZKQyoTzj6gl+2pZoPVQ xV4m6+HN9eX3rQcKH+ZGiRVMxX7kA/8ofVbAKmEaya5e8VnTi3Amvo8imDaBrBb7G4VDz1XS oC8xlRbGkCcy1aMN+PFLoyI+6gTqYJ2Ti8EfKi/yj13biPajQS7T9NfyGmTHXVf9KWyFvItO 2RlFZOBqnc6or32H34W6H7GDnAdaGCnuO2Rg8kT0VlSXT2MGocmfegOaaXUKCpFttqtgzc6t nexMg7KElAiQX+kp9XHnf/+luW9ush1eCTtOnq5i61OSCkgSkWozvKIpf4Wwzx2+3xwMMB9g JqB46f1NpCCjqVwXDvoM4lFlThsglpAVzWAI3V+6LeUaL6IpkHexje8jEY3c9ooh+HYiHLNL RqhBWrfbU9J3Tr+bgB9AJEpBAOk1q88tGnVkecGBYOIsgWb/zPC4s3MnJuHj7aei1hmWBOCu 3j9zwINV0F0LRYKuoV0w5h4832utC7M04jJkmi1sYrxicBtP9dbTQzggMulejXyMrk/eauCn GSWsb598DJdx44vu16vMN0oj8fbu267SqB8CdzjtuEshVHtU8BVq2tPoFANWWPbAIIHlY/7w HcjeZvHAk9Cb3HQg7d44TIpOph/YcPbK5sPGL+IwLT7vY2mHOOz8JwU2kYBY3qlwAOmPuufR XfUJTEMMeMe3EZrl+oVXEq9ESDSfCch35zwf+o19Qh4xyx7e8IU7f6jDodexYzNEEbY6A4pm 8YO5T1DQZeI3H3wa+rKi3xS29l9V6bdZO8QlIuEt9Wuorttga0VaJ5ahnoamqwysI49Ehv18 F9DqinXd2wwN70eefLqWY5T7GzyluWQUZ3VyL9S3VqAHzKxI9ysKtiSYE7ub4zwoPV+t9xTY 8dD/bNjJctpxNMHnJUcg0bhvF2bPH//ZKs8nhqbXuZ12unfFvFk6r65uUgU2tBPjj8iBUWxi W5RYpsmCqXIgbYAfDZuQPXbC5he/02nu++dryL9VfRuDs8zxEiJwGY9BJHKcIqzq0Q81bU0B Jh+SeKwkZ+AVQWb4U6xL2RuIwgKI8ccIpuEKAsRKea7oiGF05G7BhXwl7AKQTQs2RJQ4mMFC 1xTQLWHSAueKwXOmHTiBrDGkSO5yk+Kn2saoyvRGjn2Upq85sYZiRZR0BPkP2nLupF0+/6im ObBDiq5uci2iqk6QK1avThB7122pk1u/daVunYBdHPUh/2jd6bZyKfE6KHzvGDE57tY4g/tc O3Q9XdGtYpsgXd5fKpRu4uYkLdFAZNGZQ3NLMtRn6PNSb0PccT/spiFrJawUeoFul6ck1ubG PBih9VZrA+JR4SDyDv2sguub9kdH38poj34UYCftO31MO+q5HbwB3NnRB88thS7QQyuU5qqD Y6CH6iLbc3J2eSzfS843MKLkh1HEUjRkYzunjSsMzHsNDXIO9ZYZW6wxt24PP3DRN1gxOukl qvTjKvYUgBhh1fc6B1TcmGX5MQAyBO1nl3WN6VI8pVkUvAgjEKnZ3SbbPLYM++SytBf1l0h7 wfn7wEPKiO2JLdZ3ylttBy8ldJldGjQl4VpLf8zIc7cZYsiTKFKeIrJKfzaqU+TJtZCSecBu X0jlheN4k0g/xt9K8a46xd7XggVa4xtK/bCE8wzhAyVM47BlG5iZGe8caBiQ9ibk9XQf57d/ pAofazRLPrEsvRb97KFCtla5vI7SKzFVvAnLjCPG3E9MvYvtOwjkF9TJmkHsZJMELihLKuDK upM95eEyd6boKyj0Qom7X35KnjwEefUUQQUl9M7+zzelR9/F31bC0k5BSGEpoATJPaLCaVLj lCqgJrqUMA5CHuHRSVCIGZOZoCPUA5BsJxuGaiEGJpAME8UU0Jz1eBDOTdXWJ40bqv4rIb39 16x6MbmtdjuKFgkUJzRJtmFmyAEMqyNg+pjJcLgSdliYOuWoKUH2uIfI0+B8i+rkDzIVVmy7 lh4lbEEJWV3fU+pJxaQXzcNC6ZSUzGv5FSVO5vgWRMTvPnE5Ubh7plOsZaolwGol2P5fYdUW kP5XsIp5Bb9o+OUQ5lc24//Ndq20fPmIWlgViv/KiLU88FcO/AebI0E7CmVuZHN0cmVhbQpl bmRvYmoKNDYgMCBvYmoKMjE3MTYKZW5kb2JqCjQ3IDAgb2JqCjw8L1R5cGUgL1hPYmplY3QK L1N1YnR5cGUgL0ltYWdlCi9OYW1lIC9USTJPYmoxCi9GaWx0ZXIgL0NDSVRURmF4RGVjb2Rl Ci9EZWNvZGVQYXJtcyA8PC9LIC0xIC9Db2x1bW5zIDI0IC9Sb3dzIDEyPj4NCi9XaWR0aCAy NAovSGVpZ2h0IDEyCi9CaXRzUGVyQ29tcG9uZW50IDEKL0xlbmd0aCA0OCAwIFIKL0ltYWdl TWFzayB0cnVlCj4+DQpzdHJlYW0NCvKLx/ABABAAGADABgAwAYAMCmVuZHN0cmVhbQplbmRv YmoKNDggMCBvYmoKMTcKZW5kb2JqCjQ5IDAgb2JqCjw8L1R5cGUgL1hPYmplY3QKL1N1YnR5 cGUgL0ltYWdlCi9OYW1lIC9USTJPYmoyCi9GaWx0ZXIgL0NDSVRURmF4RGVjb2RlCi9EZWNv ZGVQYXJtcyA8PC9LIC0xIC9Db2x1bW5zIDQ4IC9Sb3dzIDE2MDA+Pg0KL1dpZHRoIDQ4Ci9I ZWlnaHQgMTYwMAovQml0c1BlckNvbXBvbmVudCAxCi9MZW5ndGggNTAgMCBSCi9JbWFnZU1h c2sgdHJ1ZQo+Pg0Kc3RyZWFtDQr+QIv4/KcHggdBwiFwOERdHhA3gg8RzU8Hg8ODIJUDBwYO 3CcE4Igl4QJ6BeS1VhDEzpTtBwnfbpBvCf//9bDSx2rUGCjycyOBFDvHzQDG75B3UR5GB4Qd cjt0EH03//9rYYSx2oYUGCjkMWnTp5KOuk3+/+v//8SD6X7Uf/yNU6EFhBrTC1SyQ9BUgxWo Xr169f//+JDGn7x50KEHTp5J9J9P//////Eg+nu1H5oBj+RtR//k4F6/x8q3JBggdU6rqRju kgn1Xrb/9a9e9evvWxSWgtpKHqLCjJ6n///kDGn/kxP//8cgbmhnGv////////////8R/wyn BRH/8iCI9CEHC7okOW/W399f/3pfXEdq1DCjynBeFrrJmPX3bogRqaAY/nRkdGxYiMjVOpr1 k4F/50AiyZhqP80fLv3vxIZ9O8NQZYFxkuUEQStOnRHnCb09X6dv/tLDC2KtQwpUUf/kGJJA aKdEFx+TcIN0mv7/+68ewwXDSvVqoj8mC9qPkIf8nAvW9kWyYh+w+G+x3h73h4/+S5wUjnW6 9byY8P/pb//rb/GtitQ1DBRyrHKeThVqn5Ifqukr//S2NdBb1aqLCjkuMvTqGf6lIdu3/6zq GfWrBR5GGRxIIddZMcmPpb92/f97eu49kcLeoaaifo5oBf/x5UOSCh1ut0gbwn1dJ///+/v2 lbC2DBKxVqGFHNLZCPDC2GQxLIXFDEKGFBhSDKP/zq8iq4OwcGHBkEDBh4cFlODlyhAnoF4X ghjzQC+9SIUcgdNDI4Ef/Ec6uv9h5AjX/jyYOagYr6WTcm7+/f/fvsO/Edkh1aeLUZGudWE6 8nAvW1anV+OawXhPVEaStf3sOiBGv/HzoGf3kQHkwd9/1nUCPrCjzQC//jynDwnTyOHSB8Jv //7CVhrioahhRnXoHg8ghcMODByECQ94LBYIFCBUFgrBR//mgF6+DO6jJzdJ/eva7SsMLirU MKOS7msHp08mOTH0tv76/1W/3rYj1eGFDBR5mBj+dQYyfuk+n/tdrhhbFWoYUqFHMzI4Z8fj nR5FJw7Bwwclw8PB6wWCUEChAsFgrBRynDwnTyOHQQfQfV/2lvthcVahqDBTrDT/9vIEar4Z FHUR5ThYQdOiPHp8J+/9rbXFFzoe9R/+VZwnNTTp3WTH6X1T6/qu68YWx5EHUNNRDCjmZkcM //xBn444URH/5m8PDt2Hbhhw3DIL6vWERBzCEEMIKEqCpYWFHIE6////+ZgY/vHzQC9fePlP zQC9frIUCDBwYOaw8GDg3B6yXDwQU6A8IKCIITQLIGNf3jyYOFgsFhAoIFBKFhEK/I+/w+xw eDwwcGDg3DweM0qfPPr//////+JDGv7x//Mz///yBjX/yYp//+OdOZgY/kgNkqBYQVBQlCCp UFCUIKlSogY1/JFHmka3TOP+v///+////////1/4j/kgZwWI8zP///IGNf6yYp//3jJg4WCw ShAoIKEoLCISOC9eD4Y4eDwYOGDg3B4eOSBYT3Tyd6X3//////iQfX8l6P/yB01gvC+lk3Jj 9bf3/e3/a2HH6u8NNRH/mb5h9d+JDPr3nQ/HKcLQcIPI40EH0+n//a7WwwlYqGFm7Ef/lQOa 5OE06+kSH6p9f1/ruvGFxVkQfDCYURnXoPX3YeQI1Xx5EGR6Cw63XokPb1vrf//+u/3hKxHa hqDBRynCwg6dEW+E3p9P/a7SxzMC+9SYUeawXha6okBVf28gxVddZMCr+3kIERDPr+PIwiPQ sOELohR+SHt4W/3r/1t/vXEVeGFYUg4jqI5rDEJ11RICq/3YdkGNQvyY5EHC4jr+3RAiq/qP /nR//dh0Qz6+oZHYIuoiORDgmR3WHXq/bok/1///bXxhbFXsKDBQ1HNQL06XywNffduZgX/k nxkCc6P6zQC/1OhkhaGHjIgoIgidOnRIfzN6ul//f2uGErFWoYUf/zWGITrqiQFX97eHRAir 8eRgsIHCdPJdwnq3/9/aWGC2KtQwo//msMQtfRICr+9vB0QIq/HkYLCBwnTyXcJ6t//ddpYM LYq1DCjzMyOBH/6DURzoyh9arMwMWtTo/HKQ51BiuqJD9SbvW/e9/e/D1xHZIdQ01EGo81Av WtckBQvb3bI48SFqX0SAq1u9uiBFX4PGdHX+3kCKut48iCggcJ08lzoJ++v3vtpYYWxVqGFP seYfXfiQz1PeQzvqOagXhfRGYha/t2HRAipfePmYF6+Dx/+UdPIoG3BKgrcGH6LHXGP4AIAI ABgAwAYAMAGADAplbmRzdHJlYW0KZW5kb2JqCjUwIDAgb2JqCjE3MTgKZW5kb2JqCjUxIDAg b2JqCjw8L1R5cGUgL1hPYmplY3QKL1N1YnR5cGUgL0ltYWdlCi9OYW1lIC9USTJPYmozCi9G aWx0ZXIgL0NDSVRURmF4RGVjb2RlCi9EZWNvZGVQYXJtcyA8PC9LIC0xIC9Db2x1bW5zIDIx NiAvUm93cyAzMTI4Pj4NCi9XaWR0aCAyMTYKL0hlaWdodCAzMTI4Ci9CaXRzUGVyQ29tcG9u ZW50IDEKL0xlbmd0aCA1MiAwIFIKL0ltYWdlTWFzayB0cnVlCj4+DQpzdHJlYW0NCvzIWDFO taztLqohyZFHJFMkODocU1kDAb2H6IZxR17zI1DQtkknhkOOFBhCMS4kIOCDIgW4IOoTyN90 gbXTdzsQDHUl2vq9P66UML+mKv1TYXIyxIdpprhprYNBrIZ9jqoYK4/RWTLgvaQhxet52XDH QZMYwkgyWepEUEvDrDr8Gn5Dj2GSAL5Ie2DIL/8YYb+SHgw2sR3V0wyLZirBQ0NogYGA9pEF 7iT1mtSHnKAxEWnBaI9KfDCrjXS8h3fPckO+xXV5AgPfOyDLycR0L33+QMAaZMfsMER07XER auQKJzOhH10HajDX87TmfRtFWDH7EUOzHrYvvIECp2QBirrXcmAhtdJk0m7hkKOoZQ5Tk7Kc odCIxERESJhg65OdNBw4STrZmBeq0nskOVZVrqIi8OwthklKQI00x5Blc1SdQhDtXFZ2KpaX OyIZIck+gZCwI/vxrQPj1rYeGqD3g2cyCnIg6hiG2GmrDsRhv5AgznzLgRVUOu9EPapYQQ08 IJqTH0hEbVArRVQlJBmoG8NBO4nQuHtP6IUd35H1703J4Rj69JB3/rf9f/IR8NfsVEfdqdkA Yp+0yGB1wYQYSVQYQMJhXERpEwz0UhxWDBEOUJw0HXTnZBmMxmDTTXERat36/dPJD/QbSkx/ p9f173Oyd9xUfY/87QBi0mrdq8h5zI/DhhWFQiQpWgxUFg6aBE1LkFxRJ+C/yBAmF+QLjYJ5 CAhLQ2DD0VMF5DOKBBFZD9Al4JEkDR0iFgY6Uhs3XoFBDCIFykg+zO5AvtV7//C4sKMmORgQ 7coIgwl6gtNYTKmC+wSyLOgtI47BAqQuF//kK/3C/UHf47ah94fYSDB2KBu4bsJ7RSxYaBuQ ZhqNSHkyMaI4OquhIYKJcd9/3+v8f/Ol8J/4kMbVe+v++QLlRAh1sR+v8lx5GeP/8StlI2fB eVYfOzXqpSxynwVy7I+tDiJClWiDBY3glrXHXkJDoivrkiQibnD8EHj7vrNYY07D5EHyDDAa QIG4cau9VIEKSgC6fD26wwuONNSGCi+mk/KmHYLpBhdBDkF3QQWhCeGECI2BfIbCxJzUGxBV IgGGQMA3KgE6+3KcM+RQEnQFFBELvwiGzYosgxsXWCSyBfaQhd6WSmOphLoM3Jr9B6IGN2v9 2F/x+qkT/tuE/pH8rD7INRL3iIwQMF6+v+K+6UR68k6+1+F+E18fRVIkn8E0Qxu43CeQMFEL ///NXIXFqKkt1ja7D9OQZ7IEbspwTWCckOct0GhXTYXXeyEt40CDfrek4lVF05WzRBN9eCaf 1T+VMHXpgqdukpH3pAgVPhmwoS+xQJfafW2iHfaVgoXHYJv4MuEg94ix1DYNSQZ2ODhkezpm MMGN0RrbIT7kzDsgX3fh0/g/8H/jXySkSn6ggx3lzTJIeIg0yLjv21fyNhS+l0RXxHSruO9f avtfN4MluskAXiKesgY2qaRKYveyNAvuguRXvxDRLUT5dLQQiNUC4JSHdwkiQ/oLe6BRHBBn N8SWwIkOvFdk38GgwrRC84YjGGgyWcIWRI0HtYdVuUAY17yCD//cIjoP/xfrr2Z7G6xGrQd4 6UKG2rJ2EGoiwUZ2QBesiflQBenrNRHxfhB7JoKcpJhMKIj4od0CJICZG6KmBBCAo1SSe2k/ oKvwv/JCv+Vv/jiQXBHyUAYI2CfT+g/ra+NSIO4MpTBAkDxNVi1I0ZBCg6uSCT+yPpUy5L8U F0rRKQMEICj+kn/bX9u/+l9U017sGSkP9B9ePXOwPxGiGfd69/8lXzqEOGgwyrKHOOoikXYi LeLv8oAxIGBsz+oIe3rvWv0D1IgYZItKHKHJ7I8RHhgiOuIlzIqfBEOYD6p9A05RQzmleI0H 7kR1I3eoQbquk1v+/moNDr8U0vsfyQbxIY3adfe+Gq7XzuaDN6yCiRLD3qnaoir8/52j528g 9JgnBhEdIXETq0HNcFqCITN7Xx1BEHH3YqTHJDqlEeRuF+vUJ91Ig69bXqFC9pDuqxILgn32 Q+1vRDPtV+GrilfOtkt4SBDBitCRNlvZJCXDBEELfTHpyYFTImO2qDtMkPCD2lJj70n6fa9a 3GiPH2Og8oAx/2l9NP6DBWF0DCYqDBA/ErAfhMNUw1KCUGT2hTEmN4PKt/kf0H+nCIZW791/ 6X8qTQa/4jkh3+4InD7RDuYoiliPQXpeMF0C52oOolVzBoQp2nAhEDG8W//q+SFSx1xG+zTs eHWt65KTv+QUMWQIA3X4W/68hN6DJbTvOwgtwQcgRvEDTpPTWvknLHbX6H7/8akSCWKCdNBw 1dJYNIiO4YKCDcdr3OxAL/C3VJBhLYYutYVZItXDXKrWRNmcgRskbIQC/WvS8iwvCEGZyKOF cQzzWGslu2gT6IEAa6ZCAYv/01ng8LiIgwplfGZV8ymFmVgv5kahonafSojKVSkO7r9uSHd3 /yBAEI9v/voMzrQnuI52oiVxtzsQGAVA6S9NevdOgfIx9epMf/+//YLiOO012rhurIsKdlwh LMZ2rRHkoiQIC9OdiAxwvWtsm6pCf9DkpO5FQMV987QBf2+gZFP2I6s/lDlWccERccRERCDn dZmZhA6dhO1bzsgDCdKR5t0HpfDT1BqGlkiwSDmQPUediBed1BjgnCoMfuiE5kaD0nRBjeQT r3v9a5Hb30H6chIe6kvXSh1YMwFnHFFzx8XDSHhcO9gudiBSScVrMkC1gsygF6wQKdpQaNfI Ufj/h4byGjeGVgvB7w8GplXR//////////kldEHkXWC7lEtAyP+IciWU4IjrcEIjkDGneX+x DPd0K92uahSOi6I67CER4cMqynKxUEYIREj4wwa0GRAlMIOqe1yXOHSaX6I89aD7f8f+Gtp1 vFQ1dhNQwTWuIMFHksAx961IWZymsxHDKuJzwy/B3iiP/iiQBjIETyXBd4YN4MOoJNUwZKQk CdQiC70eQvIf0JeLhdWh4JpcIV6+vJDkx/9vOO+78hgMdYuLrXftQyxzwcQTdREaDUpzPmFG ladPbodU2Gc4JIQ7UO12uGSSK94Ilvzg0HYkLoTm6f1/RmBjd6rJA/auGFwychNECKlbGpCF c6mg6aF2k4vWQcY/QSkEHOPmsGOPoTj9sf6tQyONQwQdkV1G0ElxGnNQaD4F9Lu9eqyMctwR EZmcRERlR0HRCJyeE5BCnDAQkLKtBw6d2uiLdvQbRCDkbuloEG2r4aCOP96jHtbCIx+OI7VW n0yGB1aeoNBhBqDPIyNUwyr6aaISSsFQYQftP2nWHdBBpdBtEY5Mfrf6uu/2I7dLXDV1asNX wwShWKS2iOQ20lYLhrkQbxkCJF1/g3YUpdH///////////5L9EJJbQdA6VOtkOO8kP9fvrEf ogu+DQ6vndRGSM5HOEIvDI/j/jmozMtv05QBjW7VqDWSXcowkZ9CU6SxEiyVfW9QZVnXsRk7 w9/B/BZAxIkv63rJLzv6345TgvTp0v7Iq5rBfeQzyJPev5G6OQY5TglB09/I80n//hbH9QzO otQR3ChhRk4Q4LQOHYK8V4ZnxHNcTnQafMaygDFK9/BhWSXcZMRfkQGJqDPW+q+yY5IfXbxp 4/e1ZMdQ7URyIjbgnB1/f6T6fT/tp0Kv4ZFkZtQeOTkXHiDMPrj3qOdKTgY/+pGuOQhyMBKd B19Ef9fe6VhguJBeQKlv+1HkQEhBwg6d6It9B9d/dUMjnQhw1TteP/////////////////// /////////8mCp637CgjjgpLkNA6Dgnv0R49B//r2GuK8PQUiAsNQZUjMZ05OBiuv7LfF4MKC CpUFBBUFTI4Sh3/8f/5EA8E6+l8iWeS3BEfHjuyBEiVOt/ao7lYa1EQR1zVIx0IcIOgevWiN 3qWO+Nf67SsdYe1ahgo5QZcU50IutulajNUTnQNPvpZOBi3rVqGQi5qGo5TgvWnXWskOTHfs jnjuiMf2I/asmPh3iDNJbqnKc4OFv3utegfXy7WhBAh47+GrCkIccnAvX71ZN1Ecn6IGJEt/ IOOshMc1TKxREcqLI5LQTmoCK7yPun/62lJwUU9/V48jVOoaNbyEjh1DCRQ7hnmo+/Ooniv9 QyFkljnQqDgnvdcjd9////a4kF5Ev/uGZ1Ef/////kxUD//jyMCUHTp0HkR1gg/evdPpYa2P V4YUNRyn5oBj/7hrPNRSoFOoYoh5GaVKCDMeIP/+P/5MU1gvWtbeR2VIyodbyBEli968Go5B nKcEp0HSp0Ql4YT1//uFx1tQ1akGLGdTmkiC8luJDRIl/8kPiQ0R+PNRoOqdDk4GPa3YKDJD nHKhcRGMgdIwMQWnrW8hx+Te9P7x0O97JjqDvE9xkRm3NQ4dU73V9PV9f/2P2rcMFBqOaAY/ /hmwvAiOtCIxNPzVpTQDH/9ng+E5GQiORA4QdA6DrWiEzYJ7/SsNcSEkqIHW9ZT5DojkQLBE MSWU6dd5H6197YI46w0M54j//hka5qzr2JI4LKsSsFmsGKUECglqnkOP147ww753IESJBDUN weGryNUf//////////812oQdPX3ZAiSwvvTtR5qyOExDt067yTnjof/9+GFx6hq1DUZqjQqf vk4F63vayJAUHHxI9BMj8EJKSxW6dEY5Y/W+//2I/q8PZCSShzQzBl4vYiL3/kx8Wdfk6D3/ eiGiRK9b+yNysxEclxzWD06dP5Fzp9d+2EqEg8gv9aw8eS4s1hiu6dEI6wTen/+nwwwSx+Gr VrOvB1L/7yBEli/ulajyQJQcJ/eRR9Bd3//rXsSDyWYf/8f///////////+ZFpzsWNYRBFvB Lp+G+hoi49OUu1kXME9LDSpuoTshIsGlirCV2KtMK0GFDCahgriEQ0FR2rzkYMvJUIi0HtEI Od3qhfwvwg8MzmJU8REH1GdimYGTI4Kg1oUu/D6T5BB4/yY/KXY8i7BcZTmXODW0CF66CwYX p2CWQg+mKIG6BVhonl0MhC4KGC+SVq0/ScGl20HDSsGc5Dwc4cViGhaIR2GqekG2F+nDC1wT p7qgw04hnw2oQaQdIRaQcRRCQ52KkkG4RDmRLwmoTVBB6B7CDeumsMlPjVJJxyQ5N0kOu0Dp 9IhyRjV8chhSeHaDep3ILlYNCGDiDztQYfBhvBguDK2BFhoKGDIKDeDIEFKhuQYCgeFDyJCh 6GdihGDgqhRghU7SAQSwyDOlInn7RDAWI6BNYTWgwWT3Cid+Ej/zoeH+T/StpYh0//ZsJyS6 GMiB0DhA4S36I+en/ULdI7CGXsaEO/5DK379hcGuIeDwyWxHDUS5wQOnTp08iPmYGIIP6b/+ 1MxlwS3mNIIXSiPkQHfpV0mmoQJo1imzNYLwkGCQK1hIabC0En8JNr5AxtKFJaDyMRbTVTvt q7R2OEhcmGiGAs+KQz+KkCggY9Mhkn8pxVNPTSWQwxaEbb0HJP2GZ4ap8t/GNP9pa3rXkWbi Kas1iabwZGOUEQQOr9C0usGrFPT1p7wYLkR+sclBwQb2pSzs/GsF9q/BxYWk9rD/aw0oetri mD+GCw7B8hx1HwbNdJvba0DYx7UGCeSHdvBpSYojDCiCRqBdxnY0BC8oMhmiGK7Jjo+BiCHV u13kIDQOGvwVCP2pDjteMmPzQNjJOo+2EGIztWBhC/mZKx50Zoe+tNPvh9+kGTHkMZ4ycC/F 2qbW52B4gwu0sM5FzJoaDHw+Ihp2U5pgrXrBEPWNhcrIFwgaUiiKVQ0O27aKSyOyhz+q2iMa D0IpVI8ZGDCd8QyGBiaFfgyZNN3fd6IQJV8YaRqBig/OxgYQkHzTxOkCddLT/uoJ18XJcEWp IjVKgyExYvBOSHJDsRdhSGGjrw9Aou5BguoIL7HsakvfzWFyJbabCDw9kx9XQ2mhTuCCBpYd Bjc6hjIHmzJcHRGOTHwyDCWyrKGCtfBqk1W9qG2GXu19YdCRCL8Rwaqnp50gbtQ8hx3UQfYV 7tSQZ4xatZN9tU4NmwtOwld4MKqiMcRjWyaGZk+Qd272miRAgenraZMemg9BsrAGGg7QTTpN ZLoQYSH7cQ3/z8RQ4aIg5GP+0iBgPcErfVhaB/XegZIZMwMfWHhr1W7DBR23qsZ3w5NzzOOE 0hhO0djhjxGnStBPQMGQcMcML9ky5BB1YJUM0hS43FlPmDBhNZBB+qIQjX21SEZoBiTH7QQv UeH9xYZCg36ZJX00GmQQf2RB0KIx/GqJwMMfapKOI9TQrflxnfhnr7qnIQddNoWq3SZU1Wnx Hq0a42fc7ENOH+DTv9JeJDG0VvZMgz2H6ydPryD/d4IPVQwp1BIsFFIOLS+4fmYGCsgXYJEO O7dhqSHv8f+kU4/+2iH1EcNaDeJ26JCCbUR+Q2eNWqDhlLy8XFMchx2GqUGhEQ5Ie4aIGdNJ P6FaVtemvDpRFEmfr/9Bt86gx0nF19eo/DX87NYvMFkYXysAYJfkgIgh7I+ko6B2K81C0lsK 6IJU7sVSDCIYEbkGKKZ8DCIcd2EU4EJ8kPfr9fBhcl/vWGC93iKil0QPvI90qk1KQbTakMgg 2poWsSD/2uXF21I8vXrZBczERkYfd4chlDx+vv/WScFXvxFr10Gv1JbKyar/R2MNr+p2jBBj 0Ns74aeLkJscQ/IZ1giv+h/kQcjfrpK41V8ar6VToP7hBlICXrTTjSqm0tNdfb1ko7CruiTk x2Uva/q0I/3X9x/Y8OQTXi2ttdr1wRxz+DjFt+6BpSEM6AXnSCB8E0G9Vqu1jBkpCkjcjdtU tx0lmYpwf9CQsgd/9V/X2MLXSG12u1BRqP5CokPYLQa21ocpCa2yCSSYftc/F6QSSjiIf9e/ 5AnoUGRY5oBghu4ekHXvv1ubvvEjSYyEc4kxxIwJdMpwkgR7ScLiE4KyOIWRAOIkpVwSO8Gi LbgiGCZikOE8EiECp7wUJhOuyHH3afgtNEeWGv1oPFYPRFt+1Yug/8PV+Gr9WrUN+2kGXuoG D04xh4aTw2xVQ7tGgGINUDBXDbQ1EGFI3yQZ+H6aDJAog1W4NKmg5BfdFq4OC0HkC+xwqQck BsrTZqBcrQfWRAcgugt0pGwwEQMb+rIYZwT90Cr3wSr2nIECj9glBUwsVIUrJbVWurUhgXdq QzigdqQUDZDGyo1hAbhxIMGFtc0BC4ob6FnUCFtglJbVc+BetIhoFHuQXKJEAYjBSBH8jCnx +TgofpqTinipM2GHQae2IirdXTsiujuzTWNk0BI6BJvSTaoIhx8zB21CCiIfUEFojHLHaOOC pdK6ErZdIz+n06F+u3xhkcOvjftdsh5wVpkCN+IJhBtLWw11UehkDZodzQDEijkbtO2Rd1pV /jtLyoAv6S8mLXvR1BizwcciOUOr/WIwhHVWEn4pJHcggxdwmMkTV+h6tVIcfdqirAwiQ9uo MFX/NAUDCuI6Y0/Mz/pkFFLxeZIdfERa+4hhRx1kC8gh0jzysAYgnDvqg/ra/68IPIzQ2hHC pBuiFsKgQfvcMFVvXVp6/vStftRcfxDBPtJgnt2ZmczxNVhgkmg8qyRBfULHp4QyMHDX+Nhf 9r+zqGIa/aTgyi/xWO+QNrKQdeg1mYzFX310D7/ktl/4j3/7IVza//ENv/pogRuf9VfXav74 td/OyF18a8Y4ztxege0GREXF0p1Ai6fIRKsZHzrCdKZj+Q4798kPb9r3/Sf/GmRw/djyBg0T +q4cMsfzvDaBhcrJikGHkUcivRCGHeEIyDqPuDNQUEcfqQbnEewYN+D9o7EBh4g7CnYkC4Ml sQC1OyYKBohoVktkIEREEDyDiK4Jbw0LyGcPkFFCKORvlIKDDregZWwIS70DWlWGG/9Al/ZN 0VoM+qxEqoF2KWus1CyGgOlBEMJZDCddORFaqg6B6piIMKo5F56B6X317//yH/j/95DRdHkR 8jouoiIiMgdCyQKtMFprQugsijhar14Xr1/+JDElm//eORrlIUFrIwHgskARS1BfkJf52Li4 eiCbPGnB04dOGQY2B4Nok5b4fvg/vB/Th4ioO1OoQeiGNieCbVBhguNEJfBA52C9KzsaBfTp /X/9d8lsvX4399kE2Rsgxv9eselktl3mYGPv4MjmX+Us0IvsHyXD/SrpXUECcaUgRsoCCTJj oFR1BiCWtS5l7XEZ3MfxrpbO4KSHJDvQIgmnuIX/cfIHJscFXrJdakGFp2W+C7uwoW8RggtO CBWlCxmoMUQQe4TwthLraX4MLxjI9iOpIBd4MHww2HDogRuZCBO/D8gdzQxJmzMhqn/+doAx 698v1iQYWvYXBktqv8cj2TNsto7GOGTgX6d3tU/rf1f1BBzoDEd0S7IM3VJuQzRCGjX6Sces Jp1a0N4+01RBgeGFWShOd4Yf+IML+di91zs1BDqMfWn49P6r6BbbvUkPZDGztUlJjtA9ftdh NenUYK4q4sdcbVqGiECzsXMiAIiludqAzUt1uSHJu8P/XdzsCReNo4FWOIiaDY7TzsUFGoQN kx9MO9MT3Ud0R/PghcJa0Kq/deq9hq+KOhGxb0D2krhq+wrWdlXHOwIYv2u12rYYKyDGylP8 6gvsLaTj6nY1yPYg7SBKp9BvSkI5totCR7/ayN3emq//H/8SDmC9zs6gvwv+tngjgKoiMhx+ SHt/v34j98kOodqDhqIMOdmRXfnazKbCYj97VqDJbEVGZcc7SjLh6HRFHDodcijkcPTfpL+/ /67SSsa9bS2mrSUWFH+ACACAABgAwAYAMAGADAplbmRzdHJlYW0KZW5kb2JqCjUyIDAgb2Jq CjY1NjcKZW5kb2JqCjUzIDAgb2JqCjw8L1R5cGUgL1hPYmplY3QKL1N1YnR5cGUgL0ltYWdl Ci9OYW1lIC9USTJPYmo0Ci9GaWx0ZXIgL0NDSVRURmF4RGVjb2RlCi9EZWNvZGVQYXJtcyA8 PC9LIC0xIC9Db2x1bW5zIDkwNCAvUm93cyAyMTk2Pj4NCi9XaWR0aCA5MDQKL0hlaWdodCAy MTk2Ci9CaXRzUGVyQ29tcG9uZW50IDEKL0xlbmd0aCA1NCAwIFIKL0ltYWdlTWFzayB0cnVl Cj4+DQpzdHJlYW0NCv5aRRQmYEqg6SeEiMd+EH6Tf3/2GR34vtrYYShjhqWkChI/lpCguQRQ GQXGSDcNk3ds+Jsorj4eP/5aQoeHve8PJjvsPhh8MH2D4MPh+DUR+WkKDPvId9i8HDDsu3bD 4cmnb4b8cPe94/+WkKMzLYIPoPp+Tx/D+v7f/d+Pt8NpS0isYWDpRqWksKMtIWOpgJVB6T1J 29JB/3vf/YZHfi+2sMVag1BhR/+WkLiwiGipPJO9Mjd6p/Te/7Xsew+/dKIWlqGFGWkUBYQO g6I3Dwg3SfyY7k2FG7t4d74evuGvhsUthuEobDC4ZDOyBSq2IYUOPhYRC8iyaUIIbhK9NE9h DeC9PoSDolkSx3LSICSHHybCgFwg49psH5KGybg+kDbZwP6dtqTYLC7bDljAl7f/+gvb4QTe GOEr3hBNpPQTG8IJoPU5kdhocRYMLlkDY/0WSYTsGfOMgw+DHDybEpS7UFEnoUYKWQECwpZC oCIIhhkLAcEkRMcJSYbqIMPIV2WQiDeFyKFP1DDeMOVYIHuWQRIMYOIQcMMsiBZLg4YcNBA3 DD8Nwcsgbw8OPwdtuDV8WH2DSk2FAMFk0FZDv6IYqFdAw15MeRA8heWeFPseOUV5BdkBxbyG hkTthwZDYya2HJsVgRDYZqpNgoEkIIISm6IMajk2LQXQYak2KA0ScQYKTYUBRmZDkCGQZHII yK+FeQLsmr2g/IdU5BgFosicHiWQNnAmzQ5NlmxJDhPCDNuTYWCBXCEHTCt3VUDRJ3ikHTI4 emQwe0+ScIGD+/CLITC9P2iyDZNj+EMP+WRIb16BA21+gw0v0xCXUjjRLHWIug3C3Tj9ygvd hMuPXoQ433b0Sh7SqStybEhMe7ybChWWT4NdPzBabX//I5mBtj//GH//df8W//ZDBeC/wyDA Ev4MhnUL+yx8F/zwo9cSixGJTv//64yErLSKAY/k2FzLhyyKrp31yyVC9bRBwf6IZ0+gpIfJ vfW3nxj/odff3fjt9UHvQfSkMKTeGQYBIYUsggPYosisW0WQbVobCLIXCwwkHFMgR0Sx+nfh sdfb3ki3w7aVmZ7VhhbGGwsNMQoaYUtKIUFTL4T6Iqgiju8ggxBuMgRoCYctIMHFuWknEDy0 qZIb0GJqMZaUWEQ4yMnpAgOQfg1sgw+THUtKYaKZb8mOve0fF+4j/veWkgr+EQQYLXIEaDqG WPybxa1LdBr7j+z573zj/fdu/8aX2THH9/4tfLSmwwv2P//feOw4cIMGQ0awZCAvYMqwsGQw Ty0qgoy0i5Ry0jhKIEAinzyQ+9Sx1D1uGH9sMPfhhyygpe7cEQdvq7ww6bHhhybCYGL1DD5B QzqyY4ww+iBfZSwfb9yTljxDQbv+534KDIpYMEHk2KiOE3+nIgItBtkY/1uQdZS0EDJviPZA hU7St3oyBAI2u/TmSmD4YXVWjvUjxmSyJjtdqmzIyrURnf5IYMElZkFMbWmFG8JmGS47TUML arDCkfhgmQwOrCmgU+44LQhxDCqMIQ6ptOIsLfbkx3JsFmwthbpSY7k2LQ7CoNb+9M7GA4cj AQjmN/vTKkC4TJUOQRuCv/phVCFure9VXYNfXI+f5rZtnYwF4qP18iqcKgwod108jVgmlshY hHFw0xX4WPhCDUGE1tfKXK3eINbSKsbbaB09yUjIiiQWPhyDALp/UjspzG1yBAbr+kLU3X1/ 5LCT201h2v2HDC0G3bk3LHwrtD8gRoKX0QIkCLbSbk2Cydpf9ffeIjtWFX/2+1Efe/ybzDZh hO/27ybFgLwZLQpMoaE1hb1tYWyORHAhBlOC4shgeg2Or/xhNNphJsUwa1+1KcZDIjgQVUhK uTdiuyQ5TknGqhA4xIMF8NPkiaENskOTHyQ5MfQTwqIcdgwRHQYWq8RruRk38k9xEGut/vSY ZY6M2RYF1/MiBR3a5EH6+I2XMLX4QPDYaGeLuKeS/ryHH3qgyIEk2EwMRXcbDp4122IpBohi vy4GHkGA/IGA8kP9EfuQzh7ILj+l81hjkiftqE2iT+1CdrtQX+N0g9GY+DBDQYSwwu7xsLvI aiLRBvY1fZIdEuW7jDIx0MkkWQyYb47tybEpuJLntSROiBFVru5NikrKgYgiCVWtrFonAv6f 9BuGscf4OTYUAxkISsMiU5Gxf+QxX51MJpogQChgg/8MHapb1IZkuBhMYUiIkYCcYuSHJj+D 0xkMZKsdpOt+Q+m2MgXBklv+8gueiLczMjgQVwwzjyBhJBB96iGG8J4ytRkDBzqUQgcmP4jK oCDTakLNAzIIERBE5NgU0+vB/wuZGGiGcMEQSvGrRGCLasmPIwux6acU0EGRAYIg+hEEQSro m6prtIM6AwCIeoMKg6DfLfuScmPaBhJwgg2Naft69PIjx5CKNHWuv28kOTHfqGoRqaI82m0g 1tf9b3eIyKoTcgvUw1ByHHdq3/9iODpwwck5Y8MKDk3vHZHfvXg/KcE9xYf7TF+Ipo6BnkCN Hg+uwd61H2s1hjVfwYcRhoy1IMz7tZBhIMEjUC8Rg3QYUhAYJq0DJCOxggmg7QyD1sMKwhyn B2oLVwyDBEYaJkR1BioTQJNIHwZW7oER0DUjHBNAkGESALonzeLchUgKCEMIIEKpNsOTYsBf ogzGzQxNZIL2THacKnIOnDvOlcIqAX93g+QUM8gRp9B8jHCCsmPb+QdOqQN5EAXg9ghxHt2Q Y08lwr8HisNckA+RVlPDeHD2DSU1iYKgVEM9IYOQz+QMBknTGpB3IGC4msGNoMP6EpwwGlI7 HYUIFgyQn/BMMKs9W1kOI0G/vFruyDAenBpXZMe2kPdVIiktmpImhEWQYDmVT/yMQQaJgihm ZgiCDEsizQRDh6rVw08jkgwguEKIMUf3vf1QRUGSY1pB/kifI9ZcLGnIRWQQYQfW3J5r0w2T HxHIGA8JBpyOitwf+iGcS+iCD4JNOEJoBfH7f7yT8GtdW794aa33FZDjt/johnDmYLmGIYRq DPeskOTHyT3Yew79IWGTSEiYjrel0QInCDBkCK8g1hr/7fUGRB1IIIB8cRe9Y1xGQILv5rFa iOKzJTByrHEpyDQRDCmFvkYRkBiBgoRBKyf0wwmnKfI6I4oIgkjl1oYTSbsXaERQdjv1YTCX I4tO+SHLHndQLhoGCOrI8YMxW1IIqSFH2FS3IWC4URCERajIEAqJPeP3CryQ5MdmVYP99u1O saGuagQiI4+tzIGJ9WuMJ36YTQf+ZJLftR/yTk4Sa4Zbq9TLWGxG00EDWSJxFPsRiKTNsqD4 4IdVrbqEH2mvbkXNByQRmeknybFYMOGE023Cen7apPq0U4Li1aIEBrr1aqTf1BkYiGRXBIhn D/anwMAwWv8dofbShhLFf+pqBA15mChjaOn1+SAyMukx9PdA2P9BEHqp47UKDr+nJjkh2mag XHYQMkTDdedlM3e7ohHhcGnYNhBLndTCw0/4IOp8yUkDNUhGGP7VEM5BGPuNp+RBIGIgwcKs ML1Jj4/5B0jKqMpYUfa/v6UkIBhMIg618ML+rJD4aVAyGetmoF01MtS9q1cbtGYF8mAIREeF TBUQ5P//////GLGLVtkaB4Qb1BJECAWsdhkTEp1kOOwgSdhNYRDOk18kPdBSeYaLfxWvG+Rq 18Fk5wwgQYaHNYusK/hY2kwwWiCVBpfqVARgn6Z0hdBsdxFWLcEHcGKdNvt0GiLGDV2QY02E HCcIPIJtUtYaZIdQeH8GdiBZNyY8MJWEIyDGpgKQ8acMNEH17ioYQMOGTvCfyIDkIaf+QzEr pAlhdPahzU0GnesjVhlcXJhhcIPYVQqaxHCykBgQxWnjNQLxf+p8iOZkBjYWEHaBJZIcmO2t 1jCkeYUXakEGT4GK3abh+hYSi1BX/tMgvqQIDyBiQbC2rkxyMf3pBggmskIybtEbhzsmQyGK 9fEY/WlLHcJuCZHbB/7/v7wmHBbBuNIczFNC3b9XEPQhldaAwQYSNpCwZFtDDD/vT/az4GBF EM4ZKRN+9cpwdogUGC/f81CjkMDvOgMSI81AwP4x4RB619AgwoS1lPZGCuqeRB7jBCKjkMM+ EGxUmO9YeRVmamXFIWMwPEJhpKTHdL5Y2QtYSpwg3phr315XMiPlROYQaIcdoWambaT9j9/v 4dpyQ9tVg+6RFiZan7//vv/TW1KsyphYQdMxf78rrAFzMC698kO1u1cIPdJBv9vS1khyY9j6 RGP3irTrhNx+8K71vH/CDbqagX7tJt1xG7//XTtGoCAqeu2xVqE1+yQ+NLpoKsjzDCW7VwZJ WRkxG1UeoYKunY/a001iGFwwo103TefigrQi4tR1JE+16IgGGEW9bakIPaIgh7SDTeyCKwwi 34GCnJo6mGFCoEQQLVqGFBqyDAgVBEHEBQYiGkG3GLFEMM9UxgwwSttBoN+4YpkQHCIZ9UGk TxYSZDNg86gxuZFTFIPOy4N5Djvgww5IcmO12rI9tQsmPtEnJj4MmA5KAMVuuPIoS3X364Yf /3akET+u9/sH960IyBAe63HfgwYXiKkkss55Kjb/GxGDglvRJAMGRKEv7VBwQIgUP5klzDWi Fb6kh0+giDYINpslwL5GELFYQfoFglTakF6cEQSSp0IYQaBKEhYYJB7LshRAZkYYMK0IYIIF BKagXHxFOx4oLsLv+y3Lxs4SckPUhCxIZmhrmsrhYZrBILiSH5qaYavkhyY7wmR+2nhOCeTH XhUx+t9CHhraY3+iNILO5gY/06IZS5le5AjQa0n3rokO6oJ1MwUXFPtRFGXl1Jj/TyPqf8gg /eQtPt/6f2mHJj9hcgQ/39r/yIPMwMdYMkYQMf/YYV6yEy+GmFxpUwjJODF/47UhMREeMQYR krDv8WjQFA+dnj2cMTIDKPtLTghFi6VqypkVALjRUmXFyrmODBZTiAiD12RXSp5qaDajhBpq MIgQiF4TsGFFO8jDGGo9jTTwRDjZavrmRWU7EAoK6wBhOQo+SMBmsGLkh9B1OOF5HdEnvSay Q6pEY+m1hyNCr0H/1UR6yrq0FDkG0GvT/t3/mqLiamXDhB4TCfX/2iMcsfCjUJ3DSkETput4 6sRohnIW8hx2aAojjjkCA7eNYfX/Jj7T03MkARvRBd3IhtUGCv/++10DDp8jdPUbXEe97Irp WpOH3r8txALtMLeI9hVJDwwkg1fv3ClOTQYQ1kMZcUReSHik/7v1CIcQhI7dpBByXOPw7fYi vQYMkIJzbCkh9Bs1An9/d9MfIwYYQdr04zUC/tpaYckTZDd4IMRDBKqdBW+GsNSFboXDJcC6 DOsMNbdb20oYQRDLXMqJOWPg9ODY1ZFdbDVjgzDmBf7w+4ZMBakhyY7YKFsUGojsP+DaRFjB hBvW4jI5GIa6IEB/DBsKEHg02vynHCBhAwXtiMGGDJpE7DTDBXqCB4j+gdpcpwfGIpNudlF4 cfB5LuncpwMDTQVtX3dUQzyDIQlxDREBg6gvDCrTmoO1IsPkGArDBBBBOM1hi1QbChB9PlLY hAtoIE2kmDBV8nbuCwlaCCIYKLHfzQ4ZHvpXMgzkIcFQagk11FxuC51YTgpGNhQuSHJjzMC9 /sLoXBUMFpesMFbIE7YLpi8L9+KtMuPgtdkDjbEfXcpwwg1Tg4SLdBpmoF2wsNuPaBYNBJxC BckOSHhUQz6O4xaWQY0XBAm/11ugZIRBh6JO4SWP/3GjIGF65JhQUF/6drMkhfyDAgKW+Bnj RGTSQcMIiGbMlxZMckOx0umEQzj/oaxThhA/cyqo+EHC6afUhmthPfCIcZXyCfqQg/bVMmY1 7uNECNElkWbrhPTDIwyOBEeEQeq6ceGgtBB7xDBQpBiYutOE8iv5MeNaeDxFPd7p0EHZIelJ jp+sP9qDT+nevbPsdqxluLAR4YUhnVkIfa7hpr3svWQQdA5b+DF4j2iTkx8MK6Qj96IQJGHX H+njYanVmZX7Ug4xoOv36tRIJ738WQY1aBkNjcfR2BPZIfd+v2R3lOCQ0GGkVZHdYMCIsRhh ZcC7FqQgsmBkdAw5GUM0MjgQuDC9ijNmuiIetDVofBlPREAwd78iDKjMDaK3npxakHVkuIfI Pf0aw4TTaEWhBkCE6DwdhlQGfVBrYMIkAYBkWwjILBimodkGA4yQ5IdqhY8ITIkBN4Ovu9+D RX4e3FaKqf6Ig7zUFxK56iOH9EZgiHrccEHkEHoPJKMexpDaDjSeTHVoMSFGmZKg+8j2kb+v qhYIH3aTkh/xraaDsG/h2r2KRFzmQbknfdtEnLHiGE2F6c6gxmX2kD3eQuxncY2qdZBB3HTd 3RDPsj5EOpEHuqyY62QTiZCe4f/NQI00wm6yrCfUgw/biH29U2hGGC9xqZEBovjlaFiNMGEh IY8kL42WP/UOkxIMXq9zwrfOyjE6Hb5JmEQersmOqEo7SndQwQadsKSHJjyGdoPsRZEHiwYX /hhJb/8Mz3YTFfK5oDGJrX6emJHAwImScg19XG9T4GPNQLhEEVrqsGxG6IxyY/CogQFHfhqL IEKCacgxp63IQ9T4GL9ZqMINXafzqwg3+TuahLySSt9NXqhYoLydoHIwIT36Fq0DJpBGshx/ ig6Fu/4YX3JD290Ru+1Y8lswsjD7sbhA/hNogg/O3NpEEHgiCVfbw3yKisgwWkh7uRVggbUk P099B093UjC/yBggTBr9OI4fx1CBsasNNMY+8zBRIL1PjhP5BjV36umDDvpJx2miIO2OSHJj 2THWZFwlrIwyOBEjJulkR8EHPgYqttprMlZIGlQ2pFe6wTpP/4jjFclQKNBBtkUddP+yIOvU ggpHGZJxQwfCvTsJqRk7/hhMKIopyggbQMqAIsmPWH4IENffiOEQSpNoMmASIqiGcj27DSbU 6EcN0/TMzIwX/rkGCiNJhtJ6aJDvI5GqlQa8MK7DTqnaThrUmPeQoOH7HogRO17Ckhyx8V7j IMVciN6lTD9q1FLf9s1Bj0LSIZw+GrCkF+9r8lwl6DXiMaB/tN+VZZCllr2od+wvyQY5AgWl uDCDjUGxGMa9bQZoZc871BcNQe6RmE7hOMUwwmG0xwZ99u8kgF1EGG7TIMO7wacgYKWoNsIG gY4hEMtcyI75AroHDCBmGapB81AxUjAyFW5DYiy7XrdeggwVBiaOQMX91F0wSzJbCjBBv5IE rwQWiDAWg+1YJI6xObDTgnhnUdPYa8hx3DuQIDI8wocnDRBBijFDJD2/0nhSBEgSfGiBGsiP f8zAutPBXkjvBB2u9V8dxk+92oi37XuiRayFEDBPyMm1pvHeCl4aaqMYbdsJAqDZIdBhPSII MeJBBPb4ZNKvIEaumtlcyM8xDCphtHY1qEH1sKgYiiBCdHacF5PMg4zXXsGT2XeUUgRr96ZU 2bPFcSnDEZFe6trfTZFAtLeEHTTpJslL+9BtWxNQMSHHaYyLnXr1rJD25CkgL/9B195BgmR6 Av/pP9qDZqBeC3r+qtkcOZEgQnBvBW/fvkXasZktEEFBAowtpMMFYWKIEFwgoq1itkh0ZKQs kOfMK7DLhXbDWEQc7utR1Ygwrb8hYu0GkQzjnb2e2GH4WwmgwWOiQ9h+8NBhDjUmOwx4PDCB r9w9jJIjaF+mw8HER/DcN34bgwb+w4bjUMOHJYGhtIPByUAYY3h1aDwdQaGOWYBQMFVMeWYE fkJZ2YKDJ3hDIYx6DHwe7LH7c+RqEtiKIMalWFYNOCIEFhAuzBojBkx8JqEQIDssfTC9bW9f eiJOsm5Y/7wg3+1e3rqtv/8iswL293W1q/Y1sV/smOPux2Gu1luTO1Fqwm7YoYaYeGYefOUg gRDLXWSChkCLI44qmDTyCCPLIQYjIMVEGMzLyyfYMOEGvUZPEIE34ZEgkyEA4ZVlT3b2QXiO 8mabwY6Io7xDG5qeExuy7QIhS+4cSdIgxVuS0QvOWSqGHhuCphwgzhy72G6wwwlCDzQuHWxS QeN3XLfhwXdp1srpRhBqiTsz3g4f1TqnQuINIhB9oXq8HGFh16tkCBFbyC471ygM/+Rjp/wb /1T9ZLhP/9rRMP622rpKO/iOPNY7DwrTShA8RTQYQJIPuKSdphPJY5FhXBkRwhoN0GwhGn2+ 3wwRbkFfkY8Gi3gwg34hoQhdpRIkR0Gmga104qTAW+QXHvCD+nLIpgxT+SdYZUA9kwGpviD1 7D5ZR3khyY94YhSyaCEIHHW/pIhit/2n0DQf12mpOMnzxGwg9ZmVPyKiiDCwYW36HFXtO38N EsW29oYfwYSDtZUGJNCK6wBeQwnfskgF7ZAjQVwqlkTggf9FkCCBrauWQCgYKw9kVzXEaIZx VBxEslQQ1F6tBqcH5BeLaDVB+RxfRK3BJ2u7eg6Sx9sdvk7f+npL/7rvtvLc1Fv15VgRepXS gY/rrcabD3X7una3X/TYMLqvelYpiuGShNNSKdvrEOHdBZZBA2kti1uWT46IjMjoFuGFqmIj VRYa5HFYUqwIIqM6FFPIIqr24sgwFftBvXsIshMTWoMETBk3U2SKGiNBqFuOSdjHH/k3LQly 3siGBezR8rrAwgfIYx2sJ4McpwMVp4fsL+ThciovI3siQSNzReumw249/diyyIOVYzZj+5N1 QSQphBNxqHRBihDASm7UPbIZ0/lSFinVg9qRWBB4eTdMnD2oKmVzQM7XLfmYuMJplvBlyH22 x6piJVv/sJctzBAg/duH00If4ahglkIPK5oFTYvGPTYIGutAknCeyY45Ah16aILvD8IggH3T kb3ENFAtB0lyLN1WKdf4Qf9BnnT/3/kh3f69fybgoRBB/JuTH6rf+iC57fXbv4r+D7/+qvEc nHb7ekxSVdGhbfiPCteNsfaSDC7Yb2tR223u1RbjQZ3+wmqGDDvBggwmi3NQXRBwPEYQQaBv gk7GUjNmKcvtYflDKA9NORodiEDq9boPWk9yUOkHtYaCYenYYSQe/WOQXPZb7e0QYwYP28MK 0SBQgybrAX/G0hZNwVmhNr2i3NAqdjDX0Psaw0iC8PaSgwRNjUZmUlCdwwligf/DFhU/9BjI GMhYbE+01kErMNggwTvYimQXQzY6DWSh+DDSCDpqrG0TdZESQdP3ZFHk3SzpEneRXq7tBhDV B8IH4biJN1UXSb1yEb0bhA737wndP3607ojdtv7/Dwgbi12uDT7trjcRpthra/DFWm9w1aYZ b6A94MKGgiGUulA7ximrayoPQcNd6lk9hiigE/ItHtIH+E+XZcIg90r9iiXOwzvHrfRQOiGd usPjoN+NkHrv6ZBgNt9osmgEfyCBGrYdxBAwYUv8OqZb8YkjYNaYiGQ4+QhJsVCDTBqmmWYB hCkEpyFuiC6laBBsrrAF4OtB05OJEPI3/0aF6enfH/7Xf/ZGyAT/+7f+1sIP/7ch0nEhgVDC 8guE9hhIHBgz8PjEsgmFvtFmFhZ5+izFbHuLRbhlIgTw0V0ouQdP7VmCtkCA/Bha5ZCAI+Nd FkrDH/yyAwn/yyGH/8f/w+d8KRwy/45T3fXdBkc//DIaK+/u1LIFAv/4jLIqh8SGdJ8si0P9 Y3Ee7RZEC3FOVBFTI6DTPnpdEnYW15XMxKcEo+CILsiFFSBj1T2oIGRoNQJ8FT7uETDp6IS/ V1ahBvryLDdBP/QQet/rW1X/8iov/f6//f/H2wo/1jvBkCFNqMsmgEWilnlkGAlolgKMsigW GEFyyAairlkoEHinW9InfW2SdkUcjh+nrenUjifvtb7b/CX9+lf/+Tfv/0uUkYHba//TTuO/ S6FvUhB7H1rj127hkM6dBKrtFmDQMBhLkhyQ8O5ZgqCDX3FhFmFgoMLGoiPyzTQW0pZoMVA8 cgisPUgQIdkQdFmgQZ0SHdqiWAoLMEgxUmPiIUswXCe3UswIzU/eTA7kQx+EQcolvY7b+nRX WxUGDx9PQsslW67kVuhlk+F0qIxyx9ciiQ9b0iDA+G1/uShOHBr/9OWTTIQx3q39jIQCYjb9 ZDCjZAuusCGkGQIGNbGWQEAi0tFkJA9hK5ZFsoMJWRXCGOIYRZFq4lkVQspwLyIzag9wi3Jm n9ZPn6tJvtluQBcslQu8fUj1N29C78hG/0/hEMtdZyY5Mdt8qAIwyLBJkTre/ew9e21+GP3i vv+Gvh2/DUips7248bYiHdT75F4NMVl3tEVmKnkIE7aGQwnKgM+W4MUGmD9FuGYQYkGCa00y yLQv1ssgWxwm4yyaihTfFhoijkbwiGK6DohlLrCp4Ooda9NBPJRf8n3bkIYT2He5R7wQa8R4 7dMLvf8L0WSZtt9Cipg4ai/0IYUNhrknCFkNCcV2EWaJgQGvRZpUCP6KqELfo2IDkuP0EDBB plk1ZIx9INC8fhNMsnhSkf09hmbRDg4kMFDRBd3IMPkGK7WRunLIgNAMH5CY69yID9BB7fl3 Kgfp4YpCaNqNNuFF/+33eiyAtfw8EiEz1Fpg1ml4x3uizbCxhqWaGrDBRxVorrcU9aQyyB57 Iq5EAw1xIQxhEDBWFr8Gnk+fykGIZGyJJRfzE7jwYLQO74+2WQQRHMjBf/FyD/+W4jhsgQ+R oVCQymYrIaNByDMJ2WYBAQagYhU3LMEwciA9byuZAhZAIQqyruEDLJVFDHEjHenY5FHW6ZZJ 3QW4MoenFk9qsQyNughgewafX5INsgwP//lkIDP1UlS6lj7FKNq54XpMZZPYj18ih2slQKGs uLZcdqgrTyCDEnDVKGEMgQGk4sFluailkJglSY+KiWQaE1bkZZZgFFD66D4Y/+RGYFB6X0Ew 4/5bkAXDBul2lDDaC+8GGGElkC4vwYY9Nt7YRHXsMloiyaBnEbogYXSmPpNuRpCIDkli3og6 f8MNP7hg0SHfxBg6v4YOpMfw4f3hoS3sYT9uJNkEEGWSoM9/Iv4QddcpyCD+E3/MF6YxaX8l Bm7kV7H/JgNTp2v/1hr/x5ZCiBgv/eiJ//4WQcn/xshnEfh2iyAgZ/4lczFI4pZAzD/smw7h aJ3xGIMLSB+L7+6fRbmYVvvgiBDJUHfFOQ4x9OQXqfTBhsMJVLIXCMeRkSyEza1lkA0GF8sl QxHaoh1SDMB0HY052LtpE3cKwuTHzsgRQ17wgwo+3TC/01Ldyb+mFK6UDEeay6oPUIhxiFJs UnkKOEmGkHhNIhOtIkP8L/9VBBwaqTHfapxrf1/X4Xlk1K9v1BhQiHGf9Mcgxpv/SbGl6ak8 uvwwqKGx/LcMJi18WwwvlmC02SbHEhsXSiL5GycLvaD4ZThOnsgRozR+8shAEMhi308slYOG PyN3lkBiB/TGWQOJEy4UcPYiaPuWT7HDeMnrDdkE4Mhn3ZBgeiFCHYYjTgxyC6cEGHdlvBg6 YaBxPjIMJTERD7DVMswFFflvhEMgiDjTohH5gtO9B/5MdnQT9/pSY7j0//u1/+uynBP/3uQg ///j/9v//x5rH/90gQP/7Gn+I2pJw8gg5B1zSGkED4kG66xBljE38d/lkDt+MjUfyFEO+yD1 vnYxm42y345DOQ1iIluOCIlAbBpQg0EG2OEHthhfZMefYaohXe7eOR03/O+DUSd179XDXf7h j2H/aCQQf8Ncghf8shNQmQYq/ETqCR8slQoPjCBkaPoMfJQ+gg39479/f7ftKwa2O1BhS0vY kDH4ctIcI+DPmRusgvE6wy0uDQTglwg8u0g4k9J+HFIkD7fD+7b7qwfYNbHDUNS0pjIsqIOq IhnmX5GX8IHJsJAXk+4T3lFyTv46Qfv032/eTYFCw/elITW/CCRDCA74QSIaPHwlJxbWgqNC BtYSsQcJQgnIl1SPnY1i7HwZEXkHDZsfDILzhA4ZAgdA6ScRLIGZ8dIjHfKKoQb49PJsqn+3 JsJEbdtt79Pb7/4QbH/5BNWl/ZBcMML/BhsV/LIDEDX8siRgwv4j/LJWP6ggeI0H5G76BB/t +njvu998jHJsWhIaVybCxoNhrwuWSmxXW0GGv+Xg119MfCkY739fH/dg317IMEitYMhnC7HJ AZyObfz4NLLvdVDROe6xHavYZgLJDkbk42KxF9eWQftVoijYYQjIOTBhETNkGAYnUlLIQBHM Fk3UogQYk2VS/CmzKsJC/phBkwcF/SUYL/CskUL/okPCZ44IF/VOoQcJf/pJwQX+loK6/x9I k/67/TeRLcR0FpL/tL74OsGktex4/XDeTdLVrwbEm5QY9LDB5HOPhvkLUuDkMOMguQglBwgw YMNAsOEGTdYCjUGkybpRNSbCQxxPschxBFm7yC9Scm4UPwdOiHD2Qb06IETybC4aPvk2KwX+ T7ybBQX6JF1+xkQaJsUgR7yDkybCobIyblNchnLggtC5McgRVIMa4eeB8hxFkCA5QJhZNwQC M1WyBRNzQHxyC7INfIaGROZHhkG8yYgkbi7EZNigM95NxK5NiwMfGUcHjkH4M84XZBh9ybFI EZNxcNGccmwoDfkx155wgsOeH95BhkBf4X+RGQl/lsiV+P8mwUX8mwuwg/4Kn/0/68fX/SI3 ZZNSZAgfhbhEErHXyRGAiIEDOksJpyY7IQT+t54UmLfr0DjdJVvHGvt8JQpJ92tLtu9V4Qdq veQQkGv2QYCxxwb6gj9k2Eo1u6TJzIh7TbXG9hbX9qwwSv2Eo2/YVqH7QTSfYhBhSDq9oGEy DBfYQk3WwRq0RVk3WBBtBSbmVcFGGGFJuCHsFkIsk2EgLhZDCpgggyDAVYIETdaD8KTcyFP2 sNSINCiEu8g5Ou2QILsHuDIaKibKpxk3Ux5qRHB9h5BB4nhKh4yYuGGDjwYMm5KIay4OTdKw iCCKDk3BGKIZ9cHv4cm5SEkx1was0aUmP4yC9/DybCQFyyEBo/7+32XFv+Jo7I7+LFrDlkrG xxCkeZY6oWCN3aYYIjqTYoDom5Y7xGEHW/T9t6f7dP3h0ROd+geEHv5BxCTbGrIMVe4UiA+n YoH+0Rr+WQhlwg7XEjBf4RBxjaVoPavJj8cOpMd2kGu3akET94aZBgP9hA23vJsVjLIBhPWJ ZBaj5NhJi65FZDQVhtYMGsMspq4YMYMHBhlkCyg2iHLg2iBFTRZKhU4TUj0n+CSEPKKCokO3 GCCqWP4RBdkGLbbhAve8F+g8K95BC8F/IEVQV6lOCRY8hBLGUjtDDRTiwYIKR6ygghy0pmK1 MDluTHf/6hNd8L9vp/6k3//dv+lx/91xq6VrY9BWoaSBhRxwokM6ZcctKYiyHrRAiYLqlLH5 Mf4N6ZY6S/7//f2+t/73/77j2LW/99kxxvxphpQ1axZCQoYqWlQVqpHiXFoQxrkxyY71tkQ/ v9/3vyyWMzL/hBrevvY/k2EwUFQBdPYrqt7kM/6I3eGsf0xgwX33JsUDF7IpSRYOJMPIVI4d xt5BcI9tsNybFgMIO23uTYKBeH93JsSBZDAxt3cmy2QMHEQaDk2LCElwkRCDJQdMaZAjk2VC JWRKhydwRDiP9tPr1ojHD/7wg/d+0g3ER/f+3/5ZK7/lkxmxPb4QaDh99DjYaUmwkBchAMJ7 H/BkM4xfRDFybBYYDC7yUcmxIFIcN3+ybLRXZGVEYuw+J+7bbDEJRZP231YNB++mQYH23D0D HEXplviwhMyiTcuxhZNlQiVkSslMH9ah9dBP/w33fuIjv+377aWO1JsJAXKgC5UAXBqqqDC/ j/u7k31EhkZSRSkjNwMg4xw7aDt23Jj9ttpSY73/vaDv7cRH//b/H3SsdqCM6pgwXH3t0Hg8 hgYDBy0gQLLSUylpDbHl35EVjIOIDIL1FpAgWWkplGWkUFBEECBB08l7pN6Den7+//7/34Py CfyGcfLSFgzy0ioMS0goSWkSUf+WkN2RRuQcnIZy4MhorLSKQXlpBQktJVcctITI+dMIPSdB LSk4ekv7fS//X9dtfFd0rSwwgSj6lpDbBguP//+RBqQcnIZy8tyBFWeB+SBeanx/jy0ht/nH 7PP///////////8ij/H2QIHy0hYM8tIsBJaQWLLSJKP///////////////////////////// ////5ZAdLJAQFp9P35GO1pMeg+3tvhvd7vaDxDybp2MmwUSDJIXvk2EgLw/3+H+D4eD7I4Iz BIcgwK7b4cPDD8ONjw/weHxvkrHf4aGDjcmwsZOZFzhwgalIMIHB09C5Icg5up3hPYOn+HyM d8hh+D6DeiUIPh9Mf3jt//b9peG7Fr3eMe9XdyLjhw7IrogRBBxcQwgncRi65DD5NhIZBI2E RGOn2E06fw1T/2hdhrw1YYguDkbkcP8kOQwrVb12H+9cPfQarg7FqI8PHskG0Rc+IaIEwgfY QUJ2gYJO4jF0RR+pK+v/7+3YXEVe1JsLGaETBmhBhQgeEDwYKnpqNPT99+RjvkY79BvSDHpj p9vvt2G+G8N7vv3d7u05JiHhwaDhw6fERFP30+TYpCkWCyOHwQMgYMUxwmg96advTThvkT8i ztvQINoEH31+09/3D77xD4pjH1aaI2HtNAgcGEDCCcRT3RGjp//k2EgLkIBiwtdj/V9q4dqy MqIy0Fbcb3tu7lSFiJKBUHQunXIYjkov/2/hiFuvq9SbBRkrINVJsLwQMgbCDGCgoTCpjXW6 pqn9esjfyT8JLhK+vr/v1/vX6S/70tVxrFKQgF7Sulfql7VPXDCoMJrjCGESoPEUFCCk2EjJ WQSroL4QX0F8JfSyBgIQLqCBg3Cu////WS0UkyKeP//yWGQy+pt930+I//////+v///iPf/l kmHj4AIAIAAYAMAGADABgAwKZW5kc3RyZWFtCmVuZG9iago1NCAwIG9iagoxMTA3NAplbmRv YmoKNTUgMCBvYmoKPDwvVHlwZSAvWE9iamVjdAovU3VidHlwZSAvSW1hZ2UKL05hbWUgL1RJ Mk9iajUKL0ZpbHRlciAvQ0NJVFRGYXhEZWNvZGUKL0RlY29kZVBhcm1zIDw8L0sgLTEgL0Nv bHVtbnMgNjQgL1Jvd3MgMjA+Pg0KL1dpZHRoIDY0Ci9IZWlnaHQgMjAKL0JpdHNQZXJDb21w b25lbnQgMQovTGVuZ3RoIDU2IDAgUgovSW1hZ2VNYXNrIHRydWUKPj4NCnN0cmVhbQ0K+SpU idWTTkE4lzI6iOaFkKWjJHHwAQAQABgAwAYAMAGADAplbmRzdHJlYW0KZW5kb2JqCjU2IDAg b2JqCjM0CmVuZG9iago1NyAwIG9iago8PC9UeXBlIC9YT2JqZWN0Ci9TdWJ0eXBlIC9JbWFn ZQovTmFtZSAvVEkyT2JqNgovRmlsdGVyIC9DQ0lUVEZheERlY29kZQovRGVjb2RlUGFybXMg PDwvSyAtMSAvQ29sdW1ucyAyNCAvUm93cyAxMj4+DQovV2lkdGggMjQKL0hlaWdodCAxMgov Qml0c1BlckNvbXBvbmVudCAxCi9MZW5ndGggNTggMCBSCi9JbWFnZU1hc2sgdHJ1ZQo+Pg0K c3RyZWFtDQrzocnZxRH8AEAEABgAwAYAMAGADAplbmRzdHJlYW0KZW5kb2JqCjU4IDAgb2Jq CjIwCmVuZG9iago1OSAwIG9iago8PC9UeXBlIC9YT2JqZWN0Ci9TdWJ0eXBlIC9JbWFnZQov TmFtZSAvVEkyT2JqNwovRmlsdGVyIC9DQ0lUVEZheERlY29kZQovRGVjb2RlUGFybXMgPDwv SyAtMSAvQ29sdW1ucyAyNCAvUm93cyAxNj4+DQovV2lkdGggMjQKL0hlaWdodCAxNgovQml0 c1BlckNvbXBvbmVudCAxCi9MZW5ndGggNjAgMCBSCi9JbWFnZU1hc2sgdHJ1ZQo+Pg0Kc3Ry ZWFtDQr8oqd4aj+ACACAABgAwAYAMAGADAplbmRzdHJlYW0KZW5kb2JqCjYwIDAgb2JqCjIw CmVuZG9iago2MSAwIG9iago8PC9UeXBlIC9YT2JqZWN0Ci9TdWJ0eXBlIC9JbWFnZQovTmFt ZSAvVEkyT2JqOAovRmlsdGVyIC9DQ0lUVEZheERlY29kZQovRGVjb2RlUGFybXMgPDwvSyAt MSAvQ29sdW1ucyAzMiAvUm93cyAyMD4+DQovV2lkdGggMzIKL0hlaWdodCAyMAovQml0c1Bl ckNvbXBvbmVudCAxCi9MZW5ndGggNjIgMCBSCi9JbWFnZU1hc2sgdHJ1ZQo+Pg0Kc3RyZWFt DQr5B8fzgEQZFtxH8AEAEAAYAMAGADABgAwKZW5kc3RyZWFtCmVuZG9iago2MiAwIG9iagoy NAplbmRvYmoKNjMgMCBvYmoKPDwvVHlwZSAvWE9iamVjdAovU3VidHlwZSAvSW1hZ2UKL05h bWUgL1RJMk9iajkKL0ZpbHRlciAvQ0NJVFRGYXhEZWNvZGUKL0RlY29kZVBhcm1zIDw8L0sg LTEgL0NvbHVtbnMgMjQgL1Jvd3MgMTY+Pg0KL1dpZHRoIDI0Ci9IZWlnaHQgMTYKL0JpdHNQ ZXJDb21wb25lbnQgMQovTGVuZ3RoIDY0IDAgUgovSW1hZ2VNYXNrIHRydWUKPj4NCnN0cmVh bQ0K+T8J/w3H8AEAEAAYAMAGADABgAwKZW5kc3RyZWFtCmVuZG9iago2NCAwIG9iagoyMApl bmRvYmoKNjUgMCBvYmoKPDwvVHlwZSAvWE9iamVjdAovU3VidHlwZSAvSW1hZ2UKL05hbWUg L1RJMk9iajEwCi9GaWx0ZXIgL0NDSVRURmF4RGVjb2RlCi9EZWNvZGVQYXJtcyA8PC9LIC0x IC9Db2x1bW5zIDI0IC9Sb3dzIDEyPj4NCi9XaWR0aCAyNAovSGVpZ2h0IDEyCi9CaXRzUGVy Q29tcG9uZW50IDEKL0xlbmd0aCA2NiAwIFIKL0ltYWdlTWFzayB0cnVlCj4+DQpzdHJlYW0N CvM3g7UfgAgAgAAYAMAGADABgAwKZW5kc3RyZWFtCmVuZG9iago2NiAwIG9iagoxOQplbmRv YmoKNjcgMCBvYmoKPDwvVHlwZSAvWE9iamVjdAovU3VidHlwZSAvSW1hZ2UKL05hbWUgL1RJ Mk9iajExCi9GaWx0ZXIgL0NDSVRURmF4RGVjb2RlCi9EZWNvZGVQYXJtcyA8PC9LIC0xIC9D b2x1bW5zIDI0IC9Sb3dzIDIwPj4NCi9XaWR0aCAyNAovSGVpZ2h0IDIwCi9CaXRzUGVyQ29t cG9uZW50IDEKL0xlbmd0aCA2OCAwIFIKL0ltYWdlTWFzayB0cnVlCj4+DQpzdHJlYW0NCvJF h19aVcLWFH8AEAEAABgAwAYAMAGADAplbmRzdHJlYW0KZW5kb2JqCjY4IDAgb2JqCjI0CmVu ZG9iago2OSAwIG9iago8PC9UeXBlIC9YT2JqZWN0Ci9TdWJ0eXBlIC9JbWFnZQovTmFtZSAv VEkyT2JqMTIKL0ZpbHRlciAvQ0NJVFRGYXhEZWNvZGUKL0RlY29kZVBhcm1zIDw8L0sgLTEg L0NvbHVtbnMgMjQgL1Jvd3MgMTY+Pg0KL1dpZHRoIDI0Ci9IZWlnaHQgMTYKL0JpdHNQZXJD b21wb25lbnQgMQovTGVuZ3RoIDcwIDAgUgovSW1hZ2VNYXNrIHRydWUKPj4NCnN0cmVhbQ0K +SOn7Uf4AIAIABgAwAYAMAGADAplbmRzdHJlYW0KZW5kb2JqCjcwIDAgb2JqCjE5CmVuZG9i ago3MSAwIG9iago8PC9UeXBlIC9YT2JqZWN0Ci9TdWJ0eXBlIC9JbWFnZQovTmFtZSAvVEky T2JqMTMKL0ZpbHRlciAvQ0NJVFRGYXhEZWNvZGUKL0RlY29kZVBhcm1zIDw8L0sgLTEgL0Nv bHVtbnMgMTI4IC9Sb3dzIDM3Mj4+DQovV2lkdGggMTI4Ci9IZWlnaHQgMzcyCi9CaXRzUGVy Q29tcG9uZW50IDEKL0xlbmd0aCA3MiAwIFIKL0ltYWdlTWFzayB0cnVlCj4+DQpzdHJlYW0N Cvky5WipyqGXKhUJ0oIzuq0OiMfTI4JQkXfIg+yA9EXdaRJ1qRqSR4SjHRjmcER9FDhEcWkf JqI4oNUHQIEu6i9wXkFAoQI7zVkcF4SYOhDXCQsHagmYd0gkHYdJBCG+ix11igjud9QkTEMQ 6VSJTSQI9nkgw+kCI6gwgtBs47tWhGw2LpF9LYd0kIR7dmHb03iZ0D3aSCYkmRHNurVsILBv QSQRQ4TEYbpAkhQb7YaSbutIETCLp26QJIKLLoN+tBENRBg2G7pIIoK7urCBIEUOoMN9JOYd IUR63D0kkISuRiI4VhvulPBxFtuHiqBHHCnHbXmHVBpi7DxbSQIjphh+kkEhOkG27kMRJBAi HDDQZHPNFUpBdCDXoJQkCkNE22G4qqsMMER3ayQJpQ2L3zDhVCsOG7jpJQwbd+vD7eUW0grZ Q7bvVJJSK7ZQ/4pJdGgLsNj+grJAI8t3pJaDDbvrpWHcMfoEth7MO6Wwt2HHdJcNpyx8dLDD eOUVLu7M70ure3W+sO33VpLhtxzo0sPwWt7bbpLu/etu3rXeNJKnuN2Gy5/t5I0t+qXfGt+3 u9Lbbpd8dx02X5Dd767uOHH3JF+vjtyi3/xp9w/9/9/ff3WvD73r/b4b69eP1v/63W9f/5P/ ePKLr//bX9/+/9/+/+8hdevd/dK+O8hVf96Ct9yHPr/qN49SCcEd3rKNhkc8eu8XbyWRepek sW/GU9a8kSt+Xv3SVRftRkPhkcepe3/S/DD9LbbeaaXCQf1ScusER3d4pJJYuww+0k87+9rW 323pLx228JdQRnbt1SS4ttg7FCssfbDyNNfffcmPu22GQxSlS7wcjpvpYP8WGMJbUNl5hEfd IJIw+nDfDt0l3tiDcEkkOtK6p922w4SeW/dsMOklSV+CI+DpJIVTLmxDD0ksPDDMPNQjSSJD /rDI+DaSse2wxGJqQSVL22hSUsd3DsNJrqG2zQKR4gwqpVtNggQhAklpcNhtBEdQnuHbDCCQ hIIVhwxpUTH22wRCnde3lDql+w7I8kkErbYiTh0qphg0lTvaCpKg2yBGvV2QdQKCFcNlICcM GyK8EUOkSfd4M6ZH0ISSW2cfsWRwoSXY3UocUkgoYcQhaX0UcocER0b++kRkNCGce1DZHQ0D CCBRQSsXDGKrYhBdljg1CKH2LhdWGCTW0qgyh6BHqouXa6Vu6TvoJuHgi6pKVI+CPfxhJNRE FGd/A1Ez1kmYYRHWQgVyP5DAsccocR5DOYEQsgoEchl1LINSAsOsGEFuvUOyKOUpkSBpCQwe TWiUojg3hROARUqYOMjQzUEhQ1TPkJiqED6QQY9B1e6Z+qmllj7H/iE2Y7QW6f6kEHv1bX11 dLvGH+m/SW1fkI+uxgn2WOt8dLfqGu7XyTINU+JUAqHY/hHr/2CGo39SBVx+Hgyr8hoEchlV djRDSoUlMGu12/X//5CxfmgELcP1Ood6gynrcQ0PE3wzj3i6yrIMJbGH2P/IHcwKfb+GiJf3 dftv+v9/Wv/////v/XD6D48LX7/j/e6/+H5Gwanh1g9QduQUCFg4wcvQZTriI+ACACAAGADA BgAwAYAMCmVuZHN0cmVhbQplbmRvYmoKNzIgMCBvYmoKMTE5MwplbmRvYmoKNzMgMCBvYmoK PDwvVHlwZSAvWE9iamVjdAovU3VidHlwZSAvSW1hZ2UKL05hbWUgL1RJMk9iajE0Ci9GaWx0 ZXIgL0NDSVRURmF4RGVjb2RlCi9EZWNvZGVQYXJtcyA8PC9LIC0xIC9Db2x1bW5zIDI0IC9S b3dzIDEyPj4NCi9XaWR0aCAyNAovSGVpZ2h0IDEyCi9CaXRzUGVyQ29tcG9uZW50IDEKL0xl bmd0aCA3NCAwIFIKL0ltYWdlTWFzayB0cnVlCj4+DQpzdHJlYW0NCvJ/fj8AEAEAABgAwAYA MAGADAplbmRzdHJlYW0KZW5kb2JqCjc0IDAgb2JqCjE4CmVuZG9iago3NSAwIG9iago8PC9U eXBlIC9YT2JqZWN0Ci9TdWJ0eXBlIC9JbWFnZQovTmFtZSAvVEkyT2JqMTUKL0ZpbHRlciAv Q0NJVFRGYXhEZWNvZGUKL0RlY29kZVBhcm1zIDw8L0sgLTEgL0NvbHVtbnMgMjQgL1Jvd3Mg MTI+Pg0KL1dpZHRoIDI0Ci9IZWlnaHQgMTIKL0JpdHNQZXJDb21wb25lbnQgMQovTGVuZ3Ro IDc2IDAgUgovSW1hZ2VNYXNrIHRydWUKPj4NCnN0cmVhbQ0K8ovH8AEAEAAYAMAGADABgAwK ZW5kc3RyZWFtCmVuZG9iago3NiAwIG9iagoxNwplbmRvYmoKNzcgMCBvYmoKPDwvVHlwZSAv WE9iamVjdAovU3VidHlwZSAvSW1hZ2UKL05hbWUgL1RJMk9iajE2Ci9GaWx0ZXIgL0NDSVRU RmF4RGVjb2RlCi9EZWNvZGVQYXJtcyA8PC9LIC0xIC9Db2x1bW5zIDI0IC9Sb3dzIDE2Pj4N Ci9XaWR0aCAyNAovSGVpZ2h0IDE2Ci9CaXRzUGVyQ29tcG9uZW50IDEKL0xlbmd0aCA3OCAw IFIKL0ltYWdlTWFzayB0cnVlCj4+DQpzdHJlYW0NCv5It1sKPwAQAQAAGADABgAwAYAMCmVu ZHN0cmVhbQplbmRvYmoKNzggMCBvYmoKMjAKZW5kb2JqCjc5IDAgb2JqCjw8L1R5cGUgL1hP YmplY3QKL1N1YnR5cGUgL0ltYWdlCi9OYW1lIC9USTJPYmoxNwovRmlsdGVyIC9DQ0lUVEZh eERlY29kZQovRGVjb2RlUGFybXMgPDwvSyAtMSAvQ29sdW1ucyAyNCAvUm93cyAxNj4+DQov V2lkdGggMjQKL0hlaWdodCAxNgovQml0c1BlckNvbXBvbmVudCAxCi9MZW5ndGggODAgMCBS Ci9JbWFnZU1hc2sgdHJ1ZQo+Pg0Kc3RyZWFtDQr80uR78PxH8AEAEAAYAMAGADABgAwKZW5k c3RyZWFtCmVuZG9iago4MCAwIG9iagoyMQplbmRvYmoKODEgMCBvYmoKPDwvVHlwZSAvWE9i amVjdAovU3VidHlwZSAvSW1hZ2UKL05hbWUgL1RJMk9iajE4Ci9GaWx0ZXIgL0NDSVRURmF4 RGVjb2RlCi9EZWNvZGVQYXJtcyA8PC9LIC0xIC9Db2x1bW5zIDI0IC9Sb3dzIDE2Pj4NCi9X aWR0aCAyNAovSGVpZ2h0IDE2Ci9CaXRzUGVyQ29tcG9uZW50IDEKL0xlbmd0aCA4MiAwIFIK L0ltYWdlTWFzayB0cnVlCj4+DQpzdHJlYW0NCv5IoLgoePwAQAQAGADABgAwAYAMCmVuZHN0 cmVhbQplbmRvYmoKODIgMCBvYmoKMjAKZW5kb2JqCjgzIDAgb2JqCjw8L1R5cGUgL1hPYmpl Y3QKL1N1YnR5cGUgL0ltYWdlCi9OYW1lIC9USTJPYmoxOQovRmlsdGVyIC9DQ0lUVEZheERl Y29kZQovRGVjb2RlUGFybXMgPDwvSyAtMSAvQ29sdW1ucyAyNCAvUm93cyAxNj4+DQovV2lk dGggMjQKL0hlaWdodCAxNgovQml0c1BlckNvbXBvbmVudCAxCi9MZW5ndGggODQgMCBSCi9J bWFnZU1hc2sgdHJ1ZQo+Pg0Kc3RyZWFtDQr80sOtdYKPgAgAgAAYAMAGADABgAwKZW5kc3Ry ZWFtCmVuZG9iago4NCAwIG9iagoyMQplbmRvYmoKODUgMCBvYmoKPDwvVHlwZSAvWE9iamVj dAovU3VidHlwZSAvSW1hZ2UKL05hbWUgL1RJMk9iajIwCi9GaWx0ZXIgL0NDSVRURmF4RGVj b2RlCi9EZWNvZGVQYXJtcyA8PC9LIC0xIC9Db2x1bW5zIDk2IC9Sb3dzIDY0ND4+DQovV2lk dGggOTYKL0hlaWdodCA2NDQKL0JpdHNQZXJDb21wb25lbnQgMQovTGVuZ3RoIDg2IDAgUgov SW1hZ2VNYXNrIHRydWUKPj4NCnN0cmVhbQ0K8qBSJHIwFwgzM4QNB9Bp8IiHDknfCBA2k34I PT+n2+I7f2O2+H2GH1w4edAc2xDwhY/wyRaR0JocIH2/6fbk4fdIN8dv7f47b7fBvd7TyGCg QemPuRoLZMEB2wg7a7kiHem7STx/11sNcGYD2KtQYUc7PU/JcF+F6+vJqek/G/JI7aeRLLF9 CyoAv/8XsjsnW28hBQw7hA2OEG9Q+S5voO9LDXcf21I0E6lIBGDI4iDsYW1ItHDCgg8Un/+S DI4Ea+7/sid9McRYUNTvBJMEMl4IOFyrOqd+SHw6Vd6V4frh/WTHB3VcMHjXDIOiksPfw8MK FkMojjKd9fg1xt4eQzpX4YUSrAx5UN4JkdtQhDZMwiFHt9tuiQ9/Xv/H//t64iiNAlomAz3Q cNJwYKRnynhQQfIxRPh/kEAvDD1gwbawbkEfB2K4agoYUEiJ5tQQIRhBYRFCJzyMWB+CT43y RFXIjd9BhYTfYYXfsGCW3wxW32FscMJt5CB4N5STvF3hoPEc7of///nUUzNqg8afRId5Ggug 3ggem9Or6Io5TvsaCEG7vCD7dLw33sN+7v9p/iH+P6/78f87HBePIMZHiFHCEPp9fJjk39Lb //r/df/92l2IyoAxftdhEaDRKSGOdnKU4aCrMIOg1Tw1u6ojH5McrCb4Kg3oW26+vql9//r9 f//YVL+xSuvaSultVGlDBC0FkxulEMKpEoYKRgMDWuiTBRkhy3aerf1v/sd/tvtx4qGW6iGF HNRQg6dPJPpOSkzR6fT9//f0I///5BCI9iQcbw9rfW7W/+MmPel////t64ir2oYKM7Dc7toO E774QbpP//9rbrHahqGCjzuwXp0qI1EL/3sOiBBF/Ued8Mj0IQ6dEKPyY9ulv////9vCWI7V qGFGdu6/28gQRdbUed+cIgmgTp5Cj6JDw3r////vWxFX1KXhhUGGC5dj1x5AwQ352OGeyyfH O/Ij8EIdOnkK+iQ9vX////etiK9qGFDCnbsa/28hXNpEHW8f/zv2XKdwBFdURqIX/vYOiBBC 3g8c7mUEQTQJ08l2k+m//67WwwlYq1DCjylsuBFC/ZbqI527JzrylgY9rzscrUc7sF61pZIc mP1t/fvf/d9iPUMt8OGojO3df7eQxrB1vO0KOd107sF4T1XJDkx1rb+/77+77EeRj4aqHDUR 5SwL194MqzYccqoREZ3bNlTureg9BN/17+thpY7VqGFOzqOd+cEQfROnkKPokPDev////1sa WO1agwU7I53bGCIPWEHToiY6BB8JvvS+/////+P+87hGaI/ER//O6nJmItBhahcQsnCpML16 8L1////xIYI/O9aPJoLCdPeTvS+//////+CeJBgjvH5SgMb1eP4AIAIAGADABgAwAYAMCmVu ZHN0cmVhbQplbmRvYmoKODYgMCBvYmoKMTA1MAplbmRvYmoKODcgMCBvYmoKPDwvVHlwZSAv WE9iamVjdAovU3VidHlwZSAvSW1hZ2UKL05hbWUgL1RJMk9iajIxCi9GaWx0ZXIgL0NDSVRU RmF4RGVjb2RlCi9EZWNvZGVQYXJtcyA8PC9LIC0xIC9Db2x1bW5zIDI0IC9Sb3dzIDE2Pj4N Ci9XaWR0aCAyNAovSGVpZ2h0IDE2Ci9CaXRzUGVyQ29tcG9uZW50IDEKL0xlbmd0aCA4OCAw IFIKL0ltYWdlTWFzayB0cnVlCj4+DQpzdHJlYW0NCv5IdL6tR8AEAEAAGADABgAwAYAMCmVu ZHN0cmVhbQplbmRvYmoKODggMCBvYmoKMjAKZW5kb2JqCjg5IDAgb2JqCjw8L1R5cGUgL1hP YmplY3QKL1N1YnR5cGUgL0ltYWdlCi9OYW1lIC9USTJPYmoyMgovRmlsdGVyIC9DQ0lUVEZh eERlY29kZQovRGVjb2RlUGFybXMgPDwvSyAtMSAvQ29sdW1ucyAyNCAvUm93cyAxMj4+DQov V2lkdGggMjQKL0hlaWdodCAxMgovQml0c1BlckNvbXBvbmVudCAxCi9MZW5ndGggOTAgMCBS Ci9JbWFnZU1hc2sgdHJ1ZQo+Pg0Kc3RyZWFtDQr5Iq+PgAgAgAAYAMAGADABgAwKZW5kc3Ry ZWFtCmVuZG9iago5MCAwIG9iagoxOAplbmRvYmoKOTEgMCBvYmoKPDwvVHlwZSAvWE9iamVj dAovU3VidHlwZSAvSW1hZ2UKL05hbWUgL1RJMk9iajIzCi9GaWx0ZXIgL0NDSVRURmF4RGVj b2RlCi9EZWNvZGVQYXJtcyA8PC9LIC0xIC9Db2x1bW5zIDI0IC9Sb3dzIDEyPj4NCi9XaWR0 aCAyNAovSGVpZ2h0IDEyCi9CaXRzUGVyQ29tcG9uZW50IDEKL0xlbmd0aCA5MiAwIFIKL0lt YWdlTWFzayB0cnVlCj4+DQpzdHJlYW0NCvJ7cPH4AIAIABgAwAYAMAGADAplbmRzdHJlYW0K ZW5kb2JqCjkyIDAgb2JqCjE4CmVuZG9iago5MyAwIG9iago8PC9UeXBlIC9YT2JqZWN0Ci9T dWJ0eXBlIC9JbWFnZQovTmFtZSAvVEkyT2JqMjQKL0ZpbHRlciAvQ0NJVFRGYXhEZWNvZGUK L0RlY29kZVBhcm1zIDw8L0sgLTEgL0NvbHVtbnMgMjQgL1Jvd3MgMTI+Pg0KL1dpZHRoIDI0 Ci9IZWlnaHQgMTIKL0JpdHNQZXJDb21wb25lbnQgMQovTGVuZ3RoIDk0IDAgUgovSW1hZ2VN YXNrIHRydWUKPj4NCnN0cmVhbQ0K/KLx8AEAEAAYAMAGADABgAwKZW5kc3RyZWFtCmVuZG9i ago5NCAwIG9iagoxNwplbmRvYmoKOTUgMCBvYmoKPDwvVHlwZSAvWE9iamVjdAovU3VidHlw ZSAvSW1hZ2UKL05hbWUgL1RJMk9iajI1Ci9GaWx0ZXIgL0NDSVRURmF4RGVjb2RlCi9EZWNv ZGVQYXJtcyA8PC9LIC0xIC9Db2x1bW5zIDI0IC9Sb3dzIDE2Pj4NCi9XaWR0aCAyNAovSGVp Z2h0IDE2Ci9CaXRzUGVyQ29tcG9uZW50IDEKL0xlbmd0aCA5NiAwIFIKL0ltYWdlTWFzayB0 cnVlCj4+DQpzdHJlYW0NCv58rUf4AIAIABgAwAYAMAGADAplbmRzdHJlYW0KZW5kb2JqCjk2 IDAgb2JqCjE4CmVuZG9iago0NCAwIG9iago8PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVu Z3RoIDk3IDAgUiA+Pg0Kc3RyZWFtDQp4nO2Vva7UMBCFqfMU+wRm/m33NNAgJJ4ACiQkhO77 N0w8uY6d1SYtRabYSKvky5njM5O3RasmAnhAgv5bBJOV+b+ff5aPXz7T1x+/8fHp7/JtgSRa H7+Wt0VTtvlmSsUfZ3C0X5WoI77PCNbcEIhJaWZwkWApJxF4iKYiI4TeIUgUOrDdMUKyQsoO Rn8Bu0jJTesO4a4EoUEILdVDO0o5gZMLJbUVpqnSSJFuSS3Rj7bXjRBJZe3GGeQozv7KiaFd SYFTW5EpyXrVknBqxt4RlfkFgptFqtbUuP0HU3PvxOJk8lMSohG08OS5kbIf7oUKCz+JD4dS uwi0UyuIrVlg2rQMAYMuIr8SEX249mT+LOYQMzD2lNqroEcjghSeZGknMzB6SIm1MTgCOY1b bWNCJSBgB0Oxh1QYz/0waeFlZxwmbo+o5POptdIMYYmZHBh7RPkVIwwhiJY4l6ZnYNjey4Wp sAWswtHUfL2BNobqxvCRmf3oKSU772XtYZ1Y8S02jxv2nGKJsfckw2EDoUrLldS2M7Si76tp jcH1yWxKnLFuQntehXtU6WJiImQmsQAGBF0fzBaQEusvP00M7UGFcsqQDO1ACsTXZ2D0oLLo qR1Y47NSUA/7g7agfrjrrrvuuuuu/7P+Aan0aNgKZW5kc3RyZWFtCmVuZG9iago5NyAwIG9i ago0OTIKZW5kb2JqCjQzIDAgb2JqCjw8L0pJMk9iajEgNDUgMCBSCi9USTJPYmoxIDQ3IDAg UgovVEkyT2JqMiA0OSAwIFIKL1RJMk9iajMgNTEgMCBSCi9USTJPYmo0IDUzIDAgUgovVEky T2JqNSA1NSAwIFIKL1RJMk9iajYgNTcgMCBSCi9USTJPYmo3IDU5IDAgUgovVEkyT2JqOCA2 MSAwIFIKL1RJMk9iajkgNjMgMCBSCi9USTJPYmoxMCA2NSAwIFIKL1RJMk9iajExIDY3IDAg UgovVEkyT2JqMTIgNjkgMCBSCi9USTJPYmoxMyA3MSAwIFIKL1RJMk9iajE0IDczIDAgUgov VEkyT2JqMTUgNzUgMCBSCi9USTJPYmoxNiA3NyAwIFIKL1RJMk9iajE3IDc5IDAgUgovVEky T2JqMTggODEgMCBSCi9USTJPYmoxOSA4MyAwIFIKL1RJMk9iajIwIDg1IDAgUgovVEkyT2Jq MjEgODcgMCBSCi9USTJPYmoyMiA4OSAwIFIKL1RJMk9iajIzIDkxIDAgUgovVEkyT2JqMjQg OTMgMCBSCi9USTJPYmoyNSA5NSAwIFIKPj4NCmVuZG9iagoyIDAgb2JqCjw8L1R5cGUgL1Bh Z2VzCi9Db3VudCAyCi9LaWRzIFsgMSAwIFIgNDIgMCBSIF0KPj4NCmVuZG9iago5OCAwIG9i ago8PC9UeXBlL01ldGFkYXRhL1N1YnR5cGUvWE1ML0xlbmd0aCA5OSAwIFI+Pg0Kc3RyZWFt Cjw/eHBhY2tldCBiZWdpbj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+ Cjx4OnhtcG1ldGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IkFkb2JlIFhN UCBDb3JlIDUuMi1jMDAxIDYzLjEzOTQzOSwgMjAxMC8wOS8yNy0xMzozNzoyNiAgICAgICAg Ij4KCTxyZGY6UkRGIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1y ZGYtc3ludGF4LW5zIyI+CgkJPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6 cGRmPSJodHRwOi8vbnMuYWRvYmUuY29tL3BkZi8xLjMvIj4KCQkJPHBkZjpQcm9kdWNlcj5L T05JQ0EgTUlOT0xUQSBiaXpodWIgQzM4NTE8L3BkZjpQcm9kdWNlcj4KCQk8L3JkZjpEZXNj cmlwdGlvbj4KCQk8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIiB4bWxuczp4bXA9Imh0 dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iPgoJCQk8eG1wOkNyZWF0ZURhdGU+MjAxNy0w Ni0yNlQxNToxMjoyMCswMjowMDwveG1wOkNyZWF0ZURhdGU+CgkJCTx4bXA6TW9kaWZ5RGF0 ZT4yMDE3LTA2LTI2VDE1OjEyOjIwKzAyOjAwPC94bXA6TW9kaWZ5RGF0ZT4KCQkJPHhtcDpN ZXRhZGF0YURhdGU+MjAxNy0wNi0yNlQxNToxMjoyMCswMjowMDwveG1wOk1ldGFkYXRhRGF0 ZT4KCQkJPHhtcDpDcmVhdG9yVG9vbD5yZW5vaXI8L3htcDpDcmVhdG9yVG9vbD4KCQk8L3Jk ZjpEZXNjcmlwdGlvbj4KCQk8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIiB4bWxuczp4 bXBNTT0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21tLyIgeG1sbnM6c3RSZWY9Imh0 dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9zVHlwZS9SZXNvdXJjZVJlZiMiIHhtbG5zOnN0 RXZ0PSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvc1R5cGUvUmVzb3VyY2VFdmVudCMi PgoJCQk8eG1wTU06RG9jdW1lbnRJRD51dWlkOjZiZWJmODkzMDdlMTFhMGYwYzE0MWIxMzk1 Yjg2NzEzPC94bXBNTTpEb2N1bWVudElEPgoJCQk8eG1wTU06SW5zdGFuY2VJRD51dWlkOjZi ZWJmODkzMDdlMTFhMGYwYzE0MWIxMzk1Yjg2NzEzPC94bXBNTTpJbnN0YW5jZUlEPgoJCQk8 eG1wTU06UmVuZGl0aW9uQ2xhc3M+ZGVmYXVsdDwveG1wTU06UmVuZGl0aW9uQ2xhc3M+CgkJ CTx4bXBNTTpWZXJzaW9uSUQ+MTwveG1wTU06VmVyc2lvbklEPgoJCQk8eG1wTU06RGVyaXZl ZEZyb20gcmRmOnBhcnNlVHlwZT0iUmVzb3VyY2UiPgoJCQkJPHN0UmVmOmluc3RhbmNlSUQ+ dXVpZDo2YmViZjg5My0wN2UxLTFhMGYtMGMxNC0xYjEzOTViODY3MTM8L3N0UmVmOmluc3Rh bmNlSUQ+CgkJCQk8c3RSZWY6ZG9jdW1lbnRJRD51dWlkOjZiZWJmODkzLTA3ZTEtMWEwZi0w YzE0LTFiMTM5NWI4NjcxMzwvc3RSZWY6ZG9jdW1lbnRJRD4KCQkJPC94bXBNTTpEZXJpdmVk RnJvbT4KCQk8L3JkZjpEZXNjcmlwdGlvbj4KCQk8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91 dD0iIiB4bWxuczpkYz0iaHR0cDovL3B1cmwub3JnL2RjL2VsZW1lbnRzLzEuMS8iPgoJCQk8 ZGM6Zm9ybWF0PmFwcGxpY2F0aW9uL3BkZjwvZGM6Zm9ybWF0PgoJCQk8ZGM6dGl0bGU+CgkJ CQk8cmRmOkFsdD4KCQkJCQk8cmRmOmxpIHhtbDpsYW5nPSJ4LWRlZmF1bHQiPnJlbm9pci0y MDE3MDYyNjE1MTIyMDwvcmRmOmxpPgoJCQkJPC9yZGY6QWx0PgoJCQk8L2RjOnRpdGxlPgoJ CTwvcmRmOkRlc2NyaXB0aW9uPgoJPC9yZGY6UkRGPgo8L3g6eG1wbWV0YT4KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAKPD94cGFja2V0IGVuZD0idyI/PgplbmRzdHJlYW0NCmVuZG9iago5OSAwIG9iagoz ODU4CmVuZG9iagoxMDAgMCBvYmoKPDwKL1RpdGxlKP7/AHIAZQBuAG8AaQByAC0AMgAwADEA NwAwADYAMgA2ADEANQAxADIAMgAwKS9DcmVhdG9yKHJlbm9pcikvUHJvZHVjZXIoS09OSUNB IE1JTk9MVEEgYml6aHViIEMzODUxKS9DcmVhdGlvbkRhdGUoRDoyMDE3MDYyNjE1MTIyMCsw MicwMCcpL01vZERhdGUoRDoyMDE3MDYyNjE1MTIyMCswMicwMCcpPj4NCmVuZG9iagoxMDEg MCBvYmoKPDwvVHlwZSAvQ2F0YWxvZwovUGFnZXMgMiAwIFIKL01ldGFkYXRhIDk4IDAgUgov T3BlbkFjdGlvbiBbIDEgMCBSIC9GaXQgXQo+Pg0KZW5kb2JqCnhyZWYNCjAgMTAyDQowMDAw MDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMTYgMDAwMDAgbg0KMDAwMDExODAyNSAwMDAwMCBu DQowMDAwMDY2MzAxIDAwMDAwIG4NCjAwMDAwNjU3MzQgMDAwMDAgbg0KMDAwMDAwMDIwNCAw MDAwMCBuDQowMDAwMDE1NTMwIDAwMDAwIG4NCjAwMDAwMTU1NTEgMDAwMDAgbg0KMDAwMDAx OTMyNSAwMDAwMCBuDQowMDAwMDE5MzQ1IDAwMDAwIG4NCjAwMDAwMjA1NzIgMDAwMDAgbg0K MDAwMDAyMDU5MiAwMDAwMCBuDQowMDAwMDIzMTQ0IDAwMDAwIG4NCjAwMDAwMjMxNjUgMDAw MDAgbg0KMDAwMDA1ODc0MCAwMDAwMCBuDQowMDAwMDU4NzYyIDAwMDAwIG4NCjAwMDAwNTk4 MjAgMDAwMDAgbg0KMDAwMDA1OTg0MCAwMDAwMCBuDQowMDAwMDYwMDkzIDAwMDAwIG4NCjAw MDAwNjAxMTIgMDAwMDAgbg0KMDAwMDA2MDM1OCAwMDAwMCBuDQowMDAwMDYwMzc3IDAwMDAw IG4NCjAwMDAwNjEwMzMgMDAwMDAgbg0KMDAwMDA2MTA1MyAwMDAwMCBuDQowMDAwMDYxOTgx IDAwMDAwIG4NCjAwMDAwNjIwMDEgMDAwMDAgbg0KMDAwMDA2MjU1NyAwMDAwMCBuDQowMDAw MDYyNTc3IDAwMDAwIG4NCjAwMDAwNjI4MjggMDAwMDAgbg0KMDAwMDA2Mjg0NyAwMDAwMCBu DQowMDAwMDYzMTk0IDAwMDAwIG4NCjAwMDAwNjMyMTQgMDAwMDAgbg0KMDAwMDA2MzYwNSAw MDAwMCBuDQowMDAwMDYzNjI1IDAwMDAwIG4NCjAwMDAwNjM4NzIgMDAwMDAgbg0KMDAwMDA2 Mzg5MSAwMDAwMCBuDQowMDAwMDY0MTM4IDAwMDAwIG4NCjAwMDAwNjQxNTcgMDAwMDAgbg0K MDAwMDA2NTQ0NyAwMDAwMCBuDQowMDAwMDY1NDY4IDAwMDAwIG4NCjAwMDAwNjU3MTUgMDAw MDAgbg0KMDAwMDA2NjI4MSAwMDAwMCBuDQowMDAwMDY2NjE1IDAwMDAwIG4NCjAwMDAxMTc1 NzEgMDAwMDAgbg0KMDAwMDExNjk4MSAwMDAwMCBuDQowMDAwMDY2ODA2IDAwMDAwIG4NCjAw MDAwODg3MjggMDAwMDAgbg0KMDAwMDA4ODc1MCAwMDAwMCBuDQowMDAwMDg4OTk1IDAwMDAw IG4NCjAwMDAwODkwMTQgMDAwMDAgbg0KMDAwMDA5MDk2NCAwMDAwMCBuDQowMDAwMDkwOTg1 IDAwMDAwIG4NCjAwMDAwOTc3ODYgMDAwMDAgbg0KMDAwMDA5NzgwNyAwMDAwMCBuDQowMDAw MTA5MTE1IDAwMDAwIG4NCjAwMDAxMDkxMzcgMDAwMDAgbg0KMDAwMDEwOTM5OSAwMDAwMCBu DQowMDAwMTA5NDE4IDAwMDAwIG4NCjAwMDAxMDk2NjYgMDAwMDAgbg0KMDAwMDEwOTY4NSAw MDAwMCBuDQowMDAwMTA5OTMzIDAwMDAwIG4NCjAwMDAxMDk5NTIgMDAwMDAgbg0KMDAwMDEx MDIwNCAwMDAwMCBuDQowMDAwMTEwMjIzIDAwMDAwIG4NCjAwMDAxMTA0NzEgMDAwMDAgbg0K MDAwMDExMDQ5MCAwMDAwMCBuDQowMDAwMTEwNzM4IDAwMDAwIG4NCjAwMDAxMTA3NTcgMDAw MDAgbg0KMDAwMDExMTAxMCAwMDAwMCBuDQowMDAwMTExMDI5IDAwMDAwIG4NCjAwMDAxMTEy NzcgMDAwMDAgbg0KMDAwMDExMTI5NiAwMDAwMCBuDQowMDAwMTEyNzIyIDAwMDAwIG4NCjAw MDAxMTI3NDMgMDAwMDAgbg0KMDAwMDExMjk5MCAwMDAwMCBuDQowMDAwMTEzMDA5IDAwMDAw IG4NCjAwMDAxMTMyNTUgMDAwMDAgbg0KMDAwMDExMzI3NCAwMDAwMCBuDQowMDAwMTEzNTIz IDAwMDAwIG4NCjAwMDAxMTM1NDIgMDAwMDAgbg0KMDAwMDExMzc5MiAwMDAwMCBuDQowMDAw MTEzODExIDAwMDAwIG4NCjAwMDAxMTQwNjAgMDAwMDAgbg0KMDAwMDExNDA3OSAwMDAwMCBu DQowMDAwMTE0MzI5IDAwMDAwIG4NCjAwMDAxMTQzNDggMDAwMDAgbg0KMDAwMDExNTYyOSAw MDAwMCBuDQowMDAwMTE1NjUwIDAwMDAwIG4NCjAwMDAxMTU4OTkgMDAwMDAgbg0KMDAwMDEx NTkxOCAwMDAwMCBuDQowMDAwMTE2MTY1IDAwMDAwIG4NCjAwMDAxMTYxODQgMDAwMDAgbg0K MDAwMDExNjQzMSAwMDAwMCBuDQowMDAwMTE2NDUwIDAwMDAwIG4NCjAwMDAxMTY2OTYgMDAw MDAgbg0KMDAwMDExNjcxNSAwMDAwMCBuDQowMDAwMTE2OTYyIDAwMDAwIG4NCjAwMDAxMTc1 NTEgMDAwMDAgbg0KMDAwMDExODA5MSAwMDAwMCBuDQowMDAwMTIyMDMwIDAwMDAwIG4NCjAw MDAxMjIwNTEgMDAwMDAgbg0KMDAwMDEyMjI1MiAwMDAwMCBuDQp0cmFpbGVyDQo8PC9TaXpl IDEwMgovSW5mbyAxMDAgMCBSCi9Sb290IDEwMSAwIFIKPj4NCnN0YXJ0eHJlZg0KMTIyMzQ3 CiUlRU9GNDIgMCBvYmoNPDwvQ29udGVudHNbNDQgMCBSXS9NZWRpYUJveFswIDAgNTk1LjAg ODQxLjBdL1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFn ZUIvSW1hZ2VDL0ltYWdlSV0vWE9iamVjdCA0MyAwIFI+Pi9Sb3RhdGUgOTAvVHlwZS9QYWdl Pj4NZW5kb2JqDTk4IDAgb2JqDTw8L0xlbmd0aCAzOTQ4L1N1YnR5cGUvWE1ML1R5cGUvTWV0 YWRhdGE+PnN0cmVhbQ0KPD94cGFja2V0IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBDZWhpSHpy ZVN6TlRjemtjOWQiPz4KPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4 bXB0az0iQWRvYmUgWE1QIENvcmUgNS4yLWMwMDEgNjMuMTM5NDM5LCAyMDEwLzA5LzI3LTEz OjM3OjI2ICAgICAgICAiPgogICA8cmRmOlJERiB4bWxuczpyZGY9Imh0dHA6Ly93d3cudzMu b3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPgogICAgICA8cmRmOkRlc2NyaXB0aW9u IHJkZjphYm91dD0iIgogICAgICAgICAgICB4bWxuczpwZGY9Imh0dHA6Ly9ucy5hZG9iZS5j b20vcGRmLzEuMy8iPgogICAgICAgICA8cGRmOlByb2R1Y2VyPktPTklDQSBNSU5PTFRBIGJp emh1YiBDMzg1MTwvcGRmOlByb2R1Y2VyPgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAg ICAgPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6eG1w PSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIj4KICAgICAgICAgPHhtcDpDcmVhdGVE YXRlPjIwMTctMDYtMjZUMTU6MTI6MjArMDI6MDA8L3htcDpDcmVhdGVEYXRlPgogICAgICAg ICA8eG1wOk1vZGlmeURhdGU+MjAxNy0wNi0yN1QxMDozODo0MiswMjowMDwveG1wOk1vZGlm eURhdGU+CiAgICAgICAgIDx4bXA6TWV0YWRhdGFEYXRlPjIwMTctMDYtMjdUMTA6Mzg6NDIr MDI6MDA8L3htcDpNZXRhZGF0YURhdGU+CiAgICAgICAgIDx4bXA6Q3JlYXRvclRvb2w+cmVu b2lyPC94bXA6Q3JlYXRvclRvb2w+CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9uPgogICAgICA8 cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIgogICAgICAgICAgICB4bWxuczp4bXBNTT0i aHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21tLyIKICAgICAgICAgICAgeG1sbnM6c3RS ZWY9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9zVHlwZS9SZXNvdXJjZVJlZiMiPgog ICAgICAgICA8eG1wTU06RG9jdW1lbnRJRD51dWlkOjZiZWJmODkzMDdlMTFhMGYwYzE0MWIx Mzk1Yjg2NzEzPC94bXBNTTpEb2N1bWVudElEPgogICAgICAgICA8eG1wTU06SW5zdGFuY2VJ RD51dWlkOjVjNmY4ZDliLWFkMjItNDQyMS05NDE5LTQwODEzNDJkM2ZlNTwveG1wTU06SW5z dGFuY2VJRD4KICAgICAgICAgPHhtcE1NOlJlbmRpdGlvbkNsYXNzPmRlZmF1bHQ8L3htcE1N OlJlbmRpdGlvbkNsYXNzPgogICAgICAgICA8eG1wTU06VmVyc2lvbklEPjE8L3htcE1NOlZl cnNpb25JRD4KICAgICAgICAgPHhtcE1NOkRlcml2ZWRGcm9tIHJkZjpwYXJzZVR5cGU9IlJl c291cmNlIj4KICAgICAgICAgICAgPHN0UmVmOmluc3RhbmNlSUQ+dXVpZDo2YmViZjg5My0w N2UxLTFhMGYtMGMxNC0xYjEzOTViODY3MTM8L3N0UmVmOmluc3RhbmNlSUQ+CiAgICAgICAg ICAgIDxzdFJlZjpkb2N1bWVudElEPnV1aWQ6NmJlYmY4OTMtMDdlMS0xYTBmLTBjMTQtMWIx Mzk1Yjg2NzEzPC9zdFJlZjpkb2N1bWVudElEPgogICAgICAgICA8L3htcE1NOkRlcml2ZWRG cm9tPgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAgICAgPHJkZjpEZXNjcmlwdGlvbiBy ZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6ZGM9Imh0dHA6Ly9wdXJsLm9yZy9kYy9l bGVtZW50cy8xLjEvIj4KICAgICAgICAgPGRjOmZvcm1hdD5hcHBsaWNhdGlvbi9wZGY8L2Rj OmZvcm1hdD4KICAgICAgICAgPGRjOnRpdGxlPgogICAgICAgICAgICA8cmRmOkFsdD4KICAg ICAgICAgICAgICAgPHJkZjpsaSB4bWw6bGFuZz0ieC1kZWZhdWx0Ij5yZW5vaXItMjAxNzA2 MjYxNTEyMjA8L3JkZjpsaT4KICAgICAgICAgICAgPC9yZGY6QWx0PgogICAgICAgICA8L2Rj OnRpdGxlPgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAgPC9yZGY6UkRGPgo8L3g6eG1w bWV0YT4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAg IAo8P3hwYWNrZXQgZW5kPSJ3Ij8+DQplbmRzdHJlYW0NZW5kb2JqDTEwMCAwIG9iag08PC9D cmVhdGlvbkRhdGUoRDoyMDE3MDYyNjE1MTIyMCswMicwMCcpL0NyZWF0b3IocmVub2lyKS9N b2REYXRlKEQ6MjAxNzA2MjcxMDM4NDIrMDInMDAnKS9Qcm9kdWNlcihLT05JQ0EgTUlOT0xU QSBiaXpodWIgQzM4NTEpL1RpdGxlKHJlbm9pci0yMDE3MDYyNjE1MTIyMCk+Pg1lbmRvYmoN eHJlZg0KMCAxDQowMDAwMDAwMDAwIDY1NTM1IGYNCjQyIDENCjAwMDAxMjQ0NzYgMDAwMDAg bg0KOTggMQ0KMDAwMDEyNDY0MiAwMDAwMCBuDQoxMDAgMQ0KMDAwMDEyODY2OCAwMDAwMCBu DQp0cmFpbGVyDQo8PC9TaXplIDEwMi9Sb290IDEwMSAwIFIvSW5mbyAxMDAgMCBSL0lEWzw3 RkU3RDg0NUMyMjMwNTQ1QUFEQTdBRjkxN0ZDNjNDOT48N0ZFN0Q4NDVDMjIzMDU0NUFBREE3 QUY5MTdGQzYzQzk+XS9QcmV2IDEyMjM0Nz4+DQpzdGFydHhyZWYNCjEyODg0NA0KJSVFT0YN Cg== --------------CF1EC0345B9BE4B0480D3D89 Content-Type: application/pdf; name="etsi-ipr-policy.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="etsi-ipr-policy.pdf" JVBERi0xLjYNJeLjz9MNCjIwODcgMCBvYmoNPDwvTGluZWFyaXplZCAxL0wgMTcxNjYzL08g MjA4OS9FIDEwNDQ4L04gMTEvVCAxNzExMTgvSCBbIDQ4NiAzMTFdPj4NZW5kb2JqDSAgICAg ICAgICAgDQoyMTAwIDAgb2JqDTw8L0RlY29kZVBhcm1zPDwvQ29sdW1ucyA0L1ByZWRpY3Rv ciAxMj4+L0ZpbHRlci9GbGF0ZURlY29kZS9JRFs8M0NCRDIyN0YxRTBDNUE0Rjk4NDUyNjJG Qjk4OUYzQ0Q+PDRBNTI3OUFDMTU2MzlBNEJBNzM3Q0QwRkE5MEE5ODU1Pl0vSW5kZXhbMjA4 NyAyMV0vSW5mbyAyMDg2IDAgUi9MZW5ndGggNzMvUHJldiAxNzExMTkvUm9vdCAyMDg4IDAg Ui9TaXplIDIxMDgvVHlwZS9YUmVmL1dbMSAyIDFdPj5zdHJlYW0NCmjeYmJkEGBgYmDmBRIM e4EEkwGImwAkWHyABGs7iCUEIlRARASIeAIi5ECK7wOJmycYmBg5toEMYGDESvz/uec3QIAB AKd1CxMNCmVuZHN0cmVhbQ1lbmRvYmoNc3RhcnR4cmVmDQowDQolJUVPRg0KICAgICAgIA0K MjEwNyAwIG9iag08PC9DIDIzMS9GaWx0ZXIvRmxhdGVEZWNvZGUvSSAyNTMvTGVuZ3RoIDIw OS9PIDE5My9TIDEzNy9WIDIwOT4+c3RyZWFtDQpo3mJgYGACosUMLAwMovYMfAwIwMfADBRl YeCYAOQwMtjdMXug0/KAj0U+gIHX08huXqH+gbDVudsaGOR3Hfy9RgpMAom/6+RvPQQRDzgY OBqUOjhYIxqMO4AEQweQz9jBpNGAzSigHWIMjNULgDQ3EAuAXMCowsDPIMHxQdLBzCD2wAHG WUwHWL8wvQFKiPxXYDS+1WgBdqg0A5OQP5DmYGCI7ATSygxM2TfAbmZgugP3jgoDU94WIM3L wOBQARc1ZmA6xAxRy3gJIMAAMsY6nQ0KZW5kc3RyZWFtDWVuZG9iag0yMDg4IDAgb2JqDTw8 L0Fjcm9Gb3JtIDIxMDEgMCBSL0xhbmco/v8ARQBOAC0ARwBCKS9NYXJrSW5mbzw8L01hcmtl ZCB0cnVlPj4vTWV0YWRhdGEgNDkgMCBSL091dGxpbmVzIDYxIDAgUi9QYWdlTGF5b3V0L09u ZUNvbHVtbi9QYWdlcyAyMDgxIDAgUi9TdHJ1Y3RUcmVlUm9vdCA4MjkgMCBSL1R5cGUvQ2F0 YWxvZz4+DWVuZG9iag0yMDg5IDAgb2JqDTw8L0NvbnRlbnRzWzIwOTEgMCBSIDIwOTIgMCBS IDIwOTMgMCBSIDIwOTQgMCBSIDIwOTUgMCBSIDIwOTYgMCBSIDIwOTcgMCBSIDIwOTggMCBS XS9Dcm9wQm94WzAuMCAwLjAgNTk1LjMyIDg0Mi4wNF0vTWVkaWFCb3hbMC4wIDAuMCA1OTUu MzIgODQyLjA0XS9QYXJlbnQgMjA4MyAwIFIvUmVzb3VyY2VzPDwvQ29sb3JTcGFjZTw8L0NT MCAyMTAyIDAgUj4+L0ZvbnQ8PC9UVDAgMjEwNCAwIFIvVFQxIDIxMDYgMCBSPj4+Pi9Sb3Rh dGUgMC9TdHJ1Y3RQYXJlbnRzIDY5L1RhYnMvUy9UeXBlL1BhZ2U+Pg1lbmRvYmoNMjA5MCAw IG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvRmlyc3QgNTQvTGVuZ3RoIDc2Ny9OIDYvVHlw ZS9PYmpTdG0+PnN0cmVhbQ0KaN7UVFtr2zAU/it6bB+KLrYuhhLIZaGFrYw1rGMhD27iJQbH KY471n8/nWNJVdKk7brBtodjHZ+bPh0dfYIzThgRnAnCOQclITxBJSVJmoAiCZfMgKYI1zwl 5+d01D+hF0X13SZPvtnPkpzS0SfreFfPN4uyXlr142g82sy9gRhhbOCnXo+ON3Vr/ZhvhAIr /ZqPbu2P7kIgqCyqxXY66/Wm9HI4HOTbYkEEyzKImNn0/nZe1C2xJzB0mN9dFOVy1RLNFR0V ness0YqOq3y5JYnAXQeDzY/pmbJIwGfLMYYFZugd5+uyejjpN2VenaLlKl8XFP/PBptq8WGC 1uu2Kdr5il5tmnVeoenG7c4YvWzzqpz362VVEEav22L92bZU0cnDXYGxAK8p79pNQ7841JJn vZ49E5wSQnb39C2kN2Xdr7dl+B+XzbYdrvLGbrRbubtJaOz73IUIKen1/W0LMCbNfYF4Aihb e9GutlMtGfmbIrQhSZKQVKdESoViTEa0EEQknQ/F2qRJQzysID7nJfF1oIYXZV9ApiXuFYtS Gn3a1kccbh/0WbuxdTDW2iHWx4U8p2dp2tmc3eMOOBwuWMEfr2AHHSQ+K6zQH+/zgv2J8hBv 3B87+RAjDAu9TGz/Mcfdg4/j8EzixqEBThF+IAW3lSykYwnIdH7I7oJ9lq8HjcEIVzY0Ze/S AKzP0YndXjtcAN7ZpBQkhdpp9jgsUEvvXjyKkt2AJWkQf2GHBEGHm43EH9dLSAJ9TwCsjmPi KXOTcWxqjbvVJ43Z239/GmKBxhy0P07bDMkoECxTRwlWyIMEa/sKPk+wTL1MsC9ya3qEW415 A7W+nVXl/8qq+Kik3JklmDee8T/GqiE+YtXu2XMZBvxZWnUM0L3Kt9Fq/BBSle3Qqqe0GHDQ AYMV8MNqDjAQ1mG79KhdTuA6yyJCdesTWoXYmEV/kVYdxHBfh2nV/byaVtVv0mqiX0Wr+6zp 5d+g1egyjtHqs+PvaPWJ3ddlzNLqTwEGAPbwjR8NCmVuZHN0cmVhbQ1lbmRvYmoNMjA5MSAw IG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDEwMjc+PnN0cmVhbQ0KSIm0Vm1v 2zYQ/q5fcR8poKL5IpJSURSIk2zx0KJuInQYjH5QbPllcCzPltf23++OpFzHaYp2w75I4vF4 L8/xntOwSgYXu241r6cdvHo1uOi6erpsZjAZVO0WPg6Gw/YzTJSSXOTgCsmtMaCd49IWJRTC cWFKjYp3h/vuy7aBwU1Tz5odDCq/GteL1abuVu0GXr8eXl1CMri8EzDdgwDYTzfJoKoESKjm SSa4EAqqKcSPT1Dy0kImUNd/KVdwZ8GVlpe4/5BM2DhVPGf1Is0MvhtIP1a/JYpbZ/BQNUuY Nmn1ZyK8WTIpuVRxC2jnsVdJKlnJTQkZahpHihN2m2aKl+wQvKxT3FOs2UMbBPM0s/gClCvc CDHtUskN8xqGTeNWMwsnDkEcdJoXZFAezxv8UDl+XKSKHG175UwKfK+C+3U8pEQ8Jp1P/iRV w3VZnCZ7/ZYK8EzBh23XtQ9fa45GbQ7aYOU16ALDzrHkecFVWbrTiv/Stt13K15V8lslDmBL y1UuIXPoCEvj8b72CFaYmOOW3fnVKOZ7FWqxSjWudoS8Zg3iW+CyQx0Sh82/UYhVoid8QBuo F/X3QX1Fr5JhpNpjqJl74S0oBhfe6XYXShs1194uqIi4eAo59oNTTyC//rE2M0bw0mgwCt0I J8EUGKZ1DgpteVH8TJv9lZgcbw3FkiNuVkKRKy50Absm+R02ybBKBC+MDG2ITZYpF5osNp2x gpo+usZuiwlVyfuftx7KfVr3Zx06a0jg2/sW+0djQxHK/87xs14kctl/y+qY1He8CM2LkMpL GI3pChtkE7xf8ftdShfpDS7Y6JJutmZ//A/ZGi3Oi+gv5nuyMLiRdCnfXo6u0NHXpo28TGnm Ic2el7FPPSvj2wniYkduYqLYOZZtkLPwgeT2GezLsy5BbnvKwcfroQNNu8hcxAYZksEdPUd0 HcA/Nx2SZ8kacrROHfGhDqspPToE+VCnJsgJbqLkTCEjS8G2pBj4QxFrFOxLqoxnYIH18dSg 2WJJVvZkLhhovTHaw7PE6QbPnTEAjij9lHNv1BFi2UNMJI+6WHRpvL70o4ob+zw4vneQ/8oe nB4LFbObHaYhNRL5LNrNWYincY2PYakfouuziRyrj3NJxeoH0jZs2cCvaeZo5m2ayKJ15E9P n5IFio1c7Gm6efCTL2f3a5JSVaRl0M4jrwNehZK7o5PHk2FZB64PlN8FaX0fqT34psmgep/L 41SGfnJg2PM4Atp1T/phSkQ7n9KSqzhhNlG2CP8dkz6UXh5jaNan48MPq37rEDXPoBn7cRWn Ve9524+vLkZI6IRD/nfh9nQyLpaPYwjQhF+Td6Ewb2K0yDsyx4NIPPCPAAMAkk890g0KZW5k c3RyZWFtDWVuZG9iag0yMDkyIDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGgg MTA4Nj4+c3RyZWFtDQpIiZRW224bOQx991fobSlgRxlprgKKAlnH3XrRNkHtlyLowySerJNN Z4o6F/TvlxQpeeztbV/mIo3IQ/IcctZ/zXK1vlZ4eVZlYawv6HkzA6PXd7PcuNbLgqKFxdu5 mp1cqBcvTt7Ol2eqUC9f/nGGaxkeLlunMmts1RwfeO3SiTKeOFmvc2XV+mZm8ViOXvDe5MY7 VbeVqWq1/jQDxzDwbYIiy02e24CbH56VM16AXsKZttDrrIIb7eBWZwUM4fogr8bCOOz0x/U0 +MrY5keRVhPclnEHGE5gFA1Z8cbXHEx4knBqK+FcwlpntjEV9F90ZRr4hK/OlLDTWQvqVhfG waAeNKURtr260LR7rrMGN94seX2Ot9J4+KDxViJcslHAs84wC7AlKxau8S0nI6r7orMa93v1 rD2awVfb4jn+TnzJrQ+2CAPvDgrttPjQfRYvjFE+72TxPnys7ulbD/23bBYQYMRQd2x2290H e2JgGw0+6ZJOpkzIcq8wYa6k/HWDZOvvGH8wHH2rG7yHSkv00VJK8pzTxZ67Rz6trBirJBEq 0GRCOKpynmh+hiXtdW5aGML14ZZK5eHhngNAKxatbHCzAXUWMHlYoM8CXumMyrd8R8g8LIka NYa2PCfEDsJ6C6s9Ub1p6+Z/6bNO+rR5QPxTfTa/ok9XGRfkWXxLnkkWU1FeYDQwauTK7TXl Fr5qhzw4v8KlO21zypULrMVSVaRTXHvStuWNiVxbDPpHMbc/USo9fE+peW5EqIVhwtijPmFN 4dv/NKOS9unJWf6oLOsY+ZJbzgPfkH9kdhfiY+paWFDtPdZ+tTxyV6LJUtz9lty55K4IfNz3 7UvR13h1J2IkAQf2E+2Z/E8sPpZXEEmQOcRGEVUYBTwRwVGg3tgieV5xFDWcviNqe2zE4Xb6 Pr0iwT2sYtgdSRC1GPoZqSQjryomYzHnc6/lnFiVfM73oHzIuTNtmbCcvhGjanURRNgkc3L+ FSm13FvDvgyn0bWsohIxQnJcEerkMOXfcrmxAHkbXcdcb7vYi1IHPiruhECH5CxMXdlo76qT Zhmb80bKswdUhQxkBVK5CjPY5RUfHofQamHE3uzhURDdMjdoChJZgh55OMROy0SR5r9VV+K6 FygxstSOtbWp82PS0wSLUCOVAs+2w8RLGFXtwShxwt9D9lr5/Cl0agGiRjkX+/1keC40bTzK 3BklhM9C78mg7Q98s88xjmYOsYTHYYp2n8h9GnmEJMST4fO7UGJfsbJJgyTUigZJx2Y2/c1B vEO/ofwjiAKbJiphEmSai3/yL0I/9HG8dzJTT4nDDbcFRki1alNcV4EZYlianpI/jUGNkr1N JIBEFBGMadDGPKf8y3vCytFM2pM/TJaQEkd/6kxuX8b447QKf0TLCU76jP+T3vNIZz7/0q/T Tv6S+v4fehJ0+qP6V4ABAO5NZysNCmVuZHN0cmVhbQ1lbmRvYmoNMjA5MyAwIG9iag08PC9G aWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDk3MD4+c3RyZWFtDQpIiXxWTW/bOBC991fwSC4q QSJlWT66iYO2SN0g1qVY5EDHbJxsKhlt3aD763c+ZTq72JNMcuZxPt4buv/4pqjKKsxM/2L6 P978aX+6oi5rO5rvrmjLYNPueO+KziaDJ6H0dp/07NEFMP2Bx3+5wlewMJP/ynkw6WE5L2d2 A6vGfuDDt/wx8PH2k7vrP8LFK7L4hHvwfeeKRTmXzVsALxeAQXvqHQeyDXZnRrl1TzveJgmQ QjPxcBDLZ1gD0G9Xt2D9yKvhwVAIWIiqMf29oZIELIkHu642lel3GCJms8BsIBFM3Wx0Z7l2 RQNgl7Bu4bu81TVCI3I9IXeI3Cnoxs0gRRMh084OmCJkRAuD4A2Ar8Ak2Iv36w+uBsyLJWY3 t9do7G0Wvdc76hrvKEJD4UNtfDXT67CiN+jaSXkvuLzSnCtXzLRVHs9qzGN51k0x/eyKOXzW 2h4E0+5oR6KUXtYGOeOttu4XUQvbBGdoYr8BGOachlceE2IyB2pvY5P2NUq/o9hIZ8chZxp8 4248CEUmS+zjKDhDTqqcNkFMvSUxvEoqB8FIx68iFcM10bJxEalcHTLFT4UVhl9KtYXpRsgT 2jDpk+4fj88UzA4Tq8vWbpP+enHIiUjMV8UmSEakYFwFgUC56g4LKJUXuJ/cc7Y5JUHLOLxW ifx4MZBbF0QkdrVx/dOJ8Bg82ZQhzM8pv2IWr5XlTO4lcf2aBSA58ckNed1yOBhcBcGNZPgd 5RhURGyxISAFX5Lz+lKkc3spSbLe1J/22KUl1TWsOo+a47gyyaHOpBA0P3ES1O3ildwAK0Ds 2OUVLlBvYIdJVZDVlWs5d1xcKCfIqUclTmefXQO5rckXA53brYPqzG16dPUMNgdcdvaBD49D 5PUvGHY2ig0zObLj9pk3ExuW2v3zcQI/Wk8thEAbrz2UEaBy4UvjPfNJ5zALI01ib86nLna3 URHtp9fEV1bPxu0Tm6d7JTRDLAQtvc1YOlcG75MEoDj/8xihY0sLvP4ml6N637AcZdxdiyOO xpn9QlgMQhpLSd9ClhydRKmq1DBnyDbKqxQHeWjl1m1S/b5wOCmdV1uT1UdPHYek6e/EPotE ZF3nIUtZ47DTQaqO0qy/XcOzNZym3XksOixGGc28eziK0fY0QmscYdRivP/44yxnNviPNJVT AW3zC3OKeeH3bqJPPsMmpPScc2r8Jn85+OVpQDn5pM9GPGQ3KD2zV10GM1TvX3+RGi3gw15w pBMc7Sm809umT5H0fEg6q9nz5CIszAjbgc2d+UeAAQDIaxvuDQplbmRzdHJlYW0NZW5kb2Jq DTIwOTQgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA5ODg+PnN0cmVhbQ0K SImUVVGP2zYMfs+v0KM01KolK7ENFAVSX4pmuN4OS94OfVDOLrLtZmdtrof9+1EiKdtpe2tf YkkhP5KfyE/7Xxe52N8L+HkSZqnrlQvrdiG12v+5yLUtSzoQ4WDzvhGLl7fi1auX75vtlajF 69dvruAsM7XOKycyo22+/L6DyZNHrvPcxuC4eBL7XxZ3stAKQIy06sN+lp0u6mqayxTA1mji 3ApN7uQWYW6V1U7+rrICvDJjdSGPQ1xY+aAKsGi7TypbgdFnlVXJ6EllVtfy2J0R50g+bCz+ BgMHi44XhznOoIwBgI/gV4Cf2MRE9rAt9VLuVAhCOQrfE3orZuEK2f0RcwRkU4Wo64jyVmVL AIkfxyjXWwq1pkiBv0iSY5ZdYMlW2lY1MbnZxXueslyUz7Oc6+UqsTwwHecYzujSlfzfMeW+ gkpaqkicPFdDtaJZF2l7QYzEDZMwPD7AFshs8XYC10SYwC7RoeeeRFYA5dMmvJO+7f4hmEd/ JoY6wLNG/qvMKgSDU6hb+r5NqLku09X5WR0XrsGQOOCcqHVSmW3XTgHNSFo8PdPpsZtFfwwU BF44vSG1UnIbvYrIopUz5C0h38ZmgxkwDvIiXDRBrx5juK9Ap0bc56eHuE193/Xk5dN9xssa +u9kvptNwjomd4OcXeFnzUNLZzHvncpqXY03npvQldlcPTx4VrKPv238Ffvov5QbtYRAzbub QAs0s2zWgayVvAa7Uopd2JVAVpipDW6arQpD/DZkgoNGjgGKgdHmN5U5KP5md6lbq8m4saqm g2+LpJnKqrM2dLRxz8mqfUZW8zgQphT7q4m+Fj+ur2EFOV0q7HOKhvPrqY2wY2iIWeL8X8Bq HjucRqvz0Y3lufeHmVCPTRm+JjUkusHBI+Nwi1OkQXT9pckLbsngHNMQad7JRmA64jTELyHg MBwmlRlGo4hxmD2vBKoHpTJ5Y4CB+7Abp6aWX5RLgshihQG5eATg1wn/u8fM+IlKdBLho+zN RDNLM5TrqhobJShnaJTzANMKsc7H0dyyeewGGC9Tczd04sRxKdWTJzVKXGBhQ08GLPae34bh 9JWEeDZuhT8xMBWGcJFE1B47OnKpA4suzLdxF7rjvqE7BepOFXVnSWI1eaG5CRlnE30aBHiH H0KlYWimonadmphJxcnKkMzp04Whb1H2cNiaGfD8/W9ivuvZUG6RFdCmMmgTeiMuk9/1PKUH orUTOMv/x9RMoS+ZChf2gxQVc44KeS2i1pdYezn3/7naDdZu57WPwnDohP8SG4g6BwfaT+cb Bic5RMmJtyf+E2AAodplYA0KZW5kc3RyZWFtDWVuZG9iag0yMDk1IDAgb2JqDTw8L0ZpbHRl ci9GbGF0ZURlY29kZS9MZW5ndGggMTAzOT4+c3RyZWFtDQpIiXxWS28TMRC+51f4aKOuu/Z6 XxJCgjSIohaqsreKw6bZPlDZjQihgl/P2DPjOGngEq/tec98n9N9nOU6z43onkX3anYj19NP lRlt5ACL1YUcaf+oska3sn9ShbZShFsrtxs4lsMPlVXaybARjyBh5IgiRva3XtNIv8iJJFf9 SBbodhDPKrPg4DHYJ6cPFITgPUcl7mN87Lwng0/BvVjTMcU9BvcY2jpKhqsBw57u4DjkFvbk sR9XfbBUyBV5JIt/FPjcL840qq8dVFR0tyL3JZVadd9mRaFd4fzJagaVg5PF5VzMTq/E69en l/PzM2EK8ebNuzM4zIpK27oW3qwrDzU+2J2KY5XTrssFdPBuZqzIcvADa53r1oqihoAr0X2f Seet5Lqs0jh8752PNvNf1ocMPWhR5EaeqQpSs3Jz+wS/kyrlZgs/P5QpoGF+f6dqKc7h8koZ eQ3im4MKNLr5f+ZlkobBNDgYMMFRtbqtMLfwRdm5WtchuxvpNHbCHPg3umibNIAjxo12ruKc vygLU7NdfkNDOq+wLHw/3CbTIVSuq7DxgzMJ1uFSNmXJenMcb5q5PgAnwOxgYl4GiQHADNVs i5O1HmOQoVwOZHei0X5WLdyfcJReysmBofjAJ5cLlbW6lpfvcF0oP+DXGKpPrkZMMw57ckMY CwI+E5sHCIdqIMaoQAitIEd4HHrKnEMd+yVZR6tDDHdkxA09ffxSLmoWcpvSzknaESSRETcM d8ZxxGzBrLRNAkA504BdbKfvhQkECWEXtvTQtHmJnVhtI80E0iNX9zvCYhpcDXQHOURyRYfT +juU0OkSUubBIjaCr17gSHZwUIPM29CjT9ijM1zeBgnomynxyPMZRSZYEZtLc/gBFzJzjl7h zjgyV8gLcBym4iodjvmexnuVleAj0S8pGPZKV59VVkOq5E/gfD5QSZjCI7vvzZBYp53zBUta h51e83zy43VIQw5CMkQDJ8h8tmn/yQtNFfoNWhWwYdpwcjD50Srj48LNgpqXUClsp6NhxLpx PbCZoSqWBHYvTyJPtUfxRdrzg8piuS8QNfH0KkUyoRAFIjZw2+9zGJaWE2Ba+a1MReDynI/J MpAfUCfiWe+QGMNhYOAhNdSR130sMkNSz09Saz1H/ZK4wpIwV4lZb5cRxL6FvrsG/+7chCxr j10Iw+G8+eURgvWluPfT7KcRXcddtGf55Szb+P+JB5CZdsRy0/bIf5TANNN62hyVSAYLwUwV aGUkhVIz5HacEFF4vUcTxAnFUU5oPCeEIQscsIM0Ekyo78XOOzGDV18EV/NU0b5kBhuJ5Rg1 mEgN+ODsvzR7D5n/n8VfsRzLaeTSCYYTln41CH5gwsTSsMVHA4H3VfwVYACdTlzjDQplbmRz dHJlYW0NZW5kb2JqDTIwOTYgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA5 MjQ+PnN0cmVhbQ0KSImMVslu2zAQvfsr5laqqBktlCIBQYBsBVLERdD4Uhg5SJEap0gko66b 9u9LzkJJtuvmJHJEzvLmzQznnyahjhID81eYv58sVP0jmGbaqDKYRrGO1WtQ6EjBT7u13yVK E9VAySv+wZ+mHYufgmmuC9W1YPeRPlbdN7tIrF64Cty5ud0e61Td2Z1R13RLrHVyq7RqY2OP /wmizB1gNbuOlbyHGQqMukLFsjsPpoXVR8IvVql17l0wTXSu1tZVBezBrRyIUkVOZIyEGHoK XBQPLj4rhBd00KA4Uo9LcaNiGBsJhcK+Iz/uhu58JncEEfbkDM/fyHUy60GU6IfZwB/B/dxl Ngwjn9kVZ7ZbdRir3HlGl4E0rykgwH+RKuuOT60kwzVHpMkEzB8gdDYKHZrcLeuJvT7/Prma XcDk6BZOTo5mF9eXEGVwenp+aYUulLyIwSqMw/TAjWN/w4USoy1acExGk1fxljORToqRM70C t0pSOmRMRocWHvZlA11FkDB5H0tBlZLbMQAtMWa1QVwTItBGUG2FAcJlliOy6oJyTXbKDV5t 5AQFFauIDUFZ8a8Ow1yoX3gefHJgKU69kmLRRQc58dB24hQ6QRkn5qZq9UzhSolJA5CKFjkz oxNmC1bIe5aVfflL8ccegZZrM+Fa6GtT6jXByjPWGWoL+9jsW4QrQWtDaLnBvcTpyxnrjAse CO6SYcELy2a9TaFQF7FwSDsOhTrOi4MMz3uGGx1m/yd48VaCJ28nuF1Eyf/4janmpB3itwOR GW4OMTwZUnzMbpYyyYnd7kfkZ0jVeboa12JAaMSV5QV10/BKWNvU/bCoGpDGuHke9UkKjKOm X1IhNXCZtyDWOO5VY5kRh8Sl2M8cV48jTdD8dpGRjbWwrzfbPvLwEhpHeZ/fsq1BZtmGI9n4 sH2Uge2YhQ+6agYtZzAOnWsQID40wM5GM3bvmIGPwTS1Xzo644K5YZi/ohQoED9zSdFwdCd+ dC9LcapqBOOWFbSioWP/ZWraLO6G8CJvDTlV+UZGfRApnxLloxxb+gKdzHg0GprXmIq1G6Cc gnGx9T3lX6AlBFq+BZoZgpZ41JIetamjlTRSGNPCx05lIu3V+h+njvvIpKV/QEnVAFyzmlYQ s2imtruJwr75ItStFE8nnRykwuX1IHTyrxjkW652gKeJ1+08PwbcF2v7scQ2PAIz2wfmFpZG fRjMLR1vv4KCe/grwACSnVSQDQplbmRzdHJlYW0NZW5kb2JqDTIwOTcgMCBvYmoNPDwvRmls dGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA5ODI+PnN0cmVhbQ0KSImMVktv4zYQvvtX8EgWK0Z8 iJKAxQKu43a32KRGIqCHYA+OrSQuEjto4y767zsvyrLTpD3E4mMenG++mUn3y6S0pQuq+666 HyY3erk1hfM26L+NS9bpD7AN1mtlnLOtfjKFjzbqJUl5kPINSKnbXv1lIqx2ov5oAuz22doL fGG//MMUCbYbU7QgUjS2IUdaPdNNHPTZGsmt+7U13zp4qepWqsSnumhTXeF6PYGndb9P5hcz NTlbqI8fzy5mX86VL9WnTz+ew2Hhalu5RuEDYnWq8dkfVFxWOeu6UjnV3U2cV0UJfuBbl7b1 yqXauqS6p4mu0EppqzR+RwFwlo4eCgvC1du2ZZEbvTBF1BCq17uVKSrd4896jycQbm8q/See qDsDEiSnZgZQfTINYY+IIJqe/lCb1ArUO4EI8HfvIuRH4ToOl17v8+sd2mltmxgDWgkKMQgK N3puPOStM4hz0te0+8LpVhBMox+WlOmWOAEB9XSaGSH5vhWZDfGG9dS9sGy/4ct1P0gBL7Zs CLBiiu6EXEpMP/Rqxf7Fx4b8C9Eyk/ut2rEFh1hDHlr9qykgy/riQuLg4KrhOyesCayYwYqU 6tq2LvNhfk0EGTIyIsgxxM4mFzNDvpvWeg4wx6EkMI73WUDpVyMYc8w79dbTkq1jffyyTFBn Q6iz/+s5WHJQl5dAVfhgzC3EDFAgRNOvCBFkUfYLkq71FUq3r1iYbApCfm3Zqa/rd2kZhsKN 0VaB6raq36vb+H/q1jU2eKrb9G91O2RlXK1T4yJ0ogZZCjl5pM+tASY9bl6w6KB3AQF3cHIH pau+4tUKhXr82cL2sBtBA4iV6V0Qqv+qTf9mbbbB1p5LM1lmhTvtDTa0zauudUrKGFMG4jdI doD0PhiiBtTMMCeYcKjWoH4hK6A7s+yYisS36kAK4JsQaP4236DbByKcw263uKIOSe4dVnOD pYGsxKnjgJtLpugLKWAtIQZbPrwnc54KJsi8IvPLvHgWCbFCDqIWcbYFSXWl3ovGkVMRz8+7 zuFMJcxLrpNzDnZ6NWxh2rZIpWzFl2gmq89nLPiZP2JFMJqJ9gGrDOpinu9I1OufsLPFkSKa mbKXmIWg/bVwe5kfdWgpmSJNwjwWnEigmC8rzuaofStTwjy4ld61298LYR5yy4L7ipIUuHHl LbXugV1oZCnHL9Lp+21esb/dVlHAlT60cjI3nk0VzaaQZ9OH01fwxBjYTAUGak0MmarnBG+e UTJHjtowjKDjSgv0rwdXWvG60shJOW6/P/Po6be9tHlxAzP0m/pHgAEADwQSxw0KZW5kc3Ry ZWFtDWVuZG9iag0yMDk4IDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNDA3 Pj5zdHJlYW0NCkiJXFKxUsMwDN3zFR7tIT7biZ1k5jrQOyaycQyhCUmgpKUEevw9kiwXypLI 8vN70pPabWZEuxPwOYtC+xAw7DMpVPuS5UYb4+hemzogxugi2Ih5kIdnldtCO0AbHeRGOV3I FnKV9vIeTqW8hZO2BPDyQ+W1nDpIIXCv8Cl+8T63FhAznd4YAX9XQnboY75bI9uwhwsrv5UN zB3kSeUB9Ib3T348kNr6V58PE9ECgpFCPbZbatZa7DF3XgdXCQA747lVxp5VA0UvA8sJpjyI cQY53cgvVWKFiTriY/kruQX6AG3kIpR1vzkihJoGEbsu5WEhcicn6oTg3RKLxcGUOJico7MA L8oqTWYGWStPpwFZHRRlDbTgdS13wI5WXnrGDmnAGNASVHWieVI5zQjb8VdOxbXAyBWkrn2T XqUJLH2ygZtjs7pXqMFAEG1ZRsEBoR0tA9YYvWOnZ9qWlRfu+sEoUn7q2DPi+Oc7y0Q3j8Br a9yYY5e852r7y1TTFEcuomPBhS8uzOTL5u5GZJs2Ez8CDAA2MLsnDQplbmRzdHJlYW0NZW5k b2JqDTIwOTkgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAyMTYvTiAxPj5z dHJlYW0NCkiJYmBgnOHo4uTKJMDAkJtXUuQe5BgZERmlwH6egY2BmQEMEpOLCxwDAnxA7Lz8 vFQGDPDtGgMjiL6sCzILUx4vYE0uKCoB0geA2CgltTgZSH8B4szykgKgOGMCkC2SlA1mg9SJ ZIcEOQPZHUA2X0lqBUiMwTm/oLIoMz2jRMHQ0tJSwTElPylVIbiyuCQ1t1jBMy85v6ggvyix JDUFqBZqBwjwuxclViq4J+bmJioY6RmR6HIiACgsIazPIeAwYhQ7jxBDgOTSojIok5HJmIEB IMAAScY4Lw0KZW5kc3RyZWFtDWVuZG9iag0xIDAgb2JqDTw8L0NvbnRlbnRzIDIgMCBSL0Ny b3BCb3hbMC4wIDAuMCA1OTUuMzIgODQyLjA0XS9NZWRpYUJveFswLjAgMC4wIDU5NS4zMiA4 NDIuMDRdL1BhcmVudCAyMDg0IDAgUi9SZXNvdXJjZXM8PC9Db2xvclNwYWNlPDwvQ1MwIDIx MDIgMCBSPj4vRm9udDw8L0MyXzAgNTMgMCBSL1RUMCAyMTA0IDAgUi9UVDEgMjEwNiAwIFI+ Pj4+L1JvdGF0ZSAwL1N0cnVjdFBhcmVudHMgNzAvVGFicy9TL1R5cGUvUGFnZT4+DWVuZG9i ag0yIDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNjAwMT4+c3RyZWFtDQpI ibRXWXPbOBJ+16/A25JbI5oACB4zqVT5SGq8FWecWLtbKWdqi7YYy5NE1NiWk+yv3wa6GwAp yU42kxebInF293f0wWyyt39zd/2uvbwTT57s7d/dtZeLbi7O92b9Svy+d3DQfxbnSsksL0RV y6w0RuiqymRZN6LOqyw3jYaBZ+uLuy+rTuz92rXz7kbszdyv0/bqetneXfdL8fTpwdGhmOwd nuXi8lbkQtxeLid7s1kupJi9m0zzLM+VmF0KevgkmqwpxTSHse5JVXVWlaJqyqyB7x8n58lp qrIiaa/SqYH/nUh/n/1jorKyMjBpNp8kukxnf0xyt6xdUmZS0Sdhvwx3lXbItMlMI6Yw0lR2 4HnyOp2qrEnWuMuHFL6ppLsVPb54l05L+CfgvYIPeKabVGYmcSNMckmfujnOWONrHNP9ZBeU fr6BB1XAw36q7EYrHjyVOfy/xu0/0CSV0zRZuctHVzWZbur4ss9ObAJ2JPygv7vrP4acw6Jl IbSBzGuhazh2ASkv6kw1TRVn/Hnf3z2Y8dlMbksxBluWmSqkmFawEaTGxfuZi+AMLlZlZXLm fh3TfY8wF9ephl83NvI66SC+Nfy8gzH2NX68h5eQJftX/AvWgHE0/haHX9t/TQIn1S6GOql+ ciuoROy7TVc3mFoa+cGtKxRFPN8MOeChUhshf/Z1MDMmzxqjhVGwTV5JYWo4ZllVotZlVtff ArM/J6aAqrFnKSBupRR1obJc1+Kmm/xbLCcHs0me1UYiDAFkU1UhyAh0pswt6GlrQBtdaDZ5 9e2rY7rjvO/csCqNfeHg/RrwowFQNsr/38Y7d5HAZd93K3+pB3bJdVbjVX4Wx6e2hA2wCdQX Pf+W2kJ6AT+S40Nb2Tp58wNua3Q+TqIrzFd2hb1TW5Mnh8dHsA+VzwCpymwh46YB3EKygIvo hgNIEnC6+7SAl70FaNISyi4+IJw6QQ84043plpcRbKGe3xGmebIdq3h5Zk7erXXT+mW0k53b CfrdLuf0JJY9PS1HGE6mm7rg1AjIuKo1gvs8meOh3YbuyEOq+Og4vKCrATbxpL1l8Rref0ll maBc2Q0KrCN8+iRgoabgnd4mb5XSz9Pc1Y5dbj+1S7x0z0fuL4wo3qa43uDoUtv1gFshZbQe HaWjA/NJMeIQIdahS4wl/aL73hFBYhp8DGGyyp2G8Y0Q5VpnutJWTFVucPv1cs48LNyea7fR AreVTPSnjrFBeWUB4RQcPx7FAeUSotTzWz7movMF1H9wR6bxfPJPaROUYHnFy3efo9W6JT38 PCoVuHLZNJsKGwAlPaCA002hokhsn6CCT1L/IWeksrqIY/gkl03xFCYHZYWD5Lt9ja7caZ3Q UhGc7Lv4vkQ1/Sf+e+4U1yQofof4ckYvaQx5IZTogXPRXOwunxBncExzH1nGHYUSEjMEzNVi mDubay7NNgW2rpP3tsgAzD3NFIsWNZ739+Pn3RjUO4NScUTcqde3wUnYI9iNGcyGiv6/KTDN XCA8eMuVB4qvFgYUA4gj4CHiWAUYewAPhMTFV5CSRD/bGMVXYBR+SRXYtCS6i2NBvgYezCMq ZCSiY4S/K343vKPTd38DRYZcED/T3RBFS8F3RPrGcriiMYHKff7WuLTgIhEnNH9HcVrrvA91 lVVfU5y/jNHaOEf/AFr1FvBZCrMh/g74YaYG8MOLozrh3wGU+CVHHcnNNwo+gDS49ylkefkU XLKvg47SoxIvXa5aVj2loecEiWcu/q/SKTR6HNtj+ojEjJkqKNQvh9lAXu//ynTqxBn/eiOr GhCgtnQ5IavF1qwWWQUO+zuyiso6yCq3I6t24IU4bethFpFbetbCfsWK3FKaWH4EBhnSIcF0 xfn4unT8MtjQeqBR11JnupQPhdBsC6HC2P21wGBKiC+k/U1+xYv9hoVJreDZ6Dpl1kgyO0lm 98wzVT2I+9KrNOwJPvkxka54fO6HHm3czz5pgxe0+k0X5KsA3bYX7ELuraRQ1sWaTdWcC4IZ vH1PkCWhvQoKaf1kRB8XLEYsOpE0kuu6+IOc06WLH5RWGcSQtdhOD2I4lnA+MUqhP3bsFPms /quX90XLT35BWo/5yG1OTLbwu+PHjkOBo5Aug3DFfQQOa6+YGzsflJFZpRDEauxFkjuMyyBs K0Ju3NwE0I4F3FVi+RjQal+JzQhc28c3Wxs2dBazv8MFygzPIy8GHu12rI1ZWZlHcCozratx GVMMWnAJRcL6wXUbKUpvLQKYAP7ksrgY9HSrgQA5WThz6D/DH1u5jVgQFeaFGIrU602iM9WD WiHzYNhVZppHEyC9w4dwb6MApTcowEmfYXXbj69FlBY7MckFTZ5q6vqUbyAJtGoxAazWcRbW LTvW4AkPqe9CXLW8GwGzFGQpFm2wMCqQT3B0g15TE2QARtyfgY9Gb+MbL8Ttmo974QvM47kO wEUNdoXOHBJY5YIP4Z13Sw++E2wGLWjYgd07i/MYLjLPiqagQgrW3DBeHO3nAS/J9dIJkV8g d+5jPH9oLfIYb5TMUTy7uOnNKKaCCgu5qvf++9pdonJtKK1qW5mdHRp7z3FfthgxiU0IluXW bOuQ7ZYfEPDUMsXqRGe1apaIJXN+rEZ2mRW9X0EKlUwG2sfultsu0RKWsFJ5UOyvVXIVKsON 9QVmWBiKWg2EgcRz7ZtYH4v5oH2io9OFGbRUY94JQjkktlGEIOhwHfv2KOTSgZoA6VERRUj7 SV4z8SfrKiPNviMPwIEPkh3+ATZhaJm0OIMMOxSXNGzbY9bilddLbjO4Dmi9TfeC9/bY862h TuZprAw8lG/Zh5/wdeGcAqgTsT65wxckDYfuwG/wwJxYqQvPHCFadNBI09yhxrKGYexp3rLz JIGcSIACOaNLDNqqwosa2ts4jg+IWqRpqBAMpYXHZ4xHFxCf5eD0AlsErqdzIwcuxDfkD0V8 BDD66lajL2tO59B5Wc4DieU8tCuWBw4cEwgu6dkDBIytV+Sfmd4KUzO93UYHtnQTxYa1dblB a51g2oo5wu1hD8EQHoVx1LrtKh0x74f61vFCeDafFJL7NZ9lTM4juzkm7Q7SSCPm4zTSkPeD 4EA24/oJ2jmUB7VhmjHgMTX2y1CcnRiecwCtUXTg1H54G0R71BxsylE3xm3MsrSH2thDMu6v ycH4GlZkCjAwmChDv2L6LewkCGFDckXLcsCI0XDFgABvQlbjIl5FWuK1UlK1u86lvw/dR3TE gax4AO6Q806w6N3jAbtllCIdZ7guPTb7d/4jjC195ta0uq9Ty8zmoWyHTHg1Mgk2BwMRWoSV KMsOt0Vy1XPts6JbkQqtg5t2QUFgKoslxyRhgYEzsJ+22sHENje7vKAyWaX0D/OC2Mvt8oID 9AzNYDglZNKpnc5MWfIieN1AxH5DzHoeLhWavQWld72r6xjF2esD9wiS2BcSxFXI1aagMbN8 ouUGoWz3vh4VXeRXyLJ6EnPURm8DlYneu8NRvu0ylHFv/4tN+w+kV5Q/KuUUiUfsP149TrnX LXbyTFNz5KBBZyMCohF8nh/GfMHKFUVqEQT4PtAQLb+Vk9qxjo1UBG5TN2pb1slHOLLxisaw 3sV1vriClKMDIs7b6Hg5oA9rxyPqnY3LBNsGTLOwaX52cigme6fiyZO9k8PjIyGVePr04Ahe ThVsq0wUgR0ztJ+xyRKOqssMj6TGp8l0U8eHGS4gcYyv63NnPwswSKRray/JMfbHvhDNOs5Y rT1+bNC2WqdQK5CtQ1RkSla7dvO8J+CLSc8c+J/Fw03inkCMCu7Kg4Fns9Xi2uHjYaGv0Cxj fXEd4AVD9fkySIHT6oR/Xvh6CSBrxSlafeqcmFKxJRj5f+F6LUMZODkOJF1wuhyhF5AvTxEv YLJtH99s4fTSlccUx8cg28nQhbXjFBHKR9SXlsNWDHrEDSmtku7zyK3wnFgkymCZ5/9jvdp2 28aS4Pt8BR8tIJHFm0gBgwE8loIYsBMjyj4s9omKOFYWCaldQ5nZv9/Tl+pzEa0E2QUMSyLP tbu6ukqmIWSxtKhEWjRwTDBR/GMyiImJ4snmpNy0lq1s5WaYEElkxNK0iIlOfvrI28nCYR5L OULr88jDOZkY/6BHuNfY/n2WE2QQ9NMApvJdKDG7odJqfHhd801IVUzVkHEeqBy96lkplAOM 2w3DogItRkPQhJA3TJF8x7J3SqWiznystXNM1BzA0psdCFPYUAoLy6AZxKQPlN4syGpfTQsn 5sLZJkNjaJtYkL9Ec6FvAgV0+34eBtR9BiJKIoU4DnbsQGVTJjWBeliUH0wtWjHSGzZKDTsj ydkxja9ZKEaAWp0dYoFQyRIWKL5OlH+ns4y5U3cxKmWfY84v+ik4nE6PjRRuaHhQWLveJ3p7 VRdgvZSaPT7oOCE80u7suHKZX2zOlbXa0p27br7fnOvLzZlaWKID2xJnKPmVl+hpk6Zv9eqF Lq0Z1uSNwMxTplLYCiIDm2pi/nXqI252ETwlhbqf7PeexT1q/S53ulyUhgwU8Kf8HkxbfiZA ykmHEUz0ZPbRH+5VIh3cVioa3s9eN+7NA29RGc+i6mKeloaBqYdO7qL7eXGXxcjjepSOOZ6U p+1EAkDf748mkfXSR72sDDSu6uMFhowxH8vnk9Qq4q/v9KecHRpqSFURCpc+D0GGdNgm6mJb jouGLpMeC6TwuYAeHOX8TlfZScHYB1mKApz9U2J32j9JrGsjQTc9Ruz4A/aEW5T5SJ8q2DfF VARR6wA/Cx8IRQcFk0l0/r0apeeYAPvBVKM2BLnXqDFBc3HW1JoVZYku9Y+rRMzKTkjMt1nl uwSKB9qtC2rXWGKiYsH+ejgBAm5948XN6motGucmrOy1KqlsjNNBnCUJWRh5rt19YvWrKXgr H7qNJkDfqYpLQiinfPQisMR4na3S6060062e8ia6nA5lABTYPTtZV/7slW0REg8iZi0/kUcA +6FD2GmGMweYORgXP4clLxupUfW6RzNcXO2vtTIs1AK4HWrpc0gWGVJtxSDMxDNH2sW0O29R LllqVLGYlO4jfSzOpFuqZGQSJr7MloLLlXv0bdYwWRUuN8Os0Ga/oCBuZ7WSTsXoohy9Iwzl nB16+WENhhp5ad0nw6QNj7p9++5uRpNub+h2jUMIDcbULa/8KK82/ONWxr+hNFPueXKwc2XH onctwaJy13iXqgcX6aa5LB+WJgaKZr50auK78qH5H+RD9R35YC5wQj2otwiMhpAP/UyoR/VC aBho1Au+qYevkeI8oSWCnXpnT3iClu34Vfk3Fp7eC2mz01ndwMVQajVwufELNYla/jGNvQrP rSIm0rda8N7Svl6Z+I4cqpUUP+1kaz7mhJMpAstlK23jInNfGrZurgqXC9O4aaH4CmHLivrI 64h3FxXqdsmq8bUu6lEoK6+omm4J5kzBlVBwJSRaCgUza97zMbh8KakNFRZ/YraOf0NMWgWz 8+bqBjvp0/eUoAIbkTAsxG62zHXY6RMzBvkDwmcno571IX9eCcKYPim7f3AcSLxgxxvdZK3X 0EO7zuVSao+313KwH40Iz9WQlD8Wkvps+lRQcuy1fUVPXRA2GLa9w+V8ko0k8kShdtJHjNu1 PkxTP0GYmNJCcz10gbDoRY9CRuh01uvQH/tsPBkZSGPWsgIPdypqUdVHqDiRfcFEV9H4qqSk 1WiiXC/0n1nBZWTddxis45oYyvQc4X0C9vKWFMHo4k0dz+i3QctWggrFt4/Xf8oQOTvAhIGY MqjSwnskiaN1eBWGpjRBz+cBwZ7r2XGn6looKOY0yagna9HaejfED9peDYmubHZvBn8h3qn3 igh0OGn+RNX3f3lefA7Ol3n+FsWLUPRqaWWKOE/CQJEbBHCAkVc3Z+qXd5jGaeWVxNdjR69E JO9TVlvGdtoKA3FLP6G3/PQCMi93J9/1Meh7r6haU1QtbdLOm1WtXXuztbZdaWnX2rbLskFH AN1s3imVJExCxFRoN+QgcHyEPnG+Dj/pLkcjYOdCKpCpPh0D3uWqJ8rbx6u9SLcf6LNlh9BA LMRsz89+hncL66L/f/LVpc6ZNi8r7qbUgsoy6qZEXlE9ErseR1Mvvg536uAMu6g9YOp5VnF9 uhUFRcM+rHyICXiGQarLF7bwVID2fpAPGXimYMRCKBEcsimO4iFzLVdIqoOcQ1YNGk+uHjXb mU9SlzLFTpleajyjM/Sk86IU6zilKI17CRs/IyydlsMiez1A4LmWtraI2kmRGTKEK/3eaFhI NDoi+COKGxeu8E3tLhU5xKHbzUKv2CfeZEL6c9ycDcmrGhwiVHzsBTsKDJXrIwAiJ/TocNiI AxTJ6O/32Q6AT/D7yvZDvdUiWvXMYZlBXHSf0LwMx/tOYY7ToWmWdhTXqLI98oHQf9bQCzT3 mB2JJtIYTz0K1JSLxs1LlkBJzfhjZyim03gQcTMjFggFlDYqCU9SDbqeFounmMRc6ehj3yG6 OvGWWdOKwbMNirhKa0E0GUQNm62wCwbmJapKLok6LYmjiUdv2KqwfZ9pGYivbypQQsUwIdw8 zkaTnhb8VL+cBqQZugWYUJExpFU1p6oqnNcoc23WXGebh9vsl+vH7Ndfrx9u79ZZ3ma//fb7 2j2k4C4bBi9hOJnxtvBTVphy/fHjInPh/EPKN4/Ufe7M28Jt7T6bxXxVZIXDT73MPn51kV+6 mF/tXMRKl8T45EV43HjdUqRFbazwtxlDuqYSqrmjFJQikneU1JzVXUmttnKNwf28/zxrqAh1 hmMTwpMb4kK9duSwkuc84gs97+jbv2etfKGlebhL2RvCBCHu66zlykqu4ZhmdSnyxSIIYx6E sYDeKvi+q/lqKZHkbxLLfLW0WD5IRT0oQH4naQC61264lWfoeREffyF3lJ2eIyYaB4M1fbny vdpgL8rXZsh+KKItV9YdeNI6NB8DNuI+Ars2/udAFPvWs5YpKI/I38DtdbF7sCuE+qEO+pxw IUyUXcz470ZOezzijoM6qL/QfIzzxujXwdo1M2YmNBOGpoSvknln4cnrlK8WVpdrF/VHXnHU FmDxc4EjV2A2LDifuQfjcX9hmQ+xMOn4ZuJyvbspZD9aaDC1GDqwJ9e3MESmoT9FXZXYT7Xa Wf20y+ZiAeWeumQwHbxuLlBXUZxT1xlP5cvFvCyotq4aWoVZ6zInuRitwEnMOAMxERMEww3s kXO2hD/cX0JOu1nOCawJMu7hxy39v0sC46LbXiaW8hKx6JeXeKV0FVIIrzQqn/P0APNy1Z4F JGEtp8uqJUJyw3AdFIKA6PEUCsP8KhDn1lRN3LjmrqQS9+l3AtC1igXZ6YN/SF3BZLBbA7Ol JlVvv5UPXUsL4JZny4L3oabJQadSIhv5cRtNVpk9sRQOoK/ek90rsLWub9aEy1tYLtPyMurj d6e9EbBSJogaigXqqYuUCETfkB1h5iKRWSbVfGYFQE6FkRMrXiInz4kY1AIb9I2wkS8AoM3W EFQBnpWirGwAIBjcDRveloO4kiDSuW7uKXyhHvdYZ/Z0sKvboECZfh5DrJihoHVU1h6M6MRn Kgmi3/TZTr+NJ534dIAy1rGRVSyZbTNEWIfqRz/Ej8M8lWZWMu91LnWVi+KVUhN5JLjR084a ipME/DJBTaoyS6cvkcm5cGXxHXKqjLQrx4b5MjBLL8yobcY5ibGMB1EVP05UriutqjOeCkO6 DDQMhdTXpFWkV/gsQ3b8LmQxS/XxCKRoHvFb4ooom/Sw4SKK9nABQJ6gNRYfMV0AOArl0H7K 7GQJLfcJ9hDZkOAgsyaecWmunN3UHQMFQs+jiViuD51jHjhH97actGoKaDn7sf8UeKvMisyX f8wlzti0zTnhxByREA7lnqm9FXJuU+aW/nOfndGJo3oJ7p+zlXuOXhao3EOGh903zkiGTtj3 3gvqlVNyKWJyyaesaBdwC52tH0LNVUAbez7JXxLwiShrg0j+YMEvrXzLZt5W5bTB3Hz85b8C DACB+FVlDQplbmRzdHJlYW0NZW5kb2JqDTMgMCBvYmoNPDwvQ29udGVudHMgNCAwIFIvQ3Jv cEJveFswLjAgMC4wIDU5NS4zMiA4NDIuMDRdL01lZGlhQm94WzAuMCAwLjAgNTk1LjMyIDg0 Mi4wNF0vUGFyZW50IDIwODQgMCBSL1Jlc291cmNlczw8L0NvbG9yU3BhY2U8PC9DUzAgMjEw MiAwIFI+Pi9Gb250PDwvQzJfMCA1MyAwIFIvVFQwIDIxMDQgMCBSL1RUMSAyMTA2IDAgUj4+ Pj4vUm90YXRlIDAvU3RydWN0UGFyZW50cyA3MS9UYWJzL1MvVHlwZS9QYWdlPj4NZW5kb2Jq DTQgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA1MzAxPj5zdHJlYW0NCkiJ tFfbctvIEX3nV8xbgJQIYmYwuDguV1kXx9qys1qLla2UspWCREpkYgOyLpb19+mZ7h4MQIK0 dpMXUQDm2n3O6dOH88ns7d3D+rq+ehCvX8/ePjzUV6vlQlzM5u2t+G12eNh+FxdKySTNRFHK JDdG6KJIZF5WokyLJDWVhoHnj5cPz7dLMXu/rBfLOzGbu6ez+mbd1A/rthFv3hweH4nJ7Og8 FVf3IhXi/qqZzObzVEgxv55M0yRNlZhfCfrnSVRJlYtpCmPdf6ookyIXRZUnFXz/MrmIzmKV ZFF9E08N/C5F/Nv8p4lK8sLApPliEukinv97krpl7ZIykYo+Cfulv6u0Q6ZVYioxhZGmsAMv ok/xVCVV9Ii7fI7hm4qW96LFF9fxNIcfAe8VfMAz3cUyMZEbYaIr+rRc4IxHfI1jlgd2Qenn G/hHZfDP21jZjW558FSm8LvG7T/TJJXSNFm4ywdXNYmuyvCyJx9tAkYSftg+PLRfupzDonkm tIHMa6FLOHYGKc/KRFVVEWb8Xds+7Mz4fC63pRiDLfNEZVJMC9gIUuPifeIiOIeLFUkenbun U7rvMeZiHWt4urOR19ES4lvC4wOMsa/x4zd4CVmyf8XfYQ0YR+Pvcfja/lQRnFS7GOqoOHAr qEi8dZve3mFqaeRnt65QFPF0M+TAh0JthPzkx2hmTJpURgujYJu0kMKUcMy8KESp86QsX0Kz rxOTAWrsWTKIWy5Fmakk1aW4W05+Fc3kcD5Jk9JIpCGQbKoKJBmRzuSpJT1tDWyjC80nv7x8 dUx3mPfRDYvc2BeO3p+APxoIZaP8+zYe3UWClv2xW/lL7dgl1UmJV3klTs8shA2oCeCL/v85 tkD6AA/R6ZFFto7+8X+4rdHpMIkOmL/YFWbvlQXlx6PTY9ioIy3pMpDSSTD8FqkV3sKuiYuV TlwTk49LqhNyYGyFQy6iv7X2ts2QOUmV0SJTXFRreq7x2a8JqkxLfYtlCZ+nKlp/dj+XsYZ/ 16ADJnqOFRC/hTfXsYnEB/vJSqgVY1Bi+6eBd/RUgij4E8lg90A4z3yY5D5t21a+KHqgqBlh okxQ1ORGMAbCvWVxCXqc+5iiKLbDqGIsw9mZlJgQmfuM1KR+3+IMDsNPKKJW8pR/d9kTQhwB wVYGxjzHIOVYxWRSRu01S+lnnIOjr5woN/hDOooS3WmtndXedUXVLveAkWoHz6slnUzc0mKP l7BfRatQXaj7hQHCRJO6Q9a88HlQe4wtwTCOwutKTwnvwCEUbAqoHvlr87k5ZIKXwqJ2hMPf 4w8tTLUNvskMHmmDD7yCS6pLYsYQyJyGYhatHUgNpvL8jM5xAotluLS98rt4WmARtbe1G+V2 I3u2CkqsfQ9aBNsqOFMfQ1CCmbzbyaCYDNaf6EIHB9o+QfsJm7CGV8M7eZaMsAWyrqpxtkhk S1Fqxjtm4jubAE0QJAMBP4xPdmQhTJyrQBzV9PkS6eChWBPieTWCREPDa3pPXALWwU6MULYy q6al5ZCB/HRDv89DyYDUmZ2alfmog71QudmbJsMTUj/0eEuEUVAy594owL8CnDRcbRU7LLLt Wo5y3Ppaz3BPbXH72EXYa8g4q5nO0tHZrnnu6LuFzCXzdoTMdnJLx8YnEog8ehGfcQs78APP xzOd4b69RWjaO/T7G6IQXoU+/mxpLXlbUTejWqEr8AmGE0SqcPaJhCCYxryBAmTpSPNCPjIU n2IrF82yl0UCdcOZgCAauOcX19JkJPVu5Ekss0BpMSzs8mFEjohQ0YoJwzvojqkYVH4ZrN60 vUkMvCWXiZoxuejQ5zCJj0g6X7JU6lTh3quC3dNGO+1yceYu8AnRxclGwDZ4Hz6DW+bWMT3q nbLTGTe+xp/dIJaGADYGYVm65Di5gO7EoSFk9EUP0bqH6HIc0ZrqEx/2HAGNUTjBhy24zkJc 89G3oVp5VMPyBaWi8bF3wXN/WEUWdUPCsPQHw8EI1A439neFy+Ip+ibnkdNsB+S+6ISXrS+5 MnyjLQ+GwNUoYW6Rv7oyCzazYSnkvaijdKMwqm5zPAGThtXvOc4CpmqzmUk3b1XjfWhtBro3 eVS/lH9l4wMDmQJwap7zlU0VBo9f48EM3IfhG9AdxYBF3HN3n6+qOhg7vWMc+xXHUTqqu2ij hINm6aCZ7Yem6knuPnDWzULc+3rEuZElqah0KprBfypj8V27oFY2WSqD5mSa2U2fNzVYpbnT YJoeanBPBBEtmG5fATcSQAUMDQfJtMcxORjRx2XPwOiIbXPNSEEYMQV4y87CMEm2WRhsGCI+ VCjgtcNo3es16KR8Mk9xVswN4C1fgjj1hwEXAGaXb9c2ofM//16nbvi98+qu8Nup4gl/V/ZU Ni0SXRI0u+6Vjl4N7WKalHKnq887V58lpZZ77WLBE2ZH6l+pAFd4PUFX2M18ncoqewOTZ/O5 xCGgl6na497hUpns6NMhJajyfaPYutLwH67cC8Hw4S6VvcXAk4tTwlOvmv+lvwlwfhhOneQy 2xXOckt0bGozU/6P4+Mi0/UYPljXAWklmRBx0vMWyBgC9Z8s0qgUCbYuX7tK4HyFr1G+FNwP QwM8KXK6QGIvAMJWFLtiVYXQy5TaCz2Z7uooTZKXxXhHGamX9ZNqo58kMWibwULRdDRftsel 2cvvXUd5H1hCrs7ci/aaGwRiT8kJ+fs0nL+ON6EKFZz1W6N+yy36vdGCyszsSiy0ir4HNYlW +3tQUA+aAaK5JRvmh3vPAyR85ybJlhcciRVdb4m6DZPKnBdtb+kj2VCKADeeXvDtcl2eRlYn R1i4lmLMENraoH/EEqoSDnIQ9A0F9D74S77kkU7LZdl+LHe6ADc7PJHaaQUGMOo55dATBIjq bdjeuFtpdgR2d8sKlW6hBV3K+23sa3KF7SpmLeT6E5GTFMyVBCjyzcAo9BusbNSamt0+Ifsx Y+psgghapl2+1GydvsOWgl4HjYCkDArujmqEEqWCA2mNrOsZuTIuKSm+dUTlc+aFYtDvCsJ+ FoLTFwedmJSrwJgsponWBVNuH0M6mu2oYTYOzgHYUEwrjgQr2SVGghLZA69HB3PbG80wprzQ UxcP5blxI1g16AZoSpaLR66mr3og7gpQts9NSO2FVMN1i/06mu2okEOXFtX/jF2h9icCwah6 JsS2Nvara3YkVsTKeBE+jcFgVs5yYDDdI0sy/ggadBbbKm/JBVFun2JlpzQ06C6G6h0JcLTG cT+z1e/jCU75eIi/7lHjCgfDohQUh5HQmNBuDCKxfUbeC6bhYBriR7TejJ8x2Zil0NKQ7Si9 KejEyanocZ+DKinkwA+HJOyq/gYNVedbNmlIB3kRDV2hyvpFLycpDCmpPSXdgA194nLJ1CAe fn3kuhnWgF5pWQ0cDX78SC9RHPApiw5Jajs1D4o00Ll/BkdXpnhz39m0BZ2OY4Jbrn2htL+s PAP5BD3vN1MX0W1LNa2/AD61TeIj208lYFXtFgnfkcEhy/wHRKLch+stwO7wNN6dpHknDC5H LKZeZn3/xZnCHIV501gic2zKoACv2EWQ+rJUOx3nzCwYP1dB+qj58W6EN+fQtyJcmafxWRfc /DDwnuLK3mVtK0zgUqhrgr2ZHI/Ym1EVYo7iZkwDTDvXajpHQwhZ+oB5O3lKawcNa9W5I1yZ 3BlfD5FkM6WNL+kBI1VAbhUNK2EjqMzxrdgIsTcNnNVxWBd7tPKhHioU7GHbta0S1R15j0aF 52892HapUidg69DvUtzFgm8fwCgQBLCTDAawUbcMkPZbCDo8Ts1JQdTQiTuEhWab+wyvIcpd 3g6y3A9FBLvIW0yfP0s9FBNesAtKD9sBbDsNrikILUpg54SYY32YK4I5tUo3Q1ZxR4Hf0RJ5 fA/t16DNILSrEO1l5Fu7nhz0SRuHHZtv2Pjr4MZLgVg2cGcegne3cYPWNUgJapyj0I5Q/pfz Ktlx2wii93wFb5YAhxF38jgYTxADsRPEAXLwiQqJkROHlBfZyN+nuqte9UJSGudkU0P2UvXq LXxNfuEsu+BO84INR1xl02fLPivjc7BU/21GOzNIxPiA18ACz8hWpW3EaB8QKgNdTtf9bGsc 6jWh6lR38jytSIZuKVV+uK5U1It31pl01otFJVrXK/O/RqxsWxYoD+giZLNsyWZrdqtKy3Ij 9bjttrmMVcZ3Wu3uybmn9WAfpB/M42nUOeAcNMHXJNHUjIkU85Wk1FiX2U9FVpPcz6GVyz/b vnzWaa0ZY7KXMhqdvF8wmYqRssvj6C6G2mFKyQoZ3szr9NCGvHmNLHR637N+jpbO++kzOsBH lK8wPD4gIB/oGYLgPzEBacyEiApRXSAFn2IQt+mhbLecF9/34ND3dheyTME0E84+rVmoO5Eu 3Nne2saAo3HEo5Tl331W+97JtQGY3UJqsSRS27cu7NE992i+xDKB+GCPARvii1TmREorHYxv wh4fC4tRCv19qfIjYg9TlsY9qSx5XWG6PHNZk4pdZ7eZLg+YTnmcw0Rumcpb47g06G2X3zDo 1Ocqv+XQ2Wn6RjMrjQvHJLKdAaOo//asklqkWN0De0j2CaQlawBPBmf0lXrbqPilo9GNUhau +PzyzeKXtwLRstxVVW6Wu2g4D+Vth3KveuVQ67e9MhmRbFvri+YJTtmzZIEV0ZElCYusMrSl l8Hjb4PIATicIjgsIxqNYH8Ww0x266x+2C6NwRuxOhj5gyx0CfyHTv0liDFy4AuAdZ49ZLmp B3YfAdOImSrbW5+YhlFW6D0kZ6Kzq9xfWu7nmNRjQwE2TN8r+ZlbgCcntd7w7RElLHROGiVP 8OzCb9jzzBXxj0szCzodHHWr3CbSZKmR2HX+J9akvPEU36KfipdB7zPR+7xROPZ7Kw8f91Va k8mY+HH+vDculgr0hQvTo6xEsBk+OsrjaCiGfIBm2ojcvqdTFW0d9I01Wnw0wDD0cq2VHKFm /YQKiyb59UTwGZNanlMpYpb0Ryk5R8IRzaei/6DekcchyiIfIojL/jQ08gJwdZb/8Hl7qPyY wKyt48n6OQlSPOeelMuFLHowENZeB2qqKRaVe5yhCoOjFMyBn/tYF+Cek/CVaXCKYV+cudoX 3wp6cuzWkRot4hRKNB8DA6GOBvkl1pYNdahcbIl1eP2D+pacrOhJ0xabepIVrCcHdXl/UFgr DBXwkCjvquT6ejygdNKHaQ5ApuWBHjt+wIdJD3KdhScuIafOk28HXwhvbebZtQxFkbBoik2V 4xqsq1xs41ySMj+HSaoM/OkttXMc0bkRdCGCBw83CsaHjpxXTEx52mRZQEyh2TJVU7eVK9+7 9LPhuf60GzXOHJD7n6TKeGmCFA8JBlStcj9hI5fBrBpPyirx6IEBaWYjqf9wwfECGru894qF VMdzWDnZ9xKG5y0i+9ivotanGSF2eZ/OYbLpQt+5YH47jmPyCOzIxxOOpprpxEQ5fICjeNSw NSekGFmFsNKrVKTyQqZkd0R7rUsCJ8V2t7PHvGZ3G0dPuQ2LN/mpvc5Pb4mg9hwLDVFFB9pk qYozhmHIWyy1J77j9nJ8NI9e7CjdIJi/uDGwP07qKO1fsSjgLRWHMdobixFtdd2Cr5ETuVaX r5bkxDHtqeQULl2kVS28vnu2XlRCcadFZQ7H1elgxibH5sH8VaE88POAAbU35csPo7ccCGYO lnHs5rllA7WubYMp+upXNZhdGp9ovJjREouyMrRe4f2sRQpbC4beOJ75Uc2sxw2OFdoAgYaG g499Si59Ss5MbQLsoaTz9TLyLfsJjPSVbZgSeXAYdAk7vgd91RZkeZsWhwxgQDABv/pL1ivO NteOiPfiF7E3ZmGMpaxrWcp4c7/r8FQzGPOkpSCCR+fApiYCNPJHz7aZx2AORz7e2UNi5Qn5 8vt6ZajLW0PdpHW97Tj4zt/iOJ4R39H1POqp9STrSfa5f7+oIL6LyldulK/ciNg2q/8XTQE5 vbSeRqjbubRVNhYABd26KgIA2OucbAVyDF6ihKvO4VMwhUOygPtLaW7ohGLud4Vf3DyrmnUa dedfIVK1PjbgYX14DbW32ij6u3QE2LYZz9bM+BdtaUBMlJVQCu2yH6aEEGU7DaGRxwp9urEN PQqKQeHryBPQ6U9B7IpyChWms3SVouyCzmLckKZYxTHwiYMrfhJOQTZQDdZsqDZJgcG3X6JQ 4Mcu5G6vzM0wwobHyDhGNQ9BloNTu92DXXAZBHbGvRmcYYXL9Mm3lAB5wXRiy8IwWphrvamO UGS03tpVK3r3HX2TZ1ZU9N1wZK0pY+s5SVEZg4M3tj4OIt+eRtNS2ym+Zio7tYhNWmY3LWVx CCxleHo6b1XmAbRasbuZ/FvEYTDN6Qg3nGbT6iyzVgf5bPbmyxQX2ICuytSWfuowvw++P/rE /xUSCGzC0Rv6wCwVnsqK0bD4zh39+TB3VuapMH+OadrwDebXexGPX3iyXr0Sew3M41+ehAdb Pv6S+Xy+7P2UNYRWLayEA6ZlFi/yGUpdAtMF2wnLLp2Ku5GakKzQWfCkko+5nOgSiQJxkn/k 7kJNcUg4ae56jzYmF5k2pauYUQJxTv4yrHUZQPnIuSO8UdIzW7i0KK/K/U9jvL7aTX5W+znN ekbHqXhLSOwXRt3Tes9th3W9COKG5AzfIpC1710cfUtv2lp7M4xfpGiyyHwGkF0hrDdyuuBc aO5rg7FBgi62hejTNAoiq925l5rE+WHVMKJQcmwys0wprcVW1qV114FU3uwrwZRp4h09lbvX L+7Mbs3utxeyh12K9i9KfPfR2EAQD5ngvTH7/DYWe7CL3f/0+uXe6NG9Cp3Z8WdCkV7/DW/3 q/3ggR/u+asfTZsNzO0Sd8Fp+UdCQEkXfh2bJXqT3O0WvZqiEGuXdPjQ6h17jMPAUCMETz7+ NPpM0Y5rZtTu0lLptXDgCnI2HnPwTAqW+mMgxZrcYDksTE4TlO+9p4PF7lF+tT4NN+gnpLhk m/rw6KgLO/ytfsp2EIjTQe0DNgTxTz2qxrf7wqlUyjvLZS9KmiJA9oCxmOdNWmRLNX/4/bv/ BBgAz1Prhw0KZW5kc3RyZWFtDWVuZG9iag01IDAgb2JqDTw8L0NvbnRlbnRzIDYgMCBSL0Ny b3BCb3hbMC4wIDAuMCA1OTUuMzIgODQyLjA0XS9NZWRpYUJveFswLjAgMC4wIDU5NS4zMiA4 NDIuMDRdL1BhcmVudCAyMDg0IDAgUi9SZXNvdXJjZXM8PC9Db2xvclNwYWNlPDwvQ1MwIDIx MDIgMCBSPj4vRm9udDw8L1RUMCAyMTA0IDAgUi9UVDEgMjEwNiAwIFI+Pj4+L1JvdGF0ZSAw L1N0cnVjdFBhcmVudHMgNzIvVGFicy9TL1R5cGUvUGFnZT4+DWVuZG9iag02IDAgb2JqDTw8 L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNjM4Mz4+c3RyZWFtDQpIicRXW3PcthV+31+B t3A7XooECF4ymcxIstwoU9mKtVNPR80DpaXlbWVSkXbt+N/34FxAgNqV7LSdvGhFEpeDc853 wdFydnB4v1m/b6836ocfDg43m/b6Q7dSlwfL4U79enB0NPyuLrXO06xQVZ2npbXKVFWal3Wj 6qxKM9sYGHixvdp8uevUwU9du+ru1cESn87bm3XfbtZDr3788ejlsZodHF9k6vpBZUo9XPez g+UyU7lavp8tsjTLtFpeK/7ns2rSplSLDMbif7qq06pUVVOmDXz/OLtMzuc6LZL2Zr6w8Nup +a/Ln2c6LSsLk5arWWLq+fJfswyXdUvmaa75k3Jf4l1zN2TRpLZRCxhpKzfwMnk7X+i0Sba0 y+0cvumke1ADvXg/X5Two+C9hg8U0/08T22CI2xyzZ+6Fc3Y0msa071wC+Z+voV/dAH/HM61 2+hOBi/yDH7XtP0tT9IZT8srPHxwVJuapg4Pe3LmCrCn4EfDZjN8HGsOi5aFMhYqb5SpIewC Sl7UqW6aKqz4q2HYPFnx5TLfVWJKdl6musjVooKNoDSY7xPM4BIOVqVlcoFPp3zel1SL9dzA 073LvEk6yG8NjxsY417Tx0/wEqrk/qq/wxowjsc/0PC1+2kSiNRgDk1SvcAVdKIOcdO7eyot j7zFdZXmjGePUw54qPSjlJ98HcyszdLGGmU1bJNVubI1hFlWlapNmdb1t8Dst5ktoGtcLAXk rcxVXeg0M7W672bvVD87Ws6ytLY5wRBAttAVgYxBZ8vMgZ63BrTxgZazX759dSp3WPe9G1al dS8Q3m8BPwYA5bL8xzbeu0sOXPbfncof6oldMpPWdJTv1em5a2ELbAL9xf+/mbtG+hs8JKfH rrNN8o//w2mtyaZFxMb8xa1wcO568uz49CXsw+3zPBlXmSPhqgQu4hPWKUFUT0ExpaEdi+fA LiWNuUxeE8SHfrJQsvCzLc22QNTwQUNuGpndQhTAfAD/nP/XyfpW/ruChnIvHIST2zUwhgZG S77Mc4MEDME60jbwA7QO5OR4OQMWul07Es+TjhboaQy804beIa3kbriLOjyjtSWeETou0z7M 90w1G8qacBPtxi8/dO6xchKA/LS9uiUmIoZztJe0G16I3kHWaCzNHN4zJ9K6Lb29QDokgrUJ cR1nnfmV3r3173IrC96PaueSxSvKWkTdxzTvJ/rhlZnBj2UD0NkKW5+i9VkrpDMKEgiTVsCF TvRc2V3uLs5x8zo5gcUKWtqd8dV8UZFUuHwcY/1gJxdbA4d37wFxsK+GmOLeAqFpmsdaOUIj 99BwKlzoIKDdE7RMyPzQl7sAoC21cA0yy73xDgI1EPmHOZ5SWoOMApCHqzS0oJL3rGd3qIPS O2qQDlMtZdej7TK5216xiJGmscChWDphelwNXWEPF2nVWInzgjILHfSa6vBSUv7WP7sfZ5Tc XvduF6i1TDsZtxF10AUF6IpHHZQbaiH3eMqvDyHoAnoHWI1tk4GehsUrEAv36WTuAMmjT19h WJan1zid2h/fvnFpzGWPF+qEVpLvFzj6VF3hdh22OyQaoIAvPjoKcOYTPzzMbbqLA7JSUzdT AsNubvkAn+euMVvGFyNfiIDHtFJc4qRHZND114HrwRVa6RKa0w+bmBE+zQsfAjUWL9sK2fBM YRIOcHDN2eDxi1TYocWDX0Jv4hSG/DnSDZJJzdsO0aGFs6DTY1hqYPK63CselNQsNaaSnqRk 9BwOG0NMijDXquUkEYUVEENgKSXhFKZrmMI7v5Yxs+VwH3gZN7Jk9cs5rVdyQpffjid6eyl4 rFEZFnDMSpuoKyQOrDizrXjhkLgN0Ws9Ejfy6tuIzV1MFhOQ18jdLsSQss0uyq6pfpq+1bzd yNgZBoTbndNPxP5c/Fd0fRnZHxN6GCkQf3zj+DsXvaCgiZLa28iB4xdhsI4epc2F9Tout7xf 0TDp/mEUWjf6Qxdg1ooCITWbAhpN2uulOw30yr07MCo/mg3yBhtHd7n4h2kvm9Tm4oMWe3xQ 1Mp/pXR0vQgAZOHRkuV+dPglwTjykk4TtA07kO04+EsnQGEHnkQlim9hkuRBXIu82HLWvYGR AYzEoceCEtZWUqN2vLkt8ELGetSrHQg2gGCMHnrZ6QUfLQA1+ME9oJZ9oNxCZwP1FDdYzEsY Tn8ja8p1cKCtVlsBVPf91PMWaamrp/yE8X7C2LRoimf9RBF587hF9aR4yfqfc7fGGJBzocUz nQJgqr2NlroLMODekesABWNyBWCh+Rh2NL+A6H/Y/E8dKacldeWXJCoRJY0ZRQ7x25a0czNp 9K10CdI3DtneMQHdSV+GTly7vlkJRSGJjyob7ExKLdvwQgMZv484Afi67XkhuKeUiTrjhQih ZzzqCBF6Mmptwyh3+uy9pffvggmORsRR3bXjaZAqvswLMTRAhTqvIpZgnH0YlM8sHYkQS/ag SO5YQVmeRRBXFIbmsujA4Oywp4HFca1B+4yGSZI0yBqi119jcTzjSCC42YR2vopjeAFWQeoY 2X3LlgHdgkG70F7xt+ETfpteelPX2qZ5jk+sp4cC2qB6lk7KJ+hk+RdgkB0UUtXmWQoZpXLK IOAWiz+LQJClv0U+3X+2YQrJ7NdQiJMMfxhUDj5LJ00+TGu7Y9MKecumpfWiPXoUbi3Fvuw8 8npq4M/cln2kvV7ZuIf5W9+txM890vS2J9sJ8PjdzbkT1PQCLD4gldFvQLPqxLPWaqRXwYED r84YNsZfmUZDArbK5X2vJXZTbl2SCdDCCdH958oj9UaMRi814UBW6DAwkviSwER14y3DoNgG h3eBCaLJ/9OWcgNw9EOx7UT2wh8ZeLIqPMb3K9rI5e/Ab5ajx+o8p3dcck+VY7WxdwxeynY0 j7+QMWjMWJemlquKk9SwLutAyNBjt/RzdkJbnB2NtwMvTS9Gns9hbMShkfPnuG6Zt82jSX3Q uHCPSkRyRr9PKcHHvcQz7v6IeiAPtcn3cg8l5hnzEpwi56vT8N63fuavYbvtNl3f5Jz0SH3P MT/QCWjhFTFpUJYQoNoBFKvUrySR3th+Cs25fG0xoeYxRIHvymbiBhpxMYWoNocowOuFb5hU osy08rX11EK2vFfj8eXkKCpAzyMgqAfFEIiSP0RXD8VdI2FgrlpG8VgTBlAcRr+NXER/I4Qs W8p0YoWWyy2NJdQgpiYkLqkNByJtO0lHgN4AS+mkYQGjVWOfcgvVePuA5m70s3ahftouAAms WSucb5jg5xmTTlfPkdOMcYaSLPCE25wIKkbFOULEO132fl4DG/SZ4nZlGe/nH7xOBBUSq+Id BToVuMxFjFE8Y1WAL8q8+MNeJeaLCHKBYblMvoNMQYaCnjde1qbXGK/povaDP3ovKeMEg+yL NhOafQ5FCSFLqLzdBNm8tNgtSaWGkFE5dGrzetflITbQHA7DdNxVct8pYXiGJzQFHlYkZXKl mNb0T77GxpX9Gi/qUwisXejYisbCwtfTOINeHvl1qJI2bH2MVftY5c7kVfcQOQf3JfRIHeQW 9WUKBDhwuRf9uqofHQo06QW3IdHjqHlUQ1uSDTFlWtvYHrZPXPOiLHXeezi19NoXXBbXuFsV Ssuqo+ETYua3Twq+5p2+In+69vamCNGhx0vA/jCqxN8LImZEs+Htnb8bTDQDSDcT0vpuWitO O5BCMxFbXN3fD0Jn3LcS8yjiOPrRRSPG58LkqSliX8Fq7M0M3Cmmmd5xFwE5jd3rZeJcOhso KoeYHFf2CRN2T/nQhWT2qouMZvtvR57QCaFL68chdJGjZ+kaSViMu7B5XLTooYPuIYEMe8h1 EGDOG8beOzjOPN5K+1WEkdDyyZ2mjX32Z9bAjmbc8LAPQvyriUE0mfG+4ErsF80NmkY4VjwU djAF8hHfFf5wHV/HxAZ1t6hQ0XnLZKrx4qlEv3CDQOkJZReR7z5E6LwmlLA+HI5eq/4P51XT 3DaORO/zK3iUq2yt+E3OLXGcSqpi79Q4VXtwLrTFyNnJkEqllOzP30Z3vwZAUpIzlzikABBo vH4f7AdKXWuMVsYSmnquZfI7+XMns7VBNUnynTarD7KVXLfyh09LBVZRy/P24qqkL+jTtV7L q+gE+uO/BVt3ngTs7KOvv8g5rHBsNjbWgW/oHlFcwSSmMOUOwHWiu9Vv3+ot3uqWPrrdF0Gd 3ApyTG+RTdv1yukyXeT0N+21zdJPAoc/4bQFx5nmKkzm0B58W5rLXvSaZreTKPCy6R08ivlZ +mdEyNiZh+Id8o4KmIaCt3pz7/bqRhNV6cbubxgYjbvFgv64yrVyxW75Vx8m5y3WaQO5Xbvl SGSb9lQOaH0OoNvNyrM5IN1EQaDCIao5YohsXIv+mOeB9eao09nUhQypm/ORIFJCa2jP5CYK 9tsk+0WMsKzo4Gb8CtVRyfbKXnhudvPm2p5Wpuxbtt/ssWWBYbQe4mdeCmGTxY//6ftt5F18 Cw8Bi54zKctyYzZP9xgIDsDeC7hhHf3RvNnfZD4SqnB+Da2YbT+yI8/YSo/+7vZ75IgRDk1t hInAJUoWuoPDVwsTeZjsfCnkP8I74CJhXm120Bh6+jDo6cMyaYdjk0IGx/MMgQ1lTn6EgtjH lUgiVaRZn/UgitxYu4cd1oRlYCpcjVLzgzdgkSlyH2FS9awFWsq8cvvG2ivox4mPBsbXWjet 35Dsu0mb6ITI10RxLQ3i2jyHAJlul04GLC+ctNTeUOMtrkCaETzyDban/27Zz5V0EYLe4Wae XaB0Imm3ut5rFTjuoz9VrAVpXu8OIIIjKnwl5w3NsF2MgMBctGxqNwI722SEFYpRJFwikLWN TIG2BKn0JKTUW7g3aUzLbojlrMeoj+jGJkGEKKaYiFhdnxKxNDVNIlSTtpwVseyEiBH2WbPc l21Tm3WTHw+yMjEjd5Gd1axPK/mf1M9pFX1LLnCrhWFxYNxCdUYYE/es7dMDhVt5axdgPBPd WwhZ2CcAZQhbUQKKSeSMP9GduPmZInoxNN1YFkPRB104ZooEemC9CXbQdSOnJh42iiBZ2hiR CdUfQGJ7HKWzQ4Lw/9YXUDifWXAULdwE73rMHuD/edGyn4xdiLXYQU9nm4c77J5AQL4TzUQm 2B2WDS0xx1D3V1iLD6rD8BxEKMbP5aTxcookVX0U5FJQypUwbw+gCt60Xt9hKxlzl8CR0P4n rvxqZvqU6qhj8jqPuA59IxK/G74E6j6Dsee7EBdSvPtI70U3fMzTHAWmDsJfMoJf49yyEO/a 5WD2Aag4He/ctt9KQvLL+Ph5Ot7pTSRLUpbCOM1vgvk1L9abvDpJsLmPCbT3LD/PsAVmhJlg AVWVUmdTmN03F8F33mlvQIoV9HokNUB0O+PhuOUDKkawyg6QiWwUrWK9IxIJt3Uw+gbnHsB/ 2rNPmkDBUwNchJLHc2yywZWPtoxuuvsLdmAJzXYiHB8OBAcLb31xPpPk1GrkeTuPb328uPAI X4GA7buZiCiO+LN63uMfjejV/momA8mC5X6Ey2IH23Csg4Y+zrqcvySDoDn7iVm1c3XT7nCz y9UIlpbHpfyQamI4zifo24J9XymvGl3SQoM8hrxSnOOVzPPUh0k3F9m6attj/A2O1VEhx8pR mJeaOS/Rd0Nayibs9jJeUgb8FvBSoHDg70V6cgOzk+xUGjul5bqtCne4tJix07vMT6kw5V8f P24Sqszn35zJ3tB36G+9WbcZ6WGzLome/v5t1YoPLatZdVNUNxcewwU413FF+Lh3/1JtHENd pBsX81I6ae8qmhKpcW4pV89f3JC9a9mMc5TTiYrA4/osrgqhL8tP1qMODpfK4WIkZG6dlkol J+b/6Zk3uXugMz+sWo116XQD67xtjsGsLAoZUxRmEwARlwU2BNzR2aN0BYMA8hI7KJDYS5vl cTfWYapwj+IKYOhUGmKa2j0H3jk1GzTg8T5CsfTstI8XbMG9vJRtdJSW+D+/1MpTi+B3YxaB /xzvxZdahLT0+9VwWRdmj7ejitfhBEXGPotpFiwvh6+s7v1+jP0tJ1wlO74xqGln/A4V5IUe VaYkJXBlCnVdOKJQ1vtQX/DRcHNeVgKvnE5JHorht9voey2vVvKW1ypWt/pdbMbfuisud0OB VuMy52kQYW/u42i5QNW19lBVl+ghaQ6UPDYRvFXRTf09sgHBCYcXV/MRzsdcFZCTleLVqTBl FukImaIEIq+QYjezGkYJRLrhfgu/NRdlDYUuDbYadJNHs107Dhc/LgoHGo9Gt7MHnHcU3zjq lDPkEDsVuXrg/Kfc/iD2w7151EUFmSiNcpbiz7C87xTncVoRBZxaOrRC0lkbqXhiPSmRV83P 0aodtqZuBxXTe58YPjUD3P43gZGpJlAI+TV7WQlRrAzlQ36CsZ3pGcGN4oI0x1qENqvKkwrX eMXPX5ZHWpsxV0IuA9Qu+xW121TZTO0svnAf7XrUHja6E1RfhqpU+P4MfTRuXlXmUV0xMsPw ZE6aZTXmtG6wa8ua4Ev9/4K80u9nEVHxKDjyMmsqoDBnaJhimF9PSTSGJ/Pw02OK8j/3YZ5y 7wV2yrMscY5WKzrGf8hAVd5LO0TdXKSFEn0dhpGI6XgPcoiDtdAWc66yaVO4a019V3QLwpEF rCOXuMBfPnSBrJPTFiMtlx1GYoIWuop87irYRywnBOx6YismDt/t9p/YCt6lOTJEUNDfKcXy sRcgHRPM/8bXkdeh+h0ChjXVKIOqg/vVOViwTVWsZLVQrA6SXxcaTsnYd5JULwRnweAsGZyl FcrgmRk6AYbQnNQMLoZN5Eooqh50GBh3/G4dHtFEZJfGifD00bdsB3o2reGEI8LWAab3KiUn XKFyBnbnb0EbKyCPcQhqUdJ7LBsYewcDe3JDn/uLBeF6Sq5i7r6/KFXCCm6wkmbcvZG/f77h zbl+onth75mjqQpuKjf3+t3d+ws36lpHv3Jlog7iOdTB/PQHj73hdTFQpr11V1/qw7V8GV+Q lwQf51ru1vyUTFQmE2Se0LxsYwpGZdsUzVnNy9IXa96RpEfIyNpj2peS5LH21U2OPqV+yClA EjLSkq4PbTUe0Kd7tPB/BTtGzQI9EY4E1z8miEkCxe7wXU1En/h0KgiB0GhvRemhXt1qlrp9 7TnQGjY2jEB5aHOy1eMhdl+Qh13yi9LFaJ7RQrxoqF1MU/KziXMie7LHbqE98maxPSpuj+J0 e+QL7RHB/XqhPSqnLxXXlvsjaIxiNW0uC0qZ7ZeZmiqe5gan08rjJScMjNDq1Q5+iy8UDiXw I+ZQo/QH0zX65AOmGodeacpMOr4YIQjytO8Hvj3PlyERTz259tOVliDUKoNJBG73XbRTGPj0 XdBRnq+ZrUcLLvBh1nGq14StpBNPJTJp7uYiiIXuhWrAMM0zclYtesJ+wkGaNrDUxExAbkJq bYwqJZHrxHn1V0qCq5GPiPGPaswmrDD4qscUt7qaeXohSLIMaQYgRp5ZvnD4DlPMBXA76S/N Nhi+S1k0ryoYEVo1vNufjjFahwo9ZkvH/OposZQI6n79gudehl2KmCQ8PGfbUwsqcq6EI9+v dCNk/J3/j4/crPO8VlafnT6vcjdm48c8mIVA8XtUFRd5eDxb1bzm/i581ntQhpP7fQImBq3r NNBat6ROaC2YajfwQSfBVGc8A6rLn/MZihf20rMHu8CMdRZatr31mF1+h5n2jqVMAs+o4//S z2pcSR01cmAw0FDJ6kJ4gBZr2ggrn1Zhaw8xHvW429gi7gJ75TWtE2JSVdWhAUt5D0cD3bba UOWjTFeuui1WQJjsYq0ch4B8g4CqaUAnoaZBIfkiZKufLuBb5aMWOwKvWa0CGs5DIfdFe0Sd 8NVttMBpMT9h9SufGOMVARrAacTPBzE7l3paXH/G/XclBQ8vfxsk3b2WDqyncuDXcuq2jTh4 sRgTNrdUZipgZxEGxABFns3z+mH3IVcxuwPeNswU8fQ2jqi+8iz8sY9Ki9hIqSBK0ZNp/Jn3 JvCorakf/qkWM+jRxoTrs04cQ6Fk3Fm7prkZLbN10pJfo04KzAYVdhfQkY9c8qNBM9FAmGsg zCUQitzTiN8ntOusbp2eTBGZZQISCYVYWpxKEfmJFEFBJJKzVUd9Sov4LW3WTZsdixAb8Xzr tjSlRYRkcqz1muEDBSPvQT+O2DoPUTejWd3yY6FO+1Z/fM1PN7DiaamdHrGjhs+eIaMTY3Lt DPDhvGfrG9l0QCKZkEhxNhHI5uk0ONbU0vLKv45xqj+Qd0SEkBzE9RDhkVWJL+P5goDV2Ed7 p1hZGXAWxw7nbmR2yFqzBtr2nu8JgRH0SbbiZLNL9MBORh27eJ6BJfZ3JyP5VIf9Hp4Z6j/x pz0yFDuBpbBlBnTEGcLmXyatl8mFHtWW6zRVJLIc0C5T75Se3sgSEXbeMJIXwp9cJnPSmVh3 PM/VlOdKbhp+oDyXSZr7v0wxenOmUFebwOX8IQ1UP2v0EsoU3qpGKm5cQ7gAAgwAx2imgg0K ZW5kc3RyZWFtDWVuZG9iag03IDAgb2JqDTw8L0NvbnRlbnRzIDggMCBSL0Nyb3BCb3hbMC4w IDAuMCA1OTUuMzIgODQyLjA0XS9NZWRpYUJveFswLjAgMC4wIDU5NS4zMiA4NDIuMDRdL1Bh cmVudCAyMDg0IDAgUi9SZXNvdXJjZXM8PC9Db2xvclNwYWNlPDwvQ1MwIDIxMDIgMCBSPj4v Rm9udDw8L0MyXzAgNTMgMCBSL1RUMCAyMTA0IDAgUi9UVDEgMjEwNiAwIFI+Pj4+L1JvdGF0 ZSAwL1N0cnVjdFBhcmVudHMgNzMvVGFicy9TL1R5cGUvUGFnZT4+DWVuZG9iag04IDAgb2Jq DTw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNjAyMD4+c3RyZWFtDQpIibRX227cyBF9 n6/oRzLwUOxuXjeLBSRZhhVYa601yCKQ94HS0BonMjmRZ2L771PdVdUXzsXyBnmRhmRfq06d c+psMTs5fdp8/NDdb8TPP5+cbjbd/apfituTxbgWf5ycnY1fxa1SMssLUTcyq8pS6LrOZNW0 osnrLC9bDQNvtnebb+tenLzuu2X/JE4W9um6e/g4dJuP4yB++eXs5bmYnZzf5OL+s8iF+Hw/ zE4Wi1xIsfgwm+dZniuxuBf044tos7YS8xzG2l+qbrK6EnVbZS18/zS7Ta5TlRVJ95DOS/jf i/SPxd9mKqvqEiYtlrNEt+nin7PcLmuWlJlU9EmYL/Gu0gyZt1nZijmMLGsz8DZ5l85V1iZb 3OUxhW8q6T+LEV98SOcV/BPwXsEHPNNTKrMysSPK5J4+9UucscXXOKZ/YRaUbn4JP1QBP05T ZTZa8+C5zOH/R9z+kSapnKbJ2l4+uGqZ6bYJL3txZRJwIOFn42YzfvI5h0WrQugSMq+FbuDY BaS8aDLVtnWY8VfjuDma8cVC7ksxBltWmSqkmNewEaTGxvvCRnABF6uzKrmxT5d035eYi4+p hqcnE3md9BDfBh43MMa8xo//gZeQJfNX/B3WgHE0/jMO/2j+tQmcVNsY6qR+YVdQiTi1m66f MLU08tGuKxRFPN8NOdRDrXZCfvG8MivLPGtLLUoF2+S1FGUDx6zqWjS6yprmR8rs37OyANSY sxQQt0qKplBZrhvx1M9+F8PsbDHLs6aUWIZQZHNVY5FR0ZVVboqetoZqowstZr/9+OqY7jDv Bzesq9K8sOX9DupHQ0GZKP+5jQ/uIoHL/rdbuUsd2SXXWYNX+UlcXhsIl8AmgC/6/TY1QHoD D8nluUG2Tv7xf7htqfNpEi0wfzMrnFwbTF6dX76EfQg+3ydjKe2SdQVkhCvfvU9jroUB7S7Z FrhqLQvk47akMbemfk2BjSYQCvkwuTA0AIyc3FziV+FHScOSYk0/thi/O5z9aOnSEIVhy8/2 SSYrnkSL4DMwA2158zYF+pfJq3Rew56LtAAC+j2dFxDQ5BR0oID/F8JwsEwGmmRop4QfK3zu 8B++hfPe8A1Of8X5QGHAen49fhYj3uDJsI1OBM6rkotzHPeaxtEyFA/6eAogUobcUAODkrOp MHqm8lIsXkKcb4DHTFnBNjWQrQaGOzd4hDVfmdVKC0ZZgAJpIuLKvHxr2FCa/c3Yv4ouhRRD GCCbydJTIeBD7dEdDzPJMDOHrLCE8JcRBJXVwH18Xljjfg+wtDyo4qB5MEZZOfHAMuIxitQo aDdYgdXJt1RWFmbS6qqJ5if7CZgfub7n536gNVhDcKnxAwuGfaQxq27Dkm7e3gRyVhpVh+m/ ooyRmqHavDOIwVcNrx/txkugPp7j3Nf4jxYkmTy3S+Gyb/iGN3bn6yk+IGK1jVjl83ZrYaER Fg3BotgHi2oKC4rEaFGBD709gDKKDM4xQdg8Qm1JU7T2U2eHb6yySpoQYZmzK7VFCR3Wo8Ql edULDPhbs5sypVza01ZUyhWl4B0G+sI+iG5YAp7RBgz03+AjMGZLes0QCGwGJxyIoYU35mY9 T/uCmeFU/gseDRWhMXGHZitDiDK7ShNOBthIVkTgroOxPGRItnYpfD/SpoMgzzLQBNoIdxXP BHtwLXJKAeBtvWdaliYhi78EGeg27g65M3B78N9Y6is9/IOSQNAW/t4WIGEFIDqLIyWApQWE XnMRFK4I7NuokGjeK7Tbl3SFc1+h2m1PQ98inmlfZ+PNnTvG0FI4ZNs04uclNwQTVuEMUJJ7 Lt0vGK5Vz5FdTbCIy05TbYHGmSLnZTP1w/m3Zx+ERZ3DGEMVclTCHXF6SRj7krYwJjrRSnAY AobEtb7HkQ0msuGqZZQ4eOxwI+DqWbi4wR/PQwRRa/E8RGST9gCsdKGLY8qonAErIEwNtqFF eXiCPuLYUPRljaLfZnhEtcv/CIwkU7HMQl5Ue1BmdY3+rW40a8b7JCRGUO04NcDMiJ91zK9x k/WwYpCIR3yDy9mpPfIecatOHmhu5+TZlZ2l4kFwuhDi3ZZ6v55wJ3xYcCI9SkEDVzSwezTr PaaanSmM7XBRi/cRX0LxfDWPfJyBRYOZfmTERy7EVYI+XJq4euxDCjfN68aEhVWgokW9zwz6 yquIig+4E3oHlSWcMfmOJ5HF8yqv8pT+JyqPtZ7OLQJiwlN6b7Cm8G8pfuuREYFc2waRDIV1 eJgk0jEw9imB53Dndp5DSUtgznVAD4F39yodeA9CReGYu8xrx9zEwNKsOAEJHrRjdmaGRfJm cl4jhI9zPfsItkKAoe1ASLQxQYrHeneVG5Z9FHM8My9F713Vm+PcbeOPHHMuliuK19VZSNMU S8GpoXOA/6Jjis6dH1ekTdlsmZHjPeuj5E7E0qEGUMqCqa27w5BTEHaNqSywfaFpoTHdDkuW aS7JzrpAf00iK4vAOjHSKZPIZbLu0wy61YPwVmsHllEoXboDB0dpeX4+PChiXdtVB4qGgizV YRO2o/3mupFHoERh+mjAms7Wrzv4JRvzc+m8xCicCkyh715wne3m31zrHhkAcozDLdU7hSB4 KNlg52HvFOb32aLmWF6SkOwom+sbjNniRHUBdrWzmXyHjvhrHJhC7kg3exG40GHcydp8mjW6 IrBV2XLWlkE+7EHji00MK6d25Dx9S1XD104i6fJmly5gW7B7vsxyH+7HgcfutEWObZimY9c7 x0uFaVvHEuAbNl8hsQDwd09skXmdcj/KE7C/1la0ZOEpC/mLe7mDlgCRtYfmFTke7SuGHUJM 8OWE4Bl1BmBTe6rarK2O2tPCuU1zp7oK4rl/QnnEnlo5c/aL/uvpmY55UK12PSialYFCZuGn Em6jYhlhz8EyYluokBRVwjBmVjxEw0Gfe8ACFFXso3BrkcICdRKjOe7mmBcwrexfXUfmRhqW w9YzbnX39FRN6Ox04Ox8GPxJMHKhzdORzWuO91eTcoRkcuoxXNfY1h3suwp8Uj/SdwmnF/wD C5zZkAqCLcISelU7r4vlwTUVOND56pAGVGDsncD14g53ZNL3jIKZita1VsAkekTdp/pl5n7g Xy/ieue1V118vN4xX+XLbOhZXbx96zxHy8qmvfZSFtKQMyLzSMjM+LA+pP/ILE1A9K2PmWPV FePAhxqYgA30uMYCn+CPxg5kalqsGHF9qqA88ATOghXuUIQ1jDZL5zY8iOUm81W5ppDmdtTW qSQa6WlM4Zm9RbGPFxF0sTwvnfv09tMqVgHgKiRR34sd7mNdo2GhsF3hPld0p8Ayu1qn1is0 CAf7zrhN4DAi6DywPfx2aSdsKIManvIOOiOn6Ass/13GaXcZJ1j1DWfGtZfmLRH/YYLBZfi8 O/RS+F2nsqnrTEt9TDYrp4KQLa1Kky1ZHJHNmidA8U5lz/wqrO4VABXFukcM6NLwNOnCvBUm vui/mn9rtpGOFywD2XJiF2K9Gw/kCjStE5XdEsy4HcN2JmpF+DVzwjmKhmWBjuttp4D0T8Su pse0FCNdY3lcZ8spvshrOWcZUge3V8gcBt505uWuwwzkmNrA0B6O7N2YfqkFsvTLgeno7Hs0 +VhxmEILqsIJcRGUBUD3gA6bcW+QuZpQdOuwtJqoJhD4GlXXr7JPdJUT3bBxY+EdI5g4rnmv lMbw42XxVII3xUcYVISUXSdGH1USNgYgttDZ+O9HZZzOgVB/wcTl+gSvlkdKww3XtgR11mjJ JThByh7bDvhacv/m4WTVnxC1jGqG2flBOIAKfjfyC6pWlDx2/ZHPgPpkCebdoxLV3PtoCrGz BnSjIITamQgmf1jNqQSNtzWy6thFd3c4LzopfFMl/Lfug4/FRedzDNbFWxbBO7pQd85Y5rbc 5piRqM9jPER3sEfcUrQx+DxOrNkNEAKiBtGIP/4YnBshWzfw8SNuGR44yDtiOjGG0vkaLhV0 JxQ39nD/Zb7aettGrvB7fgUfKSBWNUNSpNqigNd2EQPxNkj8loeCshg72CypwtFuu7++c65z ZijJ3hYF+mJZFGfmzLl8FxFIh55+tgBdo3rDSwkFyKQInJ/RbGW8oeKuJ9wNaRkHniAua0oy KNkkbqoKUFXV6Fi9QpcU1n69JO/idBhG8IBgiFI5Jbh65r5GtTk3CcCJNKMiPVM3cxWoV4LC p1zpBFEtuDXoC2VYtOVWyii1lmQbtR1o2fBr7JMvmM8q3GCONqrhEr7e9dJt/SPPq9ak2dCo 4HZ2VBhAVXnjukk4EUOSU7U/jtCi4DzXbXyU8cbIfiW+yWCcz5gU5xDTJd0W3GqzFNIb0X0T OudtuvxIGlJirwBAEVIMzMSxVNkzRybJj5y4tXIgQS3Jg5HQEV0DzOwNMvnocd4ey8TERGRK Cpah0imbQYq5bxPmTfORwGGSOG9lT9Kf9gUrNfE6xV4Q6jAmNAbAWq3CXMkWKP5MwhViep14 1RI864+8YzEpCmgkykMaNH/yUPYJqsKQRmM2I8KDwfojm1elgL0o6u3XCAymP5TchG4xzTN8 XNXi52IJDzAhHq7vVhC0Z4PFg4LgjmIRXM7fAEZRtxHo1Qx6LYBegDuQlDe5Z9ksm9qfsyyd WpYQd9PUBiaOL9jogsSkRlG1YWUvCr/OQgq38hsbUrIRskjQeF0l+BfuWFWoJlwTpc5TsViF Jpf6Yy2pLUsFFnhB9FAWxKmTg9NYdXJytLq4lRgL4V3EcVUA2BqiAJ6SGCy08SbSoSNPuSA3 vE59mexg0BK+Kq+syOqinWBtA22NQpOjzsvh4HGnZAUaR1+zxszT87ckAWiRSlL6bZ/P23ji 2qzChPKIQwZ7Fwk6qnSH1EX1sNT1mEvV6Da2GYCdkecYQS/TytCY4zEVRSGEf97v5bqsEBSM JiU5hUomWqq91DofUrh5056bUrfSqQt3cevNi2Pq3Pk5hYKHZTGIVXQ4ZYU/LZv1+tScuqqm Qa3rtYwLy6ixSPxUNpQRZm+ps9iifiSxIO5ryuFacpw970dWkvu09oZe/JGpJBtp5JkLYEpi UKQhGVb2vNcU3aVIWBy4a/qNlhVmoGQLEp9X9No7+uANOVcyu7Txe6G+T5STD6hVb+jLVbIw sEATfuMc8m+XibblN1EsOzjXgd7FvWTK3KZW2N5Nwukz92IVhJEtUZDulIf3MgxROOFcy0i9 JL+htP03NpHR80zjN9xow+KZIHL4SVBj4jkbpU9IylOB9yKsomLiIynBbBUIgR+HUdyOVFRw ZiecPqixPdqi20ymWzN1EumwBkOCVTHVvNMwyHjgcxe129ZSUoFHkIsMmZOwB4Et2USosbhJ Gp88lhQlc7oTRdhElfTYj3zB3yjKLG1Z0/AnJfvXxWYZndWkqnCQC46TGVl4cMfTcGdMJVYQ mzuF1aox4ofQbum7zVmc9YqaVbdct83LOFv9Fzhbn8ZZVYtznL2BSm0AsG5BKjorMvl833Yk tYyOiu5WJKwM5YSQjXw1/ENMXSQ/9DzaiSDei3Eac0F1kVMExwBgv9EgFFsWYSI7/bqV4ZGQ ZiwPVqJjJkX6Jo3DUmLW0jlNyC6qYF4ff0DPzr02fsilMFxPsYqb6HkSfRz9NXYJyFvgf6ty hEL7ZxpiGaotYeNAkKYwK8dLPKom1yGDO/pH4CAaW7ExgK9Gf36FDhlP6mterDxaG+vEJ2YA iDvd8oGW7xl01ZHC6sRuYkpVx6O06sfs7k/Ts5GTErDgloC5POdkaKPwXjNF3fCMSOKjrBYW EA6t6pn1cSIp+u3ENf9lUetSnTv+ruS1ENuaK1kWLKeAGgLlo4s73KRmZJRvP+DKiJZ1FC5C u3x4/y263HjydpD/0t+zK4T0qlyWBQcuzy03yQcRUZF0jyeCJX3aSjERx2REFSlLNeCAhQrk itrTN3YAjW19IHgUVhtyfEAYr5ZVfZ5AaqWDNeIeFKWe8cc7H1c0suIP9/erIoiBL2+UAC4i A/jwJZwcPtugg3zhu9Bg4aef35RulVJMONLNCMUJoThihroWTLtahDqOXxYABhch6QNoSwdm jp+EGYBxuKjo63fI1L+y/KyXm/psYtbmmo6uGdEW/nMY2Ga5WdNN8T++a9PyXT9r0Z+GYs8V nogEhh0LkfGR20pxqS9YIrMalrG4Y5lzD1dudO+bhUyQmY9+YV0fj4f056CmR8yGaJld1I2s YQjTX8GhMSu+DXTUSsEYyeV2hF1CLqTa43MBMJbTwz9hMSVsn4krDoxe2SfQz0ng2TfTCOu0 Dr/Aq1k4M9KrWiQ9vhIEELgP77UdUJwIZJI6LLhUhj7TK3FMIrNHQf4gUJsAFUKJ1sRAv0tR +GaHrbwY+TF+KK4xZWCBTU85iPTOdBO2UeoDqamKuQyTDbdKLXyqigDB1NhKfeIEKqZx9Tdj 1NsvyRyuR7Verlp/vsMGSVqSynQuNDujkhnf2BQNGwntXOaCLjiMtCu04ECictxX2QeK3m/5 n0HRX73R/rBNjqZUPZDegdMD0HSd3JyFAOkdGe4HI4Xz/jmMyf2TcfmjzFdahG7p181ZsGyV RVyzrB1KQ9eeWdApul75vzOLBFr788pt6r+EBRF0g/pZ+Rk7+IwdfK2SV/VYkWR+zBN9atAK +oewRYZUoINmnHewyjSO3ijnakWPSETajZ+rAH2kHbdphQqDEDhg4mn/xOUCqMnG5njWN0ey HiChqysj5v9fa7DLmULSQgOS0ZY81mpklcMtk1NlLh5R7voylhxR82lIIFgBuOGDcgBWk2C4 Cr4nUCVRzu6Wog8UWmgkXCmvduUjIhyvvF8dq3zVLLvK/celN3R/pvYurf28i8/WPk0TV+/Z wJspBtKuKYbWJPoUsVFvhXgM7PcPojRgyT5yGLsbjzKizOoqt1Vd9SDyi66RXBZUgVF5MVMJ M7tXMnMvFu+kPWDF9rmcEeN3k1dLiWljNZFjyU+slr476ye8UybosKtic51Y4HXBkcaK4MSm BNS/FcY/0re/kh7mrF3TQ0oTvyEZ5FcuMZHv0eSFi+NLnWzDe4PvbMq7y6B8gi7LNkjP554d Kevcpnvp9F5BIfJJX5ALlG35FN6Pb3CJN/iYPCtk1yJV/5yXd/TB+3Cw4TdX835wa+5diuAD nZzswuvStKa7nM+HqkYjeqhNobi+guKuVDZdk2wSBZ9akkotiWcd+Tv0YjwtRLCuX9CLArAG kXwGxQwGVe4pKH2SFMrsrfIzb7ErErFOd4HfyrsbqsLdD7YaXPlP9EyQRzBRXMzCufCSIIxB lV0U4kUUgHgesKGglqAAJuWpYOxk/C7zNjUzdY0DcrxJ+bQQo+tQ8RjdTGUhsLqgutgJv8c+ g75uwg5X7368XcAFry7D97p8v4BJFVb/BDloQw/DT7wg/OSwhx0hA4QHXzraotID6I3QuTV0 bqjNmorSBBGOpxwg8T7oMfgSunhdwjue3nnCp0P425Y5I4O/8pvfh5xV1NCbZRMUcjQVdsU7 H5fUyur39yvh69Wq1hTXGEzwJ6twdPhsg4fxhVtVyypk/+c3pXMYXAx86dyM7Z0IvYrIvtY5 +rhAdm3KfSh0oPbd4QEgAzocuuqiAj4PhBcmN1Sqxsc9vC8aJokWG+IzjH0YlUVTPhfXi3Xo 76Z8OCxq7PHAsGP4/n3RAqq24QwPA9DMgCAQY33Ws/jGJI/FjpW1rl7DPsFsrSl9+B8lsN1w /j7D4EKf33G/m/GtsvEtVANw76KcME8dtOhPwOlRRkz7r8amFdjabRklxAvTGeH6Y/qQ1qlR Ha14dobt6CIvcEukqveyDd/5f8Etn0j9YKBduZsQtg6iJgcB7ygrkXwmEXoJEuUktBdMxUbu WDkCcFvYL4ubJMwU7XOPo4AsEjHRssIfAphkU8bi8GzP102FIgeRkZ4dxVPPPz0OxZZXHUQj 8xmquIW7xkkIotgZ1c3LBLvZlB7EoQysuZkviEv3CZVwuzKVTHpJ4RZ+eVBBnw5vHSrbNBl8 tu1snG/u3/xbgAEAaTFCGQ0KZW5kc3RyZWFtDWVuZG9iag05IDAgb2JqDTw8L0NvbnRlbnRz IDEwIDAgUi9Dcm9wQm94WzAuMCAwLjAgNTk1LjMyIDg0Mi4wNF0vTWVkaWFCb3hbMC4wIDAu MCA1OTUuMzIgODQyLjA0XS9QYXJlbnQgMjA4NCAwIFIvUmVzb3VyY2VzPDwvQ29sb3JTcGFj ZTw8L0NTMCAyMTAyIDAgUj4+L0ZvbnQ8PC9DMl8wIDUzIDAgUi9UVDAgMjEwNCAwIFIvVFQx IDIxMDYgMCBSPj4+Pi9Sb3RhdGUgMC9TdHJ1Y3RQYXJlbnRzIDc0L1RhYnMvUy9UeXBlL1Bh Z2U+Pg1lbmRvYmoNMTAgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA1NjIy Pj5zdHJlYW0NCkiJtFdtb9tGEv6uX7EocDjyYNHkksuXIigQx84lhwR1Y6FFIRQHymIktw6p s6X68u9vZmdmuaRenOTuPtgil/syOy/P88zFbHL+8mF797G+3aoXL85fbrf17bpZqvn5rNuo 384vLrp/q7nWSRRnqiiTKDdGpUURJXlZqTIuothUKUy82S22nzeNOn/T1MvmQZ3P7Nt1vbpr 6+1d16offri4fKUm569uYnX7qGKlHm/byflsFqtEzT5OpnEUx1rNbhU/PKkqqnI1jWGufdJF GRW5Kqo8quD7p8k8uA51lAX1Kpwa+G1U+NvsHxMd5YWBRbPlJMjicPb7JLbb4pZJlGj+pPDL 8NQEp0yryFRqCjNNgRPnwYdwqqMq2NEp9yF800HzqDoa+BhOc/hRMK7hA9n0ECaRCewME9zy p2ZJK3Y0THOaM9wwcesNPOgMHl6GGg/ayORpEsPvHR1/z4t0zMuSwl7eu6qJ0qr0L3v1HgNw JOAX3XbbfepjDpvmmUoNRD5VaQlmZxDyrIx0VRV+xF933fZkxGez5FCIydlJHuksUdMCDoLQ WH9fWQ/O4GJFlAc39u0t3/eSYnEXpvD2gJ5Pgwb8W8LrFubgMH38EwYhSvhf/Qx7wDye/0jT 7/CnCsDS1PowDYozu4MO1Et76OaBQssz7+2+SrPH432XQz0Ues/lV19WZsbEUWVSZTQcExeJ MiWYmReFKtM8KsuvKbN/TUwGWYO2ZOC3PFFlpqM4LdVDM/lFtZOL2SSOSpNQGUKRTXVBRcZF Z/IYi56PhmrjC80mP3397hRuP+5HDyxygwO2vD9A/aRQUOjlbzv46CkJYNl/dyt3qROnxGlU 0lW+V2+vMYUNoAnkFz//GGIivYOX4O0rzOw0+PX/cFuTxuMg2sT8CXc4f6MxKd+/ensJB/VF y7iM18zomvQEaa4JleG3iBGLCzyG9k/0HuAme4DrciHFKVBpGU2ZB+/q0ARPWIWBqgH4gnap PoRJ0CAIJsFqdx8Wgf2wBTfeYXp07agKfbC7dldLnsGjtDhAOXw9qIGY40ioZIJ1owjofwyn BcaQAQqimGSAFb9axFEWftY1I8b9AEcWwgpqxfjTEWbxOINPC0DB3xf8+zkE2BTGSC3uweua XxvF58ixT9ZBCQzlztGEi91Hhkz12rEMImTd3vaWpEEksPiG0Lfj8aewQvv5jYxnq4XUWrma es9PV9Yz9JYFFyHwbcGQz0SrGKDXbH+NDnPeUws5UIkdC/5EwL8SBy7RxUCl5LA9d8k0Ug2Y DDolTiJP+RLgS2K9ZS91yjqv+8RX/GSNyNg6Pl3VasGuamqYr2M0SQKiabfeSth+EFTxPYeR d1JCiDxnteMHcmA9JMiupdV2Dry6o+/sbDaAY8F32rU8DCelKEcGqQibsAVifmc/BLXH0Pby 7PqVPJBFLb89DmdbM3dCxnVbi6f5Hryqrb3bJsF+FVR0HetqCjo8lVZqxjbamVGzS4j2nj/Z kZq3HhigyZE6hmtteNrGS0gd8OVrSdNGSSA6NUgKigd5mncaOTzrUzmJSnGbXedquRbra9pv KTjD491qbD/7rR3UC0c1QReuJFUbSeZG7OphTDZlVJDyapV4RQzjlayqWKKRKZJtHB0h2IhU wzxouy3p375oR4oydnWLkdzIpQ8WIf80Y6BgK3Y2EmtMpP00Gim/ONKxNB2RpcBIg17eU989 IWkhJNT1WeXjzeEFqVvg37qwlDz7G1yWRGvLN3UxBLOLYKhkV2uJXhiDxF650pIYIufgFynj M396LaC+tJvnzjcy7o7G2Z2wFtUOxVkYrx7mQic7sNUULYndprOp0sixrvCH1vFaYRiilp5v ZCxFurH4TesosMI5dDIngP2+lPaBbf0zzCR37XeBT57VhbZCxXY2+TU1gFJOrRxgPzK4DBIN 9y7E40Bpzj9cILl24X8i9lzvm14LjtGrbNZ5SVAEQ/SUFfVynE44lxGtawXIagqrhE/Sh13V DpJp3dAm7bEc6OVS2meREIt9I0bg9RsnWsYEJ7hWy04IZ5mw4YBI2VGy5WZggufR2s9mHfBV eup3r3jReuDg4wmJosjKIBFAdj6d6jKMt9Uu7V0OHAK+RaPEP+1SQNDuJSUtwmxJPOGR+KK5 Q8RrVyNpIFTckVcae/4cdZlOhkIAvMs05tGXRZhbMQHdtatF0/Wh20ltjFW9RVUNDVWlT8Fq 5lCS5wqxDxd4TY/5tqYnx6Yqo6YnPd30OLz2Wx1sASEKkEl3t1YkfQ41RPoSYQU8iukGMPRo /+O0Fv482oEWz5zyQ/5Mv0O8cbDfyeOcbzYPfgHZkVolk5heFK673YBApASb3ymeO9EcXuU0 g9qQ9KP1hMfSW93YAmGR/VcwAHDUA9qb0FPxfd4ImXszHS8xHAng7+4H0oMAxuW4fb22hzgs J2PpHsud3HbAO32nQ3QhUGgXebU8Eq2u9tA50vjUw06RcWvRDHCg/sOqzobRdU+7PeNY2dWX 3kIsmClZ4ZhF7jtoI5z8bknj+4o/cc2Y427Gyz392KO/v5m4Z78dUl4rlgxaMWMbMaBaEevt IMwUa5F2mw0yCnR62REV2Lcp4JQiGaORrbm+oPApNfhFV5HJtBT5X8JpFuXE/r0zai6Tzqky EaX4iziAp3sZ2btX9EmjSB+IyqYtSNexgGNK7kvRyRaaLB92o77J0YqVFlO+UK9O53aPTsyV InJ6PBM9nlp/RHlhxB0IdDGWJXd58LLF+tbURmQRoiD89Dzy3g4DacrDxRVWcQ43uTnIEGVU Jid1d9Hr7uSE7vYIovw2gjCmREy1BJGdJogps/jAbz1V/AxZhPFLkXrhPzjQgOM0j7WYKuDC a5xGM+5CK9KgJj6PvFRCPE65p3qGN8xR2jBpxvc92oqgy1MvBaXMWfkea0st6nUOCwYaS2BW NifgPgUPdvmw4eO19dcJtXKM2oPbiLSh4xqHr4S6y6aHwuWQGcWaRSOT2a6F4LAIZ5bha8dD vDCUNiwLDgjS3ofveSKxxKkWyWO6vUhQtPgI1CuxhyKJp01RhaE27Rb3qC+5ExT0GfKAT4/2 HDPyz0lui9hc+Qi0wYE7QoW4/98xZwA5W5HLg7bB2JxOA8clCH0SwgUHm7MJd7Pz1j60uoZG MFw+2k5ycEcvq3FUJorGWTvucr7XhrAzP+KsJeoQGxkGf+9A3GLdyMxeovNkvxLH23p5faIZ Ear/g01oWsknMsYRnetz7U3O3PBKMl4aShLC8KhLAUkRpE4piGXHy3mc5WqkhVzBuUpj885I gSnX35LTqOXh7FnWrehe6qKeqLnryd4L9L7VZK2frqmv3HDDE0KYiXkI/SAr4kKap4gaE12c ZIMkdmyZFnbys2wJFf9NdJmVcACxpfkatkzGbHkZWllkgo/CkK39L4RpZebYNyZKTjtC7/Pi QRbMch0VfA9ysTGZvzPkTykC5TscOOmmOEqLVG4GCIQI9dpK+9e2ft+GmLjv+HmaVPD9ZZhW jIyIW1f2qkfonNwHt49dIX0HCZq7JOtVaK0E9ymFuTgePbhQhHDNqsc9IkGS+/3aXusiYjkm rBnv6wPKwRrDrY9TwWyDnMvDDi4YcGXcGoE5UA0N+H5cKJBOyclsSPuyAAoE5Y9mJXtl4a3I XP680v/keIOEyFK7FGXVcvIiTqrsB0qJRFIij/Ve8utR8msxdx4sB8FpGLg4PvcWgIWnOvGe 10Noh34HNnJeG9Idx4bXYV/S78KIuuIj+jMJK6UL5NEuHNKlUwntSo7pG8EvyUbYQJLR0a/k Tus4zl5GEpRT7kw0Dli8B6NJeTo9zIFgT9MkinX2Pw73rl26IvC43LqhdnWlluRGpqY+mFbE cfz4o3o2DWwUhj4B+kzL/BnDPbaZe+liWbFt/sN91fVGbhzB9/wKwoABbnBaLIdfy0fZ0sUC 7s7nkwzDkF8oLaONYy8ZXHh28us9093V88HdlRwnL3mSluTM9HRXVVeHBdxLTaZMo2K8hEQO YEOFxkV61hBIBYBShECpjsoW5CN0bal86D6R6XJoUWQtEbOhQfMcYpqjiNn+f4uDm3w0ZV4W qEEvK+w2ZWGASdpl8RgXmSr72csblmwImer5nAzPn5OKpNztutucL3fr+0e5rrugzCcWbLFg o99enSu6ayxSdCRBc0wJGDO+4+iltZexhj+Yqaj77DhRKyWqy98Ui8hL5B3y3IflWDhWe6Mt MvlCx9ppak1JiXout8Z73GUm7/5sM/i1mwwLAi+mA+89ojzAvT+L5zgTy2FRaYTMDr/yTszD j6GAQ+mw9ww078OWIGGfYu460i90Ah5vzsrGwjy1601hzpXIFL5E/PGzJTL/C/dk6oVAJjoV Yz2wNMa1JnXGlIH7HO0WxR9UkPpDVm+SPJ0MyNWgVvZ+vrqonB33p3kHdBj5yBrqDN36xBXq BUPzgOUmXB5ASZg/Q5Ft8P+Yo/tG7Q6AhZ9guveTrlCZ5CgoboWVi4X24sTZi7c061zIzX1J 05y6o2j4CRJLv1+SXT7EFsamOUmu3aMNJp3oiIHfSob2MJOIh80GrRhCg2C0S/D1waWneHdk m5/uYXB4zQ5vA6lJ4xv516dVxdMRtTN+Fgt/JdeM7mWDFoxESsB8Bxkkxx5C9DOxlBJ4rA3j MvCWHhZbikfKz1J7waUJqz9FBBwP2GdCRtIrAi46NdBCvk74rhAnAQSrR5wPR/LAU+krUcmF vSvadd1uzypeeczeOVtozB9QsKJqFgomieHIn/aQ9tAoud/9IXkw+laBnOj40B9gqQtnEMds ENsUdQ+FmerABDjLFJhODS4BxTOX4xzBv0aStJxmCg8ugcqrKLgygE4CKVb8/RgOGkkrTihi zYtlXeAeA+PrdhQqQDBgehX1jSHU2yRsyyKCPfV6Zf2jhzDFLMSNTBoRK4o8MhyVM9Bug3Uk cZf2DnadFzjVrF5WD8if/VPYbXr+1teBbuzExzcTL3bjAesi7Wh5myZy4j2OlusFKkGikQpm pGkTetWD1IDT9Rho85EZLm1qiJUgQmf3vtgk3jBWvOes09CwkDRuNuQep/khQhMfHcTGj+H+ xGdr4pEMHsbcL+FupUiTXRik0fRqousLKjARmeUgExS7lg1w97+78ZBGNu0iBt0n6Sl/jQ4J Jfyf4a1ERNKhS04fzg9dAYLG6MJDOMcuujkXyplkHLuXpL4MkosqOAUN6l6UWvddwg6hr+eG J0WfLc7lNh4ackjH/QkylGrggTgTIA5sGDC/RC0uJALJJRQcW/chcIocQ6MJSSD/qNLOx9go ffc42MM5yKj4ltLAxCnpQcPP+GeXKR6RU3hfHaMir7FRvb1y+Zx1/gxmLHVfWZruTF/BNkhW NJnBQ++ivMHsDxjrLlfu3evVRW0pQn/q/IaPe3MjV3HfVPmd/WWNRn6duo9m3TWVdNG166Kb tWnbs3ak8gOYTb/ZumwU1bkBrMYKC+3c8Cl1XYWn2JJtO3nw2YpdDKyOMIN8OFNksy6rDn39 S7ppl39N7CzytxYWpb2z/Vu6xNy4yzecBLOlJNhCtZIL75a8f3D/tQUb/k3Z4KDPbEmaUzhj oASuh6VoS1SnL1VS3LHuiLpzR9xrcdgiACiHAPjxYdkXVNNxpxqSFNX6iu0Ja+SvZgtdtDq6 qppcR3i5JYTdhNLe2RsBwsjFT87PIAcC50eSfI549nSQPZ49Zpu/XwWCMP7ojohMVOSrkxwu k1eeILOT+3bLc6PNBxDlhGVkiagS8y/HQ2eHKI5rCvr4vfhCmBpkPdAROcs9nzRBJ99TtuDG fjziKBPH2quwLvQHfTVx07YoRXPKTkP41qapAZnvVhcVtbXacon7u8r7X1YXLZq3a5fTx+S4 NlCZF8pOo7JTGhqZvOk9saLFChLsoiudYOfl79UfuT5zp17Kj9UdZ+TfvXaosXKzcvi+cum2 KHcC9M7BoRJt3rAmO96+cQvqPOMVWE/bmfyDkzHnKOVjv4fjBs48K2FVK2rQdvUZDSvPaFgf v5ICoxWpzeYldWB56fXBttsB7waF4kiwzh8GTDnjIW6FqhaJi5NoePk0B4xxGoPbHNBCU6YX NfWpkOkakVBeLtrPGJa40RabwG8tGjrz2rUfNwW+Ebp/SQXr8u/prXR9E5o54i9faZRLOIfM R+5OjKkltYFoVkyNHky334KKFOnF8S00HUjhXlPw9prnvbdf8F8W8A8Jr8uSeBYTW4l1nKZb T2wbvqmfJ3YX+onqP/ETmwrCVi0Iff2Nu6HJv3Uc64i0Fjj5e0dIV4vrd/zi7iT5FHL1uttu j1Mv8qeJbaCBBgqOEtl1pSsEjZuh4x+wGuI/YrzdDZ94aNBeOKjFnWOLq0OskU8jWpLKN1Ef NE7nFS/gnjc3SYbv89s7IkidX0r+rsiWdfnlB9ct7c8ESramKZLOt4hy45HUUeY91U+sKEIk 1X+oM6BFBkiChLs24BX8K1H4q9uXAOik/zwm2jWLdgodhZcMOvtRQLbLxmT6G/3QJpvEkq7z CKAxaxymSOWEIAcUGXiF2E0dRdFt5A55zHnHCn0lssoPP8ivBXiKdVsUvw89RtFTsTd+Fj1l iJ7mv65D5IPb/PaW/mkC4WEiQZkuV9x4zsGpZjQ1ZZegaWXtb94TpuT/SaowCba4ToMaSvoK DWJ0PxtY3PfSFKhS/GEgbcEh6KEwDOz5oSz60H0aNEx+AHSPydqJmih/yYse5AaDW+iQGMc+ iM7tsSOfLk+JYEbO/CFnSX0QZM/CJD7b8mGMYoaA/iwbKzuZAY8+RDnlh5VItupnwZ6lTnTs Pn/CGDCrx48mEAmkJ0suxCWxhi2Q0Eeoff+oZgR7+hIc0ExQR3gwNB+Zt85mkLecICzyOhAW XaJ2w86YoQn5GC3ptYKcr3B+BbIGOTVL5q3sSc0l/kFcHO4RJbMnUiPt/4aeSaUDGICyqAfq rKB25srG2UcwWTjJAJ5GEqP84ZcjdJd/eh/gHMMOd/Vm86LL/72qfM4MvPR4eJWGUjIqQtYy ivIh+hZeFfkqg8FTuMivkBGWlyH6RvjrPtsPsKi/rDpFBK/RnLqDd6oFhGwh/IBDNTdRtHDQ E7pLZKyTuNX3U67hoxDwJIGWWkdFWcJb2xDuxSJbN9mymzTiJkko2UyLqZbehobnu/Lba2pz ePGV+46mP7fl1crJ/i3PFwLUX+jZPrB8+4ypDQ2ajll/t5BC4IUAZtbj9fmObKQhq/ZfoQWc 2RyOYwYnIFAoo6QfAobXT14YlE43TAFKa4Mg1vLy9crKaO3no5R2UQ0tsLpKS2h5X6np4UAw nPYHcdSekrtxfohdUyYmJxt+FZF1bJrisXY8AJqirdBPBuPHxNtYALZVZGXCTi/Rb9b45B7Z 3w+gApe1sM9uGX9H6roN61qmdaWrW6sJI3nwqplnDwO2lwtCTaafxErYl1uvbAeQaZchff9a oReS6bq++9NvAgwAEsOFGg0KZW5kc3RyZWFtDWVuZG9iag0xMSAwIG9iag08PC9Db250ZW50 cyAxMiAwIFIvQ3JvcEJveFswLjAgMC4wIDU5NS4zMiA4NDIuMDRdL01lZGlhQm94WzAuMCAw LjAgNTk1LjMyIDg0Mi4wNF0vUGFyZW50IDIwODUgMCBSL1Jlc291cmNlczw8L0NvbG9yU3Bh Y2U8PC9DUzAgMjEwMiAwIFI+Pi9Gb250PDwvQzJfMCA1MyAwIFIvVFQwIDIxMDQgMCBSL1RU MSAyMTA2IDAgUj4+Pj4vUm90YXRlIDAvU3RydWN0UGFyZW50cyA3NS9UYWJzL1MvVHlwZS9Q YWdlPj4NZW5kb2JqDTEyIDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNTEy MD4+c3RyZWFtDQpIibRXWXPbyBF+56+YykuAlAlhZnCmtraKOrailGXLFp2US94HSIRIZW2C kUgf/z7d092DAUjJ693KCw/MoO/++uvj+eRo9rC9v2tut+qnn45m221zu2oX6vpo3m3Ur0fH x91XdW2MTtJMlZVOijxXtiwTXVS1qtIySfPawsWr3c3226ZVR/9om0X7oI7m7t9ls7xfN9v7 bq1+/vn49ERNjk6uUnX7qFKlHm/Xk6P5PFVaze8m0zRJU6Pmt4p/fFF1UhdqmsJd98uUVVIW qqyLpIbzT5Pr6DI2SRY1y3iaw3er4l/n/5yYpChzeGm+mESZjuf/maROLIrUiTZ8pPBkqFXj lWmd5LWaws28xIvX0dt4apI62pGWjzGcmah9VB09uIunBXwpeG7ggGx6iHWSR+5GHt3yUbug N3b0mO60L1Cg9u/n8MNk8GMWG1S0kctTncL3Pan/yC+ZlF/TpXM+cDVPbF2Fzp5dYAKeSPhx t912n/qcg9AiUzaHzFtlKzA7g5RnVWLqugwz/kvXbZ/N+HyuD6WYgq2LxGRaTUtQBKlx8T5z EZyDY2VSRFfu3zn7e0q5uI8t/HvAyNuohfhW8HcLd/AxHX6Gh5Al/FT/Ahlwj+8/0vV7/Koj sNS6GNqofOEkmEjNnNLNA6WWb350cpXhiKf7IYd+KM1eyM9+X5vleZrUuVW5ATVpqVVegZlF WarKFklV/Uib/XeSZ1A1aEsGcSu0qjKTpLZSD+3k32o9OZ5P0qTKNbUhNNnUlNRk3HR5kWLT s2roNnZoPnnz49Ip3WHen1RYFjk+cO39FvrHQkNhlP+Y4ie1aMCyP+eVd+oZLalNKnLl7+r8 Eks4BzSB+uLfr2MspJfwJzo/wcq20fv/g7e5TcdJdIX5BiUcXWJNXpycn4IeLp+wU3VWHADj uoa+hWQBFrGHW+pQacbVGtvQRPy34abhHnJt2XHbfXQXd8P27dbujoBj4++Grdjd8TvqC+HC il5GpdFKNQialZsM0MJ1tJbrvq9R8XrZfnKQC/fW7AVDBCnAH4w/BO48EPjSvomogpxSfGfH FsEVnVTRU9I4MKuxKOezummVE0Oh6RFs0bI/rXPDRgsONs1Dl8xM2i/DZKY430yaq/npJDq7 wprQibUlQdd1dHXGhr6Kpxl8IRbDWES70aDZyxHwZYmuNONe4iYulEW9P3v6UtO+1CogFdrb 89R9I/ed6RpIB5pekq48z0JdJlD+F3wwYhlDKEoTm9XiODYpsAzICTp4eHRpTUzCs4xr0GJh UqkYBzTnZsU5aD5i5XE1+Dpr1qpZc7a+xTAEoX44m1KC7aA7uAZcd0mr7RpuA5esgseVjbqN 8A2uC+ks1MRWSmdQvyxXW5l87pTLTNpF5Mi8XdCtm5EDj4FtjdjIXohT9KaLiUDCl7gOnOCe ZNhgt3cLCQ6LW5KcZiOuOok94nj9fsiDcSZ1elzpCseE1ksByLD8NNM9fnPVdxW/Af0Bb1xH dxyrjuOhuvErSsK5gkTzoUQcBreUAeBTDsX2G5omdZMwmvxCtM/r8CpU8znOGDsN52/BYWlc 3CDKPTDKUQfUgUWzSA4N5Z4xjw+zUfU14g+pWy+9g51atmzKdgQKwB3zouA+nO6xbYpmGsKO FMtGIHVUh+ys2LYe5pg6rc8vEQ2wok6zAF+uxQmRKiH2WfFiaQ6JMVti3ny7kcC2VPcy96RH xoOEgxQWCKWTS5y0/cZV2rrZ5QSp9ivKd6GgfpcwLaARpRal9T+5s4EC1rxo74IkQotx2AJv jR/Ja6kgE4w+2IwEGYMs28Rq+0PYbz32A7nMgF58D/wzeWH+t0lU/SjmB0TtIOZfwFCz0Gqz 2GIIXzkgqqN30IGmAESCXQDXsRMcghnce/f27JnpwBrKpErL4Xh4IS0pE6IZkplwOLg0aL+A dIudB/6+Dbu1zPk+WWdu03kTT0u48I6YxTkrvnRnF1whtGW9oivz8SYDBppRUsvyuaTmPqmm dotnD6mHXygOTvT6D2TXGMmuMfvZPYstwu7FcWywjMFtzPLTAx5/2ZxYTTZK4QF6xqNnONoJ hK4j6UaP+DetnxmCBDN3F9NdW9Hm1BBHdnm/71HYgYNX1suNHV8TocOCyByBK6F2r1wJcEfL qGEC6vHBDz6eJoJhrF4wAt2EXxjhvq5sdEw4QQ9ZdF/y/bimyp8aHdBUolZoagrlFw5l4fft YD6ZCGdhuw+qDMa+QyRyXwOKojbtAPlzDvNgHN7g6uDGhYhgZRu/W8jBQrq2GU7SYVgthxXf oHsSVhkwK8mzgsi6WF7sx7Tq9431QvWG4zeJnbnEM41wX5kk/iV/z7g2ntgSYOlMS0EB2hJ6 hCBYAMZmnoWF0sMCrrKZ+S7WV4d2UCZrA6TQ6dAg3SOWItNKY5/ZAkYbUYgZl68x3iZ6iTCa ydZzgrtQHb3/PvjbpLTBbgDJzn8X6lN+w17llJnor/CVJwwKMpJ9TQYijWciAwbuFhEi+PSX dk+ZL8ONwfpSEmrPlc3tfI+IJztDz3FIZDcgNLdMaL6NBoyxSW2qH6INdU8bwK8s/+6E0ekz tYRUQus/VUJwRhLxx6iErhw6FJjMPEUSAYMWqWh0ClVURTOMpHV/n6kmN4XypLD1aAzB8lNS KayE+Q+ryl0YEQqN3FYWKJ9YVA9kpSgHs0e2OMHPRcOVIqyXNDAJBt64kWIgGNRw5Wasih4z ph2cSCSVAZcZb78Awvq3FMbjLvZamRDx6Zq6xN2RmSBsXUBYFkqWJGNZ4uRjt17IqOldpw3D ViVNK5tUeT6YVuFUeuwHuGfXbB9lToxeHGAXmntaibnhGtBvIGJRXdOGSkN/t9fdUAiEKpJf P0Jk3Vj49Ynx0VaaZD5i70OKPoD0yjFH7n0TfYhfxAiNam+S2EoswnzXmG9E00hdbRFUDVrg nHfc2sXYyFOL6FQNbCpYalnz6lFXgiGPYBjBSJpWnu1X1NZ5WgzGWNhlnEYdLqIuER9iCp/s fycEfn7FkhLp1hJ/XWe0cxZJZfVg55Ryd+AcrdZUEIzUDXftWwT5qF3uggpg2hew/rDIKSGU uhOh8m7UM1TzJfIF4i48yqMzGKN445Eeb5W0VeP2UWiCvT2T6KbfNmlyvep1Rl7oWjBC9X3t RgJ5t5NjPmXXl2rBqhpRPeBlPcFFjII89DjDRz1hXfGFdtDAPc9PfaZOIVMiWCChXXaULG+a FIRjv4F/0o/E2Xc9hGyJ4gOdyqpBifnp3yxatQOoEVKpBrBlsMVR2UZs+kxpHcLKjmQKZne9 AQFqCLnciaiBNyPorffSs/QxxOuHlgtnhAg9H4/9IkkrWe2mvhUzv3jJJO17sUcOkKxTFO2S u3GQYQVBGCu2dIqwZJJwtfBD1RJq2xK3u7BF+5LiOh7SMQoupFvJk+NwxRm43S8izOnDtue2 Gy6RhP2bNlj3xJzwnRAKIMPrcTOwzC8x0tcVDw3ucoH4VjWfnTB37OviJg7HjmAAKFH90hYM pAtufSoB+UchoWdvXYJqLgsJjajZyZLjy5UPtt4XQX3NfO16VJ42YLfCD/qtiA8QFTi6HtWk k3tWM8heSAZQxKYJWHHAd32WJbDS/5IOEbjuxFnZNLHfb0a4xdoO9dSBNupHmrDn8tlFTGtP hk3ttrbvbWLAhfmNECDp7j5NhZU0s9KzYj00gKNXC0Ed4VLMuiRXQrvC6WS4boeEU25eDaI0 k/HjCu6UpMzC9jzlM6oqWKUym4m198JkhDM6xUOyRncEDH3Gh3SYneyCh1V00/vM3HLBhMwX 1EjMgcLQvtOe4c0y9zqu6sMEmJ4KJRSqwQ5tOudtGwSjH6eHxFGmpCOGLTvlMIcge+nMfh1P S7j/ks0/4eS8d4d7NPh/nFfbbttGEH3vVxB9koFaEZekSDVFAddxEAN2ajQGWqAFCipkowCp JCQR0M/v7Myc2V2SopM8WeZlOTt75lziYLM1QcQ073pMTmf02GcJtLwSeEoMeprYH7y1M4OA c1HWjvYKItaqMoHK3tIPPouBD9Q8aBwmAvW9ScTmis/6tWFX8MzB6bfkYtge/9ua9/IXW59D 2uSkWNRbdBFcr/8Cv/a+9V42O7L3/GNooO7FvN/cq0D/wvitFzdUuehBSmbVclW7AZc1m1ku K4zLGv7uk1RW2gsxcfkfWn2+KZjdcscVWHF0x8Wl0Eac0tzie3/h2ePjKiO4/wPc88p1rj6m 3MSc6Kn/5qLyZv3V69sL74+9ay/9efv4c+dbJ4O7pj75Bx/8YNb8Vrm4lndeymPJAlheLv7q W50TgHyrqcRcSkx2v3YSzb4nEKz1mzp6idLzDfOSFCGFiWPbrdyQhByP9bHfAeawRYZ0ZHty Y7FztifnwOU/J8FnSIkWdaRMIltjhU6+OuLXFTc4nr/ArkXqIitAh0XvUk7Ywy+vGRPv90N5 zMu1YKEmUCgWRgamYAPjh4wsDLjrqPOodw77xHi4sfFQe5TpwGEd2JnWQpvGgs53RJ71TNGr bkSCZ2EzQ3lWehLdUPpsaBu74wQws/b4a5AybFkcCVWh8lqPzx9KrE+xA8lT51x656xVTRKr /+KIWo1Txy4a0t4s7ocumjdrNtoxa/I1s9HBP8fG2V8YZDhf1amzWnFS0fy6JiplEFgmpY9L VzDyibiVhdFzqcXOSc8kNdvEeRMum5cdmIpUa1ILTic04b0H7QH81YLzvW+w4H5q8vzrZKsy FSKq9nb5Sd1a4w2KPxPOm4RwxnoH150d9tjbjA9qbR6lAdeCvFd0sRIv0iyCYwsW+w5rS6ce YvTqg/oaCVfFGiXTmKyCb0ujXb6sbE9qF9UOZannVAcWu/QhL3ZhCrdmdkgZBjwrbOjvzeBi SiMWGVBn0TFwHODbsAxcysZiyjmeFLyx+TaJDAaS/8W6oQd8o2JjXfpO5RtvJCJnXZGvzkuz FZirXZs6a15l24fPiCWW62D6FvQgdFEtDnv88sBySS4wYE0umXps+ObzCsAvRXZ7ym3zM0lg se/szERIOTHUiwjq/s/rBLTXif2+u0Cam6ElSac8CM35QSgXySldJaxzK40eQD+1+ZEaebf+ PnHr7VZ/RBoU+foN+grROStBRZCglAIJynVZfx0F1kaBRMJN8zQDNl/s3Isvd+5/OVeMzDuR LS/uCjVsRVGDgegoC2rH1UXlD+WRgUW9WXFIo5ib67XsJf/R5+5lrm89i2wIOdTZNQ3jeU/u Ks5TFGpq+zTVWiqpjNx5iI+xP08fiJhIkNsdeIpOwQdGJs2/saPcaGQKB0COAVMGXAkKLenu df0+OyoLwoV9FEonIK8abEtW/6yjOiBaGFkZ93+1BCnYcw7E3Xy5YyG8LCo+5ODH8Z1gW+G4 HTtutkLokH4G9ZdR/bodLdlV9DpKhrU6aOg5oVzrq+SUQtha4kkZnQu2JeQvNcpEsxLQZMlm MyWNkcZY3Rhv704PSSuNv6URfRZkxWTwtNUF0V2eEi4WrwfkMEkkyDGg0t6gv/hIkiwiOpqh 0GN7huSDe6TiTwDQe4U8H9j0QQHvh67/EDsIbLcFgDtr5PGYmHYRXT3nNv10ms6KxJQO3cFy TKTlppzlzU3Mm56YniJOt/pi4izniTN9P5dHjEv/hKmbsj7SxpHBwY0AwtjW6BFnt3rzIY5B ePWBhemQHDgHET5uPtPCMKyEuwqE6/mC9yPEQQweWWiKWnlDTE3aS9HI+Q26tUhz0dBOf7+4 LNkR+JoKVvjzlK4dI2IqqjOUzu7EzI55Mmd0GJH7jwPoVJxgZ5DjcsNBseIzD+x45g2HN55d u7+1aW6QV35a5ZvyZ5HQHBK6Xp0FTl41ElVcmaMNLXbfm3+TDBocnEzcPhYahdlJxzDKlm4B KturMZblJPIYiQvp+A7Qwa+WTWEFYXJhcrX9ZHGVSvls5N/C/CkUEjwD9Tu80x8t+BLnqJr0 TteFYTOpPbXvAqdbeGXzbCLcpwK6Q+bJOrkBCn6L1kX8mI7IQacz02jYJ/sKTjcvJcFoz+II gzk+6VeNAlCUCTkr3VFOS0i1735IT/8I3gQKqECCuXXvE6kbZVX75v5thA7WdISSeqF+Oewp 6/9jCoJYozM9JC6byH5+pV37kWkhiKG0q0Wj8eA4bxgg3lq8sxQm/2WdqQlQNSuOLa+kewDx doAVVkhtv1tEwxQG59w4ifPZB7XNmay4aDy8yxBEAN2sPemvLp3IgDIlcO9RUm/SHzIfhEr6 rqaeF3J6SUR7rrVs9a0TBqJNpJrrOgzIkgiwWdWzbFlMcN9lUSzXVf7N7BcMakJ/HWa5tdr3 XTaiOk/7gP7U3VMMfyhtn3XmOhQWch6fk4t2vmmfCPjFpnlqMz6umGbyOiNcXEmKfMMHqBl2 qUDPgapHsbUIvnrO+jQeMvj8IUve32VR/zCDmLQewgIOw5MT8GZEPwcZ2tQ54br14OSJpbuh XVrX1SymyilMEQ9Stv12QVVeSBD1CazgCY/IaGOc2SrvGZKO4jDQqGjC9RjDIb5h/6WzeGcp UnvYxiqn/Cw+mDplvEbJwwj7Q0IMwqIZkIOckgoJF4LJH5pnsmR1M3sAVbBA5dKtK3a/5Zx5 XuONldmlF1OHUJdyCJF7hOSYJ20soWUXK4Iu8oOKVLnYwmj4++vBeLcyolGEiLVQxdPp0n06 5JZA8KUJbxB5iEl3wCUdoH2yUMWn5mJZ5ccg2Cc8nvqAMm3AwbCI8FaY6SL9SFxBBfFCrQf5 4knBBgLd6h76Z8mgJ6j3kZKNhjUR0bLdWg0+ZQ3ZINVgsTRdPwpzy7Iaw/Hm8bv/BRgAqSIk jQ0KZW5kc3RyZWFtDWVuZG9iag0xMyAwIG9iag08PC9Db250ZW50cyAxNCAwIFIvQ3JvcEJv eFswLjAgMC4wIDU5NS4zMiA4NDIuMDRdL01lZGlhQm94WzAuMCAwLjAgNTk1LjMyIDg0Mi4w NF0vUGFyZW50IDIwODUgMCBSL1Jlc291cmNlczw8L0NvbG9yU3BhY2U8PC9DUzAgMjEwMiAw IFI+Pi9Gb250PDwvVFQwIDIxMDQgMCBSL1RUMSAyMTA2IDAgUi9UVDIgNTggMCBSPj4+Pi9S b3RhdGUgMC9TdHJ1Y3RQYXJlbnRzIDc2L1RhYnMvUy9UeXBlL1BhZ2U+Pg1lbmRvYmoNMTQg MCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA4NTIyPj5zdHJlYW0NCkiJtFfb cts4En3XV+ARnBrRuINMTU2Vb7lMOY4v2t0HZx60spLxViJ7bWU3+/fbDYASSAK0LFkvlqUG Tze6+3QfHk1GB4ePy7sv09mS/PbbweFyOZ39Nb8lNweT+wfy58HR0f1PciNYVSpFbMVLozWR VV0aVdWkYrZkupZw8PrHP5f/e5iTg/fz6e38kRxM3LeL6de7xXR5d78gv/9+dHJMRgfH14zM nggj5Gm2GB1MJoxwMvkyGrOSMUEmMxL++S+py9qQMYOz7j9hq9IaYmtT1mD/PrqhF4UoFZ1+ LcYaPuek+HPyx0iUxmp4aHI7okoUk3+NmINFSF5yEUwELS2vXOKRMWdlBdccw1lt8egNPXV+ JsWY29LQa/ftQ4EnAIbzsqZXxVjAxw+MRNNv3jZ/CtZ7//OXYmxKSYkP+7Hg8PfegWo6m9/6 Qz/8ZR4LDMTQ+a/BjybwjygFPSwEh48HfxxRNL3zh4JfIlg4y61LSZQAW9bcxCk4/YhlybTB 0f1yef993QkAahSRumRKQiNAoNgIqipFXdu4D97e3y8H+2Ay4anCc18CW6pakbEFR1CwZ2tw 4rN/V0j49uizPJ8V4wq+LuEM/uyN/4EfoS74l/wdMOBcOP/kj9/hB1RsQaTLoaT2V4cgKDl0 Th/cA6o5+c3hEhEyzlIpZ1b0Un66Gfm0ZmWtJaDYsjKWE11BmMZaUklTVtVLyPfvkVbQMxiL grwZTiolSiYr8jgf/YMsRkeTETY/9+QE6o2F9dQLVNQGiqQa18DBcKHJ6PLl6L7ccd2zDq3R +IMj/RVQRgL1McvbOc56AbKa3W61utR4k1sxWfosvtnJoVw5FMMODfROGJ0fCgE5ZDA7rgpF yVmBRMIfj+HrqTOcXxeqtPgjmM7fwRfgwA5pj+v9TKDKqlW9T06h3kD54zOs+yGEVuG4VUDN iYsTpoCgn/AXCJO8LXBsuq+CXn3EzxrGxet3C4fxB8MwbhdH7EtEOHgvkNQfjz+cgKP10Avb DlOg2lWDOed2HXxahhvOWr7KAUweQxcw8eGPpvOfxJDOlKFjjEGVurfeVjl3643BqPZHHCqn Dw9zh3t7h+n9iVuFu1HH6ZuOD42kH4bnpZQN/AfP07GCcgHkmXMwQ2feYwFrHceuW1+SLr7C HOfeNivcEpV0it8ei8r/s4T+dGdhpn2B/+8fsfTf8c9Td+rCbkrO3ItVXXhTF1fxmLcp+aGF K4oKIwKvh6v9otDQiFfkfWjAM1xFmsJGcpv/NJgP3GESDl29g1OV3+XYpufhtIf0zYqBCBmS K3yL8BJG1Kp6sAtlFfofKfrJgXJEExK9faYF9q6in4WQK9COygL/644Ii3QeVt8sCIppWG5e skwXXnosfcoByKwyZzyktk2jgGv1uWirMKCXkq3iTEYhvbJGqYk6A6QeL5lj5ZdffPmOWuUT fS3RLRkUC4UrfsTbKrSCsqWoiNWmxPUMR7j76zw+a0Ql6o0Khqqs68isYT1yk3sYrTA3ghVq ymTrYQA3Wc/D1hC0BLUSbNAIMOpaj6atUWLlWi+Ei6Ieq0gNswNCBWZZEQ3LhIBLU4fXQTTc 0LP512nosaCfkAI4qafIZoVq/k08szcJpOOVs9rdd+W2PaajC6vmwuiJy6rxI+vKDfqOH+g3 kew3rmSpnMPOXtgZ17+AvT6wlvjYPoAr7Kw9ABu5Uyp6cMBdk4Lr9oiOewQp7PSic4Wq8VlP zSzKdONlw10P6em5glyTN2OOAjU99jKLwQbSuGDyUXqmsiooj2w6bI8y3ktI+7CXwJPnvVSp pHtHPunP3CbkPOMoynlvksKVSlRiYHJXSo7oxHMB0cfojU2M6+fS1ujedbeGpqqRT7hqAB6a QHfYEunKTWSMqS1+uFl83Ehn0BPCwF4/LCDT8CIwcSNZU3LiVcza7kSLFytn4dC1O0L6M/v1 QueatQJ/i2JFraQ+cQtlpcB8eMc+9EZg+Si9Cd5o3L1J+BrDcXxz2PoqeAOpw0bEf3pXERY1 UOs2KOc0vrqgbFZezmnhxOHWgXS8SsbhfXPtFAT+enbuiKxR8UTQ67HcdJxGfIFXUj1lF6ty tm7+QPkQVJiznZjSnMdIBsZsQAxz1HY1Us4ch8l7HLWybGkTXm+hkowF7vmOOPdifK2IyHRx S5CVEBG8B6FuWnqBjiJKJCXTcFRdhgmnB1YxZAczF9357/1EW7fl5xnJZKzuTuidcZ1k2gOw Dil6fWAnmfYA7CXT1sBpyZSA6zWJTKxv72stmYZcNVxOt+OKyw5xLYk84prLGXMcqOpxWcOz G3J5YMsa5pl84pk8f5g+FmMDVA60XTF7EX5IEXgwlN47T9V4zZdF97jrXGzLXV1jmMm+2hbX c/f1gQN39wDsufv6wIG72wJnuNuH6zWJSXHX+XoZd1PNGDNXikhD85b4DuZYf/MetVPPB3QX bX4uZMxxEmxvLuCtdp8LSnpxcoNaGvh/e+vmgqTzp2IMd6f4kRwGg/47zmqB9Gx85Utd9eaB 87LtPIC/OtOr2+L6efD6wGEe7AHYz4PXBw7zYFvgzDzow/WapE7NA+frZfMg3Y6XEWf5wETw 5oGJkHk+oLt48xMhY47SIFhvIgiN7zIRJYdeTjz9hcW2G0q34D1Oej9RYcULOAke4a0r2S/b 4npOvj5w4OQegD0nXx84cHJb4Awn+3C9JhEpTnpfa1IOtWPgZKYfV6RUDNs2S0pvHiBl5vmA 7gNe0a5S7Ycz5jgPskdKVpVVlpQbr2lIogh7egL63Jaazr8VEvbz/OGve/hFwMpezFN7ejCA nmgX+LF2l6+46o0F74gbBkqIv3gugEuW6dmtgf1g2ANymAz7QPajYQ/IYTZsjZwZDn28Xqu0 3vIEkBOUcnAGiUwMB0cLnmCDZBJPxv0Z32Jj7EHKSVbjvIs597YYa6Dc9GdPDG/isosvKjdO NiBZ69VHau7IGcpUKTddN62/BD2SrtcrYBuRp/Cu0HagbXfEtmKAxrti2x1T0gWshGu0Dfhm U8s4+HrJMs406GoZC7V6bcW/7VXsjDhLRGRs2LJ6smNrQIFHIrZJWIOsSj+HNm0ah5VsTrRX dyrUcA2fmbXYFu1HM+Y44VV362t44TXDW183I0hnt76uneBwE+i0gKcM/V6MBS7/aTGGFNG7 b4mNP+y846li/pHGU76r6u7CD362XPi6VqigUotoe2C38PeB7Bf+XpDdwt8Hsl/42yOnF34C r9sqkiUWfnC23cKP+zOx8AexA/SMDDhxCz+m29+uzgpRpnf9oLcutBQ4fTfgl+SJXd9UaLtd nyn9jthu1+8J2g507I7YftfvCdvumJL0rt+EaiKx6xtfL9j1uQa9jJakyu56Z+zu+mZne6O/ d38xJ3G9z3CN3GLOmePsyN5ihsxCxFxhnjjDmPKp8UsYIudmuAgqLoLhIGOCH69Jht1A02/m pfUaVRlsueDFOGk37Kb2YT3vpvXOwblTYsGREgKT+Iwnzt37zSa+Ukq1KZHv3mdKFLo34+oy 6iSR615vzHRvMGa6N40bfPprhPZsrrF+NGOOs9OXlUZhm6uqQg8cp05rPDE/ntyiU42+lHl9 aaXfdu+KcV1yenpejFVZ09MrUJk1PSw47EV6VozhU1PyATUnpxfwnZeWXvnDBOyoSIP1GKwG MQLWNfwO5OT0PCFUN7tOe4GLxHW49So2ug80BCUnp4UuJT2GEIEjBm4EhBQYuVDwBfpN0gnE p1z8MKfpJ//kS4PtxCO0my8hnmgdNHlnONcF467Rm9r/0udHve6Ahh0+jMCOwSgacsDmqwZG e0AMnRgQ132atkZBKtZrU6nx0ZAqUWPcHa0nQncOvPxojYxy9cQegqosSAF1ptNZMQbm/p/2 amluG0fC9/kVPFJViSKAIEjOnlSyUvGWy+O1UrUH5yJHyiiJI7lie5L599tPEOBD8k6SiygS QHejH19/neMjP3ydvMQwbmAiMlCN+V5WtxnlaZF/g2hDZD9OMD0fWdJONrPABe+4gyrI108P KHZLGwrY0E+Eo7frZSb11fYyuY+4wf/tLj+Y/TDD+cRfU76lwev5/PABXvHy2QTuVLEPbL7b 8u2XEytlgGW8ojdxuBw4l/NXtHbN3uLD/Okg7rwjH7OnIQzAfU3+9wTwwMj2SDVJPqPia/Kt BA0F2HwtMV1LEPaPag6Ff78Rda/4s6YALydxfmCxog3Kf+ry13JTeJaMW7jzQp7zxBtLOrFC eKxUym5L+pzkiM1vxczoph7MAM1NvmffWzQSKEr+BaEHzj5MXJxbGufngLZzYUpZviVs9oSy FOFHfu4wRhYdiIY9CgSzwhRYXQBWKsWb/B1EroTJZ0fX2NL/9+zgz/SSHWClzPf0y+vZLb0c 6Mh3umhGTjF5u9lDdDHW4KYKzrybqDVGrKG7oxEwdUGNtHYahKAC1zYdDMM+ESFRGKFaqSOY 6BqtR5aHwkCoICIXJGNeqMcWEkeWY0tsDxOtQRSG4Bdlk0FKBFbzarGaZYsVWJitFpcQFIDb b5nN/g2H4Q5ougGDQS0h8fsvv+GnL0DNpiUAc3Yn/17y4w6Ww9/dbyvIrv88w4oBXupRXYkU 9vgM4oqYxVXEa0QRRA6b5VE9MDyVeMBjYI7qcX0CzGochBPbYarndEUxJw6ab7BXOOoVhjEk qqXsK1Z0gVWPrx+opqy+0qLTtz0/oGzMjGDCITyJvIPIkwKRGi7bGl7pl7kwLaFSZ/yYXyev 73KQN0OUgooiI7JDYlOm4pYLPvGGHyK1w9vmF6l5K6V7elr2vx5kfXPVJd//YGJ52ZqKLhRL wSWyIAZP+dDv+LBp6z0d7U5oZdNz0qocGkIkf81pTQopI5oCzWKJQqREYospw6uxmb4HKTMg DFEt+9OzLIT0VDFXA8VMikItH9MjxfwMPXW/mElNUTcooqsHEN0OIjrXMCh0Ha79Y1I9MvSf LtbMKMy/QK7X+P5cuVAAP+CHnjRPeduT1kuOJk4OBxy60Sz0M5qZOooSkozDYg/qoa6mRZyZ N/kLYZVAzRKSf1JbV3RTUqc8nfTlbAhquLoUaY5WsUDNiKYANSQxYInvQM3wamxmy6Oey01m FgX9A26iYOYggyDTFM2AIVbNKW7iGtA65IaUFpaBjA2ClWtcko7dmAV2M5BkEI7CMTG9GR40 MxlOtjqEhemBBtV20JQDh0ymCh49hseyK1oTQYdPRABkiFLF2GtRr0xA2HHx9XdK9ZZqI7Vu yoRaCxWOXeDa1mN9jeWh4ZpV/ViNoomtHNYgOtz4Hpz8mORmWvhfIrnG7Pglghus5V8hGUSO OaNfSrZpEDMGdg9MWGV5pBiGETeUVw9woywET/heEsZ6A/lxU4CHgXRV5KsQGBjc+JfADVoV 0hJeNTX2n2hVnB0dTlcb6nO0aGckKVoOqDqsme2SOArohkiG06PrsQ8CM0ug19VUVP8Aekdh FcrUDrSXTirUx1G1ouY2DquhxUv+vM80pbqw+nHiCVAtjGIWJhGE1IImMTutaRCb0SCGb8nS nn4BFUvEXRxFLOKsoYkDlxRr1/R2hxsbeKC6bDkpQdBbGt4Qf0uA2nM6q6dWCKlV2DKnLZdn /Lw+k+VMvuOh/CzT3Uv6unhzeS72L3jfRWIYq71iSWzRgo14jc2G5iw4bfh0ay7v+QOnK5i+ Vp1yKwD0jTlWbz4QFZAeYjFUcZi5ADa9vI8ADJYRwPo1M3ZWJPuqLTUcj4pOzYytp3nqzfMh i6ckV1JFEWSt9xuNxWB7l7VMm3ra5Qvp8vghavAYDUDvGaM3GuNC/pdo1g21b6TJkL0l5MNu MoOobun/e5b8mV6yA63s4dfLenZLL7zwvb8L0hz8m/89QZxBYiDmGDEnpAmQBQi3Ac+Yo+Ds A7+yzdQUBV0EaPNYxrh6OgujLjXBJKwjy7HCYhgJXYGQ8yMktJhh5FsSWnlzkoQWFl9OslDv juMlFqUfx0t/rPMmeCkk8YoY4zUnbcwGhQu6PCO+eNhLYq6FiXKC75WYSv6bo/kvZyjHCwRj Er3b83d6UfF39KmjG6rF1GAS7799kr2yil8tJDR/3Aulzb6AQQh2680Wcp4XIasJvSmpYbUJ bkkshsLMzvg+aKpFCL0jLWsp3PU+tSELHzavpJBlZ5b4QLaTowH6oedUiNUI4/QoNT4X8pxT nJTnM+tntq90SfzfZ02QnwNkKE6aQJvsIMNqa5ITP/APyfu2KMfWY2Uj/MSWqOFn8hMDEk/R E3+CnpjqSK01ca2ZWmrNNr1aw6T2EHvIDVtj+mXnFEgsP6yECgsQMruBhEiD56YzpIvjsatC C3ZmcG8bvFndUtahRjm2nnqsGmmUdrRRFk0hRLEtry2XnplWrlIvRZVWS/2vteLXe8UMPgga a88O8qVRCbutNlgptl69Y3/jCpSy1AYsG/8ivJFmvL6FJmhNfNrnG7XvJcZrrQq5kicgxHcx ZP3YrUgYdYAXR5EacCVUkmv0YtTn0Q9GGnE8FFlnRmVVrifrI1v+2MKGQXTcb8RcviaDaQRT Ya8jLAo4NQBXxSheEc6xgnUnVPz1ngMOAblfd0Kz4R2aBwd+/XMoQ9oLiJJelB0HGUKc9JvW GEkyS0TrpYWBoikzvCLMV+RGPsBalLxRz9FceBJZ+802aQHFoG+lW3TbT3KLLPRs8uM1sXjt 2i7u2qDrsFcqCepL2M590IVgImcVww/7TZoVXCJJK82zb5Om18u5gWchmOkV92Fyon2qTdyx WRPrbQ9F1CG4Z5ct5JqCCE8P0Rmb+ynvMyrk8EHToMWaZZKMK0rG8wRPXgZ6jchSU9GEcJ8x XUL1V9c4LNWhbK4OZB3mjyGnGHaKxVYMuIGDFTboMkIfHMUa6gUhWb+iZ6gW8NsDbsnv+YW+ FSgTvj2yFar9wFs+kAKVJXt2Ytg21rNCHzQ4hV7iPRrEXFPl8+vwpgmFNbjCZKqZYhThAipi ueDdb0iEyDuXu8ra/IKtV+RY0bPOr/SwuPW1yKRXy6frfP42/mxwUMUMvIytdGqla61MnPOV r8C2t74JrrXhwJLVgZfO4/tefSXm51TgJwmgnKbAcOXiGbAq5JOXfCJC4MqWW91QiC0Vq5mx 6ZohHtmCwyyIMlPhXOBIZMVwxOW4UYTbR4XMCVKEmlWQ22SCfgCmfwmCKZnUKVR7QtS3BZm+ YxkGIq/6sn7vG/y+zbT+rqgakwGkC2WhE2QHRUKFbW7GB+X4wX4EN8UkBb61jh8MB9KN5LHk xyXboVARkW+XXwSvZPdK/9+3XjAxJG7TC1txhB3EefC/gpq0HZzXMOCmMS0UuZKhaDXBMeEt 1bcH2/Dt8gyfMMidEVUoqdbwF51YUD+AO9RYDQX6j09jY8ZNizeXVANYj/i7YKEX6BM4usLL VhAp/LjklwXvfI3+cnqMknoemVfKyh+Y0lC5aFzRsc11bHtBJ7I1fKswEUr8D4ZYQETcxr93 WDHYKzy7HBgMfb9lm+8mngocZbyQCs14BwKvYU7Y6NyU+LQMPhWnqGszeY/MLVJXFujK1hnt YXVlp6TxHxDgXrfhFkV9vhbytODMlIyUWfGck0pbZEq6ZCv4vmLUxPOZ1hJl3NNdPI0KB9j/ mSlgyOZQXyHxD/ecsmsWwAQhVOfEIoD9F4Lusdsj+/iMIBoYjDKTCbnoC1WBVL3QjI/kKesB PQNoatGond0a2xKfyZ86pC9g04OSEDA/4NAQX1jL6q3iHxLGrYb/CNQagVrTg1oOYkxBily5 cpsVtmC6ydeO8Z1hUm52+MQe2AqjEgsYPYsYPam10OX1msq+out2bOaQbhjpjRIqEPEk1DF2 Wh8Je6yYK6w9wpknzHGVpCwDraSqzIPzuEHIt2CbXiYeNAqtlTf8uEwqJ62VCy1/fLlKWsF4 wRldO15vGFQHbMeHCfdfoTtNdKbRjmdDt4uZuBV40pqglTvyLo+mScdAZsD64szhhJ8Q79JW eC/jK062wZkR/W4blC7KjXXsVRbu5SLKwrUvcwZEc2OUSc+i5nhskCIo8eePWqCdaczOmH77 oN32pwt8hvspWaB73W/jbG7bfpK5cnCYTERpPMAlMO/CLIevdLe6R38otsQEMLgFNIPGci6B w99+grj/j/aq6Y3bBqL3/RU8blpYFimKkooiQD6cIoBTxLCLHpKL4lXsoo7W/Vigza/vkDND UhK5G9vdQ2KtKM4MOW/evFFtRy+EfXH27pVYnb4XP/54+u7V29eiUeL585ev4WXrcNHCcKNn n59drXQDhkRVNiArQXXoVgpZSmhN4s9h9XlVw7rZsx47rNjhH0JCZCX8X2vYChcirr+s7Jsv Kyu37UHu6OkE/9ytyvB4u7pcXaxeXq26wlKh3eieDKgPJVQH1wYt9Auf5AoPA9/H0WiOZmak 6exu1YEoiY3Mb6/m7RMRjqUGxVlXXNic49vfonaIz8RQjC/bSbYOQb7J3E1ahdh5chhoE+Gv /52AjRDmz25E7NSL3c1AcP0UN4sJpisHan66pfa5pUDGzbRU8BcX3LhX6bvS8qJ2Qi+3fqbA 5YFPJWY13EaXMvJvPGR/w9fpO384j2dEFXRVVaGuYkngDorX5hUNueBzkBg/vbqyGL76HEi2 LpTqOPNObtvp8/rWdggYQa5/5wN+wp6xxYV/LLNLlAhOJTEA7nH9Hr++81rM/rnuP01eD8QK EJaksDw/QOUYUz2MHwwjXDVQF1rQXaUJQjU6EAB8FpNDcm1Wjc2ynOyTdLc6q9AasAIVWoPu twUalRgkxskwBOv4V4RqQsVurkUAFlwtLIdsHXICYuBtogbmuqCCdPtWwjtgupxptg/QNMg9 6yWnfLnnwnwy0mQYBNWshKZN8yfUEQNHzuZ77P9cVvM+4sSNoD4dT6QjGfYqn2G6wXLg1s5u Qt2799sRC9bX+11QI9JhnQS1Eyw3zCJOOVOJjUEOu494T9yoWfcETT9VONM5CZ33vsN3YRbx WoOUGx+LslDMmqsp2rJZlMrZFMCtb262IqB4FFSFbltbHNpY/APsfxWjBX6iZaQhXtkqnWJ8 wJlpOhdhLkeBevic7u5ceC3qpMd7FiIutZ7LU1Djq4omA/LqOoi47XHsmW0dfI8Z+nHeiu55 QgmDU4DcZvBDBR+G4vPq0lrjImONKel3nZrVGMQk2vNCcqEj6aa281KJtSOiBFBw8S0pn+VX t1VhovxOlcrFnB27jFapQdODG0+FSWaGf0i9PqbAzKm1yHFbLlANVwjIBCYBhScBvm3+kARi 6X4sDhm7kezG3qWBaYT9AJbMITcGjvlNXlTspYUDey9Q4e0hNx2GddhNFbuRFpP+OFope4kH PEkQDebbfOnYV10ZmxVOEbT8wykiAGVcXTCG0CTLezIZYJRZjiOtF0gqS6vmqV7AQlwuQVpZ rqxq4kr7kOPKEsYYpEqYtKCwjC3xSkNtQ7fUtnBh6DLl+gXwQA2u17/AsrElD/F0MJcty3lf hIucATx0iMLf48WK4zM2H3XrcsNX9N0ypSZcFCcU46CE7g2D81k6BOXziRYpYWQxpDO9GgfZ zLMprcbz7KcMDYCLhndA1EmoMu54L5GEWQH8hbrcEfLNOOlV402YVOLudUgmvaWW4clf1mtx vlcYidcko1gYOZEx1UVeWPp5aCL7QvNmwUmNj0663Yk/aXAYeALB4WYY/57u4FbXh/dKB03K AeygX8eaa9m2+x2t88qWQ5gOerEcC/63XuJRz9+ESY9d8AgbymwhhFQeFk1nQeZg8Rp7dPL+ WdL465joQ1DaxvBwFuT6KR2CjExlCFlCPL1wyolE4xsczd5Sas8ZTPgRi40zB63LmaK0HAnV EknKhCQEbdA0HK6/6VmehjlWtMcKHZC+jDS7E3QjGcKT9ZAyHJoYmyzk+Bog5M6/9EDE3V7Z WXR5QUf+N6xOGQEPl5tzQQ4DaS0n15fqje2CSImkkEjnHJVm0kBIaSYlk8iV3qSn0txyHGe3 4FJoEvaPhpHF/ioa9YjhQYKOklQzP2PN9D5/0aDZ7+KaNy4jJ936q1PnQZX7EdZlasvo+mHZ NveHP++bjXHX6IPN5rMrJ7qqM+6Q6KuqwJda+AIVoVBFzLyqEmK3V1RaI9N2/XTbTVGZI9m2 pXks043D+1Fsg+x94pUsLGL1LS0uYCMTEpkhiopqvysmggxCPRGgSRJNbDIQQWY5jlQtiEAr aFlPJgKtSdx/8G1p0tywiaY5gUg7ogZL7l+titgQBQiihmpNYsn3lhQ57D3SnBxMa8c/H38+ yVWKG9DVY7kBvDZ5sD7WNnLDUWwjNxzHNHLDUWwTNzzBdoYblhYXsNEpbiCEPoQbMgiNuUGx CrD/Y+1HxAer9nBKR8sRcyQ2k2UMNss6meX4DuoF64BOqZ7OOqr1kh3nK9Lq10gSPBDwDESy 3svUIUUeeyObk0dpJ9cQRh4FJkUe6Oqx5AFe6zyaH2sbyeMotpE8jmMayeMotok8nmA7Qx5L iwvYNCnyIIQ+hDwyCL2ISrzMkweuZskjvZksY7BZ8sgsx3fQLsgDCsDeMpaoqgpTdVn2UHn2 KDXd/4f1pWMPVCw3pDlGzxM70h5JvtgfzMxz51IePOcz36UIA30Ryha+DjIGuJ3Nmf+LcaSM 4xhHzjiSbSSN4xgn1niK8QxtLE3OwSPLMsUbhFTHG4ecMXFkkOqJQ9VFmycOXM0SR3ozWcZo cRGihVKb7M0s25zEF+Ens8OaQhpl/7QVIG4hKQYihd7OHzDHOEaAAeVvGmeYIkYxmWoq4hS3 S/DsA5MOUN36C8gRDUbEZneHM8+/MPMI9y1R0ch+N2x3Sy9+IE1z5oLkmcvyWLV+G/SOBNVI xpjErDjisQwisYxWunuxdwJXKXVtnzer9YlNeYJOy6KqGvzmw/qnZyeNvaCRJ7SeIrybma6K umnJMoJpAVs1yZZmp9puPwEUayls2HWDrs/ssbvCrC/hxG6onJ+mqEsTHyaKHGNIwKIsVONP Z+qSjsMikjK/3XHqB7EZML8kN89315hCl9Otvw73MX05jRODkzKOLApj/QZfGKnzmZGLzJSm I99KcmzY6Lb3tHBLQfbixbOTrmjXIwGD3t/Ttq2NXk3A/AqW6vWwGf5JnQhupqkYRx+VMniC utYPuf03z05qQDUDa2RdL07p7gV90bsgCkoRdmmHrsv7fowAVjHATKHKmt18D8dq1lVFlyI+ rjHH5cdn6FlowVdZCUNPtdAN75Bmdn5ApWoWYAf6ZHZzLByoT06JE5cj4pQz9ktvR+MGuJ3e Vm1RIs1Hi543Uzszi8CvuKg7IEvZJYLKuA2rKdP7V/8TYAD8QKJYDQplbmRzdHJlYW0NZW5k b2JqDTE1IDAgb2JqDTw8L0NvbnRlbnRzIDE2IDAgUi9Dcm9wQm94WzAuMCAwLjAgNTk1LjMy IDg0Mi4wNF0vTWVkaWFCb3hbMC4wIDAuMCA1OTUuMzIgODQyLjA0XS9QYXJlbnQgMjA4NSAw IFIvUmVzb3VyY2VzPDwvQ29sb3JTcGFjZTw8L0NTMCAyMTAyIDAgUj4+L0ZvbnQ8PC9UVDAg MjEwNCAwIFIvVFQxIDIxMDYgMCBSL1RUMiA1OCAwIFI+Pj4+L1JvdGF0ZSAwL1N0cnVjdFBh cmVudHMgNzcvVGFicy9TL1R5cGUvUGFnZT4+DWVuZG9iag0xNiAwIG9iag08PC9GaWx0ZXIv RmxhdGVEZWNvZGUvTGVuZ3RoIDgzMzY+PnN0cmVhbQ0KSIm0V0tz2zgSvutX4EhOjWg8CBBM TU2VX5nJlu04Nnf34MxBaysZbyV21lY2s/9+u4EmCZGAJEvWRRLVwNfPr7t51EwODp8W959m twv2yy8Hh4vF7PbP+R27OWgev7E/Do6OHv9iN5LboixZZUVhtGbK1oUpbc0srwquawUHr7// a/G/b3N28Pt8djd/YgeNe7qcfb5/mC3uHx/Yr78enRyzycHxNWe3z4wz9nz7MDloGs4Eaz5N przgXLLmltGPH6wuasOmHM66X7KyRWVYVZuiBvnXyU12mcuizGaf86mG7znL/2j+NpGFqTRc au4mWany5t8T7mARUhRCkoihZEmrUHhkKnhhwc0pnNUVHr3JTp2eJp+KqjDZtXt6l+MJgBGi qLOrfCrh6ztaorMvXjZ/Jumj//tTPjWFypg3+ykX8PnoQHV2O7/zh757Z55yNMRk859Jj2bw QxYyO8ylgK9v/jii6OzeHyK9THI6KyoXkiAAVVELE4bg9BzTkiiDo8fF4vFrXwkAakqmdMFL BYUAhmIhlLaQdV2FdfD28XGxsg6aRsQSL3wKqqKsSzatQBEkbG0OTnz073MFT08+yvPbfGrh cQFn8G8v/C/8CXnBT/YPwIBzdP7ZH7/HL8jYA1MuhiqrfnYIMmOHTuk3d6FsT35xuExSxHks 5LySo5CfbkY+rXlRawUoVWFNJZi2YKapKmaVKax9Cfn+M9El1AzaUkLcjGC2lAVXlj3NJ/9k D5OjZoLFLzw5gXpTWXnqERW1gSSVrWrgIDnUTD68HN2nO8x7UmFlNP7hSH8FlFFAfYzydoqT WoCsZjevOqemm3jFVeGj+GYnhapTKFcrNFA71Drf5RJiyKF3XOVlxs5yJBL+eQyPp05wcZ2X RYV/gujiN3gADuwQ9jDfawwtq7LL98kp5Bsof3yGeT8E0yy22xKo2Tg7oQvI7D3+A2aytzm2 Tfcos6tz/K6hXbx+tQhof9AMw3JxxP6ACAeXyOnz43cnoKfveTTs4H6l2lBY1yRKhHTDzv/U vkIq90UZg6Z16WNxxdzTxdv3+Fw5PyWYA+GBdiOzxolJeMGu/S1snjA8/SGMHgYFO6uTnrvW KtrHi4Zhg9Mt5AU+ldkJOwNsCEV2fOpansA6cTe8Sb/hg6VCAeu1aasTf/1gkFAyA+5LzNUx PWN+8eohZlei5sZ5pRAZJBodghvg0aDF4kASVbTF9nkQbR5cgkOaxrYNLXHLqKBUVMcYHOWX ORp0xX6ngjvD0aOdT8L55MUH7jCjQ1cQFGn97C59LN1pD+mLEy2RbVFIZxKcgZbk3bpx0VCW 6h3j/t6BCkSTCrV9zHKs1TL7KKXqQAdbFeiXdYtJg3NOo+6WFogZDTO/oswe/KqxaFPKu5Ry 4yF1ZSn6oLr8mC9vXUAnWBfC7DSTNr4wPIFaoA1WO1Fwx8JPP/n8LfNIjneHYc6A0LioQtJk wEsqhRKq2MIk4XgGPqygT9S4Xoqrp5eW0EVVXYdyDQNRmOR1FJuyFUNauVq+DvgmrX2NmExX bi/2/0M9QIdbupwQBwFW/Z5A/kKZAXItCiVq7EvgQ98kI4tbnENQ8sZ6Dp3NP8+o1mhvQipg h559hVIscYt/E/bqTQwZaBW8dg53apfbc+Bw2TqMmoSqsfxIlcK3DDNSBaUno6UnSrDdKy3L 0QqxK3aN6doPtgbymn1hQyL2BG3KXUMyQqxd7xgjDqtGh1WDzMY57VXh/liu09R2qUR9fmj5 7CE9YTvIns8JcWCoGfEZB4psaeSMSVvpuQsvPrEdJ9BSxUjkFVHkVytqmbNek40F3mvygV/j EcU9oaiPuyhs0GR9WNExSTLnlq4DaZeT2FWC9YZSvng76bqrCXHgfj1MpwE7pB9HWHuaNPbc 6bfNzZYdLhHCNerjdp/GFcy4LRACDm8HjevXOmMnftXp5W6z8RvNGR26dkfYuKG/nulC8yXD 3+JGU3b7P6MdldY0b96xN73dwryVXoTrK/rN6DGEE7hmb+0KeqA0jUv8MXJFVrgoLXmDO5/m frdWpd/5tHQb5NaGDLQqjkXbK83eBJ10R2TtlqIeum/SbcVxXK8lulSO1r9wd+d98RPzyShq uQObEtQHS5RJU58giYR6SO+UOLRTjEhqBR7sV5fKbLFDGUsvgRd+Ye+3JTZ7uGONe3XT2b3b qRZ+iccFS0bXqdU2DQkGyyIcJguSzVnIyBwgRf0EXlK0bpkyVuGFxHTfGtstU/vB9svUnrBx mdoPtF+mdsGOL1MRxFHZqMhQJ13dNrVKFVE7Wp4drz1etyt5vJ7XCXFoZjnitXHNYCNep0eu MZYidJOdeGrPv82e8qkBbhOPO6o/0B8xRq+0ZvSCZAPF6dToGKO9om0ZDVqh0lIlti22Z/Re sInR+8F2jN4LNDF6B+wEo8eIo7IxMUabcFhvxuhEhQakTmzpKEnu6LFrBGjC8T7uEglx6Ho1 6hJa7NwitKKQ3+CSDY3g7s41CJXNn/OphYaAX9GukNY+UFUDbqApnVwb6wlabN0QQKUc7oY7 Avtu8PrA1Ar2AOz6wOvjUhPYFjjRAcZwoyKpYx0AFL2I/oli7OhvNML0VBZLLcBLwy4gBmyO XydwLdJ9ICYLvJd81AQgArYfzgpR0u570qMXqxduKWJU9KrajA5UrWWjqpN1si2wZ+PrAxMb 9wDs2Pj6uMTGbYETbBzAjYpExqjoFREb15QjsTFRjx0bNUfvEvPYC9MjOX6ZkL2xxLjW2P5u QhzGQI0IKcH1necyLOWC5nIDi3lV6Gz+JVcwj+ff/nyEfySM6Id5bC6v0j9a1iV+9drSuS5j DcGpwqK24867th9IVdj06NgS2neEfUBTT9gLtOsK+0CmvrA9dKIzjAFHBbP0gidr68saVcHw jUxqRw0RYYTiZaHkUpGGXmwKvZJ1ijvvQ9q9zacaWDf7a7T/bqBxCC9r12424NnSC46CbqBb SgurkDcbJ1/pypM7mvzdoI3aE651M2Qf0JXyxb4P6J1wh2iWJsB6ilWx+etVvWQZTlTlh2BI KpMav15I3aOXyrputwG6OxDq7i4wiIdX25jF1Sp/vNULIRUiNvbjt8kjF6PkDh6XhoG3o6HP nbpVU1+3/Uenpz63lPOb7DSHWyb7mk8lDv9ZPoVXo+z+S2zir1Q+0GS5v2LXVlcdm/g8TPeL Rz5oNWVyDm2L7YtpL9g09PeD7ab+XqBp7O+AnZj7Y8Rh2Sgem/u8Zfo2gz+o1djgX4VN0Lds hRI/+QPq/f3qLJdFYuiv0jaEVhJPbcA1JWJTn3ctbpuxH0/+jtg49/cD7Af/XrBp8u8Hezfg xOzfgGYyNvtJ10uGf6I4PwSjEpaDfo6KpenvpcH0F8sznOTgvAnFwaSNgZNqHozwyJhOiMMg qeGc1rXGAJfWogYXiHSEXC50XaFvK3NRRnJBmnwu1ijyqUhp6lLBNaYqsYd54WgP66rQi7tE DEIZRfZqyREvbB3priakYXT0KAmwg4C/lAShSWHPNe65tty8Y69tlCJr0BTXu9/loqizy1wX Krti/ukCXuUgCtn7fAqbbnZ1DrsUsDE7zCFVMmvyKZSPpqt06ILBvxJ+XDsoOCMNnOmujJaw TZ1yvpTtLlhGnBKVwByGXp2ek/7TCzSvfrkBAx0SyAMZ73UErasNqtshBEw6tAk7KGb2p3H1 mz6/be17U6gPrbakLX6wBOo0WfwESWzXwwpOiTH0gandC1NbUS4L6YVcw1iSbWFNoVllDyyH BTqb3eZTC4/4lT0+5VPoRdndzNWMzB5IOscigq08+4EFWGf3ObytZAuP9CcdZi6VXYXboqo1 WNHcgdJjf+8LwtXZ7Psz4forzny8A6jQ6twdH70l94zD5YX6P+tVshxFkkTv+oo8ZrWhUmVE 5NZzkmmZZkymFhRmHMRFUiWIQZ1VA2iAv29fY8mlJJi51JIRGb6E+/P3IHw51y3ZhwKjqfLt e/hryRdwqfYedrx8BmzIUZugElnDP6vpkBde0vsF9B2uvWavOVP8aCvBPlAGOA+QJIsd9mNR VHQU2opM08mn8L/MO8ozv3wj2eZk27z/qq7QxfQbeX7Ej/Vy+Hi0bNSIZFMsHVOU5xIlfJeE CbTzQr6PKRjNBOdlvThs4XU55b4Te524cSuRY5Ti40e+zl6zDi6W8BilHsgkcMtFRUGclY6o ygydKGu+w/hWKroV528lKTFIlU8R+xKyQJfOfyEbZhW/rBFkp3yfeAm0Y3APvez7KkXwzhhD OzC/eSbrJt9EN1I0eHDSD94+J5kuwOnXS/H1GRfhzWu0O/kmf13ekVtdP8jJbSddxk51viU0 rPsb/TVMb5epe1fkiNT/u5wTJGX2biGFuPkYsiNAIaa37JpWcKaFwtVw7W8sXI3erLqmuHQf DtFKMgRzK19DpwHU0rZVpHsvZ24lcVqfapPD2PaZJB4f+8VOd48SzVfXa1V036lK/OHi9o+F od687fQ938i8tcwVbf1WvQ4GZe9ApuWBi9wnZ+zxJUesZZTU1gUnjpC01HFNKcw/9oixEfya gNkT+CuJX1roZcFf7gDwTVpJIkkTq/im5bbNhn3Mb3c3VDa6FookkxPOkmZJkWJhYL7nb4FV VIpDn+hCQvRKVioiK0idVjgqIyiCw6SRyR/MqqFywbLBNmgI1gz1AHb+C97JmLxGz1okV0Ju Tvnr+HXyl8+BG9RDeLhSydDQJRoHU5j/HrGJLf/7zD4w/qq9sxM++Q/+IusNB2Nw9MJYAi8u 8IRgbX1FP2r/Nu5HmNIKKvllikAtSYL+xLIr8ss4IEcBpfPcwK72pwY6l8xGcaGPKsnkCmWC bArHOhEVY+Lxq80pQzVBGcMogxijSYlwxIXxn6zF024vnIxoEU9AyElpk6rjQqa3Te7BuVN4 CMAziTjLQc7rZQskOkr5iOc2k+RR3OPXD5HLVuye9hv0YTRAG5mfJpqffhD7UboZkZcwuOOB 2XBwv0ZbwnRIJZfzkouA6xoK9Y6A4Z5uFDIL/xp61iBYkINbKp8ePnUd8Ji4JT36zo8UyqPN DwvsBWBHNbbEQv0pxB9/P/nveCnBU1Mvi6rde2GtXlg4zxQoe0Ck1GbwIggOURorE6REDV61 bSo15tYj027lTZ+sV9nJGvzM1ieXkF8wDA2e/QvkUobzAMMpQf+sChQtd38d4KO/DjDRBn49 yK9D/no4WIWf9wdr0EdjSVVVaMW1cOJYUMVeFkG51cDE4Z2mJMlWoKAE+Nuj2yDyEo1YFkjz RowaQanaWMy/mHEgsoqRnYnuGphuWrwnb/paWglH/Yi77qSDtjuduYyJ3dcBHGVb5TvhkCzo GuILCbFz3ID7aR1ZUNW2Sfl3H49q5T0R0iqdCzxzM000f56xiR8RghaKoIYQtDBz1M0pkNoE SOHmn3m/g8t0LZzsnlNINi6k0kITu6hg8XOvodIhOM8ZeiXdLwdyd+uBvvdnVmMvXegpeAfa yNWAOS6Di7Blm0GGvY8JALjGoYVfAIBXzzA1CxI1WN2f9jJOu8AE2xGY2GtGYKKunsKiagIm 2IyWkf01mFDTMUz0Wz9zU8Qwc4hRDBHDTiKGws6UsIr1oMCGG8OGkHoEDbPymKG9+xzMkECC EnwWajxNzNQTZg4j1BBnxrpP6dc8XOy752EXr1rq+6cLqp6CC1+4CBf7DQlcTBvycMEHCiDY IVxMr8ZeNiO4qKirXNPg+QUU9z4n4SKhuyo8em8y2qlksCVJxhOGJBvTlnw2+ESJV08M6ZhZ jhwtV6N8uIpxmfNRIksKbgY+mEjVlZ3AA0kWfJXCG0SWXb1m5ZddeBWHj1UBnl3Kj7UsiH77 J6s5ZPe8T1QfnGKRJh8vQPsZaLeo4H8+JmMlJjMVUwEVZlwSFIpO23AYxrDqNA25/ZOODGwZ IL42TqAvglcHmlsQpeCUa6FnCr3f30blWEbEU4uRPZFi3O+IFiMY3deafKJUm54YinFmGS8g 8tSMRR/+AnSZLTDrMCAtMILYjIkcfSjMbhSoe3rcEbzm3xicmSHqWOGlE14S9Shw+6jkMiNx 1ubVEl8yeTExnsSgmDpLVCFzQXE4zK+Y92byd/uANtXJOxxUsBckXKVcMf8qpmFKYXtgW3QJ KdZZrHH4aeEfbI4SNgtDlQeRbKSBycaYlp4vDkuI41zikQgu5Ps4CfaM3lhzONl9JxZ0ht1K ojAksIFtI7f/Da4XGRDJzmsZjfK2sgt5+b8Ll2/pam/0PMibwUTRgV7ZAvSUZSxkJ6jNIRRt Cw2LsQAjI+Ob6Yx2nJmIJ/gBL/cmDEOciioOKvWDMhhyMkCRR1dyrkSfroHR3C3KJQqUFSS1 4zTwo0/0mW1ppYfPCtZLzPYt/eGF78NdJeaopmrClRcLrByoCXyTT9nQLlUkX2jbI63cUgeU cvTnBV407/5Ix/D5N/TG11lnxOQ3TZ+Ehkt4pJPfSob4uB3t2kkAjtJJYdyRGd50Gy3zIUAC JcuFZNkXRf47VkLIv0Uy28ZVMgJVr4/CeVDeKAS0ZqIXAS0FJqEhjHIUQ+QqgcmZ5dhwkDyJ oMH8/ZKgmRUrq6c0YunFSqIQZhFb1AnWM8K1wsM2EPqMWatnuf1IOAxYeAq2gCnCvufFAKEn 6wEresDkAusDRdB4dNko3qsuoEoCubKqFJxGouQmEgqEGHQ6CIRYtUzrBHwaCwWs6jmdoKfx RPHGZFc3FggSieoETdx3RniMK9JuKtP8VKARcNvxbPWHv1gUhYdu27YEopyeGENv+k2mJ/t4 NKU8IGVKyBdPjktOjdZLMmMuOJ7a30yCyzsFbQ1+QkRm48ls/WR+C+zOgu3tgpLGV/GJz9Sx ranmLRrXCyYG2To5nZ2mgJr8lOM6jitVnmU3OpFNmMjxPLVKUP7gLznyJVs94X+SomTIpMzd 4U29+Q3uZn1FiWw8sRb6fY7Q6vif8SwdaS/w7VKf/8ns/HIwbAHU2nZ22FoCCSiYwqYjfqPU qVdmw8/fJ/9CJ8nd698nWrHgVqQdv96MhRk3o1LMTE7lu5c9Nx7Vxj3JnEoD6KkZ4fmLQTpN tawqO5vPcpTOQEu0kRfwVWuVdRHgYctDx0JMASlWOE17vY0jfqyMmpenWOKwzIwlLncIVL1t GkKEsmYHj89ZBJ4nWvAC3TNUzCV2uhbb2RoJKy59xgQRPnFUShoDaaLKBgSqPX18lxd0ee8W kYuSO1M0uB+AxJa6f6dQspME3Chx3Xi+t2VA/KD8OgysebJqkaxiIqUKI8JKZZ2063U+pP+k P0TFyNzKHj2N7/Qah5MxGXRHCXLdd9Gw870wP0IbmZ/O+yhjKMzpTiLWUufKQPzXq2op4YAa zapOSoJHS78Jogy/Bx2mgROhFE59H1KEIo7oJ2cDeQHZbZdVWaRY08tOFVaRarSgGiO5WJCp lpyhKwmCEb3wgpHWbh6/yIt4eiV+e7Wo5FlxhbeFmUR/pyVjCgnQF9aNIVY6ryiMYELtMUF6 7Oo1wjxcytUWHbfoeLGiQitEZ5qlyqcEZvjm3LIufCr/EXMLSKaWw4YD4dpxufG8ix4nWihR S5xRKXZPM3ay58fCNJG15BiPeHzhwFr/c1AbFJHWlcitXQXz3GQAC8Cs32Y9clcv/CYJq3X0 RZzVXzJB5mPaN9WS01CosE16boJ7eNI6fdOc0+nJJAnmhyg1I4SgOv6h8b96VgZ8QQ1SYEAK VS7KAdQwq4H/8Vxn0tymKoNkSSw1KpUasyeWrlg6p/JiSnyJn6yu2E2vvCbXBj7U6sPQssG4 rbVjw/HrzVi4NQUateD5/0u7tRY/rS2mtNsgnlYdSrWbsRPZLVbAAjXGoN3uuesY3idHHsw6 nnQw56hMu+yxV9rVyWalSJ+wePOUzn3IYhvIX4oghjZdRs8fb//N2MCUZqAOY4Up40UO38So EURV2qFBTvnn2y9+LKA/OoG27E3XcSAZ4wSfyoOk1wkuE1GZQ5eOfbkQgG6ajZj20yAyt6I/ l8WqUQhWbkJm2OJOnnmiIdHojOZTjt68wVJ8835AoIhNYlMUgUDdEYG6J3Tu+HB81IAkws/s lla2hO7fcZ2IEFA74O5A3XDPjhZ3tPFh4Qi48ZOP5j230WonnG2pzhbibBiBILtKE49AKvao 0quVVrqBgOo6k5RupmECFA4wVoYCmDTtAClmlv9mvWp647aB6L2/Qkc5rRVR/JDUm9s6QQGj aOD2lFzkeBEXCLRGki3a/PoOOTP8EqmN05zWFiXOcPjmzXtxPLFtdQ3dYy/YfJs+N6YDlpL9 YDM+0+hm2DY6/GGG+sjrVddPWasfcCpXvIMpWAevSlMru+cdbIQrayZH6wk0vOt+NI/DG/q9 SibmtRuDaLcoNvcVqgQwV8coN+N6w+nkw+OSqHMSLWPUa/Z9zzgXsJvFO07ZQ/LuA/273B2D 0ud34jlOqpoPfJNodCKKj6GRWU69K94A6k3q9eBI3eMgzD2tiEArVnL/4ho75ezlI5Ik3kk4 OmbJ8otty6FxfrVlm0SYSM60+uIyzXn1zQw64+xwlxK0Px5lbtd3/CZ/GLwtr/DZeZqgE+BR c19RUtviO4NF5XdVhOBQc6FqsE95NbYqAP6G4LyuWCbQwKmEl3BiZYi/nLoCPzrNu4QmuaPH blKy8fapxGfD5H6IsOYOOD7ms9pyxiGqyCFyLCkxp4eGUdu9cg55G6AVruqDKwlYisnblFM8 yLOS/hDsBjfZkoCP7i1Md8v7AFyg7vBZoCd+8sh6hJU68JWdPr4D/PRugnP7hJ6OpUIsVjYt 7yDE0Ocd2GxiFB21sFtdm6hWMoL5gdM6eNoNR+I2S51BEdoshQp8oip8Ahu7TR7SstO3Gddc 4r1eepC+bu8OzTva6Pi3ozuqwXrwmd+500l/axvTxJnSA8sgJbNF88OPKKTXLmtCoaEXxk3P pRLeaD/XbW+N1sYYaMBGTZPtIdVbBxLcT9IqRYdJraJm66OSVjl46AnLVrHCtpRinzFz3TRk S4lpfscfGodHuqI1r2CM1AiLMeCbhwUn2Kb4HnvLSgzv5fojlTqagVFLHu5zIqf86Azv3W58 qSfS2YL+13nj2aHLiLnGc3MFb12RSC+4XtxwP1XqSFDyQt3NdgIeIoUM75fcenbFapKdia54 3+gaUzOZaG8DqxapHhNDLvd5BaqvLMfxxw3EpbE/dFjRW2FYPSzhGUZaQZXGYSYOY6uqIQQc iiKBwIJpcy4QlaMc6RXXA3fEA/sdQz0qy3Gi86Yeg3C3TvUAiRqnGdyUbX6peU7qevMPTnK7 5r+9uJRW4QFYpQK0vry4VBaKv0FH9e0VIFtb9/QnLBsLYshoBvG7BehujlkawipaFeXha/nq O05RW+OindkRXKZnm1sd+1AsvlPMhO50PxG+U0hE7dwp7kiXxjuGO60sp202iifLmX72cuYn pA2eTB8tYRB58Fhbc+XO0/sB6XIrEFQQCMRZFYXgTUgqjvxkvsXsWAXb37pWGFgrAKHepDqB 1/eUsBv6jrBjvSALKjg9i/JnybQcmQseWqcmM2c8XA44GILhjCQ4iDGfRthXmLArl8rrFzfl +Gk+7Pg5yxozWJT88QyQsJyyl/l43sF45dmmttJvah/eJSM53Iize5vZ6z6JTKCbVsGSOAe1 hMrYrKEW8zSxtl7W++fZdeCmXi8Lrwzgb+jK9sqJCaelVEuSimB6Q9nShEVtwkP42n13m6ut 3mnBSG0lbYgF7jupZk6Zy1YoycAlYWg8chEykOz7NDqu3X7htr3n4xPWj7bxZi/KGMNcNjjW 3G46LdrYSyOLt6CIEixwp+WoIzFt956VU9NKJ7V5qAi6hDpy3QvSTMo9qzkOzJQKul7AbOmk TaXsNcXUZwpDJOxcXY8jynzkCgNHgMkD80HYHzunnq6yhZlAiDkC/w2bZ/F3FfmF0NJcu7+s h/rsVGxQr+QVSZl79v1xO4z3s8+H8WhcHTnXqoIaVaygBEz6aeJQEgLDTZ0LNasvDKULYo1P hYN9PxIN9kokHuy0I01u3jFAp7IcJ2o2yNEir734GuhoydBhYkuoEsm3jCKikghMtr0/24Hj G5/AJNm+HpmASnDaP1J+ya7mPv/6HY8lOGGoGE57oQhP52OVxD8fK+BpJxQDqhwqAEoHsum9 EvS94lbt4YZxjtY93opf09aYbQTGjOdq63EZNtZCyG/Cc9LzHOpKkgaZrmPhRUKCFBMM0xLm dhPLcdBb/e6zqMJg6kuQk1/BYOdDiRLi5NMZrBzJA073e4DD1Trgyl/T1nKfHCvLcQ2GDdzA HoVbBRW5A7ehDjegQ8P2dfBqyBshD6wTcVwRYLupZHHnyS77uPVblyWAYSQC2JlIDLDzoVQJ YHQoB7AzkRhg5UgeYDLjJJEiTG4oLaOlyve0O+aLz32+4ePKclwGvcFYL+1HChJ0EfaLgIDq 9blqm1K1MRK185lAVO1yJF9taKSddsbVejuXv6atMVnqV7EpdWU5rsGYl3p0WFUznFDMzTDb ojxleggzuO5SXT9tx8eB+nlBT9Ww2fpEioe7e20yv7p1JcKKIQ1Wh+V3c396j7LoX5BFjXuX WGTluPe879ErbZxf14nfvHV+89cw2+AWZtqM+ccOQm8oP2zJaL+QWdXkLO3d+qq1lwSlL93v PM/K2VgkRRfz8uJytHeysm5cqCjv/+dplBzS02SNAV/EGPRCzh1C8SFU4RBmtmeYhk7TsLi2 VzZ3pr2F23KaObOm8GpvyJq6ovadlGPsVQuY7qEZ6Z3XrdE91YXFDqH2eGLYHpr7A2KTZNHN 6S3Cz+Hx6OvqXqY30zwxOSHizKI02hf4wAgVH6aYuz/f67Y3M8UG6Ui54Xw9PtLCAyW5NFfg ULupXQnU9PyRrYfNfkga8WdY0mBADv+UTgSVGaWmbN8Mg8ETaK2eUv0XF5caOpIRurL+bJ6z SaI3FpdER1eECHaMf/u4rAFsXi6bbug1R/keTjW2UrKVetNivP7NBf7RQOfQomwM/aUbNfIX wmTHB1AOCc5cNtAEyN3YUDQGuZ2Y2EfZTRXOry3ZHrVL3KKbSVIJyKulbffW/hNgALHBU5UN CmVuZHN0cmVhbQ1lbmRvYmoNMTcgMCBvYmoNPDwvQ29udGVudHMgMTggMCBSL0Nyb3BCb3hb MC4wIDAuMCA4NDIuMDQgNTk1LjMyXS9NZWRpYUJveFswLjAgMC4wIDg0Mi4wNCA1OTUuMzJd L1BhcmVudCAyMDg1IDAgUi9SZXNvdXJjZXM8PC9Db2xvclNwYWNlPDwvQ1MwIDIxMDIgMCBS L0NTMSA2MCAwIFI+Pi9Gb250PDwvVFQwIDIxMDQgMCBSL1RUMSAyMTA2IDAgUi9UVDIgNTgg MCBSPj4+Pi9Sb3RhdGUgMC9TdHJ1Y3RQYXJlbnRzIDc4L1RhYnMvUy9UeXBlL1BhZ2U+Pg1l bmRvYmoNMTggMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAxMzE4Nz4+c3Ry ZWFtDQpIiaxX23LbRhJ911fMI+AyIcwVmKpUqiTZLnsrlmWJa++WkgeaomwmEqlIVBL//Z7u mQFBECAl174QAKdnpvv06dvx+ODw6H41v55MV+Knnw6PVqvJ9NvsSlwejpd34rfD4+PlP+JS a1m4WlhtCq+tsFIVdV17YV1ZaO01BC8ev6y+383E4dvZ5Gp2Lw7H/HU2+TpfTFbz5UL8/PPx qxNxcHhyUYrpgyiFeJguDg7H41JIMb4+GJVFWSoxnor48rfwhXdiVEKW3wz+tbYssHZ7cJmd 5aow2eRrPrJ4zkT+2/hfB6pwlcWG8dVBZkw+/v2g5CPpOFlIFZcErWzcKDWJjGRZ1NbiWUhb kehl9prvGecjWRU2u8CXzt7lJIFjpCx8dp6PFB6PpInNbsLa7CGuLsPf1/nIYacIat/nEr/L eOh0dhWEHoMx9zkp4rLZy3iPFXhRhcqOciXxuEtydMo8CMV7hSqjrKwYkhYAVeGla0Pw+j25 ZIACx8vVannbYoGF2wV+S6OFLWtwAt+mLpT3dZsDb5bL1U4OjMeyz+kyuKAqjDdiRJ42cr8P XgX057nG131AeTbNR3W2goQGEGHpL/pr9kC/4hOfMIvS9B8E5vSAvxZCM4I6q17GE8QRb7jj DSZJ3vC5QkXpsg/wslLbgJ8R0u9P3r3C0hqTGAhAoqoSJIaPMYA8BEJ4VV5xQIJfxoRoABom OzvPDWnEHwu8q+x6yQ8oTiu3k7wEgCsYoJmatBYExcUqLs74cRseYXElyGIX6KfxJ04z4QEY WfCfnBgrOgj0Wy2T1Z0It65wRhjvQ4y3Nr8eH1BkypA1tOZ8QOJCSY9fXReVE/ezg+sX7YtU ukj7QmNHVdEOUNcrIS3lg7DlGMeHo5mRLiUFTkN1gz6/Wd5tKl9YRZQl9C9iwIKhFYGEtewU /1GQgp+6DKHr8Xn+ikglCatxXoPZtLPKTt6evov/nzQbDMH7C3HOJ2ShnSXtRvHtb4Hbz16f 5Hz/u1zSljdMA5xXhuPoP5xWcgxJn1Y+5HTwadi6Pl8253NAqrKQ0kcSL+87ObVNbihdmw22 b3ot+MDV9IhOgKdNrw+kSSFge3wgYaZB7qlgUpmcQFCCBtn4gl8cZwhPpn1GirBAdHnP8Syz Pxh1xZHCIkgVnqlM/+vstkPjinJcx7IuqXXi2rbJ1hPVdpnctc9o4rNxyHCuFQrx1tYNyuoC QMAIVVP8GFG5oqy3Q8Ek9RS0gYCxiq9AUjfC94VCDxc6airHechYg0dywxnlFse1CRkGKVM6 Ts9gISoamEmJ2cJP8MYmylgqXR/KbUThH+S8tcFWDVlsm+BHHCING1sVmh6UPHq9sN9iDWNq dqh2wdyjXFNJQEWWZNrdDRlqk71TtneC3ypaHRdQZdj6TohETVFU2UWDmm6kKXrZ1lQr4o5B GZVNnjpdUoIqumWqsL7ah7tDDDyFZ65BvVIcow3qzLMB1F2Deq8tle6gfsadz2Nusy+5KrOb +TT3DLRnoDmlzpe0tOgYawuctiNJRa0bDwxp/QQP1KFS/J88YJQmZaILakMfAz6okg+M4sim AIUPKkM7QbEfor7BFEAPOH/tBQ71Nr1DgC/CxyFnV4sYsdQ23IXgcE8OjjVASFnS7knAdU8C TgDAkQAqAPCDJDQ2PEzVcueYKDZfhRJ6w43QrKO6wq5e1Vtq2lAaom9R1ZBVB3zrk5UW+UZx OYWBrhSqSnY9y61WcUtJpVRGt56gL4ATHtmLjqcR6rC/54acGVwzajqRpkbjnDR7XYapx2fX fVkuag48MT+4ckd8mY0+eEtzxb7FFOrjTHhPhMTs9ZV4xEWHivvDinvTuDihryqtkZ49OcJU 9T6XoQHkosJNKEgBHQa6UNl0+ba2GJhK7gZ0RXG0jsaDP3ef+VksntWnOmsJZSSh5Nc3oZP8 9zk1nm9fx571XKTG8/QN5aYPYVQ4p1bSZu8BWuz8PbePdZbEo+Bp8vDH51nQUbeyinnY6DsY 57IZHz4GQBECrsFTUkfQSya7q6N0MpCpioH9IZBl9S3wmBpDZDAao1qdsmsFuTeJ+picFKW0 29Blf0EQgZJcme7zCtMmr4olitd1qFQiJpBvnE0euJSJHNTQlGKlZvwNLAv55nVOupyShjr8 I94Qmz0lWmpG3rOH4Klf+O7/UgumspecnsT8OlcU1iIUywXtrBHc1jTBzZHQmc0qz71oBCh7 Qc7putDbFoab/sPIRrzwTHe03hrtdGo6W4vwYFjkyTYt0rAXFmnaQ3luVl/0jIXhjii5voQ6 ZWpWw7JEbKzXynUzTc1lo6Xp7I+LxDN6b6mhAF9dp1WEHuptv5YtSZwfJFtQxP620RJJe0tP EhoGs1nsUVNT5JqWmkNatgSDlhtKohksd0OpneNupRfK1mKfjohn9SQoW5I9UKaGaSeUJOSG oFwv9qhpEEVlY0StCa5+NVuSuCRIri9JtX8HmCSypm4HzNZij5ZWsmRcdb6R2dKyJYnzg2Tr lpjYd4JJQqYeQrO12qdoXSYYKM6No+sGNF2LUqAH0S1lajREboiBrcWQcsxmxmlqWDCCSqCR m3kgLZuN1Rh9A3sT8fv3RroN7E1+7t+bwB3YnOzt37ydQ0Mjin4PlmrWeburUc2kx1wxRlH8 hWq/v6XrHTFKTivGtCeMet26LUNb93tOlXE2DY2c4BaOJLK+ZjMqB7tw9A7lhrpMlF2afWyr 6b8ISoWucrKg66+CZpOo6BXq+S5tFKOctJHbDUtXiZpUpjyCysE6LOKFt9zFYeroTkwKonJP DxtS0ZOcrZOz41CLoKsZz7o1UKEB3D5Srs/cbmGlj3RQfU1ZuqtuGvzPwBf0JSag7aHJpM7+ oAZWGfbICE0rqAFUgJVdu+Bj0htdYuUavXuQ3z8xyZLHSANfujpwIlveE8Rr9HuRb+NpeobV qKKqqYXtQPu80ciXHMWAyrqnc3aTQAASXt80Y1vZ4OhGWaSdHyNCM8vQSw/kknsmJSnFsEGn SxpWivbw8Ywru+eDNpTym/M3HffxQCJ/NNZWJSXioUixybOSUmyKlPaYC1V3ndcDzk5nS8SH dRth8i4MtzfpgYE2eySfPwQCcLachPd5EPpr1gqWqHoIFla9J1LWQ9VoUDWOkY1QYSrShXeY RsNcpbJpGK/mcSS9Ti/THMMPUjzHddwyCVvuw/S54vQPGl/3pdtoR4iotgueVZYkChLV1lY4 Bei+hQiaiYehuKIP21sJomqBAUG1dfA8kx59uVMaTYWrFTG/ZqzkrAj4fw1qxi/BCaJqqmpk xZIKGVv1a94OtacruE4oXQV9mMcGY04hz0r1tPLkUtCp0nO9fkqa72OsAtHKLmM/heQ5Y48+ MDQ247ZjMVToox57c3mT+kZDuU9JVcjNZA5Pcnh8ytGcZMV/cukQPe0nHtFhh+OxRDkaX2+k dmn8nt4gNfxPSXlVQt/WNrVajpvtXpuhUhlVSsV2iMU4kLXY6L+OcihiKBvAWXV2d0NMtkRZ wzmD/pzgt0KY2sBlWlguRE6t0mkOysF/RafgVYXy+1BxtmzVmN2o1AkVh8mUe499wHBHlDKR 6oHDoX+vXAeOM+qCYOYj4+GzL8BD+pDZ+TnlbKo5c1LztCICm7gMIBZxozglnpteZPQ+ZCoC tUlosnTcbw9A4xM0lQoDUYAG05gdgGZ/W1ZpGdqyNjYnuSPPPy6ICVz3EE0++94xEEXGb7Rs 69pGLuHrgBw0ZZnLrCk6sQzFOvaVCtQ8tuQPoaitokisW6tU2+IRi44qcHD5P96rZceO44bu 9RV3ecfAXNe7q5eCogQOEEfjkVfyZhLJcQBHjiML+f2Q9WR3ka32zfTdzEhzmo8qkoenWPXY X6XalBeewrVUn6xzfjri8yJLH9U3yvjAy276l0WZqPYwcOtQ9ZOG2dCxGqhIsJaHNUIa/cOc Rv5wmYW2huSa4P4NAW1oYI1U9lMG85jyefQPIUT7cJmHUTapTzYPAjJ51B325QshX8o3YrzF LbjMpPUADrfYICEPGmuJ79EgWXoV055mLXFLuCialh1CblcTGMmUpOTiCut3DqbWEBTJxlBL vQJ7wlp57JMORzOR1lvfoSVLLx+nc1hpfQGsDdlgqlZamwhoqSuPlsIKcWtledtSWsG21pa3 rcUVjEv5BLSUiPdca8CjwPpkWRhVl0WXMl+U7DZlbmeNayVtgiZ7L1m+nb4HlRTOf7mLwM1v Ucs9rpgYBERYMjHSMM1M18zucxpZx6R89AUXysVHkxfG6/KEgUhanx/hgaZxIZ3epm0wnx+z iBwPBr/nE2wOVGyYiTYeAnvMp6cq5GdofqtHJKzaMGGG8DNlGMoF6XJB9bcZdqVyfvNabA3L iFvfL/Vd1a/2DmgCHiK4NP2dwWu6qCpe1Vq82kG8ruO7LzRMvgA4h62JvMwC/2+olDCl92J0 czFhO7qv0aF/ppDq6Dc+D3u6e7rA7d03V6mdMOE3IG/MOctara2eJyNmTuK/Xg5Yk+84eC2L 1UQ5k95RTqn6XHss6uTXRDJAfTbMOMPRIePENAn9OdgPBQsXBOA4s846lH89wrtzroc///Th /eefs176Z5FN/7jTqPBPv/wIys71N9jDMpj0zivHoQzxqQRLgeL5l9+S49/yVHx4vxqD833T iSWQnkpfGd904r/u7oEHwdn7DyAVUfZ9KOd46o4TMeQDtHTvsxscfOuWvj485aN/Ks36uTjO f81fTecPH3P+n8SGCImdGKVJeyOyvdHU8b34cINklrV8/eZVfrUSpgu1RIkbVOO5P6B0/2vW zd8CRU7n714W2fwq/febdPZw/vZP6DMSn3pBnu0C0ePjgoNfVup9nf8+FSdfv3rUp79/OuFR ijajO0GHUtzzD2e8NPhc5c+Ht63VdnW9jG/vpvSIjAqb3+APOGZehEM12rvp17Scce3jBkd9 5GD91pdTGbkxNX60ffSwijF+fjaJ3WDbKn6ADHD/42P0mgy+uMCDhyExi7QaTePm9pX1zOTU 13mUlOokcE166welMkk67bkYTS+mCtAUGfUn1Omqi2GZazJF7zE38/nTnYVLKdSCvDCdnyhx RniGkjv6fzJdp+WndcGW1/WwdmWzMp1QcVcNr41uQjyD0RVQo0LOmEPOLmD6c8O+emF9WiIZ hNmCFiAoKHgTxaAdZRwDOAUR9BcaNCxAfBmkirWoNChBGcf4PrVGRh1JCoQJwfDFMQUpKkEZ v/gYNWJOBholRPG4+JgpKXOB/daBEBUrYIATelbetW9K5aH1lFxcAnNtg30r3ofVhoQF7xSD 99ckHpegnN8wXTbAmB9J/HFRdDn5uARmfBfFJqL+0gJD3+vFDOGj0YuNRVDGs1dzUl8CqhXJ GY4f4wKGlWdlyiAw57vsSwGNmoz+cpBwkWyQBoEZx3ULSajp9R/Oi+y8bGgal6CMZ0TlMkzw RquQSqqbcpmZKoUyYQnK9Wyi7bRO8kUllU3JlcUqBzaQYJWpWKyQCYfVeWcD1rHkDOvksIa1 vTnD2oCsYW0TFqy15LzWC+cwKkHMoA3tnDpK0D6bahB0e9xWPJaRgjsD7hZ/NQt4DNwltZ9+ nuY5wlsXwCxzIqP6rjv6BG8KZMUvn94xeq/EFGTU/tNXgbc+/U9FwX18Or3Jcq9cwHd3Gt5y 8L9R2e3MaZ1B8HkC2Ht46FOuOx/C96sxZ0Ay57pRSwXJoDNgn/QRJKPOBCWzPpqSYWdMybSP pmTcOdP+PgO0NGKHCR0wxuTtko2tIShhizGrSvwZxMLPYVGfTifMRWJhS89UjjKOFlYAS2EJ SsBSWAHMheXBUlghaCksb1oKK5iWwvKmpbCCaamcgJba8I7L3fMgpRc/cnmcMWojtLKP95C5 nVNKm3wWODbfGXIvnfc83p3/eHfv4E36TSYwaFO4GsXx+HXHDhBqEVE++cQxeY7aWHPXyfEf EpczR09kPp8//pxJ/enje46+dyayjgozpeXjP/Q5dwJ/8xiZciewN4/1GR8wMuJjQDLhgyEZ 8NGQzPdgSMabMezSyYmszZsS6eEkzmYTKpSdMZGx+dtLhcxd0kWlXpRSQGsxO0zRWk4BLQXl 0VpSIXAtKm9cyyoY18LyxrW0gnEtnwDXGvG+axl4lFJKHNkbfkHWV7E3vEzhSJscNnPsvTPk fSbtL5J3S+Pd+c939/D68+c3J46xf0fcbe4MYcqlbhegdbmBK+KtnU8BX63E+f31vnecBTyl 1mrhrI46PN95JqCNyezpFqe4jZejPuPGW/ULMNz56d9PH7kltzP2OpCLeUXyJ65LLoLWkpYc izVerCCz5FisciKDNUbkAjY+ZAwbG3KGjQsZw8aErGHVlAiKS441bbqsmLJLjkuoLrmEyUuO vb1UyNwlwquEB2spO8q8SniwFJMFazX5oLWcrGmtJ29aC8qa1oryprVoPFoLwzquV8+ClDj0 uNdC+tXIKlvtWmuTxtvfJCrDrbUWEXIVA+5+krQs3p2/vwM2Oj/e3cfLBDlBgHPw1hgTuC23 K42Bo1XaOTuObtcc7VtMrQLWcvvsoVJ02KBoeng4N3T1dH65Juj9gQd+LqPJn/ahj7USCZoH yVgrkaJ5sI/1CJKxZoKSsR5NyVgzpmSsR1My1pxp149qg6p5Y6Io4NCVrA14aKRADmRc/rEm jGzk1pblGpvLFezDlnHzrLNsITCyUXBCWoSquMAIT2Lg3G+5l4U1woO13zrKrBEeLP3GgrXf +KC131jT2m+8ae031rT2G29aG4pHS8dU0LjVFglOACm1ub5FrEN3ekZWdKneoOnigl1eParT q0fglNPjq29fYDVP/z0h6ZhMOub09j9rfstOrE3/ocTzcFxMb7CpbxsypMa7acygUlPeNqZL Op+LCS7XH8dEEOPHw4r1vQ9jHuGWuZ7n50l9jhexEQ8LqpVJE37zsCFx3a3D6sxYNw/rkN12 dqXWMVH9jrYMvS01bCzUizn7vL+fJ3nIQ2yQ46I6k9bSzcMGgRKODevT4r19WJcc7+xLH4Xh Gfpy6n1pVO79NlXPlLtRs0yXhwXVdoMtj4s6bZDlYVFRv4k9eVxU/zuo0ph5L1VG0pIgtOcm PkAZ6fBMyXspnYdDwwaLv24fdrp9TGC/WR7A48K65HhnV05RENtDV87kfQPaxAeSvHkmSWy1 39Lhx4WdRSl+ZFh47Qb5QXdc2ElWScdFtVpUSWNfWuv5lbluS69IW4a8fJ59puxkNjTPgWGD qHmODBuVLFcOjOo29MqBYaMoWJi2nA1G3tOXuvelgzmf20zBOZ8pdweSQotseVhUkPiycjgu 6rQhHA6L6vTtQzpRNowN6TCm2I+YA2lJU1ty5cRrEMgn6z3WtTtBD6+XHmxvaj/NeFoLLy2Q G6B1nJ1PM45wv4B1nOhPNuhlFGZ0XI2C9xzgvYkKpcWBJbIKc9U9Bzgu6qSgUHGsq3tcVLi1 ePOooLqxVreOOl1uf9RJJ79XRx38+QvrbuhaT7t2Mlnt5EBaBWz65zjfZMJGKY8La5VcywOj uo1iHhg2plfIrcM6k14h14cdHIaLZ8+RmvfhBWxyvN2IIh8IPOpTigEOf3wBV49bHkDYMjPs B417DqGvXkSLFgtDhUokGXbQZRtq6PLFJqcRTQiorcmt3dwSrwQc3WpItsUMM1oS1Cibu4jz S8DRr1H+IqZrvE3KkXfbQcatdz0mrCG78IsvMCXeLkFHx1brXPDieOk3hHr5Y74EZNzCX7WY LwohJ+ZL0NGxMy7vYAShb8IC9SqmjmcTJuDo12vVmwEmhEJT+ouQLUEZrzFzINtkuFnkmSDo 6Dd43e9+cIxzT6pmHHHbsdHrZAzeZwGVX4yhmSpWnZLBT6SQaSafo7JMm20erCPaUQLWOePB Mi0sWDueD1oblzWtzceb1hZiTWsn8Ka1njxaylJBuF1yg+XqWZDKiTBKbaBhuIj9Uhv6yjil t2XLxIntFumZxTa4j1FUZc8fNYvtG0ctYvvWUZPYvnHQIravjsqL7dHd0LWRE9s50AFimz/f cWGz2L55VLdRzAPDZrF967BFbF8fVhDbQvM+9L3qXNMHsHJWe5UByV4tKAHJXmXAvldHkOxV JijZq6Mp2auMKdmr/yO+as4kR5Xgva3o8zvUBwgQMmANaCfWfxNe8pOQEoGmtlowl5ndicoM RCRE0JcKX0WlxekyWpyuwcJ2QTHfN4T60IqNvbpyqjVWlEbMVt6ot5HqNM/uS7OseVAGcQmD LGtDQVzCYJEVgiwrJmVZYSnLiktZVljKsuJS1g2jRRgGYVyCoDSEo49L2xF//n5csjQD6g9x ySsUlyrTw3GJVkT/N/LV51lzXFrMWuLSatYUlxaTlrj0MSuOS327bmo1ikuZaEJcwt83jzbH peWs9kbMibQ5Lq2mLXHpc9pBXBoML8clS14ujF6ffRWC1VcZlWD1VQiyryKw+iokrb6KSquv wtLqq6i0+iouLU6XUJGW9MV2YXF9noXYYxSXSq2xspTjUgJbWtIXz0alWdY8KIO4hEGWtaEg LmGwyApBlhWTsqywlGXFpSwrLGVZcSnrhtEiDIMwLkFQGoLp45I5Iun7cWlLM3BrOxsKS5Xn 4bBE61H9S24eaw5Li1lLWFrNmsLSYtISlj5mxWGpb9dNrUVhKRNNCEv4++bR5rC0nNXeiDmR Noel1bQlLH1OOwhLg+HlsBS/Vhr92VUhWF21ogKsrgpBdlUEVleFpNVVUWl1VVhaXRWVVlfF pcXnMirS0sV0YXF7nImkRH+eHLlUst2folIGW1a6+DUqzaLmMeEQcBEVgyxqQwXIomKwiApB FhWTsqiwlEXFpSwqLGVRcSmrhtEiDIMpDV23HoLSDlwflfQRNX0/KtEy/L3neJSUKs3DSSnu ilV6aKrP8+astJy3pKX1vCkvLactiekXvDgzoYbdBO8oNWWqCalp9I3ziHNu+gu89lbUicQ5 O60nLunpN8SD/DQcZE5QJryC8H59NlsIVrNlVILVbCHIZovAaraQtJotKq1mC0ur2aLSara4 tNhfQkWA0hcvhsXixaasCFH2bNW5tuQgfc5QCWwRSl+MHJVmWfOocDrIk1JlxSDL2lABsqwY LLJCkGXFpCwrLGVZcSnLCktZVlzKumG0CMNgikl1B8vWQ1CaQ2gZiu4z8218mgJ7xM2wIe70 L2+N3MSEtKDrlTGJ09GIrKb0cfDWcnoVh3Ixp40eADlBTAnxdgc/7kLK0eYwpCPcVq6P45ml H+E1HMRppFqZePDW0/p41y2n1enGWk9r4xX35lRqHeJxeGMsd9XGUpNj0V1aVk82Sdv7zOIp zw0HZB4rhTn3N2j94EqYS+uS8a6ntanxm3PpwuDwdHOp21walWe/nqqH1m7UMb4up5Hq7ea2 nMe631yW01hjfhvO5DxW9x+uSmOOd69KI0aSgvZRwwclI+0fWrwbLednKq3f0l/Laff1nHT7 HeMDOI/WpsZvTuUeBmG7m8pNvG8omzgvFm8eisSbdnc5fB7tMYziM2nptevHD7p5tPs4Jc1j 3fQwJfVzuW0OW2Y3llaMpc/m8/iZ2nZzk3km0vph5plJG9Q4rkxktTd5ZSJtGAYWMJaHiczv zKVrc2npnB/1TNF3PrR2S5FCD2/LaawU8cfJYR7rfhMcprFavZ7SDmNDP5A2cg7nMa5BjKTn kbw0cZoC8vdGMdkHpUWb2OOfc4+9jbXbj/i9mwrxHUppx27H9xEPcduCK1Nw39FhLjzg+ATm iXvt6c1Jq29MZCQXoo/22jsXs1JcEd0BV4XnsdK+heWslLyjWqtZ99f6T9116vsxa9fPvWC7 bmoPObW7SYmnEGnl47X5xPftxt9IOY92U2MtJ7LaGzEn0ob4EllOa018ifyCtmvo429Hw/vz RW4ed3ePVxJd4UF/Jw5q+O8Xbb2Ki6EnwEEOoWMajcD/vsIWHwanMhWzSCpjMOQKWWbzpqY3 hT511JvJQ11bio4V7FtqWmRhIyu2QWJGbXl2UM8K9j2Ncq/BMo3b4kYOWjIIWjrLbGQ626ln FEcNd7OifdNN6yxuanru6X3earTOCoKWPsSEC9cZI48drrOifVNrbPbZ8B3Sk1dgLg7zSKMK 9j2dViw6zb8E9vQvg1VWFHQM+X4DgxQ9YzzvFe17eqd5p7um8TQLhYwVLRnrO+7GxB1MkHKn w2X2jLSG4iinY54vjrx+vjfqecUgH72GCpDPEAbLaYAgTzUm5QGFpTxouJRHBpay+riUdcRo kYRB2l2xg2XrISgCQlBdfDZHiDf++/FZ0ZTaP8RnWngfnxvTw/FZpV0e5KwJrDk+L2Yt8Xk1 a4rPi0lLfP6YFcfnvl03tQbE50I0IT7j75tHm+PzclZ7I+ZE2hyfV9OW+Pw57SA+D4b3p/mq sjUX0C8vvgpA4asFFaDwVQA2X+1B4auAVPhqXyp8FZQKX+1Lha+i0ux0BS1O12Bhu6C43DcR NaEVG3t15VRrrCiNmK28UW8j1Wme3ZcmWcug4Lg0AIusAu3j0gDMsmKwyDogLbLi0iLroLTI ikuLrIPSotsAzcJUEMUlDEpD2Pq4FEL86+24ZI4/JCWLklIleTYpmUPF7x5Z6vOsKSmtZs1J aTlrTEqrSXNS+pwVJiXQrptah5JSJno+KQ2+bx5tSkrrWe2NmBNpQ767F9PmpPQLWpyURsP7 0yzVCI/XV0sFoLBU04KH7iwVgM1Se1BYKiAVltqXCksFpcJS+1Jhqai0mFxCRVDSneOCYvEy s3aUlLjWWFlaklIGW1DSnV33pVnWPCiDpIRBlrWhIClhsMgKQZYVk7KssJRlxaUsKyxlWXEp 64bRIgyDMClBUBqC75PSHqL7v5+Ugo7/eWs7OwpLlefhsBToJglKD331ed4cl5bzlsC0njdF puW0JTT9ghfHJtSwm+CAglOmmhCcRt84jzhHp7/Aa29FnUic49N64hKgfkM8iFDDQf5pbkt9 WgC4ui0AhdsWVIDCbQHY3LYHhdsCUuG2falwW1Aq3LYvFW6LSov/ZVSkqM6MQbF4tIlaQ39e vDrVlih0DlEZbCmqc/K+NMuaR4XjwUVWDLKsDRUgy4rBIisEWVZMyrLCUpYVl7KssJRlxaWs G0aLMAymnHTdeghKczj6EOWPdDLfDlF7XMadAx0KZahK83CGoo7B3pjs87w5Qy3nLRlqPW/K UMtpS4b6BS/OUKhhN8EaZahMNSFDjb5xHnHOUH+B196KOpE4Z6j1xCVD/YZ4kKGGg/zTzNYK 99dXswWgMFvbIonuzBaAzWx7UJgtIBVm25cKswWlwmz7UmG2qLTYX0JFhNKdF4Ni8YLzopps 92LVtuUgfc5QCWwRSndG3pdmWfOocDrIk1JlxSDL2lABsqwYLLJCkGXFpCwrLGVZcSnLCktZ VlzKumG0CMNgikl1B8vWQ1Cag2kZiu4zaqfTFNgjboYNr+PXtwY1iXJte1zE9cqYxOlMtIS1 lD4N3lJOr9JQruW0yQMQJ4gpId3u/Y+7kLK1OQz5CNeV6+N4ZulHvIcGuzWNVCuTTvhyWp/u utW0Ot9Yy2lt5HtzKjUtQMFFdmNp21hqcqzodZptkrb3mcVTnhsOyDxWCnPub9D6wZUwl9Yl 411Pa1PjN+fShcHh6ebStbk0Ks9+PVUPrd2oY3xdTiPV281tOY91v7ksp7HG/DacyXms7j9c lcYc716VXowkBe2jhg9KRto/tHg3Ws7PVFq/pb+W0+7rOen2O8YHcB6tTY3fnEp6UeKw3U3l Lt43lE2cF4s3D0XiTbu7HD6P9hhG8Zm09Nr14wfdPNp9nJLmsW56mJL6udw2hy2zG8sgxtJn 83n8TG27uck8E2n9MPPMpA1qHFcmstqbvDKRNgwDCxjLw0Tmd+byaHNp6Zwf9UzRdz60dkuR Qg9vy2msFPHHyWEe634THKaxWr2e0g5jQz+QljjHoTKuoY2kVopn8tLFaUrIFAnpiSWaxA7/ XDroNtVuP14hBskQh5DCjt2O7yPek20HrjzBURSjXypqdHd6tDJMFPfa05szppRKRUZyYfpo r71zKSvRklSv8DxW2riwnJWSd5RrNev+Wv+pu059P2bt+rkXbNeP7SbHdjc58mQmrXy8N5/4 wN34Gy3n0W5qLOZEVnuj5kTakJ4iq2mtSU+Rz2m7hv7l4Hek6f35IjuPu7vHLnQ1B/2dOKjh v1+09dHqfXww2IM8QsdAGqH/fYUtvg1OhSquKhU20OcaWWjzxu7ZMvWpq95MHu3aVnQVYN9W 02Irp0+bIlCjtjxFqK8A+75GuddwucZtKT7itg0EbZ1tnORD26lvfIap4e4KtG+8aZ0FL43P fb3nze/XK0DQ1ocUffF6Yxqyw/UKtG9sjc0mHEGaG39CnQpp4uGCBdj3dVq1Ydj8CdrTvwxW K1DQNeQ7EA5ZtJbxmRBo39c73fa+axzPvVCNsl5r27C+625M3M8CKnc6hmZnjJuKg58uhXzN 5O9IeyLPNgb5iDZUgHzOMFhOCwR54jEpDy4s5eHDpTxCsJQnAZeynhgtsjBIuyt2sGw9BE95 wvZ5m+4gYq15e5MvDpS3aZX2T7HFobRdiVJA2n79suG07ZKUo1j2PGtO24tZS9pezZrS9mLS krY/ZsVp+//EV12PG7kRfPev0KNkYIUhh/OVt0PiBAkugZ34JYjz4Jz3PoDLbuCcc8i/T5Pd TXKGRdknaRjA2PWq1F0cVpNVU7Yrx3ZEaZuZYja6/QE1beMH3I+W03ZzVndBzR1pOW23ppW0 fT1tJW1XplfT9hDufw0IHN+TsUIwGmtEMzAaKwTVWBEYjRWSRmNFpdFYYWk0VlQajRWXitMx Kk6X4Oi7sFgvHELnORVbt7ZlqbUuK/WYi7xeb5uro6aNSllWHpRKXsKgyppQkJcwKLJCUGXF pCorLFVZcanKCktVVlyqumFUhFEQ5iUIrhxhKvMS3SzO/YK85DqS8rLvzCguRZ47xyUXnrfm q/dn5bjUmFXiUmvWEJcak0pcupoVx6WyXTm2C4pLzLRDXMIPuB8tx6XmrO6CmjvSclxqTStx 6XraSlyqTK/GJefPaTJ6s/ZVCEZfVTQHo69CUH0VgdFXIWn0VVQafRWWRl9FpdFXcakYXUCz tGQ2tguLs/ezzlXjktRal5dqXApgSktm49molGXlQanEJQyqrAkFcQmDIisEVVZMqrLCUpUV l6qssFRlxaWqG0ZFGAVhXIJg7gimK+OSnf0iY1zigHshLvVhfi4ajzEoL0WiYHErnpvyEi2o 7qv3J+W41JZU0lJj0hCW2nJKVrqWFEelols5sBYlJSaKvnb742lSgo+3HysHpdakrq7kjqwc kxqzSkq6mrUSkvDcakbqp/MyZv6+NlMIRjONaAZGM4WgmikCo5lC0mimqDSaKSyNZopKo5ni UnE3RrOQtPFaWJy9lNksItHPlRVLrSSddUZiMIWkjVGjUpaV50TdfyMrBlXWhGagyopBkRWC KismVVlhqcqKS1VWWKqy4lLVDaMijIIhBm23HoIrL+jLjGRmXxsz0qU3nJCRrL9xLzuOQxEp 8gRru/39TSMSrcfVDfX+rJyRGrNKSGrNGlJSY1KJSVez4pxUtivHdkBBiZmit93+gBqU8APu R8tJqTmru6DmjrSclVrTSli6nraSlirT+yb6ambzZuOqJZQ8NeUOs3XUEop+WkDJTUuy5KVF WXLSsiz5aFGWXBSUianZOc9FZmuwZWH2AmZdlovcxn1TsDHrUGTnLBGZrS8XZSwcj4JaPU9C lA6DKl5CM1Dlw6AICEGVEJOqiLBUZcSlKiQsVSlxqeqFUZFEwZB54g7KxkNwdeePKRDRVUVn ewwD4Ba/G272UfbGS4GakF5mDrf+9k7YiXOgGWlNOfrJa8s5dn4qG3M6f8VDThA+Zn99gy+X 4WNKgziHQ5yWbpblPmtf6P2gtl27kZrO+qPXnnb0t11zWhPurPa0zrf8wrE0dC92cJHlXM5p Lg2ZFlmdLJ88kvb3PqunuFadkP1YKa0N/w/asXIp7Es7BO9tT+tC4y8czGGunJ5yMJc0mLbj 6Y/n6k6Lt91SvzB3IzX9hftyP9bpwnW5G6vPcNWh3I91+AWXpbXLl16WtstmktL2EgMIpSOK mvdZ/VBbz5tdacc+nNDmtFN7Trr/lvoJ3I/WhcZfOJbTXAnc5Via7CWH8skwZqu3d8rFvRku hfH9aJdqHt+Tlt55x/pb3X60Uz0o7cfam2pQKgez7wdsmuVc2mwuR/afu5+qfrIXcs+OtGM1 9+xJO3f1xLIjq7sQWXaknauZBczlYj3zFw1mnwbT0Ulf4qmiB73T4h3FClO9L3djpZxfDw/7 sU4XssNurM60p3TV5FBOpCPOerD0a8hn0ulMbroMhlIyvarkLXz9q039kGZ6mBZPabvJWzal Hdcvh8Vfk+n5tyzzQO8I3WfOzagcfpNHeuOkhJJYyEM2JFdt8jgMPif5l7OxlHY/VtqzuTkr pe7ZtWedzu0fdTLc91rWot9whu3KsZ3ysZ1sSDvCZLrRX5j3eMDJjhe03I+27+pi7sjqLqi5 I+3sOzandda/hdxAWzQczwN8jjC9b16Qj1NHM/lWdH/PZHWegxp++4K2nj71oD24hX4YH0U9 9PLF3PvXglVh53NIKEyg1OSFLmwsN51DdEmg6W0Y7dQ265qBZVtDi42cY9iUDLVdH6YI9s3A sq/thnN1uXbofXCstE0gaDu4xEk+1K/6+jewrrq7GVo27o0Jgmvjdd9x1M0v15uBoC0lHFNd r49BrrreDC0bO+uCCQeQ5mZcoUM3h4mHC87Asu9AGSMOg3+nyKApfFJZbYaCrnO4A/GQeWup n4kMLfuOg0l7XzT25z5TjRJcapuwsutkrd9PAbthdQztpJg2zQ5+uBT4muHnCHuSn20M6hFN aAbqOcOgnBYI6sRjUh1cWKrDh0t1hGCpTgIuVT0xKrIoSLub7aBsPQRXeWIuorZZJp8eY9Tu 81cNFLW77tx9LrYsIG0nohCQ+ptfaSRtm2XxDleJZTuwhrTdmpXTdnNWn7Zbk3Lavp4Vpm3Q rhjbvgNpW5hiNrr9ASVtVx5wP9qQttuzugtq7kgb0nZzWk7bN9DitF2b3jfJWIOHc0Dg+J4b KwAzYxU0AzNjBWAy1hLMjBWQZsZalmbGCkozYy1LM2NFpex0gorTJTjzXVAsF45H3ZyKrdva cqjVpUXMRV6vt83VSaZdlgZZZVBwXqqAImuGlnmpArKsGBRZK6QiKy4VWSulIisuFVkrpaJb BWVhIojyEgZXjmDKvDTzwfzSvGQW6v8Z37EoLkWeO8elOTxGzVfvz8pxqTGrxKXWrCEuNSaV uHQ1K45LZbtybHsUl5hph7iEH3A/Wo5LzVndBTV3pOW41JpW4tL1tJW4VJneN8lXc6M3W18F YOarWfowha8CMPlqCWa+CkgzXy1LM18FpZmvlqWZr6JSMbqAZmnJFLYLirP3s9HV4pLWxriV xyUGU1oyhWeXpSwrD0olLmFQZU0oiEsYFFkhqLJiUpUVlqqsuFRlhaUqKy5V3TAqwigI4xIE V47gyrg0zX4nYlzigHshLs2db33ZeAaUlyJRsLgVz215qau66v0pJSw1pNSk1JKSY1JDRs1I V1FWAlL3mSEdUTpimuhltz9aTEflo+3HKdGoKaWrKbgjp4SilpyaiK7jrMUhMKuahebJd00+ vjZNCEbTjGgGRtOEoJomAqNpQtJomqg0miYsjaaJSqNp4lJxMUazMLTxVFgcX778fZeiEP1c Wa7USqJZZyEGUxjaGDIqZVl5StTlN7JiUGVNaAaqrBgUWSGosmJSlRWWqqy4VGWFpSorLlXd MCrCKBjiznbrIbi6/6cyC42z/37MQpfeZEIW8t/8jMvMKApFnmBmt7+naRSijl35nrYfK6eh xqwSiFqzhkzUmFRi0dWsOBmV7cqxXVA4YqbobLc/oIYj/ID70XI+as7qLqi5Iy2npNa0EpSu p61kpcr0alya6PrPjN6sfRWC0VcVzcHoqxBUX0Vg9FVIGn0VlUZfhaXRV1Fp9FVcKkYX0Cwt mY3twuL4Kjb5HikvubUrc61EHrOOSwFMaclsPBuVsqw8KBoEeE4iRpfIwS1h3DyLh16q5LhQ QV/JK8sKXRCGu85nY3NQZyW1zbpGELU1dPwj5xgySYbqmMG+EUR9bTecq8vVAcVtFYRtB5c4 KV70q7462xVZFEWNe2PCOdbG675yKuB6IwjbUomprlcPFF5vRFFjZ13IVgGkuRlXqJ5FuOAI or6D6dIw+BObQXKG8WojCrvOwdrwkOnxxn0jivqOg0l7XzSWo699Q+bWtoqhrpO1YT8Z7IbV MZRLATaNoC8MWKwMjpVFGddplHmgqfTW8c1B/vMzdVxG9pjwPzuHuRkmf5d4i3kZPIaczrDT hRZWWxjfojtTIqUGbz+8+Nvx96cHczbHp2/pN10xx+ePp4fx3B//eXqgMRqO73/iL/xwCujT gf7RJ9b/IdD34e/++CilB651x8cTnZzZtyLcHf/BX3DHf58e5uPhmSnN8fD+8Pr0sJyn41cn /7239Dm9hh5fnXzXP1EzasIfjsfDb08PA33pqwD+UZb/tSzhr6HBwS/WCM2/hPRZVv2fkzsy /kE+efzAT2QC9iytfgwP/En+epJnfS/dfqDe54W+9GA7+v3fk6GlvTvyBvzaL3kJHahCOnwK y3k8uDN36uVz3Qd7POh+Pup6eAd0P/4S/pInPshv2bk/M6Vu5POPvD5+0G/8KnmN7068xPPp 72//8KILc+FnYvuuSHnT301prji6bFO3Mzqqm7mcwqGmALRKPkW5XU36ekz9DtCd7J9ymHhY X5+SMo+yf+9lX0WYx59kNz/JND4dNmOaD0c29QNtmw6uljx/F9rRF76Pwy1D8zNvOB8L/ZLq loR8Z20fttrQQV3m/NT5wtdhXlU8/fRJT8ZqWeuzaI56EI0Mhk6oLFDW9BgPo47w4f2TTv7h 6zggc9zQp7A1DDzJZ98dfsNrfAxflel6L3uS1hU+fn7aDBerDyQmF1uc7kntBqItdLL3Ksuv 5EkgTzllPb5Pe1/zQDM6j9NqzF75E7f4E0eKhBuKnt4FtT3tR/+Yvd8vv4e0Iabzux3Wzp99 3CyMjgGlnPCcx4dyLyzfyn0/6V787vQwEdPj/ygtex0EYSCO7z4FI4kGW2gPmY1ObvoCRJo4 ERJD4uN77d2VWmKMG5SD+/7/GEWieLp7rnyeeVMdrE0dJF9Lqv+JEqRQGz1yzrDknLmoK6vg t4scNYkL4GGyasf9y6R55v5G/Rucn0VveZmDiC0gSlQaX3gGhVvNQ4gTGbRUv6DIY1TlmQ5A m+/90av+KOhqLUt0Zc2dHnxCu9OLVBDVcP18dG3VtSCfIcNJeJqIds0CdST6ucG9wn2WIaqD kUxwT4CSsdb805dAVFvKMo93qrkr9gJotuhDDMyvYuvNTNlEkAn+FEEGZRR/gOJTsFIPjJiv NIR8wsaebpu3AAMAU2bjnw0KZW5kc3RyZWFtDWVuZG9iag0xOSAwIG9iag08PC9GaWx0ZXIv RmxhdGVEZWNvZGUvTGVuZ3RoIDI1NzQvTiAzPj5zdHJlYW0NCkiJnJZ5VFN3Fsd/b8mekJWw w2MNW4CwBpA1bGGRHQRRCEkIARJCSNgFQUQFFEVEhKqVMtZtdEZPRZ0urmOtDtZ96tID9TDq 6Di0FteOnRc4R51OZ6bT7x/v9zn3d+/v3d+9953zAKAnpaq11TALAI3WoM9KjMUWFRRipAkA AwogAhEAMnmtLi07IQfgksZLsFrcCfyLnl4HkGm9IkzKwDDw/4kt1+kNAEAZOAcolLVynDtx rqo36Ez2GZx5pZUmhlET6/EEcbY0sWqeved85jnaxAqNVoGzKWedQqMw8WmcV9cZlTgjqTh3 1amV9ThfxdmlyqhR4/zcFKtRymoBQOkmu0EpL8fZD2e6PidLgvMCAMh01Ttc+g4blA0G06Uk 1bpGvVpVbsDc5R6YKDRUjCUp66uUBoMwQyavlOkVmKRao5NpGwGYv/OcOKbaYniRg0WhwcFC fx/RO4X6r5u/UKbeztOTzLmeQfwLb20/51c9CoB4Fq/N+re20i0AjK8EwPLmW5vL+wAw8b4d vvjOffimeSk3GHRhvr719fU+aqXcx1TQN/qfDr9A77zPx3Tcm/JgccoymbHKgJnqJq+uqjbq sVqdTK7EhD8d4l8d+PN5eGcpy5R6pRaPyMOnTK1V4e3WKtQGdbUWU2v/UxN/ZdhPND/XuLhj rwGv2AewLvIA8rcLAOXSAFK0Dd+B3vQtlZIHMvA13+He/NzPCfr3U+E+06NWrZqLk2TlYHKj vm5+z/RZAgKgAibgAStgD5yBOxACfxACwkE0iAfJIB3kgAKwFMhBOdAAPagHLaAddIEesB5s AsNgOxgDu8F+cBCMg4/BCfBHcB58Ca6BW2ASTIOHYAY8Ba8gCCJBDIgLWUEOkCvkBflDYigS iodSoSyoACqBVJAWMkIt0AqoB+qHhqEd0G7o99BR6AR0DroEfQVNQQ+g76CXMALTYR5sB7vB vrAYjoFT4Bx4CayCa+AmuBNeBw/Bo/A++DB8Aj4PX4Mn4YfwLAIQGsJHHBEhIkYkSDpSiJQh eqQV6UYGkVFkP3IMOYtcQSaRR8gLlIhyUQwVouFoEpqLytEatBXtRYfRXehh9DR6BZ1CZ9DX BAbBluBFCCNICYsIKkI9oYswSNhJ+IhwhnCNME14SiQS+UQBMYSYRCwgVhCbib3ErcQDxOPE S8S7xFkSiWRF8iJFkNJJMpKB1EXaQtpH+ox0mTRNek6mkR3I/uQEciFZS+4gD5L3kD8lXybf I7+isCiulDBKOkVBaaT0UcYoxygXKdOUV1Q2VUCNoOZQK6jt1CHqfuoZ6m3qExqN5kQLpWXS 1LTltCHa72if06ZoL+gcuiddQi+iG+nr6B/Sj9O/oj9hMBhujGhGIcPAWMfYzTjF+Jrx3Ixr 5mMmNVOYtZmNmB02u2z2mElhujJjmEuZTcxB5iHmReYjFoXlxpKwZKxW1gjrKOsGa5bNZYvY 6WwNu5e9h32OfZ9D4rhx4jkKTifnA84pzl0uwnXmSrhy7gruGPcMd5pH5Al4Ul4Fr4f3W94E b8acYx5onmfeYD5i/on5JB/hu/Gl/Cp+H/8g/zr/pYWdRYyF0mKNxX6LyxbPLG0soy2Vlt2W ByyvWb60wqzirSqtNliNW92xRq09rTOt6623WZ+xfmTDswm3kdt02xy0uWkL23raZtk2235g e8F21s7eLtFOZ7fF7pTdI3u+fbR9hf2A/af2Dxy4DpEOaocBh88c/oqZYzFYFTaEncZmHG0d kxyNjjscJxxfOQmccp06nA443XGmOoudy5wHnE86z7g4uKS5tLjsdbnpSnEVu5a7bnY96/rM TeCW77bKbdztvsBSIBU0CfYKbrsz3KPca9xH3a96ED3EHpUeWz2+9IQ9gzzLPUc8L3rBXsFe aq+tXpe8Cd6h3lrvUe8bQrowRlgn3Cuc8uH7pPp0+Iz7PPZ18S303eB71ve1X5Bfld+Y3y0R R5Qs6hAdE33n7+kv9x/xvxrACEgIaAs4EvBtoFegMnBb4J+DuEFpQauCTgb9IzgkWB+8P/hB iEtISch7ITfEPHGGuFf8eSghNDa0LfTj0BdhwWGGsINhfw8XhleG7wm/v0CwQLlgbMHdCKcI WcSOiMlILLIk8v3IySjHKFnUaNQ30c7Riuid0fdiPGIqYvbFPI71i9XHfhT7TBImWSY5HofE JcZ1x03Ec+Jz44fjv05wSlAl7E2YSQxKbE48nkRISknakHRDaieVS3dLZ5JDkpcln06hp2Sn DKd8k+qZqk89lganJadtTLu90HWhduF4OkiXpm9Mv5MhyKjJ+EMmMTMjcyTzL1mirJass9nc 7OLsPdlPc2Jz+nJu5brnGnNP5jHzivJ25z3Lj8vvz59c5Lto2aLzBdYF6oIjhaTCvMKdhbOL 4xdvWjxdFFTUVXR9iWBJw5JzS62XVi39pJhZLCs+VEIoyS/ZU/KDLF02KpstlZa+Vzojl8g3 yx8qohUDigfKCGW/8l5ZRFl/2X1VhGqj6kF5VPlg+SO1RD2s/rYiqWJ7xbPK9MoPK3+syq86 oCFrSjRHtRxtpfZ0tX11Q/UlnZeuSzdZE1azqWZGn6LfWQvVLqk9YuDhP1MXjO7Glcapusi6 kbrn9Xn1hxrYDdqGC42ejWsa7zUlNP2mGW2WN59scWxpb5laFrNsRyvUWtp6ss25rbNtenni 8l3t1PbK9j91+HX0d3y/In/FsU67zuWdd1cmrtzbZdal77qxKnzV9tXoavXqiTUBa7ased2t 6P6ix69nsOeHXnnvF2tFa4fW/riubN1EX3DftvXE9dr11zdEbdjVz+5v6r+7MW3j4QFsoHvg +03Fm84NBg5u30zdbNw8OZT6TwCkAVv+mLiZJJmQmfyaaJrVm0Kbr5wcnImc951kndKeQJ6u nx2fi5/6oGmg2KFHobaiJqKWowajdqPmpFakx6U4pammGqaLpv2nbqfgqFKoxKk3qamqHKqP qwKrdavprFys0K1ErbiuLa6hrxavi7AAsHWw6rFgsdayS7LCszizrrQltJy1E7WKtgG2ebbw t2i34LhZuNG5SrnCuju6tbsuu6e8IbybvRW9j74KvoS+/796v/XAcMDswWfB48JfwtvDWMPU xFHEzsVLxcjGRsbDx0HHv8g9yLzJOsm5yjjKt8s2y7bMNcy1zTXNtc42zrbPN8+40DnQutE8 0b7SP9LB00TTxtRJ1MvVTtXR1lXW2Ndc1+DYZNjo2WzZ8dp22vvbgNwF3IrdEN2W3hzeot8p 36/gNuC94UThzOJT4tvjY+Pr5HPk/OWE5g3mlucf56noMui86Ubp0Opb6uXrcOv77IbtEe2c 7ijutO9A78zwWPDl8XLx//KM8xnzp/Q09ML1UPXe9m32+/eK+Bn4qPk4+cf6V/rn+3f8B/yY /Sn9uv5L/tz/bf//AgwA94Tz+w0KZW5kc3RyZWFtDWVuZG9iag0yMCAwIG9iag08PC9Db250 ZW50cyAyMSAwIFIvQ3JvcEJveFswLjAgMC4wIDU5NS4zMiA4NDIuMDRdL01lZGlhQm94WzAu MCAwLjAgNTk1LjMyIDg0Mi4wNF0vUGFyZW50IDIwODUgMCBSL1Jlc291cmNlczw8L0NvbG9y U3BhY2U8PC9DUzAgMjEwMiAwIFI+Pi9Gb250PDwvVFQwIDIxMDQgMCBSL1RUMSAyMTA2IDAg Ui9UVDIgNTggMCBSPj4+Pi9Sb3RhdGUgMC9TdHJ1Y3RQYXJlbnRzIDc5L1RhYnMvUy9UeXBl L1BhZ2U+Pg1lbmRvYmoNMjEgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA2 MzM2Pj5zdHJlYW0NCkiJ7FdZc+O4EX7Xr8AjOTWiCRAAydTWVvmaxFtzeMaq5MG7DxpZPhKb dGx5PPPvty+QoET5SOYlVXkRKQLobvTx9dd7s8nO7t3q6ny+WKlfftnZXa3mi8vlmTrdmbW3 6o+dvb32uzo1eZVZq8pKZ945VVR15m1Vqyovs9zVBWw8efi6+nG7VDt/W87PlndqZ0b/jucX V818ddU26tdf9w721WRn/yRXi3uVK3W/aCY7s1mutJqdT6Z5ludGzRZKXh5VndVeTXPYS2+m rLLSq7L2WQ3rN5PT5Dg1mU3mF+nUwXOp0j9mv01M5ksHh2Znk8S6dPbPSU5iUaTOtJElhSsD rbrALVOdZxVccwp7XYlbT5ND0jNLp7rMfHJC/45S3AFitM7q5Es6NfB4QEtccs1ry3tZbfnz eTr1WZEoNvsu1fDbklCXLJZnvOmBL3OXoiE+Wb4VPU7Bi8lMspsaDY9b3o5SXHLFm0SvMrns 1SW5JHJAmdXaxy44/IBh2ZIGe+1q1d70mQBCvVWFy3JbQCKAoZgItspMXZdxHrxr29WTeTCb 6bHAaw5BmdnaqmkJiiBgz8bggL1/lRbw7469vFyk0wr+rmAPfubFb/AR4oK/6u8gA/bJ/nve foUPiFijCvJhkZRvSYJJ1C4pvaUDNuy8JrnKiMfzMZfnpdlw+eHLis+5PNOQmdpB1ZlSK1eV WQG1oKqizIx9TfH9e+KszXwFtljwm1eVNVleVOpuOfmHaiZ7swnmvubahMqbmpIrTyrRgREm KIYKlOvMJp9fLZtjHQd9m7rSQ3ik4L9AuRRQ9ujh/0jtNh1Ypv6/ulJ3o+kLrpRblIfq/vJz XGie1OerKnOeXQg1Y8CD0wJg44t6j/6kT/uH/O1jOrWQ3Scp6OIV+lIkf1UHtMUn+3Rql3Z8 4cVdXpmliFl06tNH9Q4/lskn2fMhBZtLkPyzo6c94MUgeFRhn/H8zjEW14f9owNQ0oOPdB1w XVkEH1ZUrRawjbsOv+oSTKhU6SoJGbmwYhd6dCECQbLAv9CD2InNPT9pqblQB/J9wY9r/Dzn E3eMO3NeWbGr4FzJKISrDtwLKGKSBkDGg9MbEfd9HWqqLB8B994FOrhgvbfWZQYYVVonvXUI VFEQbI3FWOYeE8pCL66wHTiDITt/E+syQZez2HXDEYCvnM/omg5RlPsasl0NuRESUDtsQKXJ pVxPk0/cA24h88B9V6kF/7SUhg19mqcOvlzD9zpRjwLld2lJCI4fV6slbWnokOI/3+mXhfLZ ebQJ30tUNsWoxNpUS49zxRpYGB+9p19e58332Eigr5zzRzwCEniNha7UDbEElvAv7lRsNlty wVpXl/SP1akjcsJxCrQN6pPa03vaRwZryEI0P771/bpkR5I9tlY8v6QTC7a390cpNrN5Kz4e 3IGp2bf5PkktSHd2kKVSsMgjILiWsDjnH82Z1a0ZzB5a00hKeY0wlZcs08Nu8c1a8pogXzb2 GiQHnfWUrqNWdIujZrCJnOe0BlluhwdHF6OiKfpeDcaCDl8DyijjMe2hSRV1HYHjWnFwoXmo kdJvwmGkxQYtCMFAskojekinflZRpV+oyMWKtIG0DIpyEAQA8JwmXeTZizT5WJMrbH8nUOHt 83dyNn/qUp8xvBb6AMBSji+4Ww8D72i6GMtNXqKvUWYCtfPdOeMw3NEqx2XL0bLEbiSLtqTs 6FfZ01uOakim3lyb07Viq9h522wufKS5Hlz2DaV54Ued1FXAqFh2LgeMTvbhOg9St6xGSVAO xsz9ExwzT/Y/AgTAhR6hI/0GhQV4RN1dOWDxgRotbib48WYCkh2S9Wt5m/LjGpa718vJCZOL tRTyNWVQSXfZyKAhGamCqfH8o1010vOk2iqohIp73kyGxstlGH1o2pFZZC4TzVwGmGYVRlW8 AbSj5mxH+mArswwvlTIkyX6ekoDZ1bDyjsfSdzx1yuD1Xp67NEkFq3hSO+FzKlizFGvUQyNv j/3UZogS0TRFD7ajuQhnVsFedSEWb7scS5NNQfU35lgtOWn+VY5e09alok5VwLvV3JVOxZEs S+bIpQx4zdp/9tJDcyZSwzypxLBL2Sd6hhTHYriJUGJfxo5dSMf+HQUbfEn54CBPSqL7YjOq cSUbfsaeuxdKGlKipQ8wXPKVmmCLJBx0b8BiufvAbriPmsuXEIQ5CcZR9Ui+HFPEv3A8lSRF c76WZDewjqNFkMemAsc9ofSRryGw8ncZTi27SO+Stiak0fI7B4TvdIoCw1kJRRBxLxuhAJRE sW3Orjjl6IyRmLdN2CuF8ZjWkU/6xEgu+wSP4uTCTEEctoCw1lXw7xUa7pD3dQnhu4TwFFgY igzEOA7sHIgWhHTRbiSDDJuGmg9vFovO5pSsaBnn4KDiQpx5USf7vCgYIicexA9L5TMJp1Yt R1ZzjiMKiYjDAQ6cUJyO2K8hK45pC6SKJkJ+zCjRRnVPjgWCr5MfKUw7OsnWphxY83X91JhT B3A1IM478E2hi7XtAMvSdIAdUlMBUudzPWw5Y2vxPJVv8LWifi1fA6b5DLnReoSwkaLXEbYX aDIjjI01vY6xvUBVMUbZSNcrKdsWXYGyscytrGJ8NTa0o8vr3AFs/sncAXHqWe6g3Rh5MMV2 7oCU73XcoUPbrtESaUDIjDiDGWcMpmcKwhtiwoAlzntixlAk3AYiPH0ILXejZa8EgAIfiA0e ZQBy/ltqAwuQL18FeZahfbAKvhajZ3AA/wuNATr+eKsfdgIbQLpv9Sj5GBAQAfD3BMUV6Dmd Q68n5LPJtpafdz3h4P/N/n+w2Y/07dFmvwgh7ertdd3cPNHN+16uN3p59qJurl/RzfV6N3/b 83U06Wugx1yVYuF6x/dZDQX0RMeHkVQgUUPsoCM+2fJdXW5t+aNra/jbzZmjDd1VMKfGIC66 YwnVZkuBUxa0axT0U1pK7dkaGIuebyn1ZkvBN1ePNBWdV8N79jhCTYWS4WUTaSgKWzI8hkzd 7DaDNOdGk1Ka8vDZz6eUrYMBdXu7saHd2I2cY2+NeQNk1Kar8IBMbbhT6E3gi1uQrSHjkvZW PMAlEWbHbqwNl2wDjMbVyEh3JGK7kjPSPjy3j4q6B0l5ui+IvdgeqEobhr06iuEaLAewllYg xp/18wsDmfglBrJ1mOhaBjWmqGcApd3eMkThCekDJVDsw/Y1D45cbyBmvIEACA2DXRJaPIEv piP6BnLfOtVdchRfvM8Qr/Ad6DCUzABhxleHBWn00xjjDNLlpzDGmG0Y4/VPBRgHdzDPAYwp xgGmcE8ATHfJdYBxEbyYF8ALc+Ot8FIwvIzw2BhY3DquBOyJccUGGnvWqqbDhMugGAnoUoAr JG1UcF8Z5aB/Rn3dIH/A7plEB9F2OSRfo0PMEzq6EMrUED/JM18P+F8R4UwfEhjBim7bKPeL wQdEMPwUBD8ELPcRieFAtbJ1GYHPgIGaDp46q2sirdMCPhbMkqD6mCWNwBNdpQeoXEIWgLPn rd1ST1718+SVkNIlQw67DXy0aOEkWUMgXgoifceAByzWgQ9tJweZLLz4jhh2ySwvgxwWBzO5 TYIapLZmQG11oLasY21g4jAULqttR2m7tkEHxBgSskFV14OJnYLr3ngOK0mOW8bjVerpFmRm jaf3r7H4aqjeIYfuK7vInDXBwMByaT4lqotMN5gy0mLD0uGAJXCQA+ElYaPtjFb4U4gI99vO u4Uh+ovGg+aiLIKlWcSmeVRbm8e4nDmCTJD5bm/DHW7D+CoHZF0FvhEwAnFHAnfWEXyZEdom oAB3+JC8IdDD0Y5yU5vN6gjgO+JhcUt7PwSkLhm0EAhPvR3P+FqyQUYxSF5IL34oNgBy70dq /qS9bHrkxo0wfPev0FEC0opEUhI1t8XuOkhgbNLxADmMc+j1yB4D4x7HXmc3/z5FFqmmxCp1 S82+zIdKfF+yWE+Rst9tLn74r2mSA9jWcCTlT58K++n1DeYH+3TAl351T2GPcvenuyo4tbvZ 3QBGKdUuXg6UP9tkba9AcMrydwOYuj/9GzW9GBCh0KYZD/RXqi8r+ESBE1jCOQn3cJXBUjq4 xsOof2VH4rTGi4Pq9fTicB8vZ/yW2oNTXdlD2Fn1VexDfNTS5/nJ+yF/M3z0hx7Skv3iPhwO Yxu9C49xmOhl05l7t53JziXr7ibr7kMjCe0lcvrz/T08ze4/RJ79uF41/fS6VllUkKv2Nsq6 vM2UTS9Qt1HW1yVjrickUhXpRaWiw1JppAqczDmr6gtwrJZ43Lt24URtTzhJji2DC4dz7aO2 oa31qrahhfkWWMqJrKi2gVbXtY3R+yH/BY+sU4/IzK3IH9mTCxBeORebCD+5+Uy0OQQuykJN NRE02tZEwFPw1b1F2TeRWyjbJnIDYddEbqGsr0sG00RivahUBNVE0GllE2Hq8tREmlK7i4X5 UWOTGDukjZrFBcGxwZBDnS5Olm1OTDjMgYyaUwu3tZXNqbVNcDHXimpOaHW+OYmF5jR6P+Q/ YXMavhzcd6TrRNF34VJP4ucUXWwa8+uSxTdUT0KjbT0JPCseli3KvifdQtn2pBsIu550C2V9 XTKYnhTrRaXSUj0JnVb2JKYux57U9YZwridhlOlJ9FCni5NlexITDnPQRT1JdWZSq3pSY7Ow mGtN9SS0uq4njd4P+Q+FgM7z+Gg7ksyHb8XOfOR+o1oPbz33UVgXpzXehfW5Xg4+0S7KWE81 MvTZ1shgfzVP2BZl38huoWwb2Q2EXSO7hbK+LhlMI4v15qWiKqqRodPKRsbU5T5oOIpvZBhl Ghk91OniZNlGxoTDHNRRI5PwHRP0MXG2jUlZnkm0oLqY9XHoL5j4hnXeRVLkWxdfN2IN92DY tGxBrtf11KfXtcwnl3XEp9fV16SBoT1Wi8pDUbRbnwD2xWqvFgpxHyApeNQxyqBOD3W6dqYe Zfjcmowkg+HimwhzeFGswrw2J/BihlsKc+tDYH75VcUbP+T38FHUlU0+PBfAEnxFPb3AEwGX luNwR11XOPO5U4M1eX6JHdVjrAtceNb3GDCUPATrdX2PSa9re0xyWddj0uvqa9LA9JhYLSqP yXVdyvbkAwSSBNRE4UN7mBEXTv8i2UWwpLlMqxCs18WuAa4Of8DVP5+QdM5tLt12PldnUjW5 p0tdB1vSyMu3WupugaQrdKFI+BK6RrfjSdouq6Dh8SRdo9tdk4a5GvTqy0hqyLs5+qw6relC HE9rWZW9OB2508Mag7W/ftuY5+E0sJ5E7e5iUKmygSt3EHXpYsZqcRpbN2I2eDzqqRm71dj8 jNd9MR1IBsOUR58Csu9X3RAqcwtZ3FXqQ8C4cPeDxrexZuF+4G0f8p8LGNXmn4udMNeEQ7GD 8yX/9EzdDRjbuYdsEIOzS6O+PozHpm8PsKvZg2u1qr8VpFa1d4LEou5GkFpVb08AcxuItaKS oL44jMu6DkaX3tjBaivLdDAMzjqYb9oYg8KNmwwpioZmAUyLoUJhPqKPEKkhlyoTresx6LTU Y6Q2XWwx65OvkM7OxPlY0/qcEaTnMqPpt4BQ5bggVYESdO8zTjX08oucNFVIaHWqpeXkVQuL 2o9bq8uGqyUX9J+us42nBjpRnKevi/lIOhoufrwo/gfYNiuqYY8BCdnp7P3nV+bJ51eQBjOB 7Nn9tcNfzxAe/3x69dYm0NVe2xiAXe11pV5IX9vb7MHdtifTZ3rPacbteHeZXsWpq74rNjDo BJ5hfy92cOXKf4MPW/j1NHwtdpCpPLO/VT4cvpk7+svR/sre5Rj+Aq8L+P1cQKvPB/ufyO27 5v/Mvv1lcG+9N/99sq9+gLMSiiL/XyGgnefvCrS5Q/vMHpyVXYGZPfQFIXrz96NPgskAZMJt NiYVt9Pn9LTZdDRMXXwHgV8qaBEdYHWuRzR1qZdP61YQTQKdVNPHPuzJ4vYPHONz5RrZ1iQq uWxflzeYbN+aIzu5bI0n7FbdSK215RSpRaUhqWaLRsHBvVyG1VIdju0WRccTEyVPtDDhcK4q wkXa+9MqXOCK257BpSFwQadNuICj4rZ0kyzikloWcUmuiriklvW4bNRlcInUotJoKVzQaCUu TB2ecNHm7fGSUSMOvhPYoFlaEBtJIkc6WZwrSyETDlPQRRTC6VatpLC2tC+mWhMUotMmCsFR cJWySRYpTC2LFCZXRQpTy3oKN+oyFEZqUWn0FIVotJJCpg5HCiV8DbAUYpChkB7pZHGuLIVM OEhBV0UUVpU5f1dRWFnal1Ld1QSF6LSJwkpydbJJFBlMK4oEJtZE/tKKevo2qTLszbSichAU eWizkjym9kby6rZsWPIwyJBHj3SyOFeWPCYcpkDOyRNalY0IyBPnwBNQuP1yj+tUDJ4z8vsp LufOGMKBSpfJJllLXnJZy156VUtfclnH31ZdmkBCLSqNhoDQGQUQLlZhtVSG+wAWyTKIQYZB eiTKuql6yIC3cCgTDdffRgS2upTrCOwq89ZimjuCQDTaQmBnV8RUyRZZJDC1LBKYXBUJTC3r CdyoyxAYq0WloSkC0WgdgUwZ7gNU/E3Q/ggAdDEPYARRPM5p4jzHM05MR9LRcPF9hF8j7GJW 4NdYyJdyrCsCPzTagh8YCrZEtsgifqllEb/kqohfalmP30ZdBr9YLSqNmsIPjdbhx5ThiF/b jdfBCD+M0fiR45wmzpPDj46GixcRfrIxx/ga/KSFfDHHksAPjbbgB4YVWyJbZBG/1LKIX3JV xC+1rMdvoy6DX6wWlYai8EOjdfgxZTji1xg1Bj+M0fiR45wmzpPDj46Gi28i/Ooe+8Hl+AkL +WKOWwI/NNqCn6hLzZbIFlnEL7Us4pdcFfFLLevx26jL4BerRaXRUfih0Tr8mDLcB6goDj+M 0fiR45wmzpPDj46Gi9cRfpUs1Yk+/F5cpK9qyK/e0KUn6LM+bicnLufgA7+WLZANqsheYlVE L7UokpdY1YO3TZbhLhabF0VfUdxZnxN2y+VXLdXfPkBEcNhhjMaOHOc07TQ9VzjJ00AyGK68 nkNX665cdeTVui/b5fSKmDm02XDgGTvZMrWxRdUyl1rVMpdc1DKXWtUxt1GWZo4Qi4pCEsyh z6qjjim/EblKjNe+CDmM0ciR41ATZ8kcdHQwXLiKkOvqVcB1BurF3DYEcGCyBTcwq9myWK2J sCXVRNTSSiJoSTU9ZltEGchiqagQWgoycFmHGF1w+xGHdrzazRFzMRIxepzThDlygBGhcMld hBdgo1cB1hiEF/OqCcCszRbEmtb8w5TEBlWELLEqYpZaFEFLrOpR2ybLwBaLRUXRU7BZn3W4 0eU34tZVZcPhhjEaN3Kc07Sz5IAjg8HC66qKmJMaTuU1zEF6lpILe0ogZ122IAeZ7tjS2KCK yCVWReRSiyJyiVU9cttkGeRisbgqBMWcNVrHHFV++4AOyRGHMZo4cpzTtHPkiCODk3XLiDgD myeuNqSfI07oUusz6VUEdNbIbuOyjUPtEpuG2kXr43fx3IqqJa99kPSa20iM0RtJjnOadpq4 V36Sp4Fk0IAUrn68pO2qsoKKvn+fmT+gIn/PZgttdVmZ/ZWlsOt8yP9RiFLlzwXcBfOh2NWi lPnhW7HT+ZB9LXYtBIff4LmJf7cPZH7MzBN48OQGfLLD7ajsg3v55WsBick/FzuhQMQPeflo 5UqRPw1OLrMqIv8dXi17KyZy/5IPescheyeELP59/7dXtS4l3KSq7P4RFvJX6yvcgv6JWpl/ eiSn1eQHp4sreDmiXZ2/Lcy6XPAwncPg1zQc3ZPscHx072RvUOq9TaHLz9GmBgNH9+xj9hPO cbCvPsMP+OfgcnKal338crQrruzemn3FAiU2XMgSvhBdTj641b84VT9xSKHCvR235c6thPSJ iesmNaf8FKQZYzxEIzMQVKrFmfx8D/o9JPwt7IhJg1m9srttbL+aZUqTL5NDSEhdmWzbPTHP JLwxnRi0eIOUUc93cS6Eeacqpex8Lv5S7DqzeUe3UYOr7oPL/HzlstStG8wlQdNJUJgEYF7a JMCFjEvCzFOUDdAcLCpYAbvjVSm6cZVtU7n6+pPbULfMl++e4iF7HBBVl4k3399jeWKpufGu Jbg3Z1VhJ1fX4cyCaeSv8UFbK36H6miHqrZ33qL2c3traX754gJPbpKH7Idi15c6P0458e+9 PNsmEvalHyHU5MPj8MdsMZAUU6bTpejePQBUWnzWNGrNTrz+P+NlkMQwCELRq7DUydTGiBLv kk0ukHWPH1SwHZvJZOPmKwKKD+0r8lFrPR8lxzX7bzkHkBn7p/jntP5a3BN7TiYEiQc20+zM m5XCRdBsBUiyKgKSvkM+jXFGtwb/d6MZco1EVPuAChukDhvRekNRBv9EYtpUCTM5/NWEbdfb qXhl9E4bmdj/UgMA+ROTF0i5GPpyXvJwCjAASB+F5Q0KZW5kc3RyZWFtDWVuZG9iag0yMiAw IG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDIzOT4+c3RyZWFtDQpIiVyQz2rE IBDG7z7FHHcPi8a2h0IQlpSFHPqHpn0Ao5NU2KgYc8jbd2KWLXRA4WO+3/DN8KZ9ab3LwD9S MB1mGJy3CeewJIPQ4+g8qyRYZ/JNld9MOjJOcLfOGafWD4HVNfBPas45rXA429DjkfH3ZDE5 P8Lhu+mOwLslxitO6DMIUAosDjToVcc3PSHwgp1aS32X1xMxf46vNSLIoqs9jAkW56gNJu1H ZLWgUlBfqBRDb//15U71g/nRqbgfyC2EFIpU9fxISj41O3tzbVNoWbhHNEtKlK5cpMTaAjmP 96PFEIGo7bFfAQYAMY1ybg0KZW5kc3RyZWFtDWVuZG9iag0yMyAwIG9iag08PC9GaWx0ZXIv RmxhdGVEZWNvZGUvTGVuZ3RoIDEwNDM5L0xlbmd0aDEgMzQ5MjM+PnN0cmVhbQ0KSIlcVQt4 zFcW/517738m8hIp8mz9x0haeRTJqlc2hmRClyAPlVipGUkkUZEgNKmUqhKdetWntlLVtYqo pf/YsGFp04du9yOidKnuVtB2o91V2f2+1m4x/z0z+ln2f74795xzzz3vewYEIAjPQWLw5LxB KWEpRQuZc5SXq3hxjb499vzfAYoFLPmzq8sqT9YVNgLWaqbnlc2tm22JA9MhF1l+Vnmpu6Sr cGAAEOpg+rFyZoSn9o1nejHTA8ora2pr2m7nM813htbMrSp2Qx0fCWSGMl1b6a6tDm/VOoG6 VSyvz3NXli4rf/gLpncB0lq9oLQ67lz2u0D9Pnb6HUi5mjZAQ4DWqKWylzF3dvkJZovwAE0E WZTwfeoSEsw21Gaw1h68kJ+docMB3bylnfXmUKo1nQ44QKZpAipe+4PPOpR2BFG8orXdiFLx iATMLl5Xfbu3wrzqO/ft4luWb/1pAU3YRxXYh3fxPnXzrbdxGC34GBHIxFbUYxMaYMF05ryI XAaN+ZsoymzBIGznOmxHO8tOw1IcQV+KNL/BMqyUZ/nWSoSgP8ZgCqqwliaaizADnWoFhmEi 5qGanjMLzHXmRvNN7MRh+bF5mysbjWKGdvM77TPzr0jmG69gCzppY4+DnIFpXPnD8nUsQKMs UmSWmT+yBzY8zT4oZKOd2kQiay9FF0VSvcxgLTtMw/yQpWJRhHKu/hEaSuOETZthZpvt6Ms2 alnrFhzAIYZWHMPnFKx1m2+a3YhCEh7neFpwitqk9/Zy72jOmMZZGogRfFKFd/BHnCY7vSeq tGAtRXNoz5ifojeGYCp7u5tv/o1uiKUMy+RHKssci1DOy8u+bOM4LlM0DaLJ9IQYKKrENrkA AWxxCEMJKjjfr7L2i5RIh0Sw6JA71F510/Kg95IZyhWJx2t4He9RCEeq00J6ns7RlyJDzBSv iStyk9qjzljdHPWTqMRa7MUNCqfhlEO/pHKqpwZ6mbZQO52mq2KMyBdPieuyXM6Xx9RYhjy1 UK3QVmkvWa56C7wfej/x3jBTzFXI4X5Yzt6/gm0c2WF04AJDJ66QRkEUyqCTjabSEoaltJZ+ Q020h1rYymm6Qt/Qv+h7uinAYBExwib6M9jFAvG02CS2ig6G0+If4j8yQvaXiXKoTJOFsoq9 apAbGA7KyypadSiT85yibdbe0Jq0vdr7Wrcl2Pp8AAJO3tpxO+H2RS+8q72bvQe8LeZl9OEa RnMW+iGNvXczzOF6b+aOextnKZhzF00JlE4TOTMzaQ7Np1rO5AvUSDv9vu+no5yl83SdfQ4R sX6fHxVDxVgxmeFJUSrmiw1io2gR58SP0iqDZE/ZRybIcbJIlsoaWSc3S0OelF/IK/IHeYvB VIGqn+qv4lWiGqdmqkVqm+pSXdoM7YT2tSXQUmlZZWm1/NP6mDXdOsWaYy2yrrcesn4a4OLu /AAH8Xvc89EluVw65UGsE6kqSpwSp7ifZ6JEZgvuVNFEq8Wz1CIGaLWWUWIUTUK3iudcfyTe ED+IUTKbJlAe5oghd7RZequ3eEtTH+CaOsqxnWLNtZZgWiquW4JxgCBGsM3jcrBKlCfwuewk q9qOv6hAiqBrYrecwl1wTKVrBbDJrdgv59OzOCicQODNgDXcx5PoLZ4L+ZRC/5YmpJjEXTRM fokVeEp8hmv8jlfjV1SiyrAOqVSPLuziVzFQm2dJsPShP4kK5REPUAuE2sPRjaABJLXeeIGK ZKPluriARehQgbgof8ved4j9Mlt1a7lUzi/gWazCfHM56rQCdYbKIOkJxPGg3YR6maJsvC/j qTKDZ9ohft1HeA6MkdnMieTOmch9MZUnRCPDqzwnFHdQBb/xaTzFTqHFki9aUaaFEk8dnscn vLmYbu7CFrMM88yNSOZ50GDWs8YmfI31aKKV3iWoxkP8ci7SRC1LdGhZZrLwiAsiT2y+v76c 7TiKxLcM+5lI51nvUeeRh9HmGvPP3N2P8ITdgln4Bb7iKL9jC+NlG1K9k0SzmSWrOd5O5Ji7 zX4UiHJzLibzf+VOqwa3NZFrbNAZjncJSkWuWSNLvRWch/WcBQdnaxHPnxcdGVPzxzhGp/88 bdTIEcOHDf1ZasqQwYMeTU5KTBj4yMPxcQPs/W16v4cejI2JjoqM6Nun9wPhvcJ6hoYEBwX2 CLBaNCUFIclpz3LpRrzLUPH28eOTfbTdzQz3PQyXoTMr634ZQ3f5xfT7JR0sOfv/JB13JB13 JSlMT0NacpLutOtGe6Zdb6XpOQWMr820F+rGNT+e7cc3+PEQxm02vqA7I8szdYNcutPIWlzu cboyWV1zUGCGPaM0MDkJzYFBjAYxZkTYq5spIp38iIhwjmwWCAhhp4xoe6bTiLJn+jwwZJzT XWJMySlwZsbYbIXJSQZlFNtnGbCPNXom+kWQ4TdjWDIMq9+MXuGLBi/pzUltnjWtYZjlSgwu sZe4ZxQY0l3os9Erke1mGhHPfBX5P5KVh2cUNNx7GiM9zsgK3Ud6PA268eucgntPbb7fwkLW wXdFXJbLk8Wm13ASJ+TpbE2sLCwwaCWb1H2R+KK6E1+p3enjuOboRg/7WHu5Z46LSxPtMZBb ZzsQHe04bF5CtFP35BfYbcboGHuhOzO2uTc8uXW/i3LoUfefJCc1h/W6k9jm0J4/IcEh9yKl d8/8mF/ch03IvZtZ8nlkf5wbwtCLdfakwM4xDff9lA6Hp3g4i/FXSHzLKOGKVBg9MlyesJE+ vu++ocWF2XXP9+AO+C/3VR8c1VXFz3vvvrcLBbM0LBZ2KLss4SsEApgUIoUtgQCJUCBfmxQl fFjRlRaJxdqpZZkIhE3ijLUwFCqSDB0wYYaFprLJqE07UzPUaTsiwY8yaqXMWKm1U6FOA+T5 O/e9t908sFT+dCe/nHvO/Tr33N+5977wP94bbFlnW4wc31XiIvMkTTXUO+Vkbm5y6lSmiKcY ewof50u9IG/atpQaDm/xBSEQPlqJ2K6rKZqB8IdCvMFNqQith5KMr4paepDWB05RZEZuTVKt 45oep8ZfyTVxpybdvS4MJncSP5f9Se/E9F+Wb1T24k1FSWXUp1R/1aovKw+XraqNBhcn6uzY llUM0qz6Oek6u5TMLo5qAdUuqQFN1oKUa9KNWYkOS4oc/BmS1BtTHi9YKS1KsCTpq1tq/a8Z Ggp9xk4p8wPuJcUn3Ww3k0W5g/UvDtIHuTcsocFhXJVlFbWJxNBBdaCaNeEyW4DxVBENBYuT VInMzMFfyuyZw6gJJCMIWTE3AP8sk60OahiwyzX4MTvzppXgoEskSsLBkkRdYl3KjK8PB33h RJf6ivpKYsviOoc4KbO7KZAsaa5BrDYpRUgKlRaeDCuNq05GlMby2miXD18HjRXRU6qiFtct rDk5AXXRriBRRFpVtrKRlSArVKZgkadUr2wf6MLXUVzWCmmQ+oaUQtLmdWwKbUipls3n2FTY hGWLSBv/+IwprohmskemZE0eqYp8Xuv4KCIPUWhEaEQO/im4cq8HtZ7rEZ2uUVD04FrEPbxH hLV+fGOQMmsUrh4Kj6eCLxQWqrFHzm0bGPjZ6YGBbee0/q3ntqKkqKfrf7uVJOP1Oav/1dH+ 0NqseVe9Aa+8ZdsuTprK8uwz28f0n7jxNR95h8mvL0X2ADzzB1ZQsY/6T/Q/4bPGyfgN/7Jh m/iFZCOp/o6+IurJDyzzjKXv6FUUVXZTrdpOTzK0sRQRx2kr2rZDfwCym/uifSXwZ2AeUAWM sW3LgXVAOeto28V9McYWHkfKeqr1jqNH9SrzBubbp/fSw8AhlNvERTpmzKXN0I+g30uC6D5u gz77jHbaD/tzqN8A2yHIKPRWlNegX75dHuJpwVcmJGDAPgXjNNnrnaS9TIWi3nwba6nBmKXA LsyxErIEKEObbMiFwG6llxqVXrMN9ZDUgPl3sx1YZMulGGcn6heg3wToDSiPgR8GZBYQAiar x2muOpJ+DjkD66+21g300iZec3pN8N/26WZYPpZlAnP+Agirc81LkEMyfHOjwYVl2myKQ8aA ALBKfZ02iy+Rgng9q18ijQHecZz+BNwvNtIK6Ar8LNc76QDrwHKJevOGeI4Oa1doDuqeMPZh HRsRb7zZ1Y9ohvoe5Rk5tB38WoTxdwCHMObfJB82UgXmnw45W1ySHNoFNGOufzpx4thA34F9 XY25rnM+oH85sAT7Ege+yf5g/hkcc953pWpgLtq+gzZrGLB/XgJrZ05yH+6PsXJsHrZ9IqkN bVoQ179ACsDPPjiQPLOBul9hnNGAAYwFpgOXgDYgBhQBZcBkzE2YV5N8BWeYm5If4IbeixjC N8lZaw2H5H5aOdNqj8XzhIzjFLMR4jE5X5iz8OWkMzbnFHPGkZLfMcn793mdzKm0RO6Jy7SE fZA5CG45kvMOPnM+7FMrqRHyAHjcwJxl/xzJcWGuyZggJ2w5L2Ot+TJHIDWisM31Bkc6sUjL TXQEY9YZ63GmHKal4tv4avghrRcf0CJtCk3X82HDetA2qV6m1V58UWAvH4T+rEvuZ3j6lG/o PVhnB+LZRz9GTL8l+tTxok/R9Q7zXZ2UM3qH+pQs3yTdUHqsOpaMzLr/1X4nUM/rHTgzO8y/ 632mifU8zTnhuazkA0FHwn4KiANTvbnKfm9MSXkqyWcQXQEeFREq0iN0Hy6rBcKPcx65AHul /ja9pLXg7uoz/6DEKa720S6Pn9bhyy+L51LPUwODx4fcksGjQZxzc8mRDl/dks98m1PjIA3k 3xs23rHxEXAVPCoDJ0fz3cDns7wfcEYDuyy+mv1pfp6h5yGbHH66eBpz8XOYm5duKe8WnO9O nsKPPc76+XzkM47PSD7n+Jxx2rtlRv+E2g4e8zn8OtXaeT3eRil8/Kud+ziHsd/VpmmUmEeN TvOYdrd5zJiF8u8B3TyKdT+evlOj5oB9n05x7lLLTnc596g+mzbb59kRed58SM/Ie7RK+jfE OEHb9WvYd5yB0t/Ddg4invA7JuoQ8wPUjHWM1nYjH2EH1nBM5F4Q3cP3At+J2l7Eme+iFmrQ 3sJ7gfvOphHyvlhA1fD9jLThTmXJNr2a2ozLNEtU4qztoY28V7wO9of33vsYDff6cU700Uzx U7Tx01C0OyxjEKGjkhfcN4YHFWLh2UAecHYF2vB4rbJPhO6243FExkL2x1uEOcyxwJiGn1bL 98Rl+oleSdXIoVZPnFqNSuScn45hjOfRr5J9Qb8x8r7eSw8hvxpxNjXizCHJ/1rzmtaB9TyO cx3Q4ohRB92jxxHDmFz7ImGdsbs5f7R2msgcMfbiHOb3xF5KiFxabMSoBbYWvEEnY94m2L6P /M1H7u5B/3H2uU2Yew/s3HcBv2X4jcD54olQthGX7wCSPvA7BfNr71KrVkqN4PED3r2Iw07K A6X50XgvMNOC1J+y0WxB2nyWVEKaj77HdnU2ncUMdxGZfId2iR30dVFFs7SZyN0RlCd+g1z9 mA5qWbRWvEYHRYqaWRfZNFnDt4PWibcl29+klWxXz0LfT7ViHvo30iNiLdVrJ8G9czRUPIy9 Rj/9B+DJBPT/EOPaUC5SrVaF3NqF8sfmcW4n5+g0qxliKeXJfhmQvjpw+ayWYVWl2FP4y+VB /sLXtJ+Oj7fwT66Tx0U/biMO0jzE6QKQY8mBVWoLdQCH1T9SsbacvqscM7sR1xIXlmbqokB5 EpguCug0sAPlaZC/BE5YOt5uBfQWsBNjvwz5An8XMNSFVMgStkPAfuDXTl0meJ5b2TOhB8zu QfqLuGsA5YrZzXC3R5wLMV+huN/sZoCLpQxjO430bKOR2iTY70U/l64HkE8v0gSNzH/fzqdP A375GXGMZK7R2Q/IUZ8BFzJkkKV9N9yxb3cK7O92QH73iffJb3GIPqecNy9AVinnyac9Bg4C 0POgZzvxdPYJ9h9Ju2v/wBXimLvtbt29r7fT1RdobSYcHqT58DTNZ4gFaA+4de8Zms8wXkXd qzfr4uhtUEtTtQPsEzg46WbdeJAmMdQJ8HUM90HOAWn9TZwRALeV/YfTEgbnLkPtxPcakK4v oMWMjLgWcly1A1a9sz/Ovrj3B/5FxBu0DHIi5FzIcshSR2bmrDtv3TbnLLlVG1du5P+3Mf+f gNx5Dej9D+1lHlxVdcfxX97dEhTDEjpJBEMHitgoaGbaSnUKjTQgIEJDwiIVkUcEWVR0rEUH qKBBwVbFUqRIcaMaoNJRcGOGuhTctX9QdWq1w+Yo7WBRGCXm3X5+55778nJDElF8M5/53nPe Ofece7bf98COb7utPGGtQhfw38OHDMZH7sKfXCKLRZo4S74cCOs5h8ahb5NH9M6cAZ157kre Feh9Io2HeZ5H/q6IMOWeKuusrywhb6utm2/fVx3Vb3xJ5Ohn8FhUv7EBruT5f0A8b/wX+hy6 ivIfU28J+nz0f9MU0tfDNtIHSM+GCTzfifZAz4Tu0I36KxX1I63uoSdcj33/+KqKZ5lGP8vQ Z9CbkneIr6zxfHagybtGPP8dqWfvEq01GgfuTLvxfZtz7z7t3XFiZT4zubg1YROe8mT10epl 1T8b/2jV3N+Mj6VdkaJY6U+B+lf1zupfUX1/ve+Z/tTQr8tMv2zcyD1b8z6TtdAFTrU6izJf pE4P3+DsKWR9H+Zu9JBC+hSojQjfJHYVEuu2c+4eRl8n3Qs9HMe0+GxtdcZ2ENNOdPp4Y+TX iKkVlikJ2sqPOddyoZKMxcdLR7H7a8fyNmJ0bpz+puk4zscU/EQqlGBI+IyS9KWtfEAH6Y58 7vGmk77juNMJXxKnk7T6P7n2Yj9TKqVZEvvueNG7hbul2fvHfUju4+x+s2nG6Ge5cA70tzH0 Ac4L/H/YC4hR4d3kLcj/UiryN0kF6S1A3Mz8F03rf+gf8+4QSR0Jm0jfTLqL+7opO8GS7mg9 J9et+nPjDxkzcw7eqf2XgXAedIO/wJx4rvUOSdvvpoi6es91J4WH3Tcg4QE71B/INbCJdCHp Qs7iIr8r5/YQ+RPPt6Kd0E6c72OhjrN8jLczbPLnmzIj+K/KvU6Gc87PdXfxzj3hi5zpc9yM FAYnSz2xczExtIz/V1J3KekeaHHQWx7iPU9Rf5nGAP8QcXA88bBAYwft1spamEXZi91Dco9z kgzlPX3dPVJk9WyvUaZqvPIHSBeNeeSdgfY3ukfOcSfLUBjM+87XWONsYI3soy7xJ1Uk25zR ss3dKPN43+ZODbK2YKeszU9LVf5CWek3yEpnjSwmb03wG1njl0u9viOOqxoT42fMVF7Qy8T8 OaRLrVbG35z0BKZ/k2UUcfmB3HbjevlVxNJDfD9ta1878jbE+NshzXe46JFkezpGqYbwtUhl ho3x12djfq1Mpp+DdUzN2E6Wsc4C7n0a07X99eg/5FL3VrBjnOxL3Bbj0tSWF4q9Cc/jYbjO s0Gku64rs5YiaryPzHxdqHPmdWYPF+r8h0/r+BhuoHxKStyDwBrSfiqsrxIYn3qX8mvZo3PZ K6xBdwWeqUGWWCgbrjf1Zpt6Q/1qGEy/6qjXEO5tRm5pJtzr1sjtBsZL5y9VFD6Nzku9SluD pNCM37X0abmMcy/DD4mUMo763cVuf/J1fY4D5h9+Rbqv+XarZqyGUK+Qe51+I57KGSDCf/nO eeqvGDdbNnhSqoIhrNeTpMp7XPo6V+Ff/spZ15O5G8G8FspiZ7ec5p4r05yuklbyqsI38g6g OHUl9TH576J3ka6XSam35VLGaxHMhtv57kbDK3gFYL9cbZmupBryvsv/78NE+9wreiZvkGw1 xO9okPU5UC7cDY2pe2i7UtKpp2hjHX2hHacL+y8BdS639LftDHPHs8dackES6qoOTEK+6veS 2PzSJOSrViYhv/IY/WirXFv9aCu/XxLy+52AfrT13j5JyO/TTv9GJiF/5HH0o61x7puE/L7t 9GN0EvJHJ/vB+cQ9NrODu+lG9B0b7z9CR6GsvsyLPHO/COts+h1b7vewCu6Fz6DSwpkXTqFM PfofWA9jm8m8jPYU84vbCVfA96E2akvrZp6N2jbYNjOPR/WbNqEvJdLfgf1Re6ZtPXufQfvA avt9S227m6O+Z1Y0l8/0jL7R1NvcTOjAz6lfhlY3k9kSEb6A/hneg522X/p8mh0P/eYn9V3N 54IcdVdzZlwmQqwuChoidW+UUebMfbNFrLranId75BFz3oWcfedLhd8ZH3KfVKpv0DPcm27K L/PSxCbBn+AVjF/4t3ju36TE2ydT3Lky1NmKLx7GeUsb7u/kEn23ntvqOZzb5CIYozGMc1Nj 4UjO3PpOTxj/0oUyRe6H9Pde2c6dbak3QfKo7wcDSN9JXL9fbvBulPn5c2S7/wl93SV1xKsy f4oM8m6W4fHd1p8jBd7J+AKr+atkWnAm+Q3S290vPQvq8XVvyRjG7Edx27HXcgMpIl/nbJtd f/BlOYwyfaa/+DDXLceP4ZlMvP4FY5I2/Rmt8dN9VFxnkYh3kNh9ofQPCvBeA2VpQbGs84/w HT4+tVz6ZNvEBzgN0i+4Qs7x6qWfV8McleOb9zLO46RTrJzt24NpEniTwka82/3uDOMXu7kb pNh4B2JXVuN3NMgqb5EsZ00MSPqa2EdlPYVn5rgmbiP7PajGz+z3W83xG2bcyR/h9pByrwdr B9/RSm2fgh7yCGWXxX422C4jAgddL3X+rVLtXcS4dJfq4AXpFgyTYvVnQWB83RyN0d4XeNFq 6cfcXGD3+y9B99Iwu8evI/9t2BjtR91fmm/2JnlNq23+lXATzIz+1//ChdFz08Ho/ea/m6Ly TezDcDnDllI/avkgwtxDeuf6VONHI2/dUrO+3qyfqg414T/bUt3DrJHuWT8c+8nWugKdEafx eR+wR++mbm/wYx+dVMquxKMsiNR4Q9WHrT6oa029XlKzvroNbcu/5vjYaJ/FGvnqWxJ6qdV+ sb/uSLP+u4WGoU2fkvXrHWmtFBjfaTW4g/MQDxqrzS/MUb/V/SlXzZyIY32s+vcRjPtt7jq8 aDvoulP8m1kDLalVnLvk8mPhE0mUYHZLrM9vE/+31IP8siThpwp9/nVE+AfLAcsDipMnorh3 JQk/Nejd7Rj499Eu5J8VEbwcYfx/OzAGErCD87sZ9TUWtgsuQwkOWpbFhKESj3s8jvG48G37 +e4Z2T7H7dv3ftN5/KbzcqK+u72+58Ke3Aex+sox+838GD6N0POJst0tPuP6LGyAVywrFPZK Kfv2sDOd9QS5dVqtgzu4myo2rXtR8XF2QXG0D7gjfRwhE481PsH0aP0Fp0fj5DXKVOu99vEd nfV8V+zZ17dgjNxvzoJaKdOzhbir+/xs9zmpa+n5wmrWTYnuDeKkR/mu3nVSlXo1fNCbz5nw SfiStxAvALS1xPKyZV3k/cLH0B+bcR4kT6OP5sLd9jRFy9DetfCw9dvqY+dFZD6M8pv7FZ+9 zud8R6OUqG9wh0iJ8S8zpR5KnAP8j1/gG5Y6U+WnGjOcH+Kt8B/qF8xeEOnuvo9GdGZcxjiP 5Ozvclni1jBOoJ7IzNMOYoCW32Hql9pzsb+25cziHP+nlKUOUI7/qLdU3+E9IfPVFzncKLyL WRdjKTs2/LuzCh1u+Rzm0t9amZlaImc5dVKRegu/04P8a+AqnovRQpgIa+B6OcfkN7JOjlIe HJf0a6gnaahIfWFZHqH/51VKOrVV0njiNO+Lyu0ydSJ8Sec9b9pK/5/9soGN4rji+JvZu/MH Mnd2avPR8+3aMedgJxjOUL7xnSFgEMh8ptRpcB35AIPDIZ8LSqXCoraKUKI4oVXakBbTiFQl hkL3InK2kY7KhRSXr6ZAVSCEpFVbGhFXFSqlJdn+Z3btQEhEVaWqVI1Xv/fe7Hx4bmb2zXta LcZDO45MSUNEoRW6tg/130K/DCIQjMfec8aSdYNtcj5q471Gc3NX01zffWC73eON2T3sKs3w NFA+9jQPTMJen3LzBxFHnQZYLXsXyv08RY0C7SotkOy0e7Ry4GrvfmrxzqSHvB8gPriEc3CF Znj/Ri95a+gB32LcY/tInKXpQOR2qz1J+xbO3TJ+zj7Ffoy53IZvJRXmHKV52EPC90GDmncB aLZC3keEM01MRG9dTkSGvENzvzUZ52bNoW/gO54LHF/kxFqfQ99c8e3Brpd37CtU7MRxIof6 EKtli+9hGXxDLvoscb/hJThPPxRny40F0dXex98Uea09mY+2e/hiCrl9H3XyUnsL+A5YgHG/ jzxmmoBdt18Q3FbuEXzWZc82+oJnEpgJe+bdZexnxOWOvfXtoFkCTw3aCRqoQtsp+jp7fa+y r57KBbwM/2P0J5S3Iq/bhNxQ9A3du8xfo/sF8ryV313Gb3pYMPS771XOw9kCg+dt6Ex/2u9P 2iJGnot7JeN71T6H8uvgefjXPQIP2Tbqut14bbs2DN92O3LQ+VTm+HD4xiSF4L9Cnmdw9hD3 O+PRffBNtcI3ws/fEneEe/89hXH/KeJSbST8v/BliBXd8UWeVCf6izgffm++8H3eibRC+Frh U+WdgVhU5GnwN83Ct/DjVM1vOT6InZOQ8EVaPnxHLeZYK7W0eYXrU2oph1fjt3zbQfPbx6VP Gu74LI0wXlr4M9y/jr8q1kY7/oufdXwQv4w2g1wHf6YIvoXDDuLO+XCvvJv+4fhJ6Qvhp4Ut chc3f/KLbxD+InaveMmNLbs+pnsH9b3iQrdPl9vn7vYNtMxzCudkN/ZO3Mlv0FjvSho2lHcR VYv19/5B5it1qBcxyEdxvrjzxD0p9wl7tAIx0XvEPp4XeM7RMrG33igViLsL63QMnL1NNzrI e1qs4x8Rl+Xi3l0o/wd8HMYvxDm97s5T5CejcE6fHsr9BnO5wVyDaLpnF+3R1iAWGk917n1/ +Lb8do9AnDPvcXpF5GxC491JtKtz7g15hxwFZ8CvwPvgPLhE9MFvsacrxboM5UOdJMbs9l7C eh2jnOyFNMrX48Qrmklt7ClqEGBuLwrw/uAQr+K7En48ifXEGQFB36PIIRfQQudGoAqFQqFQ KD4DHlcoFAqFQqFQKBQKhUKhUCgUCoVCoVAoFAqFQqFQKBQKhUKhUCgUCoXi/wJGlPcY/ZVm 0A8oizgFqIoeIfLs8xSTF2Wi4fQTSI3E3zophZ2FvutEb/k3iU64tkZZjLm2B3a2a/tg+107 iyawIrRknhwxJpvn2oyGs5+6NoedcW0N9knX9sC+6No+2FddG/NhN2gvGRSh8TSBJsJaTmsp Dr2IErQBtNOTtFG+mY1SG2whm/C+RbYYh5oYteIxaCnerUH/dkrKUhw6jtabIJvRMga7BX1F 2xbZpgm0y/Ga0eYJ6DZaj3cJWv2fzGWvERk/YaKxfG3cWJTYkGh/cmPcmJ1o25hoa2pvSWwY Z8RaW42lLWvWtieNpfFkvG1TvHlcrK2lqXXR8k9QRkvSaDLa25qa4080ta03Eqs/fej/yTIu wv8R9WvoqyiJxbuz7t8r/Zc2o5uWaw+kwiP1M4e1sXQFcG2sVVmsd2vlWrE1XY+mtftTBYUR f+whzcBBrpLSgEyAAyADPNSohfA+ALkVmOAAyIAzwIfvJyRrDZAAneCKqNGKtaBl6IFYuTYK fUfhA/FrI2gA2EAjHbIK1ING0AE6gU+2E28SYCvIgL/Imqg2wtpRjbmPsJ6WKrWuNSKLTU7x y4/JYuqLX3L0oiWOnjPfaTbNaTZhovN6XK2jyx90dMGYiCl0bl7kSKxIK8KPLMLEN0Iy/nPy w1PotFsrpIOAaz73TVQrSJWFI50ZzUNM4xrDJur2EY1ZefmRWC63+QAVkM7f59ecGn4tNTw/ 0hlbwN+lAyADNP4unnf4O7SVXxFrDlkDOkEGnAYDwMev4Hkbz2V+mfz8LaoCNaARdIIMGABZ /C3IAL8k3JiUwq4BnF+CDPCL+FkXIf38AqwL/AKm9mtr8tRItzQqq1xDH+MaIz7vGgVFkTR/ 07o5FicqjJ3GierVSmkWVWul1pgJelobac1o0dP8dymjUt8dG8/P0kEABw0ZAAZYDL4CNgIf rPOwzpMJngO7wUGAUwYZAAbvByfAeRoPomAxyOZnLPybND9thWv1WBE/xd+gEVjxk/wXUp/g x6T+JT8q9XHoEHQ/P2aFdIoNQz2hTwA6AF2Fei//WaqsQLdj+TyDtdMhq0ANqAeNoAP4eIaX Ws16AQbppf5sQkuLrkr9I3o5m6Lr9Gh4Ng6gIUR42kxYEJ1GZ5hHwy+8iKIQ4Wd3wBIi/M1n YAkR/to2WEKEWzfBEiLcvA6WEOGGRlhChOuXw4JI812vl5Xrk+vXMyPm55uxSpuxSpuxSpvJ wzeLh256xNxesioqsGI7o5VjK3Szh5mHmbmUmS8zM87MLczcxswZzFzFzEpmBpkZYmaUmb1s CpbCZNHX7ihOjY5kZj8z9zMzycwwM8cws4yZBpscTfMSa361VA9LlYqJjw565ix4Hz8vwYqW 4MyXwCdkIE8DW5aiaGSUOo1HhYQuTVXUOOVx0yKJWB3vQ8c+bEMfvQ082KA+HKM+DNKHAfyQ NaARHAEDwAY+tC7FxDuk9ENWgRrQCLaCAeCT0xkAnBLuFA/IiVW5k64XJd6HpxRPCS+JFgeC gcpAndYRZP4Qqw/ZIT6ZiooQNRTkZ+enWd6hG3l/v5FHObEc/izvoGJsxHOu7rBuFutp9j0r 3KvHCtl3KeTBqWNTKczGQE+hpCxPomC20BMpyLugI1bwEXTzW+EH9R42XPQ6pN8M/l6/Gkxz mH8K9uq/MdIeZunn8KbrkH42uF0/XpXOxpvD4TSD6jFk0+7gFH1/v2y6DRU7LX2LUIf0rwfn 6euDsiLuVKxKohT160vDDXodxpsTfFyPJjHmIb0muOpfjJbPT9swFMfttCMpv1Y6BBUtJVXo tGHYJsTWjaJSSrJKy2GFdijueihUldhtUlqOiAvS0MQukzjsL0A7OUOaUnbhzF/BnzA47Nr5 OWkZGpNmxX7O933sZztO4qklj3oKbb5PPeFDIF51hg/2YVwE1RKiwzdpF2/nZuUj2ZJfy8/k eXlWTspT8qQck0eViBJWhpVBpV9RlD4lqEgKUkbdzkWOIP7oRvvCYPqCUAZFPSxBCedA+Ohh RUKvELsXMCWzlMcmO6sjc0tlv0qai/vXKuyOlscsYiKznGfPienKnXWWJiaTi28tB+NPlKtM +uBiVLZc3AFpP8Yiq1YbYTyyfxgD+2D/kFIUHdtZji5HsiMvXuq3FDW/JNcpeqM+yY7MksW+ TlI2D5XOJDXZ55Jatdr4Cv809Da+BEOtdiCLr4x10ANZnVLTxRuCQyq+5BzfMZeCU/iPGTik KgmP++JxKd6ec9NgOBcKoZTgUqGQ4IIYOMeeNnRnelow4yqyBWOPq38y5ynOpFKCGdtD54I5 H9sDhmUFEo9zJBEXCJ5AcYHE8YRANq6Rxz5y0EMORKQAvmbiHjN00WWGLjhD/jc18oTgkwyt V42GZtQ0o8FzjX3c2Y6yvS1VdeoUHCoL3K9t1bfBbjYY1Ro6q2u66mSqt7ir4M5ouoOqRtly qrmG/i2Tyxjapk5PCsWF9I1YB71YC8VbOitCZwsQq5C+xZ0GdwFipSFWGmIVcgURC4k9XrQc BeXpatWzJ9JAP9+vtViS5sfC77Ni82aS0d3YKT+tHKMBQtmglmdDPINrbmVuBVz8nQLXMJfv +q7obiYZO8XHvivM5REtj0izZbdQ1Hine5fNE5eaLVhwryT2vxL3GSy3qdtNhEw2UzLZ8lrF cmSZqzWYElvsagMDhts588RHXFwEMRDogaAtgRYK+eDfz7/l21V4C/akHyc4l8D8sE8DLGGW Jf4pKFf4XKsV65SfpeD3YFM+QRsTbHf78IdNCPLuEcy5m5stv+avRdO3XkvexO4uSS/BYpHe ijUJ+S3AADYbEHkNCmVuZHN0cmVhbQ1lbmRvYmoNMjQgMCBvYmoNPDwvRmlsdGVyL0ZsYXRl RGVjb2RlL0xlbmd0aCAyMjY+PnN0cmVhbQ0KSIlckM9qxCAQxu8+xRx3D4vZnCVQthRy6B+a 9gGMTlKhGWViDnn7jjZsoQMq4/f95HP0rX/sKWTQbxzdgBmmQJ5xjRs7hBHnQOragg8uH13d 3WKT0gIP+5px6WmKyhjQ7yKumXc4Pfg44lnpV/bIgWY4fd6GM+hhS+kbF6QMDXQdeJzkoWeb XuyCoCt26b3oIe8XYf4cH3tCaGt//Q3josc1WYdsaUZlGqkOzJNUp5D8P/2gxsl9WVamLd6m kaN4j9tCyefgHsltzJKmTqDGKAEC4X1IKSYQqiz1I8AA2cZvMA0KZW5kc3RyZWFtDWVuZG9i ag0yNSAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDI2NzU1L0xlbmd0aDEg NzU1MDY+PnN0cmVhbQ0KSImclgt0TVcax//7fDcP09wkvXtr4pGcc5N7EyQlkqAJ8SrxSiIa qahXMkizVCQkRRCiFFUUVTReQSSEUISiiNfQYYZoWjXUI0pacj2KxEgr6T5Xaq2xZtas1b3W t8/+vv3878dvHTAARuSAENs/rk3wbJ+TuTLyg7TEkalJ6QfmZlcBrBPgPWfkxEyNqPFKQD0G OK9NTn839ap3/ESgRSLgMvDdsVnJtw8OswKhJbK/LWV00qiaBJ9DQLs86bdPkQHTsdYLpX9B +paU1MzJgfEJ30m/FkgdODZtZBKaBA8FNsZIPyE1aXK6dZiyBsy9QLbXxiWljl5fcC5S+icB w930tIzMjKdpN8Ea79br0yeMTt+h3ZXLbVwOvKqCDDa2GA5wdsh1CJEtVj//sidIZnWKm2Jw IAeDIymG61Dqu8NSj4YUHadpOALUwTGsLowled7nezSwdXodHXSI12eTOwYoYPYOQnqypHjC oBik7wpnWecoS43k7k7HfdTXPx9d9zW5379In9XX1tc0TMkavs44wTbo07CfqT3FUQ/azLZR O+UVxUXxoCJWwSrZTQU0gTIok96niTSJJlMWTaGp7Ed2g0poJ+1hVdQBBqncEU5yxEb4C16B i5zZFW5wx6swgcs1N8Zr8IAnmqApmqE5vBQ3ClHcKYhC2XbMwmx8iDmYi3n4CPPxMRZgIRbh EyzGEizFp1iGz7AcK7ASnyMXq7Ba4QpTBLWFD6xojWDEYTDSsBZrsA7rkYd8FGMnvsAulMj9 LcVRHEc5vscFXMQl/Evu0z08wEPFk/ZTJPVRmirOSjPcpnAKo45sFztOu9ACw+gr2kZ76UuK oaN0kI7TMSWGDlEsDaAjKMRVZmO3aR8dpn60m0rZb+wZuyVPyBtmJGAEriuKYmAP2SN2j92n HXQC9ZhG+RTB/s2esnxWpDRRGrEa9oS2yLMKgYp2aItu6I4e6Iq3MQjxGItUvIdTbC8rZafY GfY9O8cus3J2hR2Aofk4eYKX5Ck74p0/7gANpTSaTvNpAa2ns3SeHlG1YY4Dd7C6dvE67b3K +6naWPVSe6rR6iB1sDpEHaZmqyXqCbVcvazeVx+rdZq75qP5aUFaqBauddI6a5HaIG2ENlIb ry3Slml7tAPaYe2aVqFVanfMDmYvs4853NzPHGMebp7t28r3nO91S4blsRVWxepidbcKq6e1 udViDbSGWmda51mXWtdbi627rWf8kvyS/Wf4V/nXt6oPMAQ4BRgDmgaODZzU2iPIoyC6sGmh +VdDHf7jPufRcHkDZ0tti2gjlVE5VdMTwzwHi9QGrzrvPBWqp6qpvdXYBm0j1Bx1r3pSvaBe UR+qNRo0k9TWRgvWwuzaekhtw7UkLV3L1BZredo+7aBWJrXd0n42K2Ynqc1ijjBHm+PMs8yL fYN8f7AkWu5Y6v+ntjy7ttN+iVLbRP8y/wctIbU5BrhIbYmBmVKbKIgq9CjUfoVd24u3yZbo eV2xvdxWmlkvvdbCZSheSjV6evRyVE8VpcDNBxWlN2/XRkowPgPubdXjTyuA2hW1y2VsuG2I Tb8ruNFEtnWVdf1ejLtJz++y6rzqNdW51Sts12wXbOdtX9tm2LJs6TpobQFAVU5V1qN8oLIb 8BNV1snSNb2fTb+LyBiY0R/w6vOCM99KMsLJ0UnO5OTp1FnmS6WVOd/TKyUulrmcNeYYi4wl xjpX5+ddXN1do1xLXMtc77g+dvN0a+4W6BYFuI35Y51uo6Ql6+aWIvNce+xIQ91Ft6uAuxzJ PVg391CeIiTVxTZx5L/tmB2qRfZ8c4MntYmLesnzG90878j8nudje+ShvclLzDSFmzoqHsae /4+Zxv7GKGPsn2WmqTOFmLr8eWaaOinMFCGZSZJZknkUIakWrDSVrAujWPabMY5VUjg7RfuN vSQ/ZrBddFRpZuzDLlM2DWDPaBMVUCGzSbqp8iWa7extIenbVvI3RJKrawO5Zkoax9vplYDB xt4YJvmlUywNU/ABbktGr5WUzpOczpcMLZaU3mnndKkkteQ0M0hSX5Csvig5fcnYF1clq+/r tMYz5iAJ6osNsGAj/FGAVtiCABThdWxDILaiDbYjCDvQHnvQAXvxBr5EGPYhFLsRjv3oiAPo hK8QgYPojEPogsN4E8fQEycQib+hN06iF06hD75GX/wd/XAaZxCFfyAGZxGNfyIWZeiPcxiA 8xiIb/EWvsF3yGEkCXwZQ+QfzVBc0dmPRFTgr/gRSbiBkbiJUbiFZPyE0ajknAukoApjcBfj 8AvS8Qjj8RgTUI0M1CATTzAJtZgqITEN2fIxzWAKpjOGO0LjY/h7wszHCh+eyscJX57G0/l4 YRFWPoFn8Ez+vvDjE/kk0YJP5ll8imglAkQgn8qnidd5tmmTqZxPF635DNGG5/CZIoh/ICaL tnyWCOazTcWmy/xDPofPFSF8ngjlH/H5op1oL7L4x6KDmCJaiqlimsgW0/kCvlC8wRfxT0QY X8yXiHC+VHTkn4pOfJmI4J+Jzny56MJXiK58pejGPxfdxZs8V/Tgq0RPvlpE8jWiF18revN1 og/PE335etGPbxBRIppv5Pkihm8S/XkB38y3iFj4YRNaYjOG4xovEgP4VvEW3ybieLEYyLeL eL5DvM2/EIP4TpHAd4nBfLd4h5eIIXyPGPo7i3XZnuWxhQE072ZeXDPzdPY9uLtrca07xd2l Tkvbo1UKFHd3CTGIO3E3EmLEXQnufvhw/sS6lsMqhxqHNQ710k8tkP5qoQxQi2SgWiyD1BIZ rJbKELVMXlbLZahaIcPUShmuVskItVqtUWvVF82aqy/VVzJSRqmvZbSMUd+ob2Ws+k7GyXiZ IBPVOpmkvpfJar1MUT/KVPUTb+GtvM06Yh3l7dYx6zjvsE7yTusU7+LdvIf3Wqd5H++3zvIB PsiH+LB1znLiI9YFPsrH+LjlzCf4pOXCp/i05cpn+Cyf4/PsxBfY2XJjF3a13NmN3a2LfJE9 2JO9LQ/L0/KyvC0f9mFf9mN/DrB8OZCDOJhD+DKHchiHcwRHchRHcwzHcjwncCIncTKncCqn cfpr5TI4k7M4m3NwEIdwGEdwFMdwHCdwEqdwGmdwFudwHk64AGe4wBVucH+9kiBctMXhEjzg CS94wwe+8IM/AhCIIAQj5P9nKXz9lwxcRijCEI4IRCIK0YhBLOIQb2aYmWaWmW3mmLlmnplv FpiFZpFZbJaYpWaZWW5WmJVmlVlt1pi1Ng+bjy3AFmFLEE62FMcRjiMd19vSbVm2EOEsXISr cBPutpK2A9sOsoUKD+EpvIS38HFcJ/yEvwgQgSJIBIsQx40iVITZim0FtiIRLiJEpIgS0SJG xIo4ES8SRKJIEskiRaSKKyJNpIurIkNkiiyRLXLENZEr8miTyBcFolAUiWJRIkpFmSgXFaJS VIlqUSNqRZ24LurFDTlGjpPj5QQ5SQdbFValVUVbaQNtpGG0mYbTCBpJo2ksLaR21J46UEfq RJ2pC3WlbtSdelBP6kW9qQ/1pX7UnwbQQBpEg2kIDaVRNIbm0FyaR/NpKY2j8TSRJtFkmkJT aRq9Te/Qu/QevU8f0If0EX1Mn9In9BlNp89pJs2i2bSAltAiWkzLrGKrxC7sdntDeyN7Y3sT e1N7M3tzewt7S3sre2vjYfyNpwkwXibQeJsg42OCja8JMX7msr2N3fH1LJVVZtVY+VapVW2V WwVWoVVEPuRLnnSJvMib/MifAiiYQugyBVEghVIY7aCdtIt20x7aS/toPx2gg3SIDtMROkrH 6DidoJN0ik7TGTpL5+g8OdEFciYXciU3cqeLFEXRFEOxFEfxlECJlETJlEKpdIXSKJ2uUgZl UhZlUw5do1zKo3wqoEIqomIqoVIqoxqqpUoqpyqqpjq6TvV0i27THbpJN+gu3TMppoDC6b5J NYXmiikyaabYpJsSc9WUmgxTZjJNOUXQA4qkhybLVJhsU2lyTJXJNTUmz9SafFNnEk2oCTeR JtokmWQdxg10OAsdwXbyoAodyQ11FDfS0dxYx3ATHctNdRw30/HcXCdwC53ILXUSt9LJ3Fqn cBudyo76Ckudxkqns6Wv8hs6g7XOZNZZDJ3NRudwW32N2+lcncftdT530AXcURdyJ13EnXUx d9El3JW76VLursu4hy7nnrqCe+lK7q2ruI+u5r66hvvpWu6v63iAvs4DdT0P0jd4sL7JQ/Qt Hqpv8zB9h4fruzxC3+OR+j6P0g/4Tf2QR+tHPEY/5rH6CY/TT3m8fsYT9HOeqF/wJP2SJ+tX PIUdeCrbeBoTv8XXOJfzOJ8LuJCLuJhLuJTLuJwruJKruJpruJbr+DrX843XB7vFt/kO3+V7 fJ8f8EN+xI/5CT/lZ/ycX/BLfgUH2EBoAAE7GqIRGqMJmqIZmqMFWqIVWqMNHCGhYOENaDAA g7Zoh/bogI7ohM7ogq7ohu7ogZ7ohd7og77oh/4YgIEYhMEYgqEYhuEYgZEYhTcxGmMwFuMw HhMwEZMwGVMwFdPwFt7GO3gX7+F9fIAP8RE+xif4FJ9hOj7HDMzELMzGHMzFPMzHAizEIizG EizFMizHCqzEKqzGGqzFF/gSX+FrfINv8R3W4Xv8gPX4ET/hZ/wD/8S/8G/8B//FL/gVv+F3 /IE/sQF/YSM2YTP+xhZsxTZsxw7sxC7sxh7sxT7sxwE5Xc6Qs+RsOVfOlwvlYrlULpcr5Sq5 Rl5Rv8g09atMV7/Jq+p3maH+kJnqT5mlNshs9ZfMURvlNbVJ5qrNMk/9LfPVFlmgtspCtU0W qe2yWO2UJWqXLFW7ZZnaI8vVXlmh9slKtV9WqYOyWh2SNeqwrFVHZJ06Kq+rY7JeHZc31Al5 U52Ut9QpeVudlnfUGXlXnZX31Dl5X52XD5STfKguyEfKWT5WLvKJcpVPlZt8ptzlc3VRvlCX 5EvlIV8pT+WgvJRNeStSPqqB8lVC+an/MVwXjl3VexiAtx3flwkc/fjl7P3BUbExQEFUkBSV sOBesTEAC+yiu1l30t2MZmMbG2x0g7Q0CGKLBYJ67/NfPAiKAgbFQbVgVRAblARXB6VB9aAs qBGsDmoG5YEfVATX/P8KvaMuRvWJuhTVL+pycG2wNrCgMrguqApcsC6oFawPgmBDEBdsDBRs CjYHW4KtwbZge7DDxbuVLsEVuURX7JLcKpfsSlyKK3WprsyludUu3ZW7DFfhMt0al+XWumxX 6XJclct161yeW+/y3QZX4Da6cW6TG+82uwlui5votrpJbpub7La7KW6Hm+p2umlul5vudrsZ bo+b5fa62W6fm+P2u7nugJvnDrr57pBb4A67QnfELXJH3WJ3zC1xx91SdyKqf9QVt8yddMvd KbfCndYX6qve6q9e6qc+GhB3Me5K3F9x/8Rdivs77nLcv0pWmlKVoRSlS6qj2rpeEYXKVr5y NU45KlCexquubtXNul036Tbdojs0X4u0UEu0QItVqKVqrtZqqTZqoUfUSo+qVOVarTUqU4Xa 60k9oafVQU9pvTZro7Zqg7Zok7aps/bpkA7oK+3XYR3UEb2kV/WKXtfLek1d9IYGaaCylKmJ mqAirVSl1mq3dumYjmq4RmukxmqExmiU4gVdrWqqIaq6YlVTUzRD0zRLUzVT0zVbd+te1VdD 3aP71ECNdFJf67TO6ZTO6oy+0Zt6V2+rp95SD72j9zRUQ5SoYUrQYCXJU4yiFaWrIsWRssi8 SGGkSHM1WXM0SfN0o27QnaqnuyKLI4siS1SiVVquZSrWCrVTWz2uxyLLIksjy7VXX2qHtqtK 67RHO/WiXtDzek6dIisjKyIL9a1O6LyO6zt11DPqpq7qHlkQmR/2CfuiNuqE/cL+4QCEuB43 4EbUDQeGg8LB4ZDos7gpJibmqhjilnB49I/RP0X/EY6IvhD9a/Sf4ciY2jF1YmLDod5cb4af 5eeHY8Jh3qDoFG+YN9wb4Y30RnmjvTHeWC/eS/ASozO9JC/ZS/FSvTQv3cvwMr0sL9vL8XK9 PC/fKwjHhvFhQpgYJoXJYUqYGqaF6WFGLee1CTPDrDA7zAlzw7wwPywIx/mN/Pv9xv4D/oP+ Q34T1POb+g/7zfzmfgu/pd/Kb407cRfuDifgHtRHA9wbewr3oWG1tmgUexr3x571StAYD3id 8SAeQhM0jf0eD6MZmqOFtwYt0Qqt8QjaxB7Bo15LPBZ7PPYEHo89h7Zoh/bogCfwJJ4KJwYH g7rBAXTBq3gNr+MNdEU3dMebeAtv4x28ix7oiffwPj7Ah/gIH+MTfIrP8Dm+QC/0Rh/0RT/0 xwAMxCAMxhAMxTAMxwiMxCiMxhiMRTwSkIgkJCMFqUhDOjKQiSxkIwe5yEM+CjAO4zEBEzEJ kzEFUzEN0zEDMzELszEHczEP87EAC1GIRViMJViKZViOFViJIhRjFUpQijKsRjkqsAZrUYkq rMN6bMBGbMJmbMFWrwzbsB07vArsxC7sxh58ib3Yh/1eJQ54VX57HMQh/2kcxlc44hV65TiK YzjuleIETuIUTuMMvsZZnMM3OI9v8R2+xw/4ET/hZ/yCC/gVv+F3/IE/cRGX8Bcu4wr+xj/4 l1GMZgw9XkWQrMZYvxOvZnXWYE36vIbX0ngdHWsxYBzFCGuzDkNezxt4I+vyJr8jb+YtvNV/ 1u/M23g772A93sm7eDfvYX024L28jw3ZiPezMR/gg3yITdiUD7MZm7MFW7IVW/MRtuGjfIyP sy3bsT078Ak+yaf4NJ9hR3bif/hfPsvOfI7P8wW+yJf4Ml9hF77K1/g632BXdmN3vsV3+C57 sCff4/v8gB/yI37MT/gpP+Pn/IK92Jt92Jf92J8DOJCDOJhDOJTDOJwjOJKjOJpjOJbxTGAi k5jMFKYyjenMYCazmM0c5jKP+SzgOE7geE7kJE7mFE7lNE7nDM7kLM7mHM7lPM7nAi5kIRdx MZdwKZdxOVdwJYtYzFUsYSnLuJrlNtbiLcESLcmSLcVSWcE1XMtKS7N0y7BMy7Jsy7Fcy7N8 K7BxNt4m2ESbZJNtik21aVzPDTbdZthMm2WzbY7NZRXX2TybbwtsoRXaIltsS2ypLbPltsJW WpEV2yorsVIrs9VWbhW2xtZapVXZOltvG2yjbbLNtsW22jbbbjtsp+2y3bbHvrS9ts/22wE7 aIfssH1lR+yoHbPjdsJO2ik7bWfsaztr5+wbO2/f2nf2vf1gP9pP9rP9YhfsV/vNfrc/7E+7 aJfsL7tsV+zv/7Ff5dE1Xlt8f3f4DJX924eLyI05JOap1VZLiTHGCAluDEFCTCESsyDmGiKG mmeCGoqaSRUtNdRMzDOlqKqhffXIfSd5MZXVrtW31vurv2+daZ+zzz5nT2d9kipuRcpQFmVV NmVXpsqkMqssKqt6R2VTHooVlCilsqscymF+Z+4195n7zQPm9+ZB85B52DxiHjWPmcfNE+ZJ M8U8ZZ42z5hnzXPmefOCedG8ZF42r5hXzWsqp8qlcitPlUd5KafyVnlVPpVfFVAFVSFVWPmo Iqqo8lV+qpgqrkqokh5P2WDmHOzpzOP0cRZxFnX6Ov2cxZzFnSWcJZ2lnKW9VmQ31AXrtzly ARAoZEcOOJATuZAbnsgDLzjhjbzIh/wogIIohMLwMa+bN8wfzJsewR4hXI39uTrX4Jpci2tz HQ7gulyP63MDbsiNOJAbcxA34aYczCHcjJtzC3ZxKLfkVtya23AYt+V23J7DOYI7cEeO5E7c mbtwV+7GUdyde3A09+QYjuVe3Jv7cF/ux/15AA/kOB7Eg3kIx/NQHsbDeQSP5FE8mj/lMTyW x/F4TuAJnMgTeRJP5in8GU/laTydZ/BMnsWzeQ7P5Xk8nxfwQl7EizmJl/BSXsaf83JewSt5 FX/Bq3kNr+UveR2v5w28kTfxZt7CW3kbJ/NXvJ2/5h0ogqLwhR+KoThKoCRKoTTKoCzKoTwq 4F28h4p4Hx/gQ1TCR/gYlVEFn6AqqsEf1VEDNVELtVEHAaiLeqiPBmiIRghEYwShCZoiGCFo huZoARdC0RKt0BptEIa2aIf2CEcEOqAjItEJndEFXdENUeiOHohGT8QgFr3QG33QF/3QHwMw EHEYhMEYgngMxTAMxwiMxCiMxqcYg7EYh/FIwAQkYiImYTKm4DNMxTRMxwzMxCzMxhzMxTzM 58LsiwVYaN4yfzRvY5F5hw+Yd/kQHzF/4uOcwmf4PF/iq3yDb/Edvse/8CP+jZ/wMxCsMJEF i5GEJViKZfgcy7ECK7EKX2A11mAtvsQ6rMcGbMQmbMYWbMU2JOMrbMfX2IGd2IVv8C12Yw++ w17sw34cwPc4iEM4jCM4imM4jhM4iRScwmmcwVmcw3lcwEVcwmVcwVVcw3XcwA+4iVv4Ebdx B3fxE+7hZ9zHL3iAh3iEx/gVv+Ff+B1P8G88xTOkwi0khljEKjaxiymZJLNkkazyjmQTD2GB iCjJLjnEITkll+QWT8kjXuIUb8kr+SS/FJCCUkgKi48UkaLiK35STIpLCSkppaS0lJGyUk7K SwV5V96TivK+fCAfSiX5SD6WylJFPpGqUk38pbrUkJpSS2pLHQmQulJP6ksDaSiNJFAaS5A0 kaYSLCHSTJpLC3FJqLSUVtJa2kiYtJV20l7CJUI6SEeJlE7SWbpIV+kmUdJdeki09JQYiZVe 0lv6SF/pJ/1lgAyUOBkkg2WIxMtQGSbDZYSMdJbLbjpyO444PB15HF6Oo45jDqfjuMPbccKR 13HSkeLI7zjjOKtS1CmVqtxep71uGguMxcZyI8lYYR9PWYnswSRUgtJhy637GbAm/7fvvu+e k1Y/p6cGvexr7rXkYa1MHmm7WHK671suk7jnv7riTVgvP5eSOaPY0gb+FJexoP2Ltkd6G/Jn u9GuP519Ow7RPtpGw9L7ybSOVmbQV9IGGqF3TNZ/iWloQY1oOM3XdVNNcVEABVNr6qRnomkx JWVwtaMwKqc/oipao2MyqPvpFm00nup1s96QP1lL6UmbtaRZVFfvV4Um6ttOoRU0j+rRSD16 iZT0+rKlLXWmGFpKazRvOEWmUxtQPNWhlvpstbSWoilKS3fRalpPEbSWZmh6MgXRXHM7ZbbE plnK/dBSyf2QxmreqZZYS7wlwTqEYmkgzaWL9IgSaULqLvf9v6HRV5FI0/UthlOCtqnLWtka aA17Ydu/wiatr51aN321VZZoe8ylRKMIzaRRFGdkozmUbJR/TTt/B5tonN77dXxDW7TekrR9 E7TGYrRdlunTB/6R1fAzsmq/6Uwug+kJtfkfT/J29NC+0Fd73FAtp6e+eXPqoL2rl24jden1 4iwVjSo0Wlt9kVGKrmu6Pw2iKKOgUZb20GjDk/rr9XM0dQptNcrqtTG03vCj3/X+ofqWb0Dn A8nIB5QWl/qn91BabFqfpI2tt5/ng+e14UN7X80HRmHDQ/vbJlqu5S+kWYbTsNJjukKpRhnD W1uuGB3VZY/W21baqfV3V6/wpFOG8ddn0Rxj7RG2jNk3z6K9ffxruSleR8psHV9x2ofW61jf SZNoo27H6dF8HUHTaJX2gSXal4bos76U66IKuu6YVqfrgLVn0Au5O9Lo7qPug+lyDz7nSk14 0T+po/mcjudAnSv+wT/4P8KS6ek1+yVLgB12w33HtjyTLTXUeKwnknTET9b1AP11fDuv9Zn1 ln21+559a6q/Xdl9UqNTB+q37BSdocO0m67Rce3Z++mmtax1t/WK9YEtzGbaD9oX0gZbaepD U/+4ny3KFmlrbFtsc9lK23312Fu/VUHUTL9VYfq97KLzGtkTM5WzTbKH2MOtD6xP7NM1W1ed 90bq3DSZBlV1RYS3ad2qZairRfPgpkEN6terG1Cndq0a1f/DeNXEtnEd4dnl8kcSJa+oP8pr O7t5oiyblCjrx6ZUWWLEH1sm7OjPwK5iJEuLKig1CAy3haOgLdQeInelQ9BLDZ8atEB76OHR QAG6h0BFg6IBKiAoCt9SBKnR9GC3TuC0RupEnXlLSrTgwiZ2dt/7Zt68mXkzs8vJl5IT46fH vjE6kjh1cnhocOBEf7yvNxY9fqznaHeki71o6C8cOXxIO9gZ7mhva20JNasHmhqDDfV1Ab/P q3hkCWJSmIdTZmaFd6ZsHmRppuo8eOHB+TiHkGawZn0wbvVWpLg3yqElx1unzRIkExb3RfeL XOCeiPq5gYvPa3qGKxG82Ll8gffMmgZT72i7fAvX8IMp0zA0LkfwmkIWXufyeoGr04gbmotM cZg2ico7nyQQhIRh4X3W5EeqU8t6mpG3sTNt7TPzguSopWBnKs2htQTBTzi0kdiDBH5NjPGe KBqi4khogziXWj/nUguX2s6jyU9uQcs+TjwlBpnCCssUljGiBXsvpg/ciBq6ozuzZvMgDoXR Of7HGbPUUJ9iqaV6BEAAUKpvQKSBAFRxpSQFxyUxkIOZ0ZIMgUYMX4jMzRCt8OSGjQOWxrgh p2WPU97Z2qxlAS6rjlrckWsE96W43zVCX+bJPIcNvRTbcjbLKly2o8ECK+QvmdyTR4ESeCKZ 4jw/lJteQAi3QrKLOh13Wtzo8PRMUXdwTrI23lmaDv0JvFBcsilNJJulkVeXMteNLY2H8Jnh zVHeiGKNb93VPE4mvKzT1HHWdf4zNLeGa9AdkyCMpjsZhruhsszKJB1JfPfYRDZOFcThJDfy Ol+7vOLmXn6zmv+Go/Lgvw08HTwfXCkWVkJZsFfI5JU8uZlZ0Z2NJeHqpnAN81XPrKSJaCFm P1zE1Qtmpsgyexui4zjwRPavNQzeGaWFjpMhE/MFtN41GRl79lNNaFEJ7Unx5Lx4wLw4A9wx mU9bFagisEDLiGOnLctwzx1FuT+y7u1jukMa/RHeGlWN95G31RvLzZqZtCa853LKPH0/rN3H cW56F5bCKOPE72tujHJzLDfjZkGxerPn3QKWd08eRSvyQut2WNt2x5fMLMvajpNletaxnXx5 Z+0y01XmlIJB50rG1kX5S4j/dkPj2U2Lq3ZRGhUnROp0yr3sbI63zLxCR5XVi3m3cUwwI6EZ zbsy0/+PXak5zH6sAao5R72HtgWxO2l6llpNGTuExtUElSwadNHEmlgU+StuWCtzqFyjqvFY kczyXCVYmJmV5KEeOFNBUYlhUD1tlJNwGSd8bcZ05zpc1m5BMh7Fc7SJs1XltF0kzlqVs7vc Znhu4dzcM/K7NredZhbSR+Ii/qL1FvjWPPr4KMEDicrRt6RMjyZXRrLmoVF9FFvZGO+IioUU E+yYjsr0DxlXo9ybMre0MUtXm7HVSShzNkoVhB31Q/aBRH0UWlUujXGpnXDAvirau6cjgczd RNIzjl3JtFq3Ki+DQvHpvqGMytA9zZVvDjHy8E+ivVW6diRLdaUZrsQ5izdRb+ZN98QN7dVS po6dCCt3Rgz0jF6kw+a6nRYtwdJq4fLOx3aaWiCaTCJaJcXx7ob2yVzrjT1voq9hov9w0yqO opbkcfRAH8ZtRbXMm5UoJbRKRdFeU+TKk/zdKFZl8PCx8Azef/CDMCbqwfB962khz80/MavZ TPASu51h3uTZaFW5Oz8T1WqnZ/exp6psbB/f196i14gMkyUmXZ8pJaXrcwvmbRVAvz5v3pIl OWVPWqUu5Jm3dYCkQGVCCaSJThPISajtlhwQ8trtJMCa4CoCEPPFsgQCC1QxCRbLsoupVUxG THGxpMDcr4pMuIghMBkeeoEnp83vWUXHtijY0O4mIGY2Gwcus/GSJPuCvJ4tTfIGNkn4BOET Lu4j3M8mMf2xOHQqdcdmWP7YgE3QJItSmNJFjujlnR3soNvYeQ3ui1xCwgZbF7V0zOJzKHeG yEb4DF9bzJMdlKYe6uVTixYP7CpEkSlehxrqKhpQIivW0FsAFy1isuaZGCKMxbFmcStKm5rL pEDX8XvoLBvlvm5Xp7ebNopbTogNiNeJL8LrI+v0qEPbqBEKRMMpbma5QfIH0fJFhqxFW8do K7A4h8modNNVr7nIEr7Vle4lQfVahQluBTU01vO6PnpX+cW4oQ8V4uW3LNd4MVuvCODeKm9A i7prQllZgNFB1hTZgtc6mkqivyM1M2WYZW9iDZLRQpMf2bwxMpXHhuOub0CEJaqLUVdAQKTj fRf1k+dB8UE7X975JVs1an69MYZvZ5MSEzT8hkyC5ewH+CvYOAP70UYBO06g8ekL3HgFGnef BOqZZcxV0PGdgmH0dU/lNxKhoV6M9nv4X+Rt7zz0QAz6YQhyyUhbfKjnWAxihxtO9A3FGvr6 GmJDyvBJOBbtHwy1tDSFw30nPDCxPRDHa+KjO9sDzSGpYySOP3Vb3W4eVLcH1I/+cKJfGh4a l0+Ne4aHutmLTbKfDZ88OThwRG5rxUmTp62to40NS81GM5F8ytd+vKujWzvw0rje39VZZ4/9 OJVdHD90oGsspne3+UPvSI+/8nnyjxPSp+3tkePDRzvjgyMsN9vaNXDkR0f6Dg9mj3WPn872 GrGjPYd8b7z77td3lZv//abyny9/jQ5iteNfrEezxh3f+dcOjH0BWkD8M7v99xun6fnn8Jkv Hg7dy7V/Fv4XTuuwE9AKJP/Nr0cAOhYeDn31i/bPBFrz0y560xRFFP29S8pj8Cl3YVVZg2ve HLyp3MRxDulvOP8BrMo3kL4Dh711Lu57G77rvYo0CteUDVgVz0ew6nkEV5T3YNIbhwXlL9Du fw3alZ9Am/IOhJTz8KrY5znI908AIrJnP5F93hkYEDY+i9D+WiJfvNeFP4PCpxvwApKElEQa Rmqt4KveoPC5serzLs1Ao/Il8q9WYnB1LxbPoCUi/xturKpEMdtPFMMqUSyfhyjWtSRiXksU /woJeymGP8X9/wHTSh76PeuwrFyBZc+nUJRfh5c9D2FCWcG4jMCcbIBXGYAJOQYTvl/BnHIN aQLlvw1Tig1Fz8sw57kCr8q/gYjyLcQC0OIbgMOev0IHjls9P4cZ2ud5yOd1iezZT97X92x8 JqH9tUS+IA2hP+x/3JdrcFXVFcf/9+xzzvXtKAgKCvJSUHwRjYQAmqgJiBCVhxKCEBohxBhM QAJDBB/lpaBYkQrUtmNpZXBGLSBqX75QZupQR5RWpTq2IPVZrVosEe7tb+17LqZ+sHzo8KF3 5jdr7332PXvt11r/4+dUlM3Aa5S7wgmUP8u1M7dKm3P2c5sz8xxp83bt/fyLglk62gW0Nyfr kBDNV7lfk+9mnBEvYQ62ZnlYu28TvqGKYCD7sFq9bF2D13SBX9uDwNa+LbYHbfH7kRDW4v9g fKvWeeH4bCZsZO0+pb5OdWFHyttVy5mZyv2pDaqhWOlwJu1Pqjb6ta4PN6smvIPnBfQzW8ez NfhfpKLwPtakXO3jNfjQmTPZQR3cDs6bjXMQxF1ymD/fxvu3Xpeaj/8V878tzCX8xM/nAj+n arULqrO7sedDH3BJe234Iz/nVH7OB3iR+9nAc5t/W2wNvpuJRjw7t1Z5bM2+jV/DPLaWB4Gt dVtszdti65/H+2treClz/FRXuDL1Dx7ReDdC44O/a3zqIw0LvlKJG6qS1PMakdqoE9xJujj1 NHdph0a4kdCX/leqnP9WBd/XiGC1xgQn62w3jLZ2Op0Yc07wvnpaOXhGw+NXVXH4IFXY+Y7/ SLmU8s9VkT4Ou5S2vfBj2o+g/kPanSqiWzU2ijQ2KOcOlqurtH83vE35LmiSMhPhXMpxUJ7d wzOy2v6Nbeqbra73s7+l/pZB/QGDPqdBR8q7YDvlznAU5Tfh9/Z/+Nj/X/vX8azEoJw1eLYP Win/Cp7i2RYDf+YblAfS3opdRL2M8r+ws1NrdCLrNBTWUb4xDrU3WKt6z1A9C5sMV60qGGak XtRUKM9bl+IupL6xvOfs4K+sd71q2kI8/E8+1uBgkb4KRZ6GwxLiBLdE9welWplq1d3uGG2E M/M22KpdcMByHibAN/YGjQi760aPdG24kRiT1xeXw2YV+NxseWhuTjv4fGt59g1yf6ItOMtN Pm9eTzsaI5ykc31O/HP2H/EQzTBdEV+iftE0YvEXiqNfoBluldwqyfJ5tJP6ADSE9T8a+wD3 rFGPEofmhMdk3yNeTXZLVecKuIfXZr8mj80Jr+O/ZVofXqghrFMH6k9wT450g7gnFr9fJfeX aim+1bjprPlrOipEqEXriYVbuMM7s3ui53RZHNCf8ez99m57J/QMyrLb/Hv4Tx7fNx93n8bH 89TFx127nztzMdXHIeJPeFk2k4+5bp+qfTzZTDux1/1FZ/k4UZBtjcaQZ4i30Ur1Dt9hfez9 FgfzMZw4l4vZ2VbPO/5ePcu5nMtZ3sYZXZb6Uivy2DlNLVMZnOH38mX2w/azjH0bRM5nP9OT sNeqMVpMm1EA9erp9zPZ5wN7aVrO9nKresXF+MVeRqx/FOicdB3vgmiHSuOt9N0CKzQtfZ3X ZMfYmGFI+QP+f4+avV5K9F6i3S72WjXxIT1HPdM3o1nj3HiszZzoJXSV+XO5TvX6Z5Tmhedw Fu5jv5rVy/RDtEnHu3U8e4o242qYzf8n4e8myraPi7FoIK+dOrL25NZoDnthuuce36dPXKs6 I/xMRdE+7CmM8wIap4d/3tHGdGMoj1AB7bU+/ycaJtEjp3r9lfgQd2bNJlFGy/h8bj60MvYA fGjk7BRjbb9H+/Ne67ZhV6in7X+8SYVut8aHvNvzIDyrnv5MJWftwHmyHGvnqZN6R5Wq8vn7 ZcaaqTPi53gXRP1UFF9B/6H0/1rj4zsoL9OJNib5qzYaqSL3icb5XJbk4vz58zoi8SFeyDn5 Hf2vy42HD3VRIWXzZ4O6cCbfTmL2aovZ5N0How26xWIYsewicpRS7+le10v3pk/QYiP+gxoM 4sNp8Z+4Y5VqidLqERaqh7cNcBRnp1DzvW3QQ34fB+gS2i7ytoE71pJ9IHyXXFSo07CDaCtg vxpcvWYdVkGc+lINPJtDbjvTParz3OPEt0INRCNcE/bXbbQNod5Aucb6wS9hGtxm/eBhmAt3 +36FmsIYtwXvqa97V33cTnypIR59yB5UapZ7i/c18P+xxG76wfrELoPhsAJuh+W+XwOxopRY Vaq58D2YDgNgAUyBlqR9DEyGWrPBGP0A+h2K/+JjRfyx5qa7aC72JuzUIzqzFw1qgXmJXWv5 yOr6MNOUtBmlbcp5GsmHo8JeOt3OQFilUW6KyqIS9pz843NGpZ6I52lc9Ig6hVdqJXmr6mD9 9d9Hj6OF7kf7XMX6vokdB+1hNfU9aKdP4W/Eksdo68SdM/s5bOf5NYldic5q1SRXxV6/znfA cnWLxqmLm6werga6o8kO0TiHSv8dmM9xsJh4ZPOxee7J+Wrz8XNZRbzJz2U0msTmsYuyzel8 5mFzWaxjw1kabfMIl6s/euMidzv7eLWWuXN1kuumccGjfJc2MP5IHetKVMf7l7nB+NZF3axf sEsnBwt4bvO4B318hma6JlUGq1iDDdT7M0ZXynuxhWjlIfjyfzAH+3ZxJ2pi0EcboJ8brhuM cI+q82VPb10NjdATBsBZcCFMhrFQDP+z9xDfp6FD+gL6PNOO+nRYktPfmRlwGfSBU2jLYHth v9b8zFbKxZRfTfgQvoBJtC/J6XGv8bO5d+/fAWuSb4MXEn2/MfkuMO3fOWEebJD2PY/9CVzP /ydgyUeZHthFpu8pj0367859j+xvTPz9aTLWXsrHe1+1/85kTg/CmJxf9jP//RzuSt6Zr09I xnwq8c146Jt6BoWbYezMAjiSts8T377MrZGtYQa1mSmibN8ye8IKclGzDjd9HD2sKfEEtO1Y DTVd5LXNIM1w08hZwzTbzdRqt4W7e7PKwiZ1Ryt3R98cTZ/F7lb0KfrE/ufWEj/XqoQzLL4n xBkT3yRKjabSlJshcbfSU6yvguNU7xpVTyyp53w+GeB1uF3N6YEaFZ1FnyVo7XvRfmnqHTQs ulPt45vQek9oXlSK/n9M5dHzutnn+gHolEXovFPUHLdDa/2TftvQUj+jzzQNjkZn3wwuyX7g vzPQsFGxmsito5lfcXS6JoQv6T786k5u7+teIZefrfr0FZoaFXFnVvPeKq9JO4WvaDm6v7cR tqhrPJOxlrJeu7WEOFnlJmXHRLVaEi3QkfFGcsgzuiqxV6JhvY36ayFMTFhozw10i1GdbqHf btXkbfwRz43W5H2tetzeY99y8QraV2hRuhv/7aaphy/ErtL08CFNDinD63kbtccu0Ix4Nt+b s3VLdJUq08X6TVyiFhie98M1pwrZ83+TX67BVVVXHP/n3L3PuURJgg0kUXNVYiCIpooJIUoM IioxJUQeY3hoIkGEYMIjE5E0rQ6KkRStGIHBji8EbLVSsdFKHew4tRQZEAot5RmhRFNFpNU2 AlJuf+fcJIM6tn5uP/xn7cfae6+191prr1X6pf68QI9693pNCaiPSj3wJQq8ONWGVyJDHP2j nPcyNeVRciJoeGSsb/eg/x6N70Sjlw5/utZ7u6C7YjoH+ifE9O2i7gd6GdS6h8gJfqNK6Gqf BjhITXgmOnSvl6Jfutl6AVT4Y96jrPXlbwvkjd05d+WlduJ0cIcBws2qJU+8wlyGP7yiRdjl IuuqnvxhFPazxF6gJdj3YtrNAWrU7A6LSyWnmGhPaqkPPx8LHVBjaLEWYr8ZAZ4mJ21Uqx2h MQFmqs4pU6sTJVd+Ta3YYD65fg4YbGv1jA+zTpVepSrje6PnNtV4K1QTX8Q+vUACuJIcZ5me 8OHM1uvUVmvtJn2f2mepOxhZ/gLIl+1h+nXw36vhzlFtom79YZesX8Phr9AT38AH/HN8fONe gNrjP85373VhDPyVLd+G/2s48BW0daKr/y33ISZ142vz63k/4HVo5X/Fdm06E3Yqa4upRUrI J1/n/TupyeLtAfGs1fXYOwIKYv1g7P5YH5sqB8t53wawGMz0Ec7VQh/eNcF4Q2ioqo2/7+tB DTsmsLknNMGOUQ4Y7A5kT0COssAZrpdMf/iWEUufY7xHgHp0bAnAfr49Bjb5Bn7whh51e2uT D/sD8F3u5HQMPY7E4DoxdI3b1q+8yzfdfdd7fdSJL9jnLC11GvS2u5f3+BR/AOxRbU5rjZmN D57GF32c0fbPgC5lbCl+EqO7tdjZqjYwsJsepI48qKoeO83cHjvV7vbSx2cg4vYyo30Kb8kZ yHS2xr3kU1vvjLP1+lmMBu2usUx/T5Mj2Y3a6eOsdi0EueYo/xywm/HFTHK8hWoD3bK4Hbqr C3YJ979Pb7oj0a1QU22N+thx1HUtutu+Bd0AGjXL3kS/TbOcj8BuDbKPMf6gZrmH2eNhsJb/ y4PPp3OZy1clf+DN2MUke6ku8DYr03ym3uaYzjNrsLFpKjZ7VBBqVZV5H/5bVcXfOMrcrALT piJnpcqcRUo379FeqiJss4x3KTM/D/j9tbP4R8tCm1URiieeva/RZqzS3Xmck6Mkvx36jPN7 RT+zw4h5G/kTmqDEQXOYPzWe/k5iYhgkREfaZYxfq3x3m/LsfjBDjcT4fJ/aNOaG8k//lhrv fq2xcSonRs6wA6JHyAGmc0fxpo4/upT/eS30OfKU49Bp0b8jVwTbmIwui52D0QpTRbtRTe6r SqV2STXXEVvvho5mzbtKCb1CjpulumBuIud9qDwznD3q5XFXaaGnlMQZ2aEClYcOQatBOXiY O+2lbL82claTx38A/aeykTnbpDG/Cf4HO+mPoa4GkO9nhU6omf8jz5aSK/+BO7sDejvjxdQT GRrrPAUdQ66/BZqmhFAFe/OvxP1JtU4l7b4aG7dXc8yH1HlzwTnwjWN9Bmt+pwynCtsu4b+d C32bem2E+odSlExNc66zAfo/pk+3vR0A7diMb2/Yh29rdg5/Nfbm2xo2lNhla9hQJLCzX8Pb EePjXwjsjb9/EDnMRN/W3DRV458J7LvObMG+9sCTA0YhzyrkRCczCLu5D12SdYsZp8nmYubR y5yDrvvwG9/e3qQWfICxtaypAy/SP1up5ArlZk10h32W9ru0a1UTWs856+B9Eh3mkR8U6Q53 KvfS9W4TQBX35r8b9+y/mf8m/rv5b8ZbJHW/WbNy/LmAp+vtJrDWf7enNcjcoLH+m1E3lJPj X4IdjA/VI98qxi/mvHTeYKXGOxvpD0WGiaqJe0d3hi6k30vnhh6Cnq1EZy+5q/9u9yiTGqMU +SY6j7Butc6DLxLqYN/HlWyy8avr4Ctg7lfQFczV6ULj0R6I3stZ/3+ipy3Gbt/B9iz1Qhy0 EJwPyumXECMbQHl0pJuBjTYq3ytRnpsc2G8j+V5+QJuZa8JW/kXc2k6cvII42UqcbIoeoTaY bhOJk35c3IddxjPej/YdYAE1In5FrjnZOU6dk06cfJ92h5q8mdjiZdj0k9jt59Bd8BcrxRji 5CTV2UsY26qLkDEPnojZJM/0VVq3Pr2DGJ4Y6MP5vi72A/wQfXxdkDGxSxfzN2TYH9M30Ak+ m9Kpz2QNcpfjh+hCXl9NvpHAvuu4nxn4TaLZCVZRz16ADxIrzHbkIt93XtCdphV9FyBDH3gW 4b8X4YfoYxvwu+OMn8U77GJNMv3HlOr2VLm9NrrDHUJ7GjZyAD88wTmFrD+FDufjhy344Ull eBm8XQ16b0e2g9Am6r9l/P8rJG+eRH0q/s14/nqZ9VL4j4xvIDf4Hn/9DmiustFTgQ3cpp5u ps7m/1Z4puQ2M99O/z5oPxXbI+y3SzfZG5B/CbXGe/Rb/LFoB/++wsPgOwleRccT8B9g3xIw Sb2tn498DE8K/S2y9s/QOqV6jZzbxr3nUMfNRP79Kgn2iCg53BOeAbQrFO9VQPtIPRawRyrt bZrh+mMvKdtFV/N79tmO/M8i70/hQR7uR241/ddAqYrJs2QSkX828l+l8eYQOpSRq9roFyHu wuQh1zZog84LT2dtX/avpJ7zkH8S+rCfuRfUqK+bwDwIj4dnoCz2I+ww1W7QUPdybOt2XWOL qImKNZxcdy42/B3bgi+2KSkcB08WmK1+2GAuuXc/8tCpzN9oZ2Fnacr1NirXJmEbG7Hzv1Kf ntSlzifYQTt+nqMaZy5/j/AJT4OcS5XjIIOzjhxvAGffhCwF6LSbnPt89cN2apxPyR0maLBT j98XEUMO6BI3kb3Hqafpo4EhqYD83SUXnO/eqHvIeebjg/PJaWtDlZofKlQPN8LYDs33RpDH p1O3vqg59i4Nt89ge1PUJ3w1ueMc7uoGnWPewg6zdDk1xww7BJ99WdP5p0ebR7jHSSp0TvEX t0VPYVeFzjEVer/QWDtdY80n8F/NG2XB/zlxbo9uI/5lsqaIfDPRbSduPoX/NxJvi1VKvjfU vRVf3aap7kMa6lM7n7eeAj2hJPw2gn9GuO8IsSISrtYI90eseZ67L4Nuhd6na4P7/wd+vp/7 n6zccDP3j8+6V7Ln87zbNNWaW8glruLOr9cY8pMaYml/M4V+mYY4K5Ti/ISYfExZznIVugeJ dR+BYeSsC7FrYnjobvKEx3mvF//NeLkGR12dYfzJ/i+7CQRLETJJzdA4CZgaHBK5FUMnhKrB DChI5F5CjUAIBoEQQSBsuEgg3KSQuImYWiMXu4JMoTEOLUiEISEiSC0W6JASlAF1WqWVwTBu f2fJ5kM/dWeeec//nPecPc85570RPz4L2+q9bjl9HYq2K5GjNQy7irUb1IoPKaXuaeWOW7mr Vvtj7mK4Wj2jDUJtdg3959QKh1ZnERjO3czolNsYa9YEO0EPcI+N5I59vNOVQH7rkGfG4Wdy ra+xgTkKWi9S58wBHj3vMfmHRc6RqWBUSG9GhUIt5KSmHcSOgqbffjysHzRzyLuDVo6e9ByB S6bqrQbFuT/ine1SjNUQumz5Oc/+inV+yh4mU0duQWaAWDU6Q/jeqEZPlUGo3bHpj1Ij99HI m29krMg+dVc6PsbiqDWfgc8CvU2O1Mf7GXVEI3yOwucx9jwZPk2qs4LKR+bjc/KtaHz6Yvpf V51ngkGomTsMt91LqjP9+GGjX2fmYB91xOFRng7u53VVYxdx7jLdx3nF2H1CF1l7pBONbV1U Fv61GB+aRR6Vbxcgm/geqyzPdLArlI8NZFljNdKdpyxqoCz8TDH7fSIs69GPxkfGK4k3uYRc sMr7OTXnWvz7ZM7yCDKVfZeyxlFiyplwXCmwVmqU/TY1RSb/MRnsJ05Oufuf3E+W6Yd3Aevf Yy9Efy7zc0K3ifErGCuFxyJ8zhJ7ARwWhPKtq/iXGvzXVOZdYv8fI4/AZyf7TeP7BGufYY0o +DQhazXS6+W/xPgRxofBx8iHmZcHn2fhUwWfJaryTYHPTfbRAp8OZC18vkDPwc5Gssfl7K9V o5wE+Bzif/gvy4LPJdqt/MdNdOm3P0T/Xua3o38aneXwmQGfQ/BZDJ9P4UMcss8yl1y3q341 NesAci1Tv1JvmtoVDktN/WpqV+rZPpHaFVtaGK5bL9DfWcPav9XAcP36S/x8i0pM7eoeVprT zpsegM/7CXVou96x14au2W9pFnYzl/OZ40SF7tjHVer5VHvsNmxwnfrZ3+uQPVjdyP0KTP1K HO/G/jdaH+EXb9Hn5bs21O4m0Z4Zuuau1Xh3Pu0DcG7HH3aXa+8gtg2mb5eK3W/Rb8b/Nqse LARrwXDwJigBa8As8Cx3W279QWm8h1Ri13BsJ8deQX9v3uEo5cBlPu0pxLRy8AqYBwrBOLAb rAZFYDaYyh2WgwawFFQA03cYrO78ngcWEQvfBYdBDXgHTAfHwV6wDVSBCvzqA54kYtcajfYU qUfUMY2NOqjeEelZr42etlC+J1Hrog6EFnfJzjwxkn9E4ndXLIz44844Y3yY8WcRPxCxn8i7 oy7L9tRoDLG1p1WsTO5kkjUYXzcV3/+GtoIGUAF2gnFgP9gEdoFyu5Cc8BPtjcCapf3gfqee t2VQTW1Yog34j83OFWRfbbAPI5dps9tLG3iXGzx/0QBnJ/1HyXvTVeF2U4XzV/R7o2fkasaW 084gTzjDmsXq7xtIbOyn/k4SsahFL9hF3NO/9Dj+fBV+ZRXfq1h3tr2EevC2JnpeVZFnJZwO UgusV563EP/q5X5b0Lc0k7mrrBMqsq5riZXEe+mgr1ap7n80xJ7JG6rVg+SvhRE+9nvsZxr7 MXz4f8PF7NXwMVzQieviEqc1YR7k9YYT9pMZ5jJLrvsF/w8Pt0OjWSPP+QXfjs7af5SPc/Lb Pq2x3oLPbXzxl6r2NOmcfZ7ceAe8O2hPV6J1hHHDY47ikUFnoMqsL+kbyPdldXefpL0AOVfT 3RqV0ee3LtC3nZi7hTh1h/YIlbjr+Q7qZWtoVLQ1FF/3OfsG3gLW5G7tEG8a4P99zvPKti+o 0nkfn5AIPOARbXItZVOvZVsX8a9N6OQr2xuDX+vOejvQT0PPyGzG5nGuN/hu1nFnqCYR26Y5 5ewhRN1wUylIv218UIz8/IefGObHdmKdHGLgbZV4TmuX9QEcz9P+RPXeZUrlXFM5u1W8twHM 9eP/U63LSqce3cxYCrlUhruRd/4+PrsnczOVSP3mI1fO5jyznVjy1V8jhyjFnYAcx/k/QS7b k/ZQ9eLdZLm/gkt/cq82eNyiP4BcGJ7fK8wvG510fCxc3FKtdI6zL1tVztPwWEEu+Gfe4Qnu wQe3TPzYWcZ7creV4XsssfewpzT0Aujl4ZMMnxyl807GsK+XrH+g04P7r2WP0eRLk0J33Gdo r9Byap4yux//kw+/YepLvrqcHGqDt4fSIzbQdW7HFADvga1gD8gDH4IqcKizfwX5/94IyOX2 gww3gXrRIBZbb1OA/KTefQpZDmLBDb79ClhpoK9GYAcB7CBAvhtwl4LRqscH3JXX2McVvYGd 57g52MtlDfE1w/c3nPFWkEzcO8M+ZvAuZrLOPPRPs24/LaNGLHIK4HVFfs8p9tJbhdh9ofcW Z1ACBqE/XyXMrcZ+/eRMm9h/rjObvm7K8lZoDHHrEdO2y1XWxccHPtLkMB/+33AxezV8wlyu KznCxXlR280YuXfAcCLO5xguzI/35vE24OFdrWnuVs12PlA1eetX2Eqqc7922M+pxrrDnBLF OxO1j/W/csazt0QNMXq8lYeI74Ewj/NKdtJ1jLx8O7l4gLiUzLuId5totyGv6wWvy9hlcu4L +MSDxMst8nFPqzi3EmrEe5xe2mlVRvWzKjU+Yt++ZNWF73eu3g3jn0rgXeVSO75GjZHr1IEK cI7vIDk054ctxrvPIS8o13uGuqMRDNJrzslOeZ6x78hzSrCdNfoG/zHF10CtO4r8Yht1UyV2 MlvbnRRiSy5yEfuuRvZWnLOes5imdVaU/mTdoJ2sCnLuRl8P3sJuEINeKfNTmFOpn1vfYd8n eUe7lY7NPOQ1edqPef/l+OwyZIRPGahhPcOH/zdczF4NH8OFPSZEuDh/V54ZMzpdnMqYCx/n G433Wvh2uHifRmerHuV8Kqljt1N7VeAbEpz72Nt4Vdqb+B7Lnv06SB27l5qggrf1oHMKKWxw n1aH+RygDv0d7RrmpTNvIjmXT+m8u0rsIcm9SPsH9J5irAR5DfsIapBbS/thBXnHIyI2EDk3 y+S76yXvFnKF/6Pt+fYuHFmDnBTr99RMMjB90p1T4KQBNZrwafxutYBm6d+DuGuj8wo4YMbt r8kfp6D3vXZ0oYEzyNY+07YTldHV3w5++B/Q7z5KTvUqth8g5yzE58xXhu8lZcSsVYYVrxkg F3vJpZYopp0ZRhqx9Wd6zPM3XSW3uWqlg//yXu7BVVVXGP/uOfucc28eQDAlBUdogqAVggNN QCSaXMRQKNIIIjE8wuOWco3h0Qsk0tDpYCEyBUu0ASpNSemImEBJYlpkShMIglc0PBwYRmkz tmRoB9B2tEMgPNJvnwf3kQShzvSP36y99l57n/04e62189FKPZV6KvVU6qnqFtSr/+Gb6lPm 6y3YRN1L3UvdS93L90cr3wmt9LOtIpPlA+zTypjSg2QiVfkUqyTqN8hMs/w8SaeeTj39q75/ qz2/m/Zmsy5yjGYM6cJuchSDCOtdu2WZ/+pA/ocDdBcG6v3J/RjI/R2ov4UU/T2kGEuR4k5B SuyHSBEH4deXwe/Ohj+GubDxa/g92+GPe4J6EeUJ+HtlMR6dxWLHLsLmRyEbrY81lmeRq8wp S/vwsuce1x9itqJfrx3YnTScb6dE9u8Nf8Jw+JPy4FczQ/9mjwD/1WT5fqPOuh6F1KPbM6Pa pf26jg5TX+zodrujL6G+kfqyu9eZM4JxBrH7gfi/AgkJXdcZX1J/h/rH1OM762afO6n7rIs6 eT+aGRsVyi28J818Zyl8k03n/ZDUknbyBALUS6mXUi9VXkabUk7eRJsYQxaQSrQZZ5Fnss0k 4LlCFt85RomF/pnJSvd3I3W+V/Ik2p8tmJcEwnHn0q6ec21AjkS/SP2iVe/g1DlEj6FdQalJ WiR6BuWFkGQeanEhEtlucoTjX7YQqy24j8USvQiFZJVNIfP275FVjLUW9VgZRsDBmM0xzsPn 6PQ5T0vMcpFrpClXcN3nUUNYx/+OhOlPS/R29m9HDcsxElvfc6ud32VOmxMub4e0CbMLRMMY aO49ZQn9yDq5DsqACDB+ByiDyJHElGJ3go5D0dI9DP+Om49291BLamfRYBTaHEVGTAIyHOn5 GA1aNfpJ/yB9Q3g57j3Mj58Cf+Jj9EO1mC99lvQl/8+yvolrJ193HO0k46PDF8jlmzKNeVAl zyGbtLi/DR+p9Izg/9KH+048QZR7fCg3Hsca8gtSoi5BsZC59yL+l/fR9j7KBsoGvhsS0aIu Q5VyhTHOSz/ghU/dwNi3gdKLShJUE1hOQNCMOTLGRMurjG9XOVZEjO7oUPsxLvVDsZLNuD6V 7eOseZvMY36Zy/y5gOuch2KzzWKKKd/k/yZxdEcehka+5UjjMrZH4w6iuKv62+GZbqFt5jyj cPehPMr3WYhs7QhW6z/nHvJNpk9CZTTMp30SZRb3lqjrLPRjWGRT4GnEGvMbQb4Fw/Mgi9fE C6Fv6kOsM9TrWCZ8KznMsfmZhHexUuZODjInknQa/yLq3Zwnz9/HvCTb2I5y6V+6mEe5PqZz ncTaO1ezttfVV+ZuZDOpIVVWm+KO2OcT6O/gjKEs4F5e5PnL/9piuY2pMz+2CFoYQ7FJou1h HiehnzBhWd4PMtKWaXqiBXPqBpLIunTyHZu0MJIkZt5pljvatc/hI5Wd1v13m/C6c533xr2L 97IO5fF6p7YXbVn2NWXofBSLTnPtImeOqO/G3rOaZ/sKymOH3moLRMlu53IbbvXxzOU35t5x v27xLMRqyVfZxQ6zMP+pVQiSKuf/Uv+EEr6/QjShRTdo28Q9eIz7atBXTY6ykTj/bwffl/Sv DuI8/6HzPGP6Vb03SqTvM85wrDOh/dWreR/Zrvn4TqEvlIgJmCRaaPc2gmIRKmw2SpSzWB+z 3LgQsxxwpPy2+g7vVBVKJPRHJaKCsb4Fue7D2E+Om3Pcga3iOrZq09hnmlLtSGMX46kkjd8k nkNoMa6hJWYy5/Ig7ldP0i8v5RwJc6igdgk+2c7c3rT7H9jVdb0r0H2frtvkHPQy7Gf5DMun uutPmwa2T4u20d7GqrBxGrRa7h+JWNsA7usA8/zqxFhs4P3yMX/OUHfCz7oHbH2hNgOjjJ9w LhXINV7CJ4yj7c5emRxkXB7PbxaTBSw38ky+ye+9gP0O+grWT0QuzyuXMS6al/hG88ux1COc 7/dt1rIfEQZzfEOttmQII07NtXANNuI4H4s9YeX6sHIkcu9GIcfcqwcQT9+5T7iwT0tFnBjB cjZ99nrq61GgbKIUhHZ6M+URtq/FPNnGe2baiA9YNw8Pi2fxoDiAJH0E8sU+aLwf+fSd+ea4 N5j3nMMuMYh++g0sUE9jqbqV++vCdHEYK5TT2Cne4p0owUPiN9gs0uFVt+GH/OfnaCmMdTux RW1m/tTGXOUQssW7fMPG84zGdJzWH2HMfJ7lWrYdxxyes1esQbKezrodjMVf8D6+znsxA1na PZxzEQaJRtpdQ0+uJ0trxCLlBOUhQjvDQJYOltO4TrbxO/uk1B7BRC2G65yPZHEU/fXlrPsS PfUcFOgzMUFLdfXS5FtgJnqK1/AU1+UTw0k+isReZPFN51N8lAfJEa7zc9o9ydw5F4Vcj499 /eIy6x5iPv4cCvhOmCdO4Bl9GMc42TGe6/TrFbQTtMumTMJ0bQ7XOY3t/+K5PoWJ4hg0IuVP bTkxSr9KZofV32vLqaTCllI/QIaQkdaYHdcoB9jjbyM7yDRyiGwgteQU2Uimk2bbppT8jaSR Z8krdj9pV0MOkvUkjwznd+T8xltlVItnkOnkobED0SBJGIE8SU8Pfqtl2rlbEVaLX2KWXJuy hO+lWp7jLEtqfwnRXb3a6PqVqHFlKZ/Q7/rpE97gPV6LOr2Q/vN3qHMPoQ9tRJ2Rx9gymn1G Kz7m25CorzIPfhVj9SbmfzZsf07U4H0Hd9B1rzZIrVaTaZ+Ml9VRlKO4/jRLSt31PqActFCF hZGJKtcf2baX9Xk2m8i7ZBjhWl2HKY8D7kT443rDnzAc/qQ8+pRJGBX7Y8YARxZa++dIJZf7 4OVbxkvJNxyB+D1WklsSbQQ3+ZUb20QZ7WZzXlP4fpiCwWpfvif6IsM5H/US13EJY5VLOEdS VR/mksfFZt7tzRir9sY5kqpexw+IV1uGCuJVx7F+HFJFE31JE55k31bZP1qqH3GfP6JehjYt 2TWDY7Wa40XLy5SXabcdbeJDtHHsVjl+tBSD0UpSlX0crwfalMOUk+WKO7LISDKBa88g1G+c Ik3A9WukPqTf2E1qiKyr6kLutuTNNYzT+l3xOl6MIi1cV7ZYaI+iKIwlEfqxbngYeRLd0zVi I3o7qP9EThgiSu/MP7Awiv7hujIaUyUik34sxKMR+gfdUIAJJte7wc344jCr4+ZdkYSF/6W9 3IOrLq44fvw9b8Ra5BGqPKwlGIJRkRTKwzYWaFJEjDQEMiLSYJEkBUlQCBdrdaSKPGypOhg1 1fJOA20JlIfVKlYtnU6NxUdbRakNjlqRgI44DJr8+jl794abayrMVP/4zP5++96zu2e/J43s 1H+nLIG3mHmcYGrqP7qvU3gPChV/eud4mZLZzg2M8QT3aDvv1AgZgU9bhU6I+8WQz97fR/la uM/acrYUccbmcsZqoTvf34T77LmLwwTgdrdydltrYBtnWM/u/TCTsq/AdXz3htf5Hky6D5bZ OuvIG5VA+22bzt1oTNDWgzxUZ9tA6Mf3dsBztL4Ca2AX+WclytqWwJnkHSU9n/QY6Wmki0hL bP9H4Dh8BO+fSNtmkD4O78Fi+OVnpMVwy4m0bRJMTNA63UdHc5bi3h4p826TG6DGnyhDAs/k T/fWmTu0gHd5kTc+akC31HgfSKZzp8zivuX4GRIPp7Cv86IGvWPBctqPpe0mibvHeNtmyGD2 70LdQ7RPHK5Gt3TzJvDujpFq77u81zfLzIxaWRhrkYXBbonzzsTDt2R+eK/M17vPOOea+2vv aSpJ/xC04KcPMTfmp3NK3nkdI9m3loVlEo+dQ7krs/x5if5T/YtTG21kvB7t7Y+RD+3jlUq1 /2P+J5HfgE10HbZ9mu+pMT5Dy7CpN15y1AbucbTWm5JLX328fybaOTdJL7/AjJXT3uZN+k+i ezJeFqbTiU+MM07c2EDneIIyTVmXA5cZ+1hM/RTQ2fOTqH06kL6+5bRZnrBPKux7dTq69lQ6 3cuXuO8QTk/g3SM9DSvteUlSInleSXSQsXPN3twOkxlbyzjD6Om4VyZZMNirou4ofE4V5KE5 Z0cPK8FCdOcUfOQQKXIWShd8cSZatthfgC+ZKqPcarneeVIGqN/xz5Ye7lqZ6G4khr2dN3qT 9I91p78Jkh/USrH6eXyPGF+d9MkpuC1SknwPAp/0Q4lBPmPnJ308fX/bOS/6UPs1ZTWJfu0b skhxRkQPwuH2NkUyAIrbx3kJrV/J/v6U8n7of52zfYPS3pcKfRPcy2SoX8c4Y2QA97ZCcddL oVsl15q2Z8lA2g53fihdnFvZh+/zZl1LSltnabTXPSg57jUyyglkNxpitzNZznCypUHHNLa3 uEus/dNIriuFcvXfirEBa0mH9b+agLhjiLUhOLkGge5ObtQa1EtxErVlB9JtcSP2A7VlB9QO aeh5SKWz/cY+3RViv76Ku196KcbmaleLWQ99aB1Tpufo0sT6zZl8R/Kc16PnvZtYO9rftOkf feI2ytXuGrTmu1LpbyVu7EccUsIejyO/hXkeZk1bZaw/xeSXeOcRO7EH7iG5xX05Ws+5rfAW sYeJN7yvx5kPNsqV3jOMpe/205S/Qdux7HcT7f6N/x5B/KPv73z89Qre6Jsk093H2XpLpkHc PSqlsdlSmXE+vmk//d2JL4mIw36Nj0VPME53owvs29+BVN0xwdyrCp1TUkfoGMm+tSzsI+Xh w9zxH7E2YsV0zeKURQ2M57ZrkUryFTue9oePLOdtK/cG0z/raG/fUc9UGA1CmdrU3YmtsIG7 SsbzZmXTV1evMNHOGSWh95AZq6+2cbrKn9wrZY+zQrKdLrLe9F9N/xazRw1S+Sk+rbvK8Wfl xiY65xMUaMpa32atecZeFubZAf8xmZnE2CuV9PXm0UeetVcK7jrOVRrmPKTS2d4Woj0hWMdd AK839uyd0Hbm/FjMmujD1Ena/CnJdp+KXmA+fc08tE49c9E2es5fxrfoub9GNuudMH5lIdSz V8eIxx6VOfjycm8jcB/VhxlUJ66I9gUPcVdrorXeSONLi70LpMwZEC1xSkDvdqN0wbdUeNl6 p5mP+mjaop3QbBFRatvNcBj68B+ipz60mm+j1Wd3UPY90mdt7LMiofdap9n81ZZqqxF/l+i7 9VXbx7O2TbLP7fb/VYv+bzf6wmo3TYORvEWvRe8HRdy9Bu7JaOLU22QYVGjqzZHt3izZau6W nmvrMzT18qLjScy5+wn5l8t4v5E4dYP0cR/BzheQj0bx/xM1BQVRk58V1XmfREcDP2oO8kX8 30dNpvxC5pEWx31WmzBXAiV2dtQUW8D/pKguzI2OxoZGzTEUffgu7daLBNvoYzPfqPTgedqT 52+Ce/lfSr37abuSOn+O6oJC/rdFzSH5wXHyfkaK6lc9dLK64W/Qio+KZOyJmjJ2M6djUV2M thkHouYMzR8UNeGTxWtkvQ18N0d1bhn/z0XNnub3IO9X2P7nvEu1MtToStR80EbfUxmTUxOe w3goch9lH7BPvn5zAsIy8jlhQT31iGCCAYk9Nfuaado1hTWUlTDv4fwPo34V9Q6S1430WvqZ iz45Sd3wEcmPFbCWy1njRtZ4B2ss5/961kj0kNGbtdWy318w7t1S+Vl4pdHHXxROgTwC5zoF 0Quwhe8q0iOwE+6Cv1oaKdsAhXzXkfqkb3xKT6QzWu42sLf/D4EjP/ii6PAGf44EW05OZ29e Bw58voTDTo7VRvm8rx/A3+x/V77/AfXwnuVxWzbLfud00B7/i+Q7m+JvT5n9aN7PkfCSk3NK /rsI/w2xS/EjDxifUxcW4b9L8d/3iMS+RLtT8bt78buv4Xvw9/jaJnxQXexBkdMDfJLmT6Cf U/Ftf8S3VVB/Dn38hTnV089y/pfSz9Ok34qanEJZBlthNcSdwmgbHIH37Pf75Hv2+4Blm23X m++PSNc6g6Ue/x53iuU6fylv7h65iPg07hVIjveixMOV6IlSqebNijP3uJ8nFwVjZbTGrqEP D5B3P++1vuFPyGgT8yrN0jPYSz1XLvYdudiLqPdM1KzoeOEM4tMp5FVJlj+blP60XrCMvuye BS34jwfJHykLFG2jc/HGMB/mahgpNUm8VTLXe446FjNuAfv2nK4nauD89vTugT0yNdgHD6On J8u0MC5Zoa79X/TzJGsolUX+1ZLl7cJ/Z5NqjLUGPdifuOVF6eY2oPuuoWw5fEO+7l+EhvwD ZX+XyqCUvCkyy8SOvci3MRW6rpd/iP+x2PU7oHHhBtYH/g7sVUO7OPPeTLoD8iXHn8H9zCWm JL5SAp9U403ViC1Sou10LqrvzFx3mXYVqguNNnyaeRKftUOf7r3M8xPepjXRY+7zNr5Dfwa5 xE+LiTF2SmHwZWK7Evo6jXv+CnGD6tGZzO1tE6v11fvvvkAccQnx0i70mcYlq03dcu8X0te/ lXXirwItv4s81mTiBtXamQkNjY0zg6/yv0AGEQ8NQtuV+8PldEX9UrADvbeGtluw/yvWB1LX xAJJH93P+mC1NWgbG9dNM3N9u2Nc5H5M/jkysB36Yx3lwRW6HuLLM4zGP4s1jgvOlHHs9RXu QbkiqJSsQNeHbf1u2IN4lHVmuR/hX+aSf6Nc7v6W/t+RYu7JdN0T/2vYHpuqbjdafiDMk36c m3Hs/VXkXcU7XOb8l/1yD46qvuL4ufd3d7PBToACAi1DL8/CAElI0wAtlYQMCHnxDEpA6ZLd JGuSXdxdkLZC2yhQaBCwZRigFobRAopVBlpLxwp1LKBA5eF0KmoHimjLUxGJYMLt957dHywQ Wttx2j96kvmc3/f+7u9x9vc8t9I5a3ahbGsZzoVG9Lsa8XwUPE4zvd3R3zkKePbAv5HUk/ka GI3+sqhMDaGemIOAmkX3m1OcjeZ8Z6MaRD3N4U7crAO/cj7y5mAv+cinEGsi5pugToGNNMx8 H9fy29RGeag7Yr0YYrgKKwtz3g9zHYevv8ba6+PErV7OJfUE+a1vJ75HdD3vaxjvI/imbQ8f R2NtfB1gjXh+j7WzicZZr2Js1oAtlIOxftpTSz1drC5Os2eTc9Hbnmbg+6pAHcTcPIS2F9Jo 9TFVqWcwLmNospmH79KxeH4C+yCGOV+KMbkHY7wHfq4Ay8FT+DZbRuVWN5wJyZhFtVC1lU89 0GcPdRV9T8V4b6G5npMo/wLNtTKoA9a6rVZhHNbRZPUS5qKe+rj7wmqL/bgYa/VjrMUR1Mvd j+p5zN9BylIrsa7WY+zfRDoNBLEv12LsL9F9xnnwPso+h/wvYY256QWmAt8iATWX7lX34Hk1 mE4D1RtYJ9Oou3meSsBgVYI6EZqEeR2qyug+8xxTZm6gIvOnlGc2UYHxMtZiV5wZb2Hei8BA lNmNOkiZ8YjtulGmKsYevoOKcHbfrTrQV80W+oKaRMvVYOqqetI0y0a9y9QW7ZWZj6Kd4kS5 a2V8mOtkGe8CjF2t85J7PphLnL97jzqfWJvBPOeQqnfOqVLnqNqC74N3nLfVbzGeF7HO4jiP jlI/bxP1MRuos7mR+uJeuMNaRz58a1yx/Fjrbnt1NM4zEvOeg1hlINb+JszvQzjH3LMW37Tu mlZeZxGfnTijeO3iDOT9Nhfz/D5Ncc8lPovX0Az3+1ZtpQpzsXPaqkUby7C2SqjQfAa/5TDG JxvpOso3TlOxcYAysJemu7/dOMVjkW/so/HGR9TJzHA+xHzmGTvoW+aTaPswlfFYNvI+KMP8 FLnjjfU+3VxLU4xLuEfdcY/ht/dBP3n0TdWFRmBMu5o7qVRNoFLzFHiB7kKfD6ix8GssjTO2 oy+Mv/k9Gmjuwprw4exZhXWGuTBO0gq0tcL4A4XA3ZyegH/AzEDsnkFtrDA9nCTuYvyQGsz+ NAQMZ12C9dUfZftT2BwM0jE2X6G5IIDx7p6KUXv1U/MN6qfS0fcOynd/l/k36o1zqY3Kxfq9 meabyMV+aqY7QQfQEXRmcjEmzWTdQq7jqGbnagotoBn5zZxe51Mm0X6HZB+p3M6PG31J+NHl FtgP6nYLN/qdUp7b79iKL//Mj+u+3OpHynjc1o9W/Ob2O7fiy7/yI+FLbsrYpo53Yl6ak/Nx fX5uO4/X/LjZlxv8wPrfymyjHOyBKmXgrII267H3zmO9AsSiBe7aVSuYIebPyDTmU8yspUbQ oFPVgDYSDDe/S6NxRo42Q2hrB876Ampw4XP1XOJc5HWMs9QixPEA5wGZSI1yGHIQlTt9EunV CQZidWMP3jchxZ6DnyHzJO6iTVSHPf60p4iKsddGgXpQDvx8boWpe5s0xP59Edf6EMuEOa8v GJo+CXd+GPFeGP6Faab1Hu7jMM7VMOLVMNX52lEg7UXqlFZP80FlShoD30g+L0ymsaRejrqP e4Y573iGmVNT07QI2n2LSnFufcfycp/trL3Ia8SZnE4Bq5qqrAH0PO6jDmoNDcX5GlLHqCNR y4PgYYAvj5YGjMcoUALiYA4oTNCy1AXxB+o04QuqqX/anVTqfRb9HXcupFUg3v4TtU/34Xks VXsLKQfjZvtOI7bGN4JvZwK3jlVE9Z61uJufxd2b55z2TkZsajun0kbgnFxCoxFLjLIepO4+ zIO1BHHGZdzLLqijZiP+mEHD8JsQVyGeWIk4ziTL1wmx0n7cr6sR321D3VLU3Yeyv4AvLqiD 96F09+4+QRHzJ9RX1VAv9QBix6M4o2fhXj+IGC4AfQx30OtU6pb93Pl5Cutuev4PwfxE3Hnz 7aXLiJlymSu0Mkljil7p2UFRl7RLtEGD8Vvpos4kuKH8FVpxTR9CnLSIIoid1npCmOflmL9X MA8v4v7uRQvwHVbuHUNRlAl7mqiBEn9nBEEQBEEQBEEQBEEQBEEQBEEQBEEQBEEQBEEQBEEQ BEEQBEEQBEEQBEEQBEEQBEEQBEEQBEEQBEEQBEEQBEEQBEEQBEEQBEEQBEEQBEEQBEEQ/mcY RF8up100iFaRl0xqR1lURZQ+zehIyn1LGfRLWEXuX4Ctq9PoCp4MSvzlGPcntaIvGsuT2oLe kNRe6O1JnUbzjN1u61a626ZZmNQG9TY3JrVJGea+pFbIfzOpLeiWpPZSb9UjqeGPGkWbyaYc ysb/MKhSClElRSlCMVBFceQVQkVpFls/ckJQYcrEmwKqw79NE5FXTTV4F+OnINIgSs+BDaBk IerV00zkhKBsWLdcEGkctdySNudHoav5bZxz3do2tNtvAE/1SKNUi7zItTqtv636t36L61GY 23K9sakcTyH2we1/EpSfn2LcZxi5WUkPIim/oBJPs/E2zr/TLZ252c7Jzh5ml4Yqo5FYpCpu F0aisyJRfzwUCWfaBXV19sRQdU08Zk8MxoLROcFA5phxxRVTigcU+utnRkP+Un+85rPkJKUd itnBULwmGLX9djRYHYrFg9FgwI5H/YFgvT9aa0fcNymPVa37ZofCNpqxy8OhOOpPivvjwZjt Dwey0ECEO6iMzA7Ho6FgLPO/soTG0DgqpgqaAjvgpgVVym3WcK1qTEEdL4TPUuPzKvN/u8CT hxw5jyC3lb8dZBtXt6d3MYrs3xhXtLisxSdaNGlxSYsPtDivxTktzmpxRovTWrynxUkt3tXi hBZ/1eK4Fse0OKLFYS0OafG6Fn/U4oAW+7VYr8UyLR7TYokWP9JikRYLtZimRYUWU7W4V4vJ WozXokSLYi2KtMjTIluLLC0GaTFQi3Qt0rTw5DusLrK9wPZDth+wPc/2LNszbE+xPcn2XbYn 2B5n+xe2R9n+me0RtgfY7mf7GttX2e5lu5vtK2xfZruL7U62v2O7je1Wts+xfYrtk2zXs32M 7VK2jWx/zHYJ28VsF7B9lO0jsPl3Fdk/4Kfvs53Pdh7bmWwnsB3PdgzbkWwzXNu2oPIfjJZ7 UFTXHcfPOfcusOziIrg8doFFV1C5KI8l6C3XchdfEzdVUKIQYrXlqrG2asJq6iuQNKsEIkan JkGdQGfqdNr+wWWxE0hj3GYSYyzGZzNq2ohRW8dHIRnbdNOh9HsuFydp7UwvfH7fc37nd373 nPPbu3tFP/GAAlAOFoOVYCNoBHtBB+gCx8EZkEBWCrfxy94k3CevgE6ggwg4CwbAEIhDVh+y +pDVh6w+ZPUhqw9ZfcjqQ1YfsvpIPNZQgugSRJcgugTRJYguQXQJ3gPOiF5yFQwCgThgPaAc rAQdolf1WoY+o/pwZJhFhs8ODwwPDYujIkRGzo4MjAyNiJv88WIOlh2BPQsGwJCYo9rFgXeG 3mGGcfjHixOReCJ/bWI1iHbADgCG28bzvhh3lDpyqcPvFmONfgxsI0s1Yg8TDygA5WAxWAli yFXYQTDCDqtLhasDKakZF/8As31Hinv7jvRz59He8izMjzbB/HAjzPoNKe71GxqfcQU3T3Bm rP0BzJp1MKufmuBe/VToaVd6Q8q2OekTt4J0fxHbT9oBIxmw+bzF2tlBdojY2R7WxvZCW1gr e5nYiZu1k1aALcF2gN+CT4DIjiDmFySBdWDuz6CHMfcNkjByi7WFJ3jlPjQO8obfxV5gO1Fi iT3PdhAL9Dm2Da9yEttp6ja23PA/y9YaupYtD1uk7F62KezOlo+xZzDO4zbAL3L/8p4in2z1 +9nTJB38CuO9Rsw69K6gdQsI7EW2FScqsSYon98I5evYbupWtswY/zHDSy90C5T7N5vaYOoa My4IJYZ/VDeyZeFYaZq/En1KdnHLVrDvspU4wiq2hC2FLmKLWSWO0sYWgSoSz1aQMrRr0d4C NqN/CP3fQC9D49k6zFiPA61HptXQVcj0feg6orB6sAqsAFVgEZjLFOPU5rDxKJTEVLP/bfT5 rmez8Ti1+X4n/JTMhz0BGCvDeCzGZSjf3UwzfiLiY/kp+8LJKbI/hRWYAzNMnQ7lN8g3+5Kp eZhokRb4K9CnxAJ7xFhSGfORANDQC/JYVsESjVv7oTxTOZQv/Vumf5appaY+Ymq2qSXmvCJT C03/NFOnskRsocW/AX1KXLB9rBhbTmVpLB1FsTE7S4DGMSuLN4oTB2w4/FSsNg7FsaE4NhQn FcWJQ3FSUZw4jHsxIwfFyEQmD9SFTBlQLwqRCVwgFdhAHFHoUvodvjO6yNRl9El+VvRxU5dD uf8KvYjvNoleMvUmHeA7o9dMHaB3DB2E8vi79A7OWsX7Qtgaj4ctQsVwUZHZwEPTOxI5+oEn W0aEEM7Pl9+iAsVRhD2TvH282RPJyvKOOTMzx5wZGQ+cbveYc4LLbDXZks2Wao1Hi1Hao1a2 okW5Dy1/PJwEr5ke7uKKBZFw5ePGykiP18tXRN7MzJLVW263scy/TM6Rl/XSODWZ/umSRSr7 OPAxU3Vbgvy7iEVCgDqzIzlZVg8XFMqHD1Lp0EGLdHCfKP2yXZTa9wuS+n5+kbx/nyA173t9 H7PWp9V/UC9k1yc4kHzo6AJPjvz7XhqvZtDXD1Bp5hv01QNMSnstN09OfY0mHihX5csH6Nu0 lObj90KiheHTooSXi3A/l+nh0wIknzvfpo/RhUbMwnCjReqjdbQaz5XDn06rsd1qwugu2mwU ZzeUF/clU5vpXmNiG5T39/aELFK53047CaUf0X5j8DwUjyE9R/vDMbyyseHiYplLl8CPoefT LKOs6vg/prnkD08J0qmToqSenDiJe3tOOlMNPYHTNDTFZUR7j08vkiurcE5VOO+b2NaN6+hc z8uTT/fjE9RfMdeI758yheub/aku+d3bFLu2hq8YN1Z9t3Ny5Ku3qfqeO1Pu6bZI3SiMGpk9 W450idKFLovUtRNf11eSUuT3j9HsNprYRnnK1tJZRurWKZKxlOJW5H55j0Xa0yJKL7VYpBac 4/1BQfpi0CJ93sSkoU5RGsTRqHeLS2T1Lu7Gp3dWLRnVeQtGdZZipLN1ovBXO2knZnL/T/H5 5/6LTTif5xup9BxWtRO3uAcuNdLGUI6nOUSl3eBF3OUnYFpIDj0aEtaE6PwQLQ3R3BB1z3Sm lTqdjziTSpwOn9Ne7LQWOWMKnUKBk8xwRr9yZEcLoyx3yripUxx50rh8yTHJO26y15HlGZft cRBLooUps8fZlKDSrgiOxPF2a7zNHhMbZxdEix0/EPYYQfNsyqOOPGpzBBz4pigjc4Wg8Gvy iSPGRmyCzVFGyqy1Qp11i3CIHLK2Oy4Tex+1Ubua53DTzIS0WFeCMzE1IUmckFAQ3RjtiHZG z0TPRmPKo2q0K6pHB6IW0ktt4YJowVvURsqpTZ0h/lOJKl8qf1PylTxlqpKrTFYmKdlKluJW 0hSnkqQ4FKsSowgKUSp91VRPCpBAdYWeTKFLK3SfFOgVspfoxVJAt1bW1XRT2lYLr86a8TxX 62JzL4MkzXmirqaXpvPhkLsPH2+iB1aF9tRKUqauBZbW6E2ZtXoxb7ySWUsCenGV7vZWSA+7 GoKbx7QhaLrwZ1zdU3Pn6Xnzvqfnz1s1VxrzGhdtwDUab856oF+7kPPBfR56968PcaFGiwR5 siD3BIPfCHzIPXj8/+gZGRu+OYeMbdgMCf5/c/5rzcGxOD1NL0ft/jOg28qLWLmkQmdzngzo 2pKAnlVZt0p3eSsC+kn0SivrdLu3ArkbRq8g/9/cwAth+roJm1PdzbiJgamrq/HX038RjX4F ouAf4EvwdzAEBsFfwT1wF9wBfwY3wQ1wHXwGroEBcAGcB+fAGfAROA36QSfYC9pAC2gGu8Eu UAeeALWgBlSDSvAYCICFoBQUggIwHeQDK4gFFnWddl/7QvtcG9IGtXvaXe22dlO7oV3Xrmmf ale0S9oF7bTWr53SPtROaie097R3tYh2XDum9WjdWpd2RPu51qn9W30pvSk9Kd0pXSmdKa0p LSnNKQ0p9Sl1KbUpSSmBKQEpHilOKXwpWFMM1UEkfawBCDAAocXQug0KZW5kc3RyZWFtDWVu ZG9iag0yNiAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvRmlyc3QgNTQvTGVuZ3RoIDUw OS9OIDgvVHlwZS9PYmpTdG0+PnN0cmVhbQ0KaN6cU1tv2jAU/ivnsahCdnxLkCokCGNEHa1U aJka5cEQDyzlpsSVxr+fbSgBrdrDHoLCZ59zvssJp4CBMwgwB84hCChwAcS+8hBYGAKPgJMR 8BGIyD4YRpTCwwOayk7N68qgSatlsVyjmep2qsplZRzcuaYYXtC3alfnutqjJFeV0eY4XKDV x9YcG4XW9gejdf1aaXtJASG+xMHINRmPU0vEQtlXA+Nktjp2RpVJ9at2dF2tBdf192S2lM1l IpptrD6MfU9Hs9WNqVsn1JV8srGl7oKbTnoOaJPSlIRRxjBLBWZZNh5bNhMn1ri2AsWyWSi9 PxgIA3H2wcCQEo7mhdx3wHyn6bT+nQ6F4P4IiGXk6zN/OpelLo53XtzghOhCESDUk3TAkyzV Rb0DVqZVZndAT3VbysJDmxMRZtUmRhZ6N6n2hQKMVtaoN4iiXlnvBPp55s+DkVf33OaqtaHd fVo4QC9qrzvTWoZ5vVUD61rTFKp0SrGvueSzeH58f3u8j2W5tVyX0hz6JdjoalJ1+vJ/rtvO xAfZAiV/xTPyyn/I/sZlcdoP5XVc7Q673R07KjeHLiUE3yRGgyC8SkyIsE+MMEHPkdHrzAIW 8tMpkEhEvsdNamet4MTehMdvw/vCmv/Mkf0zRyZC++2gJI5dKjkE3srsjwADABjTPdQNCmVu ZHN0cmVhbQ1lbmRvYmoNMjcgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0ZpcnN0IDg0 NS9MZW5ndGggMzA1Ni9OIDEwMC9UeXBlL09ialN0bT4+c3RyZWFtDQpo3qRZ227bSBL9lQL2 JQEmMZvdzYsxGMCRndg7GcdrezMvAQKaattEKFJDUna8X7+neJG6JfZmZvYhMSmRdTl16taK BAUUhaQlRZJEgBtFoVAUaQoTQVFEMowpiknxIwnpEI+kpPFFzA/jj6A4VPhHcRpTLCkV+FBB mEgo1iREKCmO8JcfiQm3+DwhIRUeT0kolVASkNAqJKgUET5MQhIxhCcwKtGaEshLYUECs4IE 30cUygDfx/gLoUlCoYIyfBVGIqY0oDAWArbADViYhhSmYUqpJBlATqpICtiZavjH9/BT6oTg gWRP04RkFOA+JRkHokdGJkACXpFMYYYIQlIBTBeBJCUidliRCvuvNCkp4TIsVHgaFwyggrOQ qSINb4OUYDDcFAGpBHYLmKtSFigQjwB3QkjSQvInChewTQiNCER4HbZrFfBFjIuIX0dwtARe gsPDkhEqHUO8CAUuAIUIITkN+RMEMwj5GYQakcCFxgWbGkYgBMIvOO4AAxcJAi35rRQXbAZu Is2xlEwRDq4MQRKOGiyI0qAPLy40P6NBFTZMMlnYHonACw49MyHUfJGCOQyvCnCB6AoFWikw U4AVsZbME6aR6AkDHrEXMA464RfTMOUw9ZRiMvWc4qAA9ITvBEBPQngptACt4LcARoligT2x AAkoCGYJ/gpUgom4AMeSgN9ikjE+YEmSMq9hdxrAFoF4pAzSzz8fLepN1bHhR++Lpu04tQK6 PvqY8bXsr29f1ubo06Yri8q0v/yCly7N9w60Tfqvr7LGQEQkhoeLrjSv3teNea6b5ev+8UEH YJ10KEuHnhFy1ZgnzuSdQBl/XRaNybviybRfs3XzNQxE/HWdNV1IX16dnV63X16/XS/vX+8M ZMRt2dKSd3Z7c0GnTXbfFdUDXW9K027FDCLctwaLUlvEedF2dfPicTG2XBxw6m2axM24m/6f 7uokdmRHf8vdaGeRjgKfu4Mvkc+XeOZFqu+pezQ0mLJ1zpaXeuWJv+TLEP3AKy3cl3ZR3dfN KuuKuqKruixy281R+Zwgmw4nVWW+0zVMKSZpT+bL62P69GSap8I8OwBAWleZpn0s1nRWPWQP ZgXprcNer1p1oPZfh2qvTm7o97r5RhedWdG6qdd1m5WEzFzZlA0nxsZ6x9g42jE29jI2ji07 FmeXPxH+O/t4tqCsWvZu2uxUTqI7PgiCvGx1VxqHi+MzAxelreyKBrfVMZ3W+Yaho8cDfk7v z1ieHCB4BQQrG793WVvktKjf1GvTDNQ4eWhMHye6M92zMZWtLPYqSw+UXe4rW9RV1xR3m17N ucmWpqFbs1qXWWdsJYlPSRIcKPntkBOLx6x6MHRt/tgYhHmfCyIYuZCIHReS0OKCN0OTw1T4 uO8k/bs1nAR7VoCauWlt6vNQYOlxfPv4VkwCetDqklYmxwdF6/gy0VqH6c4XLYMZwSPBhKNF 0zlYXHKJGfPWNdu2N/GWmuQwVX8FLBduWGbS9H4bmkGDNwkTfaDhn/vAT0xiqXS1uUOBQ9H5 Y1OgKuf1qq88fc6ym9emrcuBiNdmXTeTpwOscmJIZDEk3jEk8eZcYufc7SMbU5b1MwNsnrJy M6RY3hSdaYqMnouyRJpRtl6XhYFpNWX4ZAKoJTQQA/+WVFS4btd1BXbxU7TgB9nVs+9I3a5o zU/8EMYRZBWCuW6KGmpejm3KhU5qOaiev5V0szZ5kZWoMXSbtd84dXJDZZ+pTtEa3xw4FSaO GO0R0/Q4MxIcBAOrq2XRbRqD6PQUd5J0ioDF6/F6iIB3oEqDvQgcAjXAXlR5uVmang5WlMqh Rx27/rouhrSYIsiCWULWtkjvvmwC/Kxqn9H3OFLdrAlzvqZWPRqvB1+99TAND9Li/LAeftgU S9OPtVtrC6RK7+fAxzH3b27fu3VqVOlAes6l6RDStms2OUfTolvqrRjpYSH9sJ/PF1fXzshy A2OHvsT8+Vjkpmo5YqcmL7Ohd9m6vYNFelit3h/T508Xp3ZQkiko1sCQWgND6q1VaXwg/+yg Ez7WsJ9x7+ckDg/mpwyzAXXYQ+ZqkQ4tS7BsWqY4E6rj3hmC1WfjfZH3CA0VEFBWy6xZtvOK QluRnBE++KkdReHAs0HBTE2dWlWaWIBaGZ16ayov+fuInu4jyg0L4/ZQ5Seao4MB06J93OYl VRhR7+rli1MVndnXid8pAHREcycBGcdCzcFqWfAtunMFjEt6txXuyhtqpUgd4frQbt5+irxY Z32pREVHqa9R1YtqSIMPTb1Z4/OiK5APS7p7QS1FLaqgG44VxkFdjajz+cgWdj4j2eEe+3E/ zNLFPu72/GDRGL409aoPwhqyinrDveyhWNn1YbJj1O3GeQHkLxGsPkG2s4PjXDgxVlh7qBbJ nNDRI+FoCOm3rKg6U2UVspGJ+1x0j8sme87KoRIuUdFmacynShagegfoVuMcotEBoif7iJ6a +z66SFabpCJy3XJiA6w+GGxaWelQb3pq5J5T+MC9kzV8fJpc5QY2Vw/4kMzyNLE9lX5PbaJH wPkbk6QP5jOCyTfLcalpaT1Maz1lsIiA89iUkFcVLz539XcHB+niYCMacW+qeazoSx2n02pQ fLs4Ors6urj5QEveqV2qDur3kLOPCIR0lEjyaMmqF6rB+cbWN61utpYB4XRCWAQWwkLYCHtP H/g4cmeUnikS7Z+oEiOme3lox04Pq0iT5TzwtKhN7R5SqYWUEw79NqUbkzemyzAqdXSzWXNb cGafbT6NGI8YKBuD1I+B3YPUjzHYX9ddAruQqh85PqHGlihnolE/djwMt45HtuPWliFE6Hfc Hkglfdpu7yjDF9Vyg3Hsxe38Ex7Yy24+OGdIyl1nXFDlIQrDgEsQs4eHtRQo59QIQoIfASK3 9UZYM78YTzdHQLxTvwjtyh46bWl/xLKpr9QeA2xcQ/i+PYJrNts39x4eHFah86aiyx525FvX YB3APtfXC1qCixOEZ5c2AvGWEvYEJsYJbEQg8SPgHjY5lOA+vBtRPjUPWVX8xxqZ3YqvpBUB pawISHfWdFEXgMuZg4r+zPL23cQ2t4PK2PJSugdwk+DeM+keo4FLQPcGi1o+udfy2WPOo0b9 hBm0sSMsQuGHzGb6BS+hy02+t0hMuM6+b1c7mBKjpTZFSXyM7Yj4H7y1p83PMJ1dypb1eqxY 72rM6f9AKXDk+buCs4z3zN+F5Pex8V7tTTajUP8gGKZ/0k8/O2Xwd/z0V37nIAsFqmjQZI8+ gwVvprt+oOP9Ef0Yi8D9Pa3M6m6PHdI/rEk7o7dLNE8lTfHwOB4m1WjqD9luEhj19ew0y9l5 StqdTtqdTvqpKm2qbnMbQeWz2/3t4MurTwu3xkv3fN/17eTLa7rJ67V7MD09M+aggzdegAZq N3dvHoa2wlicLN+c1zkNnzgg+xuZtFPo1jSrvjZem3uDZ4cVGcXLEeZPJuf4nMeB6h5Rqzo+ jOpeHCH+DJJua8WQXGNH2B48jBx6LNaOPH/yyNTpTFNTpi5rv7ko+bNHBU5tt4I1vupPFOX8 YlkMq84CW2zRdcaAKu8XDlMmXbOywr8aLOVntHI2GF56S0MiPaaziocXYF5zNuWuPD+TlJqT l/DRwFPRWo3wvgcBnOCNdFNm+6uWUP61Ruk5JTGMnqbrdrPmbjQp7EvwoNEtt8rfVlQ0pyQ6 pveW5bv5aZTnTwsVz8nTx3SS51yauCdsMCY74vwJopI5cco2r53O6lyX/Umi0jmZ0pa5yqrx B0RHpj9pdDAnM4TMTbVsp+A4wvxppMWcMHFMV9nLsMRyP6O8rFs0tB3FXkzW2Cq0P7t0OKci OKYFhI6z7N1m+cBD9Attf7BzINb+fNNz+YZ0u3EJm/elYXAJGWid0zt6/Hmo5/IQaXgxe+Y8 OOSI9mefnss+JN+7XsgwTvRzBep0Nh1u8Kg98NxFyp9/ei7/kH74dp01PzLfn4d6Lg+Rhhf8 S0SL9YTQxfkHEb9wf1bquax0kvKAiv501HPpKCegHSH+/Ivm8g/pxz/KHDQiR6Y/DaPZNEQl W66w6GPr3UbHqrn/FWAAQaaXew0KZW5kc3RyZWFtDWVuZG9iag0yOCAwIG9iag08PC9FeHRl bmRzIDI3IDAgUi9GaWx0ZXIvRmxhdGVEZWNvZGUvRmlyc3QgODg0L0xlbmd0aCAyOTQ4L04g MTAwL1R5cGUvT2JqU3RtPj5zdHJlYW0NCmjelFnZbtxGFv2VgvKQBHBi1sYihSCB1LINA3Gs SLI9S+aB6i5JhNlkh4tszT/MfPOcy62rulnOGLDcFMU6dbdz72E1jzmLGI8FMwk+JOMGP7Fi Qgt8aiYVx2fMFFf4NEwZjc+E6Zg+UxZLfJqIGU5rOWDwnBEswRrCSlP6xL2ov4GHuaIL/AiB LYxhXKaEgf2VSnGBHx3hdkKGSWyfkAkJnklogQRYgs3SCL/Rbim25/iz4P2qGBfkRGKYEGRl kjChOFCTFBfDUvjXX3AmDOGkAhc9mGQiVcBJFZMR4cA4Sf9xeCKloAuDsMT0cMKk1vRwymQM e0UUMWlow4gzmRi6I5hMJV1IXNDOkWIqQnhFpBFWDcMjxFcguAIOKEmuRAlTStFFypRGDuAc UzECLjhHEhSWc8FUIrAKoVcpYiyQIx1x+pPGhaFIxExTRBESpkVMOMidJGRERGMzBCliWpNh giOtSAElRlNChZAMcaI/AZkCLuC/ThEohJbFUUzLDYt5f5GgGuCKECgLJfEwVsYa+whkMY4J EHfjmJZLyWKjsQrpjBMJL1BIccrpTsxMFNHDBheoKQErTZ8imTIj6I5CxUklKbHMKAodImI0 RQN3jUb2hFLMxJRPeGsMLUflmYRiiASbVMdUDiyJUJUCbidUmUJHLKFICM0ZXOc9ExJJlaIl S1TPDcUSHVMRaRS6oouYJX3EUA2JoQzCtyQxdAfIKf4TWJBGCMBPPz3/zX5uUdMRuHf1/DKr bdmynon4rbaPPSHpl5u8Lex3L26uX7OXeZmV6zwr2JW974qszauy+f7nn/doPIwmHbTL6pOt G5aVG/ayK9c9DtvYwt5nrd2wtmLtg2XnVVZvPHgRhlcOPOr0fdXm5T27fWLrqq5ts6vKjS3X 1oOTYTjtwKXs966qu21v7+MAnLWDeWxrLd3ww6DCwLEDnIwYm2rdbfFoH1APSIeBjANk2Ju8 7FrrWxGHFyfO4phd72yf1axtbblBiu1f+GfCyKmDrNmbYTUrqvWxc0kQxUQOimKrrCgadlfV X7IpDaNxB03ONt3V9s8ONfHkwpgwH4zLBzGaUt3d5euplu+mWvYQw5wwLif47Nz2FoAP+e6Z k5BnrM2aj8M2m67NbfOsv77NmnzN6q6wDWxh1c7WR4E2YdoYlzZVyVL2W/XYG0Djg3soYbYY ly3vYTwMYNmm2hGZQcHBsW8S7eGFSWJckgyLP1T1R0raZV2t7aarp1JfVR1Wi+cv87pp+1FO K3/N+l+GAhu3C1PJuDV7wU4uqm+bkz66uCy/bfEL1d4uq9t8ne+ysm1YXrK+Jd7Y9UOZr0Ge VbXd5siXHZI0GfyqrrqdXxBe3fvOXvzI2WVhs8aiKZwOqw4eHG023iqxX8XKqj11g6On4CSR E5yEu8EJt4rErfoVe9Xl6NN5aQc+npVt3tYdAOH+rsgzv8VKn05+pFfw9c1c7Ae+pnsTpNet Vj9q9hbToXZd5Hsfpeujcn0MN4jErd9z9vbR1o+5/USEWsMttAuiFCuyT31qd1XT5LeFZTm5 PDS2IRx9SdAjOUpkJLIbDn/a+rE9Rzg+PKDv5s3hrr8s1TpU395VqeMl5CF+2njboJ/C3qH3 DV0jL+9q1KqlGdTfOKNKp5bCIT7IHw7ddfPyxTu3jpNwW0ncmj5jr8u2rjbd+rAxJWFOJuZQ fHxd5U0mLGK79XRWlvYzW7HVg11/ZEUOQASA5MfqIctrhORbhOS2yO/HPIP5pCfsen4QhMvv xjoYGnTerIuqQZeiR15fXnn8T8LTM0mPLDuHlMk9FZSE52YaHa0/G4oSKbBFAaM7tCo0UcyJ 9old5fcPyPhlhTJ+8oqMT4RKuUOoVDiESsKESqU3v3u+jnZcXo3bsS1NN58fypuVvjsK/PgV s7ZsqK1i5XZotPARHdk6QV/sDFLGDl2kWdpooItMvF1jdtVnNgPhab91kdX53dNgxOd2qEYq g/VDBg71BbIqsg7NmEwea+TAeddEM4dauaHWTqjTsCpJY0/cvC5hznYoRfx70TRYQdqOqpBm MRni7i7n+Eg3Pm7nTLUfLDe5su9aFpUO0X6XU+vzLbCeBYuNTHJ3Z7G02eir8nYWQ79sn3Z2 7GLzxn2bnqVCn6Jut8naA9mg5tC7uiF1dUMalj1p6gnC19tdVbe9eqak51tbPB20ghfBYMxl KtwyFWZvieQHaXATL/azlF308tCfp6mjHWTk2Y15emUxcLakNPejbC9szqtNTnOiRITXRbeh yr+u7tpPwJ510AVaM8ZmhrG46BedSsx+0cmEE+Fgp6aDC1cg34SINAQo8oWVlx7uTFfi42VX Y4zbiZ57wF8OAucKkSj2EDU7mRN6ctTm0zTslsugl1VtP1Xei+7k9+JalwPn2frjPQRm6a+W 4dV6caxScr84If74jtz74/ulziGi2E2tU7KTsYuWuF12zMLV9Bozq3wvvV79+67wSbIwwU7G 3A4Sfrov2cn1uho6RQYl8pgTS06ogOf+fI038P1b9MFGYwlor93+B1T5AY3mLm//y941/jgT kQ677xbngbQhe0ha2vlMoNdk/TgXbgbiKQPcJRfnbgaCYoHO7g7Fgjnd52B+lZxtOjyPkX56 fZ+OX2f7dOzfaA+C7PGMe8cTq36w9onzQCHMmm5HTRevmQ3lboz+WX8eSRCjCDBzoJQbKO0G KkxXHh8FKj79Sll18U+kYtjib3//B4tTZuhg4MfoX8+vn7+qbqrRcDn2ycGo1MuenzG+IKvh uH8OMi0ZHDHH8jBmP7Cz3Q45yaEVT/tGuFdZF5bUzlwFW6+6ebhJcXO0kT4F7iCuz25v8VR+ dHw4BXoR8Vizy1P2wVKkkf3fRolG537WxzRhzGO1LU7p5ait89tuGIXjUWSf7PNuc2/bJQlD 59f7uhIuAXmYgOKYgPwUMYeMyp13jeGcdbJkKH2Gtw17X9X5wNW9qBs2FdwvAp+Yg1BgqxnC pyJPXRsjT+P8jjofxe9mb6cX7zCPhDv2pr7M01N2RtpjePkcvZw6cd8z/nI0TJFc3FQtbZog znmzOzgynSxcxNFLOGiYb+kEkCRdgS7VZfcHiOEJKOIlRHSWKzudPuwHlYcZHivCLGFqwhyP 66kRjxVDwa76V7NB4nl7hKkokqU9FDpikd1WQ7d4xrIdxuIjHSrTO8HRNJvmLWZBvRnSvJcj viVhAot0yRL5lZZ01Lazcm+Nt3uYvjJa2h0dxPm2ANX6+Wn8MsKDDbNE8iVYNIb9VxpEiFe2 xHwu2BkU6Pa2cIXwZNkiulhCj07H73Y8VkkehlmiMph8bde1bfGCnLUeUpifcomfPT1rjFWo q9FRDy5MU7lEU7B0+opjf0rrAYZZKpdYCpLu34/e1vdZmf/78Nh9MmURdImmYOmhwpp2X8RY oiFYOBxbZeUsud5jnP/g3R3l9hdLKMw6ucQ6kO6LcGEaqSUagUXXbQ1pc9DoZZg3apE3KOyu KMap+Yxsq1AHrZ3vvL2Fasebax8qmuoNBB0Er6snh71VmFXKZRVuZfDfs1uFqaSk/xWMhh6r 84Jeko0HEeaQUkvfv/Rtb/gC5jA130Al/vHd9erN9EY3bhHmlfJeHKeWeWOL/uigK+dj8H1P f102bU5T3NsizDTlMu143o9V64GFGaZMQGtg7DdV0Q2j4UNe9scZ73YebJh0KgmoiSMJ03y1 iFFhyqk0ID7Ouk2OJunBhKmmo4DiCLRtFWab5gGh8aW+rcMM0iIgKujM5697rQ7zS8uASLhZ eKWd7FgEUoF5P36h3Pw/fVWHKaZ1YPB/ES/MJx0HRv1iZ9VhLmmzPOyvbFN19dofpTpMHp0s j/obW2+hPiZBdvid4IgbZodOl2f+2WYLso/vTgHUMFniaHnwB4DCVIn58rC/6Oav6v8nwADh UWOuDQplbmRzdHJlYW0NZW5kb2JqDTI5IDAgb2JqDTw8L0V4dGVuZHMgMjcgMCBSL0ZpbHRl ci9GbGF0ZURlY29kZS9GaXJzdCA4ODIvTGVuZ3RoIDI5MDYvTiAxMDAvVHlwZS9PYmpTdG0+ PnN0cmVhbQ0KaN68Wk1z20YS/StT3oOdw9qYL8zAlUqKkWRHVbKskuRks+s9QORIwgYCGAC0 onP++L4egNQMCGKTVGoPMkEQeK8/Xvf0ABYpZwkTqWBG40Myrg0+FROCPjWTicRnyqShywxT aYZPyzT+BI5TiWvxW0q/G86Mwn0GcFbgUzKb0nfFsoS+a5ZZuj5lPOEAMoZxTgzG4kAC0mSM C4UzNsEBTgvLGZcaFwORywy3W5ipcFoAi2ue4kAzniZ0DZBTRdcA2Uj4ZIFsyDgLZAtUkQE5 4/gpA0SS4OIMtiUK/2Qg5pIOcJbTXRmuExqnM9D4OzI4JA2dgXGK0xkQKxDKBDdoQUHDWY1o SvKa7PFhNDBVEp/FhTIh4zK6OCVQgQOCsPSTZRIe4iBjUsAwyXFWIjUSfFLBHslxVis6wF+a 0k+gMRq/wzdpBR2AL/Ng+DnL6MAylcA5iegrTnkVCVOUMIkblEyJUDCl/BnJlLZ0oJB3f0Yz ZTRdkzJlM7rdMJ2Q4QKaSJAQKTKmBfyWMmGavJSSM60EeSBwkNGBZFpb+klBSdqSc0wbCUD8 gRM+SSBbiipkkSaG7oLcfFgU9CY0zigOAVLAEaNUkcuISKolHSiWpkSqNEstjJIqZSYBoYRE Dfe3W2YEBUllDOQU0QQKRpCkJikTu6bSoPAi6CZFuSDqzBiKhtbMkK6lBnJm6BrDbAIwCZes R0awLOlCpgmzCir4+us35+7XDrJIUHmXby7yxlUd83WIb4374suRvlwXXeleLZquWJaOqbfs e5evftnkTeea9qtvvnmG4oeh5ASUfMuulvXasfqW5cuu+FJ0hYsRxWFENYEo3rKLTbOuWxeh yMMoegKFv2XX946dVm1XdJsuxlKHsdIAq66YZot1U5SoaW4iCH0YwgQQPyC8BXDy9bqpv7gV u3li713lmrxki7Z1Dzfl099QKZ9fXR19+PxVRJEeprABxcmmQfzzil270i3rh4dNVSzzDqwt u+ryapU3q/ZAIMwhikg2QKE7W8pxdz8gHP+L9yn5x0//ZPDAoJUmr5N/v7l6876+rv01C9/H 6aKej0dRE1wEPpmQERceu9uiKrwbW8Is5FPoQVN8MuAzyQxfqD30ux+KuvRRIy8v6rJYPk3y agKd4NUhr5jhDRWGEPZUcHdZtAedRUOaJDUhqZohDQWDX87yRwZlsEt3t+m9nqQ1lL0J2iyk TQ/T2iSk5aBDFaw2y22Yn+V5XC83DwCIbDGhLRw5mrDFhvoa3Jy2JdJXwo7q6rZY4boiL4vu aZKTFvEpzlBjdkZjNtRYxk6ur05Z/Yjqb++LNQXg9OJyl3AdMtO6NMUcqszOqMyGKrPsvK7+ nn/JizK/Kchb4j4rlq5auh2//B2Zt6Hg7IzgbCg4g+5zWzcPQ3lV5DY1QorHrplEuT7AHurO zuguC3WX3hQt+9S6oXt5cu97W1R3VHdl3vSWvYON7aRBQk7WXxaKz86ILwvFl7LF/0iFSGxU hxwzxxR9qMNsRodZqEPNLpp66VabBh0daUElPDwUXedm+M1kr81CNWYzasxCNSp2XLTLsm5h wLgGxsRyelHJQhlmMzLMQhnueu3Hm/84GlUOO5xidJziDQWYzQiQhwEXU2vZHiP5NGLcv8pg Ah1fNSyt0dwmkuzZGto5hOlH+B+KtsUEguh/V6P/sgcMIvEgSPuOw4AyyicNWo918zPVU7Mp XYwjZnBUlJ7IlpcM+lwjYkVfJxGmPIgpeBKF/rx+KKq+vGnBoxFpu/occl0kJobXAXySRvCf X103+cp9/oqmuXpZ5EGSB7AojjyL/A9HRf5ascvi7r5rvaX1TVncDWPcyjUYrBHd26Z+2DWx cEgZ4pLOcEUjwGuJcbFBaOqyvosxzEEM7HAjDMF+vHco4iWGz1MGia+8bX6Zezbw2x79qN4A z755VzRt53ehBHWW+y9BH+WZjQ1IAyd4qGSBgHmuK7dsXJc3iD473oz2H7SnC/DkIJYdxGs+ Xp1OMJf7scC3JlZUPcuxK9EymvxmJ/ARZG+iSEb4ln3Ii6pzVY4WT7or5ujCYKW7YMkwWOo5 WDvqyWDpyBLK+PKe9gYlpL96Ykf3edFg6HoJge1FjUfA48BLRM03Ncdav/trMbk5GuD6JeVH dAN2ijOjSIVNkh4pxJhpNJSFcYosEwdd5pmJIAX70Fc3W9Xs/OM1u8+/OJaTu0+sq99GsGrK 4cFSM7JUw9L1U9NX62GBDMjpDLIdIaMHYBOHvkQ9oHHruunGgnmWyYBvZvCzEb6kmu174ff1 47cRjp3BkSMchDb/mUq/LH3Gt6USaQyaQn91HVpXbDGfKsmhfviofgxtGxAG6n/0kIG1mxvI bVcyDHsKhPwhqvlkhmDUQyC7xfLnqn4s3erOa7ifFAskYZ03VBgv2XKX7ohmzg85otHbucc9 o7Fe7LeFW+1ktNrfCg1sYoZNjdhIR6smv92GbVahQs4g6xGypN3EdnF2NMfn/UTvdzYRrDoM y8dtUqANY0RCG0GK19sJlUw/KvMNiCx7JOVWNSt30/sqmN5pFbrBDTcd2q1bhYbIJG4ZcTnz 17QzJXdWhNnV7Aiqbp9lvXYNFWCfo1ETjeU9YhgiaEd0f6h7CDNl+4CcjZAV+7Re+RCivpf1 w7p0+BItyuFid7Xt2uRrXED2MKtMRqzSb68ilukN1u3zBmugyWacS0c0Itw4kIPPOoBK1nDF Lz80IuXsYnF9cn7N3i0+nJ79FGlhtHyE8kZbgxbouVzbbhsBeRNW/ujGISR8hCK2iXhWMskp itHHqqQFFJflN3n0tJMeYUdGRnOyF2w/+Kzdkrpg3yBZQg+HuRrZqUI79QhI4t5fNq5F4KD7 nXnBRBWZpabMGqDlCFr4fcHY2+MJb9UINmzQaM/w9vui7erG75WX93l156I5SW/nJCWCOUnJ KdTeWKVGFNIbikloXbd+o4YGd4ftgW8IcKMXcF72wutnnm1CB4uCVkVD5fC0YTQMB27zbKTE JIxmFhmo2buC5kdK9rKuqOO4Kp79pT2MppIITaGDdwUNo5W3cdM/HDk/Xvh2RNZW7q7u9ncz W7umWXjEIqlc1xvUAJprXW7Gy5lKDkLxLIaClJq8am9dQ3Z+DJ+gnVxdoc5PF2d7Y5GOVx9p xin3bd8HIF+tiu2ukL7TQE4PZNiLq41/VuAXhW1uBZaZsn787UU828qweWmxx6a3bO7XNVZP /1rgxaXLW+gKTZ+dVCuXf6k3TfsiFLfZiVuH4k6DTYA0h5Uu05Ehgp0cseP37Ojjh4uT69Pr 04/n/y/Z9w6JrUM63ALqYAtIL9PC1O1Vq+/Sfy5n3hGstS68d33foCWxF7+xAiMZ9t+PeT96 wNUbeqfins+9jrLDd9kxYXbMlP1Dldg9Z+SUMlCIfvpcbrB8jqSmwqQenS0uT9/9dHr+np0t zt9/Wrw/6RfBOMnTVmeh1VmYgnTGBb3ngtjLx3NMH/1DAkS296eglbpl4/KJ4nK5IJMXZzOe DEUeT+CRZb8DZHTfULvJH4/ui6izyanOM4DLvcagfm/6B5fFDPreugZx/dnMDHQzzqj9Lie2 zqz+ghobLIifakUvVb7zD3B+vK+Zo7l2CRAae8Hsuct8u8Ud3T2ES4+g6IlW3jGywrc42uFg PKJn89FjLLnrYTbsYUEB8fjtCLdhU06TiBcp2r61TsQ2XteNy+ntQL9Ev9tU/rnlMOz6Frt9 7/upIlc/v7p+d/IpeoUs4/e79F8KIlofudxnIzSAcJC+vCSyx6K7j0O4hRlcGWPKOISYf++L m6LD5mnd0H8QoBRtsNQ1e5zfTj77Gt5K9xEeXksPujAHI8ytjMwSARn/CyL8XwEGACsidMYN CmVuZHN0cmVhbQ1lbmRvYmoNMzAgMCBvYmoNPDwvRXh0ZW5kcyAyNyAwIFIvRmlsdGVyL0Zs YXRlRGVjb2RlL0ZpcnN0IDg4Ni9MZW5ndGggMzA4MS9OIDEwMC9UeXBlL09ialN0bT4+c3Ry ZWFtDQpo3pRaXXPbNhb9K/dt05mmIUCABGc63XEUx+uZpM3ESvOSF1qCZbYSqSUpt973/d97 LgnKAESp3QePKQs4995zPwE6zQQllGaSjMKvlAQe00yRzAx+a0pNjt8ZqYL/nlOW8nJDueT1 BeVFQWmekMGeNBdU6Ay/JYlEYnMOQCH4LwoPBS/RJFIJ7DwjoYY1OQktGMVAegoxeUEiFylk J3jAp9QIEqbALgPkglUxKUmhAQi9pYQVqdEkWYPUZCQVqwHVpQZGagzsUfxVQTJPAVgkJI2G iEKQLFgNBk001hT4q+DFrK40vBhfpxrSC4Aq1rAAKVryGmaJqRhoEJpUwvKSFA+DPImHYYPC A/8VGCrBB5HxYvxIw1/hr0ynSnJSathlCEYkvINUpvC9wIc85a2ClJFYI/BjGBBk6UTwVwoP 0EVBFZCasxzSkgFFTloJ/sqQ1gNOQTqDi5RMSOeaHwRpk2IX0HUBNymZUpbAnwpGZnAYsc8y yfrKDA+GF3NYwAUwhTKloKYsKNMptiNasozVTAVlOWsI+jLDOCmQCzYOqmQFk5BqyhPGSTPC WnADVXKJqFPAytn5Cs7LFdMCMblmWXBVzmGjAJrnkKNUigc2WSnEJ5MNLJMM1GZk2LlK5Xhg fpQhIznAVUGGQ09pRDProhANRiEclEZ6aCYBHJkc5ipEnskNfwVkw4AIOFMgEZTOqRisQMQU ggnXBSHEsBh6FylM/vHHNz/bP/shsRL6/OZT2dqaPybDx2XVb+2rtz/IHwR9fSx7qjq6avtq tbXIK0HL99dfaG3LbVVv6I+qf/zndz/9BMwI5lNrn4acDjGzERNrqX+0tK12VW/XZP9c2X1f NXXn0JyGck5DB60iaD1Crxsq6756vWp2e9tXffVkqdy01u6A0dEKMqqup+YhlJRekKQjSWqU 9NC0uw5APjwbtm+bx+p+sKus17Q7QNw9lHhqqrVdh2LVBbFZJDYdxWIlrLKjrO5w/5td9dQ3 J04KBekLgkQkSELQM/u9gvd3+6btwSibS9fLu1uWtS+fqex7VqWp+Q/szPawtQMfFzVBPPqa IGBfNEHQ+pqkgya2hk+tH4RyDMIFlfv99tlHF0b46CIvfDsLD30BL16tEB0jl1U92BZQZs5D 5UkAldJHi1irN10AUJwFECYEkIRVMK/alwOjUIcZ7e3qsa5W5Zb+aNrffTvTIHDQ1DzsNEi6 b9/RL4ubOQW5rvkg0t8nfhAJUurOtk/VynLa9G25QoRzGNzt7apCBUBgL8vud3rftCvbBXVg QhtU4poaQRe02DYd15ByHm5EWzQHgOVv3lctvuUGzjgfyuHDCDoSItPQFuF7K4+k0/tDvYZs wNZlzbKRSHsO9MG8Q7thkIhz7iJ+5OYqtknQ4rFklmwLW6rVWBzmzaNvr+6W7799FxZPh+lI E7GAlD61zb7poC9XFoR/2zzhA8RccslIojqSaHwSixcSj+LnSAwiVsB/ny0Txh5s7rfVZgjc MLySkK/QC8VIV70Zs69pN2Vd/WdAYXf07WHVH1ob8eNVC+7zIaCiRbm19bpsmZEw4kcOxDGS XKEYSTDSJyG/QEKYIoY+VGXVTZ2QGiRtS/fNugqpF9KJ5TnoKJZnoRexJux1Ed0GbHGJqG3b PVb7AD09gisfXM/hOTNEBC45sHbNUHtA3VDm183qMDY1V41uawR2PXloabcWPXZ34AI1+J6+ 1Lz/26vb5ZcpsEcN9ZF15bOuffOTC6yH1SOnd4j1jmXtyt9B/jwZwifDd7CJmAl9mjPTbYWq sHftbD0nLdrtFFURlKSr/d7NSuWmrGooU3LYV+2urP/RHbGDaBFHunKfriBaLpQ7E+ZFRks4 b3DpV1Q09vSmLXc7LkHXXz9NnhpzVoQ5GzGfgZsXoNve7rqIjczLz0RGmwv6dHUHqZ8OKBir 7TNdPZXVtrxHUx/K18MUSehZsYSRmmxipkg8ZgrhM5OdZ6YINdK0aOonW49daPmWdmPJ8AlJ wqIfcatByG2NGaKcBqFTnGir08REOFmgy29NhS3LY/tfINEqzFt2gh7rzeL6Z24Eb9Cz8Hj9 4XoBdnfN2pIO3HqUPUtKGP9qfhThZji2s+XbuXzjA6vnET+1C3lBeBhgKecL286Fh8WBzClb 3vyKQeT1+AkzITfArzc0ffatLYIKHhuYwmeRlElE6LDCT+0ij0BSNMBuz6eJ+2o7DpFHpEid 87kqZBiRkhatHXln+1Bvd9VYcUPuHbCes9PpqyJ9ZWz036dzNgWcmDgfNH1Emevx42XV7n5s W8TzSQBtzkLzXUYIrcD4BgDtSAhPameydlJrHldEuCm9c63uL4Enpea5iBUG5RseRy6qasxc xXWqplEFNXEJH6LCVYu3/19RmOrzvGQVSc7pDqfANcba7TYASS+A6Agko3dt+dDTv8p219RV hxPygFq26w7HZrsHypowm2OKKnEiW7y5fr+8Qt/Fkt4GYtUFsXHTwjGmb/b7ISDrqIH5tew4 pSX+lJZ4fXcyaV5u1He5lLKjbDceBOZFO9wgCk5NUHwbM22kjxVGk76pozPXtM2pk59gSPrS WVemMHhzy+nbZov4WCzQc3foNxjCu1Cz7LzFIolEoH6vm/2xXl20uDiLO809L7heXfwrXBEF ZDyS4SBFvzZDD10f2vnWH212xp7MiTDXIXGCc5fkmdiv1rPNq4yqbVkH+ss5/Z0K4kQFOalw /4xDetsOPWlt61WQLiJyooznfx56Gwxlz0g2zBltN6hY1XzH5fUflDPbYh5BTzo5mxnpa5qd SEjpzjtjTz4cLhaq+8PY8/gibc2mRK3u5DQTyFInsmQoi/ig0jiJOD9XozQO1VEc++7G2XbV dWhY2+fZU4XMvMogc68yyMhv8RGL4275vB/HhP3LUY5svSk34/XhbDEShS8ymZPizsOnIpV/ aPQkEbbbP9w1gj9l7NtmhXplg4N8KHQ6tgZywuPpjKSwUDkI579iBk+ew/O0DQLEXCBGnghI z8E7Auadn/qeUL7zxXnpIj+RLl8igeN06y6Ph+PDonnd7K2bca6mm+XAHUEuzFnH6fyx5Guo ctt5IkInSD+JpJ5BSYcDW7zfaaHmtHBg6QyYHOo1l6ozgGELnKGNU+iD5fLEzPF1BBZ+e/Wh uY3u0abNThszg5SeIZp74VU4J8l8TjGHnc1gS/pod02L3DrsWNMvPNB0POiw9d9efWy+hMez vJi7KXO3gNG928tlM1KLS1yYqueRpnu/FyR5vIBD5E3OuWmbwx5HT/du47N9sO1LOwmvEpW7 dx4zwt07O5OyuctSp4iOLzbldCP7V1eZ7mYxzIDTi1JOgAlxf7zMCWMk9ZM0VacQ6gjx0DY7 d7nXNYcTbdI5bRzuqalw4DTYPoz4AZi6ACZPweTY1O4P643tqdxum1VcG/lF+Mw9v8OM78Zx xria7pW5O+yHy5rjDDB/mb222+oJuXS/jajJLkg2seScrpElENc9Dqk4vD0r66k0n79MD0Tm Z0XyvwZEIjMcDawdxsDVdMfio6nwfVJUa8WZK383aWD655dz0XsRv1CqKHK5LF3A81pWgO10 TeZ0dWQXkSA5/65i5srJf+0UTgIiaOPKL/oc5b/+cvsumGiKqWwo/6JaeXdF/Br9nAARzAly vNAY43Ro2pjmw1v36dZZZd4LD5V5LzyUDntOZAJXERymX9P1oUWrgBum0+psMVT+bKjyOWTH lInE5HRzx2LYyWP9De5Dv6ebz/Rf/+vx3Yvv/CySp2MRfOvlzmZhHXRLR9WCl87jPkX0L4RI 0w5hcXwrMDshKX9W1YnvWH2eDy0iocjKz+DD5fqctRFaTGh23lo/ZDN9si+lr1X/uG7L48zq 9DcX9JcRjP77jGl/ptT+TKnFBYmx4oqWxwh6yeEoipafT5fMcBt2oBPj1FlutV9xgv/PGPed chtlkPYzSPunKy0vkBF7Hw32SMaUsd/T9c0xxQ7VOphnxLFS+N7IvHlGhf+KcuqA9DwrQX7J k33nWHkJET+pMj+p9IWkUjH/qJc1l7N/H9A+Hyr+7xSc8ufu4oJoCKPwhGt53u4g08TJvsju /wkwAAYodHMNCmVuZHN0cmVhbQ1lbmRvYmoNMzEgMCBvYmoNPDwvRXh0ZW5kcyAyNyAwIFIv RmlsdGVyL0ZsYXRlRGVjb2RlL0ZpcnN0IDg4My9MZW5ndGggMjY2OS9OIDEwMC9UeXBlL09i alN0bT4+c3RyZWFtDQpo3pxZW3PTyBL+K/0IVSTRXKWhtrYqGwKHLWCpJOfwwotiTxIttuQj yYHs+3nfn3y6R3IyPZYMS1HBkjzzdffX15G1FZCBthJyiR8KhNb4qUEKemxAFvTcgjL0PAct DX4WoB1eWwemwOs8A6stfgrIBd0jXOHwU0Fh6bkGl9O9AZFZBM4tCEFIeY4XTuFFAUJaeuJA KIWbigyVESilECBMhttRFWEN6lOgnrkUeKHxwuGuApFdRrsQ2aE+ushBZoq2F2hMeOJASk2q ZyAVmqydAKk14jgJ0gjEQVWkJaEOKcgV7nLEgaA1Fi/yPFgunUZ9XAEqk7TGgRK43WQZKImK mUyAUrjQZBIU8WcyRRxmeKFBWU2LDajcIIWotyqUwosclMvoK0R2Oe1CMRnSasgdAqUbUkXh YyPQAC01XiB9RuJiEVxHa4hHkiUCj7SY9A5ryH7kzwgSrPA/SetoMektw4UEo5AoI3GdRlRD YshFBn1mDLo6yLOEIVGeLWgrfp2jd4ykqEAPGqTPFEiSUfi1Q5KMkmAzsgKttcIokgNW0g5l wCoCw502CEXnWRMuCrD4HV44sLnBNailLUgFdJ51tF1jyGUFPVEYgyQdAzmn0DLIdS4LWmMh D05BjnIKRoNG5iTHoDtzSwSYDPIcXWQMxnJO2w0FM0aLQXXzIAtTIXfhKwNFZunCQiEIB5Ur JNFmCihURk8cXtBijPuCAv+XX04++G89uirD1Ls4+Vi2vsZb3BFuW3+PNy7cXFX9yj+Tx+Ef vC+ruvd1WS/8819/fcRBmQzHxDg2wVFTOI9b91eLYwHv/frat91dtYHTzaZt7ssVfGybhV9u W66J5prIWBOVYOsDFnFmdMyMTpmx8ziaM6NjZmye4OTHCj5V/d2yLb+WqxjG2nkYbfdgJtQ5 a7a4U568rtquD3WSNr0rw83A0iAqTyzXCTq543TZbPqqqbnvxqWDViNMvG/WODclceSo2IOZ 5Xo0Y4czsZV0P/8wG0LJztEQMQEj4eprc9T1fj4eB8LNI+E6Jtw8ES4ECxEq4pHw2Lfq2MGF 3zRtX9W30FyvqtuSvNDFJDhOQq44ABJwdlfWt76DqoamvS3r6q+AghZ0fbtd9Ht0jBiDRi5L AA28rsgVFQK0O+2YW9QB+3KGVgCu6ush0xmGPYBRMIwcXvlF1aFFsC6/pLoc4toxHAufmvYL efW2LddrHmnFPEzBCTJw1tT3viaXlTW8vXwDa+/3OHIHAAUD1IGjalFtgtvIjf2dh6+kbHMz yohDUO1CsJBRCBYqyvkiOyBeM/GKAr7B/FvTUhSI4VS167J+Af+pFv5ouPV4++kN7G5iUwue 7Yl1iqrLlACfFJtx36ijS0AUJkq3wdSorqtV1VcY7ntIAzv6kR0Ts2NjdsQsO0LwBJXwrrrx i4fFyqfOGLEKbj0nV1J6tn5wbLI/2TIanif7NVz5do0JOQUxqmCnVBjxigRPwVVb1t2NbwPY oq/uq/4BbtpmvQvnvoESpS7u6mqBNeCsWa+rvvcePj+7Ovv8HKobqL1f+iVTIj+ghEmUkHD+ Det9N2+SmoqpEU0msSHTAGNxi+jLkPmUsG/aZruZjOKxgk+XSJGUSA1n5crXyzKQ+H5If161 swNwMoFTO4ix3nIkMY+U6wRJPjYDdCI3msIoJM2FR+f7ZI54rCkubmuOtTXNsyaexFycNRrL /vfaGp1UYrOc4gA/09ZcRM0O/wlQfd9n6oCBOYM72JOcPYBTMJyxJ22mepLLD8A4BsN6El43 7XJXMQbnT3QoV8zC05kzhv9eh5qQOBVbdIJ9jC06xT5VZOcOKMNDY79f7Zv71LN+ohTQaTpS JiXjRxvabt9ohE5AfqShjepks9wIwbmRT82GTO2TzjHrp1GQnLJ71F8k+k8WXfiHRddNFoEx xHWSwPJAlRSCt/TMxbrHuWuwOM3nLr03mccpGE4+n7s7kdMwjsHYf567O00m4UXG4M3P5u4o yR2QJJgknUbE+dXlW1hgJFTLsh9aUnNzU4WDxabpqtATSKF9FVirENkBHSTTQU3qgPHS+g6f oIT7QZHviZwPJ5EQLBOCd0LDFHWQXJG60UZSWNDS+wgKk+XI2U3TjrELV2cn5x9PaGyr8Ov7 arlFdhdN3bfV9XZYvdliC14wwYYLjhuniBvnKXr1lV8ha215vULqjjDe/X3VbDuoGyR5sSp7 /sbGJHMCB7cMXDFwBjKvoWC19JSO7o+z6m/N8oHG1N9wTD2Bt/Vyi7PCA1xuMOMx8uK0+vwM Sfv8nAlN/BHH1lmY5edec+3WjlbmyUY5/aKEd71dvw8QMg6yV+iFC//fbdV6iuvB/4tQ6WeK BrPqgBTBpKh9KVQrfNejf6rubpdUe/P6Tt0JGWzgeUVtYzlEcXi7kEgLiRO9MaDD+p9+wUo9 vTiOZcURdR6cFFCeYmIYRZm7nI1J0AmCGhBC0CT7Rw3UhAYjmEzA5AD2ZlstWZZI1iGcYdvE vhUshLkxJpafJ0BozLZtNh59dtmXNP4umRp2Qo0RKtVpNGUChh/+igiliN3zL4zjkdUKR8Cr svsCr5sW54bNqqzrpMkppho79b07NnRAuAAkte6naSnijFQ62W3g35vlmD84qrR+5csuHPFr /xWwInWhdOI9ZcByukoVbGAq4nlJcXX1eJoJCYb51IUSjbuYwWIeTjE4lcAhGqrHsGZVY+9n 3j2eGB+hWn9b8WFGZROOGPUyCa+a2lTfNqtAa908OSeMtxdI5TB7sZRWel6CTSSox/EN3YOz w0X3YnRht13xSqHMLKx0CayEt+tNuegJs0Gft8zpQcKfNFiQwEgGf4+Z61jzuPJ9hNO69t9A vYTzyz/+7qCtbu/6bqc5PwiMM9qyugkn9R7WzXIXeMORKt8dqZSLjlQ6ezpS0U9Qc5ppMaGZ fAlXKNQMwshbi+YIC0cbpdaAbFhD4Xa+x80g4H/Ye7Ggr8PARdkVgfAfLoyJXtMZY6egB61N nsoxQU7vcf7u/XJSjN2J0TImSsVEFfNE6QmixMuJdylwdv7hCP/O352fHYUy+XuIFsTpQpHq /t7vzPy3Le6W021/17RV//CSnyq1iCmJdzy9crkN8+zLWJQW80ayt3NwXtPEhLo31JIX/gUs t+3kmXLqZxEz/ng18pxHPGs9p0IeayAxv/uyWgV+T29bH+YDRlvGaYt3l8chimfIx6Hv94+P Q18CMLIRR7M/pnJ2g9Mz5mBZl7d7uvCfAxOouMYsCeopn8i4S48zXF+2VcnLli7mMU08Fy6O fzRltTugZlxhr4/hXVVWHVVXcne1S2NU2X9bhFbBgNVUCI+6xj1w9zJg7TGulzw4jTgAEnc+ dtLiEPIARJzFf1zTQEnHQL7/gB1asizjxZqj8PKlY2eJMSijQoHJtBvv6DyeRGXc/w3PkAGJ 74aveMQYJrRNTBPzVnagvO6VcY3l9axZrcrrpp0q5KPN+QFMl2IqxLzcXh+FEyr9+hBe50yg FvOoag9VBk13Z95pRS1DtPHQblnhXbRN/bCmjPy/AAMAd5ehMQ0KZW5kc3RyZWFtDWVuZG9i ag0zMiAwIG9iag08PC9FeHRlbmRzIDI3IDAgUi9GaWx0ZXIvRmxhdGVEZWNvZGUvRmlyc3Qg ODg2L0xlbmd0aCAyNjk1L04gMTAwL1R5cGUvT2JqU3RtPj5zdHJlYW0NCmjelFnbbtw4Ev2V eswAyUS8U8BgFlnHuQCZrBEbuy95kbtlW4tuySOpM/F+xn7xntKlQ7LVcvYhMdUiT1UdVhWr KGMFZWSsJMt/FMnM468m6Q3+GtKK/1oyWuOvwzSMrSfreV5OXuJ3l5HnZyco9wp/JQmR8QuF gckx0CSkdhgYEsryXEtCG57jSBgBKc5j4KGGy0nYHHPwIBzP8YKEF3jlgZwriQGrKnkAXTPH cwxJwcu9JSkNDxxJJSEdukktoJjPSRoF5DwjaYeBIOkyvMolBqxYDuQ8ExgAOc+xPDekMthu cktKMCG5IyWHOZ6UErwqJ6UF85Nh4HkgSJlhIElZUGshRjnoY0GN8sMAyDn+Y1ZVjr2wmSOd 5bwdnrTIeU5OWoJZC/u1An9WCNJMnRWStAEbFrZp1tcKTXqQBUK1U5AuLGnPiuGfzocBkPOc 58C2zGAvJcgSBjgSJklWg5lVymIAarTkASjWLELCfjPMYU/QwJHDvjIO7xkLZdJzeJRVGZvE AzYA/mRZXWkAqLBSacn/kdUG78GsNZJ/wevxPbAc84Otss4zDhjxBj9rPORwLasFuUzjPbCc gLmsk5OsM3zWYcMYHgNeri05zULhi84YIGOlYyaszjGAI1m4jnNwYQud3LBNoMb5nLUDcm75 F00+YxxAeME6wyQv4CAWynkJp7ZgxCtWDFr6gUMw4jUc9rffXn8uv/egL0P0fXl9VbRl3eP9 +NSW34aQ5Iebqt+VL97vmq4r2qdffv8day+aA2bnr99VbdcPUcszPxXDgx4eJnhxHt4E8Dld 1tum7co9z2vuaNtsDjzu6K5t9tT0D2VLXV/U26LddtS090Vd/afoq6buRp0GgTaPBMY25L9m 9L6sy7bYUVXfNe1+WE+vQuGhgWoy0Hr7w0CLiFoQMRjFOSmUZ+hL+dg228NmEAS7etbyeZOg H5U/lOpCreyRdhvS7kLa5XnaQw09fSjafVNXXbml61mVkE9vYmPDTfO/iiOf26otN8FuJAsm dmS02tLNQ0mXn6nnH9hkUAKS7qpNBchdUd8fivsyMt4djc8D410WGm/OGu9EoICjG56/aeq+ qOqqvqfrt59eEvbrvi32+H1bvqSPF9cEWujm5uJzxEviZyGrDrwAalj3x/UFuCkYMbJDzq7l XOBazi+hjuS5PBJh6OqCdb+r7g/t4DQhvNAzT06GPKmQJ3+eJx3IsnS5rfqmHffkqTn0g2Vj /PTgLeTFxf4SEW7By+XN9Uc4/dOuXKZj2ryRjlmnGGykY/L3GTmnz4f9bdke1Zlwj/7iTMiD DXhw53OUC4UYutyN0ciBXNSjLdtyV31DCNzuyqUg5dQbGBT4Kaf7yLqQcwOq3vHOlkk8TbNG DnQWLfF0XdyV/RMnlT7MG5Od+rydoftqummLbUl1sY83SR25DGPPh7Hn3FkZPnQFhcT45wE5 Y+ST/akvgbYv+4cmzkAqoSlUVYGmECjhKgwflUfrFII/lTdaqY9m+jB0fBg67nzo+HAbJZJq i+SPfVz1mdFSGW1QTJjE2fWmbZESj0dkOXsjEudZ5ARs1DH3ETIqlg9VhwiPTnchjzyEoePD 0PHnQ8eHoSPW7OaiNrI7ZFBgh9/sdifrqX96TGPD61C+j1By+lTeI4HtYQSO3Wc34wh2alqU ef71UCAdYnv56Brw3rbFHWdF+nJAkvvbYgD5MIDyMID8IhfTtonIJIT74XZbfau6ubaACt3h 9t84iIlTc9lGLMdlS8KPD2qjlhWnpp4Bf0ZGAjsp7BIZkjBvinegvHrkp4h1v2K+jNAcXaFC qOPzxyT1XwygIgCLDNvXZdfxUUbV/nGMp7EmLKAkMiCPi91Lasv7YUQ8s4bV86tjARcpIVeU iL0bhwrS17diV9abIUeclD8E5+ySMnc2ZVmCiSRousBixDckPEUYegXDRhiKPjT75h7+UfUx hjmP4WM9JP1jcBsEW4SQLbnlhJAn/iOed3n6q+ofOCNSh2qgHM7qUzdTS5l2Mj2Pk6OhiwdO u/Qw5sjX02OLc4ePkK8vphdff4ns8mdFcIceidD09+p2V3Hd+fjwtNiBZCIoIzIZZIw8XxGk YkGK3tR1+b2MD9j4MEuVU2e7pggrWT4duj7FkvRxxvhWIg8ECKPF5mixDi02QeGUZSsW21ii pItdcegSi+MOIWVJnrU4wkqWTxabFGvIecWwtcs7GzYAmQ/tVCt2Jl4q6G15hy5maMFeUve0 v212Y6Itbm+xpDrtlVV8xKXUibM0/D+iEvSJJZ2KQqW0jjMVJWKmTWQBbUKEtNnztAkZC8ZD eVe2nHwjaqSNqUnYzs5Sk8IlCKMW0qRw6sdC6htS76+u/htWJpFy2UrEi9iXc7reNI9RlSnk yup4XzyCtT9eX0QgK64pYuscXX4vN4ch3rvDfn+8RJqQ9ApS7JGW/mi2YByc3HboF9p9VTe7 5v5psZMUYVyJMK6EWREZ77Shd01b/tVE5/uMNu9toqY5KaW4vuCT6i7CSpZP8l2CJbgbq7vH phsCjvq0axAr7i7jXK55P8vdDqflAcpdtXCNFv3il+r+AVXZ1xcfr7508zGW0CnDA0jKkM4V d5SxO6LrGop3nMl87ZJ0qDPsTEyiPTd7J8sHbjdLaVmGB5EUCZQcoboTrLux6+Y09Jq37ST6 5MrpI+P4QVIrAb5FAXIfd3or9YdPUhTKNzj8CYQQSxlqUsOm+SU+dtskScVXa3ybHmx1GDnS nBcqslSooM9nRU4nkIo3/ETv8Ax6tQKXIEw05KdwdmzSfioO6LHZVZunwS3qZyyRfsmS6bQ7 ZWa4GQYO31dxwu8ey02Fwp8GUfWr4/MZafmKNHEqTYO6APQ5Y1S2Ai9P4RVd/zS0WIFWp9By vKfpDlXPQfmtqHbFbbWL25BZqWUvcKeogq4OKLg3EeDcTzxnQuaXyqapLHNpYRMVZouZVYUf F5QLK5nFOnWSpNNCU0zlKdXxTehEUXwzd1qncqilAFR13SGNMRVe6St7iiPozaFvmMPNlJqX VcrkUuMxmSfSziHMJsVJFzNfQy7d/RkX3/1J+icqCAQ+Z8Qfp3P5/RGJf+4sH9tmbDPjO1S7 dGc73caK6DbWIXHvHw/ckh5bea5tx+8+/HUh5EJnK8AyArZ09dD0Y7O47FE6+B7HnyCDO2ex IsZEYgz47seDENQUfD0ShYGOu4dESTPsV7p+uDuB4n25nT/38Aex2L90+EFNqwRWoiJr+nqA RuKMISbN5IqRNsLT9AnN++ItN3+gDVgMj0FtVgTkkQBFfxTQcQiGyeMOuyLaehPnk0TDoerh u87hyvfPw1JvpcMUZHyyXi1/GvHHLxRhJ2XCTkqf9/b5e8osZq6nIsPilJMwI4/l3KE71jbJ 3MkimSz0QZs1OMGpaLEkeoJTCZybPHUZSa4g6QTJThY9lMUWdMdAagUoIRPB92n80sZn0njf ze8iPL2CZxM8PSm2mIeNWUFyCZLi68S+qkdHPOoXm2pXALMEcPKc6XtiFMeLgTGFmUu8XAaM JWEyotm40Uz8Vxw/uC244zx5+vIokpU2cce744e7/wkwAFx5iPYNCmVuZHN0cmVhbQ1lbmRv YmoNMzMgMCBvYmoNPDwvRXh0ZW5kcyAyNyAwIFIvRmlsdGVyL0ZsYXRlRGVjb2RlL0ZpcnN0 IDg4NS9MZW5ndGggMjgxMy9OIDEwMC9UeXBlL09ialN0bT4+c3RyZWFtDQpo3pRZ23LbRhL9 lX6Mqxwbc8MAValseWXnUuV4tZar9sUvEAlJ2ICAAoC2tZ+xX7ynByA1PSSR7Is4IjCnu09f pnuY54oyynNN3uHDkHI5Pi1po/DpyGQGnzmZosSnJ5vzZ0HO8HtYF55yn5HP+VNRYbHPayqt xSfwMsMPLCml8DakKJ3xNzkWnr/xpIznlwtSlqXjW+U0vikyUoyZF4qULwosNKnCYXsB5CCi gKqZxa7CkVaKH+WkgwhopjUjY6c2rBds0FbjUZmRdgqPSkU6z3ihsWB9SkPag4+8BHKhsasE clHwAjRkmt/xZFQGoWVBRrPOZUnGgC6fZWRYhM8UGZeVWGgyueVHhowP31jQiT8+A7+l5kdA LmGuh942A70+K8iqgl8uCXh4R2VkIQMLRdYC3itN1oFVrwwW4R0LBxl+5Mh6Z7DIyRaWF0Au Sn4HzsvC9hIL0Ot1Rk45SIe1DkxhoeFgB2RtyNmwsOTYKR7qOseK6Zwcv+hhrSs0bwdyAbI9 OHIlaPEGsZXxOxxNymCXAbPa4B2DuDIZL8C+DQtEIHTFAoQ61odDJw+LgoOKATliEAXeZuw8 2AW/gmK8YzWTxY/YWvjKW1aXaWH2DbNh+VvF38BDQZaFYNiDBZTLWTGW58MCyAUY9Q6gBWIj EFoiqL2zVGSshnNUKASkh7WFZlT8UxgWAdDChHdKZAVSyucZIXhL+uGH1x/qbxNsy5B8H19f V0PdTcQeDP8O9ZeQkvzPp2Zq6+/cK/XK0Yd+qkeaerpr7vdDPb748cdnKLUCZRIoS++rp34/ UX+3YNHEDwWgXgG0CaChn2aYbr+7rYemuxdQ5jIUyJFQ+gB11w+7ahI4ucSJzcpfla8UXVf3 kQ4v6ZH/f6irbT2MVHVbgILDYWEuAVpscwmqppv6j33dbSLkgHXb97/vquF3ae0R7QCuYvBC gBescNNVU9N3M8RVv8cm8/qnZhinUGD5/fcV/+PnaFm48JelLP8cpHj6WN/VeG/Dmk8PNb37 dPMrbeu2+VIP1W1bUwV26OtDj2XTUTON1H/taIKkmH8v+E+N8eA/FTRiAcxIlGD+ALGonSd4 RuDVbb3DppGDNtXsgHOWDS1gc4A+InnwYuCd4Wa/zhGCNVy8qVr6UrV7mWRerYiR0ejon/uq Q1Y19fiS9h04fUnj0+62b2c5Y3PfSXC9Am4FuKW3DbgYof4MNsFzQ4UQlYgrkehlmBsg3gWu J7i/3o206QE3dMGTaRzYi7guYVvTVfXYTGCzrafnzFtwsnPxtGRKmQSDFsFQ0W7fTs33j9Uw nYbXAp8ERRYh+leoNXTVd6H8HQMBRXGg6yuquy/N0Hccb0mpyGIOfYKIUrF/fOyHqUaladpD DRtFeZA1XxhdSBUtfarH6VBueM0aT0Pf8lEwK/35O5ZRD+0TfRrqen6zut231YCXd7dNB12i tz99uvrw+cXnF4KockUlJVQy9OvucU7EGZEpZCO5PN7gu/AIcn69uvn8gh6HPjyliZ0jnF9c 5sEJ57Prr4f+fqh2CMpt7GKXVME8PlmKOCELJOSbrqu/sZcr+qUadn3XjOAGSnfbatgK3fQK rBWwFuSyjxGANCwBikMaVfTPpZgVKU5IMfTutysaD/xKIu1FGJfnAgZnaz/UX/th+5doKBMa YsvLkEA/1x3yrg1Rt+kfn4bm/iHJmGXXbFapEwjEU7dp91zJ6GszPdDmoerupY8T+3RMUynw 7OJjsF93234Y52jc9pv9cyovrBWXUctMoIL8CCxoueu3zR0OCU4B6YxyBVYJWH0Cyx3ZReQy u4jsRIPHfVCM3PVTsxGFsfDn/Lowmice0omHWMkTJx2CbqnkcT9VxlHzZoOq+rSThpnLe+Ms +Lntx7EanuJGqTw0SmUeNUqljxql0l6GjxuYUpCG9DhEzUh3Q7+jHv3MwCkY0gRdyHBfdc1/ ThyFKUAIFDaUr7JjzjRz4QxV9PtY+LlOsFBRJ8jD1hkRwSieWIUDQ7vTb/ebwxnHp/lfMClJ ojHWKj/SHmnFo29E+8WI4Mk4KkrnipDgUxXS2EKUtOcatG2GehN5I9kws6NkXc3pE7fDH+bx h03mrrW/QwY23LMgzPcYIYTxfjGeB/vIeBMbX1w2Pk4Hj0Md76PVmqomtFo3b9+/5FPzeNq9 JJyk86mOk1vwIuJMssq9OKDCvt9ursBNxYjCDn0MrSwKLaXOoS7kadnvcKe0iVuoGF7ZI08u 5il/5umIfo6nuLfK6d22mfph9kmYXOdhjvNnkvMX5nJpgWyd1Tz8jNNTW5+lwy/Om9Uty3Ng Mx1ZJidF+iCH3wX3OV5i4KyMebhYo7yKhTh6Fw1BVXcyyJ1LUl/GcVpGceplnyM55+P9p/ie IXlrVs/Lq4WCbqq7eno636oct56zMw5fNL4DZnbqqp100qEcehXbpGKbVHZZRhwKPFz+sUfN mPkMUxR32LsaZ5yoQF5OZlJVE6beZyDJlVIxV1rsM3NHL+TNVtpnM+PUUXHqqMupo2I3YiSZ BhR/vlFZi5kZ1XlpaUyYxtn1Zhj45D8ckceRnNvdS8gJ2KyjUQIZpv3SjMhwcbqrY06qOHVU nDrqcuroOHXUqt1aprlgUMHDb9r29NJkenpMc0PFuSFOYoX68L6+RwHbwQgcu3/uDHUxW0Qn /q+HCuWQr/AONztvh+oujI0f9yhyfzubQDpOIC0S6CwXi0lWmIR0399umy/NeOgt+M5nf/tv HMTEpbkeYoOMSM2UnyLqjQZWnPruAPhXZCSwS5xliQzMktWw5DtQwgWCSHatVsx3As3TNTqE Tp4/XvZ/CUAuAHJU2Kmrx5GPMmrkZB3u5Oa7wap9ieHyPqyI3+xg9eHRsYETSrgVJWR041BB +fpSteGKEwSftD+E4ByTNvdgynkJhZBg+ZZgRH5DwpPA8CsYpcAw9Eu/6+8RH80kMYrLGErq oekfIWyQbALBnAvLRQudxI/685APY1K4ABjRDdThrD4JM5Wfq7RL0GpZHB1dhYGLHuYa+Xr5 d+B76ZFvW5YH4lrnUGPPizBShKW/N7dtw33n48PT2YphbFQxjIsqhtErgnIpyMwjei0PWKlp qpy5ODUJrGT7cuiqFIsH2rvjnU0VI8wWu6PFPra4iC02KxaXUqKmq7baj9JieWF9wpK+aLHA SrbP8sW1fMAKNa8Krj3rWRsNAPx7WmTnSpTaJEoVva3vMMWEEUzedVe3t9jSnMzKXt7fnVCn LtLw/4hK0BeWfCoKndI6ztKUqCNtJqbNxrSVK7Q5KTg73mvLCHESI2U7u0hNCpcgzFq4IoV7 /rGl5p8Yzc/X1/+NOxOhnF3JeCtjuaSbTf8oCq51K7ulXwok63S8vhAga6EprfP07lu92Yd8 H/e73fESaUHyK0gyInP6rd/yT0P1cDtiXhh2Tde3/f3T2UnSxXnl4ryyxWWRTnraHe9sRXTI ipmo6U5aKe4v+KS6E1jJ9kV+lmApnsa68bEfQ8LNd/mCwJVwd7KWW/Zn3bY4LfdQ7npAaAyY Fz/yxfHIvxtcfxwPx1hKZ3wAufgAcivh6GQ4Gv51pA19Dl+7pBOqk6GZaM/D3sn2wO3mXFl2 8UHkbAKlZ6jxBGv5dZ/L0Gt220n2uZXTx8n84R+vAb4Nv4QLjJX0UUmJQvuGgD+BsPZchVrU KNP6Io/dISlSydVaHmdOHmeOKy4LtSYVqs7+OiNOIMnDqd7xGfT9Jbj/CTAAEB/AEg0KZW5k c3RyZWFtDWVuZG9iag0zNCAwIG9iag08PC9FeHRlbmRzIDI3IDAgUi9GaWx0ZXIvRmxhdGVE ZWNvZGUvRmlyc3QgNTcyL0xlbmd0aCAxODU3L04gNjUvVHlwZS9PYmpTdG0+PnN0cmVhbQ0K aN6MmFtv47YSgP/KPO4CbVa8iSRQFCjSbs8C2yAnCc5TXhSbToTKkktJ2c2/PzOU7JCUrS2Q QJQlfnMfktIlgwJ0yYFxgVcBXNBVguAGrwoks3gtQRUKrxpKJvFqoDR0j89sCVoXYPA3rRlY ifM18gqOYC2AMc5xIFECYzhQONA4T5fAhKGBBiY1UQwwFaZbYCXJMwUwzRBsGA4McvCfGaFx gGQr6B0kW0uPFPBC0cslcCboFw2cB47BASmM8rhQpHUBXErU0DLgihRDBFekj0UnlBJFWAlc k7kWydpMtnKjaRaSrUSgNSAKRi9bEKwQYIoCB4YGDJ2o0DMFByHxzuBjIQ0N0L9KKRwoECXq bIoShFb0SIMwgqYj2XL6BckWlTKsAFmgKQbVlYx8zjhILugXAVKggQbVlQoFGoahUxgPw0qQ QQRqiW6mWQakEfTIggwiMFTSEhlvMNDIwZgpJumRAIW+w4EEhYbhQOEA9fnll0+3lXftABo9 WsDdp1vvXkMy0c1DPTTuA79ixRW7KuGPh/sv8KUdXNO4zTBWDdz67uD88AZ39fPL0MPjhy+3 d/3jRzh0Tb15g13noe38vhrqVwfe7RwK27j+46+/ougb9x0Fh/S9u6CHWOqh4I44vm6fYeig P7hNvas3EES1P5/uL0jjK9LkUpqEmxj6Q2PECl4t8QLu/zVarqDLJZrDg+sH6Md6cD1Ur1Xd VE91Uw9vCVWtUIsllcHt+ISxTYDQ7WB4cT80QaahFrEwmQkjUb+7Xd3WQ921M+a6G3Ei//S5 9v0QehfN+VrRjZ4AkyQsqERSGUnC1pNIwj+4bqqxRwPG/ZOjzIq1nsFHVmkW06+KBQDqvh+P 1mdTZ+/aJYfBb+PQkQ83sFlRSaRREyI2L8tigdSbU2CqtnXf06iwNGcZi2AsbgQCc+p/zj9h 4WNh7/tQ3hR39/3gXd9jnCgTDr57rfv3oE1SCptIKXQkRccqqysN193+MA7OQ1O1z2P1THpv oUNZHjbd1iXhEStglYBLuH3phu7ZV4eX8xmlyzijdJRRWq6IMYkYhf4ONYc6u+/V/tCkDp+5 R1SmpArxyudDjX0XFR/cFofB6wPC0vyaSbNSZYbl8LnrhjagsXGmiFkztWKkTXgSvtb9kHhR HL1oisiLhsVeNJcFGJ4IEPBXhTqGYpgzbmyqJPQ27SeZhpT4D28HtBaT0v0zVlEjyaZMCsy4 9/kCbtLqm+w0JztFbKeM7VzJ9iLNFuzT1VOWITZtOZlnqGGFOTD2WBupRfO7s0tVNtFMi2fo zCEJFqKNPCd6xpUZTs+Zep6kVkg6I5WzRS+u2qK7U1C5AsqcicX3tXrrxiGsSQE50LOEp1d4 NuPJWbGzfdiYyyRbZCSBba0d6nZKxJN+qal2RTWRAefMCaVRJXVszhbGjCmyLOeRx7IymbMx 9VeWv7Rqfa6fR382HYt4ybMym1lm6bgLnFS4OCd85qmMp97z8RxKrqDKDCUjr0ysZSJZtQLU GVAcvXQ2k2y5guIZih9Ry8jbrPHEZpVXlvZvtJyedPgJDnRPZef8tOTscJXAcRbHeAdlTUbl cI+ZQ2GMdkDEeuq6v/eV/zuztsisle9wOnPFcEMK123IynOLDR3NTk2YjmenJkzHuMtSZCJF nxIxHCtwaQyHna1rcNPkQ5VV6B349tLhEBfgGk873bc2X0FNus3JjdHo/1xQjwNkRqISzx8R s9o244mE5xq3x0lhxVtoxla8oRIslSXt6PDFU6+a4jplCI4xxLQqv1bNmBTZ0bHnxaTZqOC/ Y4Udcahd/xOMuNPHS/+2f+qaSU5fP7cpXK3AdQKX8HuNvgj70AAbMHK+yo4kZjUT0zQXSNwF Xw8Yfof7302HON+GSObe1he5OvM2h+vqUA/ozcYN75U3c8S5fJr141ky8CQZKsAN01D/fKj8 sEyvCc+ypIiXGB22orhmhfZ3SgRsih5ur8G1r7XvWsq3rFVEpxH64JESsVWMh0PnaSO7q0+r V3pWyHp+bDRLVZThlHtsN+HES6us7xpaCialHz+QDOebN3jwbjpL4MqJu0lPJ42nukVdorcf Hq5vHj8+fkwcxVdUkolKAr7Qln1/qh5yIRlJ7fEefwuP6FvJ9T19KvFdeLrcDRh22Q86CT6F /tbTwWa/OB+lXbC0JtY8LkiDBfkbHQ8pyhX8p/L7rq179A0q3W4rv010UytYnWBldP58/zBA XfTHUsoVKSaRIuCPv66hP/o3daS+iCmtTTB0SvLuW+e3/8oNPHNDbLkNBfSna7HumpB1m+7w 5ulTWVIxx1mTWVxlCMyndtOM4Xj9rR5eYPOCp+I4xqXN7FMxjyc8OccYve/abef7KRu33WZ8 L+XZNrZCFQkVnR/Bgpb7bkvftRbbyaNC57EywfIFlnZkl8niIrlMNni0D4rJeCiuN0lj5MW5 uM6JZ7MI8SxCpOQpSP8XYAB/x87wDQplbmRzdHJlYW0NZW5kb2JqDTM1IDAgb2JqDTw8L0Zp bHRlci9GbGF0ZURlY29kZS9GaXJzdCAyMS9MZW5ndGggNjM3L04gMy9UeXBlL09ialN0bT4+ c3RyZWFtDQpo3nyUzW7bMAzHX8VPMDZpkLpAUSBbPSzA0ABrc2iHHWiJtoXKVqqPbNnTjxYT 16ddLJP8/0iKkl0u18VVUS5vipsVL2WxuF4Vd3fwGQN9dUOEb2SPFI1CqAbltBnaLLsqfsAj 9pTj8JTqeDoQPPNjkZ8wwvf380yveGgemK8xBmFf8aH+L/tgmoY8DYrCz+UKak9HAoXeDaCM V6lvLP0B7SIqRVyiS0OLPvUWUwTXuoHewHNJiMZqKq5v4T25SIFdlorbNbQej1QsliXUyVqK oLFtyZ8XXVsga80hmADUawwd0JCXxjpODI1HFQ230yZjc1pLTfywvGm7CL0ZUoAD+di5FHDQ 0ganr3k4k5HRiyFktj78M2dOn/HoUVOP/g0aw33B92DHDncVPMmoXrThIY57eBUHD8xSCAas SB1BkMjfvBSL9RVUyTt+WYFKfjyCExtrPgL3RkONnq0SpsTKHU7SnPO6Id6wGXiuN0uwruXL YwcX4RM/NDXgqTWBN0MaelS5IWo9ERxsCjKr+NuFxAMzzkPsODZZqFIk6FOxKK8h+/R49Dmb Im2sReBzn/TcT49BJZsbKssx+J7QMzG+dmgbqXB2hmJxu4RNvhiwkWqb2WXb5KsEm2nrm3zB NhV8uZSvBK4ErmZwNVFb0WxFs51ptpOmih08SrmdyHci383ku7NgovpkoznYE+zkcPeC7gXd z9D9xLxI8Llznq8y+Z7vaG0DoLAoYZyxKGVxSoF5DMif52UMJDAJTDOYJsqIxojGzDRm0hCP YZByTuRO5G4md2fBRGlzNKNDhpAETAKmGZgm4iTBmIdwurh/yS/p8vO7v/8nwABNou6fDQpl bmRzdHJlYW0NZW5kb2JqDTM2IDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9GaXJzdCA4 OTIvTGVuZ3RoIDI3NzEvTiAxMDAvVHlwZS9PYmpTdG0+PnN0cmVhbQ0KaN6UmE1vJMcNhv9K H5NDMMP6IgkYBmzHDgI7m8Wuc1rsQbaVtZC1JMgS4P33YfXUM3FSUwPkMl1qUe9U86mXZMuS b8fN8nET6VfZJFlc05arxjVv9ZjiWjYViWvdPPf7LeKkL3STEr+1bJu05rHwTVzbZuW4pZRC tMiWpUVwCVW3kC8hm6zGomwt/iwWdWup76C0WNQQLBoLD8FiW8ul3/FYWNypx63tX1olFtrv pK3V1O/kWPRthERr0u+EcmuhXENZj/Fd8WBN4y+shrJ67KeGct+LRVwzj+AWyh5PaS2U3SK4 5U2PPTctcnHUHlwjKf0B4wF0f4p4SE3Sgy0WtQf7pvkYwXqMRWzcVGLhEaxp0xIpMQ3l0tMS olr7c2koV+vBodxSDw7lpj04lFV6cChr7MUiTq2nzkK5P6XFdtU7Ngtlj/yZhbJ7D46kH0sP jrhj/7AAI7kHR5xoD470pZ7MnogUGzfv6CWCvZ+FSIl57oAjuIuWzstrB9ODe4pLD9ae2R7c E5F7sPfUlM17XOQlFtKfrW2n7aYUi9w3Z7HootKDaxftwT1u/9B+twf3ON8/toiN4EiEi/cP 2TwFQQ8eniIlLjkObxDcRbP24DjOJfXgiCutB4dy7X8RKfZae3Aot9iL97gWBD2Fcoun9L5d LV0+lDXy55E172bxFMqdjAc83z9SKLvue9nkeAz9zz47fPvOI3fH7c2WjtnHIvDE4v3h9c3T 7f3z90+3t7tB497vbr26/e3529tPWzmWw5uHj7d/u3nc7dujvv/0eHt4+/z08uMe+ubh4fnz z/u33f3067vu7S6/3/ni/v7h+eb57uH+8Pbx5v7wxdPz3T9vfnw+vD58effDx7uHD083jz9/ 6j98ff/89Onw1c83T8+Hb+4+vDzdHv58dxO//+X849PD41c3j/z49f1PIX57eNU/vok9/Oen v95/vLu/ffvzTexzRP/95bnfO20j9n73r9uHl+fx48sPv/74dPd4/vHx9un3N76PXHz58Fvf /eEf9z/dPp2V9of87u6Xu+df33Ur+vvDq5df9nWvbT3f/XznEwM9Vbh9uR/00zLvZW5fngrd vqx7qduXp2K3L3Uvd/vS9oK3L30veaesB/GTrlcdVxvXk1w/6qerjGsa1zyuZVzruA69NvTa 0GtDT4eeDj0dejr0dOjp0NOhp0NPh54OPRt6tuu9f9fL4+nGELQhaEPQhqANQRuCNgR9CPrY oA89H3o+9Hzo+dDzoedDz0964a4jC2GRWGQWhUVl0VgoCzs9YayQFqQFaUFakBakBWlBWpAW Y4FyQjmhnFBOKCeUE8oJ5YRyQjmhnFHOKGeUM8oZ5YxyRjmjnFE+Hfyel4J0QbogXZAuSBek C9IF6YJ0YdMV5YpyRbmiXFGuKFeUK8oV5YpyQ7mh3FA+Waw/WEO6Id2Qbkg3pBvSirQirUgr m1aUFWVFWVFWlBVlQ9lQNpQNZUPZUDaUDWVD2c4MHWlH2pF2pB1pR9qRdqQdaXwo+FDwoeBD wYeCDwUfCj4UfChHY4EyNhRsKNhQsKFgQ8GGgg0FGwo2FGwo2FCwoWBDSZwOwYeCDwUfCj4U fCj4UPCh4EPBh4IPBR8KPhR8KPhQ8KFklLGhYEPBhoINBRsKNhRsKNhQsKFgQznZsD/z8GGi DCQKQ6J4JMpJosAkqlGiPiUqVqK8JQpeoigmymSicCaqbKLuJipxom4nKnmitqdzIzi3BnqF 0FSELiO0HaEPCY1J6GhCixN6njh+pC0K/VRosELHFVqw0JOFZi50d6H9C/OAMDDEorLgryiF DjmHpUPX4e2cAOcAOUfKOWTOsfN8DuYrOOLOoXds4DQox0+OwxwXupxjyAbedRzv1ACnKjh1 wgBn1BuDoPk5JrEYykYlNCqhgdLsHDMSbhRbo/waBdkAZ4AzuoDRFwyCRjsxGozRjQyUBkqr 5xiU8Z4BzgBnmJmBVBhHhWH0/uXjx/1jtyzh5yxSfxVDKHlV8qqkU/0cPPaotBElnYohFEMo eVWSp/Q3peOpnmPGQystVOm3ijOUvCqGUHq6klclr0pelSwqzlCcoThDSbBSSJV0aj7/im1Q vZXqrRR2xRmKMxRnKM5QnKE4Q+lGSn9SuprS5xRnKM7QM0F6aoNgg2CjNzcINj8Hj69oY/iW hiEaKBsoGwQbhmigbNS2Rm1rEGyMRQ2UDZQNQzSKXINpA1yjtjVObwNlA2UDZSvnGLZBB2xY pFHbWj7/iuBR2/7bNLRHzlQlr5VMVz//qrIoLBKLzGJ8bSXlFQgVr1RKT6UYVVJegVDJfcVG lU5TqUGVlNd2/hXboCpVIFQgVCBUjFUxVj0ngbRUMl3JdGX6qGS64p6KeyruqZimMh9VvFLx SmXiqpimYpqKaSqmqTSYSoOpcv5zdoixKsaqjJSVIbNAsACugLIwNBfqX6H+FTvHCIvxXQVe BV4FXoWyVzBNwTSFvlJgWmBaYFpgWmBaYFpgWmBaqHaFaldoJwVwhfpXqH8FcIX2XzBNAVxh 1C3Uv5LOMeyHcbowYBeYFpgWmBaYFpgWmBaYFphmzJixZ8aVGXDZz8FjGxlwmckgU/8y4DJm zHgwAy5T9jJlL9PKMkwzTDNMM0wzTDNMM0wzTDNzQKbsZcpeBlym7GXMmAGXKXsZM+Z8jmGr 5xcR/C6cFuH8SBv/3WH4YBqxcZ5s1GAbu2NsYY5hsLHx2m6jnNuo70xAjETMSDb2ZGNLNnbE MMV0xbhlI4M2Uso8xoBmg4INLExwjHQ2SNpAa4O1DdfasDGzIMMh0yLjI/OkjYpgo50ycDKK MonaqCU2iouN7mDjqDLDMtQy5TL22mg9Nk49czGDso0Jz8c7kI95wccAwWTNqM3szTDuozD6 qJQ+SqePWsr0zjjPfM/A78PMPtzNGwGvCD4Kgo8K4aNk+KghvFPwksFbB68hPqqPj3Lko7H4 ONw+TruP4897DC82vOnw6sO7EC9HPmqijyLpo935sJwPD/JWxWsW7128iPFm5sMfPvzhwx8+ /DFe5d73/9Nvx8N3N/cf/vD1qz/95cs/Hl5v44Xv8PrDdkrX4e3h9el/+pv8H7Hpf2IlnU7J xeA8B9dlcJmD2zK4zsG6DG5zsC2DdQ5Oy2Cbg/My2OfgK0yOU7StNy0yR6+xyAWIx3X0BYqy jp4x2pq5zBxtDV1mkLamLjNJu7LvGaWtucvM0tbg0wWWVxw2s9T1U6aZpa7PSZpZ6vqcpAss 1+ckzSz1Sk5mlnolJzNLXZ+qNLPU9alKM8t2paTNLHWdk3yB5foM5gss12cwzyzbOid5ZtnW Ockzy7Y+g3lm2dZnMM8s25WczCzblZxcYLk+g2Vm2dZnsMws6zonZWZZ1zkpM8u6PoPlAsv1 GSwzy7rOd5lZ1nW+y8yyXsn3zPLKpFFmlnV9vuvMsl4ZH2aWZc2yzizLmmWdWZY1yzqzrGuW dWZZ1vmuM8uyznedWZYr+Z5Zliv5nlmW9RlsM8uyPoNtZpnXdNrMMq/ptAss13TazDKvM9hm lnmdwTazzFcm3pllvpLBmWVen6o2s8zrU6Uzy7TOt15guc63XmC5PlU6s0zrfOvMMq3zrTPL dOUVY2aZ1vnWmWW6ku+ZZVqfQZ1ZpnW+7QLLdb5tZpmuvEnNLGWdb5tZyjrfNrOUi2fw3wIM AAou9WgNCmVuZHN0cmVhbQ1lbmRvYmoNMzcgMCBvYmoNPDwvRXh0ZW5kcyAzNiAwIFIvRmls dGVyL0ZsYXRlRGVjb2RlL0ZpcnN0IDkwMy9MZW5ndGggMTM2OS9OIDEwMC9UeXBlL09ialN0 bT4+c3RyZWFtDQpo3pSVS69cNRCE/4qXsEDX5fajW4rugocA8VCUwAqxQCjKDrFgw7+nfMaV RDmZ4Xhx5b4z5a97ul12lEg5heVUOxekKFxKgjlXS/DKtaZiU9VSGVPWk5WpG8n61HmqmLog hbqaU8vUVaTWqKsltaCuWuqVOv71mLqWBhnB1GPmqSP5LKF68jH1wXJaikbtIKchIYMfEorc maGxQsAYVAZtftWSZRYcjUVmnxpWCZsaZ+BkUcf6+RWLtTLJHclsknth0JmzW7IKFtMrA24N fmotk8zE1mZNneQW/AFsgh2/rJPcg7sGyWP2cJA8ZhlMYz7LGCT7LGOQHIXbB8nzv2Bzay5z +2AwWztmazG3s7dgUcGdtYDbHQxmYV5Stcya3RjU+UllMMvwlmqd3WAFtZIaTnIrczvJ7QAe U2OKmIdg9pw7a58HgX91cOoRJI8xvyLZC3cFyc4GRJAcs1FsRJ3tD466Rkxx8Bxw6Mh5ngim ZsQzAZuDzDwV4C9mZKkV1sSoMmLHGbXULMeMOqN2UAajOCieWq0HhTkqfyYPRp6nbe7APHdj nhEwR8fxLXN0dosRc4x8HCXmGHVmY4fbOOoDc7jNWsAcPux25FpgVsoi2zw1mFPqs1xGhVGd ZPal55h5C0847NjRGPmxo6deyrFjMOrHDk/dWOSLF08/JG9PP/7x19vPvvn5i2+//PzpZUJh rTm9enr5NjHzjF4/vXx+vqn7Wd3uq8dZ3e+r/azGfXWc1eWuOvJZbffVOKk5+7vqclbHfbWd K8n31fXMvt/vOM8y3+93nGfJs35XfZ5lftDv8yzzg36fZ5nvn0Ha72M5Ih7IPzHN/ED+iXHi gdzOxfQH8nqWjwfydpb7A3k/y9sD+diT+57846nO9/KO+rd5h/OT4wW9rWOtvta4rT2vFWst a7W11rUuXl+8vnh98frijcUbizcWbyzeWLyxeGPxxuKNxRuL54vni+eL54vni+eL54vni+eL 54sXixeLF4sXixeLF4sXixeLF4t3c8jtVVwBFBQFpqAqaAq6gqHAFYgMkSEyRIbIEBkiQ2SI DJEhchG5iFxELiIXkYvIReQichG5iGwim8gmsolsIpvIJrKJbCKbyFXkKnIVuYpcRa4iV5Gr yFXkKnITuYncRG4iN5GbyE3kJnITuYncRe4id5G7yF3kLnIXuYvcRe4iD5GHyEPkIfIQeYg8 RB4iD5GHyC6yi+wiu8gusovsIrvILrKLHCKHyCFyiBwih8ghcogcIsuDkAchD0IehDwIeRDy IORByIOQByEPQh6EPAh5EPIg5EHIg5AHIQ9CHoQ8CHkQ8iDkQciDkAchD0IehDwIeRDyIORB yIOQByEPQh6EPAh5EPIg5EHIg5AHIQ9CHoQ8CHkQ8iDkQciDkAchD0IehDwIeRDyIORByIOQ ByEPQh6EPAh5EMuDvgr0d/Xpybsl+p0vq996yff09Zs//7k9qfz76avvv0756Zd//37D+NXz 87sH+dfXHz7I7x/t/OjJdiX5Dnrjr8nLkpdLctViW+q6V0rbgvct9dgrxbfgsaVG3pNjT743 UOxNFJsjxd5MsTdUjD353lSxN9ayN9ay69O9uZa9uZbNuZa9uT5oDT7u+nVpuS6169J6Xdqu S/t16bgu9evS2BjBzrg25oWNgWFjYtgYGTZmho2hYWNq2BgbLsztvSs3Bld2jFZ2itiYXNmY XNmYXNmY3IOe2ek5+3/thcvJrl9Odv1ysuuXk12/nOz65WTXLye7fjnZxuVkG5eTbVxOtnE5 2cblZBuXk21cTrZxOdnG5WQbl9MH2v8EGACAOxjnDQplbmRzdHJlYW0NZW5kb2JqDTM4IDAg b2JqDTw8L0V4dGVuZHMgMzYgMCBSL0ZpbHRlci9GbGF0ZURlY29kZS9GaXJzdCA5NzMvTGVu Z3RoIDc5Ny9OIDEwMC9UeXBlL09ialN0bT4+c3RyZWFtDQpo3pSWvaokNgyFX8VlUixj/diy YLlFIOxCQrgkT5Dqdnn/Mke6bJOBiU8xHg0++rE+W4xMzTGHTJvDvb5lnFPfOqQ+02xI7DJ8 qLZ0Dd2t3cNmi2PYavEZli1OhCsxFj8ldhlLowwdK3rLxhYrw8de5eVr7Mwy9givgB4jzirj jKOVy3OcEBhrjpSKvGTkqq0uYday7DMIrFJkpVsII9YO2JBoDxSkWuIKoLvqWyjApDJsuFm5 zY2f1pVthHcvj43FT3lUM5a1B8QrKsdGji29i2VXqLmRI2b7IlR0fdWJOBW5DnW65YHlROUN iFOq0gqaVcbEhs7ZuxuWt2/AyoqMY6lY5Y2EdcrjTJDTyoafqt38o0Ot23cMVvcPnNS7f2i5 etd3kMO7fziqru4fLoiu7h8K1939g0R39y+RI7p/iRzxCQA5InsXOU7fjESOc9oXObLvBiSa XV/iJs2+HWi7NSiwHVYLLIFV91VQrkn1D3dumNZtBXlY0R5rmKmUhbtqhQeNGeazPZDDV3sg h1d9MHGVvTxwBLSlPAQ5tpYHCrJdUASts5D2QI7Y7YEcZ7YHchxvD+Q42R7IkUVG8Iosi4yg NDS8PFRh1bUQtNMrESyH1SeHxHW2x4bl7RGw+uR4F244+devj99wDx6///3Px0+//vHl2y8/ P97xNhwv/M/H+8ewNv56vL+9fWqF0CqhNULrhHYR2k1og9AeQpv3WiO4vZCu/0jlXqr3UruX +r103Uv3vTTupedemgQCBhfBSwhgQhATApkQzOQC2nf9ISawCcFNCHBKgFPmoRHglAD3oty4 HwtxPxbifizE/ViI+7EQ92Mh7sdC3I+FuB8LQYyFIMZCEGMhiLEQxFgIYizE01MnqAmBTQhu QoBTApwyD40ApwQ4dQKGEq/tRR/yCfL/ay8GTt4PnLwfOHk/cJ7Ote/Dxr30EBXkfViZhFYY ugQzIaAJQU0WoSWwCcFNDqElwCkBTpmnRnBTgpsS3JTgpgQ3JbgpwU0JbkZwM4KbMTOS4Pai XJH7v5BPWiW0Rmj9TvuvAAMAsgOwsQ0KZW5kc3RyZWFtDWVuZG9iag0zOSAwIG9iag08PC9F eHRlbmRzIDM2IDAgUi9GaWx0ZXIvRmxhdGVEZWNvZGUvRmlyc3QgOTczL0xlbmd0aCAxMzA2 L04gMTAwL1R5cGUvT2JqU3RtPj5zdHJlYW0NCmjenFjBjh01EPwVH+GA3nS13balKBIIBFIQ WiXcIg5BQrkg/v9Iuz3FvuWxnphD3tZ2e6rsKs+zNyLo6UgieqScx09JrY2fSPFPVJNUGyAn IIaWBCsDWFKJSk1aotJSPqLSnW5UsvP2UcmSikYFqbSoaDJEJSerUSmpSlQsVYtKTe2ISkut RKWn1kfFf+t5VIqk3qLi8z00Sj5pDf3ii9LWB/JfretAvpzqc3bkH7XJQC3hyDGuOwoFnwHG vB2JozaeMLgLwxMxTSh5OGPuTKnRHdZo1MxRC1QTaszFXKNOZtdoY2ri60aXwVddo9dhuX/o oUO3qqOwr2b3OuZXS1IcIyOPRRErd3HVyK+2pPkIvu4oau625h5IPKhZc40ya65hs+YaNmuu UWfNNeqsuUabNddos+YaPWo+Se1R6+J7YNbgaNY0ZZm17GjWSsqI/Ls5ipX3mrIegXwnaWzA 7ltJ3XaB76ysPZBr+MMDYWy0QK6RWyDXKBLINUoO5BqlBnINOwK5hmkg17DQ8P2cLTTENWpo OFWuoeFB5Roa4hotNHzD5hYa4hotNKSOXR/INXpoiGv00MB4J0ID/lIcoeEf5QgNqKPQQE5F QsNtKhIaMEehgZoKQgPNkWu8eXN7l8rt509/ff7qh1+++fG7r29Pqfs2O9L729Nn9zLQh9vT 27cx1jbG1o2xbWNs3xgrx85g2RmMncG6MzjvDN5JT3bik538ZCdA2UkQOwliJ0HsJIidBLGT IHYSxE6CK+f0HPsTYvC3nuAxu+8+yjhAHY6aEVSCRtBP4F+AJxACEChBJiCzkFnILGQWMoPM IDPIDDKDzCAzyAwyg8wgs5JZyaxkVjIrmTWYf7tz8MPt10+///nHF/hcXmby0S8L5xzsOAiE AARKkAkKgRFUgkZAZiZiTMSYiDERYyLGRIyJGBMxJmJMxJiIMRFjIsZEjIkYEzEmYkzEmIjN RP6ft/Xf3ytfPvajX1/PpSjtV9qvtF9pv9J+pf1K+5X2K+1X2q+0X2m/0n6l/Ur7lfYr7Vfa r7Rfab/SfqX9SvuV9ivt12n/6x77lXvH5Sxbo7E1WncyHDfqWOK4UJ+gEBhBJWgEp53jKn0C IQABmSuZK5krmSuZK5krmRuZG5kbmRuZG5kbmRuZG5kbmRuZO5k7mTuZO5l7vggc80vIB8Tf J+eI9/QV/ZwRuhFUgkbuVx4FBypBXj/BNYJrBNeIucbFo5wnncN0bvGEcCDnyTzQLubJuMG4 wbgx4148Sg3uJnA3odr6UW5WcLOCmxVzsy4epQbfBfBdgF2kaNQw2sRXDXZhU6FGoU2FS7AL mwpVC1ULVQuNK1xUuTAucx6Z88icR7mYR6Zqpmqmar5S5RLyRTjKWSlnlS9mpZyDMk692Oy8 04B3GuhFeLwggRck6MUryLMdPNuBi73Fkwo8qYBy8QQnw2MPuHCXZyh4hkL6xROcDA9kyEXU PN3B0x3zdH/9CV4VwKsC5CJz3jvAeweOi8x5iQEvMTjWmQsvpOCNCIdcPMFziqeCLE+F+V83 r583fb6PfljJ+fMu3f7PAfY9//6fb/bs6mO3Lbt92c3PXTx2y7Jry648d+Wxi2VXV129W+/x 2O2r7vzKefXZ5/XOo/ll15bduuw+r3ee/i+7uuzmVRfP62318dlj2ZVVF3frtcduXXbbsnu3 3vLYzctuWXbv1vv4HkGWXay6crfex/dI2rLb/7v7twADAIUcEsMNCmVuZHN0cmVhbQ1lbmRv YmoNNDAgMCBvYmoNPDwvRXh0ZW5kcyAzNiAwIFIvRmlsdGVyL0ZsYXRlRGVjb2RlL0ZpcnN0 IDk2MS9MZW5ndGggMTAzMC9OIDEwMC9UeXBlL09ialN0bT4+c3RyZWFtDQpo3oRXS64jNwy8 im7wJP4kAoNZZZdNMMkuyP2vEYpyPTfSMXsxdkFlVZFitV7PIPLW2yDujfN7NMtvap7fHB8J pA1NoG2sBNZoJJiNJMFqNBN4qG0Qy5y6MhqnsFDjVBZuksoiTVJZtEkqizVNZZlNU1lW01QW j/o2iB2WyhoVp7JSs1RWbjOVVdpMZdU2U1mtrVTW2VYq62orldWj4w1CzFPZRvNUtjiMVLY4 jZ7SFsfRU9viPHqKm7UxUt1moJS3FSj1zfdJbjRfBx5oHL9AFB/pMcOD02OGB6fHDA9Ojxke kh4zPCQ9ZnhIik7fQ9po/1jTY4WHpscKD02PFR6WHis8LD1WeFh6rPCY6bHCY6bHCo+ZHsv3 /Pur3JUeHh4rPTw8Vnp4eHh6eHh4enh4eHp4hKenh0d6enp4xKenh/uOVqCdIhqcaDSiYRtR o/0RiCN5O6LcJdBKpC0SkCg89KyFh521HdE9PO7hscZGUUb0nCg8/KyFh581jizvwjmI+JdI A501a0xnbQY6a6ux0K50xHMge2R7oKy5RvEk6FmLR8HOWnjMiGSg8Fg9UXiss2b7kUkUHn7W wsNjKD9+fP3edsm9/fr6I7IWQ97wz6+/fvv588VqyVrJjjc77iyVLFdsTOKb7XfWK3b0cu+7 3+l31kp2luy7o7nurBTs8ndHc9739pIdJUsFu/xyGnZnrWRnya6KXZd+9b63l+woWSpZLlmp 2HU5K7mzVrKzZFfJXvrlO0slyyUrFTsvNdOdXSXrFbt6ufdS87izUrJaslaxdqm53/f2kh0l SxVr75rN76yV7CzZVbLvmu1+IxmVLJesVKxeqrrfSOoVa73ce/G93zmqJWslO0v2cpL3e0Op ZLli5eJ7vxlklaxXrPZy7+U0/nsz/D30XDrxwnjulw0EQAEMYAJkuf+kqn5P79e3quGHJzQb +Aucx2aDAYASznXxWVVQoqBEQYmCEgXOAmeBs8JZ4axwViif3H0ugSHPkGd/2AEzhhk/tElo itAUzXrHQIuEFmmUO8RfHuIGMAEWAFQ7VDt66eil4+A6RtJR/XkB+1zCcvh0gIeiEVFBROVE 9POOiaYmmpr+sGPghwRQj0uQOEHiBIkTJE6QOEHiBIkTRS+KkShGolDW9VAC5AXy8lA0w4xh xnXGhNAUoyl+GBehRUKLVI+LkThB4gSJEyROkDhB4gSJk45eOg6uYyQdyue/FEUJL3l2AXgo GpcirwXgDzsGfkgA9bh4vlrkaQD1uBiJYySOkThG4hiJYySOkThW9KKvg2PrAFA+7xWfS8Dl zLicWR6KZpgJzGQ87EBTjKb4YVyEFgktUjWurfj9V5/p9sYQ9Ph/+l8BBgAqgP2JDQplbmRz dHJlYW0NZW5kb2JqDTQxIDAgb2JqDTw8L0V4dGVuZHMgMzYgMCBSL0ZpbHRlci9GbGF0ZURl Y29kZS9GaXJzdCA5NjkvTGVuZ3RoIDk1Ni9OIDEwMC9UeXBlL09ialN0bT4+c3RyZWFtDQpo 3nxXy44kNAz8lRzhgCZ27MSWVntAIA4gtAJ+gNPe+P/jVmVWTEvu9mUm01VJ+VG2emRpjjlk rTmW8LeME/ytQ9R5WEOO8mBD5+LBh+IPHPbQfTkHly8nxvLkIYfNjYPNYYBxkGGbL5sOS3Js DbfLseHJl83HNkaDj/dhOHbGmXzZYpx1OYkAyfE5Qvmyy4jDeFxHTsbja+Tiy24j9+X4yKS6 4+OplHd8Pvd9CcBMyjF2UeoREKfgBiDB9zdrIhTYAPTGvgHoDf5W4ka/CQRlqW23Vkzdghob Gq6M5YDsh9eY6766LPUmZR0WXvgUkzuUXCSHUOMACON7BxpxO8TG5W3RwQPp5LFUmYwF4jqN sYTidHVjDZXbJySochsVaO97voH+6nUFklG9vohA8yfji6QNqJETp9suFFFNyEto2C0JiqN+ 3ZHQcGN8CQ2/PUt66DYNQcJNlweNfS2CH3pYZ5vQOEzVJjRispwwhgachhM0guW0CY0EBSdo JG1MI2qyfjahkQgDJzh10uCGZNakLQyFXZN9MxEYmnkYAl/CPEzWWMo8TAwnWsVgBkzOvbtx 8otiGJiCsBDwNtUEGpaMT6Hh9KYpNDx4A42Ht3hDobFZF1NoHNbFECS8cG9A41xLwffoJzPC NXQsx6dPb7+/j/Ecf719wRFsHv9+++eXz5+/w/n2x7//ff3h1z9/+u3nH99Z+X7hKyz2nf/l f3pUejT0U+mnoa/4iNVrrOv08G7hXWJZ3sTilW4N3Sp9dXT7iNVqrLZ6WFt4lViwFl7HopU+ G7rUTDvH+IP/1pNUsoejhWcNvfGXVrPbbujV7NY55jz0VGusZ/Ww9rD08GzhnT0cPXx6ePew 93Bftd1WTeuC2dp0tO6A3UyG1h2wm8nQugO8mQytY+rNLtU6pt55vY6pd16vk+SN16VOkjfb UeokebMdpXbVm65K7ap3+y4eZkWejFL2cHSwVMucpktSLXOaLkm1zOk2UjxM5qyphPewdbBU P0bX0+rH6Hpa/RhdT/Nje0o++ZYjPTw7eFazRzPXs5o9mrme1ezRfUfKD/9JPEnl9PDu4Fkn KRt/zWr2bLbArGbPxjGmDz09JVZT6eHZwpI9HD18enj3sPew9fDq4b5q0lZtlgXDf4Fed7Ts AP7v9Jould5Nxqz015ORWdmvV2lGZb92ep7Kfm303JX92ufplf16MaZV9uu9mLWd83U7s270 zG4+H2ZkPxnA08O7gbM6RZv2VKPo6/ZENYo+bc83AQYAgJsbxg0KZW5kc3RyZWFtDWVuZG9i ag00MiAwIG9iag08PC9FeHRlbmRzIDM2IDAgUi9GaWx0ZXIvRmxhdGVEZWNvZGUvRmlyc3Qg OTY3L0xlbmd0aCA5MzkvTiAxMDAvVHlwZS9PYmpTdG0+PnN0cmVhbQ0KaN58V8uOZTUM/JUs YYE6cfyKNJoFArEAoRHwA6xmx/8vKfvMoyXfeBZpS1V1bMflTPdiOmOOxXuOveLnGkrxk8bZ 8RPHPhHwWC4RyKCHqoMerg16yD42cQRnbIvP8hy8NII1OMlMg5PMe0iSmYdIfJll6Iwvsw5l i8CGPmQf9pDPsCTLHObxZVnDV5CFhoOHYA+3qFl4nBVlQHE4viw6jkUZAsWc8WmBZEZ3LNBM jY8rRPgXEY4V5KyeUqE4iCOBQkYnFTh2plAUtT0V9uUCWaOsLElxCIUi7kcsFHFothClafZg kGkqDDksuzDITKJnw+Ez+jDInq4Nx9N2HE/fjuNp3HGcrMppoI2oyjeiVDgPWo8C012PAuNd eVeQEa3I4Y4ommY/4YJQnIkoFWchSsVBDs67wvSI864OcnDeFQ6SR4Ec8iiQQx8FcmjO4yCH xsXKRA4FGRFyGFlEyGExPIGMzONiJ3I4xcVO5HBYAxFyOJpGFD5dOyLkOJIKOHXOyIFm9kwF Br/niRyLsBUcCsj2yhyLYfKdCkHkqdCxd1aFMe5tqcAy8EoFcqRBBKVtzj4IOSQVhBySfRBy KFpYsRdbZT5W2U/nhBxP5zj20zkhR3T+4cPb78+OzvHX2ycYELVF+PfbP798/PgV3j1MDez+ 9se//33+4dc/f/rt5x+DFE9F8j/DlV/on76yrbLnna2Fna/Sa3Y+Kt8K5Rd9nB72Bnaphdu9 cK5svbN3ZUvXpn4vdNc+WHqYG9iplML7XviqbLqzZ2Wvpk17N02qfejpYe9h62HtYelh7uHd w9TDq4f7W5Pu1uyUCYlfJ2R18+W+ElY3X+4rYXXz5b4SVpdT+M6uyyl3j1tdTrl73Or+yN3j VvdH7q+hvdif+2uodZZ8n6XWWbJ1u/luP1Z1mUkPcwNrNYrdx6PVKHYfj1ajWPcE+btVnLUP Xz08G1irC62ZZnWhNdOsLrRumv79rZznRR/Ww9rAWi3u90XWanG/L7JUi/tu2jzfbTe99nF2 D1MDS92fczeWVIuf+95Ltbg3vwXF75ffCrXShyzrYe1h6WHu4d3D1MOrh2cLz9PD/a3N7tak PCvxx8V1nlzZ95WQXdnNSlBl31dCVmXfH0+ZlX33OJ/KvnucX+zP3eP8Yn/uryHX/Tn315Dr fxHnPkuur/hpfnWPv9++2Uiry2j3MDUwV6NQM55qFGrGU42yuidov1tFedHH6WFvYK4upJfT /F+AAQAblAykDQplbmRzdHJlYW0NZW5kb2JqDTQzIDAgb2JqDTw8L0V4dGVuZHMgMzYgMCBS L0ZpbHRlci9GbGF0ZURlY29kZS9GaXJzdCA5NjgvTGVuZ3RoIDEwODMvTiAxMDAvVHlwZS9P YmpTdG0+PnN0cmVhbQ0KaN6UV7uOXDcM/RWVSWGMRJGUBBgugtguEgSLTbpFClfu/P+lD6Wh PbBWvNhGS4iH70PN3SI0Uk5Fak6s9rekQfYXB1UT7GATcHQxQRIBBkETtWZCS3WBe6oLPFKd YIbfYo65IIB5ZkqSuwk1yQQzJ1lgSbrAmpTNMw5tE9xTy8OEkRpbxpJTa5aGlNSzeRZKfaYr NXU1z3Dfh3kWQVnmWTSNNsFwn4u5Fhx5wRGgFHOuOHCahBA03Vv2xGahCELDLMysznQUYWqf Fji4TgvE4Jm+2jHz17FyL9Ls6FaBlaHFLCw1Zauh4dBmMexo2apoOJpMC8RowzpkA+jLAjF6 N/cNx6hm0RFjzBg4UIZZdIJk7qXXRKVYjM6QeFpgusXcC4ohAE1qkGblvUMy94JAVMlKGBmS FS0DMXjWAQ4RW4tlIIbM/qFhJHOqGAnJpNlADK3zDjG0zzvEaDPTMYxg1pKMGL1YSzJidJ0S Yox1hxjDqKSZU815SgJp3WmqZd2Bp2XdgahE0zOYSigBA8ip1jpHUSDNuCim8oyBo/K6QwxZ OMRYIwNrqy4cYuiMAXLVNuMWxGgzZzSsrjqo2IaYFmnUyVLFDtWBrYKEGMNGqySJ59wU/OW8 7hqWat11SLh7//72Fyxuf3/59vW3j/+8+/zH77cndBA2OT3fnr6CLlP69/b04cNC9x0tR/Tc 9qkEzVHU0v7350+1xGoO1LVtqWCPj4nrjqYzWnZ0Ccpk+plo3evgEqtzoK68pzLOidcd3c9o 2tEtKFMfpkl7HSqxmmN1jdUUq0uszqFaRqzusbrF6rhrEnWtlm1Cwud55h19XgnaN1/OK0H7 5st5JWhfTsln9L6cfOY47cvJZ47Tvj985jjt+8Pn15D2/eHza0j7LPk8S9pnyTXYzf6wAOUX Gr3MX3fcrR93CP+/DlwfBEc/68shVGuslljNkXqnawsastO1nclddrq24L2/0/XT87tPz3d0 Dkaz+dYzuctOQD2Tu/Cb0Dtd9bgKL/PranFm9AfO5H1u42Hqr6klVvNZ/TK/Cu9Z1IssSuin +waMHPrZ964HLS1vQe8M7uenaKdkP79E/S3g/bXt51drZ28/P1o7HXvw+7ODgy+yN4BfSl9z xSuw3pE57CI/viGfHdgW+ez/InFBY4s1XwCdUO2BUK9beIzV5jOwuWt/rVu/cN3ILaoLHFus bzgAtbnQLyyyA4sLFFuIW4hbiOcpnqdc5Mnug90Huw92H3zho3qt66s2ALrrWmMgedPoomnF J0heB3kddNG94sDiWRUvuFwUnD29fJFedo859qjD68j5Anj3qL5ROmK2a79vnHZ1obkQp6++ H9qzC+XCwrNqF1k199guPPoiqbYLIDkwJpeKexTvg1z0wRdNfdFUYnIpex/Yu8/xe6f1/ihp 9abzBRWqx6inXn8XYADpuFdIDQplbmRzdHJlYW0NZW5kb2JqDTQ0IDAgb2JqDTw8L0V4dGVu ZHMgMzYgMCBSL0ZpbHRlci9GbGF0ZURlY29kZS9GaXJzdCA5NzAvTGVuZ3RoIDEwMzYvTiAx MDAvVHlwZS9PYmpTdG0+PnN0cmVhbQ0KaN6UV7uOXDcM/RWVSWGsRPElwHAR2E6RIDDW6YIU rtwZ/v8qJDXrvQivGKTZ5QwPdQ4pUtIMhtV6Gzx7m8P/jybg/+3PUDdmG4JuYAOYblADim+4 gZIb0uaO1jZF3FgNu4djb2gfzBgNxZkQGg12YzZi50JsvMHUeIO58QZLk+4rozZBXxlXk+Uy qDcNMI2mASZoK8A02/IE2GQu8ZXJZHZw0WTUfcNtubHxBhk7wBY09WaxQaD7+mwQ8AXY1c6I cMiMCLZF544wCO4I48AdYRyoni0bBw3PgA1CEREyIkLGrpVZ8PJRvPIR4fWXHWGLavc8xBbV 6RxecNWIMI4FEWGLLl+AtTfoEWEQ6BGhYJaLZJ0NxnBKte0dXgi2LQXYEexbHhFi1o5Qs5Zz 6GowwSOWccxokmUcCJ7HMg6MCNstoOBY6J3jqpb30I4wDu7OYYuCb6ZZxsHBsYxDPEK6cUgU wjYA1COkgzfgcMs41CPEhMNyVWIQWL6h0rnNviOsU/uOsFbtVgizlrX+iGL7EETEGG1CRJjw CdbpZk2zfENloFnLOQZZ50NEGMcU2ls2EZzDBmjijjAOCg4rziT0PAwyKSLAOLg7hw3Y9HEy yzh8e8wyDgkOYB+viDAODQ5Ldao15tu3T7/tOe7t+emTtbE1v5ufn/58fvfO3X/FeNt3e77N +NuB+wgI4PsNtHl6+v3Lt68/ffjjza+//Bygl4W/WvM+4J8ey+rjnIgFI+7j85uPz/8V13Rl Fkjoz9+/fHsExEnzSI8t8X+pjhPp7FbOdHQWRxmNR3ScZj+oJStDqN2jcCsmKVhUdWbh64yG jNYqzfUqlG/y0NothVtHTpPPwntGn3dTcqthtZtEr0Ip5/EYraN7Fm7RJIXgLDxPIo0zOrc4 9SJNvrQd5jy4l25ahVvy/NC5sSS3OMkZnVucuErzspvzJk0s3JIHhOdZWe5hhkrZpYRwo0wL t+QJ4HPNOE8AVzWTSw+PrEygcHNucTk3LecWl/NlE++dfYeJXu6wfqPxchskN+dRkfP5wbk/ 5Xx+MP0fdLy9XoSOlfPQWbuhcHMeFS22Ije7ns8Pzs0uq0hzXYTeXN5r1O5eunUVbs6joufD iPKo6HmwKDe7ngeLcrMrVTV7PQHGzbthSe3mwk15AtZZCuWeXueepjwv63xqxkv+h9D8bvAn /9lNqcX9x8JRWW7xtSpllxLSjTIq3DSysqJmPaOrmo3LQOCNslW4cWWu80CgZrRUyi5Nm+9b GVK7uXZT4cY0XjLOFUfO6HPFkTL6fLcjZvQoagaXrPNLQIBqN9buWbgxzw8UeUFGn/PCPAFw nk3MEzDW+SUg+7elofbP2v0SGOMm/8ssXN3/CDAA67kdig0KZW5kc3RyZWFtDWVuZG9iag00 NSAwIG9iag08PC9FeHRlbmRzIDM2IDAgUi9GaWx0ZXIvRmxhdGVEZWNvZGUvRmlyc3QgOTY5 L0xlbmd0aCAxMTQwL04gMTAwL1R5cGUvT2JqU3RtPj5zdHJlYW0NCmjelFe7jh03DP0VlUmR vSIlUhRguFg4SJEgWTjpDBeGYbiw421sIPn7kNLy+gLc4SCNhhDPISk+ZjQwcJZaYLRaOtsT ykR76tLEhFaApwm9YF1QKrixXHCDR2nYTJDSqJswS1/grnYXuEPpY5iAhapZ7q1QM8u9FxoL TIUrmMCF+wKPwtMsdyljg2cZQipQLdIMTFCELQzCIgtMTQ9hYWgskxaYyhQLg3SpbaHVfh0W COkCG68eYIXCuiAYg9UHrmDMCS4Gq5dWLRxWWlsuWJe+omel9c3QpW+GLrQZulA3H+aIVlRD abyiGrrwYgw7yWKMvhOpEj2Bx1CagPmwpIoFNIw2N0OXuRiiy1wMAauf+RBUqZsPaSpNMy9a XdgMLS9shtYXN2OotBmi0kqyzIJtZW1WlVYOpvpo60TaF9hXeRSs6Vt76oNw7akPIrM81QeJ 2Zvqg2HZUx9spRhTfYyqe6LNhFZ7ldTHOpZoaCgAJqkPsdKKgnHWtac+phVFKpdW69Jqo9aN 006FvTdVsmoJVJXmkkAbeu+hSnuvldb2Xi+tg1nWpXWLXrRVNAWwi9LIxkJAfXBbWvXBaw/V x2ou0UQ0aWYP1YdMi0WHqM29pz7m3iMdJcuuIKu090bRANaeqKR7L15cflXG5bd3Xz7+8PPv P/1y/+PlQTOo+lpeXx4+aqst6c/Lw8uXGz0iehyj5f+g11tiKbWdNa9b+9er7+qeqBsHX5rG w8goojGLbF5d1/lMZJKoW4++kpy1iOYksn4TmcTIuuTqkas5V1OibhgO0vvxsSGik/LViD4u H8YW1y/LITo2ba9JAeimACPmiCRXj1zNuZoSNcZZpeMCYJwfOi4AxvmhpABxAigpQJwAygrA N0ngmCPuubolaow9zMkxYw9zcszYw5wdc8D3QCmeY9RUzTNTxwHh428AxAHh7K0e0dn7bNwM RH/mmJyrKVPHFh/HAwGxxcfxQEBs8ZF9UOSm7Vo8h2Cuhkwd50eSxootPuYxOrb4kOyYN9XE Z87BmToOiNChr9jCktTWbphXzxADm5irIVHH8ZjH6Y/TIcfZj/0rWfLnzcw/c52akqtHoo6z MY+HOo7GPK5jbN6Z1FHqtY4048VMKibq0PlSj1/XEMFHVb2/f/znDeEdFpY71st5od7v9Aep 6GfvTu+Sby9/qLV/H799vTx8fvf+w98fvny93H9+fP9pO3uDdV+F9SOxL39vzSPQdUZeX4Hr X3wBqwtwwmhPQOwuUM4A94H1BOimwU3Diel9bbG/THFhnjDAgehCyxgwd7fpV273qAkjZ4gz xBn7RWaCuDBzG8NtDLcx3MZwG+PEBrsNdhvsNtht8JkNcCDmQHLT+8p6DNy/HAasLrgPOvHR nNqd2p26L/AmnJQTPU70FKBbbW61udV2EhA4FZ2KTsUzqhcHOAdWD7h6wNW9QjpQINOB1cOr Hl7FE+pTeDLz8MRbW7y1RaZTT8ITdEZeMxkO3FcoE7oLHuc4ivM/AQYAZnhjwQ0KZW5kc3Ry ZWFtDWVuZG9iag00NiAwIG9iag08PC9FeHRlbmRzIDM2IDAgUi9GaWx0ZXIvRmxhdGVEZWNv ZGUvRmlyc3QgOTcyL0xlbmd0aCAxMDMyL04gMTAwL1R5cGUvT2JqU3RtPj5zdHJlYW0NCmje lFe7jlw3DP0VlUlhrESJL8BwEcR2kSAw1umCFK7cGfn/KiQ1d3cQjrhIM8O5PIeHlEhdzRDQ 1tuQ2dsa/j2agH/bxwxj2kcYq8F+gg32E2pzuHtym7jckLZ6hNG2UMxYvWEPYzS0p2ZAQ3bJ NRsFeK1GKzDYSD3OosYrMNyYAyNNuosubTsn7E3YA+JoCugGNA0wmr8H2rPqG26ITh4cqY0x PDqyWf5TPFfYDAsJwSCDQDDIgoK6BPmyxEKRQaawWwZZm2GQtRkWdG2GQXAzTAM3wzRoeMW+ ELS8Ck+cgsGmwcFgC8r+U9iDdtdg3HthFt0khT2o+k+2oLqCYUFVXEN6gx4MGWaJV277B1ac W9MsT1LENtgobtkOwwoGmaXBYNv+GQwxazPUrGAYBBZ4HWoay5dO1DSwO0NNA9Gzst0F3AzT oNCwxIGiLDUN3gzT4M0wDXaG9u5952VZ10Bsj9qWgUuaZRoK4JZpKAUD2+xjuWWt2jfDenW4 hlpbWvuyW2pWMKwt5lDXGKNNmM4YYJYvtlqzzxkaFtQWIximsUJjmMayFjbLNNZmmAZuhmlg MMA0MDTANCg0DDLJ20zBNEidAabBMximweIatmVTNsM0ogUUTMPLev/+6be/os16e95dZsbf T1+8ycHtp69Pfz5/+HAB1wXEGohXRNSL0d9gwMWYl7Fqhk38BtrE3wx5g9Ev4LgMKBj7vPJn p4DzUp6vyn7Y3YC/XnH6ePr924/vP338493nX37eqFvk73Ym3PBfrrhxqszbXgTx0/O7T89v Ef3cyjqS4F//+fbjpcKFV4V+RPw3cT9oS/es3L2ndPaCP8xeNaPHGS0Z3c8r40f+S6YzF4K9 dC8t3Mo5FTknThnNZzRmNFVl8mui8KBMqt1YuHWlVHCdE8+tiPOMhoyGoky667uR6yCo3aNw a55VOjeW5hZHPaIltzhKVebdbvYHdVDhljwghOfMcg/TKjLj1yUEzZlxL9ySJ4CKNcsTQNWa yV1mkjOTXrpZa7fUbi7ckueHz6MseX642L48P3zePsktzufZlNziDOeXl18F90tR6PWlCPxg K17fLdnNeVTknCPn9pXz+cHyf9BxBX1JlHIdOms31O5RuDmPip4PI86jIufB4tyPch4szv0o XK3Z3aTgg6q5cHPuZj1PCudu1vOkxMX+RTrfWfwfQOletXsWbk6T5P9GTpmSZvT5PkSS0edO oTwvqsWajbuq8/VIx6zdULtH4aY0Af6P61gX5lU410Uro88TQDOjuVqzuwmAB1Vz4SbIVZ8n gEZGVxMAdxOQr0cKWLtX7Z6Fm/IEwHkCME8AnCcA8wTAuVOQ85pVEzDvdjNfxXTyY/e/AgwA ilYnOw0KZW5kc3RyZWFtDWVuZG9iag00NyAwIG9iag08PC9FeHRlbmRzIDM2IDAgUi9GaWx0 ZXIvRmxhdGVEZWNvZGUvRmlyc3QgOTY5L0xlbmd0aCA5NDIvTiAxMDAvVHlwZS9PYmpTdG0+ PnN0cmVhbQ0KaN58V7uOZTUQ/BWHEKBxP21LowkQiACERrv8ANFm/H+41TbDXNHXnfi0VFXu 97nn0uLVeqMlvQnFk5pzPLktiScO1jBwjM20xuRheOPDHU36DGM2sU1eTXuQtTfd9yo13WTl pvtmlWb7ZtVmZmFY877J3lxHGKP5Ic82cCmM1cYMsvU2dxhGbW6ycZsjwjBpqwcZsax9cxx9 X22Q9EPH0fflBtFJ0qCirXBEz1vhFBUIRcTP24NDJtuFQyZHgUOPAj5UIlmHTIO8HDJd4cMh Mw5FlNMioDUg8x6KgcM1fAzIfCtGlF6jnAOyMbcCx6SIauCYR4FjjohqHxSK2U/xYe0jFJMb 92jsmgJrk6eiqzuqGf0dm4wG844KMuajmLAi6TUXrBWK1RsLR1SLYEUKa8GHUkSFErNuBZJh 21FBxifzBR+2o1rw4UcBH64R1YIPD3LHNPFAHhxtRBNGWPAxoYAFHxMKWPAxkTQsyBaigoUj CgsrJvUoMKr9KFZMbygodoDCBw4hCx/ETTiu7ySwtoIU1lFYEzkKh6XhA00RiTKFI1HsDSz4 0K1g+LCtYIplCQXDh20Fw4dLeMM4into0RQ5NUAyKG5kxPAxxr4FPmIPXl9ffj872duXl3cM AjyF+fXlr1/e3j5gq2GtYSlg85c//v7n2w+//vnTbz//GKR4h2z+N6zIv/T3D7ZlNt3Zmtn9 zpbE3i+5C5sze97ZlNnjyt7vrY+S0coV1VHDXsNWw1rA1lMiKtdEdGX2vbk6M/veXB2ZfW+u PhmzVTTAHko4c43MalhrWApY84hbUbM84lbULI+4FTXLI65Vzbx/pjWeZL0KWPOC2H2dNE+h VevkD/3wHJlLAUueYb/3Q/IMOxWRjYfILEc2pIa5hqmGewFLXi+/N1/yevm9fZJH3O/tkzzi 7nd2HnG3ogHzoQGaazSlhrmGqYZ7AUvevlE0IO/PKBqQ92fcG8B5A8a9AZw3YFQNWA8NkFyj JTXMNUw13AuY8wbMewM4b8C8N4DzBsyiAXkDZtGAvAHz3oD9ifxfEfhJjVYNzwLmPMOrSDPP 8CrSzDO8yjQfftEpBRqf/SWsBUz/X5D9z+I68jOz7z8oNDKbijTpYSF6zoOohnsBk+dQiu8B y+z7QpBm9qjS/By7vp7kMWrYC5gkhULFC4wzW+9symwp0uTPbvaZ82AqYOrJF98/9vII06oC e6j/eBLYqGEv4LwefC9/3g6+Vz/PLz8t/ncBBgAWWxXMDQplbmRzdHJlYW0NZW5kb2JqDTQ4 IDAgb2JqDTw8L0V4dGVuZHMgMzYgMCBSL0ZpbHRlci9GbGF0ZURlY29kZS9GaXJzdCA0OTAv TGVuZ3RoIDY0Mi9OIDUyL1R5cGUvT2JqU3RtPj5zdHJlYW0NCmjerFRNbxNBDP0rPsKh2fmy PSNVlRqBOATBquFW9VCqqAdKewkS/Htsb2a3IZMRQpz2xc+e57HfJLhQwEFw0UH0+vVAQb8B StRvBB+zggQ+WwQhBIsQBCwKGEKxQzJEpV0sELNGkoMU9LzkIVFSEAAnEIGclqcExBZBYKfl iYCDAQbOlpMhBzuwQEZtFB3krCfLr+K1MZSWk56DEQprOUrPzpEiFBQMkaBkiAWRoSwoGyrg vVWQE2QV5AVZhUzGhwnJWELRPuQuPqLFUEfFikQjOUOikdjyRAOdNkyigVE7ZtGYhiEpHov2 zKJBpsuiQainyHQ8ZZ25XMuzMyQabHtg0eBkSDSYDIkGW4WswWepuLwcNtMaHdwMowbJ4Hb4 8u7qqtKxT4cOjcPH++fHN+8/XXxYv5UcM5OlP8pgDtnjITmdJruzyfEk2VzbTjYbzl1i4xLc o0/7orNS/jQZzyXfmpEkNPlIwJ1U5MNFtsN297CfM1PNTL3M6+mpaNSKuBblCsoBoKugHoyh glgV7LUexnH/9Wm3aExX2UxvdZpdM3m9fvl5Ky9pJfb1bpVkGgn9ymV5AESrEsLd8Flm9uvl x34Yn+4fdt93z/th/fTy8G1eT8JFIlSJG6PHpYN5ZabpVg4uPMUsYoDJr4q8NCr5LyXJLZL+ WHIz/Sl06dynuU9Tn8Y+nc7S47zcZVjjvPk/Yr4Rc6exVBqx3Ijxcex6+lOsTqXqVKpOpepU rk7l6lSuTuVXTo2l6VRanErLZBrJ/8WptOyGGk6lrlPTPzk1L06lhh249Oncp7lPU5/GPp3O 0uO83GMXccOp3HAqN5xKDadSw6n02qm/BRgAQwT3WQ0KZW5kc3RyZWFtDWVuZG9iag00OSAw IG9iag08PC9MZW5ndGggNDUwNS9TdWJ0eXBlL1hNTC9UeXBlL01ldGFkYXRhPj5zdHJlYW0N Cjw/eHBhY2tldCBiZWdpbj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+ Cjx4OnhtcG1ldGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IkFkb2JlIFhN UCBDb3JlIDUuMi1jMDAxIDYzLjEzOTQzOSwgMjAxMC8wOS8yNy0xMzozNzoyNiAgICAgICAg Ij4KICAgPHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIy LXJkZi1zeW50YXgtbnMjIj4KICAgICAgPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIK ICAgICAgICAgICAgeG1sbnM6eG1wPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIj4K ICAgICAgICAgPHhtcDpNb2RpZnlEYXRlPjIwMTctMDQtMThUMTQ6Mjg6NDkrMDI6MDA8L3ht cDpNb2RpZnlEYXRlPgogICAgICAgICA8eG1wOkNyZWF0ZURhdGU+MjAxNy0wNC0xMlQxNjow NDowMiswMjowMDwveG1wOkNyZWF0ZURhdGU+CiAgICAgICAgIDx4bXA6TWV0YWRhdGFEYXRl PjIwMTctMDQtMThUMTQ6Mjg6NDkrMDI6MDA8L3htcDpNZXRhZGF0YURhdGU+CiAgICAgICAg IDx4bXA6Q3JlYXRvclRvb2w+QWNyb2JhdCBQREZNYWtlciAxMSBmb3IgV29yZDwveG1wOkNy ZWF0b3JUb29sPgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAgICAgPHJkZjpEZXNjcmlw dGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6eG1wTU09Imh0dHA6Ly9ucy5h ZG9iZS5jb20veGFwLzEuMC9tbS8iPgogICAgICAgICA8eG1wTU06RG9jdW1lbnRJRD51dWlk OjE1MmU1Y2FlLWVlYWMtNGY1MC1hMmI1LThhODZiOGViMjY3NzwveG1wTU06RG9jdW1lbnRJ RD4KICAgICAgICAgPHhtcE1NOkluc3RhbmNlSUQ+dXVpZDpkYTY3ODg2Yy04ZmZiLTQzMTEt YjJmMS1iZGFkMjhjNzA0MjE8L3htcE1NOkluc3RhbmNlSUQ+CiAgICAgICAgIDx4bXBNTTpz dWJqZWN0PgogICAgICAgICAgICA8cmRmOlNlcT4KICAgICAgICAgICAgICAgPHJkZjpsaT41 PC9yZGY6bGk+CiAgICAgICAgICAgIDwvcmRmOlNlcT4KICAgICAgICAgPC94bXBNTTpzdWJq ZWN0PgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAgICAgPHJkZjpEZXNjcmlwdGlvbiBy ZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6ZGM9Imh0dHA6Ly9wdXJsLm9yZy9kYy9l bGVtZW50cy8xLjEvIj4KICAgICAgICAgPGRjOmZvcm1hdD5hcHBsaWNhdGlvbi9wZGY8L2Rj OmZvcm1hdD4KICAgICAgICAgPGRjOnRpdGxlPgogICAgICAgICAgICA8cmRmOkFsdD4KICAg ICAgICAgICAgICAgPHJkZjpsaSB4bWw6bGFuZz0ieC1kZWZhdWx0Ij5FVFNJIERpcmVjdGl2 ZXMgLSBWZXJzaW9uIDM3IC0gQXByaWwgMjAxNzwvcmRmOmxpPgogICAgICAgICAgICA8L3Jk ZjpBbHQ+CiAgICAgICAgIDwvZGM6dGl0bGU+CiAgICAgICAgIDxkYzpkZXNjcmlwdGlvbj4K ICAgICAgICAgICAgPHJkZjpBbHQ+CiAgICAgICAgICAgICAgIDxyZGY6bGkgeG1sOmxhbmc9 IngtZGVmYXVsdCIvPgogICAgICAgICAgICA8L3JkZjpBbHQ+CiAgICAgICAgIDwvZGM6ZGVz Y3JpcHRpb24+CiAgICAgICAgIDxkYzpjcmVhdG9yPgogICAgICAgICAgICA8cmRmOlNlcT4K ICAgICAgICAgICAgICAgPHJkZjpsaT5QaWVycmUtQWxhaW4gQ0VSREFOPC9yZGY6bGk+CiAg ICAgICAgICAgIDwvcmRmOlNlcT4KICAgICAgICAgPC9kYzpjcmVhdG9yPgogICAgICA8L3Jk ZjpEZXNjcmlwdGlvbj4KICAgICAgPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAg ICAgICAgICAgeG1sbnM6cGRmPSJodHRwOi8vbnMuYWRvYmUuY29tL3BkZi8xLjMvIj4KICAg ICAgICAgPHBkZjpQcm9kdWNlcj5BZG9iZSBQREYgTGlicmFyeSAxMS4wPC9wZGY6UHJvZHVj ZXI+CiAgICAgICAgIDxwZGY6S2V5d29yZHM+cnVsZXMsIGRpcmVjdGl2ZXMsIGdlbmVyYWwg YXNzZW1ibHksIGJvYXJkLCBzdGF0dXRlcywgcHJvY2VkdXJlcywgZ3VpZGFuY2UsIElQUjwv cGRmOktleXdvcmRzPgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAgICAgPHJkZjpEZXNj cmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6cGRmeD0iaHR0cDovL25z LmFkb2JlLmNvbS9wZGZ4LzEuMy8iPgogICAgICAgICA8cGRmeDpTb3VyY2VNb2RpZmllZD5E OjIwMTcwNDEyMTM1OTUwPC9wZGZ4OlNvdXJjZU1vZGlmaWVkPgogICAgICAgICA8cGRmeDpD b21wYW55PkVUU0kgU2VjcmV0YXJpYXQ8L3BkZng6Q29tcGFueT4KICAgICAgICAgPHBkZng6 X2RsY19Eb2NJZEl0ZW1HdWlkPmY2MWNlNzI0LTYxMGEtNDVkYy05YzkwLTRhYWU1NDJmNWY2 ODwvcGRmeDpfZGxjX0RvY0lkSXRlbUd1aWQ+CiAgICAgICAgIDxwZGZ4OkNvbnRlbnRUeXBl SWQ+MHgwMTAxMDA4MjFFM0M2QzkwMDY3MjREQUM1QzExQUE3MEJGMUNCNTwvcGRmeDpDb250 ZW50VHlwZUlkPgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAgPC9yZGY6UkRGPgo8L3g6 eG1wbWV0YT4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAg ICAgIAo8P3hwYWNrZXQgZW5kPSJ3Ij8+DQplbmRzdHJlYW0NZW5kb2JqDTUwIDAgb2JqDTw8 L0ZpbHRlci9GbGF0ZURlY29kZS9GaXJzdCA0Mi9MZW5ndGggMTQ1L04gNS9UeXBlL09ialN0 bT4+c3RyZWFtDQpo3jIysDBUMFAwMrAwUjC2BNHGCoaGRiCGiYKhmRmIYapgZGKoYGOj75xf mlcClNb3zkwpjgbrMVAIitUPqSxI1Q9ITE8ttrPDpswYpAxiJJRhCtEYkFiUClRqBHFEEA6D 4OZYousywq3LFKILbK4CxAFgSxXMwSQ5RkHMMoQYZggxzdAc6iXC5gEEGACWHF4sDQplbmRz dHJlYW0NZW5kb2JqDTUxIDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9GaXJzdCA3L0xl bmd0aCAzNzIvTiAxL1R5cGUvT2JqU3RtPj5zdHJlYW0NCmjeVJDRbpxADEV/xW8BdSkeFlio okgENhVqE62yq+YxGmZMOy3LrMzQlr/PkFZRK79cy9fW8U2wyAHh+jquZvfNcnAwxExRNUgz Qr1/bKqHMK7t+SLHJdifji0cSTE5yUa6dTI6Gt1puVCrA/yNwhcWidhv67wuEfNdkjZVndVC VNUOb+9EfZv5PSbpjB0b6ShoPiQodpiKROSYYvIOkyvEq78uD1Uptp10cGju7uUPYhACesvw ZFmH8SdafnkxBTwPNG1AGyblzM9Vf6WRWA4gp4nO3bBsoLOS9QYmJ93sVsuFrSI986t9NlqO ijbQHh7D+N7q/wELkSZFWr4BHtjqWZEn1LajlQ8+m44lLx7xPYbx0c6syN8xvSH976fbrMxW w9x997RBGJ+MG+hPxM3bBxDBF+LJJwXbnW+qC5sB1iNh/KwH9dxY1erW0fmjRw/6XCjyiUe5 QBmlmVZRqUqMUikpS5M+6/MivLl5EWAAx9CYrw0KZW5kc3RyZWFtDWVuZG9iag01MiAwIG9i ag08PC9EZWNvZGVQYXJtczw8L0NvbHVtbnMgNS9QcmVkaWN0b3IgMTI+Pi9GaWx0ZXIvRmxh dGVEZWNvZGUvSURbPDNDQkQyMjdGMUUwQzVBNEY5ODQ1MjYyRkI5ODlGM0NEPjw0QTUyNzlB QzE1NjM5QTRCQTczN0NEMEZBOTBBOTg1NT5dL0luZm8gMjA4NiAwIFIvTGVuZ3RoIDI4Mi9S b290IDIwODggMCBSL1NpemUgMjA4Ny9UeXBlL1hSZWYvV1sxIDMgMV0+PnN0cmVhbQ0KaN7s 0z1LQnEcxfH//dsTaEtUKCShkw1NYltzL6ApaHRpcpWCXoEEvYBegbi0tDr3ANISQtBW0CQN pRSS5yw3CMSmlu8dPhx+9/l/z41BW0xCpRdiCMm7zF+lee3T+VUWaj+OuXb+kOu7zkO5upfO y+dpLj04x4lJ9UY5e5DuLSw6+/pbReeKPOrLeCiX93VuznfP3npy4vxkR7Yhly5l5tGTHbng O2bOnFtyrinnt503bMeTU/vsybHd9LlvcuXFzzbwU91P1m1cbyv7zWYzGf3teMSZenXBOiC9 QnqF9AqRXiG9QnqF//QVur8mY1YG+d+RXiG9QqRXSK+QXiHSK6RXSK8Q6RXSK6RXOM14N3VV v74FGABBzk2EDQplbmRzdHJlYW0NZW5kb2JqDXN0YXJ0eHJlZg0KMTE2DQolJUVPRg0K --------------CF1EC0345B9BE4B0480D3D89-- From nobody Fri Feb 16 07:42:47 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8490412D88E for ; Fri, 16 Feb 2018 07:42:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q_Lzh8oc4uZ0 for ; Fri, 16 Feb 2018 07:42:43 -0800 (PST) Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::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 C4791120725 for ; Fri, 16 Feb 2018 07:42:43 -0800 (PST) Received: by mail-ot0-x22b.google.com with SMTP id l10so3065851oth.1 for ; Fri, 16 Feb 2018 07:42:43 -0800 (PST) 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=2uA/RTEad65TMkn7/6SFpwX81igsXDQUrjuMufBOqj0=; b=JaRBCGlSB3o4DxFvgVSoDLBhlXNFAvMifIMPZ8TdxjyrUwq0vYjhvBqwLwEJ/N58m+ RAwJ5XzTac1D5Vk897YcCVX23BpbZthJRZM9gbE7pr2EdQgP/wpOy8zJvioVPJMHi9Wn e/KuTNdI7Jd8eg3TdUX18UmBwWUDr8qFl6tfdijqy/07JmAoQ1tqMp1o9tlg+0Q8E9nn yoK2S6Q1tSr9WyOHHzMzZi8HchjLHTu3OZCt5YYYklHhj2oN5b9v7kTGo66H/MQWjB0P I3QHimD6DwYWAAhHYjSqTVK4GsFOHKnYVeIsc2lJH2qs7MZ73bAkR5sIcRnjxNyMON5L BF3g== 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=2uA/RTEad65TMkn7/6SFpwX81igsXDQUrjuMufBOqj0=; b=pEq/nxmqyAmiypzfStuiux8+sZWlsicjAbUXFWdsrFmBAUayyvVy+vPl0hysa/d5U5 FOdo5SVRyPU9BwlLi+kaFTMYnAIo8JXlclqYxl66Myb8cNl9hRvZiQXwOcRoD7z7PDeA HaGe+vjS6GziNe8wFIWFg0LlTnSl8SXl7eadEqIYEEQ0BLFZvOt3wNmIIlpe3L5eT8hJ wyGQ5qhY9cJHMv1meeShzqId567fes9aNYtzQMh31gj7IsvOhLvreKYMfFHAsqa0Q4uU Y6IhwV2q4M55/6Tbg/F4S6YXAXfgybN3KHi4KJXwUbx0JhkH1JQCb5AtgmHclrSMayH3 F/Zg== X-Gm-Message-State: APf1xPBErlZlDkJzso+pazHSJ+sMj/amV4CXnB6EzrMgvaee35Qi3h5i DSWYOGaWgsn/6kIt1FszMXe9WyDkqna3CTj8WCA= X-Google-Smtp-Source: AH8x225gSGZockJI4utMhYhTufVTiynY25uhLCM58z+rSAkkelOaw5nhWgPvGA6Kkk8peVGkUsiF0G7h2hdVYXog6Uo= X-Received: by 10.157.84.8 with SMTP id j8mr4569990oth.350.1518795763209; Fri, 16 Feb 2018 07:42:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.44 with HTTP; Fri, 16 Feb 2018 07:42:42 -0800 (PST) In-Reply-To: <02fbd867-9694-e68e-a328-6154d6ead9d9@gmail.com> References: <151869691215.7607.4477863832246767156.idtracker@ietfa.amsl.com> <02fbd867-9694-e68e-a328-6154d6ead9d9@gmail.com> From: Abdussalam Baryun Date: Fri, 16 Feb 2018 17:42:42 +0200 Message-ID: To: Alexandre Petrescu Cc: "its@ietf.org" Content-Type: multipart/alternative; boundary="f403043c62e8f3d9530565563178" Archived-At: Subject: Re: [ipwave] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-17.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: Fri, 16 Feb 2018 15:42:45 -0000 --f403043c62e8f3d9530565563178 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Feb 16, 2018 at 1:03 PM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > > > Le 16/02/2018 =C3=A0 11:46, Abdussalam Baryun a =C3=A9crit : > >> >> >> On Thu, Feb 15, 2018 at 2:19 PM, Alexandre Petrescu < >> alexandre.petrescu@gmail.com > >> wrote: >> >> Hi IPWAVErs, >> >> I submitted a new version of the IPv6-over-OCB draft - the 17th. >> >> The ChangeLog is: >> >> Susbtituted "MUST be increased" to "is increased" in the >> MTU section, about fragmentation. >> >> The phrases in question are: >> >> NEW: >> >> If IPv6 packets of size larger >>> than >>> 1500 bytes are sent on an 802.11-OCB interface card then the IP >>> stack >>> MUST fragment. In case there are IP fragments, the field >>> "Sequence >>> number" of the 802.11 Data header containing the IP fragment >>> field is >>> increased. >>> >> >> Replace last sentence above> >> >> In case there are IP fragments, the subfield fragment number within the >> field "Sequence >> control" of The 802.11 data header containing the IP fragment is >> increased by MAC layer. >> > > Is the combination of Fragment Number and Sequence Number subfields calle= d > "Sequence control" by IEEE? > Yes, as in ieee802.11-2016-std- p646, the sequence control is 2 octets, 4 bits only for fragment number and 12 for sequence. B0 B3 B4 B15 +-----------------+--------------------------+ | Fragment number | Sequence number | +-----------------+--------------------------+ The sequence number within the Sequence Control field remains the same for all fragments, while the fragment number within the Sequence Control field increments for each fragment. AB > > --f403043c62e8f3d9530565563178 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Feb 16, 2018 at 1:03 PM, Alexandre Petrescu &= lt;alexan= dre.petrescu@gmail.com> wrote:


Le 16/02/2018 =C3=A0 11:46, Abdussalam Baryun a =C3=A9crit=C2=A0:


On Thu, Feb 15, 2018 at 2:19 PM, Alexandre Petrescu <alexandre.petrescu@gmail.com= <mailto:alexandre.petrescu@gmail.com>> wrote:

=C2=A0 =C2=A0 Hi IPWAVErs,

=C2=A0 =C2=A0 I submitted a new version of the IPv6-over-OCB draft - the 17= th.

=C2=A0 =C2=A0 The ChangeLog is:

=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Susbtituted "= ;MUST be increased" to "is increased" in the
=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 MTU section, abou= t fragmentation.

=C2=A0 =C2=A0 The phrases in question are:

=C2=A0 =C2=A0 NEW:

=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 I= f IPv6 packets of size larger than
=C2=A0 =C2=A0 =C2=A0 =C2=A0 1500 bytes are sent on an 802.11-OCB interface = card then the IP stack
=C2=A0 =C2=A0 =C2=A0 =C2=A0 MUST fragment.=C2=A0 In case there are IP fragm= ents, the field "Sequence
=C2=A0 =C2=A0 =C2=A0 =C2=A0 number" of the 802.11 Data header containi= ng the IP fragment field is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 increased.

Replace last sentence above>

In case there are IP fragments, the subfield fragment number within the fie= ld "Sequence
=C2=A0=C2=A0=C2=A0 control" of The 802.11 data header containing the I= P fragment is increased by MAC layer.

 Is the combination of Fragment Number and Sequence Number subfields called = "Sequence control" by IEEE?

<= br>
Yes, as in ieee802.11-2016-std- p646, =C2=A0the sequence cont= rol is 2 octets, 4 bits only for fragment number=C2=A0and 12 for sequence.<= /div>

B0=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 B3=C2=A0=C2=A0=C2= =A0B4=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 B15

+-----------------+--------------------------+

|=C2=A0Fragment number=C2=A0|=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Sequence number=C2=A0=C2=A0 =C2=A0|

+-----------------+--------------------------+

=C2=A0<= font lang=3D"ZH-TW" face=3D"TimesNewRomanPSMT" size=3D"2">

The sequence number within the Sequence Control field remains the same for= all fragments, while the fragment number within the Sequence Control field= increments for each fragment.


AB


--f403043c62e8f3d9530565563178-- From nobody Fri Feb 16 07:45:57 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9E012D893 for ; Fri, 16 Feb 2018 07:45:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.634 X-Spam-Level: X-Spam-Status: No, score=-2.634 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, RCVD_IN_MSPIKE_H2=-0.001, 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 RIAW196miqiq for ; Fri, 16 Feb 2018 07:45:43 -0800 (PST) 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 3C486126579 for ; Fri, 16 Feb 2018 07:45:42 -0800 (PST) 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 w1GFjf7l036733; Fri, 16 Feb 2018 16:45:41 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 40F41201FE5; Fri, 16 Feb 2018 16:45:41 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 33CCD201653; Fri, 16 Feb 2018 16:45:41 +0100 (CET) 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 w1GFjeVe029394; Fri, 16 Feb 2018 16:45:41 +0100 To: Abdussalam Baryun Cc: "its@ietf.org" References: <151869691215.7607.4477863832246767156.idtracker@ietfa.amsl.com> <02fbd867-9694-e68e-a328-6154d6ead9d9@gmail.com> From: Alexandre Petrescu Message-ID: <7b7949f5-eca6-8b55-1331-0abb3260fdc9@gmail.com> Date: Fri, 16 Feb 2018 16:45:40 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.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] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-17.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: Fri, 16 Feb 2018 15:45:55 -0000 Le 16/02/2018 à 16:42, Abdussalam Baryun a écrit : > > > On Fri, Feb 16, 2018 at 1:03 PM, Alexandre Petrescu > > wrote: > > > > Le 16/02/2018 à 11:46, Abdussalam Baryun a écrit : > > > > On Thu, Feb 15, 2018 at 2:19 PM, Alexandre Petrescu > > >> wrote: > >     Hi IPWAVErs, > >     I submitted a new version of the IPv6-over-OCB draft - the > 17th. > >     The ChangeLog is: > >              Susbtituted "MUST be increased" to "is increased" > in the >              MTU section, about fragmentation. > >     The phrases in question are: > >     NEW: > >                                           If IPv6 packets > of size larger than >         1500 bytes are sent on an 802.11-OCB interface card > then the IP stack >         MUST fragment.  In case there are IP fragments, the > field "Sequence >         number" of the 802.11 Data header containing the IP > fragment field is >         increased. > > > Replace last sentence above> > > In case there are IP fragments, the subfield fragment number > within the field "Sequence >     control" of The 802.11 data header containing the IP > fragment is increased by MAC layer. > > > Is the combination of Fragment Number and Sequence Number subfields > called "Sequence control" by IEEE? > > > > Yes, as in ieee802.11-2016-std- p646,  the sequence control is 2 octets, > 4 bits only for fragment number and 12 for sequence. > > B0   B3   B4                        B15 > > +-----------------+--------------------------+ > > | Fragment number |       Sequence number    | > > +-----------------+--------------------------+ > > The sequence number within the Sequence Control field remains the same > for all fragments, while the fragment number within the Sequence Control > field increments for each fragment. Thanks for the explanation. Makes sense. Do they say whether the fragments are IP fragments or not? Because in implementation, whenever there is an IP fragment, that fragment number field is incremented. And there seems to be strong opposition we write this. Alex > > > AB > > From nobody Fri Feb 16 08:53:32 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A914120454 for ; Fri, 16 Feb 2018 08:53:31 -0800 (PST) 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 H3GjXYRu5EEi for ; Fri, 16 Feb 2018 08:53:29 -0800 (PST) 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 A6FDD126579 for ; Fri, 16 Feb 2018 08:53:28 -0800 (PST) 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 w1GGrMRq115575; Fri, 16 Feb 2018 17:53:22 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 96CE4206FF6; Fri, 16 Feb 2018 17:53:22 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 86ECF206FB5; Fri, 16 Feb 2018 17:53:22 +0100 (CET) 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 w1GGrM99025960; Fri, 16 Feb 2018 17:53:22 +0100 To: dickroy@alum.mit.edu, "'Abdussalam Baryun'" Cc: its@ietf.org References: <151869691215.7607.4477863832246767156.idtracker@ietfa.amsl.com> <02fbd867-9694-e68e-a328-6154d6ead9d9@gmail.com> <7b7949f5-eca6-8b55-1331-0abb3260fdc9@gmail.com> From: Alexandre Petrescu Message-ID: <479c2890-a58f-dbbf-ec33-82528cd218ca@gmail.com> Date: Fri, 16 Feb 2018 17:53:22 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.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] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-17.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: Fri, 16 Feb 2018 16:53:31 -0000 Le 16/02/2018 à 17:20, Dick Roy a écrit : > "Do they say whether the fragments are IP fragments or not?" > > Of course 802.11 does not say anything about what is being > fragmented. It DOES NOT KNOW! How can it unless it inspects the > MSDU, and 802.11 DOES NOT DO THAT! Well 802.11 does inspect the *DU for which it is in charge, and that contains the EtherType which is 0x86DD which stands for IPv6. > Nor does it care! Any reference, especially if it's normative, to > 802.11 fragmentation should be removed from the draft. If we remove that frag text should we also delete de implementation of it? Alex > > RR > > -----Original Message----- From: its [mailto:its-bounces@ietf.org] > On Behalf Of Alexandre Petrescu Sent: Friday, February 16, 2018 7:46 > AM To: Abdussalam Baryun Cc: its@ietf.org Subject: Re: [ipwave] Fwd: > New Version Notification for > draft-ietf-ipwave-ipv6-over-80211ocb-17.txt > > > > Le 16/02/2018 à 16:42, Abdussalam Baryun a écrit : >> >> >> On Fri, Feb 16, 2018 at 1:03 PM, Alexandre Petrescu >> > > > wrote: >> >> >> >> Le 16/02/2018 à 11:46, Abdussalam Baryun a écrit : >> >> >> >> On Thu, Feb 15, 2018 at 2:19 PM, Alexandre Petrescu >> >> > >> wrote: >> >> Hi IPWAVErs, >> >> I submitted a new version of the IPv6-over-OCB draft - the 17th. >> >> The ChangeLog is: >> >> Susbtituted "MUST be increased" to "is increased" in the MTU >> section, about fragmentation. >> >> The phrases in question are: >> >> NEW: >> >> If IPv6 packets of size larger than 1500 bytes are sent on an >> 802.11-OCB interface card then the IP stack MUST fragment. In >> case there are IP fragments, the field "Sequence number" of the >> 802.11 Data header containing the IP fragment field is increased. >> >> >> Replace last sentence above> >> >> In case there are IP fragments, the subfield fragment number >> within the field "Sequence control" of The 802.11 data header >> containing the IP fragment is increased by MAC layer. >> >> >> Is the combination of Fragment Number and Sequence Number subfields >> called "Sequence control" by IEEE? >> >> >> >> Yes, as in ieee802.11-2016-std- p646, the sequence control is 2 >> octets, 4 bits only for fragment number and 12 for sequence. >> >> B0 B3 B4 B15 >> >> +-----------------+--------------------------+ >> >> | Fragment number | Sequence number | >> >> +-----------------+--------------------------+ >> >> The sequence number within the Sequence Control field remains the >> same for all fragments, while the fragment number within the >> Sequence Control field increments for each fragment. > > Thanks for the explanation. Makes sense. > > Do they say whether the fragments are IP fragments or not? > > Because in implementation, whenever there is an IP fragment, that > fragment number field is incremented. > > And there seems to be strong opposition we write this. > > Alex >> >> >> AB >> >> > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > > From nobody Fri Feb 16 08:57:48 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 098F6124C27 for ; Fri, 16 Feb 2018 08:57:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ltXUEwekYZF4 for ; Fri, 16 Feb 2018 08:57:45 -0800 (PST) Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (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 6E0BA120454 for ; Fri, 16 Feb 2018 08:57:45 -0800 (PST) Received: from resomta-po-12v.sys.comcast.net ([96.114.154.236]) by resqmta-po-08v.sys.comcast.net with ESMTP id mjKLedJHqTLZLmjKTeBSY9; Fri, 16 Feb 2018 16:57:45 +0000 Received: from [172.22.228.216] ([162.210.130.3]) by resomta-po-12v.sys.comcast.net with SMTP id mjIIe4uNYqparmjIKevxTD; Fri, 16 Feb 2018 16:55:43 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Tony Li In-Reply-To: <479c2890-a58f-dbbf-ec33-82528cd218ca@gmail.com> Date: Fri, 16 Feb 2018 08:55:29 -0800 Cc: Richard Roy , Abdussalam Baryun , its@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1F509630-9711-46B2-89B3-4C297DEC08E9@tony.li> References: <151869691215.7607.4477863832246767156.idtracker@ietfa.amsl.com> <02fbd867-9694-e68e-a328-6154d6ead9d9@gmail.com> <7b7949f5-eca6-8b55-1331-0abb3260fdc9@gmail.com> <479c2890-a58f-dbbf-ec33-82528cd218ca@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3445.5.20) X-CMAE-Envelope: MS4wfJ7AglKAzVg0Ps0oYjXscIJCFqUusn6sj86FS+woS736sXfHMuvLVVV5PwX/r+FpOQPPFdv+svg6d6gySbAy0HpFCt0jb6Idh9bBbs6k2k3MulxpZy5d J/DPqq1mnUyjc+t2RXRPGb6NChVIk1gtZ9257Y9wWsl2bYPPOYfNBLDVFhh5Y8duB6+M6U62DIDx/Mi1z32ZO6FBETu5IxJv+B7FefkxU+bGiiU4YH2aylUf kZpoZHqfg/FixO2UHKK4mtVPPNalkrOQbNxVLhY1ixc= Archived-At: Subject: Re: [ipwave] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-17.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: Fri, 16 Feb 2018 16:57:47 -0000 >> "Do they say whether the fragments are IP fragments or not?" >> Of course 802.11 does not say anything about what is being = fragmented. It DOES NOT KNOW! How can it unless it inspects the MSDU, = and 802.11 DOES NOT DO THAT! >=20 > Well 802.11 does inspect the *DU for which it is in charge, and that > contains the EtherType which is 0x86DD which stands for IPv6. >=20 >> Nor does it care! Any reference, especially if it's normative, to >> 802.11 fragmentation should be removed from the draft. >=20 > If we remove that frag text should we also delete de implementation of = it? Yes please. That=E2=80=99s just a fundamental confusion of the word =E2=80=98fragment=E2= =80=99 being used independently by two layers. They should NEVER be tied = together. Tony From nobody Fri Feb 16 09:39:30 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61DB1128959 for ; Fri, 16 Feb 2018 09:39:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 GynmPU8LNMlD for ; Fri, 16 Feb 2018 09:39:27 -0800 (PST) Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::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 56757127876 for ; Fri, 16 Feb 2018 09:39:27 -0800 (PST) Received: by mail-ot0-x22a.google.com with SMTP id q9so3401031oti.0 for ; Fri, 16 Feb 2018 09:39:27 -0800 (PST) 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=GTxkQttzlIPCxfPUUdAMraG6wZ0rX4rgUnDVOwQZhas=; b=srxwFBaKBYgNo8BmEINe076M85+HguYFs+skcvipq78NkjFYCsnjpDnT6tHGIdfPJB APPHihh96wqcZYHjd2r8SYVJRJVP1djWtcdDBl/QsjJtc9g6F5DTSZTqEcRTNQtmabBY 9IKi0d3mzh4sldsfyHYRDMapfONPyklKeXL3evv76XP1i8rpPMy7CxmIJDsPkVLP9fyR RfUQVOAu5GfR3f7l3d917w5wPVuL7SuobcZj9ozisBzWr4jcmImOT2vUOzFHddDaGxqo pRylr9LfriyP+OrbZSS9i2B1QTu7K8PsBAjQNPnmCjt8aBaqqtis9Sn5UGSR2kedIPfS Ri8w== 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=GTxkQttzlIPCxfPUUdAMraG6wZ0rX4rgUnDVOwQZhas=; b=eqFH+H1AeYL8JmGmoA0M9f1OSvIA7XT44qzR8NEPPNsVlFc9n+Ua6Pfnlmr0Xxdl0K w0jIHO/7NRTnRYfjg0LYgkgtrLMpbyvfbpYfi1PeiZa3PlrGPUJhfwmGbEEjiYQi0jpZ BTVLNlD0nced1GL1uyUaA3fjpURYIlJmyd4xj1dlIWe7v1JZ5LlAx/OXkaZsKnP+dM6U 0B8GQFoL1ylyveKuVEKFfWZj3/5boYiPhhuvvvHymJARomdRwvNvNDXNhuQ7Z8gu2K+s Av/a8MNu5wUnQJjlS6TYbqmwjTI9q4IGVRRkkrf6p2tOrSpxKYx4/gtKX91EFJxSrrTp XcZA== X-Gm-Message-State: APf1xPA8dHTADsPv40seCnIPvS0v6MMTbEdSztLjZM1MaUG1stvkmk57 IU+QyHpN5XEg/uuJizpMBAAre9uQ6Tq2sMJzxKo= X-Google-Smtp-Source: AH8x225P+E/VJPwCblcKrYzcHoxH363dmVSiT+i3HnwCgFTqTnXWWJMCWHjP4BG6KIK3EXoqzH6CMLy32lLCLE6P2Hs= X-Received: by 10.157.113.1 with SMTP id n1mr5438427otj.132.1518802766658; Fri, 16 Feb 2018 09:39:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.44 with HTTP; Fri, 16 Feb 2018 09:39:26 -0800 (PST) In-Reply-To: <7b7949f5-eca6-8b55-1331-0abb3260fdc9@gmail.com> References: <151869691215.7607.4477863832246767156.idtracker@ietfa.amsl.com> <02fbd867-9694-e68e-a328-6154d6ead9d9@gmail.com> <7b7949f5-eca6-8b55-1331-0abb3260fdc9@gmail.com> From: Abdussalam Baryun Date: Fri, 16 Feb 2018 19:39:26 +0200 Message-ID: To: Alexandre Petrescu Cc: "its@ietf.org" Content-Type: multipart/alternative; boundary="f403045e853864004b056557d371" Archived-At: Subject: Re: [ipwave] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-17.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: Fri, 16 Feb 2018 17:39:29 -0000 --f403045e853864004b056557d371 Content-Type: text/plain; charset="UTF-8" On Fri, Feb 16, 2018 at 5:45 PM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > > > [...] >> Is the combination of Fragment Number and Sequence Number subfields >> called "Sequence control" by IEEE? >> >> >> >> Yes, as in ieee802.11-2016-std- p646, the sequence control is 2 octets, >> 4 bits only for fragment number and 12 for sequence. >> >> B0 B3 B4 B15 >> >> +-----------------+--------------------------+ >> >> | Fragment number | Sequence number | >> >> +-----------------+--------------------------+ >> >> The sequence number within the Sequence Control field remains the same >> for all fragments, while the fragment number within the Sequence Control >> field increments for each fragment. >> > > Thanks for the explanation. Makes sense. > We always try to make sense or explain reasons so we go forward, > > Do they say whether the fragments are IP fragments or not? > we are discussing IPv6, why we think about other, > > Because in implementation, whenever there is an IP fragment, that fragment > number field is incremented. > ok > > And there seems to be strong opposition we write this. > Why, when was it off list? Just make a decision so we go forward, I don't want us to delay, let us decide together and move on, I agreed with some participant in that we leave the mac functions to it, but I don't say we don't discuss what to write in reasonable engineering way. Yes they oppose that writing text that includes something IP canot do in MAC. I mentioned it is fragment increase by MAC layer, while you posted the question. I seen no opposition to my new text. Furthermore, IMHO, they need to give reasonable reason, or as you said it makes sense, However, we don't forget that this MAC has limited fragmentation numbers so only 16, but IP has more, so we can recommend here. What you think? AB --f403045e853864004b056557d371 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Feb 16, 2018 at 5:45 PM, Alexandre Petrescu &= lt;alexan= dre.petrescu@gmail.com> wrote:


[...]
=C2=A0 =C2=A0 Is the combination of Fragment Number and Sequence Number sub= fields
=C2=A0 =C2=A0 called "Sequence control" by IEEE?



Yes, as in ieee802.11-2016-std- p646, =C2=A0the sequence control is 2 octet= s, 4 bits only for fragment number=C2=A0and 12 for sequence.

B0 =C2=A0 B3=C2=A0=C2=A0=C2=A0B4 =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 B15

+-----------------+--------------------------+

|=C2=A0Fragment number=C2=A0|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Sequence = number=C2=A0=C2=A0 =C2=A0|

+-----------------+--------------------------+

The sequence number within the Sequence Control field remains the same for = all fragments, while the fragment number within the Sequence Control field = increments for each fragment.

Thanks for the explanation.=C2=A0 Makes sense.

We always=C2=A0try to make sense or explain reasons so we go forwar= d,=C2=A0

Do they say whether the fragments are IP fragments or not?
=

we are discussing IPv6, why we think about other,=C2=A0=

Because in implementation, whenever there is an IP fragment, that fragment = number field is incremented.

ok=C2=A0

And there seems to be strong opposition we write this.

Why, when was it off list?

Just ma= ke a decision so we go forward, I don't want us to delay, let us decide= together and move on, I agreed with some participant in that we leave=C2= =A0the mac =C2=A0functions to it, but I don't say we don't discuss = what to write in reasonable engineering way.

Yes t= hey oppose that writing text that includes something IP canot do in MAC.


=C2=A0I mentioned it is=C2=A0 fragmen= t increase by MAC layer, while you posted the question. I seen no oppositio= n to my new text. Furthermore, IMHO, they need to give reasonable reason, o= r as you said it makes sense,

However, we don'= t forget that this MAC has limited fragmentation numbers so only 16, but IP= has more, so we can recommend here.

What you thin= k?

AB
--f403045e853864004b056557d371-- From nobody Fri Feb 16 09:46:23 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA3C127698 for ; Fri, 16 Feb 2018 09:46:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 VyC5lh7le_ew for ; Fri, 16 Feb 2018 09:46:21 -0800 (PST) Received: from resqmta-po-05v.sys.comcast.net (resqmta-po-05v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:164]) (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 6E675124C27 for ; Fri, 16 Feb 2018 09:46:21 -0800 (PST) Received: from resomta-po-20v.sys.comcast.net ([96.114.154.244]) by resqmta-po-05v.sys.comcast.net with ESMTP id mk3yeY9q4AXXjmk5Vet1tK; Fri, 16 Feb 2018 17:46:21 +0000 Received: from [172.22.228.216] ([162.210.130.3]) by resomta-po-20v.sys.comcast.net with SMTP id mk3LestSd7ijLmk3OeLumB; Fri, 16 Feb 2018 17:44:19 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Tony Li In-Reply-To: Date: Fri, 16 Feb 2018 09:44:07 -0800 Cc: Alexandre Petrescu , "its@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <5DEACD7B-7655-45A1-A29C-F6561C2AD937@tony.li> References: <151869691215.7607.4477863832246767156.idtracker@ietfa.amsl.com> <02fbd867-9694-e68e-a328-6154d6ead9d9@gmail.com> <7b7949f5-eca6-8b55-1331-0abb3260fdc9@gmail.com> To: Abdussalam Baryun X-Mailer: Apple Mail (2.3445.5.20) X-CMAE-Envelope: MS4wfIqPR+kTIRFh1o/i2EB2z1zfADfxzGhbx7SJJg166nzKZx80mXRyQHMYF4QwvY4c6mF1ix9xefNpK0lh3CWh4KSs5tQyKJdjP8hyRyzeLYsICTRRl3Ic BR4aVdvq15whsYAKVWmiRnw0v9UEmNGfc0LgZBs79Vl2FSPzogw+hZ084+OcREKSAEgOlgTrmcR9a39keB/Xac1jTEYV93yBc2YcyZuEakwDgH091/hTrC2w CtnIiJ0OSH+XTzDauO4zbA== Archived-At: Subject: Re: [ipwave] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-17.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: Fri, 16 Feb 2018 17:46:23 -0000 > I mentioned it is fragment increase by MAC layer, while you posted = the question. I seen no opposition to my new text. I am opposed to your proposal. You have not fixed the problem. This = document should have NO mention of fragmentation at all. Tony From nobody Fri Feb 16 10:02:46 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4674124C27 for ; Fri, 16 Feb 2018 10:02:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 yOizENReboON for ; Fri, 16 Feb 2018 10:02:43 -0800 (PST) Received: from mail-ot0-x235.google.com (mail-ot0-x235.google.com [IPv6:2607:f8b0:4003:c0f::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DDF71200C1 for ; Fri, 16 Feb 2018 10:02:43 -0800 (PST) Received: by mail-ot0-x235.google.com with SMTP id w38so3452543ota.8 for ; Fri, 16 Feb 2018 10:02:43 -0800 (PST) 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=MZYgccLR9g7rFI/LzxC3hxdkrL8aySVwxEavEHiHBAM=; b=FC6vmZyIlQHFPXP+wJ0Z9wzLLPRzOwaQFWwEbWhN05nnyPTEyQgFDP5ut3D24hYZc9 Env0fPtCuQbjyUuy+jNssiBi0IVJajrxDDJSjWy/HDzXvqN5ulheOoIZEjo2X9KxkEJe gnybwoS2cx8tf8j2th349QUxq4ZgfooH6L5EG5uGJ2zlpL4eZynhUdLcteLXOIH7XpN8 b2ztWYZiV8rfBGSmpKCULULy8/GhHWvM30ar4s5mOlO/5bKbpEmY4/ImwCW2uT/IeBey T9glwlngl5xQdMxtCdQ1QzwM81shiNZTdYRdNo2VNSXBKStBBq5+e50K58ATOQVUZwua NZjQ== 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=MZYgccLR9g7rFI/LzxC3hxdkrL8aySVwxEavEHiHBAM=; b=XFUdWL/FsDk+wv6DyH1BTFjjJYGrx6AaZd/HDtZH82PGbS+N0NnBa+8opAvDkFffFM JNFGmFF9SGHTLVBVFFolJ6XIDSqA5k40wnbTAV15Z4cU4qKccqmKqkrzjm1mg+y5kTqA wvoR/UGDoVNtP6RQArcbehKJG1py/9gEAUG460eKjOCL5jL5DCLBYxffpJgzzICBY34d TC6RGi4kENS1b6hcl4A8fKAGKhLOpBzWycTm6SWc8yjzlXIr8buO2JQ5tnQfbdmclZs6 CSlK8lLumqv1ulsDiMQipvUNLcP2h6TM7RYexH9YJhkEPxSX4apDje1dGLdYbY3rZqHm +5UA== X-Gm-Message-State: APf1xPCUR5wD6RfLrq8w1afPo23va4hw72AZC+VMlSqxKrhfHBpSttIh zE+Q9PmIcjWsf22UO0CGF9VHpMK+MXkGipE4oEg= X-Google-Smtp-Source: AH8x226x26vVdszPS9HRDc+UNBA3Yx6AGafkkQOOvnxv1Pu7aG+pjVtvfPnWonaw3fSXNgHnc2RqddVrpLvKPtDZfGI= X-Received: by 10.157.48.65 with SMTP id w1mr5346841otd.391.1518804162103; Fri, 16 Feb 2018 10:02:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.44 with HTTP; Fri, 16 Feb 2018 10:02:41 -0800 (PST) In-Reply-To: References: <151869691215.7607.4477863832246767156.idtracker@ietfa.amsl.com> <02fbd867-9694-e68e-a328-6154d6ead9d9@gmail.com> <7b7949f5-eca6-8b55-1331-0abb3260fdc9@gmail.com> From: Abdussalam Baryun Date: Fri, 16 Feb 2018 20:02:41 +0200 Message-ID: To: Richard Roy Cc: its Content-Type: multipart/alternative; boundary="001a11352f5490d552056558263f" Archived-At: Subject: Re: [ipwave] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-17.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: Fri, 16 Feb 2018 18:02:46 -0000 --001a11352f5490d552056558263f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Feb 16, 2018 at 6:20 PM, Dick Roy wrote: > "Do they say whether the fragments are IP fragments or not?" > > Of course 802.11 does not say anything about what is being fragmented. I= t > DOES NOT KNOW! How can it unless it inspects the MSDU, and 802.11 DOES N= OT > DO THAT! Nor does it care! it should care to do it job, better service to upper layers, > Any reference, especially if it's normative, to > 802.11 fragmentation should be removed from the draft. > we are saying if IPv6 fragments transmitted on ieee802.11, we don't care about mac but about best practice for IPv6 transmission on such media (I will not say careless media but wireless ). AB > > RR > > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu > Sent: Friday, February 16, 2018 7:46 AM > To: Abdussalam Baryun > Cc: its@ietf.org > Subject: Re: [ipwave] Fwd: New Version Notification for > draft-ietf-ipwave-ipv6-over-80211ocb-17.txt > > > > Le 16/02/2018 =C3=A0 16:42, Abdussalam Baryun a =C3=A9crit : > > > > > > On Fri, Feb 16, 2018 at 1:03 PM, Alexandre Petrescu > > > > wrote: > > > > > > > > Le 16/02/2018 =C3=A0 11:46, Abdussalam Baryun a =C3=A9crit : > > > > > > > > On Thu, Feb 15, 2018 at 2:19 PM, Alexandre Petrescu > > > > > > >> wrote: > > > > Hi IPWAVErs, > > > > I submitted a new version of the IPv6-over-OCB draft - the > > 17th. > > > > The ChangeLog is: > > > > Susbtituted "MUST be increased" to "is increased" > > in the > > MTU section, about fragmentation. > > > > The phrases in question are: > > > > NEW: > > > > If IPv6 packets > > of size larger than > > 1500 bytes are sent on an 802.11-OCB interface car= d > > then the IP stack > > MUST fragment. In case there are IP fragments, th= e > > field "Sequence > > number" of the 802.11 Data header containing the I= P > > fragment field is > > increased. > > > > > > Replace last sentence above> > > > > In case there are IP fragments, the subfield fragment number > > within the field "Sequence > > control" of The 802.11 data header containing the IP > > fragment is increased by MAC layer. > > > > > > Is the combination of Fragment Number and Sequence Number subfields > > called "Sequence control" by IEEE? > > > > > > > > Yes, as in ieee802.11-2016-std- p646, the sequence control is 2 octets= , > > 4 bits only for fragment number and 12 for sequence. > > > > B0 B3 B4 B15 > > > > +-----------------+--------------------------+ > > > > | Fragment number | Sequence number | > > > > +-----------------+--------------------------+ > > > > The sequence number within the Sequence Control field remains the same > > for all fragments, while the fragment number within the Sequence Contro= l > > field increments for each fragment. > > Thanks for the explanation. Makes sense. > > Do they say whether the fragments are IP fragments or not? > > Because in implementation, whenever there is an IP fragment, that > fragment number field is incremented. > > And there seems to be strong opposition we write this. > > Alex > > > > > > AB > > > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > --001a11352f5490d552056558263f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Feb 16, 2018 at 6:20 PM, Dick Roy <dickroy@alum.mit.edu= > wrote:
"Do they say whether the = fragments are IP fragments or not?"

Of course 802.11 does not say anything about what is being fragmente= d.=C2=A0 It
DOES NOT KNOW!=C2=A0 How can it unless it inspects the MSDU, and 802.11 DOE= S NOT
DO THAT! Nor does it care!

it should care t= o do it job, better service to upper layers,
=C2=A0
Any reference, especially if it's normative, to
802.11 fragmentation should be removed from the draft.

we are saying if IPv6 fragments transmitted on ieee802.11, = we don't care about mac but about best practice for IPv6 transmission o= n such media (I will not say careless media but wireless ).

<= /div>
AB=C2=A0=C2=A0

RR

-----Original Message-----
From: its [mailto:its-bounces@ietf.= org] On Behalf Of Alexandre Petrescu
Sent: Friday, February 16, 2018 7:46 AM
To: Abdussalam Baryun
Cc: its@ietf.org
Subject: Re: [ipwave] Fwd: New Version Not= ification for
draft-ietf-ipwave-ipv6-over-80211ocb-17.txt



Le 16/02/2018 =C3=A0 16:42, = Abdussalam Baryun a =C3=A9crit=C2=A0:
>
>
> On Fri, Feb 16, 2018 at 1:03 PM, Alexandre Petrescu
> <alexandre.petrescu= @gmail.com <mailto:a= lexandre.petrescu@gmail.com>>
wrote:
>
>
>
>=C2=A0 =C2=A0 =C2=A0Le 16/02/2018 =C3=A0 11:46, Abdussalam Baryun a =C3= =A9crit=C2=A0:
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Thu, Feb 15, 2018 at 2:19 PM, Alex= andre Petrescu
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<alexandre.petrescu@gmail.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:alexandre.petrescu@gmail.com>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:alexandre.petrescu@gmail.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:alexandre.petrescu@gmail.com>>> wro= te:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi IPWAVErs,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I submitted a new vers= ion of the IPv6-over-OCB draft - the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A017th.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The ChangeLog is:
>
>=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 Susbtituted "MUST be increased" to "i= s increased"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in the
>=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 MTU section, about fragmentation.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The phrases in questio= n are:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 NEW:
>
>=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 If IPv6 packets
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of size larger than
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 1500 bytes are sent on an 802.11-OCB interface card
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0then the IP stack
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 MUST fragment.=C2=A0 In case there are IP fragments, the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0field "Sequence >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 number" of the 802.11 Data header containing the IP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0fragment field is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 increased.
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Replace last sentence above>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In case there are IP fragments, the s= ubfield fragment number
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0within the field "Sequence
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0 control" of = The 802.11 data header containing the IP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0fragment is increased by MAC layer. >
>
>=C2=A0 =C2=A0 =C2=A0Is the combination of Fragment Number and Sequence = Number subfields
>=C2=A0 =C2=A0 =C2=A0called "Sequence control" by IEEE?
>
>
>
> Yes, as in ieee802.11-2016-std- p646, =C2=A0the sequence control is 2 = octets,
> 4 bits only for fragment number=C2=A0and 12 for sequence.
>
> B0 =C2=A0 B3=C2=A0=C2=A0=C2=A0B4 =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 B15
>
> +-----------------+--------------------------+
>
> |=C2=A0Fragment number=C2=A0|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Sequ= ence number=C2=A0=C2=A0 =C2=A0|
>
> +-----------------+--------------------------+
>
> The sequence number within the Sequence Control field remains the same=
> for all fragments, while the fragment number within the Sequence Contr= ol
> field increments for each fragment.

Thanks for the explanation.=C2=A0 Makes sense.

Do they say whether the fragments are IP fragments or not?

Because in implementation, whenever there is an IP fragment, that
fragment number field is incremented.

And there seems to be strong opposition we write this.

Alex
>
>
> AB
>
>

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


--001a11352f5490d552056558263f-- From nobody Mon Feb 19 06:08:12 2018 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 7A4231242F7; Mon, 19 Feb 2018 06:08:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: its@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151904928641.18763.16352596992811069572@ietfa.amsl.com> Date: Mon, 19 Feb 2018 06:08:06 -0800 Archived-At: Subject: [ipwave] I-D Action: draft-ietf-ipwave-ipv6-over-80211ocb-18.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: Mon, 19 Feb 2018 14:08:07 -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 Jerome Haerri Jong-Hyouk Lee Thierry Ernst Filename : draft-ietf-ipwave-ipv6-over-80211ocb-18.txt Pages : 39 Date : 2018-02-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. 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-18 https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-18 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 Mon Feb 19 06:11:53 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D707912762F for ; Mon, 19 Feb 2018 06:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34xWyrEsGsbM for ; Mon, 19 Feb 2018 06:11:48 -0800 (PST) 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 CBE991242F7 for ; Mon, 19 Feb 2018 06:11:47 -0800 (PST) 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 w1JEBjed107856 for ; Mon, 19 Feb 2018 15:11:45 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id EEECD203F5B for ; Mon, 19 Feb 2018 15:11:44 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id E1614203F59 for ; Mon, 19 Feb 2018 15:11:44 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w1JEBieN009203 for ; Mon, 19 Feb 2018 15:11:44 +0100 References: <151904928675.18763.3200006360258384244.idtracker@ietfa.amsl.com> To: "its@ietf.org" From: Alexandre PETRESCU Organization: CEA X-Forwarded-Message-Id: <151904928675.18763.3200006360258384244.idtracker@ietfa.amsl.com> Message-ID: Date: Mon, 19 Feb 2018 15:11:44 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <151904928675.18763.3200006360258384244.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070404030106030406070102" Archived-At: Subject: [ipwave] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-18.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, 19 Feb 2018 14:11:51 -0000 This is a cryptographically signed message in MIME format. --------------ms070404030106030406070102 Content-Type: multipart/alternative; boundary="------------C706094DFAA82862E93C21A2" Content-Language: fr This is a multi-part message in MIME format. --------------C706094DFAA82862E93C21A2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi IPWAVErs, We submitted a new version of the IPv6-over-OCB draft. This is the ChangeLog: > =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 Improved the MTU and fragmentatio= n paragraph. This is what the paragraph is now: > =C2=A0If IPv6 packets of size larger than > =C2=A0=C2=A0 the MTU are sent on an 802.11-OCB interface card then the = IP stack > =C2=A0=C2=A0 MUST fragment.=C2=A0 In case there are IPv6 fragments, the= subfield > =C2=A0=C2=A0 "Fragment number" within the field "Sequence control" of t= he 802.11 > =C2=A0=C2=A0 Data header containing the IPv6 fragment is increased by t= he MAC > =C2=A0=C2=A0 layer. Alex -------- Message transf=C3=A9r=C3=A9 -------- Sujet=C2=A0: New Version Notification for=20 draft-ietf-ipwave-ipv6-over-80211ocb-18.txt Date=C2=A0: Mon, 19 Feb 2018 06:08:06 -0800 De=C2=A0: internet-drafts@ietf.org Pour=C2=A0: Jerome Haerri ,=20 ipwave-chairs@ietf.org, Jerome Haerri ,=20 Alexandre Petrescu , Alexandre Petrescu=20 , Nabil Benamar ,=20 Thierry Ernst , Jong-Hyouk Lee=20 A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-18.txt has been successfully submitted by Alexandre Petrescu and posted to the IETF repository. Name: draft-ietf-ipwave-ipv6-over-80211ocb Revision: 18 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: 2018-02-19 Group: ipwave Pages: 39 URL: https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ip= v6-over-80211ocb-18.txt Status: https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-o= ver-80211ocb/ Htmlized: https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-8= 0211ocb-18 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-i= pv6-over-80211ocb-18 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipwave-ipv= 6-over-80211ocb-18 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. = =20 Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------C706094DFAA82862E93C21A2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi IPWAVErs,

We submitted a new version of the IPv6-over-OCB draft.

This is the ChangeLog= :

=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0= Improved the MTU and fragmentation paragraph.

This is what the paragraph is now:

=C2=A0If IPv6 packets of size larger = than
=C2=A0=C2=A0 the MTU are sent on an 802.11-OCB interface card= then the IP stack
=C2=A0=C2=A0 MUST fragment.=C2=A0 In case there are IPv6 frag= ments, the subfield
=C2=A0=C2=A0 "Fragment number" within the field "Sequence con= trol" of the 802.11
=C2=A0=C2=A0 Data header containing the IPv6 fragment is incr= eased by the MAC
=C2=A0=C2=A0 layer.

Alex




-------- Message transf=C3=A9r=C3=A9 --------
Suj= et=C2=A0: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-18.txt
Dat= e=C2=A0: Mon, 19 Feb 2018 06:08:06 -0800
De=C2= =A0: internet-drafts@ietf.org
Pou= r=C2=A0: Jerome Haerri <Jerome.Haerri@eurecom.fr>, ipwave-chairs@ietf.org, Jerome Haerri <jerome.haerri@eurecom.fr>, Alexandre Petrescu= <Alexandre.Petrescu@cea.fr>, Alexandre Petr= escu <alexandre.petrescu@cea.fr>, Nabil Benamar <n.benamar@est.umi.ac.ma>, Thierry Ernst <thierry.ernst@yogoko.fr>, Jong-Hyouk Lee <jonghyouk@smu.ac.kr> 


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

Name:		draft-ietf-ipwave-ipv6-over-80211ocb
Revision:	18
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:	2018-02-19
Group:		ipwave
Pages:		39
URL:            https=
://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-18.t=
xt
Status:         https://datatra=
cker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/
Htmlized:       https://tools.ietf=
=2Eorg/html/draft-ietf-ipwave-ipv6-over-80211ocb-18
Htmlized:       https://=
datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-18=

Diff:           https://ww=
w.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipwave-ipv6-over-80211ocb-18

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.

                                                                         =
        =20


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

The IETF Secretariat
--------------C706094DFAA82862E93C21A2-- --------------ms070404030106030406070102 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 C2AwggWCMIIEaqADAgECAgIYEjANBgkqhkiG9w0BAQsFADA9MQswCQYDVQQGEwJGUjEMMAoG A1UECgwDQ0VBMSAwHgYDVQQDDBdDRUEgQUMgVXRpbGlzYXRldXIgMjAzMTAeFw0xNzExMjcx MTUzMThaFw0yMDExMjcxMTUzMThaMFUxCzAJBgNVBAYTAkZSMQwwCgYDVQQKDANjZWExFDAS BgNVBAsMC1V0aWxpc2F0ZXVyMSIwIAYDVQQDDBlQRVRSRVNDVSBBbGV4YW5kcmUgMjIyMDQw MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxflZNm4uFO1gfpGFsdm8+ijK5FnS fr24rrT8KW0oz8cV8u+UZ55M/bqidvqSXGGz3C480T6DZsfXoTsvqD5ZLE+F8II6J2g5NU8J mKX95WafZuQo8DC2EnkDu2jH0kU58PGyJqzlQ1ThJw+E90C4yg55q5ekRRv13L7W4D38+eO6 2LLQyplKiyjXJRFnrYPCQWKdmaoa3+gXm88N0z9SH1VnKDB7nN0WKcgkB8xFFW9ShkDriTj4 WOtBlX5I49L6nc2f5jgRR7ur63vWwWV57guJDYgdbciTIMsoanyOMkblfZko71HlcYOQcext cIzx7W14tLdo5Lbk5sbTLTPCUwIDAQABo4ICcjCCAm4wHQYDVR0OBBYEFJiCut4KQg9+Gt1J iu2nte1qatj0MB8GA1UdIwQYMBaAFOEcbJodbegbsvFP/cZ0LCdXBYhzMIHIBgNVHSAEgcAw gb0wgboGCisGAQQB4GABBgcwgaswJQYIKwYBBQUHAgEWGWh0dHA6Ly93d3ctaWdjLmNlYS5m ci9wYy8wgYEGCCsGAQUFBwICMHUwDRYDQ0VBMAYCAQICAQAaZFZvdXMgZGV2ZXogYWNjZXB0 ZXIgbGEgcG9saXRpcXVlIGRlIGNlcnRpZmljYXRpb24gYXZhbnQgZCd1dGlsaXNlciBjZSBj ZXJ0aWZpY2F0LCBjZi4gd3d3LWlnYy5jZWEuZnIwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAkBgNVHREEHTAbgRlhbGV4YW5kcmUucGV0cmVzY3VAY2VhLmZyMFEGA1Ud HwRKMEgwRqBEoEKGQGh0dHA6Ly9jcmwtYWMtdXRpbGlzYXRldXIuY2VhLmZyL2NybC9jZWFf YWNfdXRpbGlzYXRldXJfMjAzMS5jcmwwcwYJYIZIAYb4QgENBGYWZFZvdXMgZGV2ZXogYWNj ZXB0ZXIgbGEgcG9saXRpcXVlIGRlIGNlcnRpZmljYXRpb24gYXZhbnQgZCd1dGlsaXNlciBj ZSBjZXJ0aWZpY2F0LCBjZi4gd3d3LWlnYy5jZWEuZnIwUAYIKwYBBQUHAQEERDBCMEAGCCsG AQUFBzAChjRodHRwOi8vd3d3LWlnYy5jZWEuZnIvYWMvY2VhX2FjX3V0aWxpc2F0ZXVyXzIw MzEuY2VyMA0GCSqGSIb3DQEBCwUAA4IBAQC77Z707Ko1uZGK3utBHUQUUyTD4pRjmFxFozU2 kwdk6a8hdHTaaRqjPSUIbfeoZVpZCynd12VynalWcoXM40Bf+bhMN3pAavULka7+oAEQyYuI 7OQ8dE/t3R43Ai8dx0npk+ziPQrlD7tAgMsK8Qd+V7ZhUI0A1ANJXWzZ7DYV6jR4t9nwxlsk Kll2PaD+hTIiP86YVsiHMiu0ZhRGrYJf/U1myMQc28b4LdTofpwh22z8DLHlFoGjGipwYbpb oFn998AOsc2fvujB0Y+AahlKK8lecqOTXJNQaRUrE1dl/n2Xu8GK3KIRtcoo7QTDOTzx/BiN 5EC8XdsqNMRXmc1GMIIF1jCCA76gAwIBAgIBCTANBgkqhkiG9w0BAQsFADBeMQswCQYDVQQG EwJGUjEMMAoGA1UECgwDQ0VBMRcwFQYDVQQLDA4wMDAyIDc3NTY4NTAxOTELMAkGA1UECwwC QUMxGzAZBgNVBAMMEkNFQSBBQyBSYWNpbmUgMjA0MTAeFw0xNjA0MTkwNzM0NTNaFw0zMTA0 MTYwNzM0NTNaMD0xCzAJBgNVBAYTAkZSMQwwCgYDVQQKDANDRUExIDAeBgNVBAMMF0NFQSBB QyBVdGlsaXNhdGV1ciAyMDMxMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvWDF ixM71KL9p38YSLTYgXRTceZWAD0RSg7NylBGPXNHYbceuGKDhRIeX58FIi+JiVFFejFI6jpE impm3MgsXQ5O08clieLLBNCjVzpAMPTO5lXuz0j28ey5AVPwhEw7ngUCtmHaWh8v1eY6xrLV C/porFjHycFbd4oj6QLfyghoo/RXWglYPNjilkCBrRe+jKxM3QYYVD6rouvGrF58SlpGCfwX FA88OcYC24kH8YOOYvh8Ld/p+ty7QUiDq53YmVZ5iDUc3pt3r9pN61zJ83FPEhZbC8+KHDTb D0TXaot2No4u8wk0s0jBpicVN4hxfS+LiFcTsFmsorDW6L7GIwIDAQABo4IBvjCCAbowDwYD VR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQU4Rxsmh1t6Buy8U/9xnQsJ1cFiHMwHwYDVR0jBBgw FoAUoBGJ+Jq/poSxKQc3U0Htl5VCex0wgcgGA1UdIASBwDCBvTCBugYKKwYBBAHgYAEGBzCB qzAlBggrBgEFBQcCARYZaHR0cDovL3d3dy1pZ2MuY2VhLmZyL3BjLzCBgQYIKwYBBQUHAgIw dTANFgNDRUEwBgIBAgIBABpkVm91cyBkZXZleiBhY2NlcHRlciBsYSBwb2xpdGlxdWUgZGUg Y2VydGlmaWNhdGlvbiBhdmFudCBkJ3V0aWxpc2VyIGNlIGNlcnRpZmljYXQsIGNmLiB3d3ct aWdjLmNlYS5mcjAOBgNVHQ8BAf8EBAMCAQYwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2Ny bC1hYy1yYWNpbmUuY2VhLmZyL2NybC9hYy1yYWNpbmUtMjA0MS5jcmwwRwYIKwYBBQUHAQEE OzA5MDcGCCsGAQUFBzAChitodHRwOi8vd3d3LWlnYy5jZWEuZnIvYWMvYWMtcmFjaW5lLTIw NDEuY2VyMA0GCSqGSIb3DQEBCwUAA4ICAQALtUqrZEfol/oEtIOlM3SaHCPHblVt8TdY88IB 3qCpg5lJ8rWU7g8jAsc0moYYor0hrvb17XjXECYL76MOJBCQYEKfWnkTYqAyMTsKee+kK8Xw 5P8wzPPjXA3tUvRm8oHEGYcSfLEzdj+UT+F+E4MnkV1nUOCEJq2Krx+lu1IJQJRCbjUQF+ES ICwTDQE7FHzGGKVsGOEjkbYhDS/+4r5GPbc983y5d94S0ISYmM1klOSeRNGelcnl0fJbH0zs 1y8+YJWg3gWL1j7aNo+sQQCrPrYQnmufAm3HQr42+u0AbFvOX5XKwF1YAx7XpJWuUGeXkjqx 8xIWisShEc/S+Gm4mdKcUgym5C7gkA0nzbmBIJI3iSLRqk/m2Re7R5vC3fF3uyfT9mGeAnNa E9b7ZkBzhrSfFToylbvqnAYvxVcYFCE1XhVMHxKvRiiW9L/u9vHuAbTRaXBFzObrXF6UohLR XNqJKKaPYkRLgrVm6b303Ogp50u6DiSgvI4Dh7x9K9IqpJ/+csqdXpoVdhQjhcA5JZRNrv3q 0zVf/Q93GT3VHOgaeMkEa9Sn30x4GmZfuNon/zSagJZkLO72K3wa6XQbGf8MZP/QtSMGPzrN eVUgp4H6l9hcQINVHmimTrcZa7/22K0FD56epY/OqAXwIWOb9i+jdDIoW5c5pW+/BDDasTGC AvMwggLvAgEBMEMwPTELMAkGA1UEBhMCRlIxDDAKBgNVBAoMA0NFQTEgMB4GA1UEAwwXQ0VB IEFDIFV0aWxpc2F0ZXVyIDIwMzECAhgSMA0GCWCGSAFlAwQCAQUAoIIBgTAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODAyMTkxNDExNDRaMC8GCSqGSIb3 DQEJBDEiBCBnpVrdkfDjrscnBpBEfALr8qF27AocxX/50JoGWIRWWjBSBgkrBgEEAYI3EAQx RTBDMD0xCzAJBgNVBAYTAkZSMQwwCgYDVQQKDANDRUExIDAeBgNVBAMMF0NFQSBBQyBVdGls aXNhdGV1ciAyMDMxAgIYEjBUBgsqhkiG9w0BCRACCzFFoEMwPTELMAkGA1UEBhMCRlIxDDAK BgNVBAoMA0NFQTEgMB4GA1UEAwwXQ0VBIEFDIFV0aWxpc2F0ZXVyIDIwMzECAhgSMGwGCSqG SIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJ KoZIhvcNAQEBBQAEggEAuqn+ZF1VGO+F1fgTWNBbypOb2tbjN5i0wceGjDCGPKJtNDUxTUhn uHqndf/V7U5XaXnY4jFQXMSYyfbwh6doPte1TnvCZLHQQ56w4XWWZ+2GlGJMZ28llxcPivwR dJ9w5B9ct8+7WR6bBZU3+Ug7eteCr/SXWDqVo5CNFzBWTpUjd+2tXOuCWtWGMAdc05rG7JSR Yk08aEko99ee9AwW82u08PuefaIr291rGX84qkZKAQd1BP4yoRTSs+bNjAZvgJ2xmXPX5JQo KokWVlopNa4MGHJcQFuRhj6/pwUhNZt/MDY5xsc/0Duw1/lvGTYFKdL6S4y3BselF7yqg04I RgAAAAAAAA== --------------ms070404030106030406070102-- From nobody Mon Feb 19 06:18:22 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F38DD1277BB for ; Mon, 19 Feb 2018 06:18:20 -0800 (PST) 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 2jYRi7hfwFaL for ; Mon, 19 Feb 2018 06:18:19 -0800 (PST) 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 47CA9127775 for ; Mon, 19 Feb 2018 06:18:19 -0800 (PST) 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 w1JEIEug110086; Mon, 19 Feb 2018 15:18:14 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 22D7B203E71; Mon, 19 Feb 2018 15:18:14 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 13832203E43; Mon, 19 Feb 2018 15:18:14 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w1JEID1K013263; Mon, 19 Feb 2018 15:18:13 +0100 To: dickroy@alum.mit.edu, "'Abdussalam Baryun'" Cc: its@ietf.org References: <151869691215.7607.4477863832246767156.idtracker@ietfa.amsl.com> <02fbd867-9694-e68e-a328-6154d6ead9d9@gmail.com> <7b7949f5-eca6-8b55-1331-0abb3260fdc9@gmail.com> <479c2890-a58f-dbbf-ec33-82528cd218ca@gmail.com> From: Alexandre Petrescu Message-ID: Date: Mon, 19 Feb 2018 15:18:13 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.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] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-17.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, 19 Feb 2018 14:18:21 -0000 Le 16/02/2018 à 19:26, Dick Roy a écrit : > > > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu > Sent: Friday, February 16, 2018 8:53 AM > To: dickroy@alum.mit.edu; 'Abdussalam Baryun' > Cc: its@ietf.org > Subject: Re: [ipwave] Fwd: New Version Notification for > draft-ietf-ipwave-ipv6-over-80211ocb-17.txt > > > > Le 16/02/2018 à 17:20, Dick Roy a écrit : >> "Do they say whether the fragments are IP fragments or not?" >> >> Of course 802.11 does not say anything about what is being >> fragmented. It DOES NOT KNOW! How can it unless it inspects the >> MSDU, and 802.11 DOES NOT DO THAT! > > Well 802.11 does inspect the *DU for which it is in charge, and that > contains the EtherType which is 0x86DD which stands for IPv6. > [RR] It ONLY does that on a DL_Unitdata.indication, NOT on a .request. Yes, and the .indication could contain an IPv6 data packet that has a an IPv6 Extension header titled Fragment. The MAC layer could have found that header, or maybe it was indicated by some other instruction in the same computer that this data structure to become a packet is an IP fragment. > Indications go up the stack, requests go down! > >> Nor does it care! Any reference, especially if it's normative, to >> 802.11 fragmentation should be removed from the draft. > > If we remove that frag text should we also delete de implementation of it? > [RR] Absolutely! Well, but that is hard to achieve, because there are many implementations. That said. If there is nobody in need of this fragmentation aspect (the IP fragment is preceded by a fragment indication in the MAC header) then maybe we could be silent about it, and remove that sentence which tells what MAC does. It is not normative text, it is just observation. Alex From nobody Mon Feb 19 07:51:45 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 887FE1205F0 for ; Mon, 19 Feb 2018 07:51:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 YfFSYJiadUbh for ; Mon, 19 Feb 2018 07:51:42 -0800 (PST) Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (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 E608F127873 for ; Mon, 19 Feb 2018 07:51:41 -0800 (PST) Received: from resomta-po-01v.sys.comcast.net ([96.114.154.225]) by resqmta-po-03v.sys.comcast.net with ESMTP id nniqeJi2806N1nnjBe65qG; Mon, 19 Feb 2018 15:51:41 +0000 Received: from [192.168.1.6] ([24.130.209.5]) by resomta-po-01v.sys.comcast.net with SMTP id nnj9eqPVwBeQjnnjAeLzmd; Mon, 19 Feb 2018 15:51:41 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Tony Li In-Reply-To: Date: Mon, 19 Feb 2018 07:51:39 -0800 Cc: Richard Roy , Abdussalam Baryun , its@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <858E8682-DD3B-403C-8331-14CF36CA050A@tony.li> References: <151869691215.7607.4477863832246767156.idtracker@ietfa.amsl.com> <02fbd867-9694-e68e-a328-6154d6ead9d9@gmail.com> <7b7949f5-eca6-8b55-1331-0abb3260fdc9@gmail.com> <479c2890-a58f-dbbf-ec33-82528cd218ca@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3445.5.20) X-CMAE-Envelope: MS4wfDxzaCuWQVyaGRE4aaGwqlyq7UltGyjQluNSzLBVm5BcpFJWCox3fyGk3CySfBax51kOBgn3pz3t0Ypmes8ZZ/Pjmlowf3HbFs6HAx7/A6naUNYlh9+i fgIRT54IWuzHUTXsmZ04/zbA2QBrWzxMujBrwNLPLiUv9OSGby96hrJZ8vU8vYh/h45qe47I1BiKyNn+vI9DTEWBCyqOoOPId4aR22HivHT9IItbAYvXC0O9 6TULQpFVIg9GpeX3l2gwGxKKguBTGFuAIh3BBrYy5EQ= Archived-At: Subject: Re: [ipwave] New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-17.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, 19 Feb 2018 15:51:44 -0000 > The MAC layer could have found that header, or maybe it was indicated = by some other instruction in the same computer that this data structure = to become a packet is an IP fragment. Think about that. The MAC layer could look inside the IPv6 packet. = Parse it. Look for an extension header. Skip past the Hop-by-Hop Options = header, Destination Options header, and Routing header. And only then = realize that it has a Fragment Header. > If there is nobody in need of this fragmentation aspect (the IP = fragment is preceded by a fragment indication in the MAC header) then = maybe we could be silent about it, and remove that sentence which tells = what MAC does. It is not normative text, it is just observation. The text as written is ambiguous and will lead to inconsistent = implementations. Because you have not used normative RFC 2119 language, = some people will ignore it. However, some people will take a natural = language English implementation and implement it. Worse yet, experienced implementors will look at the spec and question = the sanity of it. Tony From nobody Tue Feb 20 10:08:50 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBF512D943 for ; Tue, 20 Feb 2018 10:08:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 hFVAPKjY_Afx for ; Tue, 20 Feb 2018 10:08:46 -0800 (PST) Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002: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 9B09A126D0C for ; Tue, 20 Feb 2018 10:08:46 -0800 (PST) Received: by mail-yb0-x231.google.com with SMTP id b12-v6so597814ybn.8 for ; Tue, 20 Feb 2018 10:08:46 -0800 (PST) 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=TmjZt6Z0UZTK0QPzwkV83kByo1IHqN13zGADvWdOr68=; b=iYpsstoGDsWhm63SRZC2dRDjibqDoav5M4k/9csoChjX09sRpRE+NSl3vuAPh3WdP+ ZDnM7mlSYEfA3n0/4USPQYi4x/yyfngCJCaC4oajhN/GmDgw6D9YxPcRBGBHtD00EC6w iEmNUf4wGvgV5yAh6UBZWkx45Tnp+mU4OM+CFgcPY0YE3TRCfioPC1yRvgjfLgLRSh+X DK7sR/R39L4m9pzdqVqHV2beuISIsaw6HcZsW+Ke4tnEArk+tOKXbggkxGlbO1r2SUAO fKTXkz3o4fs7kpIFWOBT9bfBSTxDhyMjmrTlQ1UrRax5huncelTon2Z8fiypcHfAWkHK WWdw== 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=TmjZt6Z0UZTK0QPzwkV83kByo1IHqN13zGADvWdOr68=; b=UxV5Nfv+oszxzo3LL7ck7LO7M5qzPsfvn53QTzvb4xqLaeY+DWDZhJjZF0fJQSdDQZ cw7g11XRG9o5q+ldPutVjDhbLeHdM14q5gN7GD2I/THWzs+gC0+8L9Lvga5IaHB1e03b EDSp4IuBiwJtYheDlagJ6rNKeSQF+dizyAjZGSuYjifOKdoPp4PkCY00dkwuOl4iGSh4 5Ht4ukJCTFpF64XTqAhvED7DIcvUwkAHLgJBuH7jIIsUNDg1KGpQ+0W5/YisDD321Kac 90lIpDDkqmQz3hXhSlKx9BFbzwDSDnU3UU301VD5ojeb8HHPGsHmfbo6LLC4Tz3zhC9i jC/w== X-Gm-Message-State: APf1xPCcenZIRCFTN6Se2FOtNFPc7y41JD1KEmpVZxiGs1SoCFeRAPAK /4/jy8z5YShdq4/e9hVNER1zNjitAn+MskN7Dxg= X-Google-Smtp-Source: AH8x226qyTBLIzIWurj+BmjoJdIS+et0p/edjxhAGKroatfA1ZjnR/RZ1n1blQYytJBlONsRfc6jDLNwXQfYQfhjjtU= X-Received: by 2002:a25:f607:: with SMTP id t7-v6mr491025ybd.124.1519150125536; Tue, 20 Feb 2018 10:08:45 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a25:b942:0:0:0:0:0 with HTTP; Tue, 20 Feb 2018 10:08:45 -0800 (PST) In-Reply-To: <1516789512.9922.18.camel@it.uc3m.es> References: <1516789512.9922.18.camel@it.uc3m.es> From: Michelle Wetterwald Date: Tue, 20 Feb 2018 19:08:45 +0100 Message-ID: To: cjbc@it.uc3m.es Cc: "its@ietf.org" , Russ Housley Content-Type: multipart/alternative; boundary="00000000000097dc320565a8b3b6" Archived-At: Subject: Re: [ipwave] Rechartering 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, 20 Feb 2018 18:08:48 -0000 --00000000000097dc320565a8b3b6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Carlos, all I have just been popping out of a few days away from this list and found nice discussions... Regarding the re-chartering, we agreed in Singapore that the need for a vehicular service-specific multicast address would be re-discussed at a later step. It may be the right time now to consider it again, and include it as a study topic for the updated charter. Best regards, Michelle 2018-01-24 11:25 GMT+01:00 Carlos Jes=C3=BAs Bernardos Cano : > Hi, > > Now that our first document is close to be shipped to the IESG for IETF > LC, the chairs and AD are starting to plan on potential rechartering > (as we anticipated in Singapore). > > There are a number of things people have discussed in the past, > including the time of the BoFs. Now it is time to bring in the > ideas and suggest them on the mailing list. > > Please, keep in mind some important considerations/constraints: > > - We will schedule time on the f2f session in London for rechartering > discussion, _only if_ discussion has taken place on the mailing list. > So please, do not wait for the call for presentations during the > meeting to propose topics. > > - Our current charter includes a "Problem Statement" item, which is > addressed in the document draft-ietf-ipwave-vehicular-networking. > Obviously, potential topics for rechartering should be covered there > (it will not make sense to work on topics that the community has not > agreed to be important and remain unsolved). > > - A rechartering process will always take into account the energy level > of the WG and the completion level of the current milestones. This > means that we need to finish (submit to the IESG) our 2 documents > before we actually start working on the new topics. > > Please, share your thoughts on the mailing list! > > Thanks, > > Carlos and Russs > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > --=20 Michelle Wetterwald michelle.wetterwald@gmail.com --00000000000097dc320565a8b3b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Carlos, all

I have just b= een popping out of a few days away from this list and found nice discussion= s...

Regarding the re-chartering, we agreed in Sin= gapore that the need for a vehicular service-specific multicast address wou= ld be re-discussed at a later step.
It may be the right time now = to=C2=A0consider it again, and include it as a study topic for the updated = charter.

Best regards,
Michelle


2018= -01-24 11:25 GMT+01:00 Carlos Jes=C3=BAs Bernardos Cano &= lt;cjbc@it.uc3m.es= >:
Hi,

Now that our first document is close to be shipped to the IESG for IETF
LC, the chairs and AD are starting to plan on potential rechartering
(as we anticipated in Singapore).

There are a number of things people have discussed in the past,
including the time of the BoFs. Now it is time to bring in the
ideas and suggest them on the mailing list.

Please, keep in mind some important considerations/constraints:

- We will schedule time on the f2f session in London for rechartering
discussion, _only if_ discussion has taken place on the mailing list.
So please, do not wait for the call for presentations during the
meeting to propose topics.

- Our current charter includes a "Problem Statement" item, which = is
addressed in the document draft-ietf-ipwave-vehicular-networking.
Obviously, potential topics for rechartering should be covered there
(it will not make sense to work on topics that the community has not
agreed to be important and remain unsolved).

- A rechartering process will always take into account the energy level
of the WG and the completion level of the current milestones. This
means that we need to finish (submit to the IESG) our 2 documents
before we actually start working on the new topics.

Please, share your thoughts on the mailing list!

Thanks,

Carlos and Russs

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



--
Michelle W= etterwald
--00000000000097dc320565a8b3b6-- From nobody Tue Feb 20 20:17:48 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB65129C6A for ; Tue, 20 Feb 2018 20:17:47 -0800 (PST) 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 DUPfbwmlacCX for ; Tue, 20 Feb 2018 20:17:45 -0800 (PST) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::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 7A72812702E for ; Tue, 20 Feb 2018 20:17:45 -0800 (PST) Received: by mail-oi0-x22c.google.com with SMTP id l124so255901oib.0 for ; Tue, 20 Feb 2018 20:17:45 -0800 (PST) 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=KGtNXTCcbp8LKjx/bNV+sMz6W5N8eaaqfavkDwQlBRU=; b=qLQhd45XNxht3syNx9BYVLrhw6XuY9TtzJG8MCHCAtaNln+rSRdGiujnTM5VqCAKwZ mLV0hYCQ/POBnVuaGLFABiSaiY0UFi7/fzG61nQdTxuNZ/5SG/H7yNH4xe5XfLrQLaJs Ayljj+7PvUPcaTYf7fM9UNbUZ8+gqtLkFU/YBObAWELmm1fbRbBWVYjSbglhpezi5UP+ XMAJLgeayrElBNKD1Ok6ajX3SSVV9cQHnglxFwbmeN4XL1bIDxeaWtP3C720eOTT3BR5 kbqzuZvZTy1TpLfj03Xw1k2lO3xbd2r/zzBnkPSDjo6C7XoY3i6Kqf6vswEnHqgne6mv 4d3g== 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=KGtNXTCcbp8LKjx/bNV+sMz6W5N8eaaqfavkDwQlBRU=; b=Me9PJ2Hy5m91DkKo/Vp1ExlJTjohbWl1NwT6zWV0gVakstQVazW6O90tGpTpaE2obI r1TTbYKO2k+BIq+ORKO6kcGbmjXhYAymfpChmTyibb5oCxoDkzpDmMFdTD04tmi6tHny cAPTraDAeJES/KZvA/fo1onKg9PjErHO6WUgGFtBvDzmmLnm5Vprc77MWoriInzT7vGM FQvv7Mg1BlVj/DxKmON2Mk5hWsIaikvcNB5Bok01QEmILQpwHrIX6spFjBqCJro23/mB wcM7NtGEK8gfAmwV01xJEyd8GrgMJ3LTMsJftEmVYn+ymJzKpPpN0dFuKuD6P1Z6AQ5n W9AA== X-Gm-Message-State: APf1xPAFLGIhdosolwABLkmqe2gejf+CtPYc0Ku/cgC5c6CHxg2HjWKb IuiB9c5QxH0HHz98mV6ebc/zTdaidM5MCP6+95I= X-Google-Smtp-Source: AH8x227vm9xLH8aok4mde62cSqhJc2K8y5llRLgRJlX8xepMgWqOr6c6XLI4+n4Uwm0tOZTIACDgbeb4xhGPBqOwuNg= X-Received: by 10.202.205.66 with SMTP id d63mr1321465oig.226.1519186664852; Tue, 20 Feb 2018 20:17:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.36 with HTTP; Tue, 20 Feb 2018 20:17:44 -0800 (PST) In-Reply-To: References: <151869691215.7607.4477863832246767156.idtracker@ietfa.amsl.com> <02fbd867-9694-e68e-a328-6154d6ead9d9@gmail.com> <7b7949f5-eca6-8b55-1331-0abb3260fdc9@gmail.com> <479c2890-a58f-dbbf-ec33-82528cd218ca@gmail.com> From: Abdussalam Baryun Date: Wed, 21 Feb 2018 06:17:44 +0200 Message-ID: To: Richard Roy Cc: Alexandre Petrescu , its Content-Type: multipart/alternative; boundary="001a1134f8ee81924a0565b135cf" Archived-At: Subject: Re: [ipwave] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-17.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, 21 Feb 2018 04:17:47 -0000 --001a1134f8ee81924a0565b135cf Content-Type: text/plain; charset="UTF-8" On Tue, Feb 20, 2018 at 7:55 AM, Dick Roy wrote: > Please understand that fragmentation at any given layer is handled by that > layer and that layer only. ok, agree that each layer does its fragmentation, so we can suggest to change or delete the last sentence OLD> If IPv6 packets of size larger than the MTU are sent on an 802.11-OCB interface card then the IP stack MUST fragment. In case there are IPv6 fragments, the subfield "Fragment number" within the field "Sequence control" of the 802.11 Data header containing the IPv6 fragment is increased by the MAC layer. NEW> If IPv6 packets of size larger than the MTU are sent on an 802.11-OCB interface card then the IP stack MUST fragment. Another NEW option> If IPv6 packets of size larger than the MTU are sent on an 802.11-OCB interface card then the IP stack MUST fragment. The MAC sublayer may fragment IPv6 packets or fragments, while increasing the subfield "Fragment number" within the field "Sequence control" of the 802.11 Data header containing the IPv6 packet or fragment. AB> it states in the document that MAC sublayer may not fragment depending on the capability of receiver/destination. There is a management negotiation that informs about capabilities. Regards AB --001a1134f8ee81924a0565b135cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Feb 20, 2018 at 7:55 AM, Dick Roy <dickroy@alum.mit.edu= > wrote:
Please understand that fragmentation= at any given layer is handled by that
layer and that layer only.

ok,=C2=A0 agree= that each layer does its fragmentation, so we can suggest to change or del= ete the last sentence

OLD>

If IPv6 packets of size larger than

the MTU are sent on an 802.11-OCB interface card then the= IP stack

MUST fragment. In case there are IPv6 fragments, the subf= ield

"Fragment number" within the field "Sequen= ce control" of the 802.11

Data header containing the IPv6 fragment is increased by = the MAC

layer.

=C2=A0
NEW>

<= /span>

If IPv6 packets of size larger th= an

the MTU are sent on an 802.11-OCB interface card then the= IP stack

MUST fragment.



Another NEW option>


If IPv6 packets of size larger than

the MTU are sent on an 802.11-OCB interface card then the IP s= tack

MUST fragment. The MAC sublayer may fragment=C2= =A0IPv6 packets or fragments,=C2=A0while increasing the subfield

"Fragment number" within the field "Sequence cont= rol" of the 802.11

Data header containing the IPv= 6 packet or fragment.


AB> it states in the document that MAC s= ublayer may not fragment depending on the capability of receiver/destinatio= n. There is a management negotiation that informs about capabilities.



Regards

AB



--001a1134f8ee81924a0565b135cf-- From nobody Tue Feb 20 21:04:09 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20E3312D0C3 for ; Tue, 20 Feb 2018 21:04:07 -0800 (PST) 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 9dYTMN0c7k4i for ; Tue, 20 Feb 2018 21:04:05 -0800 (PST) Received: from resqmta-po-05v.sys.comcast.net (resqmta-po-05v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:164]) (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 8167B129C6D for ; Tue, 20 Feb 2018 21:04:05 -0800 (PST) Received: from resomta-po-11v.sys.comcast.net ([96.114.154.235]) by resqmta-po-05v.sys.comcast.net with ESMTP id oMZSerTUkw5SdoMZZelD4V; Wed, 21 Feb 2018 05:04:05 +0000 Received: from [10.95.83.8] ([162.210.129.5]) by resomta-po-11v.sys.comcast.net with SMTP id oMXNeWS5arMhGoMXQeKbD9; Wed, 21 Feb 2018 05:02:03 +0000 From: Tony Li Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_8B4DAFF0-4DDA-4D82-8A09-1DB8228672A8" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Tue, 20 Feb 2018 21:01:47 -0800 In-Reply-To: Cc: Richard Roy , Alexandre Petrescu , its To: Abdussalam Baryun References: <151869691215.7607.4477863832246767156.idtracker@ietfa.amsl.com> <02fbd867-9694-e68e-a328-6154d6ead9d9@gmail.com> <7b7949f5-eca6-8b55-1331-0abb3260fdc9@gmail.com> <479c2890-a58f-dbbf-ec33-82528cd218ca@gmail.com> X-Mailer: Apple Mail (2.3445.5.20) X-CMAE-Envelope: MS4wfNhSBugsx0ZxUneTtb/qS3x0bJm5NPDjioEJVhXFPhj9icI80vM71xWodtXs+ChuzapZ70cOEwiUPepzFgQCIgw1DDnVZUtkzlQUcTrQCGDwHM/RXULQ K/LS3QRfJNKpow4OjVxKTh/+1n1yu2NNC3melPXz28f7JwGnWK/rG1aUmCxf1w5BEFdqxLR/iuO9eEF+gjoFkEqe6g/d2OieMD2UCj5+VdenXiazi4Vq9bu6 jmcvn9i6V7TqhxeZkHe5wW7S81cbnzbCjydogZtIz8w= Archived-At: Subject: Re: [ipwave] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-17.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, 21 Feb 2018 05:04:07 -0000 --Apple-Mail=_8B4DAFF0-4DDA-4D82-8A09-1DB8228672A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > NEW> >=20 > If IPv6 packets of size larger than >=20 > the MTU are sent on an 802.11-OCB interface card then the IP stack >=20 > MUST fragment. >=20 >=20 Thank you, this is a vast improvement.=20 Now, I=E2=80=99ll point out that the remaining sentence is highly = redundant: fragmentation is already well defined in terms of the MTU. = RFC 2460, section 4.5 says: "The Fragment header is used by an IPv6 source to send a packet larger than would fit in the path MTU to its destination. (Note: unlike IPv4, fragmentation in IPv6 is performed only by source nodes, not by routers along a packet's delivery path -- see section 5.)=E2=80=9D > Another NEW option> >=20 >=20 >=20 > If IPv6 packets of size larger than >=20 > the MTU are sent on an 802.11-OCB interface card then the IP stack >=20 > MUST fragment. The MAC sublayer may fragment IPv6 packets or = fragments, while increasing the subfield >=20 > "Fragment number" within the field "Sequence control" of the 802.11 >=20 > Data header containing the IPv6 packet or fragment. >=20 First, this should never happen, as it implies that the packet is both = less than or equal to the MTU and at the same time larger than the MTU. = Second, I can=E2=80=99t quote chapter and verse, but I=E2=80=99d bet = that this is already covered in 802.11-OCB. Thus, it=E2=80=99s again = redundant. I=E2=80=99ll propose a third alternative: how about we just delete the = paragraph entirely? > AB> it states in the document that MAC sublayer may not fragment = depending on the capability of receiver/destination. There is a = management negotiation that informs about capabilities. >=20 All nodes on an IP subnet are presumed to be using the same MTU layer, = thus, fragmentation should be done by the packet source and never again. = In particular IPv6 should never, ever inject a packet that needs MAC = fragmentation. Tony --Apple-Mail=_8B4DAFF0-4DDA-4D82-8A09-1DB8228672A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

NEW>

If = IPv6 packets of size larger than

the MTU = are sent on an 802.11-OCB interface card then the IP stack

MUST fragment.



Thank you, this is a vast = improvement. 

Now, I=E2=80=99ll = point out that the remaining sentence is highly redundant: fragmentation = is already well defined in terms of the MTU.  RFC 2460, section 4.5 = says:

"The Fragment = header is used by an IPv6 source to send a packet larger
   than = would fit in the path MTU to its destination.  (Note: = unlike
   IPv4, fragmentation in IPv6 is = performed only by source nodes, not by
  =  routers along a packet's delivery path -- see section = 5.)=E2=80=9D

Another NEW option>


If IPv6 packets of size = larger than

the MTU are sent on an = 802.11-OCB interface card then the IP stack

MUST fragment. The MAC sublayer may fragment IPv6 = packets or fragments, while increasing the subfield

"Fragment number" within the field "Sequence = control" of the 802.11

Data header = containing the IPv6 packet or = fragment.


First, = this should never happen, as it implies that the packet is both less = than or equal to the MTU and at the same time larger than the MTU. =  Second, I can=E2=80=99t quote chapter and verse, but I=E2=80=99d = bet that this is already covered in 802.11-OCB.  Thus, it=E2=80=99s = again redundant.

I=E2=80=99ll = propose a third alternative: how about we just delete the paragraph = entirely?

AB> it = states in the document that MAC sublayer may not fragment depending on = the capability of receiver/destination. There is a management = negotiation that informs about capabilities.


All nodes on an IP subnet are presumed to be using = the same MTU layer, thus, fragmentation should be done by the packet = source and never again. In particular IPv6 should never, ever inject a = packet that needs MAC fragmentation.

Tony


= --Apple-Mail=_8B4DAFF0-4DDA-4D82-8A09-1DB8228672A8-- From nobody Tue Feb 20 23:43:08 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB43512E880 for ; Tue, 20 Feb 2018 23:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 Wr9ueUOQKcRQ for ; Tue, 20 Feb 2018 23:43:06 -0800 (PST) Received: from mail-ot0-x233.google.com (mail-ot0-x233.google.com [IPv6:2607:f8b0:4003:c0f::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 10DE112E87B for ; Tue, 20 Feb 2018 23:43:06 -0800 (PST) Received: by mail-ot0-x233.google.com with SMTP id b15so641629otf.3 for ; Tue, 20 Feb 2018 23:43:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=1giU+c50I/JSDDcGrayGs67ZHoGNejEUmOnKxuXiGRg=; b=b/eOiXW0FdFfIBmgy2zYeEp5jBiDWwj+IKOGAMDOhW5qgokKJNBm6qRoiNwJBE4n2l vbaqQclX6cipc5qvSIQDv80ZeQHFdpb+aJ7yEwpDlJup1wE3rCWsUR+R02M0a1Ab47yG 1kyz0QC6jW2YELaspGz/N1KjWO4/Y6jb+nhPJyxeyuM9Vk/BD43OgYVCnYuXZZNA/aqg c7t9mjRRtPZFho4/xTz1f1JJER0Xt143Fu3La/7AvqniCvwAJHLcov10qDONX2p13n3l z2BAT8KNcQzHNoFkiyPvkfbR2nk1QR5x1QL5MNK0VIZxTP9Hvh2BIC/sR+TSWH+dNI1F o8QA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=1giU+c50I/JSDDcGrayGs67ZHoGNejEUmOnKxuXiGRg=; b=QF0kDS8NF4ZQuLnFMrTDWTZVG/+n3Feg9oxY+aeTgv2QC4aGNorn41P39OH+a9c2B9 CHCZ4bSAoLCXIIhcJavCrgjegxb1iDfePCml/OrSeoAcJg3jU2FC9V4yffrQlkBOagJ4 XfD1XHXTACprRyWr+HMt194PB0KAypnv6xzgiJV4zHFptKKuoCnWEJ4tbE6M1raiYXAu kQoeVxI7Ccl1YOf1lb7+B4dZEW9wzIKvFIszYaxCtqy9x17Z8vj5Kx+qTwkhqHRAsbkp VDqDqTHJsc/+IowBFVbnfdFvvdZTfAVh52DRtZZmgnbI5aNsH6mlE0tKafRPpw4QdUvb xrKQ== X-Gm-Message-State: APf1xPD3qQ57GuU8Q4Ton+CErgep0vRbZXkeYLG7i8kqFEf/DbdsSBq5 sHs34gb3XjcTpSKRkzcyNAojaZWanVPQ4b1XM8nWJQ== X-Google-Smtp-Source: AG47ELtB0okWrSOvp93bpePH2UCX/ATRgKhnRKsFaUoJYBmGip0cqxe43ToeWhQB3Yl/sBVOmpByb7YsNM0+gHizUn4= X-Received: by 10.157.39.138 with SMTP id c10mr1839811otb.132.1519198985253; Tue, 20 Feb 2018 23:43:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.36 with HTTP; Tue, 20 Feb 2018 23:43:04 -0800 (PST) From: Abdussalam Baryun Date: Wed, 21 Feb 2018 09:43:04 +0200 Message-ID: To: its Content-Type: multipart/alternative; boundary="94eb2c03e2cedbf9540565b41372" Archived-At: Subject: [ipwave] Type/subType in little-edian (New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-18.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, 21 Feb 2018 07:43:08 -0000 --94eb2c03e2cedbf9540565b41372 Content-Type: text/plain; charset="UTF-8" Hi WG, I maybe missed the discussion regarding the below, draft>page 7> 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. AB> the HEX number shows 16 bit which is not number of bits for virsion+type+subtype. AB> if we use the little-edian order as described in section 9.2.2 (IEEE802.11-2016-std), and also in RFC1042, then we work the bits from std-table-9.1, the 802.11 data header type= B2B3= 01, subtype=B4B5B6B7=0000. Then this is in IEEE-Hex = 0x10. AB> The 802.11 QoS data header type= B2B3= 01, subtype=B4B5B6B7=0001. Then this is in IEEE-Hex = 0x11. RFC1042> The IEEE likes to specify numbers in bit transmission order, or bitwise little-endian order. The Internet protocols are documented in byte-wise big-endian order. AB> in the std-doc the put the table-9.1 in Internet binary, but not IEEE binary. However, section 9.2.2 describes. AB> I prefer we let them like in the std-doc as bits in IEEE binary, but not sure what WG thinks, please suggest, Regards AB --94eb2c03e2cedbf9540565b41372 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi WG,

I maybe missed the discussion regarding th= e below,

draft>page 7>

The distinction between the two formats is given by the value of the

field "Type/Subtype". The value of the field &q= uot;Type/Subtype" in the

802.11 Data header is 0x0020. The value of the field &quo= t;Type/Subtype"

in the 802.11 QoS header is 0x0028.

AB> the HEX number shows 16= bit which is not number of bits for virsion+type+subtype.

AB> if = we use the little-edian order as described in section 9.2.2 (IEEE802.11-201= 6-std), and also in RFC1042, then we work the bits from std-table-9.1, the = 802.11 data header type=3D B2B3=3D 01, subtype=3DB4B5B6B7=3D0000. Then this= is in IEEE-Hex =3D 0x10.

AB>=C2=A0The 802.11 QoS data header = type=3D B2B3=3D 01, subtype=3DB4B5B6B7=3D0001. Then this is in IEEE-Hex =3D= 0x11.

RFC1042>

The IEEE likes to specify numbers in bit transmissi= on order, or bitwise little-endian order.

The Internet protocols are = documented in byte-wise big-endian order.

AB> in the std-do= c the put the table-9.1 in Internet binary, but not IEEE binary. However, s= ection 9.2.2 describes.

AB> I prefer we let them like in the std-doc as bits in IEEE binary,= but not sure what WG thinks, please suggest,

Regards

AB

--94eb2c03e2cedbf9540565b41372-- From nobody Wed Feb 21 01:33:44 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C594C120047 for ; Wed, 21 Feb 2018 01:33:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=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 57ZRdT1VRXnh for ; Wed, 21 Feb 2018 01:33:40 -0800 (PST) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EFAD12E88E for ; Wed, 21 Feb 2018 01:33:40 -0800 (PST) Received: by mail-wr0-x229.google.com with SMTP id v65so2474670wrc.11 for ; Wed, 21 Feb 2018 01:33:40 -0800 (PST) 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:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=URNolLEVqNsy+0Y01zTKrhAF7RTW3X5Nn5QW6YE38IE=; b=XnENbYSFQVBVjuzWgkOeO9EDVQP1MxPyYRdjvOodpX7waNQmrWw1tm9N2sA7lswJ81 dcS9mBZvoM/qDlai3rb/jm3iSES4HVGWEDcaWKwh8t5OWw6w18uCGHRfTUIRvo6q9tph y+ZNSO80Nk7bO3BZvtDToEI1qCVqOhjQCRdakPxqzx4iWNlQuA/alh7fWhssM0h7HoLH bcF5a+RwYWAhCWtvMSIwSkth4bcp8k+GBcvx2O0dcTwFf5sEYVI+fg/LJRefUgcU5UZJ g3QWiCNHHFBsTpGUaXFSL31ZuB2+gOGxJRu0ynKABzEIN+ENLxMiu2RLEK41eNDxXx11 cJKw== 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 :in-reply-to:references:organization:mime-version :content-transfer-encoding; bh=URNolLEVqNsy+0Y01zTKrhAF7RTW3X5Nn5QW6YE38IE=; b=YxcnkUlmeoWhL9pWlMkCpzUFJx1V/CM1yJAAalA3uOU0j/nW6i8n2JF3O3PZ2XyyRO GaXr20ysffBA0vWMwaYtJ2P+Q5CcK1pJEPMCtOksUYYQOOn2w1aVsab0vJatCAZ05KPy BRQ0SnQD48GSR1mvd2+0sXCShqqCxe/LXAUwwKKr+plCsFTIDsIIv/3dWbhglNDnAfyF KnC9O0CX3Yyz4FP9IZ/0degSoOUEEE/rMbpj8ol5MfJ0Tcn9W1+aW26JuLSMJxju8do9 qa2X7afhIIhr6zoCx7Be4vdJhPd0EoUzc7dTK2JeNdw1QoYbf+0xPeAZyjFGDn0g0Zrw jxnw== X-Gm-Message-State: APf1xPDQemLGbZdbuLfSEsf0A8mQ6J8icjsVNJJQ2+woRfIAOWlR6SDl 3wA7K0tYBgtiZsdic37mNfn8ig== X-Google-Smtp-Source: AH8x224rSXupmjXAO29vN8khGeEdyV2g/cKtNQ9k2MCxfx8MqvcB6554SKkUClg8AsG4FcqU0EcsqA== X-Received: by 10.28.109.10 with SMTP id i10mr1626696wmc.107.1519205618472; Wed, 21 Feb 2018 01:33:38 -0800 (PST) Received: from wifi-83-67.uc3m.es (wifi-83-67.uc3m.es. [163.117.83.67]) by smtp.gmail.com with ESMTPSA id b136sm21583312wme.34.2018.02.21.01.33.37 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 21 Feb 2018 01:33:37 -0800 (PST) Message-ID: <1519205616.2767.15.camel@it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano Reply-To: cjbc@it.uc3m.es To: Michelle Wetterwald Cc: "its@ietf.org" , Russ Housley Date: Wed, 21 Feb 2018 10:33:36 +0100 In-Reply-To: References: <1516789512.9922.18.camel@it.uc3m.es> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.3-1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Rechartering 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, 21 Feb 2018 09:33:43 -0000 Hi Michelle, This can be definitely part of the re-chartering discussion. Thanks, Carlos On Tue, 2018-02-20 at 19:08 +0100, Michelle Wetterwald wrote: > Hi Carlos, all > > I have just been popping out of a few days away from this list and > found nice discussions... > > Regarding the re-chartering, we agreed in Singapore that the need for > a vehicular service-specific multicast address would be re-discussed > at a later step. > It may be the right time now to consider it again, and include it as > a study topic for the updated charter. > > Best regards, > Michelle > > > 2018-01-24 11:25 GMT+01:00 Carlos Jesús Bernardos Cano es>: > > Hi, > > > > Now that our first document is close to be shipped to the IESG for > > IETF > > LC, the chairs and AD are starting to plan on potential > > rechartering > > (as we anticipated in Singapore). > > > > There are a number of things people have discussed in the past, > > including the time of the BoFs. Now it is time to bring in the > > ideas and suggest them on the mailing list. > > > > Please, keep in mind some important considerations/constraints: > > > > - We will schedule time on the f2f session in London for > > rechartering > > discussion, _only if_ discussion has taken place on the mailing > > list. > > So please, do not wait for the call for presentations during the > > meeting to propose topics. > > > > - Our current charter includes a "Problem Statement" item, which is > > addressed in the document draft-ietf-ipwave-vehicular-networking. > > Obviously, potential topics for rechartering should be covered > > there > > (it will not make sense to work on topics that the community has > > not > > agreed to be important and remain unsolved). > > > > - A rechartering process will always take into account the energy > > level > > of the WG and the completion level of the current milestones. This > > means that we need to finish (submit to the IESG) our 2 documents > > before we actually start working on the new topics. > > > > Please, share your thoughts on the mailing list! > > > > Thanks, > > > > Carlos and Russs > > > > _______________________________________________ > > its mailing list > > its@ietf.org > > https://www.ietf.org/mailman/listinfo/its > > > From nobody Wed Feb 21 04:04:49 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32170126CF9 for ; Wed, 21 Feb 2018 04:04:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 2blxAdcS6WkT for ; Wed, 21 Feb 2018 04:04:44 -0800 (PST) Received: from mail-ot0-x236.google.com (mail-ot0-x236.google.com [IPv6:2607:f8b0:4003:c0f::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B421127077 for ; Wed, 21 Feb 2018 04:04:36 -0800 (PST) Received: by mail-ot0-x236.google.com with SMTP id e64so1175560ote.4 for ; Wed, 21 Feb 2018 04:04:36 -0800 (PST) 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=7MSNXMpdVSftg/OD4GMZmBEUhe8sDo0qMqPIFlsx7DU=; b=H/IrxrkC7DoWmhkKiiKT8I8HHOR5rkBumPRWW4WBtqzFdz2kbtofOPvoe1qc1fPCCm IfQaNZK7vHblm6tZ9+Gz/PqKNuRcQJn4AABK7sDs5YC5bs263TpaNGBoWl0LT1HBL8Ka 13KhbTK0f2J6InSNOoYRFg9+SjB4QpaA2nG1RG/55NDDa+DS4r7xHwUeIU65V32zpJA4 ds1mReV2FU1o+eQH9mlSYO/4MsL8zeNpl/h/OggjSKPCiSaAIUl9i2lBVveErm3TQyNQ cPsWoJuIyhBMc41+DPt95NuzfVJxwSkJX6vDyr1F0x4BN7QdZ6TFO5k786T3VX4Kh7IS cNcA== 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=7MSNXMpdVSftg/OD4GMZmBEUhe8sDo0qMqPIFlsx7DU=; b=nkdZLuVKzWASadIr4UP1+fR4T3qU8GRVl8lwQD5wZJs3opby/oNNrTGaAhK8E9iKm7 v77ZlmyM2k9IOkE4uqv50Z6pjKHdfCERT5/9b4xqBy1jkKn0fDQB9sj7YfaRGRig9Lbk 9+kwlGO8iCFC2vJ/ZXoOR7N90ogWiWUhwMt2hg00GIYW0cBFVZ+z/UyUieOpP2z3skOY 9oYQQfnimZZ2knXg6ePSkgDc5uFPJtK+xxe5MxU1TgfEaHRwyL+5ndcVVk2XOTjaNa/1 +FitnBuaMB1AcFwIDYnb90riD6ecUBrNgRg/o6u4ii394jta4grVrzJeaNqgzLgTJ/X8 fGeA== X-Gm-Message-State: APf1xPAzl7FSXCIo6QjR8tWk59w6PSmMkQaIS53vK86WoRrD3RMWixDT 32C/ogE6s7R2JnHrIFZCY6698DQtTEetRIoyNQQ= X-Google-Smtp-Source: AG47ELs+l83J2AlZXI0KlNesEz4EJkCJQEUJpANyxVW7UCS/RbFi/533205unOYIyPKpMlPNMlPaBfILB/fedz5QmO4= X-Received: by 10.157.65.237 with SMTP id v42mr2211120oti.156.1519214676034; Wed, 21 Feb 2018 04:04:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.36 with HTTP; Wed, 21 Feb 2018 04:04:35 -0800 (PST) In-Reply-To: References: <151869691215.7607.4477863832246767156.idtracker@ietfa.amsl.com> <02fbd867-9694-e68e-a328-6154d6ead9d9@gmail.com> <7b7949f5-eca6-8b55-1331-0abb3260fdc9@gmail.com> <479c2890-a58f-dbbf-ec33-82528cd218ca@gmail.com> From: Abdussalam Baryun Date: Wed, 21 Feb 2018 14:04:35 +0200 Message-ID: To: Tony Li Cc: Alexandre Petrescu , its Content-Type: multipart/alternative; boundary="94eb2c1c1cec1a4bcd0565b7bb6b" Archived-At: Subject: Re: [ipwave] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-17.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, 21 Feb 2018 12:04:46 -0000 --94eb2c1c1cec1a4bcd0565b7bb6b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 21, 2018 at 7:01 AM, Tony Li wrote: > > NEW> > > If IPv6 packets of size larger than > > the MTU are sent on an 802.11-OCB interface card then the IP stack > > MUST fragment. > > > Thank you, this is a vast improvement. > No problem, I always try to work with the WG to improve our work, > > Now, I=E2=80=99ll point out that the remaining sentence is highly redunda= nt: > fragmentation is already well defined in terms of the MTU. RFC 2460, > section 4.5 says: > > "The Fragment header is used by an IPv6 source to send a packet larger > than would fit in the path MTU to its destination. (Note: unlike > IPv4, fragmentation in IPv6 is performed only by source nodes, not by > routers along a packet's delivery path -- see section 5.)=E2=80=9D > The redundant does not harm, but we don't forget that that sentence was there and I am not sure who was interested to keep it, maybe redundant to clarify the 1500 MTU issue, > > Another NEW option> > > > If IPv6 packets of size larger than > > the MTU are sent on an 802.11-OCB interface card then the IP stack > > MUST fragment. The MAC sublayer may fragment IPv6 packets or > fragments, while increasing the subfield > > "Fragment number" within the field "Sequence control" of the 802.11 > > Data header containing the IPv6 packet or fragment. > > > First, this should never happen, as it implies that the packet is both > less than or equal to the MTU and at the same time larger than the MTU. > Second, I can=E2=80=99t quote chapter and verse, but I=E2=80=99d bet that= this is already > covered in 802.11-OCB. Thus, it=E2=80=99s again redundant. > I don't think so, because 802.11-OCB does fragmentation not based on MTU issues, but based on reliability of wireless communication and improvement and efficiency, reed the section of fragmentation/defagmentation section 10.2.7 in that section 10.2.7 -std-802.11-2016> Fragmentation creates MPDUs smaller than the original MSDU or MMPDU length to increase reliability, by increasing the probability of successful transmission (as defined in 10.2.2) of the MSDU or MMPDU when channel characteristics limit reception reliability for longer frames. AB> it is important to clarify that both layer do fragmentation in different purposes, and it can happen in such medium and environment, > > I=E2=80=99ll propose a third alternative: how about we just delete the pa= ragraph > entirely? > But why? however, I never opposed WG decision of fragment text, only if there are good reasons, > > AB> it states in the document that MAC sublayer may not fragment dependin= g > on the capability of receiver/destination. There is a management > negotiation that informs about capabilities. > > > All nodes on an IP subnet are presumed to be using the same MTU layer, > thus, fragmentation should be done by the packet source and never again. = In > particular IPv6 should never, ever inject a packet that needs MAC > fragmentation. > Again, MAC fragmentation is important for using the channel and reliability of MAC-transmissions. This fragmentation mechanism is done through using management frames between MAC entities and MLME. Shorter frames get faster transmitted and also MSDUs specially when using PHY layer capabilities, AB --94eb2c1c1cec1a4bcd0565b7bb6b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Feb 21, 2018 at 7:01 AM, Tony Li <tony.li@tony.li> wrote:

NEW>

If IPv6 packets of size larger than

the MTU = are sent on an 802.11-OCB interface card then the IP stack

MUST fragment.



Thank you, this is a = vast improvement.=C2=A0

N= o problem, I always try to work with the WG to improve our work,
= =C2=A0

Now, I=E2=80=99ll point out that the remaining sentenc= e is highly redundant: fragmentation is already well defined in terms of th= e MTU.=C2=A0 RFC 2460, section 4.5 says:

"Th= e Fragment header is used by an IPv6 source to send a packet larger
=C2=A0 =C2=A0than would fit in the path MTU to its destinatio= n. =C2=A0(Note: unlike
=C2=A0 =C2=A0IPv4, fragmentation in IPv6 i= s performed only by source nodes, not by
=C2=A0 =C2=A0routers alo= ng a packet's delivery path -- see section 5.)=E2=80=9D

The redundant does not harm, but = we don't forget that that sentence was there and I am not sure who was = interested to keep it, maybe redundant to clarify the 1500 MTU issue,
=
=C2=A0

<= span>

Another NEW option>


If IPv6 packets of size larger than

th= e MTU are sent on an 802.11-OCB interface card then the IP stack

MUST fragment. The MAC sublayer may fragment=C2=A0IPv6 packets o= r fragments,=C2=A0while increasing the subfield

"= Fragment number" within the field "Sequence control" of the = 802.11

Data header containing the IPv6 packet or fragm= ent.


First, this should never hap= pen, as it implies that the packet is both less than or equal to the MTU an= d at the same time larger than the MTU.=C2=A0 Second, I can=E2=80=99t quote= chapter and verse, but I=E2=80=99d bet that this is already covered in 802= .11-OCB.=C2=A0 Thus, it=E2=80=99s again redundant.
=

I don't think so, because 802.11-OCB does fragmenta= tion not based on MTU issues, but based on reliability of wireless communic= ation and improvement and efficiency, reed the section of fragmentation/def= agmentation section=C2=A010.2.7

in that section 10= .2.7 -std-802.11-2016>

Fragmentation creates MPDUs smaller than the original MSDU or MM= PDU length to increase

reliability, by increasing the probability of successful = transmission (as defined in 10.2.2) of the MSDU or

MMPDU when channel characteristics limit reception reliability for longe= r frames.


AB> it is important to clarify that both laye= r do fragmentation in different purposes, and it can happen in such medium = and environment,


I=E2= =80=99ll propose a third alternative: how about we just delete the paragrap= h entirely?

But why? however, I= never opposed WG decision of fragment text, only if there are good reasons= ,
=C2=A0

AB> it states in the document that MAC sublayer= may not fragment depending on the capability of receiver/destination. Ther= e is a management negotiation that informs about capabilities.


All nodes on an IP subnet a= re presumed to be using the same MTU layer, thus, fragmentation should be d= one by the packet source and never again. In particular IPv6 should never, = ever inject a packet that needs MAC fragmentation.
=

Again, MAC fragmentation is important for using the cha= nnel and reliability of MAC-transmissions. This fragmentation mechanism is = done through using management=C2=A0frames=C2=A0between MAC entities and MLM= E. Shorter frames get faster transmitted and also MSDUs specially when usin= g=C2=A0PHY layer=C2=A0capabilities,

AB
--94eb2c1c1cec1a4bcd0565b7bb6b-- From nobody Wed Feb 21 04:11:57 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4705126D74 for ; Wed, 21 Feb 2018 04:11:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 1YXkjewsFZhL for ; Wed, 21 Feb 2018 04:11:54 -0800 (PST) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::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 E85ED126CF9 for ; Wed, 21 Feb 2018 04:11:53 -0800 (PST) Received: by mail-oi0-x22e.google.com with SMTP id b8so938537oib.11 for ; Wed, 21 Feb 2018 04:11:53 -0800 (PST) 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=4Zawq7q33ob9NOTVNJG16kzCdoCEzL8MZ/I4tyKYhrc=; b=Gt4aJuuciqD1RrfePAXxKqDa09Q0AQh7bxGjcdJR5vIaEhPDwne2QPzqUYttEXugKG EacWSiSl+oqrrPsSNswHKBck9RUt4PKDwNp3bLEDCqk/GtRlX3LcOnppWHd+Z74B/yjL lhQy7TZDCJcNTm2cBF59IHy1neo+uweYwn5Z9Tqbkd1SHgsWcq8W8oVrdvUQFqmvZV1d WN23lyywFDyL9w3UKYFum3aN4VHnB63mdZGCx8JlDSeG2yU6zLgFUM8yynnx6Up2o0vN dGK/LfTxtTF5u2CQ85msRZnd1i7AEEYGGDEMJGAfqZE6e7YDdCHfWEEskyfNPYRPscze Dj0Q== 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=4Zawq7q33ob9NOTVNJG16kzCdoCEzL8MZ/I4tyKYhrc=; b=dBT1jVxhVyQu4XUorqYNYvM/Ig4+fuIvWd6JtG8wu+/IfxZJrJe1UN4P18ob+raV+S Bc/dOI/AKyntf4eUqGnP/7WCq/E2V+jIovPLTBo9x6kTOEbezAxjjwLZi+9ylFwyRVwG ZtPK7HUYLPXozgKDX6wB1snJo+RkLJ3wcOGUtqa9VsDBb2+dxHfkAQthhNPbCyMri7ak OcGcSNM9xXobxrH9UBF8PTXEHyF9JUEzedIKkms36tpTuKaYVhiUTgqbaCj2eOPV23IU 5jo94++5aJpW+/ooTALfDop2FwP8g+SDvLr1tN3osXbyprCdd2BEYqx/CmjpNVV+RIdO ksPQ== X-Gm-Message-State: APf1xPCOXkIERnKd3bilXP7VdOBCwXWFXV3RwluPCalmqT/uxOJBY5pr c6RpuioYij5tOaw/VtVilN9pflsnwnwvS0yaLVE= X-Google-Smtp-Source: AH8x226vJ5ngbZU1ZUJjTFG26WdKKjhbQBI+GkFfJ4vIhR2FGi1WhpRX9kpN6nCljv7u28sDkAh+AyWO14WdTHSh7TA= X-Received: by 10.202.232.21 with SMTP id f21mr1832269oih.29.1519215113287; Wed, 21 Feb 2018 04:11:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.36 with HTTP; Wed, 21 Feb 2018 04:11:52 -0800 (PST) In-Reply-To: References: <151869691215.7607.4477863832246767156.idtracker@ietfa.amsl.com> <02fbd867-9694-e68e-a328-6154d6ead9d9@gmail.com> <7b7949f5-eca6-8b55-1331-0abb3260fdc9@gmail.com> <479c2890-a58f-dbbf-ec33-82528cd218ca@gmail.com> From: Abdussalam Baryun Date: Wed, 21 Feb 2018 14:11:52 +0200 Message-ID: To: Tony Li Cc: Alexandre Petrescu , its Content-Type: multipart/alternative; boundary="001a11403e3a2a3ce40565b7d525" Archived-At: Subject: Re: [ipwave] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-17.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, 21 Feb 2018 12:11:56 -0000 --001a11403e3a2a3ce40565b7d525 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 21, 2018 at 7:01 AM, Tony Li wrote: > > NEW> > > If IPv6 packets of size larger than > > the MTU are sent on an 802.11-OCB interface card then the IP stack > > MUST fragment. > > > Thank you, this is a vast improvement. > No problem, I always try to work with the WG to improve our work, > > Now, I=E2=80=99ll point out that the remaining sentence is highly redunda= nt: > fragmentation is already well defined in terms of the MTU. RFC 2460, > section 4.5 says: > > "The Fragment header is used by an IPv6 source to send a packet larger > than would fit in the path MTU to its destination. (Note: unlike > IPv4, fragmentation in IPv6 is performed only by source nodes, not by > routers along a packet's delivery path -- see section 5.)=E2=80=9D > The redundant does not harm, but we don't forget that that sentence was there and I am not sure who was interested to keep it, maybe redundant to clarify the 1500 MTU issue, > > Another NEW option> > > > If IPv6 packets of size larger than > > the MTU are sent on an 802.11-OCB interface card then the IP stack > > MUST fragment. The MAC sublayer may fragment IPv6 packets or > fragments, while increasing the subfield > > "Fragment number" within the field "Sequence control" of the 802.11 > > Data header containing the IPv6 packet or fragment. > > > First, this should never happen, as it implies that the packet is both > less than or equal to the MTU and at the same time larger than the MTU. > Second, I can=E2=80=99t quote chapter and verse, but I=E2=80=99d bet that= this is already > covered in 802.11-OCB. Thus, it=E2=80=99s again redundant. > I don't think so, because 802.11-OCB does fragmentation not based on MTU issues, but based on reliability of wireless communication and improvement and efficiency, reed the section of fragmentation/defagmentation section 10.2.7 in that section 10.2.7 -std-802.11-2016> Fragmentation creates MPDUs smaller than the original MSDU or MMPDU length to increase reliability, by increasing the probability of successful transmission (as defined in 10.2.2) of the MSDU or MMPDU when channel characteristics limit reception reliability for longer frames. AB> it is important to clarify that both layer do fragmentation in different purposes, and it can happen in such medium and environment, > > I=E2=80=99ll propose a third alternative: how about we just delete the pa= ragraph > entirely? > But why? however, I never opposed WG decision of fragment text, only if there are good reasons, > > AB> it states in the document that MAC sublayer may not fragment dependin= g > on the capability of receiver/destination. There is a management > negotiation that informs about capabilities. > > > All nodes on an IP subnet are presumed to be using the same MTU layer, > thus, fragmentation should be done by the packet source and never again. = In > particular IPv6 should never, ever inject a packet that needs MAC > fragmentation. > Again, MAC fragmentation is important for using the wireless channel and reliability of MAC-transmissions. Figure 5 in our draft defines the reference model and also in the std-802.11 while including MLME and PLME. This fragmentation mechanism is done through using management frames/negotiation between MAC entities and MLME. Shorter frames get faster transmitted and also MSDUs specially when using PHY layer capabilities, AB --001a11403e3a2a3ce40565b7d525 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, Feb 21,= 2018 at 7:01 AM, Tony Li <tony.li@tony.li> wrote:

<= span>NEW>

<= div>

If IPv6 packets of size larger than

the MTU are sent on an 802.11-OCB interface card then the IP stac= k

MUST fragment.



Tha= nk you, this is a vast improvement.=C2=A0

No problem, I always try to work with the WG to imp= rove our work,
=C2=A0

Now, I=E2=80=99ll point out that the rema= ining sentence is highly redundant: fragmentation is already well defined i= n terms of the MTU.=C2=A0 RFC 2460, section 4.5 says:

<= span>"The Fragment header is used by an IPv6 source to send a packet l= arger
=C2=A0 =C2=A0than would fit in the path MTU to i= ts destination. =C2=A0(Note: unlike
=C2=A0 =C2=A0IPv4, fragmentat= ion in IPv6 is performed only by source nodes, not by
=C2=A0 =C2= =A0routers along a packet's delivery path -- see section 5.)=E2=80=9D

The redundan= t does not harm, but we don't forget that that sentence was there and I= am not sure who was interested to keep it, maybe redundant to clarify the = 1500 MTU issue,
=C2=A0

<= div dir=3D"ltr">
=

Another NEW option>

<= br>

If IPv6 packets of size larger than

the MTU are sent on an 802.11-OCB interface card then the IP stack

MUST fragment. The MAC sublayer may fragment=C2=A0IPv6 = packets or fragments,=C2=A0while increasing the subfield

"Fragment number" within the field "Sequence control"= ; of the 802.11

Data header containing the IPv6 packet= or fragment.


First, this should = never happen, as it implies that the packet is both less than or equal to t= he MTU and at the same time larger than the MTU.=C2=A0 Second, I can=E2=80= =99t quote chapter and verse, but I=E2=80=99d bet that this is already cove= red in 802.11-OCB.=C2=A0 Thus, it=E2=80=99s again redundant.

I don't think so, because 802.11-O= CB does fragmentation not based on MTU issues, but based on reliability of = wireless communication and improvement and efficiency, reed the section of = fragmentation/defagmentation section=C2=A010.2.7

i= n that section 10.2.7 -std-802.11-2016>

Fragmentation creates MPDUs smaller than the or= iginal MSDU or MMPDU length to increase

reliability, b= y increasing the probability of successful transmission (as defined in 10.2= .2) of the MSDU or

MMPDU when channel characteristics limit reception= reliability for longer frames.


AB> it is important to = clarify that both layer do fragmentation in different purposes, and it can = happen in such medium and environment,


I=E2=80=99ll propose a third alternative: how about we just delete t= he paragraph entirely?

B= ut why? however, I never opposed WG decision of fragment text, only if ther= e are good reasons,
=C2=A0

<= span>

AB> it states in the document that MAC = sublayer may not fragment depending on the capability of receiver/destinati= on. There is a management negotiation that informs about capabilities.
<= /p>


All nodes on an IP = subnet are presumed to be using the same MTU layer, thus, fragmentation sho= uld be done by the packet source and never again. In particular IPv6 should= never, ever inject a packet that needs MAC fragmentation.

Again, MAC fragmentation is important fo= r using the wireless channel and reliability of MAC-transmissions. Figure 5= in our draft defines the reference model and also in the std-802.11 while = including MLME and PLME. This fragmentation mechanism is done through using= management=C2=A0frames/negotiation=C2=A0between MAC entities and MLME. Sho= rter frames get faster transmitted and also MSDUs specially when using=C2= =A0PHY layer=C2=A0capabilities,

AB
=
--001a11403e3a2a3ce40565b7d525-- From nobody Wed Feb 21 07:19:58 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 650E4127698 for ; Wed, 21 Feb 2018 07:19:57 -0800 (PST) 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 O4Rf-MI5GJmr for ; Wed, 21 Feb 2018 07:19:55 -0800 (PST) Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (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 84DC9127010 for ; Wed, 21 Feb 2018 07:19:54 -0800 (PST) Received: from resomta-po-15v.sys.comcast.net ([96.114.154.239]) by resqmta-po-03v.sys.comcast.net with ESMTP id oWAQeMmpC06N1oWBWeBJSK; Wed, 21 Feb 2018 15:19:54 +0000 Received: from [192.168.1.6] ([24.130.209.5]) by resomta-po-15v.sys.comcast.net with SMTP id oWBTedJgOMFvCoWBUeceQY; Wed, 21 Feb 2018 15:19:54 +0000 From: tony.li@tony.li Message-Id: <4862AE04-39FB-404B-A8D1-ACBD6DC793F8@tony.li> Content-Type: multipart/alternative; boundary="Apple-Mail=_2B904722-7BB5-48D5-83DB-A2B3FD0D541D" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 21 Feb 2018 07:19:50 -0800 In-Reply-To: Cc: Alexandre Petrescu , its To: Abdussalam Baryun References: <151869691215.7607.4477863832246767156.idtracker@ietfa.amsl.com> <02fbd867-9694-e68e-a328-6154d6ead9d9@gmail.com> <7b7949f5-eca6-8b55-1331-0abb3260fdc9@gmail.com> <479c2890-a58f-dbbf-ec33-82528cd218ca@gmail.com> X-Mailer: Apple Mail (2.3445.5.20) X-CMAE-Envelope: MS4wfHBqXSMlCFNaCiSGqqm01VlkNt5k3KrQBj+PE6Bnf0c0RWSjLBgL2QeKvmh8+lalQbMwcE2SCQm0ywY4HSDw/1IzJ1Y0GOJlusbdOUlBS4nfsjl7w4+s 6kXcy717l4IvlRLL/t0Mxqoxyxabct4E87VDqKRp3AeqcZmvG12i1uhNfpNLvpSWhxGb6fP4hmxNPQSukUJ7klrPss0XKYTr8VnuW+TkMZTuIIC96JwIEMSy Archived-At: Subject: Re: [ipwave] New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-17.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, 21 Feb 2018 15:19:57 -0000 --Apple-Mail=_2B904722-7BB5-48D5-83DB-A2B3FD0D541D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > The redundant does not harm, but we don't forget that that sentence = was there and I am not sure who was interested to keep it, maybe = redundant to clarify the 1500 MTU issue, Redundancy is unnecessary and always creates the potential for = conflicting interpretations between two documents. These are protocol = specifications we=E2=80=99re writing, not Dickensian novels. If we do = not mean to revise or update the behavior described in another document, = we should not be restating it. Our focus should be purely on the interaction between IPv6 and IEEE = 802.11-OCB. We shouldn=E2=80=99t go repeating the fundamentals of = either side of the interaction. >> The MAC sublayer may fragment IPv6 packets or fragments, while = increasing the subfield >>=20 >> "Fragment number" within the field "Sequence control" of the 802.11 >>=20 >> Data header containing the IPv6 packet or fragment. >>=20 >=20 > First, this should never happen, as it implies that the packet is both = less than or equal to the MTU and at the same time larger than the MTU. = Second, I can=E2=80=99t quote chapter and verse, but I=E2=80=99d bet = that this is already covered in 802.11-OCB. Thus, it=E2=80=99s again = redundant. >=20 > I don't think so, because 802.11-OCB does fragmentation not based on = MTU issues, but based on reliability of wireless communication and = improvement and efficiency, reed the section of = fragmentation/defagmentation section 10.2.7 >=20 > in that section 10.2.7 -std-802.11-2016> > Fragmentation creates MPDUs smaller than the original MSDU or MMPDU = length to increase >=20 > reliability, by increasing the probability of successful transmission = (as defined in 10.2.2) of the MSDU or >=20 > MMPDU when channel characteristics limit reception reliability for = longer frames. >=20 Thank you for the clarification. Again, given that, mentioning OCB = fragmentation is again unnecessary. It is wholly independent of IPv6. > AB> it is important to clarify that both layer do fragmentation in = different purposes, and it can happen in such medium and environment, >=20 I think it raises more confusion than clarity. =20 >=20 > I=E2=80=99ll propose a third alternative: how about we just delete the = paragraph entirely? >=20 > But why? however, I never opposed WG decision of fragment text, only = if there are good reasons, Because it adds no value. What would an implementer do differently with = the proposed text? If it does not affect the bits on the wire, then it = doesn=E2=80=99t need to be in the spec. Tony --Apple-Mail=_2B904722-7BB5-48D5-83DB-A2B3FD0D541D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

The redundant does not harm, but = we don't forget that that sentence was there and I am not sure who was = interested to keep it, maybe redundant to clarify the 1500 MTU = issue,


Redundancy is unnecessary and = always creates the potential for conflicting interpretations between two = documents. These are protocol specifications we=E2=80=99re writing, not = Dickensian novels. If we do not mean to revise or update the behavior = described in another document, we should not be restating = it.

Our focus should be purely on = the interaction between IPv6 and IEEE 802.11-OCB.  We shouldn=E2=80=99= t go repeating the fundamentals of either side of the = interaction.

The = MAC sublayer may fragment IPv6 packets or fragments, while = increasing the subfield

"Fragment = number" within the field "Sequence control" of the 802.11

Data header containing the IPv6 packet or = fragment.


First, this should never happen, as it implies that the = packet is both less than or equal to the MTU and at the same time larger = than the MTU.  Second, I can=E2=80=99t quote chapter and verse, but = I=E2=80=99d bet that this is already covered in 802.11-OCB.  Thus, = it=E2=80=99s again redundant.

I don't think so, because 802.11-OCB = does fragmentation not based on MTU issues, but based on reliability of = wireless communication and improvement and efficiency, reed the section = of fragmentation/defagmentation section 10.2.7

in that section 10.2.7 = -std-802.11-2016>

Fragmentation creates = MPDUs smaller than the original MSDU or MMPDU length to increase

reliability, by increasing the probability of = successful transmission (as defined in 10.2.2) of the MSDU or

MMPDU when channel characteristics limit reception = reliability for longer = frames.

<= br class=3D"">

Thank you for the = clarification.  Again, given that, mentioning OCB fragmentation is = again unnecessary. It is wholly independent of IPv6.

AB> it is important to clarify that both = layer do fragmentation in different purposes, and it can happen in such = medium and = environment,


I think it raises more = confusion than clarity.  



I=E2=80=99ll propose a = third alternative: how about we just delete the paragraph = entirely?

But why? however, I never opposed WG = decision of fragment text, only if there are good = reasons,


Because it adds no = value. What would an implementer do differently with the proposed text? = If it does not affect the bits on the wire, then it doesn=E2=80=99t need = to be in the spec.

Tony

= --Apple-Mail=_2B904722-7BB5-48D5-83DB-A2B3FD0D541D-- From nobody Wed Feb 21 09:10:18 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8484212D885 for ; Wed, 21 Feb 2018 09:10:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=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 Fzgmmu5X_wRP for ; Wed, 21 Feb 2018 09:10:14 -0800 (PST) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::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 4DDBD12D868 for ; Wed, 21 Feb 2018 09:10:14 -0800 (PST) Received: by mail-wr0-x234.google.com with SMTP id w77so6529780wrc.6 for ; Wed, 21 Feb 2018 09:10:14 -0800 (PST) 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=47XyOX6qQZ6ZMqx2wfgN6Up0+PGe1kBk0tSoYFi/0GM=; b=LhFyzzC/7K+eEVa5mutcNlySb+JTkfrkbPv6Yu51vbR++BKdLylMYMkRn0THl2Jly2 Y2PEanV7tHU4HKGPtZIygqO0puy1iHzTzfy/NO1a3RO5E17p91DMbHibADDiRvQ8284k +caiY2GI08gQLgoHkzDaf3Y5TPVCipvJ4XGCXa5fvY9F9VfAvkwFMYA4QITmgb6tfX/K HTqGuEE84IswuyFAUM9KmciQ96Yabm+/9n01vYgLJ12EjNmtvmbVZo1U72fuaGL0vnNy isz1fB+iYZocHAZKcGqIYPFTVq9LiI9V76+TScCJT6Q2lJCuID6NthzI5OW8+3waA4qs LVfA== 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=47XyOX6qQZ6ZMqx2wfgN6Up0+PGe1kBk0tSoYFi/0GM=; b=cCSZAJffE/8U5aDNByGDfi980Z6FzwkTq0eAiT5euoTyoGMbzci6E4aMaHTy9vf5XA KsBDVMKPrEbHdUakIuRoOc6pzAjP8gv8N/UEjUSPwU/s2hAYbPyAynti5KVFbDuSpkzh FNo4P0PE5FCnYxMr8DUMwg2Vgem85oYZ/jxQYAnP8TirIfo0n3c++CreXZ0gKRWNZ3NO doZW9hhuKrEN3Yl0hs5jZl+Qa1Eia7Zq0p/5u5OJo5w735eecVBeZ7xPAuJq9t4dsADc GsS9mlGDZSRCw4oujS7M3kXlrXax7GA72CGzDyAxGMKVXh49SB/SmKBGILmEhFQOanl6 ms1w== X-Gm-Message-State: APf1xPBGx576dvYbKVBjCGOWj9+P5SEpttWL6KhH9A7DmFOWZREXWj9R d1r+vZLFpk0epjvrdVFUDashZjCR X-Google-Smtp-Source: AH8x225/ch44vRnlDMYkboKT3p1E42D/rPuBlQUdK1oeQNfxo5mothyhiPFsIYlL513ACtEpiddMvw== X-Received: by 10.28.167.208 with SMTP id q199mr2792993wme.29.1519233012457; Wed, 21 Feb 2018 09:10:12 -0800 (PST) Received: from acorde ([2001:720:410:1010:d681:d7ff:fe28:350b]) by smtp.gmail.com with ESMTPSA id i11sm19571979wre.36.2018.02.21.09.10.11 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 21 Feb 2018 09:10:11 -0800 (PST) Message-ID: <1519233010.3516.75.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: Russ Housley Date: Wed, 21 Feb 2018 18:10:10 +0100 Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.3-1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: [ipwave] IETF 101: IPWAVE agenda requests 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, 21 Feb 2018 17:10:16 -0000 Hi, We have a 2.5h slot for London, accounting for some re-chartering discussions. Please, send agenda requests to the chairs by Wed, Feb 28th, indicating short abstract, draft name, and time requested. Obviously, requests from existing or related to WG items will have precedence. For requests related to re-chartering topics, please indicate explicitly. Once we have all the requests, Russ and I will decide how to best organize this discussion. Thanks, Carlos & Russ From nobody Wed Feb 21 10:00:45 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62472126DED for ; Wed, 21 Feb 2018 10:00:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=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 StAcpuxCUWm6 for ; Wed, 21 Feb 2018 10:00:41 -0800 (PST) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::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 C53E1126B7E for ; Wed, 21 Feb 2018 10:00:40 -0800 (PST) Received: by mail-wr0-x231.google.com with SMTP id z12so6979353wrg.4 for ; Wed, 21 Feb 2018 10:00:40 -0800 (PST) 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:date:organization:mime-version :content-transfer-encoding; bh=apKYHc0zrMgyKy85KVpAQEXX6Zi/uGTP4Vd5AQiAn8s=; b=w2aPJTdknERAalX4KUvZqeKhyVQwPSZiYgTDXT9ifdL8pkOhwMlATLqrWlRHreeMyq w7aQt6/KLawQEiXytEij5HEXR39LFkDlnB/psLXhpfYTaeGXDipK7E+/ULg5yobGIyEU 1X3brRLqY57+9clXIcG7w+TJLSNnnBuzxk7dKA2mlaWWm1Y+fsLgNFeWjYK/u0xCJSWh Ji06lbxzbC18Zf9BKmxtWQ/z5vd3xsMvJ8HEqQSrUvmzREH0hPUUviKTh7o1+kv102ry 3Cyuc4qFRHOTvs/z3GMocZTAVqAV1bZHiPByoDdJL06VtYmQTAkYOqU/AfXtLMDFmY1S Onog== 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:date :organization:mime-version:content-transfer-encoding; bh=apKYHc0zrMgyKy85KVpAQEXX6Zi/uGTP4Vd5AQiAn8s=; b=msiMj6uqkQPpL8DqFgfegXeWMbNQL8Th3c4qaUqsnfWe6sduJ5qNl9yV7Qt7xb3nxa nBWeRG01NuoORxslY7/rQkGSfavDaX6EAmpJeXwi7ZghshhMYxPPEFLo0o9BHyri4/AN Jfxtdhv740UWsty1lMu/pAHvWHgHVhE+U20HAh+dnAfCnXJtc3GDuEwoHBzrWqnSKQ5v R74/J7Sk8psDYuYIxi75tedBJhBJCWUoTjLQ8rRLaxQmRYEX3pDKTsRXyaCbG94Tu/PV 4FxP4eOguMfYyBRnCQ0BKcCa+dU/cnjOJO/bnjfClg+U5FgEuVUZW4X84GgslA9gZTSG R4IA== X-Gm-Message-State: APf1xPCnwLj+VomCTX+Q8BuxrK6ZtdmzG5kbrVEPehoSAQYJoq5cWWCP fbka2KBDAeibby/Za5/SNKw3aA== X-Google-Smtp-Source: AH8x2243k3/PDA1ukpxIlMphhZRQfmsHyG69GzP6/22XrWW9oGxhj3gIjFtIusFhdLMa2IjN1U0WJw== X-Received: by 10.223.153.23 with SMTP id x23mr3846173wrb.134.1519236039078; Wed, 21 Feb 2018 10:00:39 -0800 (PST) Received: from acorde ([2001:720:410:1010:d681:d7ff:fe28:350b]) by smtp.gmail.com with ESMTPSA id b30sm56499343wra.34.2018.02.21.10.00.38 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 21 Feb 2018 10:00:38 -0800 (PST) Message-ID: <1519236037.3516.101.camel@it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano Reply-To: cjbc@it.uc3m.es To: draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org, "its@ietf.org" Date: Wed, 21 Feb 2018 19:00:37 +0100 Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.3-1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: [ipwave] Review of draft-ietf-ipwave-ipv6-over-80211ocb-18 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, 21 Feb 2018 18:00:43 -0000 Hi, I've reviewed the latest version of the draft (-18). I have the following comments: - Section 4.1: If IPv6 packets of size larger than the MTU are sent on an 802.11-OCB interface card then the IP stack MUST fragment. In case there are IPv6 fragments, the subfield "Fragment number" within the field "Sequence control" of the 802.11 Data header containing the IPv6 fragment is increased by the MAC layer. I think this has to be removed. The first sentence is obvious (if a packet is larger than the MTU, it has to be fragmented), and the second we have had extensive discussion on it on the mailing list. I also believe that this would be a layer violation. - Section 4.1: Non-IP packets such as WAVE Short Message Protocol (WSMP) can be delivered on 802.11-OCB links. Specifications of these packets are 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 GeoNetworking packets have an MTU of 1492 bytes. The operation of IPv6 over GeoNetworking is specified at [ETSI-IPv6-GeoNetworking]. I think this text can be removed, as it is about non-IP packets and this document is about IPv6-over-OCB. I tend to prefer to avoid unnecessary text in normative documents. - Section 4.2: 1 0 0 0 0 1 1 0 1 1 0 1 1 1 0 1 is the binary representation of the EtherType value 0x86DD. Same comment as before. I think this has to be removed. - Section 4.2.1: Additionally, the Ethernet Adaptation Layer performs operations in relation to IP fragmentation and MTU. One of these operations is briefly described in Section 4.1. Please, remove. The adaptation layer does not perform any fragmentation related operation. - Section 4.3: Additionally, if stable identifiers are needed, it is recommended to follow the Recommendation on Stable IPv6 Interface Identifiers [RFC8064]. Do we want to make the "recommended" there normative? - Section 4.4 and 4.4.1: I wonder if we want to change the writing so it is actually normative. For example: CURRENT: For unicast as for multicast, there is no change from the unicast and multicast address mapping format of Ethernet interfaces, as defined by sections 6 and 7 of [RFC2464]. PROPOSED: Unicast and multicast address mapping MUST follow the procedures specified for Ethernet interfaces in sections 6 and 7 of [RFC2464]. - Section 4.6: 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. Please, remove, this text is not needed. Thanks, Carlos From nobody Thu Feb 22 04:21:13 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D39B512EA57 for ; Thu, 22 Feb 2018 04:21:10 -0800 (PST) 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 WlOzShZVG6WL for ; Thu, 22 Feb 2018 04:21:09 -0800 (PST) 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 D2BB5126C89 for ; Thu, 22 Feb 2018 04:21:08 -0800 (PST) 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 w1MCL787010400 for ; Thu, 22 Feb 2018 13:21:07 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 34B81202E84 for ; Thu, 22 Feb 2018 13:21:07 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 21540202DBA for ; Thu, 22 Feb 2018 13:21:07 +0100 (CET) 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 w1MCL61w030368 for ; Thu, 22 Feb 2018 13:21:06 +0100 To: its@ietf.org References: From: Alexandre Petrescu Message-ID: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> Date: Thu, 22 Feb 2018 13:21:06 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.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] Type/subType in little-edian (New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-18.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, 22 Feb 2018 12:21:11 -0000 Le 21/02/2018 à 08:43, Abdussalam Baryun a écrit : > Hi WG, > > I maybe missed the discussion regarding the below, > > draft>page 7> > > 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. > > AB> the HEX number shows 16 bit which is not number of bits for > virsion+type+subtype. I agree with you. There was an error in interpreting the dump. I propose to better interpret the "Type/Subtype" as to be of length 6 bits. Leftmost 4 bits is Subtype and rightmost 2 bits is Type. The Type is always of value 2, to mean Data frame. The SubType is usually value 0, which means 802.11 Data. Some times the Subtype is value 8. This means this is 802.11 QoS Data. As such, the text becomes: > The distinction between the two formats is given by the > value of the field "Subtype" in the Frame Control Field. > The value of the field "Subtype" in the 802.11 Data header > is 0x0. The value of the field "Subtype" in the 802.11 > QoS header is 8. Unless, of course, we want to remove the description of this distinction between 802.11 QoS Data and 802.11 Data headers. Alex From nobody Thu Feb 22 04:24:35 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76D50126C89; Thu, 22 Feb 2018 04:24:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 UDG8XnkSR30V; Thu, 22 Feb 2018 04:24:31 -0800 (PST) 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 BAE0F126C2F; Thu, 22 Feb 2018 04:24:30 -0800 (PST) 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 w1MCOSbW025035; Thu, 22 Feb 2018 13:24:28 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0713E202CC6; Thu, 22 Feb 2018 13:24:28 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id EDB11202E9B; Thu, 22 Feb 2018 13:24:27 +0100 (CET) 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 w1MCORYE001096; Thu, 22 Feb 2018 13:24:27 +0100 To: cjbc@it.uc3m.es, draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org, "its@ietf.org" References: <1519236037.3516.101.camel@it.uc3m.es> From: Alexandre PETRESCU Organization: CEA Message-ID: <136aef05-3931-3d26-2b0f-59fdc7ee0b4f@cea.fr> Date: Thu, 22 Feb 2018 13:24:27 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <1519236037.3516.101.camel@it.uc3m.es> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040606050605050209090003" Archived-At: Subject: Re: [ipwave] Review of draft-ietf-ipwave-ipv6-over-80211ocb-18 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, 22 Feb 2018 12:24:33 -0000 This is a cryptographically signed message in MIME format. --------------ms040606050605050209090003 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: fr -- Alexandre Petrescu alexandre.petrescu@cea.fr, t=C3=A9l 0169089223 Le 21/02/2018 =C3=A0 19:00, Carlos Jes=C3=BAs Bernardos Cano a =C3=A9crit= =C2=A0: > Hi, > > I've reviewed the latest version of the draft (-18). I have the > following comments: > > - Section 4.1: > > If IPv6 packets of size larger than > the MTU are sent on an 802.11-OCB interface card then the IP stack > MUST fragment. In case there are IPv6 fragments, the subfield > "Fragment number" within the field "Sequence control" of the 802.11= > Data header containing the IPv6 fragment is increased by the MAC > layer. > > I think this has to be removed. The first sentence is obvious (if a > packet is larger than the MTU, it has to be fragmented), and the second= > we have had extensive discussion on it on the mailing list. I also > believe that this would be a layer violation. > > - Section 4.1: > > Non-IP packets such as WAVE Short Message Protocol (WSMP) can be > delivered on 802.11-OCB links. Specifications of these packets are= > 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 GeoNetworking packets have an MTU of 1492 bytes. The > operation of IPv6 over GeoNetworking is specified at > [ETSI-IPv6-GeoNetworking]. > > I think this text can be removed, as it is about non-IP packets and > this document is about IPv6-over-OCB. I tend to prefer to avoid > unnecessary text in normative documents. Agreed. > > - Section 4.2: > > 1 0 0 0 0 1 1 0 1 1 0 1 1 1 0 1 > is the binary representation of the EtherType value 0x86DD. > > Same comment as before. I think this has to be removed. Agreed. > > - Section 4.2.1: > > Additionally, the Ethernet Adaptation Layer performs operations in > relation to IP fragmentation and MTU. One of these operations is > briefly described in Section 4.1. > > Please, remove. The adaptation layer does not perform any fragmentation= > related operation. Agreed. > > - Section 4.3: > > Additionally, if stable identifiers are > needed, it is recommended to follow the Recommendation on Stable > IPv6 > Interface Identifiers [RFC8064]. > > Do we want to make the "recommended" there normative? Yes, RECOMMENDED. > > - Section 4.4 and 4.4.1: I wonder if we want to change the writing so > it is actually normative. For example: > > CURRENT: > > For unicast as for multicast, there is no change from the unicast > and > multicast address mapping format of Ethernet interfaces, as defined= > by sections 6 and 7 of [RFC2464]. > > PROPOSED: > > Unicast and multicast address mapping MUST follow the procedures > specified for Ethernet interfaces in sections 6 and 7 of [RFC2464]. Agreed. > > - Section 4.6: > > 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. > > Please, remove, this text is not needed. Agreed. Alex --------------ms040606050605050209090003 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 C2AwggWCMIIEaqADAgECAgIYEjANBgkqhkiG9w0BAQsFADA9MQswCQYDVQQGEwJGUjEMMAoG A1UECgwDQ0VBMSAwHgYDVQQDDBdDRUEgQUMgVXRpbGlzYXRldXIgMjAzMTAeFw0xNzExMjcx MTUzMThaFw0yMDExMjcxMTUzMThaMFUxCzAJBgNVBAYTAkZSMQwwCgYDVQQKDANjZWExFDAS BgNVBAsMC1V0aWxpc2F0ZXVyMSIwIAYDVQQDDBlQRVRSRVNDVSBBbGV4YW5kcmUgMjIyMDQw MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxflZNm4uFO1gfpGFsdm8+ijK5FnS fr24rrT8KW0oz8cV8u+UZ55M/bqidvqSXGGz3C480T6DZsfXoTsvqD5ZLE+F8II6J2g5NU8J mKX95WafZuQo8DC2EnkDu2jH0kU58PGyJqzlQ1ThJw+E90C4yg55q5ekRRv13L7W4D38+eO6 2LLQyplKiyjXJRFnrYPCQWKdmaoa3+gXm88N0z9SH1VnKDB7nN0WKcgkB8xFFW9ShkDriTj4 WOtBlX5I49L6nc2f5jgRR7ur63vWwWV57guJDYgdbciTIMsoanyOMkblfZko71HlcYOQcext cIzx7W14tLdo5Lbk5sbTLTPCUwIDAQABo4ICcjCCAm4wHQYDVR0OBBYEFJiCut4KQg9+Gt1J iu2nte1qatj0MB8GA1UdIwQYMBaAFOEcbJodbegbsvFP/cZ0LCdXBYhzMIHIBgNVHSAEgcAw gb0wgboGCisGAQQB4GABBgcwgaswJQYIKwYBBQUHAgEWGWh0dHA6Ly93d3ctaWdjLmNlYS5m ci9wYy8wgYEGCCsGAQUFBwICMHUwDRYDQ0VBMAYCAQICAQAaZFZvdXMgZGV2ZXogYWNjZXB0 ZXIgbGEgcG9saXRpcXVlIGRlIGNlcnRpZmljYXRpb24gYXZhbnQgZCd1dGlsaXNlciBjZSBj ZXJ0aWZpY2F0LCBjZi4gd3d3LWlnYy5jZWEuZnIwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAkBgNVHREEHTAbgRlhbGV4YW5kcmUucGV0cmVzY3VAY2VhLmZyMFEGA1Ud HwRKMEgwRqBEoEKGQGh0dHA6Ly9jcmwtYWMtdXRpbGlzYXRldXIuY2VhLmZyL2NybC9jZWFf YWNfdXRpbGlzYXRldXJfMjAzMS5jcmwwcwYJYIZIAYb4QgENBGYWZFZvdXMgZGV2ZXogYWNj ZXB0ZXIgbGEgcG9saXRpcXVlIGRlIGNlcnRpZmljYXRpb24gYXZhbnQgZCd1dGlsaXNlciBj ZSBjZXJ0aWZpY2F0LCBjZi4gd3d3LWlnYy5jZWEuZnIwUAYIKwYBBQUHAQEERDBCMEAGCCsG AQUFBzAChjRodHRwOi8vd3d3LWlnYy5jZWEuZnIvYWMvY2VhX2FjX3V0aWxpc2F0ZXVyXzIw MzEuY2VyMA0GCSqGSIb3DQEBCwUAA4IBAQC77Z707Ko1uZGK3utBHUQUUyTD4pRjmFxFozU2 kwdk6a8hdHTaaRqjPSUIbfeoZVpZCynd12VynalWcoXM40Bf+bhMN3pAavULka7+oAEQyYuI 7OQ8dE/t3R43Ai8dx0npk+ziPQrlD7tAgMsK8Qd+V7ZhUI0A1ANJXWzZ7DYV6jR4t9nwxlsk Kll2PaD+hTIiP86YVsiHMiu0ZhRGrYJf/U1myMQc28b4LdTofpwh22z8DLHlFoGjGipwYbpb oFn998AOsc2fvujB0Y+AahlKK8lecqOTXJNQaRUrE1dl/n2Xu8GK3KIRtcoo7QTDOTzx/BiN 5EC8XdsqNMRXmc1GMIIF1jCCA76gAwIBAgIBCTANBgkqhkiG9w0BAQsFADBeMQswCQYDVQQG EwJGUjEMMAoGA1UECgwDQ0VBMRcwFQYDVQQLDA4wMDAyIDc3NTY4NTAxOTELMAkGA1UECwwC QUMxGzAZBgNVBAMMEkNFQSBBQyBSYWNpbmUgMjA0MTAeFw0xNjA0MTkwNzM0NTNaFw0zMTA0 MTYwNzM0NTNaMD0xCzAJBgNVBAYTAkZSMQwwCgYDVQQKDANDRUExIDAeBgNVBAMMF0NFQSBB QyBVdGlsaXNhdGV1ciAyMDMxMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvWDF ixM71KL9p38YSLTYgXRTceZWAD0RSg7NylBGPXNHYbceuGKDhRIeX58FIi+JiVFFejFI6jpE impm3MgsXQ5O08clieLLBNCjVzpAMPTO5lXuz0j28ey5AVPwhEw7ngUCtmHaWh8v1eY6xrLV C/porFjHycFbd4oj6QLfyghoo/RXWglYPNjilkCBrRe+jKxM3QYYVD6rouvGrF58SlpGCfwX FA88OcYC24kH8YOOYvh8Ld/p+ty7QUiDq53YmVZ5iDUc3pt3r9pN61zJ83FPEhZbC8+KHDTb D0TXaot2No4u8wk0s0jBpicVN4hxfS+LiFcTsFmsorDW6L7GIwIDAQABo4IBvjCCAbowDwYD VR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQU4Rxsmh1t6Buy8U/9xnQsJ1cFiHMwHwYDVR0jBBgw FoAUoBGJ+Jq/poSxKQc3U0Htl5VCex0wgcgGA1UdIASBwDCBvTCBugYKKwYBBAHgYAEGBzCB qzAlBggrBgEFBQcCARYZaHR0cDovL3d3dy1pZ2MuY2VhLmZyL3BjLzCBgQYIKwYBBQUHAgIw dTANFgNDRUEwBgIBAgIBABpkVm91cyBkZXZleiBhY2NlcHRlciBsYSBwb2xpdGlxdWUgZGUg Y2VydGlmaWNhdGlvbiBhdmFudCBkJ3V0aWxpc2VyIGNlIGNlcnRpZmljYXQsIGNmLiB3d3ct aWdjLmNlYS5mcjAOBgNVHQ8BAf8EBAMCAQYwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2Ny bC1hYy1yYWNpbmUuY2VhLmZyL2NybC9hYy1yYWNpbmUtMjA0MS5jcmwwRwYIKwYBBQUHAQEE OzA5MDcGCCsGAQUFBzAChitodHRwOi8vd3d3LWlnYy5jZWEuZnIvYWMvYWMtcmFjaW5lLTIw NDEuY2VyMA0GCSqGSIb3DQEBCwUAA4ICAQALtUqrZEfol/oEtIOlM3SaHCPHblVt8TdY88IB 3qCpg5lJ8rWU7g8jAsc0moYYor0hrvb17XjXECYL76MOJBCQYEKfWnkTYqAyMTsKee+kK8Xw 5P8wzPPjXA3tUvRm8oHEGYcSfLEzdj+UT+F+E4MnkV1nUOCEJq2Krx+lu1IJQJRCbjUQF+ES ICwTDQE7FHzGGKVsGOEjkbYhDS/+4r5GPbc983y5d94S0ISYmM1klOSeRNGelcnl0fJbH0zs 1y8+YJWg3gWL1j7aNo+sQQCrPrYQnmufAm3HQr42+u0AbFvOX5XKwF1YAx7XpJWuUGeXkjqx 8xIWisShEc/S+Gm4mdKcUgym5C7gkA0nzbmBIJI3iSLRqk/m2Re7R5vC3fF3uyfT9mGeAnNa E9b7ZkBzhrSfFToylbvqnAYvxVcYFCE1XhVMHxKvRiiW9L/u9vHuAbTRaXBFzObrXF6UohLR XNqJKKaPYkRLgrVm6b303Ogp50u6DiSgvI4Dh7x9K9IqpJ/+csqdXpoVdhQjhcA5JZRNrv3q 0zVf/Q93GT3VHOgaeMkEa9Sn30x4GmZfuNon/zSagJZkLO72K3wa6XQbGf8MZP/QtSMGPzrN eVUgp4H6l9hcQINVHmimTrcZa7/22K0FD56epY/OqAXwIWOb9i+jdDIoW5c5pW+/BDDasTGC AvMwggLvAgEBMEMwPTELMAkGA1UEBhMCRlIxDDAKBgNVBAoMA0NFQTEgMB4GA1UEAwwXQ0VB IEFDIFV0aWxpc2F0ZXVyIDIwMzECAhgSMA0GCWCGSAFlAwQCAQUAoIIBgTAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODAyMjIxMjI0MjdaMC8GCSqGSIb3 DQEJBDEiBCA8gicuAKmPmtoJOEsh76jAXGVyQ8fwJkU9H1c2a08ADTBSBgkrBgEEAYI3EAQx RTBDMD0xCzAJBgNVBAYTAkZSMQwwCgYDVQQKDANDRUExIDAeBgNVBAMMF0NFQSBBQyBVdGls aXNhdGV1ciAyMDMxAgIYEjBUBgsqhkiG9w0BCRACCzFFoEMwPTELMAkGA1UEBhMCRlIxDDAK BgNVBAoMA0NFQTEgMB4GA1UEAwwXQ0VBIEFDIFV0aWxpc2F0ZXVyIDIwMzECAhgSMGwGCSqG SIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJ KoZIhvcNAQEBBQAEggEArdCwgHwiPunzqP6d90ps50jMB3h3Ju5HkdWF/oFgaVVGaffiF/Im GELPzpRnE8o3eSqKwwDEhjelewNAX7MBIBiRk/aPUt+kgUZ5LzeLEu8uBy4FogQ83OFXIzmL 7iZjHBfYS+EFlEdqIo9Cl4RVitlsGP9dia9leS4Xc97gkNjyqpcsv4RVHZbt6uV8UdyKgdJR zKueexv5xyTbkNHb9SyAyUVIsSfUnGmOZ0y7ytTPaoWSCVagz2LqPtI7mjJN/9KaeEdxVDJD A+HJ44d3oznSHn+6XsanoJfPC9tYASAsIGMHPp/L6e4jGm/U2nj3IN3gFsVgmw4KS8Fxu2FT vgAAAAAAAA== --------------ms040606050605050209090003-- From nobody Thu Feb 22 04:26:58 2018 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 AECED126C2F; Thu, 22 Feb 2018 04:26:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: its@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151930241167.21212.12399339603250896625@ietfa.amsl.com> Date: Thu, 22 Feb 2018 04:26:51 -0800 Archived-At: Subject: [ipwave] I-D Action: draft-ietf-ipwave-ipv6-over-80211ocb-19.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: Thu, 22 Feb 2018 12:26:52 -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 Jerome Haerri Jong-Hyouk Lee Thierry Ernst Filename : draft-ietf-ipwave-ipv6-over-80211ocb-19.txt Pages : 39 Date : 2018-02-22 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. 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-19 https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-19 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 Thu Feb 22 04:29:10 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8158B12EA81 for ; Thu, 22 Feb 2018 04:29:08 -0800 (PST) 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 9dSGtMKCzEV9 for ; Thu, 22 Feb 2018 04:29:06 -0800 (PST) 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 DD408126CBF for ; Thu, 22 Feb 2018 04:29:05 -0800 (PST) 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 w1MCT4Q6026051 for ; Thu, 22 Feb 2018 13:29:04 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 22DE6202F37 for ; Thu, 22 Feb 2018 13:29:04 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 17C34202B76 for ; Thu, 22 Feb 2018 13:29:04 +0100 (CET) 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 w1MCT3fT005067 for ; Thu, 22 Feb 2018 13:29:03 +0100 References: <151930241199.21212.9300629537382236957.idtracker@ietfa.amsl.com> To: "its@ietf.org" From: Alexandre Petrescu X-Forwarded-Message-Id: <151930241199.21212.9300629537382236957.idtracker@ietfa.amsl.com> Message-ID: <58686a6d-934e-46bb-c5c2-09f7b6cdb23a@gmail.com> Date: Thu, 22 Feb 2018 13:29:03 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <151930241199.21212.9300629537382236957.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------DF767681B45996C1910D9C87" Content-Language: fr Archived-At: Subject: [ipwave] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-19.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, 22 Feb 2018 12:29:08 -0000 This is a multi-part message in MIME format. --------------DF767681B45996C1910D9C87 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi IPWAVErs, Following recent comments I uploaded a new version of the IPv6-over-OCB draft. This is the ChangeLog: >    o  Removed the text about fragmentation. > >    o  Removed the mentioning of WSMP and GeoNetworking. > >    o  Removed the explanation of the binary representation of the >       EtherType. > >    o  Rendered normative the paragraph about unicast and multicast >       address mapping. > >    o  Removed paragraph about addressing model, subnet structure and >       easiness of using LLs. > >    o  Clarified the Type/Subtype field in the 802.11 Header. > >    o  Used RECOMMENDED instead of recommended, for the stable interface >       identifiers. Yours, Alex -------- Message transféré -------- Sujet : New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-19.txt Date : Thu, 22 Feb 2018 04:26:51 -0800 De : internet-drafts@ietf.org Pour : Jerome Haerri , ipwave-chairs@ietf.org, Jerome Haerri , Alexandre Petrescu , Alexandre Petrescu , Nabil Benamar , Thierry Ernst , Jong-Hyouk Lee A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-19.txt has been successfully submitted by Alexandre Petrescu and posted to the IETF repository. Name: draft-ietf-ipwave-ipv6-over-80211ocb Revision: 19 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: 2018-02-22 Group: ipwave Pages: 39 URL: https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-19.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-19 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-19 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-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. 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 --------------DF767681B45996C1910D9C87 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi IPWAVErs,

Following recent comments I uploaded a new version of the IPv6-over-OCB draft.

This is the ChangeLog:

   o  Removed the text about fragmentation.

   o  Removed the mentioning of WSMP and GeoNetworking.

   o  Removed the explanation of the binary representation of the
      EtherType.

   o  Rendered normative the paragraph about unicast and multicast
      address mapping.

   o  Removed paragraph about addressing model, subnet structure and
      easiness of using LLs.

   o  Clarified the Type/Subtype field in the 802.11 Header.

   o  Used RECOMMENDED instead of recommended, for the stable interface
      identifiers.

Yours,

Alex



-------- Message transféré --------
Sujet : New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-19.txt
Date : Thu, 22 Feb 2018 04:26:51 -0800
De : internet-drafts@ietf.org
Pour : Jerome Haerri <Jerome.Haerri@eurecom.fr>, ipwave-chairs@ietf.org, Jerome Haerri <jerome.haerri@eurecom.fr>, Alexandre Petrescu <Alexandre.Petrescu@cea.fr>, Alexandre Petrescu <alexandre.petrescu@cea.fr>, Nabil Benamar <n.benamar@est.umi.ac.ma>, Thierry Ernst <thierry.ernst@yogoko.fr>, Jong-Hyouk Lee <jonghyouk@smu.ac.kr> 


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

Name:		draft-ietf-ipwave-ipv6-over-80211ocb
Revision:	19
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:	2018-02-22
Group:		ipwave
Pages:		39
URL:            https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-19.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-19
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-19
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-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.

                                                                                  


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
--------------DF767681B45996C1910D9C87-- From nobody Thu Feb 22 04:39:31 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6171512EA94; Thu, 22 Feb 2018 04:39:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2W7wHyFWG9I; Thu, 22 Feb 2018 04:39:27 -0800 (PST) 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 75F4D12EA87; Thu, 22 Feb 2018 04:39:27 -0800 (PST) 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 w1MCdPx6029196; Thu, 22 Feb 2018 13:39:25 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A37DB202FF1; Thu, 22 Feb 2018 13:39:25 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 926DB202E4B; Thu, 22 Feb 2018 13:39:25 +0100 (CET) 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 w1MCdPZh015206; Thu, 22 Feb 2018 13:39:25 +0100 From: Alexandre PETRESCU To: cjbc@it.uc3m.es, draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org, "its@ietf.org" References: <1519236037.3516.101.camel@it.uc3m.es> Organization: CEA Message-ID: <549cdf14-d0e3-0f45-e7ac-5d925f9c4c53@cea.fr> Date: Thu, 22 Feb 2018 13:39:25 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <1519236037.3516.101.camel@it.uc3m.es> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000203090505020109090803" Archived-At: Subject: Re: [ipwave] Review of draft-ietf-ipwave-ipv6-over-80211ocb-18 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, 22 Feb 2018 12:39:29 -0000 This is a cryptographically signed message in MIME format. --------------ms000203090505020109090803 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: quoted-printable Le 21/02/2018 =C3=A0 19:00, Carlos Jes=C3=BAs Bernardos Cano a =C3=A9crit= =C2=A0: > Hi, > > I've reviewed the latest version of the draft (-18). I have the > following comments: > > - Section 4.1: > > If IPv6 packets of size larger than > the MTU are sent on an 802.11-OCB interface card then the IP stack > MUST fragment. In case there are IPv6 fragments, the subfield > "Fragment number" within the field "Sequence control" of the 802.11= > Data header containing the IPv6 fragment is increased by the MAC > layer. > > I think this has to be removed. The first sentence is obvious (if a > packet is larger than the MTU, it has to be fragmented), and the second= > we have had extensive discussion on it on the mailing list. I also > believe that this would be a layer violation. > > - Section 4.1: > > Non-IP packets such as WAVE Short Message Protocol (WSMP) can be > delivered on 802.11-OCB links. Specifications of these packets are= > 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 GeoNetworking packets have an MTU of 1492 bytes. The > operation of IPv6 over GeoNetworking is specified at > [ETSI-IPv6-GeoNetworking]. > > I think this text can be removed, as it is about non-IP packets and > this document is about IPv6-over-OCB. I tend to prefer to avoid > unnecessary text in normative documents. Agreed. > > - Section 4.2: > > 1 0 0 0 0 1 1 0 1 1 0 1 1 1 0 1 > is the binary representation of the EtherType value 0x86DD. > > Same comment as before. I think this has to be removed. Agreed. > > - Section 4.2.1: > > Additionally, the Ethernet Adaptation Layer performs operations in > relation to IP fragmentation and MTU. One of these operations is > briefly described in Section 4.1. > > Please, remove. The adaptation layer does not perform any fragmentation= > related operation. Agreed. > > - Section 4.3: > > Additionally, if stable identifiers are > needed, it is recommended to follow the Recommendation on Stable > IPv6 > Interface Identifiers [RFC8064]. > > Do we want to make the "recommended" there normative? Yes, RECOMMENDED. > > - Section 4.4 and 4.4.1: I wonder if we want to change the writing so > it is actually normative. For example: > > CURRENT: > > For unicast as for multicast, there is no change from the unicast > and > multicast address mapping format of Ethernet interfaces, as defined= > by sections 6 and 7 of [RFC2464]. > > PROPOSED: > > Unicast and multicast address mapping MUST follow the procedures > specified for Ethernet interfaces in sections 6 and 7 of [RFC2464]. Agreed. > > - Section 4.6: > > 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. > > Please, remove, this text is not needed. Agreed. Alex --------------ms000203090505020109090803 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 C2AwggWCMIIEaqADAgECAgIYEjANBgkqhkiG9w0BAQsFADA9MQswCQYDVQQGEwJGUjEMMAoG A1UECgwDQ0VBMSAwHgYDVQQDDBdDRUEgQUMgVXRpbGlzYXRldXIgMjAzMTAeFw0xNzExMjcx MTUzMThaFw0yMDExMjcxMTUzMThaMFUxCzAJBgNVBAYTAkZSMQwwCgYDVQQKDANjZWExFDAS BgNVBAsMC1V0aWxpc2F0ZXVyMSIwIAYDVQQDDBlQRVRSRVNDVSBBbGV4YW5kcmUgMjIyMDQw MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxflZNm4uFO1gfpGFsdm8+ijK5FnS fr24rrT8KW0oz8cV8u+UZ55M/bqidvqSXGGz3C480T6DZsfXoTsvqD5ZLE+F8II6J2g5NU8J mKX95WafZuQo8DC2EnkDu2jH0kU58PGyJqzlQ1ThJw+E90C4yg55q5ekRRv13L7W4D38+eO6 2LLQyplKiyjXJRFnrYPCQWKdmaoa3+gXm88N0z9SH1VnKDB7nN0WKcgkB8xFFW9ShkDriTj4 WOtBlX5I49L6nc2f5jgRR7ur63vWwWV57guJDYgdbciTIMsoanyOMkblfZko71HlcYOQcext cIzx7W14tLdo5Lbk5sbTLTPCUwIDAQABo4ICcjCCAm4wHQYDVR0OBBYEFJiCut4KQg9+Gt1J iu2nte1qatj0MB8GA1UdIwQYMBaAFOEcbJodbegbsvFP/cZ0LCdXBYhzMIHIBgNVHSAEgcAw gb0wgboGCisGAQQB4GABBgcwgaswJQYIKwYBBQUHAgEWGWh0dHA6Ly93d3ctaWdjLmNlYS5m ci9wYy8wgYEGCCsGAQUFBwICMHUwDRYDQ0VBMAYCAQICAQAaZFZvdXMgZGV2ZXogYWNjZXB0 ZXIgbGEgcG9saXRpcXVlIGRlIGNlcnRpZmljYXRpb24gYXZhbnQgZCd1dGlsaXNlciBjZSBj ZXJ0aWZpY2F0LCBjZi4gd3d3LWlnYy5jZWEuZnIwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAkBgNVHREEHTAbgRlhbGV4YW5kcmUucGV0cmVzY3VAY2VhLmZyMFEGA1Ud HwRKMEgwRqBEoEKGQGh0dHA6Ly9jcmwtYWMtdXRpbGlzYXRldXIuY2VhLmZyL2NybC9jZWFf YWNfdXRpbGlzYXRldXJfMjAzMS5jcmwwcwYJYIZIAYb4QgENBGYWZFZvdXMgZGV2ZXogYWNj ZXB0ZXIgbGEgcG9saXRpcXVlIGRlIGNlcnRpZmljYXRpb24gYXZhbnQgZCd1dGlsaXNlciBj ZSBjZXJ0aWZpY2F0LCBjZi4gd3d3LWlnYy5jZWEuZnIwUAYIKwYBBQUHAQEERDBCMEAGCCsG AQUFBzAChjRodHRwOi8vd3d3LWlnYy5jZWEuZnIvYWMvY2VhX2FjX3V0aWxpc2F0ZXVyXzIw MzEuY2VyMA0GCSqGSIb3DQEBCwUAA4IBAQC77Z707Ko1uZGK3utBHUQUUyTD4pRjmFxFozU2 kwdk6a8hdHTaaRqjPSUIbfeoZVpZCynd12VynalWcoXM40Bf+bhMN3pAavULka7+oAEQyYuI 7OQ8dE/t3R43Ai8dx0npk+ziPQrlD7tAgMsK8Qd+V7ZhUI0A1ANJXWzZ7DYV6jR4t9nwxlsk Kll2PaD+hTIiP86YVsiHMiu0ZhRGrYJf/U1myMQc28b4LdTofpwh22z8DLHlFoGjGipwYbpb oFn998AOsc2fvujB0Y+AahlKK8lecqOTXJNQaRUrE1dl/n2Xu8GK3KIRtcoo7QTDOTzx/BiN 5EC8XdsqNMRXmc1GMIIF1jCCA76gAwIBAgIBCTANBgkqhkiG9w0BAQsFADBeMQswCQYDVQQG EwJGUjEMMAoGA1UECgwDQ0VBMRcwFQYDVQQLDA4wMDAyIDc3NTY4NTAxOTELMAkGA1UECwwC QUMxGzAZBgNVBAMMEkNFQSBBQyBSYWNpbmUgMjA0MTAeFw0xNjA0MTkwNzM0NTNaFw0zMTA0 MTYwNzM0NTNaMD0xCzAJBgNVBAYTAkZSMQwwCgYDVQQKDANDRUExIDAeBgNVBAMMF0NFQSBB QyBVdGlsaXNhdGV1ciAyMDMxMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvWDF ixM71KL9p38YSLTYgXRTceZWAD0RSg7NylBGPXNHYbceuGKDhRIeX58FIi+JiVFFejFI6jpE impm3MgsXQ5O08clieLLBNCjVzpAMPTO5lXuz0j28ey5AVPwhEw7ngUCtmHaWh8v1eY6xrLV C/porFjHycFbd4oj6QLfyghoo/RXWglYPNjilkCBrRe+jKxM3QYYVD6rouvGrF58SlpGCfwX FA88OcYC24kH8YOOYvh8Ld/p+ty7QUiDq53YmVZ5iDUc3pt3r9pN61zJ83FPEhZbC8+KHDTb D0TXaot2No4u8wk0s0jBpicVN4hxfS+LiFcTsFmsorDW6L7GIwIDAQABo4IBvjCCAbowDwYD VR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQU4Rxsmh1t6Buy8U/9xnQsJ1cFiHMwHwYDVR0jBBgw FoAUoBGJ+Jq/poSxKQc3U0Htl5VCex0wgcgGA1UdIASBwDCBvTCBugYKKwYBBAHgYAEGBzCB qzAlBggrBgEFBQcCARYZaHR0cDovL3d3dy1pZ2MuY2VhLmZyL3BjLzCBgQYIKwYBBQUHAgIw dTANFgNDRUEwBgIBAgIBABpkVm91cyBkZXZleiBhY2NlcHRlciBsYSBwb2xpdGlxdWUgZGUg Y2VydGlmaWNhdGlvbiBhdmFudCBkJ3V0aWxpc2VyIGNlIGNlcnRpZmljYXQsIGNmLiB3d3ct aWdjLmNlYS5mcjAOBgNVHQ8BAf8EBAMCAQYwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2Ny bC1hYy1yYWNpbmUuY2VhLmZyL2NybC9hYy1yYWNpbmUtMjA0MS5jcmwwRwYIKwYBBQUHAQEE OzA5MDcGCCsGAQUFBzAChitodHRwOi8vd3d3LWlnYy5jZWEuZnIvYWMvYWMtcmFjaW5lLTIw NDEuY2VyMA0GCSqGSIb3DQEBCwUAA4ICAQALtUqrZEfol/oEtIOlM3SaHCPHblVt8TdY88IB 3qCpg5lJ8rWU7g8jAsc0moYYor0hrvb17XjXECYL76MOJBCQYEKfWnkTYqAyMTsKee+kK8Xw 5P8wzPPjXA3tUvRm8oHEGYcSfLEzdj+UT+F+E4MnkV1nUOCEJq2Krx+lu1IJQJRCbjUQF+ES ICwTDQE7FHzGGKVsGOEjkbYhDS/+4r5GPbc983y5d94S0ISYmM1klOSeRNGelcnl0fJbH0zs 1y8+YJWg3gWL1j7aNo+sQQCrPrYQnmufAm3HQr42+u0AbFvOX5XKwF1YAx7XpJWuUGeXkjqx 8xIWisShEc/S+Gm4mdKcUgym5C7gkA0nzbmBIJI3iSLRqk/m2Re7R5vC3fF3uyfT9mGeAnNa E9b7ZkBzhrSfFToylbvqnAYvxVcYFCE1XhVMHxKvRiiW9L/u9vHuAbTRaXBFzObrXF6UohLR XNqJKKaPYkRLgrVm6b303Ogp50u6DiSgvI4Dh7x9K9IqpJ/+csqdXpoVdhQjhcA5JZRNrv3q 0zVf/Q93GT3VHOgaeMkEa9Sn30x4GmZfuNon/zSagJZkLO72K3wa6XQbGf8MZP/QtSMGPzrN eVUgp4H6l9hcQINVHmimTrcZa7/22K0FD56epY/OqAXwIWOb9i+jdDIoW5c5pW+/BDDasTGC AvMwggLvAgEBMEMwPTELMAkGA1UEBhMCRlIxDDAKBgNVBAoMA0NFQTEgMB4GA1UEAwwXQ0VB IEFDIFV0aWxpc2F0ZXVyIDIwMzECAhgSMA0GCWCGSAFlAwQCAQUAoIIBgTAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODAyMjIxMjM5MjVaMC8GCSqGSIb3 DQEJBDEiBCBLkjVRPPjXybfr4I7stxgrrdtwLRGBCKMO9ib2FSXTuDBSBgkrBgEEAYI3EAQx RTBDMD0xCzAJBgNVBAYTAkZSMQwwCgYDVQQKDANDRUExIDAeBgNVBAMMF0NFQSBBQyBVdGls aXNhdGV1ciAyMDMxAgIYEjBUBgsqhkiG9w0BCRACCzFFoEMwPTELMAkGA1UEBhMCRlIxDDAK BgNVBAoMA0NFQTEgMB4GA1UEAwwXQ0VBIEFDIFV0aWxpc2F0ZXVyIDIwMzECAhgSMGwGCSqG SIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJ KoZIhvcNAQEBBQAEggEAAJ4suJY9ZrshLtdXPTrDrR4fQ8iP6blWKmWZbsLDLTxJg3Vpz7dx eLDNVbC15i6N97TnQZCGz/84+9ej2qnCMfyymRb7sKqUOjoK+qX+f6heawxYITKbWzSAA1+2 fhAMZgYjqQFKS26RpzSDfagM/g/TGwp3i4uwxBTCSaUv8OxvYg3hwZNXYtVkIJ4lIxRAo8+X c86JZTL969N3CQxasVzWckpiAZr5Dm45C9/b0vXJj1Z3/FSg1yDO0zDVgGmwtodP+3O1gmEP psePDNSEvWs5SmUxIg8u0sK4Fxw7uc4ILyrK1QXyOShmDsspvrQNe0qFMX3jZUcAX7zeAISl agAAAAAAAA== --------------ms000203090505020109090803-- From nobody Fri Feb 23 09:32:34 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C13812D77B for ; Fri, 23 Feb 2018 09:32:33 -0800 (PST) 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 u2oWtlW88Lph for ; Fri, 23 Feb 2018 09:32:31 -0800 (PST) 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 129941241F8 for ; Fri, 23 Feb 2018 09:32:30 -0800 (PST) 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 w1NHWTq2042966 for ; Fri, 23 Feb 2018 18:32:29 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4F311204F97 for ; Fri, 23 Feb 2018 18:32:29 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 2A1B1204FD0 for ; Fri, 23 Feb 2018 18:32:29 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w1NHWSbe013639 for ; Fri, 23 Feb 2018 18:32:28 +0100 To: its@ietf.org References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> From: Alexandre Petrescu Message-ID: <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> Date: Fri, 23 Feb 2018 18:32:28 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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: Fri, 23 Feb 2018 17:32:33 -0000 IPWAVErs, The issue below is an important issue. I want to ask the group which of 802.11 Data headers or 802.11 QoS Data headers are more likely to be the right ones? In order to RECOMMEND in this draft to carry IP messages. For my part I tend to prefer to recommend 802.11 Data (Subtype 0). Many implementations of BSM in America and CAM and SPAT in Europe are sent with 802.11 QoS Data headers (Subtype 8). Numerous other implementations of CAM and DENM in Europe are sent with 802.11 Data headers instead (Subtype 0). This means that a CAM sent by implementation of company X is not understood by a CAM receiver open source rendits for example, because of that difference in Subtype. If we put that CAM on IP there will still be lack of interoperability, unless we recommend IP to be carried by a particular 802.11 header (Data or QoS Data). Alex Le 22/02/2018 à 13:21, Alexandre Petrescu a écrit : > > > Le 21/02/2018 à 08:43, Abdussalam Baryun a écrit : >> Hi WG, >> >> I maybe missed the discussion regarding the below, >> >> draft>page 7> >> >> 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. >> >> AB> the HEX number shows 16 bit which is not number of bits for >> virsion+type+subtype. > > I agree with you. There was an error in interpreting the dump. > > I propose to better interpret the "Type/Subtype" as to be of length 6 > bits. Leftmost 4 bits is Subtype and rightmost 2 bits is Type. > > The Type is always of value 2, to mean Data frame. > > The SubType is usually value 0, which means 802.11 Data. > > Some times the Subtype is value 8. This means this is 802.11 QoS > Data. > > As such, the text becomes: >> The distinction between the two formats is given by the value of >> the field "Subtype" in the Frame Control Field. The value of the >> field "Subtype" in the 802.11 Data header is 0x0. The value of the >> field "Subtype" in the 802.11 QoS header is 8. > > Unless, of course, we want to remove the description of this > distinction between 802.11 QoS Data and 802.11 Data headers. > > Alex > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its From nobody Fri Feb 23 09:38:56 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8DA12D77B for ; Fri, 23 Feb 2018 09:38:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 nCFtOjny8igF for ; Fri, 23 Feb 2018 09:38:54 -0800 (PST) Received: from mail-pl0-x236.google.com (mail-pl0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0094A1241F8 for ; Fri, 23 Feb 2018 09:38:53 -0800 (PST) Received: by mail-pl0-x236.google.com with SMTP id w21so5268840plp.11 for ; Fri, 23 Feb 2018 09:38:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=IJtJtnHgdXHv91wl5cP3LWFHE+AhPy5UiKTBTAl8lRc=; b=hA3kOdS3l+d9rf0ERBsRh6EI10avO+XdIZwgJvQtJkDb/Gs0qEez7lNqOgJqfZGfu4 ZBWesR+9nzagvfleEUqZPOx7/PEv6FVlT8ICBVxOZSfOGmoTeHojojTl6DpGBV6jnhBX tL4509RFBuA5zYu8xlZr41Nx3+hr4/eqXjlgChLpK/6AVXDT2QFTQAgtWwRfsit69YEn NFGA9x5IWzSzKTAG+ohqtYCY1e6L0ykmGxT0Kdb/mp6A0f4btlbfuae7wUsyn7DLW+Bg CpbF7wkSRBVVvfJJoYl/SwEXgo1uRVT19hAqEiKxdu9raiypYNp5w44383D5lWNC7R42 HvBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=IJtJtnHgdXHv91wl5cP3LWFHE+AhPy5UiKTBTAl8lRc=; b=N89wU1eljZiRvDhb9UuAtqk32r/feqt8VH/HGOgFUuskxhQN2JG5AFI/IrUB17bSGM ruAiGLyMyWq1yiiW5+gj2W8zLUYFZwqOQSVPkNgCYFVr7np1DRBVtlhaUCMaTbUpvhZ+ 22CLlyFgF9RciRNipGAKMF5OODlY7T9CeW42rlQK3w8SQw0LgyZ3dGxQdsEtsuRAZ21y 3vf2u6RPqer71ypOQC7XbOdEKA5Ol5QDTTSFK/PAGsk/c+sEyP3z3wQr8VHL81kczPAU VLUNEuQbSIz0wzez+xy1eXP6ccvBlV/d/Hjs0/K3bSBxz0BMnkvocntcHy1UZJiR0R6S o2mw== X-Gm-Message-State: APf1xPDWXNlq7MxkwgahKEtip+p5kYhwBuwv5VjLuEsK9v5jhxqx+Ud8 HUfQISGCRk1Y7+/VRZ//cgI= X-Google-Smtp-Source: AH8x227rbKCsBt4S56zjDA2mmuaCBOHPBdQxboZZ2rYWxl5j+xcslaw17r1lgneUcD3GK41PhmUCUg== X-Received: by 2002:a17:902:d893:: with SMTP id b19-v6mr2384080plz.332.1519407533618; Fri, 23 Feb 2018 09:38:53 -0800 (PST) Received: from [172.22.228.216] ([162.210.130.3]) by smtp.gmail.com with ESMTPSA id 205sm6197639pfy.117.2018.02.23.09.38.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Feb 2018 09:38:52 -0800 (PST) From: Tony Li Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A7BE30BD-E2DF-484E-B50B-E5CBB5435199" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Fri, 23 Feb 2018 09:38:51 -0800 In-Reply-To: <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> Cc: its@ietf.org To: Alexandre Petrescu References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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: Fri, 23 Feb 2018 17:38:55 -0000 --Apple-Mail=_A7BE30BD-E2DF-484E-B50B-E5CBB5435199 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > If we put that CAM on IP there will still be lack of interoperability, > unless we recommend IP to be carried by a particular 802.11 header = (Data > or QoS Data). I would propose that we use the Data header. My experience with the QoS = Data with Wi-Fi was that there wasn=E2=80=99t enough of a performance = difference with QoS for it to make a difference to the IP layer. Tony --Apple-Mail=_A7BE30BD-E2DF-484E-B50B-E5CBB5435199 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

If we put that CAM on IP there will still be = lack of interoperability,
unless we recommend IP to be = carried by a particular 802.11 header (Data
or QoS Data).


I would = propose that we use the Data header. My experience with the QoS Data = with Wi-Fi was that there wasn=E2=80=99t enough of a performance = difference with QoS for it to make a difference to the IP = layer.

Tony

= --Apple-Mail=_A7BE30BD-E2DF-484E-B50B-E5CBB5435199-- From nobody Fri Feb 23 12:16:17 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E96E51205F0 for ; Fri, 23 Feb 2018 12:16:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FD8cKckPOmlW for ; Fri, 23 Feb 2018 12:16:13 -0800 (PST) Received: from smtp2.eurecom.fr (smtp2.eurecom.fr [193.55.113.211]) by ietfa.amsl.com (Postfix) with ESMTP id 4707C1201F8 for ; Fri, 23 Feb 2018 12:16:13 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.47,383,1515452400"; d="scan'208";a="7696249" Received: from monza.eurecom.fr ([192.168.106.15]) by drago2i.eurecom.fr with ESMTP; 23 Feb 2018 21:16:11 +0100 Received: from xerus29 (unknown [192.168.200.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by monza.eurecom.fr (Postfix) with ESMTPSA id C8F3F2C1F; Fri, 23 Feb 2018 21:16:11 +0100 (CET) From: =?utf-8?B?SsOpcsO0bWUgSMOkcnJp?= To: "'Alexandre Petrescu'" , References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> In-Reply-To: <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> Date: Fri, 23 Feb 2018 21:16:11 +0100 Organization: EURECOM Message-ID: <006301d3ace3$25f9d500$71ed7f00$@eurecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHelLAw/aN7IRfcwiTBG/gKcgHVEwGONDnFAivYBTejfsgasA== Content-Language: en-us Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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: Fri, 23 Feb 2018 20:16:16 -0000 Hi Alex, If we consider ETSI (and I guess WAVE), the use of 802.11 QoS is due to = the requirements of the Traffic Classes as LL priorization (DENM = priority over basic CAM and priority over long CAM etc..). This is also = required by the DCC implementation and the CAR 2 CAR profile in EU.=20 Now, as you abstract ETSI and WAVE (thus pure IP), my understanding is = that QoS remains required from the IEEE 802.11p (ok, IEEE 802.11-2016 = OCB) as there is a specification of the EDCA parameters for OCB. = Besides, I do not think it costs much to keep the EDCA in, as it first = allows to safe a half of the MAC queueing time (the EDCA parameters for = the two low AC are less, up to a quarter of a DIFS...so, it could be = beneficial to allow this even for IP. Second, the EDCA allows TXOpps = (Transmit Opportunities)..although put to 'zero' for OCB (I think), this = mechanism still allows an AP to reserve a given time a long(er) = connectivity with one device (e. streaming of video etc..). Finally, it = does not cost anything..you can always take the lowest AC and you get = the same behavior as non-QoS.. Bottom line, the fact that some IP implementation to decode OCB assume = non-QoS frames looks more to me like an implementation error and we = should not propagate this... Btw, I remains really not convinced of the use of CAM over IP..this is a = recurring discussion over the thread...C-V2X will not use IP for CAM, = ETSI and WAVE will not use IP for CAM...the basic CAMs are used for pure = positioning and the recent 'increase' of information put in CAM looks to = be like a bad strategy as we end up having a container carrying too many = things and being too big for what it is...(WLAN is good at squeezing = various small packets but really not good at big things especially in = broadcast mode)...a better strategy would be to define new messages = tailored to the information needs, and have smart service = scheduling...(especially benefiting from IP-related mechanisms) BR, J=C3=A9r=C3=B4me -----Original Message----- From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu Sent: Friday 23 February 2018 18:32 To: its@ietf.org Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in = IPv6-over-802.11-OCB IPWAVErs, The issue below is an important issue. I want to ask the group which of 802.11 Data headers or 802.11 QoS Data = headers are more likely to be the right ones? In order to RECOMMEND in = this draft to carry IP messages. For my part I tend to prefer to recommend 802.11 Data (Subtype 0). Many implementations of BSM in America and CAM and SPAT in Europe are = sent with 802.11 QoS Data headers (Subtype 8). Numerous other = implementations of CAM and DENM in Europe are sent with 802.11 Data = headers instead (Subtype 0). This means that a CAM sent by implementation of company X is not = understood by a CAM receiver open source rendits for example, because of = that difference in Subtype. If we put that CAM on IP there will still be lack of interoperability, = unless we recommend IP to be carried by a particular 802.11 header (Data = or QoS Data). Alex Le 22/02/2018 =C3=A0 13:21, Alexandre Petrescu a =C3=A9crit : >=20 >=20 > Le 21/02/2018 =C3=A0 08:43, Abdussalam Baryun a =C3=A9crit : >> Hi WG, >>=20 >> I maybe missed the discussion regarding the below, >>=20 >> draft>page 7> >>=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 >> AB> the HEX number shows 16 bit which is not number of bits for >> virsion+type+subtype. >=20 > I agree with you. There was an error in interpreting the dump. >=20 > I propose to better interpret the "Type/Subtype" as to be of length 6 = > bits. Leftmost 4 bits is Subtype and rightmost 2 bits is Type. >=20 > The Type is always of value 2, to mean Data frame. >=20 > The SubType is usually value 0, which means 802.11 Data. >=20 > Some times the Subtype is value 8. This means this is 802.11 QoS=20 > Data. >=20 > As such, the text becomes: >> The distinction between the two formats is given by the value of the=20 >> field "Subtype" in the Frame Control Field. The value of the field=20 >> "Subtype" in the 802.11 Data header is 0x0. The value of the field=20 >> "Subtype" in the 802.11 QoS header is 8. >=20 > Unless, of course, we want to remove the description of this=20 > distinction between 802.11 QoS Data and 802.11 Data headers. >=20 > Alex >=20 > _______________________________________________ its mailing list=20 > its@ietf.org https://www.ietf.org/mailman/listinfo/its _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its From nobody Fri Feb 23 12:21:55 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE9D4120724 for ; Fri, 23 Feb 2018 12:21:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w--r8c_Xu452 for ; Fri, 23 Feb 2018 12:21:52 -0800 (PST) Received: from smtp2.eurecom.fr (smtp2.eurecom.fr [193.55.113.211]) by ietfa.amsl.com (Postfix) with ESMTP id F369A1205F0 for ; Fri, 23 Feb 2018 12:21:51 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.47,383,1515452400"; d="scan'208,217";a="7696263" Received: from monza.eurecom.fr ([192.168.106.15]) by drago2i.eurecom.fr with ESMTP; 23 Feb 2018 21:21:51 +0100 Received: from xerus29 (unknown [192.168.200.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by monza.eurecom.fr (Postfix) with ESMTPSA id CF9EE2C42; Fri, 23 Feb 2018 21:21:50 +0100 (CET) From: =?utf-8?B?SsOpcsO0bWUgSMOkcnJp?= To: "'Tony Li'" , "'Alexandre Petrescu'" Cc: References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> In-Reply-To: Date: Fri, 23 Feb 2018 21:21:50 +0100 Organization: EURECOM Message-ID: <006b01d3ace3$f0168e00$d043aa00$@eurecom.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006C_01D3ACEC.51DDDC30" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHelLAw/aN7IRfcwiTBG/gKcgHVEwGONDnFAivYBTcB5QRVg6NvpIAw Content-Language: en-us Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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: Fri, 23 Feb 2018 20:21:54 -0000 This is a multipart message in MIME format. ------=_NextPart_000_006C_01D3ACEC.51DDDC30 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable HI Tony, =20 The word QoS is misleading in WiFi=E2=80=A6it is not QoS and is only a = prioritization of different =E2=80=98classes=E2=80=99 of traffic. I am = surprised though that IP could not benefit much from it=E2=80=A6maybe = was it due to TCP? I mean, TX opp are a really beneficial aspect if you = need to advantage one MN over others. =20 BR, =20 J=C3=A9r=C3=B4me =20 From: its [mailto:its-bounces@ietf.org] On Behalf Of Tony Li Sent: Friday 23 February 2018 18:39 To: Alexandre Petrescu Cc: its@ietf.org Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in = IPv6-over-802.11-OCB =20 =20 If we put that CAM on IP there will still be lack of interoperability, unless we recommend IP to be carried by a particular 802.11 header (Data or QoS Data). =20 =20 I would propose that we use the Data header. My experience with the QoS = Data with Wi-Fi was that there wasn=E2=80=99t enough of a performance = difference with QoS for it to make a difference to the IP layer. =20 Tony =20 ------=_NextPart_000_006C_01D3ACEC.51DDDC30 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

HI Tony,

 

The word QoS is misleading in WiFi=E2=80=A6it is not QoS and is only = a prioritization of different =E2=80=98classes=E2=80=99 of traffic. I am = surprised though that IP could not benefit much from it=E2=80=A6maybe = was it due to TCP? I mean, TX opp are a really beneficial aspect if you = need to advantage one MN over others.

 

BR,

 

J=C3=A9r=C3=B4me

 

From:= = its [mailto:its-bounces@ietf.org] On Behalf Of Tony = Li
Sent: Friday 23 February 2018 18:39
To: Alexandre = Petrescu
Cc: its@ietf.org
Subject: Re: [ipwave] = 802.11 Data vs 802.11 QoS Data in = IPv6-over-802.11-OCB

 

 



If we put = that CAM on IP there will still be lack of interoperability,
unless = we recommend IP to be carried by a particular 802.11 header (Data
or = QoS Data).

 

 

I = would propose that we use the Data header. My experience with the QoS = Data with Wi-Fi was that there wasn=E2=80=99t enough of a performance = difference with QoS for it to make a difference to the IP = layer.

 

Tony

 

------=_NextPart_000_006C_01D3ACEC.51DDDC30-- From nobody Fri Feb 23 12:34:38 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B801F124B17 for ; Fri, 23 Feb 2018 12:34:36 -0800 (PST) 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 CmOO77ONEI9y for ; Fri, 23 Feb 2018 12:34:35 -0800 (PST) Received: from resqmta-po-04v.sys.comcast.net (resqmta-po-04v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:163]) (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 6E3761205F0 for ; Fri, 23 Feb 2018 12:34:35 -0800 (PST) Received: from resomta-po-05v.sys.comcast.net ([96.114.154.229]) by resqmta-po-04v.sys.comcast.net with ESMTP id pK35eXpl3ge0CpK39eKs1Y; Fri, 23 Feb 2018 20:34:35 +0000 Received: from [172.22.228.216] ([162.210.130.3]) by resomta-po-05v.sys.comcast.net with SMTP id pK0zejf5CpYf5pK11efIQA; Fri, 23 Feb 2018 20:32:32 +0000 From: Tony Li Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_BE439C03-F39B-42D4-84E0-03A1EF232342" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Fri, 23 Feb 2018 12:32:20 -0800 In-Reply-To: <006b01d3ace3$f0168e00$d043aa00$@eurecom.fr> Cc: Alexandre Petrescu , its@ietf.org To: =?utf-8?B?SsOpcsO0bWUgSMOkcnJp?= References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <006b01d3ace3$f0168e00$d043aa00$@eurecom.fr> X-Mailer: Apple Mail (2.3445.5.20) X-CMAE-Envelope: MS4wfMg2dF3D8r4Khf9RUeuM0wCrcrOCzBTY9zUqPt4sQFKFVf8AXl3xy9CcNOc4YpEK3g4sg2q1YLpBnzcHH/oPtRIku8q/Vmbzu6amcnqK+Rd9w/Je7tFt 2pFKMTYlxessuVTp+gj6pNAgHppdf75jdnEI5CXjBWFDXHBvt/AfXw5faHLRz/wcBXPgNYGHbWIPsqS03P9OxD2k+43D+0vBnNZ5TvDKyAUQ4gw7ntVGTK/a U0t9JdvHIq21XpiiSLUgCQ== Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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: Fri, 23 Feb 2018 20:34:37 -0000 --Apple-Mail=_BE439C03-F39B-42D4-84E0-03A1EF232342 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > The word QoS is misleading in WiFi=E2=80=A6it is not QoS and is only a = prioritization of different =E2=80=98classes=E2=80=99 of traffic. I am = surprised though that IP could not benefit much from it=E2=80=A6maybe = was it due to TCP? I mean, TX opp are a really beneficial aspect if you = need to advantage one MN over others. For prioritization to have any significant effect on IP, you need = consistent QoS treatment end-to-end, which the Internet simply does not = provide. Further, the queues that build up on the Wi-Fi AP weren=E2=80=99t= ever sufficient to cause any useful prioritization.=20 The downside, of course, is the larger header size with QoS. Tony --Apple-Mail=_BE439C03-F39B-42D4-84E0-03A1EF232342 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

The word QoS is misleading = in WiFi=E2=80=A6it is not QoS and is only a prioritization of different = =E2=80=98classes=E2=80=99 of traffic. I am surprised though that IP = could not benefit much from it=E2=80=A6maybe was it due to TCP? I mean, = TX opp are a really beneficial aspect if you need to advantage one MN = over others.


For prioritization to = have any significant effect on IP, you need consistent QoS treatment = end-to-end, which the Internet simply does not provide. Further, the = queues that build up on the Wi-Fi AP weren=E2=80=99t ever sufficient to = cause any useful prioritization. 

The downside, of course, is the larger = header size with QoS.

Tony

= --Apple-Mail=_BE439C03-F39B-42D4-84E0-03A1EF232342-- From nobody Fri Feb 23 12:40:17 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88B7E1205F0 for ; Fri, 23 Feb 2018 12:40:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 UWOHPUj8Z7Qe for ; Fri, 23 Feb 2018 12:40:13 -0800 (PST) Received: from mail-pl0-x22a.google.com (mail-pl0-x22a.google.com [IPv6:2607:f8b0:400e:c01::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 C45C61201F8 for ; Fri, 23 Feb 2018 12:40:13 -0800 (PST) Received: by mail-pl0-x22a.google.com with SMTP id s13so5538757plq.6 for ; Fri, 23 Feb 2018 12:40:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:subject:from:to:cc:date:in-reply-to:references :mime-version:content-transfer-encoding; bh=WXaY44RXz5IKaFVXgPfe5c0BUXUHd9MwPVuWVQY/daI=; b=eXQfssTuP5qybUSBEodiniIKXDhEoIJRyT+jHPW++TaZm/e3UGlaqB49h6Kh1svG8l 6LmzmUUk+JA7HABK1+3dRP5vBpq0ACKBczaaDENOhbkkuRxTIQXRbP3WKUYQ0rcBNBOo DQMOEhCcaU4MewQWq1x6bLIRcJCaSWXGq2e1hRM+pie470wvKDhv9MjQju2Ms81Pnnox cSYzBLVERJo1DSeKk8JSErlGxAozdNoaRAQPQcI55SBt3gNJvtWfwKFw9bKDrXYTWbDb eKZgzGMjLTKNR2Syfu9jICb0PtBcSM/PlMOleM2zalut0gHBhTbgl/gEBVgRE/xgfCFi BAnw== 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:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=WXaY44RXz5IKaFVXgPfe5c0BUXUHd9MwPVuWVQY/daI=; b=n15wAutb+fV15PyDEQl6Fbl5lCYp3oMs5BVwNGHqtuO1WM2JW5lTizn4NiiDQ4M4rF +7bvH8RFonAfl2GWcWneLqZMh08/QMuehRIzgUGzgnUQybekTLlSU6Kd6Loo0re2t1n9 HNN6K/eNxJL77tcsxUhtGZnp2xpfw0Ra2SYCORhQnVNCksGTDlt9sM+7ie24QNcpgk/Y OUPrrz66NWdW5nXHwXOiNJRwEplxTsNzmHJ6oFhA6nGM+Ht47H+GUiNTNG4ezNGI2J5E wf0K1JOoYbDzKGt2mbXiZRHRD4agUlKG9nOhgQX4cKgkbZy7tsBxCMFUYqSRRyWRTR09 +GWw== X-Gm-Message-State: APf1xPCYKiEG6SDZlJIFjiOEl0WR0G1/TghKnL787qvj+X5jKBlJFDYa Q27zCl1IYwvGBYpd5CoqcuM= X-Google-Smtp-Source: AH8x224YLOXo5GUEWnNvuNlM8c+KGzeAMa3ByjTfGZDZwC7Ht7LZDz0gBY4F1JB0aS/Z/Jxm6jbYSQ== X-Received: by 2002:a17:902:ab8c:: with SMTP id f12-v6mr2777713plr.171.1519418413294; Fri, 23 Feb 2018 12:40:13 -0800 (PST) Received: from localhost.localdomain (c-71-198-163-21.hsd1.ca.comcast.net. [71.198.163.21]) by smtp.gmail.com with ESMTPSA id x9sm4631699pgc.81.2018.02.23.12.40.12 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 23 Feb 2018 12:40:12 -0800 (PST) Message-ID: <1519418411.2226.429.camel@gmail.com> From: Rex Buddenberg To: =?ISO-8859-1?Q?J=E9r=F4me_H=E4rri?= , 'Tony Li' , 'Alexandre Petrescu' Cc: its@ietf.org Date: Fri, 23 Feb 2018 12:40:11 -0800 In-Reply-To: <006b01d3ace3$f0168e00$d043aa00$@eurecom.fr> References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <006b01d3ace3$f0168e00$d043aa00$@eurecom.fr> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.5.2 (3.18.5.2-1.fc23) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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: Fri, 23 Feb 2018 20:40:15 -0000 Jerome, > IP could not benefit much from it… ??  Was IP using diff-serv?  It would seem that if you are going to shuffle queues (sort traffic) at layer 2, you need to at layer 3 as well.  And the sorting flags need to be coherent at both layers?? On Fri, 2018-02-23 at 21:21 +0100, Jérôme Härri wrote: > HI Tony, >   > The word QoS is misleading in WiFi…it is not QoS and is only a > prioritization of different ‘classes’ of traffic. I am surprised > though that IP could not benefit much from it…maybe was it due to > TCP? I mean, TX opp are a really beneficial aspect if you need to > advantage one MN over others. >   > BR, >   > Jérôme >   > From: its [mailto:its-bounces@ietf.org] On Behalf Of Tony Li > Sent: Friday 23 February 2018 18:39 > To: Alexandre Petrescu > Cc: its@ietf.org > Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over- > 802.11-OCB >   >   > > > If we put that CAM on IP there will still be lack of > interoperability, > unless we recommend IP to be carried by a particular 802.11 header > (Data > or QoS Data). >   >   > I would propose that we use the Data header. My experience with the > QoS Data with Wi-Fi was that there wasn’t enough of a performance > difference with QoS for it to make a difference to the IP layer. >   > Tony >   > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Sat Feb 24 03:55:38 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D47812D82F for ; Sat, 24 Feb 2018 03:55:36 -0800 (PST) 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 KR-i6nCLgaRF for ; Sat, 24 Feb 2018 03:55:35 -0800 (PST) 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 DC7C5127871 for ; Sat, 24 Feb 2018 03:55:34 -0800 (PST) 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 w1OBtWig009080; Sat, 24 Feb 2018 12:55:32 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 26745200F32; Sat, 24 Feb 2018 12:55:32 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 16DE8200EF8; Sat, 24 Feb 2018 12:55:32 +0100 (CET) Received: from [132.166.84.13] ([132.166.84.13]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w1OBtVXC012982; Sat, 24 Feb 2018 12:55:31 +0100 To: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , "'Tony Li'" Cc: its@ietf.org References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <006b01d3ace3$f0168e00$d043aa00$@eurecom.fr> From: Alexandre Petrescu Message-ID: <47719743-a074-4c43-eae7-8afc3ca93237@gmail.com> Date: Sat, 24 Feb 2018 12:55:31 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <006b01d3ace3$f0168e00$d043aa00$@eurecom.fr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 24 Feb 2018 11:55:36 -0000 The header is called "802.11 QoS Data" by wireshark. I find the use of "QoS" in line with the use of "traffic classes". IP _could_ benefit from it, but in order to describe a mapping, it should be in another document. Such mappings are not currently developped nor implemented (e.g. map a Traffic Class field in the IP header into a traffic class field in the 802.11 QoS Data header). Alex Le 23/02/2018 à 21:21, Jérôme Härri a écrit : > HI Tony, > > The word QoS is misleading in WiFi…it is not QoS and is only a > prioritization of different ‘classes’ of traffic. I am surprised though > that IP could not benefit much from it…maybe was it due to TCP? I mean, > TX opp are a really beneficial aspect if you need to advantage one MN > over others. > > BR, > > Jérôme > > *From:*its [mailto:its-bounces@ietf.org] *On Behalf Of *Tony Li > *Sent:* Friday 23 February 2018 18:39 > *To:* Alexandre Petrescu > *Cc:* its@ietf.org > *Subject:* Re: [ipwave] 802.11 Data vs 802.11 QoS Data in > IPv6-over-802.11-OCB > > > > If we put that CAM on IP there will still be lack of interoperability, > unless we recommend IP to be carried by a particular 802.11 header (Data > or QoS Data). > > I would propose that we use the Data header. My experience with the QoS > Data with Wi-Fi was that there wasn’t enough of a performance difference > with QoS for it to make a difference to the IP layer. > > Tony > From nobody Sat Feb 24 04:53:43 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46E09129C59 for ; Sat, 24 Feb 2018 04:53:41 -0800 (PST) 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 wDsnrKLWyLbH for ; Sat, 24 Feb 2018 04:53:39 -0800 (PST) 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 26474120227 for ; Sat, 24 Feb 2018 04:53:38 -0800 (PST) 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 w1OCrabU171160; Sat, 24 Feb 2018 13:53:36 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 40FA820127B; Sat, 24 Feb 2018 13:53:36 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 338B1200ECC; Sat, 24 Feb 2018 13:53:36 +0100 (CET) Received: from [132.166.84.13] ([132.166.84.13]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w1OCrZo2024245; Sat, 24 Feb 2018 13:53:35 +0100 To: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , its@ietf.org References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <006301d3ace3$25f9d500$71ed7f00$@eurecom.fr> From: Alexandre Petrescu Message-ID: Date: Sat, 24 Feb 2018 13:53:35 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <006301d3ace3$25f9d500$71ed7f00$@eurecom.fr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 24 Feb 2018 12:53:41 -0000 Le 23/02/2018 à 21:16, Jérôme Härri a écrit : > Hi Alex, > > If we consider ETSI (and I guess WAVE), the use of 802.11 QoS is due > to the requirements of the Traffic Classes as LL priorization (DENM > priority over basic CAM and priority over long CAM etc..). This is > also required by the DCC implementation and the CAR 2 CAR profile in > EU. That is a requirement. But is there an implementation of mapping the priority of CAM over DENM into a QoS Control field in QoS Data Header? I doubt there is, because the implementations of CAM I see put the Priority field to 6, which means Voice. So they transmit CAM as Voice even though it is not voice. We can not reckon in IPv6-over-OCB document something which makes little sense (send CAM as Voice). > Now, as you abstract ETSI and WAVE (thus pure IP), my understanding > is that QoS remains required from the IEEE 802.11p (ok, IEEE > 802.11-2016 OCB) as there is a specification of the EDCA parameters > for OCB. Besides, I do not think it costs much to keep the EDCA in, > as it first allows to safe a half of the MAC queueing time (the EDCA > parameters for the two low AC are less, up to a quarter of a > DIFS...so, it could be beneficial to allow this even for IP. Second, > the EDCA allows TXOpps (Transmit Opportunities)..although put to > 'zero' for OCB (I think), this mechanism still allows an AP to > reserve a given time a long(er) connectivity with one device (e. > streaming of video etc..). Finally, it does not cost anything..you > can always take the lowest AC and you get the same behavior as > non-QoS.. Well, this text is more informal in nature. It is something that describes a potential behaviour but we have no proof of existing such behaviour, no proof of interoperability. This could be part of an INFORMATIONAL Internet Draft. > Bottom line, the fact that some IP implementation to decode OCB > assume non-QoS frames looks more to me like an implementation error > and we should not propagate this... Well, wireshark has problems interpreting 802.11 QoS Data containing CAM messages. Many receivers of QoS Data dont know what to do with the fields because they are not agreed. I dont want to propagate that disagreement into the IP-over-OCB draft. > Btw, I remains really not convinced of the use of CAM over IP..this > is a recurring discussion over the thread... Yes, it is recurring. > C-V2X will not use IP for CAM, LTE-V2X will carry CAM in IP. What is C-V2X and why does not it use IP? > ETSI and WAVE will not use IP for CAM... That is their problem. ETSI transports IP over GeoNetworking - that is not the right way to do it. > the basic CAMs are used for pure positioning The mandatory fields in CAM or more than just lat/long/altitude. There is also mandatory time in a strange format, car dimensions, curve, non standard precisions and more. > and the recent 'increase' of information put in CAM If CAM worries about size, I think CAM should think about its existing redundancy. For example, position is carried twice in a CAM message: in the CAM itself and in the GeoNetworking header. That is an issue they should address first. > looks to be like a bad strategy as we end up having a container > carrying too many things and being too big for what it is... I agree. But I think we should compare header sizes and then there will be surprises. CAM transported in IP may be a smaller packet than CAM transported in BTP and GeoNetworking. > (WLAN is good at squeezing various small packets but really not good > at big things especially in broadcast mode)...a better strategy would > be to define new messages tailored to the information needs, and have > smart service scheduling...(especially benefiting from IP-related > mechanisms) I fully agree with this. Alex From nobody Sat Feb 24 11:55:31 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5074012D7E8 for ; Sat, 24 Feb 2018 11:55:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 AfoqcbjJpwSd for ; Sat, 24 Feb 2018 11:55:29 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FD6C1200B9 for ; Sat, 24 Feb 2018 11:55:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 000F4300A07 for ; Sat, 24 Feb 2018 14:55:26 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id sZo6FNUHh6l3 for ; Sat, 24 Feb 2018 14:55:25 -0500 (EST) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 570AD30044B; Sat, 24 Feb 2018 14:55:25 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <1519418411.2226.429.camel@gmail.com> Date: Sat, 24 Feb 2018 14:55:26 -0500 Cc: its@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <9231453B-5144-4FAE-8475-72B2708EE239@vigilsec.com> References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <006b01d3ace3$f0168e00$d043aa00$@eurecom.fr> <1519418411.2226.429.camel@gmail.com> To: Rex Buddenberg , =?utf-8?B?SsOpcsO0bWUgSMOkcnJp?= , Tony Li , Alexandre Petrescu X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 24 Feb 2018 19:55:30 -0000 >> IP could not benefit much from it=E2=80=A6 >=20 > ?? Was IP using diff-serv? It would seem that if you are going to > shuffle queues (sort traffic) at layer 2, you need to at layer 3 as > well. And the sorting flags need to be coherent at both layers?? Indeed. Without specifying the linkage between the IEEE 802.11 QoS and = DiffServ code points, there will not be any significant value. If memory serves, there was recently sone discussion about DiffServe in = 6man. However, I do not know if the work being done there would cover = this situation. Russ From nobody Sat Feb 24 13:22:20 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E630512D86D for ; Sat, 24 Feb 2018 13:22:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 ckX8nGfPZxcn for ; Sat, 24 Feb 2018 13:22:17 -0800 (PST) Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::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 6ED97124BE8 for ; Sat, 24 Feb 2018 13:22:17 -0800 (PST) Received: by mail-ot0-x22a.google.com with SMTP id 95so10280151ote.5 for ; Sat, 24 Feb 2018 13:22:17 -0800 (PST) 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=vO6Warj55uiJvp31T+ogXUP3VVOSQr2/9JEtVE35Clk=; b=ZPyGMMLQT+pNlmqn0HxR9dfhJK8EtAVQzrhh7yz6O4ZuhOY8JwcM9lqY5hK1X8312n BtLjJYR5vmTXH3UgJy74AaIzv3iF6hU2wIkOpD7c9uf2RhmJA/S6aqkCIBJ2VIDxOIGM 6CkemntX5C2NtII9tcvB+0T9Zh9Ffz0vPv2CitOh5qOOKNMOFxmSgePzbT7dTX8wIapF aeocRrSSmZaqXHi/JqSinUbO0ju6YcPFI/dB5H8BLqkO9mfdGA13NMzky0ASYpk0igK4 6CYpnkNK99Eq84FZyDC7UwUyNEK9TkKvIlzlpyv5feX6IwZlIuRlC8qt5AFAW9rFcIL/ nNXA== 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=vO6Warj55uiJvp31T+ogXUP3VVOSQr2/9JEtVE35Clk=; b=Fa/rlE4ODYnGeVRTbn1koIUJ0TPxeNADYZCxEv+Og7NIQ0ZNC+SpCbJXiwIhRtvvNx natb2jkP5xlBTaT4uUWCRd5NZC5nV8hy0f8MKk1PVal2sYGmIUXRN4GT6KrEV+/RlU8B 1CDruiMkdOMxpOOH7eT1ArY6CohUuIzW9OtkStX++PXRXSv3tgOh9VdwG+IA/Fv83ySm EK+4+8gf6epsDqdYpTiZllgSg99QYkxcojwZONvXeGk7bwM6kG4eCYxvNcr2USWE+1Z2 IldBsmriU86XQdPICUmQSH5/tBJL1yxBnZJIprL3OYYH5euZEiydHDL5sYTSPQ52elLV 3eKg== X-Gm-Message-State: APf1xPDu9hWQAko5Ln7iyfp+sosZbssTla9g3TCY3Xph9mmvSMZm2w+4 cM39lXAmmF4SQtAqtucusoYn59OyCc4ncATpZ9w= X-Google-Smtp-Source: AG47ELvFng17xrtHIeVwQeHTT07Lk6xDxyF/9EPuizFSTMwD61mxFlusvh0tzuysqz2blm7JhOJxATptpGL8CbZf0H0= X-Received: by 10.157.65.237 with SMTP id v42mr4356420oti.156.1519507336487; Sat, 24 Feb 2018 13:22:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.36 with HTTP; Sat, 24 Feb 2018 13:22:15 -0800 (PST) In-Reply-To: <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> From: Abdussalam Baryun Date: Sat, 24 Feb 2018 23:22:15 +0200 Message-ID: To: Alexandre Petrescu Cc: its Content-Type: multipart/alternative; boundary="94eb2c1c1cec0666c00565fbdf05" Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 24 Feb 2018 21:22:19 -0000 --94eb2c1c1cec0666c00565fbdf05 Content-Type: text/plain; charset="UTF-8" On Fri, Feb 23, 2018 at 7:32 PM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > IPWAVErs, > > The issue below is an important issue. > > I want to ask the group which of 802.11 Data headers or 802.11 QoS Data > headers are more likely to be the right ones? In order to RECOMMEND in > this draft to carry IP messages. > why or, why not data and QoS data? Why right or wrong way of thinking? Could we think any upper layer have many options for many usecases within ITS applications. > For my part I tend to prefer to recommend 802.11 Data (Subtype 0). > > Many implementations of BSM in America and CAM and SPAT in Europe are > sent with 802.11 QoS Data headers (Subtype 8). Numerous other > implementations of CAM and DENM in Europe are sent with 802.11 Data > headers instead (Subtype 0). > What about performance considerations, it is not known yet, but I think it is better to consider that if we take the data header only approach that means we may not be using MAC layer's services which can open a question. > > This means that a CAM sent by implementation of company X is not > understood by a CAM receiver open source rendits for example, because of > that difference in Subtype. > No, there is communication between nodes for interoperability for each layer, > If we put that CAM on IP there will still be lack of interoperability, > unless we recommend IP to be carried by a particular 802.11 header (Data > or QoS Data). > I think using QoS data header is optional, and if used can make advantages for ip transmission. AB --94eb2c1c1cec0666c00565fbdf05 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Feb 23, 2018 at 7:32 PM, Alexandre Petrescu &= lt;alexan= dre.petrescu@gmail.com> wrote:
IPWAVErs,<= br>
The issue below is an important issue.

I want to ask the group which of 802.11 Data headers or 802.11 QoS Data
headers are more likely to be the right ones?=C2=A0 In order to RECOMMEND i= n
this draft to carry IP messages.

why or= , why not data and QoS data?=C2=A0Why right or wrong way of thinking? Could= we think any upper layer have many options for many usecases within ITS ap= plications.


For my part I tend to prefer to recommend 802.11 Data (Subtype 0).

Many implementations of BSM in America and CAM and SPAT in Europe are
sent with 802.11 QoS Data headers (Subtype 8).=C2=A0 Numerous other
implementations of CAM and DENM in Europe are sent with 802.11 Data
headers instead (Subtype 0).

What about= performance considerations, it is not known yet, but I think it is better = to consider=C2=A0that if we take=C2=A0the data header only=C2=A0approach th= at means we may not be using MAC layer's services which can open a ques= tion.=C2=A0

This means that a CAM sent by implementation of company X is not
understood by a CAM receiver open source rendits for example, because of that difference in Subtype.

No, there i= s communication between=C2=A0nodes=C2=A0for interoperability for each layer= ,



If we put that CAM on IP there will still be lack of interoperability,
unless we recommend IP to be carried by a particular 802.11 header (Data or QoS Data).

I think using QoS data he= ader is optional,=C2=A0and if used can make advantages for ip transmission.=

AB=C2=A0
--94eb2c1c1cec0666c00565fbdf05-- From nobody Sat Feb 24 17:02:49 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC0E0124BFA for ; Sat, 24 Feb 2018 17:02:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 S1GRO09uD26u for ; Sat, 24 Feb 2018 17:02:45 -0800 (PST) Received: from mail-pl0-x22c.google.com (mail-pl0-x22c.google.com [IPv6:2607:f8b0:400e:c01::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 AB6651243F6 for ; Sat, 24 Feb 2018 17:02:45 -0800 (PST) Received: by mail-pl0-x22c.google.com with SMTP id c11-v6so3738955plo.0 for ; Sat, 24 Feb 2018 17:02:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:subject:from:to:cc:date:in-reply-to:references :mime-version:content-transfer-encoding; bh=lDs4krnUSUsQpIHWfLdvxi1z7+mrAsEPx++JGG5P9cY=; b=ZZxcVprz2TnOWFmgskFAKSssRG72L6QKA5MTwszlT4fIj5gJ0G6NRFiWYfzOG6Ijng GLZdi5VVq/kDQlVxBz5dYrZ/vbUCwQZzGGppGwQGCF1pSlOGBmQhL5mCshp7X0Iubjqs 3XTGuKo2oE8Jr55T3pJB5V17YImVEM0H7ufJ+uO27676KVOwCCTzvcOspHDzZY3K+KhD 4v+9tjvVJbIh0HTLnZiNE8LtgigNRAMPxRMmK9a3jIECiCBPRXqX2hsLZkZxGzbx6X1h qxftA6NSBsYASdcugDnBx8mluI3BVIn99uAG75cVALhWOLvBLHk718uBV3lJkM2QRs6E 2HtA== 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:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=lDs4krnUSUsQpIHWfLdvxi1z7+mrAsEPx++JGG5P9cY=; b=RUyv2bXTaEA9wSXJ2P5RU5aUthBxB4ED6PNBym5BpxGptaynrPfmki20kiD5zJBrAg u0S0r5pEws9MyeZ7BVcsvCSfK9X2W3x428ERRrbqUdQtLKT5/r++yHv3drAsFeQQOaFL 7m3V1eCLEGF2Il30uc6yn7w1NCImEzHuLeDGYjcFy5T3S0VgLx/pYf6pMiyk5cww4XGZ S4hUIrB64FV5ZRkVuVwFLVZslZMhwgy9btfSyxu6Ci3SMvrNQ9VWBhwW/X6ea5ccn7gq 8kjxfngnforlM0b3d3y53IroMlkQ4X80ClgXZARRlHyYEznVpcWoAMMJs1i3+AIii/M9 +OUA== X-Gm-Message-State: APf1xPDlwg+rJFfp2PEb9Trok+2nnjFypw/qeATltXnDGRouRc1munDM SNMCXx96aBUkA9IVtmatNYM= X-Google-Smtp-Source: AH8x226zjBxKrZwDjtZfVTLlMNB2yDfNyChy2/vGiDCRD23vBeghsJOy93Gyf6Bmxx9TpYM0mFULpg== X-Received: by 2002:a17:902:6805:: with SMTP id h5-v6mr6226462plk.46.1519520565132; Sat, 24 Feb 2018 17:02:45 -0800 (PST) Received: from localhost.localdomain (c-71-198-163-21.hsd1.ca.comcast.net. [71.198.163.21]) by smtp.gmail.com with ESMTPSA id s62sm9193903pgc.12.2018.02.24.17.02.43 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 24 Feb 2018 17:02:44 -0800 (PST) Message-ID: <1519520562.2226.459.camel@gmail.com> From: Rex Buddenberg To: Abdussalam Baryun , Alexandre Petrescu Cc: its Date: Sat, 24 Feb 2018 17:02:42 -0800 In-Reply-To: References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.5.2 (3.18.5.2-1.fc23) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 25 Feb 2018 01:02:48 -0000 in line On Sat, 2018-02-24 at 23:22 +0200, Abdussalam Baryun wrote: > > > On Fri, Feb 23, 2018 at 7:32 PM, Alexandre Petrescu cu@gmail.com> wrote: > > IPWAVErs, > > > > The issue below is an important issue. > > > > I want to ask the group which of 802.11 Data headers or 802.11 QoS > > Data > > headers are more likely to be the right ones?  In order to > > RECOMMEND in > > this draft to carry IP messages. > why or, why not data and QoS data? Why right or wrong way of > thinking? Could we think any upper layer have many options for many > usecases within ITS applications. > What do you mean by 'QoS data'?  Beware. both qos and QoS have several meanings, particularly if you haven't done your definition homework. First.  qos (that experienced) at layer 3 is first-in, first-out of a router.  If you want to change that, then diff-serv provides QoS control -- you can sort packets according to the DSCP into four bins which are then drained in order.      Second.  But think about this in the context of radio-WAN --> wired (usually fiber) terrestrial WAN (v to i, if you must).  The terrestrial WAN is provisioned in 10s of Gbits while the radio provides Mbits of data -- one 10,000th of the capacity of the fiber.  If there's no congestion on the fiber there is no QoS control mechanism on the planet that can improve qos.  Coversely, there are several ways to make things worse. One, ironically, is to turn on diff-serv and spend CPU cycles sorting datagrams rather than sending the %%^&&*( traffic.   Second, there are a couple ways to 'implement QoS' in the radio-WAN (layer 2).        If you have the carrier-sense multiple access MAC that defines both 802.3 and 802.11, then about the only thing you can do is mark a frame as more urgent than the others (perhaps by setting something congruent with DSCP).  That doesn't get it onto the network any faster, and if the router-and-upstream is overprovisioned anyway, you get no benefit.      On the other hand, if you have a scheduling MAC like that in LTE or IEEE 802.16, you have a hatful of ways to define, and implement QoS control.  There are more knobs on the standards than anyone will ever use.  At least one of the possible ways to tickle QoS control is for the base station to give a needy (and urgent) subscriber station a larger transmit window.  (some of my students and I once tried to map these coherently onto diff-serv categories; gave up in frustration). Thirdly, be careful what you ask for.  In the original IP specification there was an entire byte marked for 'QoS'.  It was never defined (and in practice, capacity on the internet gained faster than congestion), so there wasn't much point.  At one point DISA (Defense Information System Agency, owner of DoD's part of the internet) proposed 2^8 different sort bins -- after all, that's the number of bits we have available! (Imagine the CPU cycles spent sorting THAT ... for every datagram).   Diff-serv defines four which is about right.  The old naval message system defined five precedence categories.   > > > > For my part I tend to prefer to recommend 802.11 Data (Subtype 0). > > > > Many implementations of BSM in America and CAM and SPAT in Europe > > are > > sent with 802.11 QoS Data headers (Subtype 8).  Numerous other > > implementations of CAM and DENM in Europe are sent with 802.11 Data > > headers instead (Subtype 0). > What about performance considerations, it is not known yet, but I > think it is better to consider that if we take the data header > only approach that means we may not be using MAC layer's services > which can open a question.  > > > > This means that a CAM sent by implementation of company X is not > > understood by a CAM receiver open source rendits for example, > > because of > > that difference in Subtype. > No, there is communication between nodes for interoperability for > each layer, > > > > > > If we put that CAM on IP there will still be lack of > > interoperability, > > unless we recommend IP to be carried by a particular 802.11 header > > (Data > > or QoS Data). > I think using QoS data header is optional, and if used can make > advantages for ip transmission. > > AB  > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Sun Feb 25 09:58:32 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 340A51270A0 for ; Sun, 25 Feb 2018 09:58:31 -0800 (PST) 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 1eBELS2tY5wh for ; Sun, 25 Feb 2018 09:58:29 -0800 (PST) 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 5F486126D05 for ; Sun, 25 Feb 2018 09:58:29 -0800 (PST) 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 w1PHwRtg148153; Sun, 25 Feb 2018 18:58:27 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 02345200C90; Sun, 25 Feb 2018 18:58:27 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id DFA2520199F; Sun, 25 Feb 2018 18:58:26 +0100 (CET) Received: from [132.166.84.53] ([132.166.84.53]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w1PHwQI4004088; Sun, 25 Feb 2018 18:58:26 +0100 To: Tony Li Cc: its@ietf.org References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> From: Alexandre Petrescu Message-ID: <9ada5591-2af3-272d-3bc3-031bf35454c3@gmail.com> Date: Sun, 25 Feb 2018 18:58:26 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.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] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 25 Feb 2018 17:58:31 -0000 Le 23/02/2018 à 18:38, Tony Li a écrit : > > >> If we put that CAM on IP there will still be lack of interoperability, >> unless we recommend IP to be carried by a particular 802.11 header (Data >> or QoS Data). > > > I would propose that we use the Data header. My experience with the QoS > Data with Wi-Fi was that there wasn’t enough of a performance difference > with QoS for it to make a difference to the IP layer. I agree. I propose the following text. OLD: > In OCB mode, IPv6 packets MAY be transmitted either as "IEEE 802.11 > Data" or alternatively as "IEEE 802.11 QoS Data", as illustrated in > Figure 2. NEW: > In OCB mode, it is RECOMMENDED to transmit IPv6 packets as "IEEE > 802.11 Data" (the value of the field Subtype in the Frame Control > Field is 0). Alex From nobody Mon Feb 26 00:04:40 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4171241FC for ; Mon, 26 Feb 2018 00:04:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 vT3K7LvjSXrE for ; Mon, 26 Feb 2018 00:04:38 -0800 (PST) Received: from mail-ot0-x22e.google.com (mail-ot0-x22e.google.com [IPv6:2607:f8b0:4003:c0f::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 D9FCA120721 for ; Mon, 26 Feb 2018 00:04:37 -0800 (PST) Received: by mail-ot0-x22e.google.com with SMTP id p8so12597343otf.2 for ; Mon, 26 Feb 2018 00:04:37 -0800 (PST) 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=0PyTJt3POqgxc4BObgzUIOWCWp/KKS2F8osUiSqTXIA=; b=JfHaHkGoWjczPkBe+vWh8ExNwKxAW+EvwY30+TBU2TbmlrJTdCpgUUegSeYSbsT7hO pcnOgPA6tAQul2ZY85GIGZlgaK2L360JRw9LmRDNExsVLhHTwU/r46L+dz+Ddg/43i6U 1hV1eIb5iCN5qBwwmhuqLjo2U+UgH8FKuJVIsz8INaC8NsrIUCUSURiMpuliR+Wcsdup 6X5tbtgBe2JqqU8LETvz5L/2C4/lg8V3KAyMVFjttGpGMxBjIQM6Z9r/2d7rAlZ8ydQV 8DE30Q6r96GYltoqePTVEQTB8OPLMKdjx6t/n+RcG6oPgUV2E91pUAwM9SJYBMFUpIku 0WCw== 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=0PyTJt3POqgxc4BObgzUIOWCWp/KKS2F8osUiSqTXIA=; b=OXDS7q7ygBTeQ2zaYDwXw95qUmb8oBq6tKDyYfVQPrAuHnQfyg1po+7sKs/jjWhUH/ 5lDOeZtIe5Zg4HaVVxpj5Zx82rsCEhlTMLzTHuTJZIOps2nP1dC5V/sVQIjSswaf9Twr SdH9GNHpLFxEclqJNuhX5SqatGJ+21mpbSC1ekF+uSZWaki6EZ/+26+VmYkpJP+AIpXB AoAub9ZaTlf97dfrgpd/dho8LM+0kdF05kQkQKssUTTmvpePQyW4LmiJFVBBSNod0GMR 3HKmFr2D/pZXwZID7MFw/a6bRHsPbwYYxA/STKyG2A4zDljEYSdh6K4GElxf6YgvLMnw C99g== X-Gm-Message-State: APf1xPDJuiJBv6qGvrKjo8JSBta3kYOhwRk8VwTso4LKo09r+1PvAoxh cGI8R/nhlmXsrXPKkuh2WJz3udDdZuzC6iY6I3k= X-Google-Smtp-Source: AG47ELsZ3eMbeQ5RakbBKJMF47/EQp6F2ha5W7Jz5ISnEmZ2feBs/CNbEmTHv9lor2GhoW4N4KWTSWkGfjNTiOVkd0Y= X-Received: by 10.157.65.237 with SMTP id v42mr7222902oti.156.1519632277151; Mon, 26 Feb 2018 00:04:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.36 with HTTP; Mon, 26 Feb 2018 00:04:36 -0800 (PST) In-Reply-To: <9ada5591-2af3-272d-3bc3-031bf35454c3@gmail.com> References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <9ada5591-2af3-272d-3bc3-031bf35454c3@gmail.com> From: Abdussalam Baryun Date: Mon, 26 Feb 2018 10:04:36 +0200 Message-ID: To: Alexandre Petrescu Cc: Tony Li , its Content-Type: multipart/alternative; boundary="94eb2c1c1cec11a25c056618f65e" Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 26 Feb 2018 08:04:39 -0000 --94eb2c1c1cec11a25c056618f65e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The experience test you referred to is not clarified, was it a ITS environment experience or was it a fixed wireless experience. Furthermore, the WiFi technology ieee802.11 is developed so which WiFi technology was used. Moreover, did your experience use Video and voice communication or your proposal is only for data communication only. So if your IP packet are data then your experience is right, but if the IP packet is carrying voice or video I don't agree. IMO we could not exclude from the draft voice and video communication in the ITS environment/use-case. On Sun, Feb 25, 2018 at 7:58 PM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > > > Le 23/02/2018 =C3=A0 18:38, Tony Li a =C3=A9crit : > >> >> >> If we put that CAM on IP there will still be lack of interoperability, >>> unless we recommend IP to be carried by a particular 802.11 header (Dat= a >>> or QoS Data). >>> >> >> >> I would propose that we use the Data header. My experience with the QoS >> Data with Wi-Fi was that there wasn=E2=80=99t enough of a performance di= fference >> with QoS for it to make a difference to the IP layer. >> > > I agree. > > I propose the following text. > > OLD: > >> In OCB mode, IPv6 packets MAY be transmitted either as "IEEE 802.11 >> Data" or alternatively as "IEEE 802.11 QoS Data", as illustrated in >> Figure 2. >> > > NEW: > >> In OCB mode, it is RECOMMENDED to transmit IPv6 packets as "IEEE >> 802.11 Data" (the value of the field Subtype in the Frame Control >> Field is 0). >> > > Alex > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > --94eb2c1c1cec11a25c056618f65e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The experience=C2=A0test you referred to=C2=A0is not = clarified, was it a ITS environment experience or was it a fixed wireless e= xperience. Furthermore, the WiFi technology ieee802.11 is developed so whic= h WiFi technology was used. Moreover, did your experience=C2=A0use Video an= d voice communication or your proposal is only for data communication only.=

So if your IP packet are data then your experienc= e is right, but if the IP packet is carrying voice or video I don't agr= ee. IMO we could not exclude from the draft=C2=A0voice and video communicat= ion in the ITS environment/use-case.=C2=A0
=
On Sun, Feb 25, 2018 at 7:58 PM, Alexandre P= etrescu <alexandre.petrescu@gmail.com> wrote:
=


Le 23/02/2018 =C3=A0 18:38, Tony Li a =C3=A9crit=C2=A0:


If we put that CAM on IP there will still be lack of interoperability,
unless we recommend IP to be carried by a particular 802.11 header (Data or QoS Data).


I would propose that we use the Data header. My experience with the QoS Dat= a with Wi-Fi was that there wasn=E2=80=99t enough of a performance differen= ce with QoS for it to make a difference to the IP layer.

 I agree.

I propose the following text.

OLD:
=C2=A0 =C2=A0In OCB mode, IPv6 packets MAY be transmitted either as "I= EEE 802.11
=C2=A0 =C2=A0Data" or alternatively as "IEEE 802.11 QoS Data"= ;, as illustrated in
=C2=A0 =C2=A0Figure 2.

NEW:
=C2=A0 =C2=A0In OCB mode, it is RECOMMENDED to transmit IPv6 packets as &qu= ot;IEEE
=C2=A0 =C2=A0802.11 Data" (the value of the field Subtype in the Frame= Control
=C2=A0 =C2=A0Field is 0).

Alex

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

--94eb2c1c1cec11a25c056618f65e-- From nobody Mon Feb 26 00:22:13 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3111312D777 for ; Mon, 26 Feb 2018 00:22:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 t_yB6YHndVoO for ; Mon, 26 Feb 2018 00:22:09 -0800 (PST) Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC86712D775 for ; Mon, 26 Feb 2018 00:22:09 -0800 (PST) Received: by mail-ot0-x22f.google.com with SMTP id 95so12624833ote.5 for ; Mon, 26 Feb 2018 00:22:09 -0800 (PST) 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=/YrI45zkEynfcr1nV5oyqToiqSLF6neJL8osmEnocLA=; b=J35axwhWRPRrVUcRXJNoiSaLgJg9Rvc85zZIqUwK26nNs1paQ/PlxSNghd75QsW/TR l0F77zYI9iZM6qC/TYU4U07av9A4jjD0vQolpBzWsHoK0pGWsBNz4sON2MS2RnKIG35P Od55EasYWMD29q1vaNNv+kqXMvsO5Uf232l9Tfxh5rlHZUFKJSZ3/OLdOv5U437O8NaD qX823iylal2Z9cREbiFN/hMsWBx5bsdcYlIOZ93Qze4ektD6Wz14E3pJ1BmTAC43hYyN +3Lt1QOY3jIqrygN19Hxy1Tkag2rCIlAOtM36WI8twsMdHdzuS1Kerw6fHvfNTDaA6GG VAVw== 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=/YrI45zkEynfcr1nV5oyqToiqSLF6neJL8osmEnocLA=; b=t7LtVy8Cq9d2AJFjCnKcJBZCqduX5tiiWGvDH57s0GySSfAWETJHo9iemheSH+0RM5 VDSkg4acAS1KBtjhvZWw4tNMQPZIyfr0r6VJavVzG1pq8OsymxaGIBFbWDMQ7psczHLx wtDscKJ91K8lz0OQXYMCcPwT+DD7i/7YiGKdQ5D61KTJlZQbC5ak5Wi+52OPz3rDRI9H hAQ6mWsanz2qOs/gw3vvyEm/wK8Dp5AlcCVHz2i90YzToIwjnrI4hxBSRBmNI6lGiHO5 /Zylgtler99WurWi1rCfVZdBDznLHx3SI9ngFw3X3yjbC3z6bFpUyb5jPZ4oO4zxttAQ 4rtw== X-Gm-Message-State: APf1xPAZSsYxhE0HbUZ7snrIMCpo4fkTiLPC86ASDERbhLPtnmVxkYwW FkRLtvmXqpgdumpiGrFmWFRwVwfmA3yEp2WKL+o= X-Google-Smtp-Source: AG47ELsj7622VxEGV3vjRyy2J4D5E7b6fIDe9/dhu2jHW9c/PEoPUaZLo5Fy2rgwKsvih0hDuPlqvhmk4Ex/Vkybe8I= X-Received: by 10.157.48.73 with SMTP id w9mr7345952otd.391.1519633328795; Mon, 26 Feb 2018 00:22:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.36 with HTTP; Mon, 26 Feb 2018 00:22:08 -0800 (PST) In-Reply-To: <1519520562.2226.459.camel@gmail.com> References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <1519520562.2226.459.camel@gmail.com> From: Abdussalam Baryun Date: Mon, 26 Feb 2018 10:22:08 +0200 Message-ID: To: Rex Buddenberg Cc: Alexandre Petrescu , its Content-Type: multipart/alternative; boundary="001a113db6fac075750566193475" Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 26 Feb 2018 08:22:12 -0000 --001a113db6fac075750566193475 Content-Type: text/plain; charset="UTF-8" On Sun, Feb 25, 2018 at 3:02 AM, Rex Buddenberg wrote: > in line > > On Sat, 2018-02-24 at 23:22 +0200, Abdussalam Baryun wrote: > > > > > > On Fri, Feb 23, 2018 at 7:32 PM, Alexandre Petrescu > cu@gmail.com> wrote: > > > IPWAVErs, > > > > > > The issue below is an important issue. > > > > > > I want to ask the group which of 802.11 Data headers or 802.11 QoS > > > Data > > > headers are more likely to be the right ones? In order to > > > RECOMMEND in > > > this draft to carry IP messages. > > why or, why not data and QoS data? Why right or wrong way of > > thinking? Could we think any upper layer have many options for many > > usecases within ITS applications. > > > What do you mean by 'QoS data'? Beware. both qos and QoS have several > meanings, particularly if you haven't done your definition homework. > > First. qos (that experienced) at layer 3 is first-in, first-out of a > router. If you want to change that, then diff-serv provides QoS > control -- you can sort packets according to the DSCP into four bins > which are then drained in order. > > > Second. But think about this in the context of radio-WAN --> wired > (usually fiber) terrestrial WAN (v to i, if you must). The terrestrial > WAN is provisioned in 10s of Gbits while the radio provides Mbits of > data -- one 10,000th of the capacity of the fiber. If there's no > congestion on the fiber there is no QoS control mechanism on the planet > that can improve qos. Coversely, there are several ways to make things > worse. One, ironically, is to turn on diff-serv and spend CPU cycles > sorting datagrams rather than sending the %%^&&*( traffic. I only now am thinking point to point in MAC layer, let us don't go out of the draft's use-case. Why you are thinking of the PHY layer in terms of CPU, while we should think about the unstable physical links and capacity. > > > > Second, there are a couple ways to 'implement QoS' in the radio-WAN > (layer 2). > If you have the carrier-sense multiple access MAC that defines > both 802.3 and 802.11, then about the only thing you can do is mark a > frame as more urgent than the others (perhaps by setting something > congruent with DSCP). That doesn't get it onto the network any faster, > and if the router-and-upstream is overprovisioned anyway, you get no > benefit. > We need to discuss only 802.11 OCB, and I think we need fastest as possible, and MAC layer does fragmentation for faster purposes and sends frames in parallel MIMO, > On the other hand, if you have a scheduling MAC like that in LTE > or IEEE 802.16, you have a hatful of ways to define, and implement QoS > control. There are more knobs on the standards than anyone will ever > use. At least one of the possible ways to tickle QoS control is for > the base station to give a needy (and urgent) subscriber station a > larger transmit window. (some of my students and I once tried to map > these coherently onto diff-serv categories; gave up in frustration). > The 802.11-2016 already defined the windows for OCB which is different from BSS, so why not use its capabilities of QoS, > > > Thirdly, be careful what you ask for. I don't ask for any thing, the user of IP will ask us, we provide the optional use of QoS use-cases, > In the original IP specification > there was an entire byte marked for 'QoS'. It was never defined (and > in practice, capacity on the internet gained faster than congestion), > so there wasn't much point. At one point DISA (Defense Information > System Agency, owner of DoD's part of the internet) proposed 2^8 > different sort bins -- after all, that's the number of bits we have > available! (Imagine the CPU cycles spent sorting THAT ... for every > datagram). Diff-serv defines four which is about right. The old > naval message system defined five precedence categories. I don't agree, I think ITS has a variable link capacity which is not stable, but you are referring to stable capacity and connections. AB > > > > > > > > For my part I tend to prefer to recommend 802.11 Data (Subtype 0). > > > > > > Many implementations of BSM in America and CAM and SPAT in Europe > > > are > > > sent with 802.11 QoS Data headers (Subtype 8). Numerous other > > > implementations of CAM and DENM in Europe are sent with 802.11 Data > > > headers instead (Subtype 0). > > What about performance considerations, it is not known yet, but I > > think it is better to consider that if we take the data header > > only approach that means we may not be using MAC layer's services > > which can open a question. > > > > > > This means that a CAM sent by implementation of company X is not > > > understood by a CAM receiver open source rendits for example, > > > because of > > > that difference in Subtype. > > No, there is communication between nodes for interoperability for > > each layer, > > > > > > > > > > If we put that CAM on IP there will still be lack of > > > interoperability, > > > unless we recommend IP to be carried by a particular 802.11 header > > > (Data > > > or QoS Data). > > I think using QoS data header is optional, and if used can make > > advantages for ip transmission. > > > > AB > > _______________________________________________ > > its mailing list > > its@ietf.org > > https://www.ietf.org/mailman/listinfo/its > --001a113db6fac075750566193475 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Feb 25, 2018 at 3:02 AM, Rex Buddenberg <<= a href=3D"mailto:buddenbergr@gmail.com" target=3D"_blank">buddenbergr@gmail= .com> wrote:
in line

On Sat, 2018-02-24 at 23:22 +0200, Abdussalam Baryun wrote:
>
>
> On Fri, Feb 23, 2018 at 7:32 PM, Alexandre Petrescu <alexandre.petr= es
> cu@gmail.com> wrote:
> > IPWAVErs,
> >
> > The issue below is an important issue.
> >
> > I want to ask the group which of 802.11 Data headers or 802.11 Qo= S
> > Data
> > headers are more likely to be the right ones?=C2=A0 In order to > > RECOMMEND in
> > this draft to carry IP messages.
> why or, why not data and QoS data?=C2=A0Why right or wrong way of
> thinking? Could we think any upper layer have many options for many > usecases within ITS applications.
>
What do you mean by 'QoS data'?=C2=A0 Beware. both qos and Q= oS have several
meanings, particularly if you haven't done your definition homework.
First. =C2=A0qos (that experienced) at layer 3 is first-in, first-out of a<= br> router.=C2=A0 If you want to change that, then diff-serv provides QoS
control -- you can sort packets according to the DSCP into four bins
which are then drained in order.
=C2=A0 =C2=A0=C2=A0

Second.=C2=A0 But think about this in the context of radio-WAN --> wired=
(usually fiber) terrestrial WAN (v to i, if you must).=C2=A0 The terrestria= l
WAN is provisioned in 10s of Gbits while the radio provides Mbits of
data -- one 10,000th of the capacity of the fiber.=C2=A0 If there's no<= br> congestion on the fiber there is no QoS control mechanism on the planet
that can improve qos.=C2=A0 Coversely, there are several ways to make thing= s
worse. One, ironically, is to turn on diff-serv and spend CPU cycles
sorting datagrams rather than sending the %%^&&*( traffic.

I only now am thinking point to point in=C2=A0MAC = layer, let us don't go out of the draft's use-case. Why you are thi= nking of the PHY layer=C2=A0in terms of CPU,=C2=A0while we should think abo= ut the unstable physical links and capacity.
=C2=A0
=C2=A0


Second, there are a couple ways to 'implement QoS' in the radio-WAN=
(layer 2). =C2=A0
=C2=A0 =C2=A0 =C2=A0If you have the carrier-sense multiple access MAC that = defines
both 802.3 and 802.11, then about the only thing you can do is mark a
frame as more urgent than the others (perhaps by setting something
congruent with DSCP).=C2=A0 That doesn't get it onto the network any fa= ster,
and if the router-and-upstream is overprovisioned anyway, you get no
benefit.

We need to discuss only 802.11= OCB, and I think we need fastest as possible, and MAC layer does fragmenta= tion for faster purposes and sends frames in parallel MIMO,
=C2= =A0
=C2=A0 =C2=A0 =C2=A0On the other hand, if you have a scheduling MAC like th= at in LTE
or IEEE 802.16, you have a hatful of ways to define, and implement QoS
control.=C2=A0 There are more knobs on the standards than anyone will ever<= br> use.=C2=A0 At least one of the possible ways to tickle QoS control is for the base station to give a needy (and urgent) subscriber station a
larger transmit window. =C2=A0(some of my students and I once tried to map<= br> these coherently onto diff-serv categories; gave up in frustration).

The 802.11-2016 already defined the windows f= or OCB which is different from BSS, so why not=C2=A0use its capabilities of= QoS,
=C2=A0


Thirdly, be careful what you ask for.

I don= 't ask for any thing, the user of IP will ask us, we provide the option= al use of QoS use-cases,
=C2=A0
=C2=A0In t= he original IP specification
there was an entire byte marked for 'QoS'.=C2=A0 It was never defin= ed (and
in practice, capacity on the internet gained faster than congestion),
so there wasn't much point.=C2=A0 At one point DISA (Defense Informatio= n
System Agency, owner of DoD's part of the internet) proposed 2^8
different sort bins -- after all, that's the number of bits we have
available! (Imagine the CPU cycles spent sorting THAT ... for every
datagram). =C2=A0 Diff-serv defines four which is about right.=C2=A0 The ol= d
naval message system defined five precedence categories.
<= br>
I don't agree, I think ITS has a variable link capacity= =C2=A0which is not stable, but you are referring to stable capacity and con= nections.

AB
=C2=A0

> >
> > For my part I tend to prefer to recommend 802.11 Data (Subtype 0)= .
> >
> > Many implementations of BSM in America and CAM and SPAT in Europe=
> > are
> > sent with 802.11 QoS Data headers (Subtype 8).=C2=A0 Numerous oth= er
> > implementations of CAM and DENM in Europe are sent with 802.11 Da= ta
> > headers instead (Subtype 0).
> What about performance considerations, it is not known yet, but I
> think it is better to consider=C2=A0that if we take=C2=A0the data head= er
> only=C2=A0approach that means we may not be using MAC layer's serv= ices
> which can open a question.=C2=A0
> >
> > This means that a CAM sent by implementation of company X is not<= br> > > understood by a CAM receiver open source rendits for example,
> > because of
> > that difference in Subtype.
> No, there is communication between=C2=A0nodes=C2=A0for interoperabilit= y for
> each layer,
>
>
> >
> > If we put that CAM on IP there will still be lack of
> > interoperability,
> > unless we recommend IP to be carried by a particular 802.11 heade= r
> > (Data
> > or QoS Data).
> I think using QoS data header is optional,=C2=A0and if used can make > advantages for ip transmission.
>
> AB=C2=A0
> _______________________= ________________________
> its mailing list
> its@ietf.org
> https://www.ietf.org/mailman/listinfo/its

--001a113db6fac075750566193475-- From nobody Mon Feb 26 00:37:32 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A78112D77B for ; Mon, 26 Feb 2018 00:37:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_HK_NAME_DR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fischer-tech.eu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zrmPVtEExamq for ; Mon, 26 Feb 2018 00:37:25 -0800 (PST) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::6]) (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 E598412D77A for ; Mon, 26 Feb 2018 00:37:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1519634242; s=strato-dkim-0002; d=fischer-tech.eu; h=Content-Type:In-Reply-To:Date:Message-ID:From:References:Cc:To: Subject:X-RZG-CLASS-ID:X-RZG-AUTH; bh=CgKCUlij8TwqSBo5lp6m9dr1gOolUNKtRc4I+tzLC4E=; b=J9eCz7i6ryfAw6jzW+xnFhWhHVPihXSXqUlhw88OEKka5e3JaEtBTHHtXT+q01P8/I wNvfeiYImCPamaofyYXxZym+4OgZermYW4u98eg/AD0vkYJT7BxAoUxLuGMTjeXlN2t3 KkpJTph7V0QIpJLzfVnnIlT/wgXhDX2QrCjRdIr4MPXkqn4LI8MUa0Jeur46WyWhTJp5 kmKlfvWDURBm3Jcdxy0DkSkXR3jvLuQmDvDV9zj7WJbIFazddu99CGV4TlJaVz6J/FuJ KGFXCIe2fPXGk6LT8q+fRvGlwQabtRauMZfS77YPt4tH3BTjQSlzjYKFQCwdSDy7bXLt Z34A== X-RZG-AUTH: :JGYCfFOrc/o0m7eTcArWz0wjmOawaLakL8gsnQVmzXBs/kysHP8WeUE0sQcvY8PAWSJdtjsmGi0ld1/vHArCyy4koBAMYfhthZ+hFiS2ZTq4 X-RZG-CLASS-ID: mo00 Received: from [IPv6:2003:a:1511:b400:8dc1:266:d907:2128] ([2003:a:1511:b400:8dc1:266:d907:2128]) by smtp.strato.de (RZmta 42.18 AUTH) with ESMTPSA id h068a2u1Q8bLvJC (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Mon, 26 Feb 2018 09:37:21 +0100 (CET) To: Abdussalam Baryun , Alexandre Petrescu Cc: Tony Li , its References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <9ada5591-2af3-272d-3bc3-031bf35454c3@gmail.com> From: "Dr. Hans-Joachim Fischer" Organization: ESF GmbH Message-ID: <6cdc0835-fb4c-133b-77ff-0234cfdd9ef9@fischer-tech.eu> Date: Mon, 26 Feb 2018 09:37:20 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------DF3050EE8A8F523A054BEE5A" Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 26 Feb 2018 08:37:29 -0000 This is a multi-part message in MIME format. --------------DF3050EE8A8F523A054BEE5A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Be careful with voice and audio transmission in ITS using 5,9 GHz. That seems to be prohibited by regulation in Europe; well, not explicitly, but this is a possible interpretation of the technical requirements presented in regulatory documents. In Germany, it is prohibited. Hans-Joachim Am 26.02.2018 um 09:04 schrieb Abdussalam Baryun: > The experience test you referred to is not clarified, was it a ITS > environment experience or was it a fixed wireless experience. > Furthermore, the WiFi technology ieee802.11 is developed so which WiFi > technology was used. Moreover, did your experience use Video and voice > communication or your proposal is only for data communication only. > > So if your IP packet are data then your experience is right, but if > the IP packet is carrying voice or video I don't agree. IMO we could > not exclude from the draft voice and video communication in the ITS > environment/use-case. > > On Sun, Feb 25, 2018 at 7:58 PM, Alexandre Petrescu > > > wrote: > > > > Le 23/02/2018 à 18:38, Tony Li a écrit : > > > > If we put that CAM on IP there will still be lack of > interoperability, > unless we recommend IP to be carried by a particular > 802.11 header (Data > or QoS Data). > > > > I would propose that we use the Data header. My experience > with the QoS Data with Wi-Fi was that there wasn’t enough of a > performance difference with QoS for it to make a difference to > the IP layer. > > > I agree. > > I propose the following text. > > OLD: > >    In OCB mode, IPv6 packets MAY be transmitted either as > "IEEE 802.11 >    Data" or alternatively as "IEEE 802.11 QoS Data", as > illustrated in >    Figure 2. > > > NEW: > >    In OCB mode, it is RECOMMENDED to transmit IPv6 packets as > "IEEE >    802.11 Data" (the value of the field Subtype in the Frame > Control >    Field is 0). > > > 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 -- Dr. Hans-Joachim Fischer Managing Director -------------------------------------------------------------------------------- ESF News edition 2018/1 https://fischer-tech.eu/Feeds/News/ESF-News-2018-01.pdf -------------------------------------------------------------------------------- Towards deployment of C-ITS based on proven technology Avoid risks and delay by looking on potential future technologies. The real advocate on ITS is ISO TC204! -------------------------------------------------------------------------------- + + + Instaurare omnia in Christo + + + -------------------------------------------------------------------------------- The information contained in this message is confidential and may be legally privileged. This email is intended for the addressee(s). Addressees may be individual persons or members of mailing list. If you are not an addressee, you are hereby notified that any use, dissemination, or reproduction of this email and its optional attachements is strictly prohibited and may be unlawful. If you are not an addressee, please contact the sender by return e-mail and destroy all copies of the original message. -------------------------------------------------------------------------------- ESF GmbH Fichtenweg 9 89143 Blaubeuren +49 (7344) 175340 (Direct line Dr. Fischer) +49 (7344) 919188 (Central office) +49 (7344) 919123 (Fax) https://fischer-tech.eu : Main web of ESF GmbH http://its-standards.eu : News on cooperative ITS standardization http://its-testing.org : International consultancy for cooperative ITS -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- ESF online-news: http://fischer-tech.eu/Feeds/esf.rss C-ITS online news: http://its-standards.info/Feeds/cits.rss ESF Online Nachrichten: http://fischer-tech.de/Feeds/esfD.rss ------------------------------------------------------------------------------- --------------DF3050EE8A8F523A054BEE5A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


Be careful with voice and audio transmission in ITS using 5,9 GHz. That seems to be prohibited by regulation in Europe; well, not explicitly, but this is a possible interpretation of the technical requirements presented in regulatory documents. In Germany, it is prohibited.

Hans-Joachim


Am 26.02.2018 um 09:04 schrieb Abdussalam Baryun:
The experience test you referred to is not clarified, was it a ITS environment experience or was it a fixed wireless experience. Furthermore, the WiFi technology ieee802.11 is developed so which WiFi technology was used. Moreover, did your experience use Video and voice communication or your proposal is only for data communication only.

So if your IP packet are data then your experience is right, but if the IP packet is carrying voice or video I don't agree. IMO we could not exclude from the draft voice and video communication in the ITS environment/use-case. 

On Sun, Feb 25, 2018 at 7:58 PM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:


Le 23/02/2018 à 18:38, Tony Li a écrit :


If we put that CAM on IP there will still be lack of interoperability,
unless we recommend IP to be carried by a particular 802.11 header (Data
or QoS Data).


I would propose that we use the Data header. My experience with the QoS Data with Wi-Fi was that there wasn’t enough of a performance difference with QoS for it to make a difference to the IP layer.

 I agree.

I propose the following text.

OLD:
   In OCB mode, IPv6 packets MAY be transmitted either as "IEEE 802.11
   Data" or alternatively as "IEEE 802.11 QoS Data", as illustrated in
   Figure 2.

NEW:
   In OCB mode, it is RECOMMENDED to transmit IPv6 packets as "IEEE
   802.11 Data" (the value of the field Subtype in the Frame Control
   Field is 0).

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


-- 
Dr. Hans-Joachim Fischer
Managing Director

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

               ESF News edition 2018/1
https://fischer-tech.eu/Feeds/News/ESF-News-2018-01.pdf

-------------------------------------------------------------------------------- 
      Towards deployment of C-ITS based on proven technology
Avoid risks and delay by looking on potential future technologies.

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

-------------------------------------------------------------------------------- 
ESF online-news:        http://fischer-tech.eu/Feeds/esf.rss
C-ITS online news:      http://its-standards.info/Feeds/cits.rss
ESF Online Nachrichten: http://fischer-tech.de/Feeds/esfD.rss
-------------------------------------------------------------------------------
--------------DF3050EE8A8F523A054BEE5A-- From nobody Mon Feb 26 01:25:00 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12BBE126CE8 for ; Mon, 26 Feb 2018 01:24:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tztSGXn6Px_i for ; Mon, 26 Feb 2018 01:24:56 -0800 (PST) Received: from smtp2.eurecom.fr (smtp2.eurecom.fr [193.55.113.211]) by ietfa.amsl.com (Postfix) with ESMTP id 66BEB1204DA for ; Mon, 26 Feb 2018 01:24:56 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.47,396,1515452400"; d="scan'208";a="7700518" Received: from monza.eurecom.fr ([192.168.106.15]) by drago2i.eurecom.fr with ESMTP; 26 Feb 2018 10:24:55 +0100 Received: from xerus29 (unknown [192.168.200.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by monza.eurecom.fr (Postfix) with ESMTPSA id E301D1651; Mon, 26 Feb 2018 10:24:54 +0100 (CET) From: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= To: "'Alexandre Petrescu'" , References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <006301d3ace3$25f9d500$71ed7f00$@eurecom.fr> In-Reply-To: Date: Mon, 26 Feb 2018 10:24:54 +0100 Organization: EURECOM Message-ID: <007901d3aee3$a9985ba0$fcc912e0$@eurecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHelLAw/aN7IRfcwiTBG/gKcgHVEwGONDnFAivYBTcBDgW0eQFK9evKo2/uqzA= Content-Language: en-us Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 26 Feb 2018 09:24:59 -0000 Hi Alex, > That is a requirement. > > But is there an implementation of mapping the priority of CAM over = DENM into a QoS Control field in QoS Data Header? > > I doubt there is, because the implementations of CAM I see put the = Priority field to 6, which means Voice. So they transmit CAM as Voice = even though it is not voice. > > We can not reckon in IPv6-over-OCB document something which makes = little sense (send CAM as Voice). Of course there is....the QoS fields actually means the Access = Categories (AC) for WLAN, so EDCA. Both in ETSI and in WAVE they use the = QoS Control filed of IEE 802.11p to send CAM/BSM with higher priority = (from a MAC perspective)...When looking at the EDCA 'naming' you should = not care much of the 'name'...this was done at the time internet was = only composed of voice, video etc..you should look at the underlying = values of each AC. So, EDCA is composed of two fields: 1) AIFN - a deterministic idle time before even considering reducing CW 2) CW - a random timer to decrease each time the channel is idle.=20 QoS Data combinations for OCB: AC_VO: AIFN=3D2, CW=3D8 AC_VI: AIFN=3D2, CW=3D16 AC_BE: AIFN=3D3, CW=3D32 AC_BK: AIFN=3D7, CW=3D32 So, it does not matter the name (Voice, video)..what matters is that in = implementation (BSM for instance), AIFN=3D2 so that it takes the fastest = access (deterministic) and as such has the highest priority. This is = also what you found: CAM on Priority field 6, so AC_VI so AIFN=3D2. BSM = uses the same strategy.=20 Now, on the CAR 2 CAR specification, it is recommended a different = priority: AC_BE, as it uses DP2. The reason behind this is the CAR2CAR = provides a 'strict' prioritization between DENMs and CAMs. Emergency = DENMs uses AC_VI, normal DENM uses AC_VO, CAM uses AC_BE and any other = traffic AC_BK. So, bottom line is: all ETSI and WAVE implementation use the QoS Data = field as they use EDCA. If you found an implementation that does not use = the QoS, it is wrong according to the standard. >> Now, as you abstract ETSI and WAVE (thus pure IP), my understanding = is=20 >> that QoS remains required from the IEEE 802.11p (ok, IEEE >> 802.11-2016 OCB) as there is a specification of the EDCA parameters=20 >> for OCB. Besides, I do not think it costs much to keep the EDCA in, = as=20 >> it first allows to safe a half of the MAC queueing time (the EDCA=20 >> parameters for the two low AC are less, up to a quarter of a=20 >> DIFS...so, it could be beneficial to allow this even for IP. Second,=20 >> the EDCA allows TXOpps (Transmit Opportunities)..although put to=20 >> 'zero' for OCB (I think), this mechanism still allows an AP to = reserve=20 >> a given time a long(er) connectivity with one device (e. >> streaming of video etc..). Finally, it does not cost anything..you = can=20 >> always take the lowest AC and you get the same behavior as non-QoS.. >Well, this text is more informal in nature. It is something that >describes a potential behaviour but we have no proof of existing such = behaviour, no proof of interoperability. This could be part of an = INFORMATIONAL Internet Draft. Well, my text is informal, but the specs are not. IEEE 802.11p (IEEE = 802.11-2016 OCB) uses EDCA not DCF...as this is L2 layer, I do not think = anything is required from IETF...just follow the IEEE 802.11-2016 specs = and do whatever is allows above it...I will double check again on the = IEEE 802.11-2016, but if what I think is confirmed, the whole discussion = does not make any sense..., as it is my understanding that the OCB = requires EDCA, so QoS_Data...so, you cannot change that at IP level. >> Bottom line, the fact that some IP implementation to decode OCB = assume=20 >> non-QoS frames looks more to me like an implementation error and we=20 >> should not propagate this... >Well, wireshark has problems interpreting 802.11 QoS Data containing = CAM messages. Many receivers of QoS Data dont know what to do with the = fields because they are not agreed. Yes, and this is why is the prototype we use, we actually have an parser = for CAM to be supported by Wireshark...it does not come by default. But = I am surprised..what kind of problem would wireshark face with the QoS = Data?=20 > I don't want to propagate that disagreement into the IP-over-OCB = draft. To me, this looks more like an implementation issue, rather than a = standard issue...but I will ask my team to check on our prototype... >> C-V2X will not use IP for CAM, >LTE-V2X will carry CAM in IP. What is C-V2X and why does not it use = IP? Sorry, it will not. In C-V2X (the widely known name...LTE-V2X is again a = bit like 802.11p...'LTE Prose for V2X' is the real name...), mode 4 = (ad-hoc mode..currently chosen by all vendors (except maybe Huawei, but = might have changed), there is two options for protocol stack: IPv6 = (again, only IPv6) and non-IP (L2)...you can use non-IP packets and it = is so mentioned that BSM and CAM will use the non-IP option, as it is = also required to use the ETSI/WAVE security provisions to secure the = C-V2X mode 4 (as no SIM=3D no security), as the ETSI/WAVE security = provisions works for non-IP packets (geonet or WSM)... Of course, it does not block from using IP...it is again the same = discussion we had with ITS-G5/DSRC...for safety communication, IP is not = required...you can do everything without and faster. And considering = that IEEE 802.11p (ok, OCB) and C-V2X mode 4 (no SIM=3Dno SEC) DO NOT = have any form of security mechanism embedded, they must use the those = specified by ETSI/WAVE for accessing CCH. Again, C-V2X mode 4 (the current V2X techno for Safety-critical = communication) shall not be seen as following the same path as other = cellular techno. It does not provide QoS (at all), as it channel access = is contention-based (a bit like CSMA)...so collisions will occur (unlike = 4G and 5G operated, where you are either dropped or you pass). And as = such, IP is also not required, even if all 4G and 5G use IP. >> ETSI and WAVE will not use IP for CAM... >That is their problem. Disagree: you need to be compatible with them...so, whatever IETF will = do shall not break anything that has been done on ETSI or WAVE. This is = one of the requirement for accessing the ITS-G5 spectrum in EU, and I = believe the same in the US. >ETSI transports IP over GeoNetworking - that is not the right way to do = it. Disagree: we need to integrate security mechanisms specified by ETSI = even if we use IPv6. Today, we do not have any security specification = providing 'trust', privacy and authentication for using 802.11-OCB (I = believe it is the work of IPWAVE and it is not completed yet...).=20 The mistake ETSI did is to try to be nice with IETF and help them to = provide a way to use IPv6 over ITS-G5 in a secured way...WAVE took a = different path: 'not my problem', which then explain why ETSI officially = does not endorse IPWAVE (unfortunately, despite my many discussions with = them)...from an ETSI perspective, using IPv6 over ITS-G5 is = solved...(might be ugly, but it is solved). =20 >> the basic CAMs are used for pure positioning >The mandatory fields in CAM or more than just lat/long/altitude. There = is also mandatory time in a strange format, car dimensions, curve, non = standard precisions and more. Yes, correct...but these are configurable fields, which may or may not = be integrated...recent studies even showed that even the standard CAM = size is not clear anymore..you have a 'range' of size, and that is a = problem for wireless optimization...especially if you need to do = wireless congestion control. >> and the recent 'increase' of information put in CAM >If CAM worries about size, I think CAM should think about its existing = redundancy. For example, position is carried twice in a CAM message: in = the CAM itself and in the GeoNetworking header. That >is an issue they = should address first. Well, of course, this is a waste...but one reason for such existence is = from the possibility to relay a packet (agnostic from the upper = messages, unfortunately, we cannot use a Zero-NET for CAM as it is pure = 1-hop TSB)... Yet, today we start seeing even BSM investigating ways to do multi-hop = 'position' based relaying to reach longer distance.=20 And if you think about it, one day, your IPv6-over-OCB might need to use = a multi-hop networking protocol (e.g. MANET)..but doing the MANET way is = highly mobile environment will not be that efficient...position-based = mechanisms will be required (proven in various previous studies)...now, = your L3 will not be able to inspect the GPS position of your = CAM-over-IP...so, you will need to have GPS (or so) position at IP/L3, = which will end up being similar than now... If you do not want to do this, then the IRTF people might come with ICN, = but then would this be done above L3 or at L3...if still at L3, you = still will have a contextual L3 packet that might be redundant with = application/service layer messages...(the cost of using OSI) But this is just my personal view and very long term...for now, if we = only look at CAM, indeed we can have twice the GPS position (but wait: = not the same granularity and you do not have elevation in geonet). But = if you look at the bigger picture: doing CAM-over-geonet only required = a single CAM, that's it. For IPv6-over-OCB, you need all the IPv6 = address autoconfiguration..that requires additional IPv6 packets to be = transmitted...this is similar to compare an apple with a tomato. =20 >> looks to be like a bad strategy as we end up having a container=20 >> carrying too many things and being too big for what it is... >I agree. But I think we should compare header sizes and then there = will be surprises. >CAM transported in IP may be a smaller packet than CAM transported in = BTP and GeoNetworking. Not that much if you counts also all IPv6-related control/management = packets required to transmit your CAM-over-OCB, in a highly dynamic = environment... > (WLAN is good at squeezing various small packets but really not good=20 > at big things especially in broadcast mode)...a better strategy would=20 > be to define new messages tailored to the information needs, and have=20 > smart service scheduling...(especially benefiting from IP-related > mechanisms) > I fully agree with this. :-) at least we do on this :-) Cheers, J=C3=A9r=C3=B4me From nobody Mon Feb 26 01:34:35 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D95126D3F for ; Mon, 26 Feb 2018 01:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJthTrZXUoU7 for ; Mon, 26 Feb 2018 01:34:32 -0800 (PST) Received: from smtp2.eurecom.fr (smtp2.eurecom.fr [193.55.113.211]) by ietfa.amsl.com (Postfix) with ESMTP id B365C126CF6 for ; Mon, 26 Feb 2018 01:34:31 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.47,396,1515452400"; d="scan'208,217";a="7700568" Received: from monza.eurecom.fr ([192.168.106.15]) by drago2i.eurecom.fr with ESMTP; 26 Feb 2018 10:34:30 +0100 Received: from xerus29 (unknown [192.168.200.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by monza.eurecom.fr (Postfix) with ESMTPSA id 682CC16FA; Mon, 26 Feb 2018 10:34:30 +0100 (CET) From: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= To: "'Dr. Hans-Joachim Fischer'" , "'Abdussalam Baryun'" , "'Alexandre Petrescu'" Cc: "'Tony Li'" , "'its'" References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <9ada5591-2af3-272d-3bc3-031bf35454c3@gmail.com> <6cdc0835-fb4c-133b-77ff-0234cfdd9ef9@fischer-tech.eu> In-Reply-To: <6cdc0835-fb4c-133b-77ff-0234cfdd9ef9@fischer-tech.eu> Date: Mon, 26 Feb 2018 10:34:29 +0100 Organization: EURECOM Message-ID: <008701d3aee5$00b4a960$021dfc20$@eurecom.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0088_01D3AEED.627DCC50" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHelLAw/aN7IRfcwiTBG/gKcgHVEwGONDnFAivYBTcB5QRVgwFu9SHuAdIGJvACSXL3QKNHUi9Q Content-Language: en-us Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 26 Feb 2018 09:34:33 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0088_01D3AEED.627DCC50 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =20 >From: its [mailto:its-bounces@ietf.org] On Behalf Of Dr. Hans-Joachim = Fischer > >Be careful with voice and audio transmission in ITS using 5,9 GHz. That = seems to be prohibited by regulation in Europe; well, not explicitly, = but this is a possible >interpretation of the technical requirements = presented in regulatory documents. In Germany, it is prohibited. >Hans-Joachim Sorry to come again on this=E2=80=A6this is a big = misunderstanding=E2=80=A6there is NO audio and NO video = transmitted=E2=80=A6 =20 It is just that the WiFi uses AC with old names=E2=80=A6which ETSI and = WAVE uses for something else=E2=80=A6let=E2=80=99s describe it so: =20 At L2, there is 4 access categories, with proven properties in channel = access (I do not want to go in that direction, but there is plethora of = publications showing the impact of using EDCA and unfair access if = different WLAN uses DCF and others uses EDCA).=20 =20 At L2,=20 - AC_1 (VO) provides the highest channel access priority - AC_2 (VI) provides the second highest channel access priority - AC_3 (BE) provides a neutral access priority - AC_4 (BK) provides the lowest access priority =20 A L3 packet must be mapped to one of these 4 access categories (whatever = their names).=20 =20 It is a high(er) layer decision to do the mapping, as WLAN will only = look at the priority field and map (no question asked).=20 =20 Thus, a higher layer is forbidden to transmit VI traffic, but not to use = AC_VI if another type of traffic needs this level of priority.=20 =20 Hoping it is clearer now, BR, =20 J=C3=A9r=C3=B4me =20 ------=_NextPart_000_0088_01D3AEED.627DCC50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

 

>From: its [mailto:its-bounces@ietf.org] On Behalf Of Dr. = Hans-Joachim Fischer
>

>Be careful = with voice and audio transmission in ITS using 5,9 GHz. That seems to be = prohibited by regulation in Europe; well, not explicitly, but this is a = possible >interpretation of the = technical requirements presented in regulatory documents. In Germany, it = is prohibited.

>Hans-Joachim

Sorry to come again on this=E2=80=A6this is a big = misunderstanding=E2=80=A6there is NO audio and NO video = transmitted=E2=80=A6

 

It is just that the WiFi uses AC with old names=E2=80=A6which ETSI = and WAVE uses for something else=E2=80=A6let=E2=80=99s describe it = so:

 

At L2, there is 4 access categories, with proven properties in = channel access (I do not want to go in that direction, but there is = plethora of publications showing the impact of using EDCA and unfair = access if different WLAN uses DCF and others uses EDCA). =

 

At L2,

-          = AC_1 (VO) provides the highest channel access = priority

-          = AC_2 (VI) provides the second highest channel access = priority

-          = AC_3 (BE) provides a neutral access priority

-          = AC_4 (BK) provides the lowest access priority

 

A L3 packet must be mapped to one of these 4 access categories = (whatever their names).

 

It is a high(er) layer decision to do the mapping, as WLAN will only = look at the priority field and map (no question asked). =

 

Thus, a higher layer is forbidden to transmit VI traffic, but not to = use AC_VI if another type of traffic needs this level of priority. =

 

Hoping it is clearer now,


BR,

 

J=C3=A9r=C3=B4me

 

------=_NextPart_000_0088_01D3AEED.627DCC50-- From nobody Mon Feb 26 01:41:17 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80E62126CF6 for ; Mon, 26 Feb 2018 01:41:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2TglmaSK00R for ; Mon, 26 Feb 2018 01:41:14 -0800 (PST) Received: from smtp2.eurecom.fr (smtp2.eurecom.fr [193.55.113.211]) by ietfa.amsl.com (Postfix) with ESMTP id 7958D126D3F for ; Mon, 26 Feb 2018 01:41:13 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.47,396,1515452400"; d="scan'208,217";a="7700609" Received: from monza.eurecom.fr ([192.168.106.15]) by drago2i.eurecom.fr with ESMTP; 26 Feb 2018 10:41:12 +0100 Received: from xerus29 (unknown [192.168.200.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by monza.eurecom.fr (Postfix) with ESMTPSA id 376321948; Mon, 26 Feb 2018 10:41:12 +0100 (CET) From: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= To: "'Dr. Hans-Joachim Fischer'" , "'Abdussalam Baryun'" , "'Alexandre Petrescu'" Cc: "'Tony Li'" , "'its'" References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <9ada5591-2af3-272d-3bc3-031bf35454c3@gmail.com> <6cdc0835-fb4c-133b-77ff-0234cfdd9ef9@fischer-tech.eu> <008701d3aee5$00b4a960$021dfc20$@eurecom.fr> In-Reply-To: <008701d3aee5$00b4a960$021dfc20$@eurecom.fr> Date: Mon, 26 Feb 2018 10:41:11 +0100 Organization: EURECOM Message-ID: <009d01d3aee5$f0344ea0$d09cebe0$@eurecom.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009E_01D3AEEE.51FE5BF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHelLAw/aN7IRfcwiTBG/gKcgHVEwGONDnFAivYBTcB5QRVgwFu9SHuAdIGJvACSXL3QAH90IQfozdnfVA= Content-Language: en-us Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 26 Feb 2018 09:41:15 -0000 This is a multipart message in MIME format. ------=_NextPart_000_009E_01D3AEEE.51FE5BF0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Oh, and forgot to mention that there is a clear mapping in 802.11-2016 = between the 7-bits priority field (802.1D) and the 4 = queues=E2=80=A6nothing to do here. =20 BR, =20 J=C3=A9r=C3=B4me =20 From: its [mailto:its-bounces@ietf.org] On Behalf Of J=C3=A9r=C3=B4me = H=C3=A4rri Sent: Monday 26 February 2018 10:34 To: 'Dr. Hans-Joachim Fischer'; 'Abdussalam Baryun'; 'Alexandre = Petrescu' Cc: 'Tony Li'; 'its' Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in = IPv6-over-802.11-OCB =20 =20 >From: its [mailto:its-bounces@ietf.org] On Behalf Of Dr. Hans-Joachim = Fischer > >Be careful with voice and audio transmission in ITS using 5,9 GHz. That = seems to be prohibited by regulation in Europe; well, not explicitly, = but this is a possible >interpretation of the technical requirements = presented in regulatory documents. In Germany, it is prohibited. >Hans-Joachim Sorry to come again on this=E2=80=A6this is a big = misunderstanding=E2=80=A6there is NO audio and NO video = transmitted=E2=80=A6 =20 It is just that the WiFi uses AC with old names=E2=80=A6which ETSI and = WAVE uses for something else=E2=80=A6let=E2=80=99s describe it so: =20 At L2, there is 4 access categories, with proven properties in channel = access (I do not want to go in that direction, but there is plethora of = publications showing the impact of using EDCA and unfair access if = different WLAN uses DCF and others uses EDCA).=20 =20 At L2,=20 - AC_1 (VO) provides the highest channel access priority - AC_2 (VI) provides the second highest channel access priority - AC_3 (BE) provides a neutral access priority - AC_4 (BK) provides the lowest access priority =20 A L3 packet must be mapped to one of these 4 access categories (whatever = their names).=20 =20 It is a high(er) layer decision to do the mapping, as WLAN will only = look at the priority field and map (no question asked).=20 =20 Thus, a higher layer is forbidden to transmit VI traffic, but not to use = AC_VI if another type of traffic needs this level of priority.=20 =20 Hoping it is clearer now, BR, =20 J=C3=A9r=C3=B4me =20 ------=_NextPart_000_009E_01D3AEEE.51FE5BF0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Oh, and forgot to mention that there is a clear mapping in = 802.11-2016 between the 7-bits priority field (802.1D) and the 4 = queues=E2=80=A6nothing to do here.

 

BR,

 

J=C3=A9r=C3=B4me

 

From: its [mailto:its-bounces@ietf.org] On Behalf Of = J=C3=A9r=C3=B4me H=C3=A4rri
Sent: Monday 26 February 2018 = 10:34
To: 'Dr. Hans-Joachim Fischer'; 'Abdussalam Baryun'; = 'Alexandre Petrescu'
Cc: 'Tony Li'; 'its'
Subject: = Re: [ipwave] 802.11 Data vs 802.11 QoS Data in = IPv6-over-802.11-OCB

 

 

>From: its [mailto:its-bounces@ietf.org] = On Behalf Of Dr. Hans-Joachim Fischer
>

>Be careful = with voice and audio transmission in ITS using 5,9 GHz. That seems to be = prohibited by regulation in Europe; well, not explicitly, but this is a = possible >interpretation of the = technical requirements presented in regulatory documents. In Germany, it = is prohibited.

>Hans-Joachim

Sorry to come again on this=E2=80=A6this is a big = misunderstanding=E2=80=A6there is NO audio and NO video = transmitted=E2=80=A6

 

It is just that the WiFi uses AC with old names=E2=80=A6which ETSI = and WAVE uses for something else=E2=80=A6let=E2=80=99s describe it = so:

 

At L2, there is 4 access categories, with proven properties in = channel access (I do not want to go in that direction, but there is = plethora of publications showing the impact of using EDCA and unfair = access if different WLAN uses DCF and others uses EDCA). =

 

At L2,

-          = AC_1 (VO) provides the highest channel access = priority

-          = AC_2 (VI) provides the second highest channel access = priority

-          = AC_3 (BE) provides a neutral access priority

-          = AC_4 (BK) provides the lowest access priority

 

A L3 packet must be mapped to one of these 4 access categories = (whatever their names).

 

It is a high(er) layer decision to do the mapping, as WLAN will only = look at the priority field and map (no question asked). =

 

Thus, a higher layer is forbidden to transmit VI traffic, but not to = use AC_VI if another type of traffic needs this level of priority. =

 

Hoping it is clearer now,


BR,

 

J=C3=A9r=C3=B4me

 

------=_NextPart_000_009E_01D3AEEE.51FE5BF0-- From nobody Mon Feb 26 02:23:14 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6753126DFF for ; Mon, 26 Feb 2018 02:23:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbukqlVzRZVT for ; Mon, 26 Feb 2018 02:23:12 -0800 (PST) Received: from smtp2.eurecom.fr (smtp2.eurecom.fr [193.55.113.211]) by ietfa.amsl.com (Postfix) with ESMTP id 60415126D3F for ; Mon, 26 Feb 2018 02:23:11 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.47,396,1515452400"; d="scan'208,217";a="7700816" Received: from monza.eurecom.fr ([192.168.106.15]) by drago2i.eurecom.fr with ESMTP; 26 Feb 2018 11:23:01 +0100 Received: from xerus29 (unknown [192.168.200.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by monza.eurecom.fr (Postfix) with ESMTPSA id D58831B78 for ; Mon, 26 Feb 2018 11:23:00 +0100 (CET) From: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= To: "'its'" Date: Mon, 26 Feb 2018 11:23:00 +0100 Organization: EURECOM Message-ID: <00b601d3aeeb$c75e25e0$561a71a0$@eurecom.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B7_01D3AEF4.292A7D20" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdOu5nRtEo5NnojVQsSA7kykJ+1/6Q== Content-Language: en-us Archived-At: Subject: [ipwave] IP and L2 aspects 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, 26 Feb 2018 10:23:14 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00B7_01D3AEF4.292A7D20 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear All, =20 Not wanting to blame anybody, but from a higher level perspective, I = would like to suggest stop these endless discussions between what IPv6 = requires and what OCB does. I mean, there is a clear specification of = what OCB does (in IEEE 802.11-2016). And IETF should not specify aspects = from L2, unless the L2 spec leaves it open (which is seldom not the case = for the OCB case).=20 =20 I mean, there is a standard that has been optimized over 10 years to = operate (and be now deployed in various US state DOT), which does not = use IP. Now, it is fully legitimate to make use of IPv6 and without = using WSM or Geonet. I support this effort, as I am even co-author of = the draft and I also need this standard=E2=80=A6and I wish that we could = have a RFC by now (or even by yesterday=E2=80=A6). =20 But as IPv6 has some requirements that is not provided by OCB (not open, = rather not possible), there are some attempts to use OCB with wrong = configurations. Also there is a recurring invalid claim that = IPv6-over-OCB would be isolated (and as such independent) from other = WAVE/ETSI traffic. This is wrong, as at least that at the current form = (and similarly to attempts of C-V2X to use ITS-G5 spectra), there is a = complex debate on spectrum neutrality=E2=80=A6but the current direction = is that WAVE/ETSI have been specified first and are there (and deployed = now), so whatever comes not should not break anything. I mean, people at IETF are expert in IP, and people who designed the OCB = are expect in L2 (with 10 years of experience in making OCB work - = regardless of what is on top/L3). Now, over the endless (and recurring) = discussions over this thread, I have seen many hypothesis from IETF on = what OCB could/would do, which has been corrected by some OCB experts = (whom some of them even have been involved in the writing of the very = OCB specs). Of course, debate are always possible, what about trusting = the OCB people of what OCB does and build IPv6 over it ?=20 =20 If you think it could make sense, maybe can gather a team of OCB = experts, have them on a telco for a one-time clear-all-issues = discussion, and end all debate after this. =20 I mean, it is a fully valid to need to tweak OCB for IPv6 requirements, = but we should take OCB as it is now, make a spec on top of it as good as = possible, and enhance it later if necessary. As such, I strongly push to complete the debate on the current OCB draft = and move it to RFC, yet with leaving any L2 discussions/parameters = outside the RFC. =20 Then, if IPv6 requires something that OCB does not provide, then = let=E2=80=99s go to IEEE and ask for change. But at least we have a = spec=E2=80=A6as if we keep exchanging long e-mails and keep having = misunderstanding from what the IP community thinks of OCB and what OCB = actually is, we will never complete the work. =20 I see a need to use IPv6 over OCB (and without specifically Geonet), = example for IoT-related V2I sensor gathering, and I see there are a few = aspects to solve before this happens. Let=E2=80=99s try to solve that at = our London meeting, so we can move to other challenges of actually using = the draft/RFC for future connected vehicles applications.. =20 My two cents hoping we can move forward, BR, =20 J=C3=A9r=C3=B4me =20 =20 From: its [mailto:its-bounces@ietf.org] On Behalf Of J=C3=A9r=C3=B4me = H=C3=A4rri Sent: Monday 26 February 2018 10:41 To: 'Dr. Hans-Joachim Fischer'; 'Abdussalam Baryun'; 'Alexandre = Petrescu' Cc: 'Tony Li'; 'its' Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in = IPv6-over-802.11-OCB =20 Oh, and forgot to mention that there is a clear mapping in 802.11-2016 = between the 7-bits priority field (802.1D) and the 4 = queues=E2=80=A6nothing to do here. =20 BR, =20 J=C3=A9r=C3=B4me =20 From: its [mailto:its-bounces@ietf.org] On Behalf Of J=C3=A9r=C3=B4me = H=C3=A4rri Sent: Monday 26 February 2018 10:34 To: 'Dr. Hans-Joachim Fischer'; 'Abdussalam Baryun'; 'Alexandre = Petrescu' Cc: 'Tony Li'; 'its' Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in = IPv6-over-802.11-OCB =20 =20 >From: its [mailto:its-bounces@ietf.org] On Behalf Of Dr. Hans-Joachim = Fischer > >Be careful with voice and audio transmission in ITS using 5,9 GHz. That = seems to be prohibited by regulation in Europe; well, not explicitly, = but this is a possible >interpretation of the technical requirements = presented in regulatory documents. In Germany, it is prohibited. >Hans-Joachim Sorry to come again on this=E2=80=A6this is a big = misunderstanding=E2=80=A6there is NO audio and NO video = transmitted=E2=80=A6 =20 It is just that the WiFi uses AC with old names=E2=80=A6which ETSI and = WAVE uses for something else=E2=80=A6let=E2=80=99s describe it so: =20 At L2, there is 4 access categories, with proven properties in channel = access (I do not want to go in that direction, but there is plethora of = publications showing the impact of using EDCA and unfair access if = different WLAN uses DCF and others uses EDCA).=20 =20 At L2,=20 - AC_1 (VO) provides the highest channel access priority - AC_2 (VI) provides the second highest channel access priority - AC_3 (BE) provides a neutral access priority - AC_4 (BK) provides the lowest access priority =20 A L3 packet must be mapped to one of these 4 access categories (whatever = their names).=20 =20 It is a high(er) layer decision to do the mapping, as WLAN will only = look at the priority field and map (no question asked).=20 =20 Thus, a higher layer is forbidden to transmit VI traffic, but not to use = AC_VI if another type of traffic needs this level of priority.=20 =20 Hoping it is clearer now, BR, =20 J=C3=A9r=C3=B4me =20 ------=_NextPart_000_00B7_01D3AEF4.292A7D20 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Dear All,

 

Not wanting to blame anybody, but from a higher level perspective, I = would like to suggest stop these endless discussions between what IPv6 = requires and what OCB does. I mean, there is a clear specification of = what OCB does (in IEEE 802.11-2016). And IETF should not specify aspects = from L2, unless the L2 spec leaves it open (which is seldom not the case = for the OCB case).

 

I mean, there is a standard that has been optimized over 10 years to = operate (and be now deployed in various US state DOT), which does not = use IP. Now, it is fully legitimate to make use of IPv6 and without = using WSM or Geonet. I support this effort, as I am even co-author of = the draft and I also need this standard=E2=80=A6and I wish that we could = have a RFC by now (or even by = yesterday=E2=80=A6).

 

But as IPv6 has some requirements that is not provided by OCB (not = open, rather not possible), there are some attempts to use OCB with = wrong configurations. Also there is a recurring invalid claim that = IPv6-over-OCB would be isolated (and as such independent) from other = WAVE/ETSI traffic. =C2=A0This is wrong, as at least that at the current = form (and similarly to attempts of C-V2X to use ITS-G5 spectra), there = is a complex debate on spectrum neutrality=E2=80=A6but the current = direction is that WAVE/ETSI have been specified first and are there (and = deployed now), so whatever comes not should not break = anything.

I mean, people at IETF are expert in IP, and people who designed the = OCB are expect in L2 (with 10 years of experience in making OCB work - = regardless of what is on top/L3). Now, over the endless (and recurring) = discussions over this thread, I have seen many hypothesis from IETF on = what OCB could/would do, which has been corrected by some OCB experts = (whom some of them even have been involved in the writing of the very = OCB specs). Of course, debate are always possible, what about trusting = the OCB people of what OCB does and build IPv6 over it ? =

 

If you think it could make sense, maybe can gather a team of OCB = experts, have them on a telco for a one-time clear-all-issues = discussion, and end all debate after this.

 

I mean, it is a fully valid to need to tweak OCB for IPv6 = requirements, =C2=A0but we should take OCB as it is now, make a spec on = top of it as good as possible, and enhance it later if = necessary.

As such, I strongly push to complete the debate on the current OCB = draft and move it to RFC, yet with leaving any L2 discussions/parameters = outside the RFC.

 

Then, if IPv6 requires something that OCB does not provide, then = let=E2=80=99s go to IEEE and ask for change. But at least we have a = spec=E2=80=A6as if we keep exchanging long e-mails and keep having = misunderstanding from what the IP community thinks of OCB and what OCB = actually is, we will never complete the work.

 

I see a need to use IPv6 over OCB (and without specifically Geonet), = example for IoT-related V2I sensor gathering, and I see there are a few = aspects to solve before this happens. Let=E2=80=99s try to solve that at = our London meeting, so we can move to other challenges of actually using = the draft/RFC for future connected vehicles = applications..

 

My two cents hoping we can move forward,

BR,

 

J=C3=A9r=C3=B4me

 

 

From: its [mailto:its-bounces@ietf.org] On Behalf Of = J=C3=A9r=C3=B4me H=C3=A4rri
Sent: Monday 26 February 2018 = 10:41
To: 'Dr. Hans-Joachim Fischer'; 'Abdussalam Baryun'; = 'Alexandre Petrescu'
Cc: 'Tony Li'; 'its'
Subject: = Re: [ipwave] 802.11 Data vs 802.11 QoS Data in = IPv6-over-802.11-OCB

 

Oh, and forgot to mention that there is a clear mapping in = 802.11-2016 between the 7-bits priority field (802.1D) and the 4 = queues=E2=80=A6nothing to do here.

 

BR,

 

J=C3=A9r=C3=B4me

 

From: its [mailto:its-bounces@ietf.org] = On Behalf Of J=C3=A9r=C3=B4me H=C3=A4rri
Sent: Monday = 26 February 2018 10:34
To: 'Dr. Hans-Joachim Fischer'; = 'Abdussalam Baryun'; 'Alexandre Petrescu'
Cc: 'Tony Li'; = 'its'
Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in = IPv6-over-802.11-OCB

 

 

>From: its [mailto:its-bounces@ietf.org] = On Behalf Of Dr. Hans-Joachim Fischer
>

>Be careful = with voice and audio transmission in ITS using 5,9 GHz. That seems to be = prohibited by regulation in Europe; well, not explicitly, but this is a = possible >interpretation of the = technical requirements presented in regulatory documents. In Germany, it = is prohibited.

>Hans-Joachim

Sorry to come again on this=E2=80=A6this is a big = misunderstanding=E2=80=A6there is NO audio and NO video = transmitted=E2=80=A6

 

It is just that the WiFi uses AC with old names=E2=80=A6which ETSI = and WAVE uses for something else=E2=80=A6let=E2=80=99s describe it = so:

 

At L2, there is 4 access categories, with proven properties in = channel access (I do not want to go in that direction, but there is = plethora of publications showing the impact of using EDCA and unfair = access if different WLAN uses DCF and others uses EDCA). =

 

At L2,

-          = AC_1 (VO) provides the highest channel access = priority

-          = AC_2 (VI) provides the second highest channel access = priority

-          = AC_3 (BE) provides a neutral access priority

-          = AC_4 (BK) provides the lowest access priority

 

A L3 packet must be mapped to one of these 4 access categories = (whatever their names).

 

It is a high(er) layer decision to do the mapping, as WLAN will only = look at the priority field and map (no question asked). =

 

Thus, a higher layer is forbidden to transmit VI traffic, but not to = use AC_VI if another type of traffic needs this level of priority. =

 

Hoping it is clearer now,


BR,

 

J=C3=A9r=C3=B4me

 

------=_NextPart_000_00B7_01D3AEF4.292A7D20-- From nobody Mon Feb 26 03:38:43 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BCDC12D77A for ; Mon, 26 Feb 2018 03:38:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7kfuh3cWIXU for ; Mon, 26 Feb 2018 03:38:39 -0800 (PST) Received: from smtp2.eurecom.fr (smtp2.eurecom.fr [193.55.113.211]) by ietfa.amsl.com (Postfix) with ESMTP id BA0E112D778 for ; Mon, 26 Feb 2018 03:38:38 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.47,396,1515452400"; d="scan'208";a="7701187" Received: from monza.eurecom.fr ([192.168.106.15]) by drago2i.eurecom.fr with ESMTP; 26 Feb 2018 12:38:37 +0100 Received: from xerus29 (unknown [192.168.200.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by monza.eurecom.fr (Postfix) with ESMTPSA id 4AAF11B7; Mon, 26 Feb 2018 12:38:37 +0100 (CET) From: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= To: "'Alexandre Petrescu'" , References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <006301d3ace3$25f9d500$71ed7f00$@eurecom.fr> <007901d3aee3$a9985ba0$fcc912e0$@eurecom.fr> In-Reply-To: <007901d3aee3$a9985ba0$fcc912e0$@eurecom.fr> Date: Mon, 26 Feb 2018 12:38:36 +0100 Organization: EURECOM Message-ID: <00da01d3aef6$574c4380$05e4ca80$@eurecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHelLAw/aN7IRfcwiTBG/gKcgHVEwGONDnFAivYBTcBDgW0eQFK9evKAbex+qSjYmPfQA== Content-Language: en-us Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 26 Feb 2018 11:38:42 -0000 Hi Alex, All, After double checking IEEE802.11-2016, here are two aspects I need to = correct (sorry for my mistake)L: 1) both data and QoSData are allowed when Dot11OCBActivated=3Dtrue; 2) EDCA parameters were wrong ( I wrongly used the nonOCB ones) QoS Data combinations for OCB: AC_VO: AIFN=3D2, CWmin=3D4 CWmax=3D8=20 AC_VI: AIFN=3D3, CWmin=3D8 CWmax=3D16 AC_BE: AIFN=3D6, CWmin=3D16 CWmax=3D1024 AC_BK: AIFN=3D9, CWmin=3D16 CWmax=3D1024 Both Data and QoSData are theoretically possible, so indeed the draft = should cover this aspect.=20 Yet, I still suggest to keep QoS for IPv6, again as even if it does not = bring much 'now' for IPv6, it does not cost much either...and we should = not forgot that we might interact with EDCA transmissions (QoS) and as = such could create harmful interference on the DSRC/ITS-G5 channels. BR, J=C3=A9r=C3=B4me -----Original Message----- From: its [mailto:its-bounces@ietf.org] On Behalf Of J=C3=A9r=C3=B4me = H=C3=A4rri Sent: Monday 26 February 2018 10:25 To: 'Alexandre Petrescu'; its@ietf.org Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in = IPv6-over-802.11-OCB Hi Alex, > That is a requirement. > > But is there an implementation of mapping the priority of CAM over = DENM into a QoS Control field in QoS Data Header? > > I doubt there is, because the implementations of CAM I see put the = Priority field to 6, which means Voice. So they transmit CAM as Voice = even though it is not voice. > > We can not reckon in IPv6-over-OCB document something which makes = little sense (send CAM as Voice). Of course there is....the QoS fields actually means the Access = Categories (AC) for WLAN, so EDCA. Both in ETSI and in WAVE they use the = QoS Control filed of IEE 802.11p to send CAM/BSM with higher priority = (from a MAC perspective)...When looking at the EDCA 'naming' you should = not care much of the 'name'...this was done at the time internet was = only composed of voice, video etc..you should look at the underlying = values of each AC. So, EDCA is composed of two fields: 1) AIFN - a deterministic idle time before even considering reducing CW 2) CW - a random timer to decrease each time the channel is idle.=20 QoS Data combinations for OCB: AC_VO: AIFN=3D2, CW=3D8 AC_VI: AIFN=3D2, CW=3D16 AC_BE: AIFN=3D3, CW=3D32 AC_BK: AIFN=3D7, CW=3D32 So, it does not matter the name (Voice, video)..what matters is that in = implementation (BSM for instance), AIFN=3D2 so that it takes the fastest = access (deterministic) and as such has the highest priority. This is = also what you found: CAM on Priority field 6, so AC_VI so AIFN=3D2. BSM = uses the same strategy.=20 Now, on the CAR 2 CAR specification, it is recommended a different = priority: AC_BE, as it uses DP2. The reason behind this is the CAR2CAR = provides a 'strict' prioritization between DENMs and CAMs. Emergency = DENMs uses AC_VI, normal DENM uses AC_VO, CAM uses AC_BE and any other = traffic AC_BK. So, bottom line is: all ETSI and WAVE implementation use the QoS Data = field as they use EDCA. If you found an implementation that does not use = the QoS, it is wrong according to the standard. >> Now, as you abstract ETSI and WAVE (thus pure IP), my understanding=20 >> is that QoS remains required from the IEEE 802.11p (ok, IEEE >> 802.11-2016 OCB) as there is a specification of the EDCA parameters=20 >> for OCB. Besides, I do not think it costs much to keep the EDCA in,=20 >> as it first allows to safe a half of the MAC queueing time (the EDCA=20 >> parameters for the two low AC are less, up to a quarter of a=20 >> DIFS...so, it could be beneficial to allow this even for IP. Second,=20 >> the EDCA allows TXOpps (Transmit Opportunities)..although put to=20 >> 'zero' for OCB (I think), this mechanism still allows an AP to=20 >> reserve a given time a long(er) connectivity with one device (e. >> streaming of video etc..). Finally, it does not cost anything..you=20 >> can always take the lowest AC and you get the same behavior as = non-QoS.. >Well, this text is more informal in nature. It is something that >describes a potential behaviour but we have no proof of existing such = behaviour, no proof of interoperability. This could be part of an = INFORMATIONAL Internet Draft. Well, my text is informal, but the specs are not. IEEE 802.11p (IEEE = 802.11-2016 OCB) uses EDCA not DCF...as this is L2 layer, I do not think = anything is required from IETF...just follow the IEEE 802.11-2016 specs = and do whatever is allows above it...I will double check again on the = IEEE 802.11-2016, but if what I think is confirmed, the whole discussion = does not make any sense..., as it is my understanding that the OCB = requires EDCA, so QoS_Data...so, you cannot change that at IP level. >> Bottom line, the fact that some IP implementation to decode OCB=20 >> assume non-QoS frames looks more to me like an implementation error=20 >> and we should not propagate this... >Well, wireshark has problems interpreting 802.11 QoS Data containing = CAM messages. Many receivers of QoS Data dont know what to do with the = fields because they are not agreed. Yes, and this is why is the prototype we use, we actually have an parser = for CAM to be supported by Wireshark...it does not come by default. But = I am surprised..what kind of problem would wireshark face with the QoS = Data?=20 > I don't want to propagate that disagreement into the IP-over-OCB = draft. To me, this looks more like an implementation issue, rather than a = standard issue...but I will ask my team to check on our prototype... >> C-V2X will not use IP for CAM, >LTE-V2X will carry CAM in IP. What is C-V2X and why does not it use = IP? Sorry, it will not. In C-V2X (the widely known name...LTE-V2X is again a = bit like 802.11p...'LTE Prose for V2X' is the real name...), mode 4 = (ad-hoc mode..currently chosen by all vendors (except maybe Huawei, but = might have changed), there is two options for protocol stack: IPv6 = (again, only IPv6) and non-IP (L2)...you can use non-IP packets and it = is so mentioned that BSM and CAM will use the non-IP option, as it is = also required to use the ETSI/WAVE security provisions to secure the = C-V2X mode 4 (as no SIM=3D no security), as the ETSI/WAVE security = provisions works for non-IP packets (geonet or WSM)... Of course, it does not block from using IP...it is again the same = discussion we had with ITS-G5/DSRC...for safety communication, IP is not = required...you can do everything without and faster. And considering = that IEEE 802.11p (ok, OCB) and C-V2X mode 4 (no SIM=3Dno SEC) DO NOT = have any form of security mechanism embedded, they must use the those = specified by ETSI/WAVE for accessing CCH. Again, C-V2X mode 4 (the current V2X techno for Safety-critical = communication) shall not be seen as following the same path as other = cellular techno. It does not provide QoS (at all), as it channel access = is contention-based (a bit like CSMA)...so collisions will occur (unlike = 4G and 5G operated, where you are either dropped or you pass). And as = such, IP is also not required, even if all 4G and 5G use IP. >> ETSI and WAVE will not use IP for CAM... >That is their problem. Disagree: you need to be compatible with them...so, whatever IETF will = do shall not break anything that has been done on ETSI or WAVE. This is = one of the requirement for accessing the ITS-G5 spectrum in EU, and I = believe the same in the US. >ETSI transports IP over GeoNetworking - that is not the right way to do = it. Disagree: we need to integrate security mechanisms specified by ETSI = even if we use IPv6. Today, we do not have any security specification = providing 'trust', privacy and authentication for using 802.11-OCB (I = believe it is the work of IPWAVE and it is not completed yet...).=20 The mistake ETSI did is to try to be nice with IETF and help them to = provide a way to use IPv6 over ITS-G5 in a secured way...WAVE took a = different path: 'not my problem', which then explain why ETSI officially = does not endorse IPWAVE (unfortunately, despite my many discussions with = them)...from an ETSI perspective, using IPv6 over ITS-G5 is = solved...(might be ugly, but it is solved). =20 >> the basic CAMs are used for pure positioning >The mandatory fields in CAM or more than just lat/long/altitude. There = is also mandatory time in a strange format, car dimensions, curve, non = standard precisions and more. Yes, correct...but these are configurable fields, which may or may not = be integrated...recent studies even showed that even the standard CAM = size is not clear anymore..you have a 'range' of size, and that is a = problem for wireless optimization...especially if you need to do = wireless congestion control. >> and the recent 'increase' of information put in CAM >If CAM worries about size, I think CAM should think about its existing = redundancy. For example, position is carried twice in a CAM message: in = the CAM itself and in the GeoNetworking header. That >is an issue they = should address first. Well, of course, this is a waste...but one reason for such existence is = from the possibility to relay a packet (agnostic from the upper = messages, unfortunately, we cannot use a Zero-NET for CAM as it is pure = 1-hop TSB)... Yet, today we start seeing even BSM investigating ways to do multi-hop = 'position' based relaying to reach longer distance.=20 And if you think about it, one day, your IPv6-over-OCB might need to use = a multi-hop networking protocol (e.g. MANET)..but doing the MANET way is = highly mobile environment will not be that efficient...position-based = mechanisms will be required (proven in various previous studies)...now, = your L3 will not be able to inspect the GPS position of your = CAM-over-IP...so, you will need to have GPS (or so) position at IP/L3, = which will end up being similar than now... If you do not want to do this, then the IRTF people might come with ICN, = but then would this be done above L3 or at L3...if still at L3, you = still will have a contextual L3 packet that might be redundant with = application/service layer messages...(the cost of using OSI) But this is just my personal view and very long term...for now, if we = only look at CAM, indeed we can have twice the GPS position (but wait: = not the same granularity and you do not have elevation in geonet). But = if you look at the bigger picture: doing CAM-over-geonet only required = a single CAM, that's it. For IPv6-over-OCB, you need all the IPv6 = address autoconfiguration..that requires additional IPv6 packets to be = transmitted...this is similar to compare an apple with a tomato. =20 >> looks to be like a bad strategy as we end up having a container=20 >> carrying too many things and being too big for what it is... >I agree. But I think we should compare header sizes and then there = will be surprises. >CAM transported in IP may be a smaller packet than CAM transported in = BTP and GeoNetworking. Not that much if you counts also all IPv6-related control/management = packets required to transmit your CAM-over-OCB, in a highly dynamic = environment... > (WLAN is good at squeezing various small packets but really not good=20 > at big things especially in broadcast mode)...a better strategy would=20 > be to define new messages tailored to the information needs, and have=20 > smart service scheduling...(especially benefiting from IP-related > mechanisms) > I fully agree with this. :-) at least we do on this :-) Cheers, J=C3=A9r=C3=B4me _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its From nobody Mon Feb 26 04:16:58 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD251242F7 for ; Mon, 26 Feb 2018 04:16:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYxl7vdRvuaq for ; Mon, 26 Feb 2018 04:16:54 -0800 (PST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (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 6A683124234 for ; Mon, 26 Feb 2018 04:16:54 -0800 (PST) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1eqHi5-0008T7-K5; Mon, 26 Feb 2018 13:16:49 +0100 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 899B6420484; Mon, 26 Feb 2018 13:16:49 +0100 (CET) To: Russ Housley , Rex Buddenberg , =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , Tony Li , Alexandre Petrescu Cc: its@ietf.org References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <006b01d3ace3$f0168e00$d043aa00$@eurecom.fr> <1519418411.2226.429.camel@gmail.com> <9231453B-5144-4FAE-8475-72B2708EE239@vigilsec.com> From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology Message-ID: <80cd759d-c521-ce19-c7ee-06947c101142@kit.edu> Date: Mon, 26 Feb 2018 13:16:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <9231453B-5144-4FAE-8475-72B2708EE239@vigilsec.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1519647409.677111891 Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 26 Feb 2018 12:16:56 -0000 Hi, see inline. Am 24.02.2018 um 20:55 schrieb Russ Housley: >>> IP could not benefit much from it… >> >> ?? Was IP using diff-serv? It would seem that if you are going to >> shuffle queues (sort traffic) at layer 2, you need to at layer 3 as >> well. And the sorting flags need to be coherent at both layers?? > > Indeed. Without specifying the linkage between the IEEE 802.11 QoS and DiffServ code points, there will not be any significant value. There is such a document, it was recently published as RFC: Mapping Diffserv to IEEE 802.11 https://datatracker.ietf.org/doc/rfc8325/ > If memory serves, there was recently sone discussion about DiffServe in 6man. However, I do not know if the work being done there would cover this situation. Cheers Roland From nobody Mon Feb 26 04:27:46 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F060C126DD9 for ; Mon, 26 Feb 2018 04:27:43 -0800 (PST) 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 b6cxRO-xaACE for ; Mon, 26 Feb 2018 04:27:42 -0800 (PST) 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 D55471242F7 for ; Mon, 26 Feb 2018 04:27:41 -0800 (PST) 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 w1QCQiOT029694; Mon, 26 Feb 2018 13:26:44 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id EF8CF2051F6; Mon, 26 Feb 2018 13:26:43 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id E2E2020325B; Mon, 26 Feb 2018 13:26:43 +0100 (CET) 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 w1QCQhuc009036; Mon, 26 Feb 2018 13:26:43 +0100 To: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , its@ietf.org References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <006301d3ace3$25f9d500$71ed7f00$@eurecom.fr> <007901d3aee3$a9985ba0$fcc912e0$@eurecom.fr> <00da01d3aef6$574c4380$05e4ca80$@eurecom.fr> From: Alexandre Petrescu Message-ID: <0e65b8c6-9226-9369-b05f-dc0476805d40@gmail.com> Date: Mon, 26 Feb 2018 13:26:43 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <00da01d3aef6$574c4380$05e4ca80$@eurecom.fr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 26 Feb 2018 12:27:44 -0000 Le 26/02/2018 à 12:38, Jérôme Härri a écrit : > Hi Alex, All, > > After double checking IEEE802.11-2016, here are two aspects I need to correct (sorry for my mistake)L: > 1) both data and QoSData are allowed when Dot11OCBActivated=true; Yes, IEEE allows for both alternatives. The Data alternative is what open-source implementations do. (the OCB mode in linux kernel). The QoSData alternative is what many closed-source non-IP stacks do. > 2) EDCA parameters were wrong ( I wrongly used the nonOCB ones) > > QoS Data combinations for OCB: > AC_VO: AIFN=2, CWmin=4 CWmax=8 > AC_VI: AIFN=3, CWmin=8 CWmax=16 > AC_BE: AIFN=6, CWmin=16 CWmax=1024 > AC_BK: AIFN=9, CWmin=16 CWmax=1024 Thanks for the detail. > Both Data and QoSData are theoretically possible, so indeed the draft should cover this aspect. I agree both are theoretically possible, but I dont know whether the draft should cover both. On my side, I do not know how these QoSData headers are generated by software, because I have no access to that software. It is closed source. I know some of the company names doing it. On another hand, the Data headers are open source, so we know how they are generated. > Yet, I still suggest to keep QoS for IPv6, Well, how about keeping just an entry point for QoSData now, to speed to IESG, and later write a document about IPv6-over-OCB-QoS. > again as even if it does not bring much 'now' for IPv6, it does not > cost much either...and we should not forgot that we might interact > with EDCA transmissions (QoS) and as such could create harmful > interference on the DSRC/ITS-G5 channels. If there is interference, it is because IEEE allows both Data and QoSData; it is not because IP prefers Data. Here I am more afraid of lack of interoperability, rather than of interference. Some stacks are not interoperable because of these Data vs QoSData assumptions. github.com/rendits does not interoperate with company X and Y, nor vice-versa, because of these Data vs QoSData. Alex From nobody Mon Feb 26 04:31:55 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C18451242F7 for ; Mon, 26 Feb 2018 04:31:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1K-Jm3su-sOB for ; Mon, 26 Feb 2018 04:31:52 -0800 (PST) Received: from smtp2.eurecom.fr (smtp2.eurecom.fr [193.55.113.211]) by ietfa.amsl.com (Postfix) with ESMTP id 7C27D124234 for ; Mon, 26 Feb 2018 04:31:52 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.47,396,1515452400"; d="scan'208";a="7701309" Received: from monza.eurecom.fr ([192.168.106.15]) by drago2i.eurecom.fr with ESMTP; 26 Feb 2018 13:31:51 +0100 Received: from xerus29 (unknown [192.168.200.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by monza.eurecom.fr (Postfix) with ESMTPSA id 384635E8; Mon, 26 Feb 2018 13:31:51 +0100 (CET) From: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= To: "'Bless, Roland \(TM\)'" , "'Russ Housley'" , "'Rex Buddenberg'" , "'Tony Li'" , "'Alexandre Petrescu'" Cc: References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <006b01d3ace3$f0168e00$d043aa00$@eurecom.fr> <1519418411.2226.429.camel@gmail.com> <9231453B-5144-4FAE-8475-72B2708EE239@vigilsec.com> <80cd759d-c521-ce19-c7ee-06947c101142@kit.edu> In-Reply-To: <80cd759d-c521-ce19-c7ee-06947c101142@kit.edu> Date: Mon, 26 Feb 2018 13:31:50 +0100 Organization: EURECOM Message-ID: <00ef01d3aefd$c728b8d0$557a2a70$@eurecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHelLAw/aN7IRfcwiTBG/gKcgHVEwGONDnFAivYBTcB5QRVgwMwtBtqAYJCmloCXJSOEwHnBQLeoywk1tA= Content-Language: en-us Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 26 Feb 2018 12:31:54 -0000 Excellent... Thanks Roland.. I think we should mention this in this IPv6-over-OCB draft... BR, J=C3=A9r=C3=B4me -----Original Message----- From: Bless, Roland (TM) [mailto:roland.bless@kit.edu]=20 Sent: Monday 26 February 2018 13:17 To: Russ Housley; Rex Buddenberg; J=C3=A9r=C3=B4me H=C3=A4rri; Tony Li; = Alexandre Petrescu Cc: its@ietf.org Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in = IPv6-over-802.11-OCB Hi, see inline. Am 24.02.2018 um 20:55 schrieb Russ Housley: >>> IP could not benefit much from it=E2=80=A6 >> >> ?? Was IP using diff-serv? It would seem that if you are going to=20 >> shuffle queues (sort traffic) at layer 2, you need to at layer 3 as=20 >> well. And the sorting flags need to be coherent at both layers?? >=20 > Indeed. Without specifying the linkage between the IEEE 802.11 QoS = and DiffServ code points, there will not be any significant value. There is such a document, it was recently published as RFC: Mapping Diffserv to IEEE 802.11 https://datatracker.ietf.org/doc/rfc8325/ > If memory serves, there was recently sone discussion about DiffServe = in 6man. However, I do not know if the work being done there would = cover this situation. Cheers Roland From nobody Mon Feb 26 04:50:28 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF4F8124234 for ; Mon, 26 Feb 2018 04:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6UzLkMnMLMs for ; Mon, 26 Feb 2018 04:50:24 -0800 (PST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (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 0EEB7126E01 for ; Mon, 26 Feb 2018 04:50:23 -0800 (PST) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1eqIEV-0006F7-Qb; Mon, 26 Feb 2018 13:50:19 +0100 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id BBDF7420484; Mon, 26 Feb 2018 13:50:19 +0100 (CET) To: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , 'its' References: <00b601d3aeeb$c75e25e0$561a71a0$@eurecom.fr> From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology Message-ID: <03412d69-afe0-3787-ae95-b92e936af08a@kit.edu> Date: Mon, 26 Feb 2018 13:50:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <00b601d3aeeb$c75e25e0$561a71a0$@eurecom.fr> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1519649419.885040516 Archived-At: Subject: Re: [ipwave] IP and L2 aspects 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, 26 Feb 2018 12:50:26 -0000 Hi Jérôme, Am 26.02.2018 um 11:23 schrieb Jérôme Härri: > Not wanting to blame anybody, but from a higher level perspective, I > would like to suggest stop these endless discussions between what IPv6 > requires and what OCB does. I mean, there is a clear specification of > what OCB does (in IEEE 802.11-2016). And IETF should not specify aspects > from L2, unless the L2 spec leaves it open (which is seldom not the case > for the OCB case). I disagree a bit with "IETF should not specify aspects from L2" if the link layer designers can imagine that IP is run some day over their protocol. In this case, the link layers should probably consider RFC3814 'Advice for Internet Subnetwork Designers'from 2004: https://tools.ietf.org/html/rfc3819 Thus, the IETF provides _recommendations_ for link layer designers. > I mean, there is a standard that has been optimized over 10 years to > operate (and be now deployed in various US state DOT), which does not > use IP. Now, it is fully legitimate to make use of IPv6 and without > using WSM or Geonet. I support this effort, as I am even co-author of > the draft and I also need this standard…and I wish that we could have a > RFC by now (or even by yesterday…). So in case the link layer doesn't fulfill the requirements an adaptation layer can be used as in 6lowpan or the proposed draft-ietf-ipwave-ipv6-over-80211ocb This is obviously an extra effort, but allows to have better performance and less overhead for non-IP communications. Regards Roland From nobody Mon Feb 26 05:16:30 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 471D7126DED for ; Mon, 26 Feb 2018 05:16:28 -0800 (PST) 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 kxE6GqcFkXio for ; Mon, 26 Feb 2018 05:16:26 -0800 (PST) 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 91D9D126DC2 for ; Mon, 26 Feb 2018 05:16:26 -0800 (PST) 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 w1QDGNSB149430; Mon, 26 Feb 2018 14:16:23 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 22766205214; Mon, 26 Feb 2018 14:16:23 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 0BD9420516D; Mon, 26 Feb 2018 14:16:23 +0100 (CET) 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 w1QDGMhx006540; Mon, 26 Feb 2018 14:16:22 +0100 To: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , "'Bless, Roland (TM)'" , "'Russ Housley'" , "'Rex Buddenberg'" , "'Tony Li'" Cc: its@ietf.org References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <006b01d3ace3$f0168e00$d043aa00$@eurecom.fr> <1519418411.2226.429.camel@gmail.com> <9231453B-5144-4FAE-8475-72B2708EE239@vigilsec.com> <80cd759d-c521-ce19-c7ee-06947c101142@kit.edu> <00ef01d3aefd$c728b8d0$557a2a70$@eurecom.fr> From: Alexandre Petrescu Message-ID: <22a0f386-0fc4-3cad-73fd-5b23ff7c8359@gmail.com> Date: Mon, 26 Feb 2018 14:16:22 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <00ef01d3aefd$c728b8d0$557a2a70$@eurecom.fr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 26 Feb 2018 13:16:28 -0000 Le 26/02/2018 à 13:31, Jérôme Härri a écrit : > Excellent... > > Thanks Roland.. > > I think we should mention this in this IPv6-over-OCB draft... Right now the draft mentions draft-ietf-tsvwg-ieee-802-11-11 which is a precursor of that RFC. I could update it to the RFC number if necessary. draft says: > 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. The existence of that RFC8325 does not solve the interoperability problem. If we continue to say that IPv6 could be sent either as QoSData, or alternatively as Data, any day someone will send it differently than the others can receive. If, on the other hand, the linux kernel implemented QoSData in an open source code, and that it worked fine, then I could agree with you. But up to now I feel like the QoSData is implemented _only_ by closed-source proprietary code to which I have no access. If someone could show a packet dump of an IPv6 packet carried with 802.11 QoSData header, then I would agree to document it in this draft. Alex From nobody Mon Feb 26 08:12:38 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D71D812D82F for ; Mon, 26 Feb 2018 08:12:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GS_l87WGXVix for ; Mon, 26 Feb 2018 08:12:34 -0800 (PST) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::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 0548412D80E for ; Mon, 26 Feb 2018 08:12:34 -0800 (PST) Received: by mail-qt0-x22a.google.com with SMTP id u11so7426277qtg.7 for ; Mon, 26 Feb 2018 08:12:33 -0800 (PST) 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:thread-index:content-language; bh=8otazCddD0C6x5xJsIojEYfU40KD4PyamwpLaXEAdu4=; b=RQ5qI9Wkbk1fWrNcKeTAIRmAqJaVyEYNkI+Xio0Y6EuI0uVoC09WWhUnzdGxBp1CQn 7Fht/eA9GhFYEfwabYgj9C9FRDvEZRtrsKapKt0ruRgh9iFq/+eGfQkKshmi4emOZ7OS f2IR1y/u51YSdRW6dGDYjoZExCeRZ717lS2A6PJrP99kKumVZJ6zCrZn3EeGiqw6rup4 E02rIlEorVROFPkljhLXagGhV2zxjmqzlf8pQXjVHRGaAKHRk4qTxuMExBaHDzAGaFnp LCKKPOM6s3AA4J2UG1G+7VTAAb5J5/+caUk0Ll41syJtN3ak4+/hMiTGCfWYdppVH32n 4Oxg== 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:thread-index:content-language; bh=8otazCddD0C6x5xJsIojEYfU40KD4PyamwpLaXEAdu4=; b=DSLAinJZqdoCxvkL+DaOvqaVigSmz6v2DB16ZWXnVizo4M3XjhRUHN5koQamVrEI3W 5q0eDjYYUFIgmii0+nKRw48DC33s41b6xBrAb4Y9LwH5XTH/YdFdEk3VAUjIjIwzp16M 6wbZAgEZIbfHr9WgcV8SBZyxsIm3fpIOQVBqW4LfKSWl4nFkitkijD80d5lBWaB3B13+ vIH9yVH2PgcXsp+m/hAjp360RyTVJFkqRNAp/zklJ3oX7bdtKm2OGLYN2g607mK9rhvX vjPVQnInjjPU1WM9QwNigPz2LytB7nqwYBbUQ7LLdHZjoTe59icUw7VzGwCqpNTIQOxd XK4Q== X-Gm-Message-State: APf1xPBKcZQvzua6pAv1sC2RudwZT15iTDM0/JsRYRKl95BcgIYtPCnv mYnzi2U1ZWyHReTVM1i2TFQ= X-Google-Smtp-Source: AG47ELtasPWzfeHReMrZkxEl5igx59265yp00J9mptJL54Koh1KOoq+c1ScNGrVCDU3Tdbowykq+fw== X-Received: by 10.200.48.145 with SMTP id v17mr18320203qta.296.1519661553202; Mon, 26 Feb 2018 08:12:33 -0800 (PST) Received: from FrancoisPC (pool-108-48-182-86.washdc.fios.verizon.net. [108.48.182.86]) by smtp.gmail.com with ESMTPSA id p142sm4886232qke.4.2018.02.26.08.12.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Feb 2018 08:12:32 -0800 (PST) From: =?UTF-8?Q?Fran=C3=A7ois_Simon?= To: "'Abdussalam Baryun'" , "'Alexandre Petrescu'" Cc: "'Tony Li'" , "'its'" , References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <9ada5591-2af3-272d-3bc3-031bf35454c3@gmail.com> In-Reply-To: Date: Mon, 26 Feb 2018 11:12:31 -0500 Message-ID: <00d201d3af1c$9b1bc5b0$d1535110$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D3_01D3AEF2.B24807A0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHelLAw/aN7IRfcwiTBG/gKcgHVEwGONDnFAivYBTcB5QRVgwFu9SHuAdIGJvCjWgJ7QA== Content-Language: en-us Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 26 Feb 2018 16:12:36 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00D3_01D3AEF2.B24807A0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If this comment relates to the access category (AC): background (BK), = best effort (BE), video (VI) and voice (VO), it is derived from IEEE = 802.1D which indicates a list of =E2=80=9Ctraffic type that can benefit = from segregation from the others and seems to command wide spread = support=E2=80=9D. The four access categories: AC_BK, AC_BE, AC_VI, and = AC_VO defined in OCB are derived from the 802.1D list. This is just = INFORMATIVE and does not implies any restriction. The naming as been = retained to represent priorities: AC_BK =E2=80=93 lowest priority and = AC_VI =E2=80=93 highest priority; Any 802.11 data or 802.11 QoS data can = be assigned any of the four priorities. Fygs =20 From: its [mailto:its-bounces@ietf.org] On Behalf Of Abdussalam Baryun Sent: Monday, February 26, 2018 3:05 AM To: Alexandre Petrescu Cc: Tony Li ; its Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in = IPv6-over-802.11-OCB =20 The experience test you referred to is not clarified, was it a ITS = environment experience or was it a fixed wireless experience. = Furthermore, the WiFi technology ieee802.11 is developed so which WiFi = technology was used. Moreover, did your experience use Video and voice = communication or your proposal is only for data communication only. =20 So if your IP packet are data then your experience is right, but if the = IP packet is carrying voice or video I don't agree. IMO we could not = exclude from the draft voice and video communication in the ITS = environment/use-case.=20 =20 On Sun, Feb 25, 2018 at 7:58 PM, Alexandre Petrescu = > = wrote: Le 23/02/2018 =C3=A0 18:38, Tony Li a =C3=A9crit : =20 If we put that CAM on IP there will still be lack of interoperability, unless we recommend IP to be carried by a particular 802.11 header (Data or QoS Data). I would propose that we use the Data header. My experience with the QoS = Data with Wi-Fi was that there wasn=E2=80=99t enough of a performance = difference with QoS for it to make a difference to the IP layer. I agree. I propose the following text. OLD: In OCB mode, IPv6 packets MAY be transmitted either as "IEEE 802.11 Data" or alternatively as "IEEE 802.11 QoS Data", as illustrated in Figure 2. NEW: In OCB mode, it is RECOMMENDED to transmit IPv6 packets as "IEEE 802.11 Data" (the value of the field Subtype in the Frame Control Field is 0). Alex _______________________________________________ its mailing list its@ietf.org =20 https://www.ietf.org/mailman/listinfo/its =20 ------=_NextPart_000_00D3_01D3AEF2.B24807A0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

If this = comment relates to the access category (AC): background (BK), best = effort (BE), video (VI) and voice (VO), it is derived from IEEE 802.1D = which indicates a list of =E2=80=9Ctraffic type that can benefit from = segregation from the others and seems to command wide spread = support=E2=80=9D. The four access categories: AC_BK, AC_BE, AC_VI, = and AC_VO defined in OCB are derived from the 802.1D list.=C2=A0 This is = just INFORMATIVE and does not implies any restriction.=C2=A0 The naming = as been retained to represent priorities: AC_BK =E2=80=93 lowest = priority and AC_VI =E2=80=93 highest priority; Any 802.11 data or 802.11 = QoS data can be assigned any of the four priorities.=C2=A0=C2=A0 = Fygs

 

From: its [mailto:its-bounces@ietf.org] On = Behalf Of Abdussalam Baryun
Sent: Monday, February 26, = 2018 3:05 AM
To: Alexandre Petrescu = <alexandre.petrescu@gmail.com>
Cc: Tony Li = <tony1athome@gmail.com>; its = <its@ietf.org>
Subject: Re: [ipwave] 802.11 Data vs = 802.11 QoS Data in IPv6-over-802.11-OCB

 

The experience test you referred to is not = clarified, was it a ITS environment experience or was it a fixed = wireless experience. Furthermore, the WiFi technology ieee802.11 is = developed so which WiFi technology was used. Moreover, did your = experience use Video and voice communication or your proposal is = only for data communication only.

 

So if your IP packet are data then your experience is = right, but if the IP packet is carrying voice or video I don't agree. = IMO we could not exclude from the draft voice and video = communication in the ITS = environment/use-case. 

 

On Sun, = Feb 25, 2018 at 7:58 PM, Alexandre Petrescu <alexandre.petrescu@gmail.com> = wrote:



Le 23/02/2018 =C3=A0 18:38, Tony Li a = =C3=A9crit :

 

If we put = that CAM on IP there will still be lack of interoperability,
unless = we recommend IP to be carried by a particular 802.11 header (Data
or = QoS Data).



I = would propose that we use the Data header. My experience with the QoS = Data with Wi-Fi was that there wasn=E2=80=99t enough of a performance = difference with QoS for it to make a difference to the IP = layer.


I = agree.

I propose the following = text.

OLD:

  =  In OCB mode, IPv6 packets MAY be transmitted either as "IEEE = 802.11
   Data" or alternatively as "IEEE 802.11 = QoS Data", as illustrated in
   Figure = 2.


NEW:

  =  In OCB mode, it is RECOMMENDED to transmit IPv6 packets as = "IEEE
   802.11 Data" (the value of the field = Subtype in the Frame Control
   Field is = 0).


Alex

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

 

------=_NextPart_000_00D3_01D3AEF2.B24807A0-- From nobody Mon Feb 26 08:19:04 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B132412D7F4 for ; Mon, 26 Feb 2018 08:19:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.689 X-Spam-Level: X-Spam-Status: No, score=-1.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 Pdbm4wfNziDq for ; Mon, 26 Feb 2018 08:18:58 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41518126CBF for ; Mon, 26 Feb 2018 08:18:57 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id f25so19721187qkm.0 for ; Mon, 26 Feb 2018 08:18:57 -0800 (PST) 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:thread-index:content-language; bh=5kaGRMeuw2/bVn9TXewTMznSRCS23ND28EnaaEH4HMU=; b=VB/MvHdnwY5quzUzEp/7gLsWvmST9VXdFFWeP9ck4Gb4ibrHNyS7j6wVyrDdz9DeqE qXbMUQEB4TVhD25a9n19M6/FHWQo3ft89JUzAa+dJVWqB/KBEr3Rox2ntwBkCdoT8jmu V/t+FIDcQbNhCKxSULxNl3rj3rVMKdkOsppX2eQ0dNAlEA13Uqq4Y8kW6/NSu/304QU/ FyUdcOhPDZyrBubavyMoNYYx0oRcktTU9KZN+p3rYQEhFlZU78HZbrWEaPG/cM/5Jt3s ri40PMJSuFSqie6FWsRGHaGKDlJoiuz5vuz/jYwcRyVxL0LdKcJqhzNztXJle38Y3bEG Q7JQ== 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:thread-index:content-language; bh=5kaGRMeuw2/bVn9TXewTMznSRCS23ND28EnaaEH4HMU=; b=eDTiITGXWpZ7eTWoH1mU+GPOO3aGkEw/Fpb8dbuvyFeZIG2jc02kAtBChNAwoLJBV7 5Sa3D4WDujkZnrk48xDR4W4Ocl8w65f0BwO9cGBaI4dLR/NTdS4/TUUXAm9xI5JWkWnx 3Qt0/C0gO3PJFeONI4mC3LuEpd3BDWwG491hkyVfOUqpWyUN78ecBUKJWFq5F88JuW3x ZLONdBpMS01O8zgN3z0ofQF9aJK7YwoWD0mUaX5xXt097kzCVaQPJXHqCamx5IciyG1V 4uI5aDVABQfhQv3Q4XpPf8L4gCnahkENvzytWs46Gv3XlPHUEnd9OeG9taE2J8mho4vW seeA== X-Gm-Message-State: APf1xPCc5ClyVWqx2UlUMe7tcc1BNkMnmX2g43/RvKG8QbrM+Z3tLygp tmqNJZ5nTSmx8/k93ZYUdKE= X-Google-Smtp-Source: AG47ELuNrCCuCVMfjKizuK7CVH62/TvO8xGRKpBY3dZCWNPrOIZxbraYKbXRTtNBQiepoF3IUnATvg== X-Received: by 10.55.215.205 with SMTP id t74mr17189025qkt.259.1519661936233; Mon, 26 Feb 2018 08:18:56 -0800 (PST) Received: from FrancoisPC (pool-108-48-182-86.washdc.fios.verizon.net. [108.48.182.86]) by smtp.gmail.com with ESMTPSA id c42sm5490518qtc.42.2018.02.26.08.18.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Feb 2018 08:18:55 -0800 (PST) From: =?UTF-8?Q?Fran=C3=A7ois_Simon?= To: "'Dr. Hans-Joachim Fischer'" , "'Abdussalam Baryun'" , "'Alexandre Petrescu'" Cc: "'Tony Li'" , "'its'" References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <9ada5591-2af3-272d-3bc3-031bf35454c3@gmail.com> <6cdc0835-fb4c-133b-77ff-0234cfdd9ef9@fischer-tech.eu> In-Reply-To: <6cdc0835-fb4c-133b-77ff-0234cfdd9ef9@fischer-tech.eu> Date: Mon, 26 Feb 2018 11:18:53 -0500 Message-ID: <00eb01d3af1d$7f4e8100$7deb8300$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EC_01D3AEF3.967AEA00" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHelLAw/aN7IRfcwiTBG/gKcgHVEwGONDnFAivYBTcB5QRVgwFu9SHuAdIGJvACSXL3QKNHxY9A Content-Language: en-us Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 26 Feb 2018 16:19:01 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00EC_01D3AEF3.967AEA00 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable AC_VO (voice) is only a label indicating the highest priority; nothing = more is implied. =20 From: its [mailto:its-bounces@ietf.org] On Behalf Of Dr. Hans-Joachim = Fischer Sent: Monday, February 26, 2018 3:37 AM To: Abdussalam Baryun ; Alexandre Petrescu = Cc: Tony Li ; its Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in = IPv6-over-802.11-OCB =20 =20 Be careful with voice and audio transmission in ITS using 5,9 GHz. That = seems to be prohibited by regulation in Europe; well, not explicitly, = but this is a possible interpretation of the technical requirements = presented in regulatory documents. In Germany, it is prohibited. Hans-Joachim =20 Am 26.02.2018 um 09:04 schrieb Abdussalam Baryun: The experience test you referred to is not clarified, was it a ITS = environment experience or was it a fixed wireless experience. = Furthermore, the WiFi technology ieee802.11 is developed so which WiFi = technology was used. Moreover, did your experience use Video and voice = communication or your proposal is only for data communication only. =20 So if your IP packet are data then your experience is right, but if the = IP packet is carrying voice or video I don't agree. IMO we could not = exclude from the draft voice and video communication in the ITS = environment/use-case.=20 =20 On Sun, Feb 25, 2018 at 7:58 PM, Alexandre Petrescu = > = wrote: Le 23/02/2018 =C3=A0 18:38, Tony Li a =C3=A9crit : =20 If we put that CAM on IP there will still be lack of interoperability, unless we recommend IP to be carried by a particular 802.11 header (Data or QoS Data). I would propose that we use the Data header. My experience with the QoS = Data with Wi-Fi was that there wasn=E2=80=99t enough of a performance = difference with QoS for it to make a difference to the IP layer. I agree. I propose the following text. OLD: In OCB mode, IPv6 packets MAY be transmitted either as "IEEE 802.11 Data" or alternatively as "IEEE 802.11 QoS Data", as illustrated in Figure 2. NEW: In OCB mode, it is RECOMMENDED to transmit IPv6 packets as "IEEE 802.11 Data" (the value of the field Subtype in the Frame Control Field is 0). Alex _______________________________________________ its mailing list its@ietf.org =20 https://www.ietf.org/mailman/listinfo/its =20 _______________________________________________ its mailing list its@ietf.org =20 https://www.ietf.org/mailman/listinfo/its --=20 Dr. Hans-Joachim Fischer Managing Director =20 -------------------------------------------------------------------------= -------=20 =20 ESF News edition 2018/1 https://fischer-tech.eu/Feeds/News/ESF-News-2018-01.pdf =20 -------------------------------------------------------------------------= -------=20 Towards deployment of C-ITS based on proven technology Avoid risks and delay by looking on potential future technologies. =20 The real advocate on ITS is ISO TC204! -------------------------------------------------------------------------= -------=20 + + + Instaurare omnia in Christo + + + -------------------------------------------------------------------------= -------=20 The information contained in this message is confidential and may be = legally=20 privileged. This email is intended for the addressee(s). Addressees may = be=20 individual persons or members of mailing list.=20 If you are not an addressee, you are hereby notified that any use,=20 dissemination, or reproduction of this email and its optional = attachements is=20 strictly prohibited and may be unlawful. If you are not an addressee, = please=20 contact the sender by return e-mail and destroy all copies of the = original=20 message.=20 -------------------------------------------------------------------------= -------=20 ESF GmbH Fichtenweg 9 89143 Blaubeuren +49 (7344) 175340 (Direct line Dr. Fischer) +49 (7344) 919188 (Central office) +49 (7344) 919123 (Fax) https://fischer-tech.eu : Main web of ESF GmbH http://its-standards.eu : News on cooperative ITS standardization http://its-testing.org : International consultancy for cooperative ITS -------------------------------------------------------------------------= -------=20 =20 -------------------------------------------------------------------------= -------=20 ESF online-news: http://fischer-tech.eu/Feeds/esf.rss C-ITS online news: http://its-standards.info/Feeds/cits.rss ESF Online Nachrichten: http://fischer-tech.de/Feeds/esfD.rss -------------------------------------------------------------------------= ------ ------=_NextPart_000_00EC_01D3AEF3.967AEA00 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

AC_VO (voice) is only = a label indicating the highest priority; nothing more is = implied.

 

From: its [mailto:its-bounces@ietf.org] On = Behalf Of Dr. Hans-Joachim Fischer
Sent: Monday, February = 26, 2018 3:37 AM
To: Abdussalam Baryun = <abdussalambaryun@gmail.com>; Alexandre Petrescu = <alexandre.petrescu@gmail.com>
Cc: Tony Li = <tony1athome@gmail.com>; its = <its@ietf.org>
Subject: Re: [ipwave] 802.11 Data vs = 802.11 QoS Data in = IPv6-over-802.11-OCB

 

 

Be = careful with voice and audio transmission in ITS using 5,9 GHz. That = seems to be prohibited by regulation in Europe; well, not explicitly, = but this is a possible interpretation of the technical requirements = presented in regulatory documents. In Germany, it is = prohibited.

Hans-Joachim

 

Am = 26.02.2018 um 09:04 schrieb Abdussalam = Baryun:

The experience test you referred to is not = clarified, was it a ITS environment experience or was it a fixed = wireless experience. Furthermore, the WiFi technology ieee802.11 is = developed so which WiFi technology was used. Moreover, did your = experience use Video and voice communication or your proposal is = only for data communication only.

 

So if your IP packet are data then your experience is = right, but if the IP packet is carrying voice or video I don't agree. = IMO we could not exclude from the draft voice and video = communication in the ITS = environment/use-case. 

 

On Sun, = Feb 25, 2018 at 7:58 PM, Alexandre Petrescu <alexandre.petrescu@gmail.com> = wrote:



Le 23/02/2018 =C3=A0 18:38, Tony Li a = =C3=A9crit :

 

If we put = that CAM on IP there will still be lack of interoperability,
unless = we recommend IP to be carried by a particular 802.11 header (Data
or = QoS Data).



I = would propose that we use the Data header. My experience with the QoS = Data with Wi-Fi was that there wasn=E2=80=99t enough of a performance = difference with QoS for it to make a difference to the IP = layer.


I = agree.

I propose the following = text.

OLD:

  =  In OCB mode, IPv6 packets MAY be transmitted either as "IEEE = 802.11
   Data" or alternatively as "IEEE 802.11 = QoS Data", as illustrated in
   Figure = 2.


NEW:

  =  In OCB mode, it is RECOMMENDED to transmit IPv6 packets as = "IEEE
   802.11 Data" (the value of the field = Subtype in the Frame Control
   Field is = 0).


Alex

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

 




_______________________=
________________________
its mailing =
list
its@ietf.org
https://www.ietf.org/m=
ailman/listinfo/its



-- =

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

 
=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=A0ESF News =
edition 2018/1
https://=
fischer-tech.eu/Feeds/News/ESF-News-2018-01.pdf
=
 
---------------------------------------------=
----------------------------------- =

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Towards =
deployment of C-ITS based on proven =
technology
Avoid risks and delay by looking on =
potential future =
technologies.
 
=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 =
The real advocate on ITS is ISO =
TC204!
---------------------------------------------=
----------------------------------- 
+ + + =
Instaurare omnia in Christo + + =
+
--------------------------------------------------=
------------------------------ 
The information =
contained in this message is confidential and may be legally =

privileged. This email is intended for the =
addressee(s). Addressees may be 
individual persons =
or members of mailing list. 
If you are not an =
addressee, you are hereby notified that any use, =

dissemination, or reproduction of this email and =
its optional attachements is 
strictly prohibited =
and may be unlawful. If you are not an addressee, please =

contact the sender by return e-mail and destroy =
all copies of the original 
message. =

---------------------------------------------------=
----------------------------- 
ESF =
GmbH
Fichtenweg 9
89143 =
Blaubeuren
+49 (7344) 175340 (Direct line Dr. =
Fischer)
+49 (7344) 919188 (Central =
office)
+49 (7344) 919123 =
(Fax)
https://fischer-tech.eu :=C2=A0 =
Main web of ESF GmbH
http://its-standards.eu : News on =
cooperative ITS standardization
http://its-testing.org :=C2=A0 =
International consultancy for cooperative =
ITS
------------------------------------------------=
-------------------------------- =

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

ESF =
online-news:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://fischer-tech.eu/Feed=
s/esf.rss
C-ITS online =
news:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://its-standards.in=
fo/Feeds/cits.rss
ESF Online Nachrichten: http://fischer-tech.de/Fee=
ds/esfD.rss
------------------------------------=
-------------------------------------------
= ------=_NextPart_000_00EC_01D3AEF3.967AEA00-- From nobody Mon Feb 26 08:22:13 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8486D127078 for ; Mon, 26 Feb 2018 08:22:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 D2goYFwifQJD for ; Mon, 26 Feb 2018 08:22:09 -0800 (PST) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E60B120227 for ; Mon, 26 Feb 2018 08:22:09 -0800 (PST) Received: by mail-qt0-x229.google.com with SMTP id m13so14698600qtg.13 for ; Mon, 26 Feb 2018 08:22:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=82sVK7ugQ2KTNVjSTM9EBga1wRNU+6hO0rjPs9iMDqg=; b=vL4PoGFeTRy2Gdhtsh9zys3797YfsxYjjLa9QWpHTo+PetyR+AtUgkaSTf9F5tRHxz 2bcLyU+vY2HNBrTLAleB9uv0snOGw2wmtqxS7/wC+0D5ddiK1fFXEMLsnWgritpEU/IU Wo3RE3+jg2ngAOoEcrVsfz0Ab5btpP8Rl6J9Mw0iCouYN2vqTqZ+42tFECqdfeaD4D0G 5Oma0WvIkYUC6Z2Tjpk6olk0NKHFRXaWIaBDRqsP+x23+8YqLYd3PR1Yh4yV2OQ51pLc RSD9//g22UMrUu/iY+SePmrzgZvm3XXASdTptfwfUfMqXx75hyk6nyrc1Y7SptAFTMpl 2otA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=82sVK7ugQ2KTNVjSTM9EBga1wRNU+6hO0rjPs9iMDqg=; b=gyVYeTHVYNfYlSS/6PVHQ+Y5Rl2tzLSLe83K12YVyLm9q76+ekR6EYpJ6QY0UZGHy2 0L2O6V8gQsA/4Jl0DfSZKhyfZAZs5p1BRGkv8i+LV5Q3rFi64erAHAPi11jjprAcf7mf mXdiGL6RcdJShmnE4be5mqsPmW8coxYtijRYoM1W1552YcQFMgN+SK2e88kywRFhX9im lhwUBi0G42uTW7GmgCIX9LJnzhT6PR+DqPpCWDcdX0wg0yNw6piLi58O5Bl1PWjkmuUE rleRXk5/u6LyFDTHgTHt5JMsaUlH7WJtk1eRhIbcCH0Vi0BEhrM/4ya314lBo1usnU/d JGWg== X-Gm-Message-State: APf1xPDqe4ix7Wx59kry3wTXTsCPlJMnQguaLFed+i9TeiIIqre2w5PN OfY8WJwZCtKqNocNjg6Fnso= X-Google-Smtp-Source: AG47ELukNrsRocLZraEpxKTc8HA+sfJYbZ2hMxW0VTTbPP6Vj75A75p20a9o5bUTVchhx0cc7Vr6gA== X-Received: by 10.200.26.131 with SMTP id x3mr19075530qtj.288.1519662128461; Mon, 26 Feb 2018 08:22:08 -0800 (PST) Received: from FrancoisPC (pool-108-48-182-86.washdc.fios.verizon.net. [108.48.182.86]) by smtp.gmail.com with ESMTPSA id z127sm5105216qkb.1.2018.02.26.08.22.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Feb 2018 08:22:07 -0800 (PST) From: =?UTF-8?Q?Fran=C3=A7ois_Simon?= To: =?UTF-8?B?J0rDqXLDtG1lIEjDpHJyaSc=?= , "'Alexandre Petrescu'" , References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <006301d3ace3$25f9d500$71ed7f00$@eurecom.fr> <007901d3aee3$a9985ba0$fcc912e0$@eurecom.fr> In-Reply-To: <007901d3aee3$a9985ba0$fcc912e0$@eurecom.fr> Date: Mon, 26 Feb 2018 11:22:06 -0500 Message-ID: <00f801d3af1d$f20ce4c0$d626ae40$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHelLAw/aN7IRfcwiTBG/gKcgHVEwGONDnFAivYBTcBDgW0eQFK9evKAbex+qSjYrygwA== Content-Language: en-us Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 26 Feb 2018 16:22:12 -0000 Correct ! -----Original Message----- From: its [mailto:its-bounces@ietf.org] On Behalf Of J=C3=A9r=C3=B4me = H=C3=A4rri Sent: Monday, February 26, 2018 4:25 AM To: 'Alexandre Petrescu' ; its@ietf.org Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in = IPv6-over-802.11-OCB Hi Alex, > That is a requirement. > > But is there an implementation of mapping the priority of CAM over = DENM into a QoS Control field in QoS Data Header? > > I doubt there is, because the implementations of CAM I see put the = Priority field to 6, which means Voice. So they transmit CAM as Voice = even though it is not voice. > > We can not reckon in IPv6-over-OCB document something which makes = little sense (send CAM as Voice). Of course there is....the QoS fields actually means the Access = Categories (AC) for WLAN, so EDCA. Both in ETSI and in WAVE they use the = QoS Control filed of IEE 802.11p to send CAM/BSM with higher priority = (from a MAC perspective)...When looking at the EDCA 'naming' you should = not care much of the 'name'...this was done at the time internet was = only composed of voice, video etc..you should look at the underlying = values of each AC. So, EDCA is composed of two fields: 1) AIFN - a deterministic idle time before even considering reducing CW 2) CW - a random timer to decrease each time the channel is idle.=20 QoS Data combinations for OCB: AC_VO: AIFN=3D2, CW=3D8 AC_VI: AIFN=3D2, CW=3D16 AC_BE: AIFN=3D3, CW=3D32 AC_BK: AIFN=3D7, CW=3D32 So, it does not matter the name (Voice, video)..what matters is that in = implementation (BSM for instance), AIFN=3D2 so that it takes the fastest = access (deterministic) and as such has the highest priority. This is = also what you found: CAM on Priority field 6, so AC_VI so AIFN=3D2. BSM = uses the same strategy.=20 Now, on the CAR 2 CAR specification, it is recommended a different = priority: AC_BE, as it uses DP2. The reason behind this is the CAR2CAR = provides a 'strict' prioritization between DENMs and CAMs. Emergency = DENMs uses AC_VI, normal DENM uses AC_VO, CAM uses AC_BE and any other = traffic AC_BK. So, bottom line is: all ETSI and WAVE implementation use the QoS Data = field as they use EDCA. If you found an implementation that does not use = the QoS, it is wrong according to the standard. >> Now, as you abstract ETSI and WAVE (thus pure IP), my understanding=20 >> is that QoS remains required from the IEEE 802.11p (ok, IEEE >> 802.11-2016 OCB) as there is a specification of the EDCA parameters=20 >> for OCB. Besides, I do not think it costs much to keep the EDCA in,=20 >> as it first allows to safe a half of the MAC queueing time (the EDCA=20 >> parameters for the two low AC are less, up to a quarter of a=20 >> DIFS...so, it could be beneficial to allow this even for IP. Second,=20 >> the EDCA allows TXOpps (Transmit Opportunities)..although put to=20 >> 'zero' for OCB (I think), this mechanism still allows an AP to=20 >> reserve a given time a long(er) connectivity with one device (e. >> streaming of video etc..). Finally, it does not cost anything..you=20 >> can always take the lowest AC and you get the same behavior as = non-QoS.. >Well, this text is more informal in nature. It is something that >describes a potential behaviour but we have no proof of existing such = behaviour, no proof of interoperability. This could be part of an = INFORMATIONAL Internet Draft. Well, my text is informal, but the specs are not. IEEE 802.11p (IEEE = 802.11-2016 OCB) uses EDCA not DCF...as this is L2 layer, I do not think = anything is required from IETF...just follow the IEEE 802.11-2016 specs = and do whatever is allows above it...I will double check again on the = IEEE 802.11-2016, but if what I think is confirmed, the whole discussion = does not make any sense..., as it is my understanding that the OCB = requires EDCA, so QoS_Data...so, you cannot change that at IP level. >> Bottom line, the fact that some IP implementation to decode OCB=20 >> assume non-QoS frames looks more to me like an implementation error=20 >> and we should not propagate this... >Well, wireshark has problems interpreting 802.11 QoS Data containing = CAM messages. Many receivers of QoS Data dont know what to do with the = fields because they are not agreed. Yes, and this is why is the prototype we use, we actually have an parser = for CAM to be supported by Wireshark...it does not come by default. But = I am surprised..what kind of problem would wireshark face with the QoS = Data?=20 > I don't want to propagate that disagreement into the IP-over-OCB = draft. To me, this looks more like an implementation issue, rather than a = standard issue...but I will ask my team to check on our prototype... >> C-V2X will not use IP for CAM, >LTE-V2X will carry CAM in IP. What is C-V2X and why does not it use = IP? Sorry, it will not. In C-V2X (the widely known name...LTE-V2X is again a = bit like 802.11p...'LTE Prose for V2X' is the real name...), mode 4 = (ad-hoc mode..currently chosen by all vendors (except maybe Huawei, but = might have changed), there is two options for protocol stack: IPv6 = (again, only IPv6) and non-IP (L2)...you can use non-IP packets and it = is so mentioned that BSM and CAM will use the non-IP option, as it is = also required to use the ETSI/WAVE security provisions to secure the = C-V2X mode 4 (as no SIM=3D no security), as the ETSI/WAVE security = provisions works for non-IP packets (geonet or WSM)... Of course, it does not block from using IP...it is again the same = discussion we had with ITS-G5/DSRC...for safety communication, IP is not = required...you can do everything without and faster. And considering = that IEEE 802.11p (ok, OCB) and C-V2X mode 4 (no SIM=3Dno SEC) DO NOT = have any form of security mechanism embedded, they must use the those = specified by ETSI/WAVE for accessing CCH. Again, C-V2X mode 4 (the current V2X techno for Safety-critical = communication) shall not be seen as following the same path as other = cellular techno. It does not provide QoS (at all), as it channel access = is contention-based (a bit like CSMA)...so collisions will occur (unlike = 4G and 5G operated, where you are either dropped or you pass). And as = such, IP is also not required, even if all 4G and 5G use IP. >> ETSI and WAVE will not use IP for CAM... >That is their problem. Disagree: you need to be compatible with them...so, whatever IETF will = do shall not break anything that has been done on ETSI or WAVE. This is = one of the requirement for accessing the ITS-G5 spectrum in EU, and I = believe the same in the US. >ETSI transports IP over GeoNetworking - that is not the right way to do = it. Disagree: we need to integrate security mechanisms specified by ETSI = even if we use IPv6. Today, we do not have any security specification = providing 'trust', privacy and authentication for using 802.11-OCB (I = believe it is the work of IPWAVE and it is not completed yet...).=20 The mistake ETSI did is to try to be nice with IETF and help them to = provide a way to use IPv6 over ITS-G5 in a secured way...WAVE took a = different path: 'not my problem', which then explain why ETSI officially = does not endorse IPWAVE (unfortunately, despite my many discussions with = them)...from an ETSI perspective, using IPv6 over ITS-G5 is = solved...(might be ugly, but it is solved). =20 >> the basic CAMs are used for pure positioning >The mandatory fields in CAM or more than just lat/long/altitude. There = is also mandatory time in a strange format, car dimensions, curve, non = standard precisions and more. Yes, correct...but these are configurable fields, which may or may not = be integrated...recent studies even showed that even the standard CAM = size is not clear anymore..you have a 'range' of size, and that is a = problem for wireless optimization...especially if you need to do = wireless congestion control. >> and the recent 'increase' of information put in CAM >If CAM worries about size, I think CAM should think about its existing = redundancy. For example, position is carried twice in a CAM message: in = the CAM itself and in the GeoNetworking header. That >is an issue they = should address first. Well, of course, this is a waste...but one reason for such existence is = from the possibility to relay a packet (agnostic from the upper = messages, unfortunately, we cannot use a Zero-NET for CAM as it is pure = 1-hop TSB)... Yet, today we start seeing even BSM investigating ways to do multi-hop = 'position' based relaying to reach longer distance.=20 And if you think about it, one day, your IPv6-over-OCB might need to use = a multi-hop networking protocol (e.g. MANET)..but doing the MANET way is = highly mobile environment will not be that efficient...position-based = mechanisms will be required (proven in various previous studies)...now, = your L3 will not be able to inspect the GPS position of your = CAM-over-IP...so, you will need to have GPS (or so) position at IP/L3, = which will end up being similar than now... If you do not want to do this, then the IRTF people might come with ICN, = but then would this be done above L3 or at L3...if still at L3, you = still will have a contextual L3 packet that might be redundant with = application/service layer messages...(the cost of using OSI) But this is just my personal view and very long term...for now, if we = only look at CAM, indeed we can have twice the GPS position (but wait: = not the same granularity and you do not have elevation in geonet). But = if you look at the bigger picture: doing CAM-over-geonet only required = a single CAM, that's it. For IPv6-over-OCB, you need all the IPv6 = address autoconfiguration..that requires additional IPv6 packets to be = transmitted...this is similar to compare an apple with a tomato. =20 >> looks to be like a bad strategy as we end up having a container=20 >> carrying too many things and being too big for what it is... >I agree. But I think we should compare header sizes and then there = will be surprises. >CAM transported in IP may be a smaller packet than CAM transported in = BTP and GeoNetworking. Not that much if you counts also all IPv6-related control/management = packets required to transmit your CAM-over-OCB, in a highly dynamic = environment... > (WLAN is good at squeezing various small packets but really not good=20 > at big things especially in broadcast mode)...a better strategy would=20 > be to define new messages tailored to the information needs, and have=20 > smart service scheduling...(especially benefiting from IP-related > mechanisms) > I fully agree with this. :-) at least we do on this :-) Cheers, J=C3=A9r=C3=B4me _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its From nobody Mon Feb 26 08:22:52 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E759127286 for ; Mon, 26 Feb 2018 08:22:51 -0800 (PST) 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 D_FaakpsbVRY for ; Mon, 26 Feb 2018 08:22:44 -0800 (PST) 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 42CD4127078 for ; Mon, 26 Feb 2018 08:22:44 -0800 (PST) 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 w1QGMflR015757; Mon, 26 Feb 2018 17:22:41 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A27A020541C; Mon, 26 Feb 2018 17:22:41 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 8E32C201DD9; Mon, 26 Feb 2018 17:22:41 +0100 (CET) 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 w1QGMfQu021418; Mon, 26 Feb 2018 17:22:41 +0100 To: =?UTF-8?Q?Fran=c3=a7ois_Simon?= , "'Dr. Hans-Joachim Fischer'" , "'Abdussalam Baryun'" Cc: "'Tony Li'" , "'its'" References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <9ada5591-2af3-272d-3bc3-031bf35454c3@gmail.com> <6cdc0835-fb4c-133b-77ff-0234cfdd9ef9@fischer-tech.eu> <00eb01d3af1d$7f4e8100$7deb8300$@gmail.com> From: Alexandre Petrescu Message-ID: <6187cb92-5c8f-d08b-dcc2-859652d629d0@gmail.com> Date: Mon, 26 Feb 2018 17:22:41 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <00eb01d3af1d$7f4e8100$7deb8300$@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 26 Feb 2018 16:22:51 -0000 Le 26/02/2018 à 17:18, François Simon a écrit : > AC_VO (voice) is only a label indicating the highest priority; nothing > more is implied. YEs, sure, but imagine someone sends real voice; that will compete with CAM 'voice' - we dont want that either :-) In such situation, what one would like in standards is to see 'highest priority' instead of 'voice'. Alex > > *From:*its [mailto:its-bounces@ietf.org] *On Behalf Of *Dr. Hans-Joachim > Fischer > *Sent:* Monday, February 26, 2018 3:37 AM > *To:* Abdussalam Baryun ; Alexandre Petrescu > > *Cc:* Tony Li ; its > *Subject:* Re: [ipwave] 802.11 Data vs 802.11 QoS Data in > IPv6-over-802.11-OCB > > Be careful with voice and audio transmission in ITS using 5,9 GHz. That > seems to be prohibited by regulation in Europe; well, not explicitly, > but this is a possible interpretation of the technical requirements > presented in regulatory documents. In Germany, it is prohibited. > > Hans-Joachim > > Am 26.02.2018 um 09:04 schrieb Abdussalam Baryun: > > The experience test you referred to is not clarified, was it a ITS > environment experience or was it a fixed wireless experience. > Furthermore, the WiFi technology ieee802.11 is developed so which > WiFi technology was used. Moreover, did your experience use Video > and voice communication or your proposal is only for data > communication only. > > So if your IP packet are data then your experience is right, but if > the IP packet is carrying voice or video I don't agree. IMO we could > not exclude from the draft voice and video communication in the ITS > environment/use-case. > > On Sun, Feb 25, 2018 at 7:58 PM, Alexandre Petrescu > > > wrote: > > > > Le 23/02/2018 à 18:38, Tony Li a écrit : > > If we put that CAM on IP there will still be lack of > interoperability, > unless we recommend IP to be carried by a particular > 802.11 header (Data > or QoS Data). > > > > I would propose that we use the Data header. My experience > with the QoS Data with Wi-Fi was that there wasn’t enough of > a performance difference with QoS for it to make a > difference to the IP layer. > > > I agree. > > I propose the following text. > > OLD: > >    In OCB mode, IPv6 packets MAY be transmitted either as > "IEEE 802.11 >    Data" or alternatively as "IEEE 802.11 QoS Data", as > illustrated in >    Figure 2. > > > NEW: > >    In OCB mode, it is RECOMMENDED to transmit IPv6 packets > as "IEEE >    802.11 Data" (the value of the field Subtype in the > Frame Control >    Field is 0). > > > 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 > > > > -- > > Dr. Hans-Joachim Fischer > > Managing Director > > -------------------------------------------------------------------------------- > >                ESF News edition 2018/1 > > https://fischer-tech.eu/Feeds/News/ESF-News-2018-01.pdf > > -------------------------------------------------------------------------------- > >       Towards deployment of C-ITS based on proven technology > > Avoid risks and delay by looking on potential future technologies. > >                The real advocate on ITS is ISO TC204! > > -------------------------------------------------------------------------------- > > + + + Instaurare omnia in Christo + + + > > -------------------------------------------------------------------------------- > > The information contained in this message is confidential and may be legally > > privileged. This email is intended for the addressee(s). Addressees may be > > individual persons or members of mailing list. > > If you are not an addressee, you are hereby notified that any use, > > dissemination, or reproduction of this email and its optional attachements is > > strictly prohibited and may be unlawful. If you are not an addressee, please > > contact the sender by return e-mail and destroy all copies of the original > > message. > > -------------------------------------------------------------------------------- > > ESF GmbH > > Fichtenweg 9 > > 89143 Blaubeuren > > +49 (7344) 175340 (Direct line Dr. Fischer) > > +49 (7344) 919188 (Central office) > > +49 (7344) 919123 (Fax) > > https://fischer-tech.eu :  Main web of ESF GmbH > > http://its-standards.eu : News on cooperative ITS standardization > > http://its-testing.org :  International consultancy for cooperative ITS > > -------------------------------------------------------------------------------- > > -------------------------------------------------------------------------------- > > ESF online-news:http://fischer-tech.eu/Feeds/esf.rss > > C-ITS online news:http://its-standards.info/Feeds/cits.rss > > ESF Online Nachrichten:http://fischer-tech.de/Feeds/esfD.rss > > ------------------------------------------------------------------------------- > From nobody Mon Feb 26 08:41:05 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9876126CC4 for ; Mon, 26 Feb 2018 08:41:03 -0800 (PST) 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 SKi1-fRP7LeF for ; Mon, 26 Feb 2018 08:41:00 -0800 (PST) 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 E46FB124BFA for ; Mon, 26 Feb 2018 08:40:58 -0800 (PST) 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 w1QGeuTn036003; Mon, 26 Feb 2018 17:40:56 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 085A82054B0; Mon, 26 Feb 2018 17:40:56 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id EC1312012A6; Mon, 26 Feb 2018 17:40:55 +0100 (CET) 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 w1QGerxa009692; Mon, 26 Feb 2018 17:40:54 +0100 To: =?UTF-8?Q?Fran=c3=a7ois_Simon?= , =?UTF-8?B?J0rDqXLDtG1lIEjDpHJyaSc=?= , its@ietf.org References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <006301d3ace3$25f9d500$71ed7f00$@eurecom.fr> <007901d3aee3$a9985ba0$fcc912e0$@eurecom.fr> <00f801d3af1d$f20ce4c0$d626ae40$@gmail.com> From: Alexandre Petrescu Message-ID: Date: Mon, 26 Feb 2018 17:40:53 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <00f801d3af1d$f20ce4c0$d626ae40$@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 26 Feb 2018 16:41:04 -0000 Le 26/02/2018 à 17:22, François Simon a écrit : > Correct ! Is there a mapping between the Access Categories and IPv6 Traffic Class fields? RFC8200: > 3. IPv6 Header Format > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Version| Traffic Class | Flow Label | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Payload Length | Next Header | Hop Limit | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | | > + Source Address + > | | > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | | > + Destination Address + > | | > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Version 4-bit Internet Protocol version number = 6. > > Traffic Class 8-bit Traffic Class field. See Section 7. > > Flow Label 20-bit flow label. See Section 6. Alex > > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Jérôme Härri > Sent: Monday, February 26, 2018 4:25 AM > To: 'Alexandre Petrescu' ; its@ietf.org > Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB > > Hi Alex, > >> That is a requirement. >> >> But is there an implementation of mapping the priority of CAM over DENM into a QoS Control field in QoS Data Header? >> >> I doubt there is, because the implementations of CAM I see put the Priority field to 6, which means Voice. So they transmit CAM as Voice even though it is not voice. >> >> We can not reckon in IPv6-over-OCB document something which makes little sense (send CAM as Voice). > > Of course there is....the QoS fields actually means the Access Categories (AC) for WLAN, so EDCA. Both in ETSI and in WAVE they use the QoS Control filed of IEE 802.11p to send CAM/BSM with higher priority (from a MAC perspective)...When looking at the EDCA 'naming' you should not care much of the 'name'...this was done at the time internet was only composed of voice, video etc..you should look at the underlying values of each AC. > > So, EDCA is composed of two fields: > 1) AIFN - a deterministic idle time before even considering reducing CW > 2) CW - a random timer to decrease each time the channel is idle. > > QoS Data combinations for OCB: > AC_VO: AIFN=2, CW=8 > AC_VI: AIFN=2, CW=16 > AC_BE: AIFN=3, CW=32 > AC_BK: AIFN=7, CW=32 > > So, it does not matter the name (Voice, video)..what matters is that in implementation (BSM for instance), AIFN=2 so that it takes the fastest access (deterministic) and as such has the highest priority. This is also what you found: CAM on Priority field 6, so AC_VI so AIFN=2. BSM uses the same strategy. > > Now, on the CAR 2 CAR specification, it is recommended a different priority: AC_BE, as it uses DP2. The reason behind this is the CAR2CAR provides a 'strict' prioritization between DENMs and CAMs. Emergency DENMs uses AC_VI, normal DENM uses AC_VO, CAM uses AC_BE and any other traffic AC_BK. > > So, bottom line is: all ETSI and WAVE implementation use the QoS Data field as they use EDCA. If you found an implementation that does not use the QoS, it is wrong according to the standard. > >>> Now, as you abstract ETSI and WAVE (thus pure IP), my understanding >>> is that QoS remains required from the IEEE 802.11p (ok, IEEE >>> 802.11-2016 OCB) as there is a specification of the EDCA parameters >>> for OCB. Besides, I do not think it costs much to keep the EDCA in, >>> as it first allows to safe a half of the MAC queueing time (the EDCA >>> parameters for the two low AC are less, up to a quarter of a >>> DIFS...so, it could be beneficial to allow this even for IP. Second, >>> the EDCA allows TXOpps (Transmit Opportunities)..although put to >>> 'zero' for OCB (I think), this mechanism still allows an AP to >>> reserve a given time a long(er) connectivity with one device (e. >>> streaming of video etc..). Finally, it does not cost anything..you >>> can always take the lowest AC and you get the same behavior as non-QoS.. > >> Well, this text is more informal in nature. It is something that >> describes a potential behaviour but we have no proof of existing such behaviour, no proof of interoperability. This could be part of an INFORMATIONAL Internet Draft. > > Well, my text is informal, but the specs are not. IEEE 802.11p (IEEE 802.11-2016 OCB) uses EDCA not DCF...as this is L2 layer, I do not think anything is required from IETF...just follow the IEEE 802.11-2016 specs and do whatever is allows above it...I will double check again on the IEEE 802.11-2016, but if what I think is confirmed, the whole discussion does not make any sense..., as it is my understanding that the OCB requires EDCA, so QoS_Data...so, you cannot change that at IP level. > > >>> Bottom line, the fact that some IP implementation to decode OCB >>> assume non-QoS frames looks more to me like an implementation error >>> and we should not propagate this... > >> Well, wireshark has problems interpreting 802.11 QoS Data containing CAM messages. Many receivers of QoS Data dont know what to do with the fields because they are not agreed. > > Yes, and this is why is the prototype we use, we actually have an parser for CAM to be supported by Wireshark...it does not come by default. But I am surprised..what kind of problem would wireshark face with the QoS Data? > > >> I don't want to propagate that disagreement into the IP-over-OCB draft. > > To me, this looks more like an implementation issue, rather than a standard issue...but I will ask my team to check on our prototype... > >>> C-V2X will not use IP for CAM, > >> LTE-V2X will carry CAM in IP. What is C-V2X and why does not it use IP? > > Sorry, it will not. In C-V2X (the widely known name...LTE-V2X is again a bit like 802.11p...'LTE Prose for V2X' is the real name...), mode 4 (ad-hoc mode..currently chosen by all vendors (except maybe Huawei, but might have changed), there is two options for protocol stack: IPv6 (again, only IPv6) and non-IP (L2)...you can use non-IP packets and it is so mentioned that BSM and CAM will use the non-IP option, as it is also required to use the ETSI/WAVE security provisions to secure the C-V2X mode 4 (as no SIM= no security), as the ETSI/WAVE security provisions works for non-IP packets (geonet or WSM)... > > Of course, it does not block from using IP...it is again the same discussion we had with ITS-G5/DSRC...for safety communication, IP is not required...you can do everything without and faster. And considering that IEEE 802.11p (ok, OCB) and C-V2X mode 4 (no SIM=no SEC) DO NOT have any form of security mechanism embedded, they must use the those specified by ETSI/WAVE for accessing CCH. > > Again, C-V2X mode 4 (the current V2X techno for Safety-critical communication) shall not be seen as following the same path as other cellular techno. It does not provide QoS (at all), as it channel access is contention-based (a bit like CSMA)...so collisions will occur (unlike 4G and 5G operated, where you are either dropped or you pass). And as such, IP is also not required, even if all 4G and 5G use IP. > > >>> ETSI and WAVE will not use IP for CAM... > >> That is their problem. > > Disagree: you need to be compatible with them...so, whatever IETF will do shall not break anything that has been done on ETSI or WAVE. This is one of the requirement for accessing the ITS-G5 spectrum in EU, and I believe the same in the US. > >> ETSI transports IP over GeoNetworking - that is not the right way to do it. > > Disagree: we need to integrate security mechanisms specified by ETSI even if we use IPv6. Today, we do not have any security specification providing 'trust', privacy and authentication for using 802.11-OCB (I believe it is the work of IPWAVE and it is not completed yet...). > The mistake ETSI did is to try to be nice with IETF and help them to provide a way to use IPv6 over ITS-G5 in a secured way...WAVE took a different path: 'not my problem', which then explain why ETSI officially does not endorse IPWAVE (unfortunately, despite my many discussions with them)...from an ETSI perspective, using IPv6 over ITS-G5 is solved...(might be ugly, but it is solved). > >>> the basic CAMs are used for pure positioning > >> The mandatory fields in CAM or more than just lat/long/altitude. There is also mandatory time in a strange format, car dimensions, curve, non standard precisions and more. > > Yes, correct...but these are configurable fields, which may or may not be integrated...recent studies even showed that even the standard CAM size is not clear anymore..you have a 'range' of size, and that is a problem for wireless optimization...especially if you need to do wireless congestion control. > >>> and the recent 'increase' of information put in CAM > >> If CAM worries about size, I think CAM should think about its existing redundancy. For example, position is carried twice in a CAM message: in the CAM itself and in the GeoNetworking header. That >is an issue they should address first. > > Well, of course, this is a waste...but one reason for such existence is from the possibility to relay a packet (agnostic from the upper messages, unfortunately, we cannot use a Zero-NET for CAM as it is pure 1-hop TSB)... > Yet, today we start seeing even BSM investigating ways to do multi-hop 'position' based relaying to reach longer distance. > > And if you think about it, one day, your IPv6-over-OCB might need to use a multi-hop networking protocol (e.g. MANET)..but doing the MANET way is highly mobile environment will not be that efficient...position-based mechanisms will be required (proven in various previous studies)...now, your L3 will not be able to inspect the GPS position of your CAM-over-IP...so, you will need to have GPS (or so) position at IP/L3, which will end up being similar than now... > > If you do not want to do this, then the IRTF people might come with ICN, but then would this be done above L3 or at L3...if still at L3, you still will have a contextual L3 packet that might be redundant with application/service layer messages...(the cost of using OSI) > > But this is just my personal view and very long term...for now, if we only look at CAM, indeed we can have twice the GPS position (but wait: not the same granularity and you do not have elevation in geonet). But if you look at the bigger picture: doing CAM-over-geonet only required a single CAM, that's it. For IPv6-over-OCB, you need all the IPv6 address autoconfiguration..that requires additional IPv6 packets to be transmitted...this is similar to compare an apple with a tomato. > >>> looks to be like a bad strategy as we end up having a container >>> carrying too many things and being too big for what it is... > >> I agree. But I think we should compare header sizes and then there will be surprises. >> CAM transported in IP may be a smaller packet than CAM transported in BTP and GeoNetworking. > > Not that much if you counts also all IPv6-related control/management packets required to transmit your CAM-over-OCB, in a highly dynamic environment... > >> (WLAN is good at squeezing various small packets but really not good >> at big things especially in broadcast mode)...a better strategy would >> be to define new messages tailored to the information needs, and have >> smart service scheduling...(especially benefiting from IP-related >> mechanisms) > >> I fully agree with this. > > :-) at least we do on this :-) > > Cheers, > > Jérôme > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > From nobody Mon Feb 26 08:42:06 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3488E12D870 for ; Mon, 26 Feb 2018 08:42:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vpa42MHtetNN for ; Mon, 26 Feb 2018 08:42:02 -0800 (PST) Received: from smtp2.eurecom.fr (smtp2.eurecom.fr [193.55.113.211]) by ietfa.amsl.com (Postfix) with ESMTP id 32DD3126CC4 for ; Mon, 26 Feb 2018 08:42:02 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.47,397,1515452400"; d="scan'208";a="7702271" Received: from monza.eurecom.fr ([192.168.106.15]) by drago2i.eurecom.fr with ESMTP; 26 Feb 2018 17:42:01 +0100 Received: from xerus29 (unknown [192.168.200.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by monza.eurecom.fr (Postfix) with ESMTPSA id 900C91957; Mon, 26 Feb 2018 17:42:00 +0100 (CET) From: =?utf-8?B?SsOpcsO0bWUgSMOkcnJp?= To: "'Alexandre Petrescu'" , =?utf-8?Q?'Fran=C3=A7ois_Simon'?= , "'Dr. Hans-Joachim Fischer'" , "'Abdussalam Baryun'" Cc: "'Tony Li'" , "'its'" References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <9ada5591-2af3-272d-3bc3-031bf35454c3@gmail.com> <6cdc0835-fb4c-133b-77ff-0234cfdd9ef9@fischer-tech.eu> <00eb01d3af1d$7f4e8100$7deb8300$@gmail.com> <6187cb92-5c8f-d08b-dcc2-859652d629d0@gmail.com> In-Reply-To: <6187cb92-5c8f-d08b-dcc2-859652d629d0@gmail.com> Date: Mon, 26 Feb 2018 17:41:59 +0100 Organization: EURECOM Message-ID: <002901d3af20$b966e960$2c34bc20$@eurecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHelLAw/aN7IRfcwiTBG/gKcgHVEwGONDnFAivYBTcB5QRVgwFu9SHuAdIGJvACSXL3QAKWMu63Adu1s1+jJDgI0A== Content-Language: en-us Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 26 Feb 2018 16:42:05 -0000 Hi Alex, Well, from the IP layer, what you see is a 7 bit User Priority, nothing = else..feel free to label the 7 UP as you want....how it is translated is = L2 business (and naming..)..so we should not care much about the names. Now, you raised an issue (that was also identified by other OCB people = reading the thread..and will probably also provide feedback soon) is the = coexistence between traffic. CAM uses AC_BE in ETSI, DENM uses AC_VI and AC_VO in ETSI. Event-based = BSM uses AC_VI and non-even-based BSM uses AC_BE (I think)...so, if you = send IPv6 traffic with DCF (where DIFS =3D 2, same as AC_VI), then you = will compete directly with DENM and event-based BSM, which is * very* = problematic...thus my suggestion to keep QoSData so that we at least = have an option to avoid interfering with CAM/DENM. Now, if you want to transmit CAM with IPv6-over-OCB, then you 'clearly' = needs QoSData so that the pure IP CAM/BSN and ETSI/WAVE CAM/BSM have the = same L2 'priority' in accessing the channel, otherwise you risk creating = harmful interference and packet collisions. BR, J=C3=A9r=C3=B4me=20 -----Original Message----- From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu Sent: Monday 26 February 2018 17:23 To: Fran=C3=A7ois Simon; 'Dr. Hans-Joachim Fischer'; 'Abdussalam Baryun' Cc: 'Tony Li'; 'its' Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in = IPv6-over-802.11-OCB Le 26/02/2018 =C3=A0 17:18, Fran=C3=A7ois Simon a =C3=A9crit : > AC_VO (voice) is only a label indicating the highest priority; nothing = > more is implied. YEs, sure, but imagine someone sends real voice; that will compete with = CAM 'voice' - we dont want that either :-) In such situation, what one would like in standards is to see 'highest = priority' instead of 'voice'. Alex >=20 > *From:*its [mailto:its-bounces@ietf.org] *On Behalf Of *Dr.=20 > Hans-Joachim Fischer > *Sent:* Monday, February 26, 2018 3:37 AM > *To:* Abdussalam Baryun ; Alexandre=20 > Petrescu > *Cc:* Tony Li ; its > *Subject:* Re: [ipwave] 802.11 Data vs 802.11 QoS Data in=20 > IPv6-over-802.11-OCB >=20 > Be careful with voice and audio transmission in ITS using 5,9 GHz.=20 > That seems to be prohibited by regulation in Europe; well, not=20 > explicitly, but this is a possible interpretation of the technical=20 > requirements presented in regulatory documents. In Germany, it is = prohibited. >=20 > Hans-Joachim >=20 > Am 26.02.2018 um 09:04 schrieb Abdussalam Baryun: >=20 > The experience test you referred to is not clarified, was it a ITS > environment experience or was it a fixed wireless experience. > Furthermore, the WiFi technology ieee802.11 is developed so which > WiFi technology was used. Moreover, did your experience use Video > and voice communication or your proposal is only for data > communication only. >=20 > So if your IP packet are data then your experience is right, but = if > the IP packet is carrying voice or video I don't agree. IMO we = could > not exclude from the draft voice and video communication in the = ITS > environment/use-case. >=20 > On Sun, Feb 25, 2018 at 7:58 PM, Alexandre Petrescu > > > wrote: >=20 >=20 >=20 > Le 23/02/2018 =C3=A0 18:38, Tony Li a =C3=A9crit : >=20 > If we put that CAM on IP there will still be lack of > interoperability, > unless we recommend IP to be carried by a particular > 802.11 header (Data > or QoS Data). >=20 >=20 >=20 > I would propose that we use the Data header. My experience > with the QoS Data with Wi-Fi was that there wasn=E2=80=99t = enough of > a performance difference with QoS for it to make a > difference to the IP layer. >=20 >=20 > I agree. >=20 > I propose the following text. >=20 > OLD: >=20 > In OCB mode, IPv6 packets MAY be transmitted either as > "IEEE 802.11 > Data" or alternatively as "IEEE 802.11 QoS Data", as > illustrated in > Figure 2. >=20 >=20 > NEW: >=20 > In OCB mode, it is RECOMMENDED to transmit IPv6 = packets > as "IEEE > 802.11 Data" (the value of the field Subtype in the > Frame Control > Field is 0). >=20 >=20 > Alex >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its >=20 >=20 >=20 >=20 > _______________________________________________ >=20 > its mailing list >=20 > its@ietf.org >=20 > https://www.ietf.org/mailman/listinfo/its >=20 >=20 >=20 > -- >=20 > Dr. Hans-Joachim Fischer >=20 > Managing Director >=20 > ---------------------------------------------------------------------- > ---------- >=20 > ESF News edition 2018/1 >=20 > https://fischer-tech.eu/Feeds/News/ESF-News-2018-01.pdf >=20 > ---------------------------------------------------------------------- > ---------- >=20 > Towards deployment of C-ITS based on proven technology >=20 > Avoid risks and delay by looking on potential future technologies. >=20 > The real advocate on ITS is ISO TC204! >=20 > ---------------------------------------------------------------------- > ---------- >=20 > + + + Instaurare omnia in Christo + + + >=20 > ---------------------------------------------------------------------- > ---------- >=20 > The information contained in this message is confidential and may be=20 > legally >=20 > privileged. This email is intended for the addressee(s). Addressees=20 > may be >=20 > individual persons or members of mailing list. >=20 > If you are not an addressee, you are hereby notified that any use, >=20 > dissemination, or reproduction of this email and its optional=20 > attachements is >=20 > strictly prohibited and may be unlawful. If you are not an addressee,=20 > please >=20 > contact the sender by return e-mail and destroy all copies of the=20 > original >=20 > message. >=20 > ---------------------------------------------------------------------- > ---------- >=20 > ESF GmbH >=20 > Fichtenweg 9 >=20 > 89143 Blaubeuren >=20 > +49 (7344) 175340 (Direct line Dr. Fischer) >=20 > +49 (7344) 919188 (Central office) >=20 > +49 (7344) 919123 (Fax) >=20 > https://fischer-tech.eu : Main web of ESF GmbH >=20 > http://its-standards.eu : News on cooperative ITS standardization >=20 > http://its-testing.org : International consultancy for cooperative=20 > ITS >=20 > ---------------------------------------------------------------------- > ---------- >=20 > ---------------------------------------------------------------------- > ---------- >=20 > ESF online-news:http://fischer-tech.eu/Feeds/esf.rss >=20 > C-ITS online news:http://its-standards.info/Feeds/cits.rss >=20 > ESF Online Nachrichten:http://fischer-tech.de/Feeds/esfD.rss >=20 > ---------------------------------------------------------------------- > --------- >=20 _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its From nobody Mon Feb 26 08:47:09 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40C8B124319 for ; Mon, 26 Feb 2018 08:47:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1kq77OfOT5E for ; Mon, 26 Feb 2018 08:47:06 -0800 (PST) Received: from smtp2.eurecom.fr (smtp2.eurecom.fr [193.55.113.211]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA93120227 for ; Mon, 26 Feb 2018 08:47:05 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.47,397,1515452400"; d="scan'208";a="7702283" Received: from monza.eurecom.fr ([192.168.106.15]) by drago2i.eurecom.fr with ESMTP; 26 Feb 2018 17:47:04 +0100 Received: from xerus29 (unknown [192.168.200.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by monza.eurecom.fr (Postfix) with ESMTPSA id 79B111984; Mon, 26 Feb 2018 17:47:04 +0100 (CET) From: =?utf-8?B?SsOpcsO0bWUgSMOkcnJp?= To: "'Alexandre Petrescu'" , =?utf-8?Q?'Fran=C3=A7ois_Simon'?= , References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <006301d3ace3$25f9d500$71ed7f00$@eurecom.fr> <007901d3aee3$a9985ba0$fcc912e0$@eurecom.fr> <00f801d3af1d$f20ce4c0$d626ae40$@gmail.com> In-Reply-To: Date: Mon, 26 Feb 2018 17:47:03 +0100 Organization: EURECOM Message-ID: <002b01d3af21$6e779a70$4b66cf50$@eurecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHelLAw/aN7IRfcwiTBG/gKcgHVEwGONDnFAivYBTcBDgW0eQFK9evKAbex+qQCF4nJkAMphqaUozi6WpA= Content-Language: en-us Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 26 Feb 2018 16:47:08 -0000 Hi Alex, All, Made a minor mistake: the 802.1D UP are actually 8 values, 0-7. So 8 = bits, and accordingly you can directly map the IPv6 TC to the UP...there = is a spec in ETSI for that, but not sure if there is one spec in IETF = for that..(did not have time to read Roland's identified RFC yet...maybe = it is there...) BR, J=C3=A9r=C3=B4me -----Original Message----- From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com]=20 Sent: Monday 26 February 2018 17:41 To: Fran=C3=A7ois Simon; 'J=C3=A9r=C3=B4me H=C3=A4rri'; its@ietf.org Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in = IPv6-over-802.11-OCB Le 26/02/2018 =C3=A0 17:22, Fran=C3=A7ois Simon a =C3=A9crit : > Correct ! Is there a mapping between the Access Categories and IPv6 Traffic Class = fields? RFC8200: > 3. IPv6 Header Format >=20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Version| Traffic Class | Flow Label | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Payload Length | Next Header | Hop Limit | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | | > + Source Address + > | | > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | | > + Destination Address + > | | > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Version 4-bit Internet Protocol version number =3D = 6. >=20 > Traffic Class 8-bit Traffic Class field. See Section 7. >=20 > Flow Label 20-bit flow label. See Section 6. Alex >=20 > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of J=C3=A9r=C3=B4me = H=C3=A4rri > Sent: Monday, February 26, 2018 4:25 AM > To: 'Alexandre Petrescu' ; its@ietf.org > Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in=20 > IPv6-over-802.11-OCB >=20 > Hi Alex, >=20 >> That is a requirement. >> >> But is there an implementation of mapping the priority of CAM over = DENM into a QoS Control field in QoS Data Header? >> >> I doubt there is, because the implementations of CAM I see put the = Priority field to 6, which means Voice. So they transmit CAM as Voice = even though it is not voice. >> >> We can not reckon in IPv6-over-OCB document something which makes = little sense (send CAM as Voice). >=20 > Of course there is....the QoS fields actually means the Access = Categories (AC) for WLAN, so EDCA. Both in ETSI and in WAVE they use the = QoS Control filed of IEE 802.11p to send CAM/BSM with higher priority = (from a MAC perspective)...When looking at the EDCA 'naming' you should = not care much of the 'name'...this was done at the time internet was = only composed of voice, video etc..you should look at the underlying = values of each AC. >=20 > So, EDCA is composed of two fields: > 1) AIFN - a deterministic idle time before even considering reducing=20 > CW > 2) CW - a random timer to decrease each time the channel is idle. >=20 > QoS Data combinations for OCB: > AC_VO: AIFN=3D2, CW=3D8 > AC_VI: AIFN=3D2, CW=3D16 > AC_BE: AIFN=3D3, CW=3D32 > AC_BK: AIFN=3D7, CW=3D32 >=20 > So, it does not matter the name (Voice, video)..what matters is that = in implementation (BSM for instance), AIFN=3D2 so that it takes the = fastest access (deterministic) and as such has the highest priority. = This is also what you found: CAM on Priority field 6, so AC_VI so = AIFN=3D2. BSM uses the same strategy. >=20 > Now, on the CAR 2 CAR specification, it is recommended a different = priority: AC_BE, as it uses DP2. The reason behind this is the CAR2CAR = provides a 'strict' prioritization between DENMs and CAMs. Emergency = DENMs uses AC_VI, normal DENM uses AC_VO, CAM uses AC_BE and any other = traffic AC_BK. >=20 > So, bottom line is: all ETSI and WAVE implementation use the QoS Data = field as they use EDCA. If you found an implementation that does not use = the QoS, it is wrong according to the standard. >=20 >>> Now, as you abstract ETSI and WAVE (thus pure IP), my understanding=20 >>> is that QoS remains required from the IEEE 802.11p (ok, IEEE >>> 802.11-2016 OCB) as there is a specification of the EDCA parameters=20 >>> for OCB. Besides, I do not think it costs much to keep the EDCA in,=20 >>> as it first allows to safe a half of the MAC queueing time (the EDCA = >>> parameters for the two low AC are less, up to a quarter of a=20 >>> DIFS...so, it could be beneficial to allow this even for IP. Second, = >>> the EDCA allows TXOpps (Transmit Opportunities)..although put to=20 >>> 'zero' for OCB (I think), this mechanism still allows an AP to=20 >>> reserve a given time a long(er) connectivity with one device (e. >>> streaming of video etc..). Finally, it does not cost anything..you=20 >>> can always take the lowest AC and you get the same behavior as = non-QoS.. >=20 >> Well, this text is more informal in nature. It is something that >> describes a potential behaviour but we have no proof of existing such = behaviour, no proof of interoperability. This could be part of an = INFORMATIONAL Internet Draft. >=20 > Well, my text is informal, but the specs are not. IEEE 802.11p (IEEE = 802.11-2016 OCB) uses EDCA not DCF...as this is L2 layer, I do not think = anything is required from IETF...just follow the IEEE 802.11-2016 specs = and do whatever is allows above it...I will double check again on the = IEEE 802.11-2016, but if what I think is confirmed, the whole discussion = does not make any sense..., as it is my understanding that the OCB = requires EDCA, so QoS_Data...so, you cannot change that at IP level. >=20 >=20 >>> Bottom line, the fact that some IP implementation to decode OCB=20 >>> assume non-QoS frames looks more to me like an implementation error=20 >>> and we should not propagate this... >=20 >> Well, wireshark has problems interpreting 802.11 QoS Data containing = CAM messages. Many receivers of QoS Data dont know what to do with the = fields because they are not agreed. >=20 > Yes, and this is why is the prototype we use, we actually have an = parser for CAM to be supported by Wireshark...it does not come by = default. But I am surprised..what kind of problem would wireshark face = with the QoS Data? >=20 >=20 >> I don't want to propagate that disagreement into the IP-over-OCB = draft. >=20 > To me, this looks more like an implementation issue, rather than a = standard issue...but I will ask my team to check on our prototype... >=20 >>> C-V2X will not use IP for CAM, >=20 >> LTE-V2X will carry CAM in IP. What is C-V2X and why does not it use = IP? >=20 > Sorry, it will not. In C-V2X (the widely known name...LTE-V2X is again = a bit like 802.11p...'LTE Prose for V2X' is the real name...), mode 4 = (ad-hoc mode..currently chosen by all vendors (except maybe Huawei, but = might have changed), there is two options for protocol stack: IPv6 = (again, only IPv6) and non-IP (L2)...you can use non-IP packets and it = is so mentioned that BSM and CAM will use the non-IP option, as it is = also required to use the ETSI/WAVE security provisions to secure the = C-V2X mode 4 (as no SIM=3D no security), as the ETSI/WAVE security = provisions works for non-IP packets (geonet or WSM)... >=20 > Of course, it does not block from using IP...it is again the same = discussion we had with ITS-G5/DSRC...for safety communication, IP is not = required...you can do everything without and faster. And considering = that IEEE 802.11p (ok, OCB) and C-V2X mode 4 (no SIM=3Dno SEC) DO NOT = have any form of security mechanism embedded, they must use the those = specified by ETSI/WAVE for accessing CCH. >=20 > Again, C-V2X mode 4 (the current V2X techno for Safety-critical = communication) shall not be seen as following the same path as other = cellular techno. It does not provide QoS (at all), as it channel access = is contention-based (a bit like CSMA)...so collisions will occur (unlike = 4G and 5G operated, where you are either dropped or you pass). And as = such, IP is also not required, even if all 4G and 5G use IP. >=20 >=20 >>> ETSI and WAVE will not use IP for CAM... >=20 >> That is their problem. >=20 > Disagree: you need to be compatible with them...so, whatever IETF will = do shall not break anything that has been done on ETSI or WAVE. This is = one of the requirement for accessing the ITS-G5 spectrum in EU, and I = believe the same in the US. >=20 >> ETSI transports IP over GeoNetworking - that is not the right way to = do it. >=20 > Disagree: we need to integrate security mechanisms specified by ETSI = even if we use IPv6. Today, we do not have any security specification = providing 'trust', privacy and authentication for using 802.11-OCB (I = believe it is the work of IPWAVE and it is not completed yet...). > The mistake ETSI did is to try to be nice with IETF and help them to = provide a way to use IPv6 over ITS-G5 in a secured way...WAVE took a = different path: 'not my problem', which then explain why ETSI officially = does not endorse IPWAVE (unfortunately, despite my many discussions with = them)...from an ETSI perspective, using IPv6 over ITS-G5 is = solved...(might be ugly, but it is solved). > =20 >>> the basic CAMs are used for pure positioning >=20 >> The mandatory fields in CAM or more than just lat/long/altitude. = There is also mandatory time in a strange format, car dimensions, curve, = non standard precisions and more. >=20 > Yes, correct...but these are configurable fields, which may or may not = be integrated...recent studies even showed that even the standard CAM = size is not clear anymore..you have a 'range' of size, and that is a = problem for wireless optimization...especially if you need to do = wireless congestion control. >=20 >>> and the recent 'increase' of information put in CAM >=20 >> If CAM worries about size, I think CAM should think about its = existing redundancy. For example, position is carried twice in a CAM = message: in the CAM itself and in the GeoNetworking header. That >is an = issue they should address first. >=20 > Well, of course, this is a waste...but one reason for such existence = is from the possibility to relay a packet (agnostic from the upper = messages, unfortunately, we cannot use a Zero-NET for CAM as it is pure = 1-hop TSB)... > Yet, today we start seeing even BSM investigating ways to do multi-hop = 'position' based relaying to reach longer distance. >=20 > And if you think about it, one day, your IPv6-over-OCB might need to = use a multi-hop networking protocol (e.g. MANET)..but doing the MANET = way is highly mobile environment will not be that = efficient...position-based mechanisms will be required (proven in = various previous studies)...now, your L3 will not be able to inspect the = GPS position of your CAM-over-IP...so, you will need to have GPS (or so) = position at IP/L3, which will end up being similar than now... >=20 > If you do not want to do this, then the IRTF people might come with=20 > ICN, but then would this be done above L3 or at L3...if still at L3,=20 > you still will have a contextual L3 packet that might be redundant=20 > with application/service layer messages...(the cost of using OSI) >=20 > But this is just my personal view and very long term...for now, if we = only look at CAM, indeed we can have twice the GPS position (but wait: = not the same granularity and you do not have elevation in geonet). But = if you look at the bigger picture: doing CAM-over-geonet only required = a single CAM, that's it. For IPv6-over-OCB, you need all the IPv6 = address autoconfiguration..that requires additional IPv6 packets to be = transmitted...this is similar to compare an apple with a tomato. > =20 >>> looks to be like a bad strategy as we end up having a container=20 >>> carrying too many things and being too big for what it is... >=20 >> I agree. But I think we should compare header sizes and then there = will be surprises. >> CAM transported in IP may be a smaller packet than CAM transported in = BTP and GeoNetworking. >=20 > Not that much if you counts also all IPv6-related control/management = packets required to transmit your CAM-over-OCB, in a highly dynamic = environment... >=20 >> (WLAN is good at squeezing various small packets but really not good=20 >> at big things especially in broadcast mode)...a better strategy would = >> be to define new messages tailored to the information needs, and have = >> smart service scheduling...(especially benefiting from IP-related >> mechanisms) >=20 >> I fully agree with this. >=20 > :-) at least we do on this :-) >=20 > Cheers, >=20 > J=C3=A9r=C3=B4me >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its >=20 >=20 From nobody Mon Feb 26 09:08:00 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4C112D7F8 for ; Mon, 26 Feb 2018 09:07:58 -0800 (PST) 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 5pS2rURpzDR4 for ; Mon, 26 Feb 2018 09:07:55 -0800 (PST) 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 A2D0E126C3D for ; Mon, 26 Feb 2018 09:07:54 -0800 (PST) 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 w1QH7qPK043059; Mon, 26 Feb 2018 18:07:52 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A26E120549C; Mon, 26 Feb 2018 18:07:52 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9150120545D; Mon, 26 Feb 2018 18:07:52 +0100 (CET) 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 w1QH7qDD006174; Mon, 26 Feb 2018 18:07:52 +0100 To: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , "=?UTF-8?Q?'Fran=c3=a7ois_Simon'?=" , its@ietf.org References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <006301d3ace3$25f9d500$71ed7f00$@eurecom.fr> <007901d3aee3$a9985ba0$fcc912e0$@eurecom.fr> <00f801d3af1d$f20ce4c0$d626ae40$@gmail.com> <002b01d3af21$6e779a70$4b66cf50$@eurecom.fr> From: Alexandre Petrescu Message-ID: Date: Mon, 26 Feb 2018 18:07:52 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <002b01d3af21$6e779a70$4b66cf50$@eurecom.fr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 26 Feb 2018 17:07:58 -0000 Le 26/02/2018 à 17:47, Jérôme Härri a écrit : > Hi Alex, All, > > Made a minor mistake: the 802.1D UP are actually 8 values, 0-7. So 8 > bits, and accordingly you can directly map the IPv6 TC to the > UP...there is a spec in ETSI for that, but not sure if there is one > spec in IETF for that. At IETF there is a spec that says that the Traffic Class field in the IPv6 header contains a DSCP (differentiated service code point) of length 6bit and the other 2bits are 'currently' unused. (RFC2474). As such, I dont think a one-to-one mapping between a 802.1D UP value and a DSCP value is possible, unless some compression algorithm is used. So, I dont think that mapping is as straightforward as one might see it at a first sight. > (did not have time to read Roland's identified RFC yet...maybe it is > there...) I looked at the RFC8325 referred to by Roland. As the mapping of an 8-bit value to a 6-bit value is not straightforward they do agree on a number of inconsistencies and potential conflicts. Remark, in none of those conflicts and inconsistencies they talk about anything related to vehicular networks. Even though one may assimilate 'CAM' to something like 'voice' because it has relatively same stringency in delivery requirements, one should better think twice: there is a huge difference of effect between an audio call subjected to some hicups and noise, and a CAM not reaching a destination thus making some vehicle believe there is no obstacle. That is why I thik RFC8325 could be a good starting point, but there should be more. And until then, I think it is good to just go with Data in IPv6-over-OCB. Alex > > BR, > > Jérôme -----Original Message----- From: Alexandre Petrescu > [mailto:alexandre.petrescu@gmail.com] Sent: Monday 26 February 2018 > 17:41 To: François Simon; 'Jérôme Härri'; its@ietf.org Subject: Re: > [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB > > > > Le 26/02/2018 à 17:22, François Simon a écrit : >> Correct ! > > Is there a mapping between the Access Categories and IPv6 Traffic > Class fields? > > RFC8200: >> 3. IPv6 Header Format >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |Version| Traffic Class | Flow Label | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Payload Length | Next Header | Hop Limit | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | + + | | + Source Address + | | + + | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | + + | | + Destination Address + | | + + | >> | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Version 4-bit Internet Protocol version number = 6. >> >> Traffic Class 8-bit Traffic Class field. See Section 7. >> >> Flow Label 20-bit flow label. See Section 6. > > > Alex > >> >> -----Original Message----- From: its [mailto:its-bounces@ietf.org] >> On Behalf Of Jérôme Härri Sent: Monday, February 26, 2018 4:25 AM >> To: 'Alexandre Petrescu' ; >> its@ietf.org Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data >> in IPv6-over-802.11-OCB >> >> Hi Alex, >> >>> That is a requirement. >>> >>> But is there an implementation of mapping the priority of CAM >>> over DENM into a QoS Control field in QoS Data Header? >>> >>> I doubt there is, because the implementations of CAM I see put >>> the Priority field to 6, which means Voice. So they transmit >>> CAM as Voice even though it is not voice. >>> >>> We can not reckon in IPv6-over-OCB document something which >>> makes little sense (send CAM as Voice). >> >> Of course there is....the QoS fields actually means the Access >> Categories (AC) for WLAN, so EDCA. Both in ETSI and in WAVE they >> use the QoS Control filed of IEE 802.11p to send CAM/BSM with >> higher priority (from a MAC perspective)...When looking at the >> EDCA 'naming' you should not care much of the 'name'...this was >> done at the time internet was only composed of voice, video >> etc..you should look at the underlying values of each AC. >> >> So, EDCA is composed of two fields: 1) AIFN - a deterministic idle >> time before even considering reducing CW 2) CW - a random timer to >> decrease each time the channel is idle. >> >> QoS Data combinations for OCB: AC_VO: AIFN=2, CW=8 AC_VI: AIFN=2, >> CW=16 AC_BE: AIFN=3, CW=32 AC_BK: AIFN=7, CW=32 >> >> So, it does not matter the name (Voice, video)..what matters is >> that in implementation (BSM for instance), AIFN=2 so that it takes >> the fastest access (deterministic) and as such has the highest >> priority. This is also what you found: CAM on Priority field 6, so >> AC_VI so AIFN=2. BSM uses the same strategy. >> >> Now, on the CAR 2 CAR specification, it is recommended a different >> priority: AC_BE, as it uses DP2. The reason behind this is the >> CAR2CAR provides a 'strict' prioritization between DENMs and CAMs. >> Emergency DENMs uses AC_VI, normal DENM uses AC_VO, CAM uses AC_BE >> and any other traffic AC_BK. >> >> So, bottom line is: all ETSI and WAVE implementation use the QoS >> Data field as they use EDCA. If you found an implementation that >> does not use the QoS, it is wrong according to the standard. >> >>>> Now, as you abstract ETSI and WAVE (thus pure IP), my >>>> understanding is that QoS remains required from the IEEE >>>> 802.11p (ok, IEEE 802.11-2016 OCB) as there is a specification >>>> of the EDCA parameters for OCB. Besides, I do not think it >>>> costs much to keep the EDCA in, as it first allows to safe a >>>> half of the MAC queueing time (the EDCA parameters for the two >>>> low AC are less, up to a quarter of a DIFS...so, it could be >>>> beneficial to allow this even for IP. Second, the EDCA allows >>>> TXOpps (Transmit Opportunities)..although put to 'zero' for >>>> OCB (I think), this mechanism still allows an AP to reserve a >>>> given time a long(er) connectivity with one device (e. >>>> streaming of video etc..). Finally, it does not cost >>>> anything..you can always take the lowest AC and you get the >>>> same behavior as non-QoS.. >> >>> Well, this text is more informal in nature. It is something >>> that describes a potential behaviour but we have no proof of >>> existing such behaviour, no proof of interoperability. This >>> could be part of an INFORMATIONAL Internet Draft. >> >> Well, my text is informal, but the specs are not. IEEE 802.11p >> (IEEE 802.11-2016 OCB) uses EDCA not DCF...as this is L2 layer, I >> do not think anything is required from IETF...just follow the IEEE >> 802.11-2016 specs and do whatever is allows above it...I will >> double check again on the IEEE 802.11-2016, but if what I think is >> confirmed, the whole discussion does not make any sense..., as it >> is my understanding that the OCB requires EDCA, so QoS_Data...so, >> you cannot change that at IP level. >> >> >>>> Bottom line, the fact that some IP implementation to decode OCB >>>> assume non-QoS frames looks more to me like an implementation >>>> error and we should not propagate this... >> >>> Well, wireshark has problems interpreting 802.11 QoS Data >>> containing CAM messages. Many receivers of QoS Data dont know >>> what to do with the fields because they are not agreed. >> >> Yes, and this is why is the prototype we use, we actually have an >> parser for CAM to be supported by Wireshark...it does not come by >> default. But I am surprised..what kind of problem would wireshark >> face with the QoS Data? >> >> >>> I don't want to propagate that disagreement into the IP-over-OCB >>> draft. >> >> To me, this looks more like an implementation issue, rather than a >> standard issue...but I will ask my team to check on our >> prototype... >> >>>> C-V2X will not use IP for CAM, >> >>> LTE-V2X will carry CAM in IP. What is C-V2X and why does not it >>> use IP? >> >> Sorry, it will not. In C-V2X (the widely known name...LTE-V2X is >> again a bit like 802.11p...'LTE Prose for V2X' is the real >> name...), mode 4 (ad-hoc mode..currently chosen by all vendors >> (except maybe Huawei, but might have changed), there is two >> options for protocol stack: IPv6 (again, only IPv6) and non-IP >> (L2)...you can use non-IP packets and it is so mentioned that BSM >> and CAM will use the non-IP option, as it is also required to use >> the ETSI/WAVE security provisions to secure the C-V2X mode 4 (as no >> SIM= no security), as the ETSI/WAVE security provisions works for >> non-IP packets (geonet or WSM)... >> >> Of course, it does not block from using IP...it is again the same >> discussion we had with ITS-G5/DSRC...for safety communication, IP >> is not required...you can do everything without and faster. And >> considering that IEEE 802.11p (ok, OCB) and C-V2X mode 4 (no >> SIM=no SEC) DO NOT have any form of security mechanism embedded, >> they must use the those specified by ETSI/WAVE for accessing CCH. >> >> Again, C-V2X mode 4 (the current V2X techno for Safety-critical >> communication) shall not be seen as following the same path as >> other cellular techno. It does not provide QoS (at all), as it >> channel access is contention-based (a bit like CSMA)...so >> collisions will occur (unlike 4G and 5G operated, where you are >> either dropped or you pass). And as such, IP is also not required, >> even if all 4G and 5G use IP. >> >> >>>> ETSI and WAVE will not use IP for CAM... >> >>> That is their problem. >> >> Disagree: you need to be compatible with them...so, whatever IETF >> will do shall not break anything that has been done on ETSI or >> WAVE. This is one of the requirement for accessing the ITS-G5 >> spectrum in EU, and I believe the same in the US. >> >>> ETSI transports IP over GeoNetworking - that is not the right >>> way to do it. >> >> Disagree: we need to integrate security mechanisms specified by >> ETSI even if we use IPv6. Today, we do not have any security >> specification providing 'trust', privacy and authentication for >> using 802.11-OCB (I believe it is the work of IPWAVE and it is not >> completed yet...). The mistake ETSI did is to try to be nice with >> IETF and help them to provide a way to use IPv6 over ITS-G5 in a >> secured way...WAVE took a different path: 'not my problem', which >> then explain why ETSI officially does not endorse IPWAVE >> (unfortunately, despite my many discussions with them)...from an >> ETSI perspective, using IPv6 over ITS-G5 is solved...(might be >> ugly, but it is solved). >> >>>> the basic CAMs are used for pure positioning >> >>> The mandatory fields in CAM or more than just lat/long/altitude. >>> There is also mandatory time in a strange format, car >>> dimensions, curve, non standard precisions and more. >> >> Yes, correct...but these are configurable fields, which may or may >> not be integrated...recent studies even showed that even the >> standard CAM size is not clear anymore..you have a 'range' of >> size, and that is a problem for wireless optimization...especially >> if you need to do wireless congestion control. >> >>>> and the recent 'increase' of information put in CAM >> >>> If CAM worries about size, I think CAM should think about its >>> existing redundancy. For example, position is carried twice in >>> a CAM message: in the CAM itself and in the GeoNetworking >>> header. That >is an issue they should address first. >> >> Well, of course, this is a waste...but one reason for such >> existence is from the possibility to relay a packet (agnostic from >> the upper messages, unfortunately, we cannot use a Zero-NET for >> CAM as it is pure 1-hop TSB)... Yet, today we start seeing even >> BSM investigating ways to do multi-hop 'position' based relaying >> to reach longer distance. >> >> And if you think about it, one day, your IPv6-over-OCB might need >> to use a multi-hop networking protocol (e.g. MANET)..but doing the >> MANET way is highly mobile environment will not be that >> efficient...position-based mechanisms will be required (proven in >> various previous studies)...now, your L3 will not be able to >> inspect the GPS position of your CAM-over-IP...so, you will need >> to have GPS (or so) position at IP/L3, which will end up being >> similar than now... >> >> If you do not want to do this, then the IRTF people might come with >> ICN, but then would this be done above L3 or at L3...if still at >> L3, you still will have a contextual L3 packet that might be >> redundant with application/service layer messages...(the cost of >> using OSI) >> >> But this is just my personal view and very long term...for now, if >> we only look at CAM, indeed we can have twice the GPS position >> (but wait: not the same granularity and you do not have elevation >> in geonet). But if you look at the bigger picture: doing >> CAM-over-geonet only required a single CAM, that's it. For >> IPv6-over-OCB, you need all the IPv6 address >> autoconfiguration..that requires additional IPv6 packets to be >> transmitted...this is similar to compare an apple with a tomato. >> >>>> looks to be like a bad strategy as we end up having a container >>>> carrying too many things and being too big for what it is... >> >>> I agree. But I think we should compare header sizes and then >>> there will be surprises. CAM transported in IP may be a smaller >>> packet than CAM transported in BTP and GeoNetworking. >> >> Not that much if you counts also all IPv6-related >> control/management packets required to transmit your CAM-over-OCB, >> in a highly dynamic environment... >> >>> (WLAN is good at squeezing various small packets but really not >>> good at big things especially in broadcast mode)...a better >>> strategy would be to define new messages tailored to the >>> information needs, and have smart service >>> scheduling...(especially benefiting from IP-related mechanisms) >> >>> I fully agree with this. >> >> :-) at least we do on this :-) >> >> Cheers, >> >> Jérôme >> >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/listinfo/its >> >> > > From nobody Mon Feb 26 09:12:35 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 392421242EA for ; Mon, 26 Feb 2018 09:12:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 mGKz8hQGZcwj for ; Mon, 26 Feb 2018 09:12:32 -0800 (PST) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4F1F1205F0 for ; Mon, 26 Feb 2018 09:12:31 -0800 (PST) Received: by mail-qt0-x22f.google.com with SMTP id v90so19641258qte.12 for ; Mon, 26 Feb 2018 09:12:31 -0800 (PST) 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-transfer-encoding:thread-index :content-language; bh=HmTxyeWLAK7K5CdmmfHHAqGOEejfuDPPeWqDfeHkAfc=; b=OQmxqK6mNa985B5S54ITbegljoL3hrVUTUo3utz1+0EB80Zgtw1cF9JPVyIC52Qv4w BrNfztMKoOKB9dRuDPBSCDvhcOdd5tzrwUvzvpObhGwk2DPL6sgZxUdMQ9Qw34PQsp8M Ebvd4Chuy5Wwz3hLJWItuqqUMJYpACKdo+70xqdFk9V2ZsRdfxsk60mth8JSpb2uyO5S ZUD1yGxGPSGQPbD31kk/yjvAtRij+fPTF7XRGqfUZb8By9ZG4Ym7TlsAGlJGFLH638pd qRoupUSAhB3bA+WjezqUb0l7k91Mw433OCfZuMyzNlbvt8qOg6tITXhPCZBrBemUtdBA VAvg== 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-transfer-encoding:thread-index :content-language; bh=HmTxyeWLAK7K5CdmmfHHAqGOEejfuDPPeWqDfeHkAfc=; b=qtR9u5GEXndeuBYsLvgkaBv8C2yW8UX7NkwPHD23FVlp5BXMGjnDiRkhf9RhUW0V2t EqA+CWuBeNHk1QH6yeoEIarcS8bA2vIQmgbgKELdjxu9BZ9H+KO4ACJGPYDhFX5ArY/2 pMIzNytczjW0fvJt3qHxgIZaiA2F4KkKDZPP8urkSVko7OWAWsuRJJrVhhx9Gi7X5Tt5 CN1iDGcrhCcy5WwjkzP+usZdpzr1lAqplGnQeA41TIiyqaKW5pKbYFlkCkPohW0HRshe aMZIbAKEF5clGXoBmE4SYyN/eiyD+F+7r3qWaOQsxIB8Xv7HpVFvHwb72s+lx4+/X+Lq 1iDA== X-Gm-Message-State: APf1xPD87SYciM7dPaPJcpLhyhwR7r9TMhkUq+NicGAmPUWQs1cEXJej kuQZAFsYiQ2DfCLMos9iJRA= X-Google-Smtp-Source: AG47ELt9Dh8EhCtklzxWNfIstEc5KEvoI5LbWyEt2vLjb5BG3UbupNP2v8xJH+GJXobuvJYG5K+qEQ== X-Received: by 10.200.65.86 with SMTP id e22mr12970531qtm.183.1519665151084; Mon, 26 Feb 2018 09:12:31 -0800 (PST) Received: from FrancoisPC (pool-108-48-182-86.washdc.fios.verizon.net. [108.48.182.86]) by smtp.gmail.com with ESMTPSA id p34sm5735815qtj.3.2018.02.26.09.12.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Feb 2018 09:12:30 -0800 (PST) From: =?UTF-8?Q?Fran=C3=A7ois_Simon?= To: "'Alexandre Petrescu'" , "'Dr. Hans-Joachim Fischer'" , "'Abdussalam Baryun'" Cc: "'Tony Li'" , "'its'" References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <9ada5591-2af3-272d-3bc3-031bf35454c3@gmail.com> <6cdc0835-fb4c-133b-77ff-0234cfdd9ef9@fischer-tech.eu> <00eb01d3af1d$7f4e8100$7deb8300$@gmail.com> <6187cb92-5c8f-d08b-dcc2-859652d629d0@gmail.com> In-Reply-To: <6187cb92-5c8f-d08b-dcc2-859652d629d0@gmail.com> Date: Mon, 26 Feb 2018 12:12:29 -0500 Message-ID: <018e01d3af24$fb9696b0$f2c3c410$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHelLAw/aN7IRfcwiTBG/gKcgHVEwGONDnFAivYBTcB5QRVgwFu9SHuAdIGJvACSXL3QAKWMu63Adu1s1+jJETGoA== Content-Language: en-us Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 26 Feb 2018 17:12:34 -0000 In the RFC you can call it what ever you wish. -----Original Message----- From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com]=20 Sent: Monday, February 26, 2018 11:23 AM To: Fran=C3=A7ois Simon ; 'Dr. Hans-Joachim Fischer' = ; 'Abdussalam Baryun' = Cc: 'Tony Li' ; 'its' Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in = IPv6-over-802.11-OCB Le 26/02/2018 =C3=A0 17:18, Fran=C3=A7ois Simon a =C3=A9crit : > AC_VO (voice) is only a label indicating the highest priority; nothing = > more is implied. YEs, sure, but imagine someone sends real voice; that will compete with = CAM 'voice' - we dont want that either :-) In such situation, what one would like in standards is to see 'highest = priority' instead of 'voice'. Alex >=20 > *From:*its [mailto:its-bounces@ietf.org] *On Behalf Of *Dr.=20 > Hans-Joachim Fischer > *Sent:* Monday, February 26, 2018 3:37 AM > *To:* Abdussalam Baryun ; Alexandre=20 > Petrescu > *Cc:* Tony Li ; its > *Subject:* Re: [ipwave] 802.11 Data vs 802.11 QoS Data in=20 > IPv6-over-802.11-OCB >=20 > Be careful with voice and audio transmission in ITS using 5,9 GHz.=20 > That seems to be prohibited by regulation in Europe; well, not=20 > explicitly, but this is a possible interpretation of the technical=20 > requirements presented in regulatory documents. In Germany, it is = prohibited. >=20 > Hans-Joachim >=20 > Am 26.02.2018 um 09:04 schrieb Abdussalam Baryun: >=20 > The experience test you referred to is not clarified, was it a ITS > environment experience or was it a fixed wireless experience. > Furthermore, the WiFi technology ieee802.11 is developed so which > WiFi technology was used. Moreover, did your experience use Video > and voice communication or your proposal is only for data > communication only. >=20 > So if your IP packet are data then your experience is right, but = if > the IP packet is carrying voice or video I don't agree. IMO we = could > not exclude from the draft voice and video communication in the = ITS > environment/use-case. >=20 > On Sun, Feb 25, 2018 at 7:58 PM, Alexandre Petrescu > > > wrote: >=20 >=20 >=20 > Le 23/02/2018 =C3=A0 18:38, Tony Li a =C3=A9crit : >=20 > If we put that CAM on IP there will still be lack of > interoperability, > unless we recommend IP to be carried by a particular > 802.11 header (Data > or QoS Data). >=20 >=20 >=20 > I would propose that we use the Data header. My experience > with the QoS Data with Wi-Fi was that there wasn=E2=80=99t = enough of > a performance difference with QoS for it to make a > difference to the IP layer. >=20 >=20 > I agree. >=20 > I propose the following text. >=20 > OLD: >=20 > In OCB mode, IPv6 packets MAY be transmitted either as > "IEEE 802.11 > Data" or alternatively as "IEEE 802.11 QoS Data", as > illustrated in > Figure 2. >=20 >=20 > NEW: >=20 > In OCB mode, it is RECOMMENDED to transmit IPv6 = packets > as "IEEE > 802.11 Data" (the value of the field Subtype in the > Frame Control > Field is 0). >=20 >=20 > Alex >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its >=20 >=20 >=20 >=20 > _______________________________________________ >=20 > its mailing list >=20 > its@ietf.org >=20 > https://www.ietf.org/mailman/listinfo/its >=20 >=20 >=20 > -- >=20 > Dr. Hans-Joachim Fischer >=20 > Managing Director >=20 > ---------------------------------------------------------------------- > ---------- >=20 > ESF News edition 2018/1 >=20 > https://fischer-tech.eu/Feeds/News/ESF-News-2018-01.pdf >=20 > ---------------------------------------------------------------------- > ---------- >=20 > Towards deployment of C-ITS based on proven technology >=20 > Avoid risks and delay by looking on potential future technologies. >=20 > The real advocate on ITS is ISO TC204! >=20 > ---------------------------------------------------------------------- > ---------- >=20 > + + + Instaurare omnia in Christo + + + >=20 > ---------------------------------------------------------------------- > ---------- >=20 > The information contained in this message is confidential and may be=20 > legally >=20 > privileged. This email is intended for the addressee(s). Addressees=20 > may be >=20 > individual persons or members of mailing list. >=20 > If you are not an addressee, you are hereby notified that any use, >=20 > dissemination, or reproduction of this email and its optional=20 > attachements is >=20 > strictly prohibited and may be unlawful. If you are not an addressee,=20 > please >=20 > contact the sender by return e-mail and destroy all copies of the=20 > original >=20 > message. >=20 > ---------------------------------------------------------------------- > ---------- >=20 > ESF GmbH >=20 > Fichtenweg 9 >=20 > 89143 Blaubeuren >=20 > +49 (7344) 175340 (Direct line Dr. Fischer) >=20 > +49 (7344) 919188 (Central office) >=20 > +49 (7344) 919123 (Fax) >=20 > https://fischer-tech.eu : Main web of ESF GmbH >=20 > http://its-standards.eu : News on cooperative ITS standardization >=20 > http://its-testing.org : International consultancy for cooperative=20 > ITS >=20 > ---------------------------------------------------------------------- > ---------- >=20 > ---------------------------------------------------------------------- > ---------- >=20 > ESF online-news:http://fischer-tech.eu/Feeds/esf.rss >=20 > C-ITS online news:http://its-standards.info/Feeds/cits.rss >=20 > ESF Online Nachrichten:http://fischer-tech.de/Feeds/esfD.rss >=20 > ---------------------------------------------------------------------- > --------- >=20 From nobody Mon Feb 26 09:24:00 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55AF4127342 for ; Mon, 26 Feb 2018 09:23:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gn9UWBktV3CB for ; Mon, 26 Feb 2018 09:23:56 -0800 (PST) Received: from smtp2.eurecom.fr (smtp2.eurecom.fr [193.55.113.211]) by ietfa.amsl.com (Postfix) with ESMTP id 8285812025C for ; Mon, 26 Feb 2018 09:23:53 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.47,397,1515452400"; d="scan'208";a="7702351" Received: from monza.eurecom.fr ([192.168.106.15]) by drago2i.eurecom.fr with ESMTP; 26 Feb 2018 18:23:52 +0100 Received: from xerus29 (unknown [192.168.200.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by monza.eurecom.fr (Postfix) with ESMTPSA id 3CB301AC5; Mon, 26 Feb 2018 18:23:52 +0100 (CET) From: =?utf-8?B?SsOpcsO0bWUgSMOkcnJp?= To: "'Alexandre Petrescu'" , =?utf-8?Q?'Fran=C3=A7ois_Simon'?= , References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <006301d3ace3$25f9d500$71ed7f00$@eurecom.fr> <007901d3aee3$a9985ba0$fcc912e0$@eurecom.fr> <00f801d3af1d$f20ce4c0$d626ae40$@gmail.com> <002b01d3af21$6e779a70$4b66cf50$@eurecom.fr> In-Reply-To: Date: Mon, 26 Feb 2018 18:23:51 +0100 Organization: EURECOM Message-ID: <006c01d3af26$92655990$b7300cb0$@eurecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHelLAw/aN7IRfcwiTBG/gKcgHVEwGONDnFAivYBTcBDgW0eQFK9evKAbex+qQCF4nJkAMphqaUAo/H9voB/QVRS6MUXi5w Content-Language: en-us Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 26 Feb 2018 17:23:59 -0000 Hi Alex, I see...indeed not straightforward...is the RFC pointed out by Roland = doing the mapping? If so, we could use it...otherwise, we could define = what we prefer...(for example, the ETSI also did it for Geonet...mapping = a geonet TF to the AC_...a bit arbitrary, but was tailored made) BR, J=C3=A9r=C3=B4me -----Original Message----- From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com]=20 Sent: Monday 26 February 2018 18:08 To: J=C3=A9r=C3=B4me H=C3=A4rri; 'Fran=C3=A7ois Simon'; its@ietf.org Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in = IPv6-over-802.11-OCB Le 26/02/2018 =C3=A0 17:47, J=C3=A9r=C3=B4me H=C3=A4rri a =C3=A9crit : > Hi Alex, All, >=20 > Made a minor mistake: the 802.1D UP are actually 8 values, 0-7. So 8=20 > bits, and accordingly you can directly map the IPv6 TC to the=20 > UP...there is a spec in ETSI for that, but not sure if there is one=20 > spec in IETF for that. At IETF there is a spec that says that the Traffic Class field in the IPv6 header contains a DSCP (differentiated service code point) of = length 6bit and the other 2bits are 'currently' unused. (RFC2474). As such, I dont think a one-to-one mapping between a 802.1D UP value and = a DSCP value is possible, unless some compression algorithm is used. So, I dont think that mapping is as straightforward as one might see it = at a first sight. > (did not have time to read Roland's identified RFC yet...maybe it is > there...) I looked at the RFC8325 referred to by Roland. As the mapping of an = 8-bit value to a 6-bit value is not straightforward they do agree on a = number of inconsistencies and potential conflicts. Remark, in none of those conflicts and inconsistencies they talk about = anything related to vehicular networks. Even though one may assimilate 'CAM' to something like 'voice' because = it has relatively same stringency in delivery requirements, one should = better think twice: there is a huge difference of effect between an = audio call subjected to some hicups and noise, and a CAM not reaching a = destination thus making some vehicle believe there is no obstacle. That is why I thik RFC8325 could be a good starting point, but there = should be more. And until then, I think it is good to just go with Data in = IPv6-over-OCB. Alex >=20 > BR, >=20 > J=C3=A9r=C3=B4me -----Original Message----- From: Alexandre Petrescu=20 > [mailto:alexandre.petrescu@gmail.com] Sent: Monday 26 February 2018 > 17:41 To: Fran=C3=A7ois Simon; 'J=C3=A9r=C3=B4me H=C3=A4rri'; = its@ietf.org Subject: Re:=20 > [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB >=20 >=20 >=20 > Le 26/02/2018 =C3=A0 17:22, Fran=C3=A7ois Simon a =C3=A9crit : >> Correct ! >=20 > Is there a mapping between the Access Categories and IPv6 Traffic=20 > Class fields? >=20 > RFC8200: >> 3. IPv6 Header Format >>=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 >> |Version| Traffic Class | Flow Label |=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Payload Length | Next Header | Hop Limit |=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | + + | | + Source Address + | | + + | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | + + | | + Destination Address + | | + + | >> |=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >> Version 4-bit Internet Protocol version number =3D 6. >>=20 >> Traffic Class 8-bit Traffic Class field. See Section 7. >>=20 >> Flow Label 20-bit flow label. See Section 6. >=20 >=20 > Alex >=20 >>=20 >> -----Original Message----- From: its [mailto:its-bounces@ietf.org] On = >> Behalf Of J=C3=A9r=C3=B4me H=C3=A4rri Sent: Monday, February 26, 2018 = 4:25 AM >> To: 'Alexandre Petrescu' ; its@ietf.org = >> Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in=20 >> IPv6-over-802.11-OCB >>=20 >> Hi Alex, >>=20 >>> That is a requirement. >>>=20 >>> But is there an implementation of mapping the priority of CAM over=20 >>> DENM into a QoS Control field in QoS Data Header? >>>=20 >>> I doubt there is, because the implementations of CAM I see put the=20 >>> Priority field to 6, which means Voice. So they transmit CAM as=20 >>> Voice even though it is not voice. >>>=20 >>> We can not reckon in IPv6-over-OCB document something which makes=20 >>> little sense (send CAM as Voice). >>=20 >> Of course there is....the QoS fields actually means the Access=20 >> Categories (AC) for WLAN, so EDCA. Both in ETSI and in WAVE they use=20 >> the QoS Control filed of IEE 802.11p to send CAM/BSM with higher=20 >> priority (from a MAC perspective)...When looking at the EDCA 'naming' = >> you should not care much of the 'name'...this was done at the time=20 >> internet was only composed of voice, video etc..you should look at=20 >> the underlying values of each AC. >>=20 >> So, EDCA is composed of two fields: 1) AIFN - a deterministic idle=20 >> time before even considering reducing CW 2) CW - a random timer to=20 >> decrease each time the channel is idle. >>=20 >> QoS Data combinations for OCB: AC_VO: AIFN=3D2, CW=3D8 AC_VI: = AIFN=3D2, >> CW=3D16 AC_BE: AIFN=3D3, CW=3D32 AC_BK: AIFN=3D7, CW=3D32 >>=20 >> So, it does not matter the name (Voice, video)..what matters is that=20 >> in implementation (BSM for instance), AIFN=3D2 so that it takes the=20 >> fastest access (deterministic) and as such has the highest priority.=20 >> This is also what you found: CAM on Priority field 6, so AC_VI so=20 >> AIFN=3D2. BSM uses the same strategy. >>=20 >> Now, on the CAR 2 CAR specification, it is recommended a different >> priority: AC_BE, as it uses DP2. The reason behind this is the=20 >> CAR2CAR provides a 'strict' prioritization between DENMs and CAMs. >> Emergency DENMs uses AC_VI, normal DENM uses AC_VO, CAM uses AC_BE=20 >> and any other traffic AC_BK. >>=20 >> So, bottom line is: all ETSI and WAVE implementation use the QoS Data = >> field as they use EDCA. If you found an implementation that does not=20 >> use the QoS, it is wrong according to the standard. >>=20 >>>> Now, as you abstract ETSI and WAVE (thus pure IP), my understanding = >>>> is that QoS remains required from the IEEE 802.11p (ok, IEEE=20 >>>> 802.11-2016 OCB) as there is a specification of the EDCA parameters = >>>> for OCB. Besides, I do not think it costs much to keep the EDCA in, = >>>> as it first allows to safe a half of the MAC queueing time (the=20 >>>> EDCA parameters for the two low AC are less, up to a quarter of a=20 >>>> DIFS...so, it could be beneficial to allow this even for IP.=20 >>>> Second, the EDCA allows TXOpps (Transmit Opportunities)..although=20 >>>> put to 'zero' for OCB (I think), this mechanism still allows an AP=20 >>>> to reserve a given time a long(er) connectivity with one device (e. >>>> streaming of video etc..). Finally, it does not cost anything..you=20 >>>> can always take the lowest AC and you get the same behavior as=20 >>>> non-QoS.. >>=20 >>> Well, this text is more informal in nature. It is something=20 >>> that describes a potential behaviour but we have no proof of=20 >>> existing such behaviour, no proof of interoperability. This could=20 >>> be part of an INFORMATIONAL Internet Draft. >>=20 >> Well, my text is informal, but the specs are not. IEEE 802.11p (IEEE=20 >> 802.11-2016 OCB) uses EDCA not DCF...as this is L2 layer, I do not=20 >> think anything is required from IETF...just follow the IEEE >> 802.11-2016 specs and do whatever is allows above it...I will double=20 >> check again on the IEEE 802.11-2016, but if what I think is=20 >> confirmed, the whole discussion does not make any sense..., as it is=20 >> my understanding that the OCB requires EDCA, so QoS_Data...so, you=20 >> cannot change that at IP level. >>=20 >>=20 >>>> Bottom line, the fact that some IP implementation to decode OCB=20 >>>> assume non-QoS frames looks more to me like an implementation error = >>>> and we should not propagate this... >>=20 >>> Well, wireshark has problems interpreting 802.11 QoS Data containing = >>> CAM messages. Many receivers of QoS Data dont know what to do with=20 >>> the fields because they are not agreed. >>=20 >> Yes, and this is why is the prototype we use, we actually have an=20 >> parser for CAM to be supported by Wireshark...it does not come by=20 >> default. But I am surprised..what kind of problem would wireshark=20 >> face with the QoS Data? >>=20 >>=20 >>> I don't want to propagate that disagreement into the IP-over-OCB=20 >>> draft. >>=20 >> To me, this looks more like an implementation issue, rather than a=20 >> standard issue...but I will ask my team to check on our prototype... >>=20 >>>> C-V2X will not use IP for CAM, >>=20 >>> LTE-V2X will carry CAM in IP. What is C-V2X and why does not it use = >>> IP? >>=20 >> Sorry, it will not. In C-V2X (the widely known name...LTE-V2X is=20 >> again a bit like 802.11p...'LTE Prose for V2X' is the real name...),=20 >> mode 4 (ad-hoc mode..currently chosen by all vendors (except maybe=20 >> Huawei, but might have changed), there is two options for protocol=20 >> stack: IPv6 (again, only IPv6) and non-IP (L2)...you can use non-IP=20 >> packets and it is so mentioned that BSM and CAM will use the non-IP=20 >> option, as it is also required to use the ETSI/WAVE security=20 >> provisions to secure the C-V2X mode 4 (as no SIM=3D no security), as=20 >> the ETSI/WAVE security provisions works for non-IP packets (geonet or = >> WSM)... >>=20 >> Of course, it does not block from using IP...it is again the same=20 >> discussion we had with ITS-G5/DSRC...for safety communication, IP is=20 >> not required...you can do everything without and faster. And=20 >> considering that IEEE 802.11p (ok, OCB) and C-V2X mode 4 (no SIM=3Dno = >> SEC) DO NOT have any form of security mechanism embedded, they must=20 >> use the those specified by ETSI/WAVE for accessing CCH. >>=20 >> Again, C-V2X mode 4 (the current V2X techno for Safety-critical >> communication) shall not be seen as following the same path as other=20 >> cellular techno. It does not provide QoS (at all), as it channel=20 >> access is contention-based (a bit like CSMA)...so collisions will=20 >> occur (unlike 4G and 5G operated, where you are either dropped or you = >> pass). And as such, IP is also not required, even if all 4G and 5G=20 >> use IP. >>=20 >>=20 >>>> ETSI and WAVE will not use IP for CAM... >>=20 >>> That is their problem. >>=20 >> Disagree: you need to be compatible with them...so, whatever IETF=20 >> will do shall not break anything that has been done on ETSI or WAVE.=20 >> This is one of the requirement for accessing the ITS-G5 spectrum in=20 >> EU, and I believe the same in the US. >>=20 >>> ETSI transports IP over GeoNetworking - that is not the right way to = >>> do it. >>=20 >> Disagree: we need to integrate security mechanisms specified by ETSI=20 >> even if we use IPv6. Today, we do not have any security specification = >> providing 'trust', privacy and authentication for using 802.11-OCB (I = >> believe it is the work of IPWAVE and it is not completed yet...). The = >> mistake ETSI did is to try to be nice with IETF and help them to=20 >> provide a way to use IPv6 over ITS-G5 in a secured way...WAVE took a=20 >> different path: 'not my problem', which then explain why ETSI=20 >> officially does not endorse IPWAVE (unfortunately, despite my many=20 >> discussions with them)...from an ETSI perspective, using IPv6 over=20 >> ITS-G5 is solved...(might be ugly, but it is solved). >>=20 >>>> the basic CAMs are used for pure positioning >>=20 >>> The mandatory fields in CAM or more than just lat/long/altitude.=20 >>> There is also mandatory time in a strange format, car dimensions,=20 >>> curve, non standard precisions and more. >>=20 >> Yes, correct...but these are configurable fields, which may or may=20 >> not be integrated...recent studies even showed that even the standard = >> CAM size is not clear anymore..you have a 'range' of size, and that=20 >> is a problem for wireless optimization...especially if you need to do = >> wireless congestion control. >>=20 >>>> and the recent 'increase' of information put in CAM >>=20 >>> If CAM worries about size, I think CAM should think about its=20 >>> existing redundancy. For example, position is carried twice in a=20 >>> CAM message: in the CAM itself and in the GeoNetworking header. That = >>> >is an issue they should address first. >>=20 >> Well, of course, this is a waste...but one reason for such existence=20 >> is from the possibility to relay a packet (agnostic from the upper=20 >> messages, unfortunately, we cannot use a Zero-NET for CAM as it is=20 >> pure 1-hop TSB)... Yet, today we start seeing even BSM investigating=20 >> ways to do multi-hop 'position' based relaying to reach longer=20 >> distance. >>=20 >> And if you think about it, one day, your IPv6-over-OCB might need to=20 >> use a multi-hop networking protocol (e.g. MANET)..but doing the MANET = >> way is highly mobile environment will not be that=20 >> efficient...position-based mechanisms will be required (proven in=20 >> various previous studies)...now, your L3 will not be able to inspect=20 >> the GPS position of your CAM-over-IP...so, you will need to have GPS=20 >> (or so) position at IP/L3, which will end up being similar than=20 >> now... >>=20 >> If you do not want to do this, then the IRTF people might come with=20 >> ICN, but then would this be done above L3 or at L3...if still at L3,=20 >> you still will have a contextual L3 packet that might be redundant=20 >> with application/service layer messages...(the cost of using OSI) >>=20 >> But this is just my personal view and very long term...for now, if we = >> only look at CAM, indeed we can have twice the GPS position (but=20 >> wait: not the same granularity and you do not have elevation in=20 >> geonet). But if you look at the bigger picture: doing=20 >> CAM-over-geonet only required a single CAM, that's it. For=20 >> IPv6-over-OCB, you need all the IPv6 address autoconfiguration..that=20 >> requires additional IPv6 packets to be transmitted...this is similar=20 >> to compare an apple with a tomato. >>=20 >>>> looks to be like a bad strategy as we end up having a container=20 >>>> carrying too many things and being too big for what it is... >>=20 >>> I agree. But I think we should compare header sizes and then there=20 >>> will be surprises. CAM transported in IP may be a smaller packet=20 >>> than CAM transported in BTP and GeoNetworking. >>=20 >> Not that much if you counts also all IPv6-related control/management=20 >> packets required to transmit your CAM-over-OCB, in a highly dynamic=20 >> environment... >>=20 >>> (WLAN is good at squeezing various small packets but really not good = >>> at big things especially in broadcast mode)...a better strategy=20 >>> would be to define new messages tailored to the information needs,=20 >>> and have smart service scheduling...(especially benefiting from=20 >>> IP-related mechanisms) >>=20 >>> I fully agree with this. >>=20 >> :-) at least we do on this :-) >>=20 >> Cheers, >>=20 >> J=C3=A9r=C3=B4me >>=20 >> _______________________________________________ its mailing list=20 >> its@ietf.org https://www.ietf.org/mailman/listinfo/its >>=20 >>=20 >=20 >=20 From nobody Mon Feb 26 12:38:44 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E80D812D82F for ; Mon, 26 Feb 2018 12:38:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 h1J6a3cp_4Cr for ; Mon, 26 Feb 2018 12:38:39 -0800 (PST) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5F7C12D864 for ; Mon, 26 Feb 2018 12:38:38 -0800 (PST) Received: by mail-qt0-x235.google.com with SMTP id d26so20429381qtk.10 for ; Mon, 26 Feb 2018 12:38:38 -0800 (PST) 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:thread-index:content-language; bh=C8jJjSEqPxE8jALLFhu4nft3fWHSqYk99nBSC3Wpixc=; b=kk1jq22Ejp8nuZ2BBGA71a7H0fq3CskJLP19LUjM8b0KzZqy3whjkbhRomsSJf/dv2 6KGpLNrtwXZw7a/CiMvP1VHanLDzIfoibV/iKH/7hm/dCiaAi6bgIUNe09vT5X5AKiCR NttcEPjtLfPnulDLodl4H+hRMlI5vd52sMU7LKK+I/tZIouP5mAwtGErf1QkLtIAN7Q3 QjqHJZ/SAYeMwBZfpnAXpJmXfm0oGdTi1SDrhGrubM9mRPe8YxxfCKMGi4SRTxpvrwCr 3hZrwz4cB7Zq6pQd2NZ6I0Iun3j42Rbl3czpQFdyl0PiQM2D70EuJywrzUQvuzfRnay7 i8ig== 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:thread-index:content-language; bh=C8jJjSEqPxE8jALLFhu4nft3fWHSqYk99nBSC3Wpixc=; b=lWumALSLwEXa0Gf/PlFYJXTJgog0E8St+KaECalmZznWy9EAGpGhJY4Cn/zbFcihkX I1rLWM+Av9dL1VjVTagpF04VyXBt1F/ahAGCvAik/3KMgJ2oL4rOIB2ZZLy0My55Tr30 BHqiSNhCi8i3crmlN+YRGertQiNdq9kx8oKl30tG2CiMe7Ymsh+LEBxq+HCUiPrzwtrU jyrUkFZ8KcJ9741b4GQU1rMJjL7BuFXtG+6dtlRAqo9EiWbg6SoBohiX+VaFZPWr/u3C B+YXUX5WrgftwU1+kWraiUYY+QPJEF+XvoMo+sZbRur0SXZDLLLzKKDLb/0dfAJmHaOM v6rQ== X-Gm-Message-State: APf1xPAFzkP/lgBJfa+rF8zI9NWqmZrfePHmQrOrbRC56qzY+o7D2xkZ PM23ZPIaUK0gLNrNzD8VXpE= X-Google-Smtp-Source: AG47ELuEk5HVVGpiNrqryVgGNIJZwu4Gjn+xnQMW/ghTEnIglMZtBcdINtqMX/veLocEiaMqtW9Yrw== X-Received: by 10.200.5.136 with SMTP id a8mr19022057qth.110.1519677517865; Mon, 26 Feb 2018 12:38:37 -0800 (PST) Received: from FrancoisPC (pool-108-48-182-86.washdc.fios.verizon.net. [108.48.182.86]) by smtp.gmail.com with ESMTPSA id h190sm5970913qka.10.2018.02.26.12.38.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Feb 2018 12:38:36 -0800 (PST) From: =?utf-8?Q?Fran=C3=A7ois_Simon?= To: =?utf-8?B?J0rDqXLDtG1lIEjDpHJyaSc=?= , "'Alexandre Petrescu'" , Cc: References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <006301d3ace3$25f9d500$71ed7f00$@eurecom.fr> <007901d3aee3$a9985ba0$fcc912e0$@eurecom.fr> <00da01d3aef6$574c4380$05e4ca80$@eurecom.fr> In-Reply-To: <00da01d3aef6$574c4380$05e4ca80$@eurecom.fr> Date: Mon, 26 Feb 2018 15:38:35 -0500 Message-ID: <003a01d3af41$c6674cb0$5335e610$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003B_01D3AF17.DD9626B0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHelLAw/aN7IRfcwiTBG/gKcgHVEwGONDnFAivYBTcBDgW0eQFK9evKAbex+qQB/uwIKqNS+0LA Content-Language: en-us Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 26 Feb 2018 20:38:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_003B_01D3AF17.DD9626B0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable QoS Data combinations for OCB: AC_VO: AIFN=3D2, CWmin=3D4 CWmax=3D8 AC_VI: AIFN=3D3, CWmin=3D8 CWmax=3D16 AC_BE: AIFN=3D6, CWmin=3D16 CWmax=3D1024 AC_BK: AIFN=3D9, CWmin=3D16 CWmax=3D1024 I am not sure where these values come from: AIFSN: The values assigned for each AC are the DEFAULT values. Those = values may not fit all applications. This attribute specifies the = number of slots, after a SIFS, that the STA, for a particular AC, senses the medium idle either before transmitting = or executing a backoff. The value is (2..15); CWmin: The minimum contention window size is defined by the aCWmin = value. This attribute specifies the value of the minimum size of the = window that is used by a STA for a particular AC for generating a random = number for the backoff. It is calculated by 2x =E2=80=93 1 where x is = an integer. aCWmin is 0..255 CWmax: The maximum contention window size is defined by aCWmax. The = aCWmax is 0..65535 The defaults for CWmin and CWmax are specified in IEEE 802.11-2016, = Clause 9.4.2.29 EDCA Parameter Set element. -----Original Message----- From: its [mailto:its-bounces@ietf.org] On Behalf Of J=C3=A9r=C3=B4me = H=C3=A4rri Sent: Monday, February 26, 2018 6:39 AM To: 'Alexandre Petrescu' ; its@ietf.org Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in = IPv6-over-802.11-OCB Hi Alex, All, After double checking IEEE802.11-2016, here are two aspects I need to = correct (sorry for my mistake)L: 1) both data and QoSData are allowed when Dot11OCBActivated=3Dtrue; 2) EDCA parameters were wrong ( I wrongly used the nonOCB ones) QoS Data combinations for OCB: AC_VO: AIFN=3D2, CWmin=3D4 CWmax=3D8 AC_VI: AIFN=3D3, CWmin=3D8 CWmax=3D16 AC_BE: AIFN=3D6, CWmin=3D16 CWmax=3D1024 AC_BK: AIFN=3D9, CWmin=3D16 CWmax=3D1024 Both Data and QoSData are theoretically possible, so indeed the draft = should cover this aspect.=20 Yet, I still suggest to keep QoS for IPv6, again as even if it does not = bring much 'now' for IPv6, it does not cost much either...and we should = not forgot that we might interact with EDCA transmissions (QoS) and as = such could create harmful interference on the DSRC/ITS-G5 channels. BR, J=C3=A9r=C3=B4me -----Original Message----- From: its [mailto:its-bounces@ietf.org] On Behalf Of J=C3=A9r=C3=B4me = H=C3=A4rri Sent: Monday 26 February 2018 10:25 To: 'Alexandre Petrescu'; its@ietf.org =20 Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in = IPv6-over-802.11-OCB Hi Alex, > That is a requirement. > > But is there an implementation of mapping the priority of CAM over = DENM into a QoS Control field in QoS Data Header? > > I doubt there is, because the implementations of CAM I see put the = Priority field to 6, which means Voice. So they transmit CAM as Voice = even though it is not voice. > > We can not reckon in IPv6-over-OCB document something which makes = little sense (send CAM as Voice). Of course there is....the QoS fields actually means the Access = Categories (AC) for WLAN, so EDCA. Both in ETSI and in WAVE they use the = QoS Control filed of IEE 802.11p to send CAM/BSM with higher priority = (from a MAC perspective)...When looking at the EDCA 'naming' you should = not care much of the 'name'...this was done at the time internet was = only composed of voice, video etc..you should look at the underlying = values of each AC. So, EDCA is composed of two fields: 1) AIFN - a deterministic idle time before even considering reducing CW 2) CW - a random timer to decrease each time the channel is idle.=20 QoS Data combinations for OCB: AC_VO: AIFN=3D2, CW=3D8 AC_VI: AIFN=3D2, CW=3D16 AC_BE: AIFN=3D3, CW=3D32 AC_BK: AIFN=3D7, CW=3D32 So, it does not matter the name (Voice, video)..what matters is that in = implementation (BSM for instance), AIFN=3D2 so that it takes the fastest = access (deterministic) and as such has the highest priority. This is = also what you found: CAM on Priority field 6, so AC_VI so AIFN=3D2. BSM = uses the same strategy.=20 Now, on the CAR 2 CAR specification, it is recommended a different = priority: AC_BE, as it uses DP2. The reason behind this is the CAR2CAR = provides a 'strict' prioritization between DENMs and CAMs. Emergency = DENMs uses AC_VI, normal DENM uses AC_VO, CAM uses AC_BE and any other = traffic AC_BK. So, bottom line is: all ETSI and WAVE implementation use the QoS Data = field as they use EDCA. If you found an implementation that does not use = the QoS, it is wrong according to the standard. >> Now, as you abstract ETSI and WAVE (thus pure IP), my understanding=20 >> is that QoS remains required from the IEEE 802.11p (ok, IEEE >> 802.11-2016 OCB) as there is a specification of the EDCA parameters=20 >> for OCB. Besides, I do not think it costs much to keep the EDCA in,=20 >> as it first allows to safe a half of the MAC queueing time (the EDCA=20 >> parameters for the two low AC are less, up to a quarter of a=20 >> DIFS...so, it could be beneficial to allow this even for IP. Second,=20 >> the EDCA allows TXOpps (Transmit Opportunities)..although put to=20 >> 'zero' for OCB (I think), this mechanism still allows an AP to=20 >> reserve a given time a long(er) connectivity with one device (e. >> streaming of video etc..). Finally, it does not cost anything..you=20 >> can always take the lowest AC and you get the same behavior as = non-QoS.. >Well, this text is more informal in nature. It is something that >describes a potential behaviour but we have no proof of existing such = behaviour, no proof of interoperability. This could be part of an = INFORMATIONAL Internet Draft. Well, my text is informal, but the specs are not. IEEE 802.11p (IEEE = 802.11-2016 OCB) uses EDCA not DCF...as this is L2 layer, I do not think = anything is required from IETF...just follow the IEEE 802.11-2016 specs = and do whatever is allows above it...I will double check again on the = IEEE 802.11-2016, but if what I think is confirmed, the whole discussion = does not make any sense..., as it is my understanding that the OCB = requires EDCA, so QoS_Data...so, you cannot change that at IP level. >> Bottom line, the fact that some IP implementation to decode OCB=20 >> assume non-QoS frames looks more to me like an implementation error=20 >> and we should not propagate this... >Well, wireshark has problems interpreting 802.11 QoS Data containing = CAM messages. Many receivers of QoS Data dont know what to do with the = fields because they are not agreed. Yes, and this is why is the prototype we use, we actually have an parser = for CAM to be supported by Wireshark...it does not come by default. But = I am surprised..what kind of problem would wireshark face with the QoS = Data?=20 > I don't want to propagate that disagreement into the IP-over-OCB = draft. To me, this looks more like an implementation issue, rather than a = standard issue...but I will ask my team to check on our prototype... >> C-V2X will not use IP for CAM, >LTE-V2X will carry CAM in IP. What is C-V2X and why does not it use = IP? Sorry, it will not. In C-V2X (the widely known name...LTE-V2X is again a = bit like 802.11p...'LTE Prose for V2X' is the real name...), mode 4 = (ad-hoc mode..currently chosen by all vendors (except maybe Huawei, but = might have changed), there is two options for protocol stack: IPv6 = (again, only IPv6) and non-IP (L2)...you can use non-IP packets and it = is so mentioned that BSM and CAM will use the non-IP option, as it is = also required to use the ETSI/WAVE security provisions to secure the = C-V2X mode 4 (as no SIM=3D no security), as the ETSI/WAVE security = provisions works for non-IP packets (geonet or WSM)... Of course, it does not block from using IP...it is again the same = discussion we had with ITS-G5/DSRC...for safety communication, IP is not = required...you can do everything without and faster. And considering = that IEEE 802.11p (ok, OCB) and C-V2X mode 4 (no SIM=3Dno SEC) DO NOT = have any form of security mechanism embedded, they must use the those = specified by ETSI/WAVE for accessing CCH. Again, C-V2X mode 4 (the current V2X techno for Safety-critical = communication) shall not be seen as following the same path as other = cellular techno. It does not provide QoS (at all), as it channel access = is contention-based (a bit like CSMA)...so collisions will occur (unlike = 4G and 5G operated, where you are either dropped or you pass). And as = such, IP is also not required, even if all 4G and 5G use IP. >> ETSI and WAVE will not use IP for CAM... >That is their problem. Disagree: you need to be compatible with them...so, whatever IETF will = do shall not break anything that has been done on ETSI or WAVE. This is = one of the requirement for accessing the ITS-G5 spectrum in EU, and I = believe the same in the US. >ETSI transports IP over GeoNetworking - that is not the right way to do = it. Disagree: we need to integrate security mechanisms specified by ETSI = even if we use IPv6. Today, we do not have any security specification = providing 'trust', privacy and authentication for using 802.11-OCB (I = believe it is the work of IPWAVE and it is not completed yet...).=20 The mistake ETSI did is to try to be nice with IETF and help them to = provide a way to use IPv6 over ITS-G5 in a secured way...WAVE took a = different path: 'not my problem', which then explain why ETSI officially = does not endorse IPWAVE (unfortunately, despite my many discussions with = them)...from an ETSI perspective, using IPv6 over ITS-G5 is = solved...(might be ugly, but it is solved). =20 >> the basic CAMs are used for pure positioning >The mandatory fields in CAM or more than just lat/long/altitude. There = is also mandatory time in a strange format, car dimensions, curve, non = standard precisions and more. Yes, correct...but these are configurable fields, which may or may not = be integrated...recent studies even showed that even the standard CAM = size is not clear anymore..you have a 'range' of size, and that is a = problem for wireless optimization...especially if you need to do = wireless congestion control. >> and the recent 'increase' of information put in CAM >If CAM worries about size, I think CAM should think about its existing = redundancy. For example, position is carried twice in a CAM message: in = the CAM itself and in the GeoNetworking header. That >is an issue they = should address first. Well, of course, this is a waste...but one reason for such existence is = from the possibility to relay a packet (agnostic from the upper = messages, unfortunately, we cannot use a Zero-NET for CAM as it is pure = 1-hop TSB)... Yet, today we start seeing even BSM investigating ways to do multi-hop = 'position' based relaying to reach longer distance.=20 And if you think about it, one day, your IPv6-over-OCB might need to use = a multi-hop networking protocol (e.g. MANET)..but doing the MANET way is = highly mobile environment will not be that efficient...position-based = mechanisms will be required (proven in various previous studies)...now, = your L3 will not be able to inspect the GPS position of your = CAM-over-IP...so, you will need to have GPS (or so) position at IP/L3, = which will end up being similar than now... If you do not want to do this, then the IRTF people might come with ICN, = but then would this be done above L3 or at L3...if still at L3, you = still will have a contextual L3 packet that might be redundant with = application/service layer messages...(the cost of using OSI) But this is just my personal view and very long term...for now, if we = only look at CAM, indeed we can have twice the GPS position (but wait: = not the same granularity and you do not have elevation in geonet). But = if you look at the bigger picture: doing CAM-over-geonet only required = a single CAM, that's it. For IPv6-over-OCB, you need all the IPv6 = address autoconfiguration..that requires additional IPv6 packets to be = transmitted...this is similar to compare an apple with a tomato. =20 >> looks to be like a bad strategy as we end up having a container=20 >> carrying too many things and being too big for what it is... >I agree. But I think we should compare header sizes and then there = will be surprises. >CAM transported in IP may be a smaller packet than CAM transported in = BTP and GeoNetworking. Not that much if you counts also all IPv6-related control/management = packets required to transmit your CAM-over-OCB, in a highly dynamic = environment... > (WLAN is good at squeezing various small packets but really not good=20 > at big things especially in broadcast mode)...a better strategy would=20 > be to define new messages tailored to the information needs, and have=20 > smart service scheduling...(especially benefiting from IP-related > mechanisms) > I fully agree with this. :-) at least we do on this :-) Cheers, J=C3=A9r=C3=B4me _______________________________________________ its mailing list its@ietf.org =20 https://www.ietf.org/mailman/listinfo/its _______________________________________________ its mailing list its@ietf.org =20 https://www.ietf.org/mailman/listinfo/its ------=_NextPart_000_003B_01D3AF17.DD9626B0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable RE: [ipwave] 802.11 Data vs 802.11 QoS Data in = IPv6-over-802.11-OCB

QoS Data = combinations for OCB:

AC_VO: = AIFN=3D2, CWmin=3D4 CWmax=3D8

AC_VI: = AIFN=3D3, CWmin=3D8 CWmax=3D16

AC_BE: = AIFN=3D6, CWmin=3D16 CWmax=3D1024

AC_BK: = AIFN=3D9, CWmin=3D16 CWmax=3D1024

I am not sure = where these values come from:

AIFSN: The values assigned for each AC are the DEFAULT values. Those = values may not = fit all applications.  This attribute specifies the number of slots, after a = SIFS, that the STA,

for a = particular AC, senses the medium idle either before transmitting = or executing a backoff.  The value = is (2..15);

CWmin: The minimum contention window size is defined by the aCWmin = value. This attribute specifies the value of the minimum size = of the window that is used by a STA for a particular AC for generating a = random number for the backoff.  It is calculated by 2x =E2=80=93 1 where x is an = integer. aCWmin is 0..255

CWmax: The = maximum contention window size is defined by aCWmax.  The aCWmax = is  0..65535

The defaults = for CWmin and = CWmax are specified in IEEE 802.11-2016, Clause  = 9.4.2.29 EDCA Parameter Set = element.

-----Original = Message-----
From: its [mailto:its-bounces@ietf.org] On = Behalf Of J=C3=A9r=C3=B4me H=C3=A4rri
Sent: Monday, February 26, 2018 6:39 AM
To: 'Alexandre Petrescu' <alexandre.petrescu@gmail.com>; = its@ietf.org
Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in = IPv6-over-802.11-OCB

Hi Alex, = All,

After double = checking IEEE802.11-2016, here are two aspects I need to correct (sorry = for my mistake)L:

1) both data = and QoSData are allowed when Dot11OCBActivated=3Dtrue;

2) EDCA = parameters were wrong ( I wrongly used the nonOCB = ones)

QoS Data = combinations for OCB:

AC_VO: = AIFN=3D2, CWmin=3D4 CWmax=3D8

AC_VI: = AIFN=3D3, CWmin=3D8 CWmax=3D16

AC_BE: = AIFN=3D6, CWmin=3D16 CWmax=3D1024

AC_BK: = AIFN=3D9, CWmin=3D16 CWmax=3D1024

Both Data and = QoSData are theoretically possible, so indeed the draft should cover = this aspect.

Yet, I still = suggest to keep QoS for IPv6, again as even if it does not bring much = 'now' for IPv6, it does not cost much either...and we should not forgot = that we might interact with EDCA transmissions (QoS) and as such could = create harmful interference on the DSRC/ITS-G5 = channels.

BR,

J=C3=A9r=C3=B4me

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

From: its = [mailto:its-bounces@ietf.org] = On Behalf Of J=C3=A9r=C3=B4me H=C3=A4rri

Sent: Monday 26 = February 2018 10:25

To: 'Alexandre = Petrescu'; its@ietf.org

Subject: Re: = [ipwave] 802.11 Data vs 802.11 QoS Data in = IPv6-over-802.11-OCB

Hi = Alex,

> That is a = requirement.

>

> But is = there an implementation of mapping the priority of CAM over DENM into a = QoS Control field in QoS Data Header?

>

> I doubt = there is, because the implementations of CAM I see put the Priority = field to 6, which means Voice.  So they transmit CAM as Voice even = though it is not voice.

>

> We can not = reckon in IPv6-over-OCB document something which makes little sense = (send CAM as Voice).

Of course there = is....the QoS fields actually means the Access Categories (AC) for WLAN, = so EDCA. Both in ETSI and in WAVE they use the QoS Control filed of IEE = 802.11p to send CAM/BSM with higher priority (from a MAC = perspective)...When looking at the EDCA 'naming' you should not care = much of the 'name'...this was done at the time internet was only = composed of voice, video etc..you should look at the underlying values = of each AC.

So, EDCA is = composed of two fields:

1) AIFN - a = deterministic idle time before even considering reducing = CW

2) CW - a = random timer to decrease each time the channel is idle. =

QoS Data = combinations for OCB:

AC_VO: = AIFN=3D2, CW=3D8

AC_VI: = AIFN=3D2, CW=3D16

AC_BE: = AIFN=3D3, CW=3D32

AC_BK: = AIFN=3D7, CW=3D32

So, it does not = matter the name (Voice, video)..what matters is that in implementation = (BSM for instance), AIFN=3D2 so that it takes the fastest access = (deterministic) and as such has the highest priority. This is also what = you found: CAM on Priority field 6, so AC_VI so AIFN=3D2. BSM uses the = same strategy.

Now, on the CAR = 2 CAR specification, it is recommended a different priority: AC_BE, as = it uses DP2. The reason behind this is the CAR2CAR provides a 'strict' = prioritization between DENMs and CAMs. Emergency DENMs uses AC_VI, = normal DENM uses AC_VO, CAM uses AC_BE and any other traffic = AC_BK.

So, bottom line = is: all ETSI and WAVE implementation use the QoS Data field as they use = EDCA. If you found an implementation that does not use the QoS, it is = wrong according to the standard.

>> Now, = as you abstract ETSI and WAVE (thus pure IP), my understanding =

>> is = that QoS remains required from the IEEE 802.11p (ok, = IEEE

>> = 802.11-2016 OCB) as there is a specification of the EDCA parameters =

>> for = OCB. Besides, I do not think it costs much to keep the EDCA in, =

>> as it = first allows to safe a half of the MAC queueing time (the EDCA =

>> = parameters for the two low AC are less, up to a quarter of a =

>> = DIFS...so, it could be beneficial to allow this even for IP. Second, =

>> the = EDCA allows TXOpps (Transmit Opportunities)..although put to =

>> 'zero' = for OCB (I think), this mechanism still allows an AP to =

>> = reserve a given time a long(er) connectivity with one device = (e.

>> = streaming of video etc..). Finally, it does not cost anything..you =

>> can = always take the lowest AC and you get the same behavior as = non-QoS..

>Well, this = text is more informal in nature.   It is something = that

>describes a = potential behaviour but we have no proof of existing such behaviour, no = proof of interoperability.  This could be part of an INFORMATIONAL = Internet Draft.

Well, my text = is informal, but the specs are not. IEEE 802.11p (IEEE 802.11-2016 OCB) = uses EDCA not DCF...as this is L2 layer, I do not think anything is = required from IETF...just follow the IEEE 802.11-2016 specs and do = whatever is allows above it...I will double check again on the IEEE = 802.11-2016, but if what I think is confirmed, the whole discussion does = not make any sense..., as it is my understanding that the OCB requires = EDCA, so QoS_Data...so, you cannot change that at IP = level.


>> Bottom = line, the fact that some IP implementation to decode OCB =

>> assume = non-QoS frames looks more to me like an implementation error =

>> and we = should not propagate this...

>Well, = wireshark has problems interpreting 802.11 QoS Data containing CAM = messages.  Many receivers of QoS Data dont know what to do with the = fields because they are not agreed.

Yes, and this = is why is the prototype we use, we actually have an parser for CAM to be = supported by Wireshark...it does not come by default. But I am = surprised..what kind of problem would wireshark face with the QoS Data? =


> I don't = want to propagate that disagreement into the IP-over-OCB = draft.

To me, this = looks more like an implementation issue, rather than a standard = issue...but I will ask my team to check on our = prototype...

>> C-V2X = will not use IP for CAM,

>LTE-V2X = will carry CAM in IP.  What is C-V2X and why does not it use = IP?

Sorry, it will = not. In C-V2X (the widely known name...LTE-V2X is again a bit like = 802.11p...'LTE Prose for V2X' is the real name...), mode 4 (ad-hoc = mode..currently chosen by all vendors (except maybe Huawei, but might = have changed), there is two options for protocol stack: IPv6 (again, = only IPv6) and non-IP (L2)...you can use non-IP packets and it is so = mentioned that BSM and CAM will use the non-IP option, as it is also = required to use the ETSI/WAVE security provisions to secure the C-V2X = mode 4 (as no SIM=3D no security), as the ETSI/WAVE security provisions = works for non-IP packets (geonet or WSM)...

Of course, it = does not block from using IP...it is again the same discussion we had = with ITS-G5/DSRC...for safety communication, IP is not required...you = can do everything without and faster. And considering that IEEE 802.11p = (ok, OCB) and C-V2X mode 4 (no SIM=3Dno SEC) DO NOT have any form of = security mechanism embedded, they must use the those specified by = ETSI/WAVE for accessing CCH.

Again, C-V2X = mode 4 (the current V2X techno for Safety-critical communication) shall = not be seen as following the same path as other cellular techno. It does = not provide QoS (at all), as it channel access is contention-based (a = bit like CSMA)...so collisions will occur (unlike 4G and 5G operated, = where you are either dropped or you pass). And as such, IP is also not = required, even if all 4G and 5G use IP.


>> ETSI = and WAVE will not use IP for CAM...

>That is = their problem.

Disagree: you = need to be compatible with them...so, whatever IETF will do shall not = break anything that has been done on ETSI or WAVE. This is one of the = requirement for accessing the ITS-G5 spectrum in EU, and I believe the = same in the US.

>ETSI = transports IP over GeoNetworking - that is not the right way to do = it.

Disagree: we = need to integrate security mechanisms specified by ETSI even if we use = IPv6. Today, we do not have any security specification providing = 'trust', privacy and authentication for using 802.11-OCB (I believe it = is the work of IPWAVE and it is not completed yet...). =

The mistake = ETSI did is to try to be nice with IETF and help them to provide a way = to use IPv6 over ITS-G5 in a secured way...WAVE took a different path: = 'not my problem', which then explain why ETSI officially does not = endorse IPWAVE (unfortunately, despite my many discussions with = them)...from an ETSI perspective, using IPv6 over ITS-G5 is = solved...(might be ugly, but it is solved).

  =

>> the = basic CAMs are used for pure positioning

>The = mandatory fields in CAM or more than just lat/long/altitude.  There = is also mandatory time in a strange format, car dimensions, curve, non = standard precisions and more.

Yes, = correct...but these are configurable fields, which may or may not be = integrated...recent studies even showed that even the standard CAM size = is not clear anymore..you have a 'range' of size, and that is a problem = for wireless optimization...especially if you need to do wireless = congestion control.

>> and = the recent 'increase' of information put in CAM

>If CAM = worries about size, I think CAM should think about its existing = redundancy.  For example, position is carried twice in a CAM = message: in the CAM itself and in the GeoNetworking header.  That = >is an issue they should address first.

Well, of = course, this is a waste...but one reason for such existence is from the = possibility to relay a packet (agnostic from the upper messages, = unfortunately, we cannot use a Zero-NET for CAM as it is pure 1-hop = TSB)...

Yet, today we = start seeing even BSM investigating ways to do multi-hop 'position' = based relaying to reach longer distance.

And if you = think about it, one day, your IPv6-over-OCB might need to use a = multi-hop networking protocol (e.g. MANET)..but doing the MANET way is = highly mobile environment will not be that efficient...position-based = mechanisms will be required (proven in various previous studies)...now, = your L3 will not be able to inspect the GPS position of your = CAM-over-IP...so, you will need to have GPS (or so) position at IP/L3, = which will end up being similar than now...

If you do not = want to do this, then the IRTF people might come with ICN, but then = would this be done above L3 or at L3...if still at L3, you still will = have a contextual L3 packet that might be redundant with = application/service layer messages...(the cost of using = OSI)

But this is = just my personal view and very long term...for now, if we only look at = CAM, indeed we can have twice the GPS position (but wait: not the same = granularity and you do not have elevation in geonet). But if you look = at  the bigger picture: doing CAM-over-geonet only required a = single CAM, that's it. For IPv6-over-OCB, you need all the IPv6 address = autoconfiguration..that requires additional IPv6 packets to be = transmitted...this is similar to compare an apple with a = tomato.

 

>> looks = to be like a bad strategy as we end up having a container =

>> = carrying too many things and being too big for what it = is...

>I = agree.  But I think we should compare header sizes and then there = will be surprises.

>CAM = transported in IP may be a smaller packet than CAM transported in BTP = and GeoNetworking.

Not that much = if you counts also all IPv6-related control/management packets required = to transmit your CAM-over-OCB, in a highly dynamic = environment...

> (WLAN is = good at squeezing various small packets but really not good =

> at big = things especially in broadcast mode)...a better strategy would =

> be to = define new messages tailored to the information needs, and have =

> smart = service scheduling...(especially benefiting from = IP-related

> = mechanisms)

> I fully = agree with this.

:-) at least we = do on this :-)

Cheers,

J=C3=A9r=C3=B4me

_______________________________________________

its mailing = list

its@ietf.org

https://www.ietf.org/mailman/listinfo/its<= SPAN LANG=3D"en-us">

_______________________________________________

its mailing = list

its@ietf.org

https://www.ietf.org/mailman/listinfo/its<= SPAN LANG=3D"en-us">

------=_NextPart_000_003B_01D3AF17.DD9626B0-- From nobody Mon Feb 26 12:46:10 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B24512D864 for ; Mon, 26 Feb 2018 12:46:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LP_5L4NKbElw for ; Mon, 26 Feb 2018 12:46:03 -0800 (PST) Received: from smtp2.eurecom.fr (smtp2.eurecom.fr [193.55.113.211]) by ietfa.amsl.com (Postfix) with ESMTP id 94F11127601 for ; Mon, 26 Feb 2018 12:46:02 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.47,397,1515452400"; d="scan'208,217";a="7702743" Received: from monza.eurecom.fr ([192.168.106.15]) by drago2i.eurecom.fr with ESMTP; 26 Feb 2018 21:46:01 +0100 Received: from xerus29 (unknown [192.168.200.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by monza.eurecom.fr (Postfix) with ESMTPSA id 278466AA; Mon, 26 Feb 2018 21:46:01 +0100 (CET) From: =?utf-8?B?SsOpcsO0bWUgSMOkcnJp?= To: =?utf-8?Q?'Fran=C3=A7ois_Simon'?= , "'Alexandre Petrescu'" , References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <006301d3ace3$25f9d500$71ed7f00$@eurecom.fr> <007901d3aee3$a9985ba0$fcc912e0$@eurecom.fr> <00da01d3aef6$574c4380$05e4ca80$@eurecom.fr> <003a01d3af41$c6674cb0$5335e610$@gmail.com> In-Reply-To: <003a01d3af41$c6674cb0$5335e610$@gmail.com> Date: Mon, 26 Feb 2018 21:46:00 +0100 Organization: EURECOM Message-ID: <008a01d3af42$cfcdcdf0$6f6969d0$@eurecom.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008B_01D3AF4B.319DF5C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHelLAw/aN7IRfcwiTBG/gKcgHVEwGONDnFAivYBTcBDgW0eQFK9evKAbex+qQB/uwIKgGoV/jvo0XLPzA= Content-Language: en-us Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 26 Feb 2018 20:46:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_008B_01D3AF4B.319DF5C0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Fran=C3=A7ois, =20 They come from IEEE 802.11-2016, section p.899, section , 9.4.2.29 EDCA = Parameter Set element, Table 9-138=E2=80=94Default EDCA parameter set = for STA operation if dot11OCBActivated is true =20 BR, =20 J=C3=A9r=C3=B4me =20 From: Fran=C3=A7ois Simon [mailto:fygsimon@gmail.com]=20 Sent: Monday 26 February 2018 21:39 To: 'J=C3=A9r=C3=B4me H=C3=A4rri'; 'Alexandre Petrescu'; its@ietf.org Cc: fygsimon@gmail.com Subject: RE: [ipwave] 802.11 Data vs 802.11 QoS Data in = IPv6-over-802.11-OCB =20 QoS Data combinations for OCB: AC_VO: AIFN=3D2, CWmin=3D4 CWmax=3D8 AC_VI: AIFN=3D3, CWmin=3D8 CWmax=3D16 AC_BE: AIFN=3D6, CWmin=3D16 CWmax=3D1024 AC_BK: AIFN=3D9, CWmin=3D16 CWmax=3D1024 I am not sure where these values come from: AIFSN: The values assigned for each AC are the DEFAULT values. Those = values may not fit all applications. This attribute specifies the = number of slots, after a SIFS, that the STA, for a particular AC, senses the medium idle either before transmitting = or executing a backoff. The value is (2..15); CWmin: The minimum contention window size is defined by the aCWmin = value. This attribute specifies the value of the minimum size of the = window that is used by a STA for a particular AC for generating a random = number for the backoff. It is calculated by 2x =E2=80=93 1 where x is = an integer. aCWmin is 0..255 CWmax: The maximum contention window size is defined by aCWmax. The = aCWmax is 0..65535 The defaults for CWmin and CWmax are specified in IEEE 802.11-2016, = Clause 9.4.2.29 EDCA Parameter Set element. -----Original Message----- From: its [mailto:its-bounces@ietf.org] On Behalf Of J=C3=A9r=C3=B4me = H=C3=A4rri Sent: Monday, February 26, 2018 6:39 AM To: 'Alexandre Petrescu' ; its@ietf.org Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in = IPv6-over-802.11-OCB Hi Alex, All, After double checking IEEE802.11-2016, here are two aspects I need to = correct (sorry for my mistake)L: 1) both data and QoSData are allowed when Dot11OCBActivated=3Dtrue; 2) EDCA parameters were wrong ( I wrongly used the nonOCB ones) QoS Data combinations for OCB: AC_VO: AIFN=3D2, CWmin=3D4 CWmax=3D8 AC_VI: AIFN=3D3, CWmin=3D8 CWmax=3D16 AC_BE: AIFN=3D6, CWmin=3D16 CWmax=3D1024 AC_BK: AIFN=3D9, CWmin=3D16 CWmax=3D1024 Both Data and QoSData are theoretically possible, so indeed the draft = should cover this aspect.=20 Yet, I still suggest to keep QoS for IPv6, again as even if it does not = bring much 'now' for IPv6, it does not cost much either...and we should = not forgot that we might interact with EDCA transmissions (QoS) and as = such could create harmful interference on the DSRC/ITS-G5 channels. BR, J=C3=A9r=C3=B4me -----Original Message----- From: its [ mailto:its-bounces@ietf.org] = On Behalf Of J=C3=A9r=C3=B4me H=C3=A4rri Sent: Monday 26 February 2018 10:25 To: 'Alexandre Petrescu'; its@ietf.org Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in = IPv6-over-802.11-OCB Hi Alex, > That is a requirement. >=20 > But is there an implementation of mapping the priority of CAM over = DENM into a QoS Control field in QoS Data Header? >=20 > I doubt there is, because the implementations of CAM I see put the = Priority field to 6, which means Voice. So they transmit CAM as Voice = even though it is not voice. >=20 > We can not reckon in IPv6-over-OCB document something which makes = little sense (send CAM as Voice). Of course there is....the QoS fields actually means the Access = Categories (AC) for WLAN, so EDCA. Both in ETSI and in WAVE they use the = QoS Control filed of IEE 802.11p to send CAM/BSM with higher priority = (from a MAC perspective)...When looking at the EDCA 'naming' you should = not care much of the 'name'...this was done at the time internet was = only composed of voice, video etc..you should look at the underlying = values of each AC. So, EDCA is composed of two fields: 1) AIFN - a deterministic idle time before even considering reducing CW 2) CW - a random timer to decrease each time the channel is idle.=20 QoS Data combinations for OCB: AC_VO: AIFN=3D2, CW=3D8 AC_VI: AIFN=3D2, CW=3D16 AC_BE: AIFN=3D3, CW=3D32 AC_BK: AIFN=3D7, CW=3D32 So, it does not matter the name (Voice, video)..what matters is that in = implementation (BSM for instance), AIFN=3D2 so that it takes the fastest = access (deterministic) and as such has the highest priority. This is = also what you found: CAM on Priority field 6, so AC_VI so AIFN=3D2. BSM = uses the same strategy.=20 Now, on the CAR 2 CAR specification, it is recommended a different = priority: AC_BE, as it uses DP2. The reason behind this is the CAR2CAR = provides a 'strict' prioritization between DENMs and CAMs. Emergency = DENMs uses AC_VI, normal DENM uses AC_VO, CAM uses AC_BE and any other = traffic AC_BK. So, bottom line is: all ETSI and WAVE implementation use the QoS Data = field as they use EDCA. If you found an implementation that does not use = the QoS, it is wrong according to the standard. >> Now, as you abstract ETSI and WAVE (thus pure IP), my understanding=20 >> is that QoS remains required from the IEEE 802.11p (ok, IEEE >> 802.11-2016 OCB) as there is a specification of the EDCA parameters=20 >> for OCB. Besides, I do not think it costs much to keep the EDCA in,=20 >> as it first allows to safe a half of the MAC queueing time (the EDCA=20 >> parameters for the two low AC are less, up to a quarter of a=20 >> DIFS...so, it could be beneficial to allow this even for IP. Second,=20 >> the EDCA allows TXOpps (Transmit Opportunities)..although put to=20 >> 'zero' for OCB (I think), this mechanism still allows an AP to=20 >> reserve a given time a long(er) connectivity with one device (e. >> streaming of video etc..). Finally, it does not cost anything..you=20 >> can always take the lowest AC and you get the same behavior as = non-QoS.. >Well, this text is more informal in nature. It is something that >describes a potential behaviour but we have no proof of existing such = behaviour, no proof of interoperability. This could be part of an = INFORMATIONAL Internet Draft. Well, my text is informal, but the specs are not. IEEE 802.11p (IEEE = 802.11-2016 OCB) uses EDCA not DCF...as this is L2 layer, I do not think = anything is required from IETF...just follow the IEEE 802.11-2016 specs = and do whatever is allows above it...I will double check again on the = IEEE 802.11-2016, but if what I think is confirmed, the whole discussion = does not make any sense..., as it is my understanding that the OCB = requires EDCA, so QoS_Data...so, you cannot change that at IP level. =20 >> Bottom line, the fact that some IP implementation to decode OCB=20 >> assume non-QoS frames looks more to me like an implementation error=20 >> and we should not propagate this... >Well, wireshark has problems interpreting 802.11 QoS Data containing = CAM messages. Many receivers of QoS Data dont know what to do with the = fields because they are not agreed. Yes, and this is why is the prototype we use, we actually have an parser = for CAM to be supported by Wireshark...it does not come by default. But = I am surprised..what kind of problem would wireshark face with the QoS = Data?=20 =20 > I don't want to propagate that disagreement into the IP-over-OCB = draft. To me, this looks more like an implementation issue, rather than a = standard issue...but I will ask my team to check on our prototype... >> C-V2X will not use IP for CAM, >LTE-V2X will carry CAM in IP. What is C-V2X and why does not it use = IP? Sorry, it will not. In C-V2X (the widely known name...LTE-V2X is again a = bit like 802.11p...'LTE Prose for V2X' is the real name...), mode 4 = (ad-hoc mode..currently chosen by all vendors (except maybe Huawei, but = might have changed), there is two options for protocol stack: IPv6 = (again, only IPv6) and non-IP (L2)...you can use non-IP packets and it = is so mentioned that BSM and CAM will use the non-IP option, as it is = also required to use the ETSI/WAVE security provisions to secure the = C-V2X mode 4 (as no SIM=3D no security), as the ETSI/WAVE security = provisions works for non-IP packets (geonet or WSM)... Of course, it does not block from using IP...it is again the same = discussion we had with ITS-G5/DSRC...for safety communication, IP is not = required...you can do everything without and faster. And considering = that IEEE 802.11p (ok, OCB) and C-V2X mode 4 (no SIM=3Dno SEC) DO NOT = have any form of security mechanism embedded, they must use the those = specified by ETSI/WAVE for accessing CCH. Again, C-V2X mode 4 (the current V2X techno for Safety-critical = communication) shall not be seen as following the same path as other = cellular techno. It does not provide QoS (at all), as it channel access = is contention-based (a bit like CSMA)...so collisions will occur (unlike = 4G and 5G operated, where you are either dropped or you pass). And as = such, IP is also not required, even if all 4G and 5G use IP. =20 >> ETSI and WAVE will not use IP for CAM... >That is their problem. Disagree: you need to be compatible with them...so, whatever IETF will = do shall not break anything that has been done on ETSI or WAVE. This is = one of the requirement for accessing the ITS-G5 spectrum in EU, and I = believe the same in the US. >ETSI transports IP over GeoNetworking - that is not the right way to do = it. Disagree: we need to integrate security mechanisms specified by ETSI = even if we use IPv6. Today, we do not have any security specification = providing 'trust', privacy and authentication for using 802.11-OCB (I = believe it is the work of IPWAVE and it is not completed yet...).=20 The mistake ETSI did is to try to be nice with IETF and help them to = provide a way to use IPv6 over ITS-G5 in a secured way...WAVE took a = different path: 'not my problem', which then explain why ETSI officially = does not endorse IPWAVE (unfortunately, despite my many discussions with = them)...from an ETSI perspective, using IPv6 over ITS-G5 is = solved...(might be ugly, but it is solved). =20 >> the basic CAMs are used for pure positioning >The mandatory fields in CAM or more than just lat/long/altitude. There = is also mandatory time in a strange format, car dimensions, curve, non = standard precisions and more. Yes, correct...but these are configurable fields, which may or may not = be integrated...recent studies even showed that even the standard CAM = size is not clear anymore..you have a 'range' of size, and that is a = problem for wireless optimization...especially if you need to do = wireless congestion control. >> and the recent 'increase' of information put in CAM >If CAM worries about size, I think CAM should think about its existing = redundancy. For example, position is carried twice in a CAM message: in = the CAM itself and in the GeoNetworking header. That >is an issue they = should address first. Well, of course, this is a waste...but one reason for such existence is = from the possibility to relay a packet (agnostic from the upper = messages, unfortunately, we cannot use a Zero-NET for CAM as it is pure = 1-hop TSB)... Yet, today we start seeing even BSM investigating ways to do multi-hop = 'position' based relaying to reach longer distance.=20 And if you think about it, one day, your IPv6-over-OCB might need to use = a multi-hop networking protocol (e.g. MANET)..but doing the MANET way is = highly mobile environment will not be that efficient...position-based = mechanisms will be required (proven in various previous studies)...now, = your L3 will not be able to inspect the GPS position of your = CAM-over-IP...so, you will need to have GPS (or so) position at IP/L3, = which will end up being similar than now... If you do not want to do this, then the IRTF people might come with ICN, = but then would this be done above L3 or at L3...if still at L3, you = still will have a contextual L3 packet that might be redundant with = application/service layer messages...(the cost of using OSI) But this is just my personal view and very long term...for now, if we = only look at CAM, indeed we can have twice the GPS position (but wait: = not the same granularity and you do not have elevation in geonet). But = if you look at the bigger picture: doing CAM-over-geonet only required = a single CAM, that's it. For IPv6-over-OCB, you need all the IPv6 = address autoconfiguration..that requires additional IPv6 packets to be = transmitted...this is similar to compare an apple with a tomato. =20 >> looks to be like a bad strategy as we end up having a container=20 >> carrying too many things and being too big for what it is... >I agree. But I think we should compare header sizes and then there = will be surprises. >CAM transported in IP may be a smaller packet than CAM transported in = BTP and GeoNetworking. Not that much if you counts also all IPv6-related control/management = packets required to transmit your CAM-over-OCB, in a highly dynamic = environment... > (WLAN is good at squeezing various small packets but really not good=20 > at big things especially in broadcast mode)...a better strategy would=20 > be to define new messages tailored to the information needs, and have=20 > smart service scheduling...(especially benefiting from IP-related > mechanisms) > I fully agree with this. :-) at least we do on this :-) Cheers, J=C3=A9r=C3=B4me _______________________________________________ its mailing list its@ietf.org = https://www.ietf.org/mailman/listinfo/its _______________________________________________ its mailing list its@ietf.org = https://www.ietf.org/mailman/listinfo/its ------=_NextPart_000_008B_01D3AF4B.319DF5C0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable RE: [ipwave] 802.11 Data vs 802.11 QoS Data in = IPv6-over-802.11-OCB

Hi Fran=C3=A7ois,

 

They come from IEEE 802.11-2016, section p.899, section , 9.4.2.29 = EDCA Parameter Set element, Table 9-138=E2=80=94Default EDCA parameter = set for STA operation if dot11OCBActivated is = true

 

BR,

 

J=C3=A9r=C3=B4me

 

From:= = Fran=C3=A7ois Simon [mailto:fygsimon@gmail.com]
Sent: Monday = 26 February 2018 21:39
To: 'J=C3=A9r=C3=B4me H=C3=A4rri'; = 'Alexandre Petrescu'; its@ietf.org
Cc: = fygsimon@gmail.com
Subject: RE: [ipwave] 802.11 Data vs 802.11 = QoS Data in IPv6-over-802.11-OCB

 

QoS Data combinations for = OCB:

AC_VO: AIFN=3D2, CWmin=3D4 = CWmax=3D8

AC_VI: AIFN=3D3, CWmin=3D8 = CWmax=3D16

AC_BE: AIFN=3D6, CWmin=3D16 = CWmax=3D1024

AC_BK: AIFN=3D9, CWmin=3D16 = CWmax=3D1024

I am not sure where these = values come from:

AIFSN: The values assigned = for each AC are the DEFAULT values. Those = values may not = fit all applications.  This attribute specifies = the number of slots, after a SIFS, that the = STA,

for a particular AC, senses = the medium idle either before transmitting or executing a backoff.  = The value is (2..15);<= /o:p>

CWmin: = The minimum contention window size is defined by the aCWmin = value. This = attribute specifies the value of the minimum size of the window = that is used = by a STA for a particular AC for generating a random number for = the = backoff.  It is calculated by = 2x =E2=80=93 1 where x is an = integer. aCWmin is = 0..255=

CWmax: The = maximum contention window size is defined by aCWmax.  The aCWmax = is  0..65535

The defaults = for CWmin and CWmax are specified in IEEE 802.11-2016, = Clause  9.4.2.29 = EDCA Parameter Set element.

-----Original = Message-----
From: its [mailto:its-bounces@ietf.org] On = Behalf Of J=C3=A9r=C3=B4me H=C3=A4rri
Sent: Monday, February 26, 2018 = 6:39 AM
To: 'Alexandre Petrescu' <alexandre.petrescu@gmail.com= >; its@ietf.org
Subject: = Re: [ipwave] 802.11 Data vs 802.11 QoS Data in = IPv6-over-802.11-OCB

Hi Alex, = All,

After double checking = IEEE802.11-2016, here are two aspects I need to correct (sorry for my = mistake)L:

1) both data and QoSData = are allowed when Dot11OCBActivated=3Dtrue;

2) EDCA parameters were = wrong ( I wrongly used the nonOCB ones)

QoS Data combinations for = OCB:

AC_VO: AIFN=3D2, CWmin=3D4 = CWmax=3D8

AC_VI: AIFN=3D3, CWmin=3D8 = CWmax=3D16

AC_BE: AIFN=3D6, CWmin=3D16 = CWmax=3D1024

AC_BK: AIFN=3D9, CWmin=3D16 = CWmax=3D1024

Both Data and QoSData are = theoretically possible, so indeed the draft should cover this aspect. =

Yet, I still suggest to = keep QoS for IPv6, again as even if it does not bring much 'now' for = IPv6, it does not cost much either...and we should not forgot that we = might interact with EDCA transmissions (QoS) and as such could create = harmful interference on the DSRC/ITS-G5 = channels.

BR,

= J=C3=A9r=C3=B4me=

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

From: its [mailto:its-bounces@ietf.org<= /span>] On Behalf = Of J=C3=A9r=C3=B4me H=C3=A4rri

Sent: Monday 26 February = 2018 10:25

To: 'Alexandre = Petrescu'; its@ietf.org=

Subject: = Re: [ipwave] 802.11 Data vs 802.11 QoS Data in = IPv6-over-802.11-OCB

Hi = Alex,

> That is a = requirement.

> =

> But is = there an implementation of mapping the priority of CAM over DENM into a = QoS Control field in QoS Data Header?

> =

> I doubt = there is, because the implementations of CAM I see put the Priority = field to 6, which means Voice.  So they transmit CAM as Voice even = though it is not voice.

> =

> We can = not reckon in IPv6-over-OCB document something which makes little sense = (send CAM as Voice).

Of course there is....the = QoS fields actually means the Access Categories (AC) for WLAN, so EDCA. = Both in ETSI and in WAVE they use the QoS Control filed of IEE 802.11p = to send CAM/BSM with higher priority (from a MAC perspective)...When = looking at the EDCA 'naming' you should not care much of the = 'name'...this was done at the time internet was only composed of voice, = video etc..you should look at the underlying values of each = AC.

So, EDCA is composed of two = fields:

1) AIFN - a deterministic = idle time before even considering reducing = CW

2) CW - a random timer to = decrease each time the channel is idle.

QoS Data combinations for = OCB:

AC_VO: AIFN=3D2, = CW=3D8

AC_VI: AIFN=3D2, = CW=3D16

AC_BE: AIFN=3D3, = CW=3D32

AC_BK: AIFN=3D7, = CW=3D32

So, it does not matter the = name (Voice, video)..what matters is that in implementation (BSM for = instance), AIFN=3D2 so that it takes the fastest access (deterministic) = and as such has the highest priority. This is also what you found: CAM = on Priority field 6, so AC_VI so AIFN=3D2. BSM uses the same strategy. =

Now, on the CAR 2 CAR = specification, it is recommended a different priority: AC_BE, as it uses = DP2. The reason behind this is the CAR2CAR provides a 'strict' = prioritization between DENMs and CAMs. Emergency DENMs uses AC_VI, = normal DENM uses AC_VO, CAM uses AC_BE and any other traffic = AC_BK.

So, bottom line is: all = ETSI and WAVE implementation use the QoS Data field as they use EDCA. If = you found an implementation that does not use the QoS, it is wrong = according to the standard.

>> Now, as you = abstract ETSI and WAVE (thus pure IP), my understanding =

>> is that QoS = remains required from the IEEE 802.11p (ok, = IEEE

>> 802.11-2016 OCB) = as there is a specification of the EDCA parameters =

>> for OCB. Besides, = I do not think it costs much to keep the EDCA in, =

>> as it first allows = to safe a half of the MAC queueing time (the EDCA =

>> parameters for the = two low AC are less, up to a quarter of a

>> DIFS...so, it = could be beneficial to allow this even for IP. Second, =

>> the EDCA allows = TXOpps (Transmit Opportunities)..although put to =

>> 'zero' for OCB (I = think), this mechanism still allows an AP to =

>> reserve a given = time a long(er) connectivity with one device = (e.

>> streaming of video = etc..). Finally, it does not cost anything..you =

>> can always take = the lowest AC and you get the same behavior as = non-QoS..

>Well, this text is more = informal in nature.   It is something = that

>describes a potential = behaviour but we have no proof of existing such behaviour, no proof of = interoperability.  This could be part of an INFORMATIONAL Internet = Draft.

Well, my text is informal, = but the specs are not. IEEE 802.11p (IEEE 802.11-2016 OCB) uses EDCA not = DCF...as this is L2 layer, I do not think anything is required from = IETF...just follow the IEEE 802.11-2016 specs and do whatever is allows = above it...I will double check again on the IEEE 802.11-2016, but if = what I think is confirmed, the whole discussion does not make any = sense..., as it is my understanding that the OCB requires EDCA, so = QoS_Data...so, you cannot change that at IP = level.

 

>> Bottom line, the = fact that some IP implementation to decode OCB =

>> assume non-QoS = frames looks more to me like an implementation error =

>> and we should not = propagate this...

>Well, wireshark has = problems interpreting 802.11 QoS Data containing CAM messages.  = Many receivers of QoS Data dont know what to do with the fields because = they are not agreed.

Yes, and this is why is the = prototype we use, we actually have an parser for CAM to be supported by = Wireshark...it does not come by default. But I am surprised..what kind = of problem would wireshark face with the QoS Data? =

 

> I don't want to = propagate that disagreement into the IP-over-OCB = draft.

To me, this looks more like = an implementation issue, rather than a standard issue...but I will ask = my team to check on our prototype...

>> C-V2X will not use = IP for CAM,

>LTE-V2X will carry CAM = in IP.  What is C-V2X and why does not it use = IP?

Sorry, it will not. In = C-V2X (the widely known name...LTE-V2X is again a bit like = 802.11p...'LTE Prose for V2X' is the real name...), mode 4 (ad-hoc = mode..currently chosen by all vendors (except maybe Huawei, but might = have changed), there is two options for protocol stack: IPv6 (again, = only IPv6) and non-IP (L2)...you can use non-IP packets and it is so = mentioned that BSM and CAM will use the non-IP option, as it is also = required to use the ETSI/WAVE security provisions to secure the C-V2X = mode 4 (as no SIM=3D no security), as the ETSI/WAVE security provisions = works for non-IP packets (geonet or = WSM)...

Of course, it does not = block from using IP...it is again the same discussion we had with = ITS-G5/DSRC...for safety communication, IP is not required...you can do = everything without and faster. And considering that IEEE 802.11p (ok, = OCB) and C-V2X mode 4 (no SIM=3Dno SEC) DO NOT have any form of security = mechanism embedded, they must use the those specified by ETSI/WAVE for = accessing CCH.

Again, C-V2X mode 4 (the = current V2X techno for Safety-critical communication) shall not be seen = as following the same path as other cellular techno. It does not provide = QoS (at all), as it channel access is contention-based (a bit like = CSMA)...so collisions will occur (unlike 4G and 5G operated, where you = are either dropped or you pass). And as such, IP is also not required, = even if all 4G and 5G use IP.

 

>> ETSI and WAVE will = not use IP for CAM...

>That is their = problem.

Disagree: you need to be = compatible with them...so, whatever IETF will do shall not break = anything that has been done on ETSI or WAVE. This is one of the = requirement for accessing the ITS-G5 spectrum in EU, and I believe the = same in the US.

>ETSI transports IP over = GeoNetworking - that is not the right way to do = it.

Disagree: we need to = integrate security mechanisms specified by ETSI even if we use IPv6. = Today, we do not have any security specification providing 'trust', = privacy and authentication for using 802.11-OCB (I believe it is the = work of IPWAVE and it is not completed yet...). =

The mistake ETSI did is to = try to be nice with IETF and help them to provide a way to use IPv6 over = ITS-G5 in a secured way...WAVE took a different path: 'not my problem', = which then explain why ETSI officially does not endorse IPWAVE = (unfortunately, despite my many discussions with them)...from an ETSI = perspective, using IPv6 over ITS-G5 is solved...(might be ugly, but it = is solved).

  =

>> the basic CAMs are = used for pure positioning

>The mandatory fields in = CAM or more than just lat/long/altitude.  There is also mandatory = time in a strange format, car dimensions, curve, non standard precisions = and more.

Yes, correct...but these = are configurable fields, which may or may not be integrated...recent = studies even showed that even the standard CAM size is not clear = anymore..you have a 'range' of size, and that is a problem for wireless = optimization...especially if you need to do wireless congestion = control.

>> and the recent = 'increase' of information put in CAM

>If CAM worries about = size, I think CAM should think about its existing redundancy.  For = example, position is carried twice in a CAM message: in the CAM itself = and in the GeoNetworking header.  That >is an issue they should = address first.

Well, of course, this is a = waste...but one reason for such existence is from the possibility to = relay a packet (agnostic from the upper messages, unfortunately, we = cannot use a Zero-NET for CAM as it is pure 1-hop = TSB)...

Yet, today we start seeing = even BSM investigating ways to do multi-hop 'position' based relaying to = reach longer distance.

And if you think about it, = one day, your IPv6-over-OCB might need to use a multi-hop networking = protocol (e.g. MANET)..but doing the MANET way is highly mobile = environment will not be that efficient...position-based mechanisms will = be required (proven in various previous studies)...now, your L3 will not = be able to inspect the GPS position of your CAM-over-IP...so, you will = need to have GPS (or so) position at IP/L3, which will end up being = similar than now...

If you do not want to do = this, then the IRTF people might come with ICN, but then would this be = done above L3 or at L3...if still at L3, you still will have a = contextual L3 packet that might be redundant with application/service = layer messages...(the cost of using OSI)

But this is just my = personal view and very long term...for now, if we only look at CAM, = indeed we can have twice the GPS position (but wait: not the same = granularity and you do not have elevation in geonet). But if you look = at  the bigger picture: doing CAM-over-geonet only required a = single CAM, that's it. For IPv6-over-OCB, you need all the IPv6 address = autoconfiguration..that requires additional IPv6 packets to be = transmitted...this is similar to compare an apple with a = tomato.

 

=

>> looks to = be like a bad strategy as we end up having a container =

>> carrying too many = things and being too big for what it is...

>I agree.  But I = think we should compare header sizes and then there will be = surprises.

>CAM transported in IP = may be a smaller packet than CAM transported in BTP and = GeoNetworking.

Not that much if you counts = also all IPv6-related control/management packets required to transmit = your CAM-over-OCB, in a highly dynamic = environment...

> (WLAN is good at = squeezing various small packets but really not good =

> at big things = especially in broadcast mode)...a better strategy would =

> be to define new = messages tailored to the information needs, and have =

> smart service = scheduling...(especially benefiting from = IP-related

> = mechanisms)

> I fully agree with = this.

:-) at least we do on this = :-)

Cheers,

J=C3=A9r=C3=B4me=

____________________________= ___________________

its mailing = list

its@ietf.org=

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

____________________________= ___________________

its mailing = list

its@ietf.org=

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

------=_NextPart_000_008B_01D3AF4B.319DF5C0-- From nobody Mon Feb 26 13:18:46 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96580127078 for ; Mon, 26 Feb 2018 13:18:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 HPXav6_yqjRB for ; Mon, 26 Feb 2018 13:18:42 -0800 (PST) Received: from mail-ot0-x22e.google.com (mail-ot0-x22e.google.com [IPv6:2607:f8b0:4003:c0f::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 DF0D0126DFB for ; Mon, 26 Feb 2018 13:18:41 -0800 (PST) Received: by mail-ot0-x22e.google.com with SMTP id 95so1819284ote.5 for ; Mon, 26 Feb 2018 13:18:41 -0800 (PST) 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=rAcBvNQOio5sxEBeb0jXnT8Eni454j06+bcwyUJI6j0=; b=AIbdkTwg+L9UVe+zRZQs8CXN9V2oSv9I9Lf4zKLJUa9jqS9MaIhYHrZyYytdo+HNdS vALTXO1JgJdmqsp4EkoELBQRjLcVqA4KMWOXLfoiw8Cjgj1nFGbL5dMKrq2/MLHXMnbG hZoU7X9yTQhf7sqCSw3dDqNp1/Y1vubHW/iLWKxPlEpJKX4+Mayj5+2si9qHr8eGIRRd xHh0IeWGPCW05zKhvdg+A/31KgWMt5xS3gEKIcGasrJXMtrDNRrpA2QU3lV3UTYnmPQ3 wF1XStIwySBqY0DJcjC6Tsdl3kGPU1Rqox0l8lclOjdX7omWdKGzHtsO80l1qDaXBA6K vmYQ== 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=rAcBvNQOio5sxEBeb0jXnT8Eni454j06+bcwyUJI6j0=; b=ozMqwsPUfxU10d9GLmxDQYebKjSWmDXtdRFpdB4J5Shm2uSzsujXIVeC1DVhH/VDIg yl2+JEky2lAUVrCwvoIoo/h9WtAzLpsvCZ+WLKLCHr/6pHTg/O2O1+Imd7CzGoGl1YPV 9wkgAjhZsExtZu80Ia/xqBnqX05YWvt2Vkz0ZJ56Mzs3bCeWCXYLUFk1eyKe62CdFQQu y/lyQmmtlpvKqXBPnEn2NHiTUM6/f8rWUDQ61SE6kJCpr9rfvfh6Eu31CYkdAOmLag3i /4jpr/Ya5TtRb7Ox43fq4lJ5Gwxg+YTO0qqsavxz7cReiFVN4tQUiNG6opIJBClLcD7h tflw== X-Gm-Message-State: APf1xPBJKxlFnMExuhppe/GAivGZ3tA9oDDx9yfdXy30fCSo6/coK6cz pXRo8Qf4Mb/ymvdPglFi6HvLx9CZiMqz/uTpnWw= X-Google-Smtp-Source: AG47ELutjPAtiH3TQ4JrF+j+dFiwZUinPqIzpKcnZ6w2ceUp9QSmv9MehOYS24gP4/Zylae27ghAKyITS0PtnorovoY= X-Received: by 10.157.11.120 with SMTP id p53mr8394202otd.208.1519679921192; Mon, 26 Feb 2018 13:18:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.36 with HTTP; Mon, 26 Feb 2018 13:18:40 -0800 (PST) In-Reply-To: <00b601d3aeeb$c75e25e0$561a71a0$@eurecom.fr> References: <00b601d3aeeb$c75e25e0$561a71a0$@eurecom.fr> From: Abdussalam Baryun Date: Mon, 26 Feb 2018 23:18:40 +0200 Message-ID: To: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= Cc: its Content-Type: multipart/alternative; boundary="001a113d0a54e003ee0566240d72" Archived-At: Subject: Re: [ipwave] IP and L2 aspects 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, 26 Feb 2018 21:18:45 -0000 --001a113d0a54e003ee0566240d72 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Feb 26, 2018 at 12:23 PM, J=C3=A9r=C3=B4me H=C3=A4rri wrote: > Dear All, > > > > *Not wanting to blame anybody, but from a higher level perspective, I > would like to suggest stop these endless discussions between what IPv6 > requires and what OCB does.* > *Why you see it is endless, I see we are ending many issues, and our WG chair is listening the discussion, if the chair tells us stop we can, but I don't think we are discussing in endless, because we solved many things so far and we are updating draft to better versions.* > * I mean, there is a clear specification of what OCB does (in IEEE > 802.11-2016). And IETF should not specify aspects from L2, unless the L2 > spec leaves it open (which is seldom not the case for the OCB case). * > *this WG is not specifying L2, but using L2 technologies, * > > *I mean, there is a standard that has been optimized over 10 years to > operate (and be now deployed in various US state DOT), which does not use > IP. * > *Any standard protocol uses what is under only, so I don't think IEEE802.11 can use IP. We are focusing this work that IP uses IEEE802.11p for best transmissions * > *Now, it is fully legitimate to make use of IPv6 and without using WSM or > Geonet. I support this effort, as I am even co-author of the draft and I > also need this standard=E2=80=A6and I wish that we could have a RFC by no= w (or even > by yesterday=E2=80=A6). * > *We let this by the AD and WG chair, they can guide us what to do and when,= * > > > *But as IPv6 has some requirements that is not provided by OCB (not open, > rather not possible), there are some attempts to use OCB with wrong > configurations. * > *Not agreeing, but please specify? * > *Also there is a recurring invalid claim that IPv6-over-OCB would be > isolated (and as such independent) from other WAVE/ETSI traffic. * > *I think isolated is better. WAVE/ETSI have different users from Internet users. * > * This is wrong, as at least that at the current form (and similarly to > attempts of C-V2X to use ITS-G5 spectra), there is a complex debate on > spectrum neutrality=E2=80=A6but the current direction is that WAVE/ETSI h= ave been > specified first and are there (and deployed now), so whatever comes not > should not break anything.* > > *I mean, people at IETF are expert in IP, and people who designed the OCB > are expect in L2 (with 10 years of experience in making OCB work - > regardless of what is on top/L3). Now, over the endless (and recurring) > discussions over this thread, I have seen many hypothesis from IETF on wh= at > OCB could/would do, which has been corrected by some OCB experts (whom so= me > of them even have been involved in the writing of the very OCB specs). Of > course, debate are always possible, what about trusting the OCB people of > what OCB does and build IPv6 over it ? * > *I trust all, but I would like to discuss until the WG chair advices. * > > > *If you think it could make sense, maybe can gather a team of OCB experts= , > have them on a telco for a one-time clear-all-issues discussion, and end > all debate after this.* > *It is not debate but discussions. IETF use discussion to get to consensus, and then editor update draft as we are doing,* > > > *I mean, it is a fully valid to need to tweak OCB for IPv6 requirements, > but we should take OCB as it is now, make a spec on top of it as good as > possible, and enhance it later if necessary.* > > *As such, I strongly push to complete the debate on the current OCB draft > and move it to RFC, yet with leaving any L2 discussions/parameters outsid= e > the RFC.* > > > > *Then, if IPv6 requires something that OCB does not provide, then let=E2= =80=99s go > to IEEE and ask for change. But at least we have a spec=E2=80=A6as if we = keep > exchanging long e-mails and keep having misunderstanding from what the IP > community thinks of OCB and what OCB actually is, we will never complete > the work.* > *IEEE and IETF has an agreement. some in IETF are in connection with IEEE, and we have an officer that his/her job is for coordination between IEEE and IETF. We always can use that through our AD. * *AB* --001a113d0a54e003ee0566240d72 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Feb 26, 2018 at 12:23 PM, J=C3=A9r=C3=B4me H=C3=A4rri <= jerome.haerri@eurecom.fr> wrote:

Dear All,=

=C2=A0

Not wanting to blame anybody, but fr= om a higher level perspective, I would like to suggest stop these endless d= iscussions between what IPv6 requires and what OCB does.=


Why you see it is endless, I see we are ending many issues, and our WG = chair is listening the=C2=A0discussion, if the chair tells=C2=A0us stop we = can, but I don't think we are discussing in endless, because we solved = many things so far and we are updating draft to better versions.
=C2=A0

I me= an, there is a clear specification of what OCB does (in IEEE 802.11-2016). = And IETF should not specify aspects from L2, unless the L2 spec leaves it o= pen (which is seldom not the case for the OCB case).


this WG is not specifying L2, but using L2 technologies,

=C2=A0

I mean, there is a standard th= at has been optimized over 10 years to operate (and be now deployed in vari= ous US state DOT), which does not use IP.


Any standa= rd protocol uses what is under only, so I don't think IEEE802.11 can us= e IP. We are focusing this work=C2=A0that IP=C2=A0uses IEEE802.11p for best= transmissions=C2=A0
=C2=A0

Now, it is fully legitimate to make use of IPv6 a= nd without using WSM or Geonet. I support this effort, as I am even co-auth= or of the draft and I also need this standard=E2=80=A6and I wish that we co= uld have a RFC by now (or even by yesterday=E2=80=A6).=C2=A0=


<= u>We let this by the AD and WG chair, they can=C2=A0guide us what to = do and when,
=C2=A0

=C2=A0=

But as IPv6 has some requirements that is not provided by OCB (not open, r= ather not possible), there are some attempts to use OCB with wrong configur= ations.


<= /u>
Not agreeing, but please specify?=C2=A0<= /u>

=C2=A0

<= u>Also there is a recurring invalid clai= m that IPv6-over-OCB would be isolated (and as such independent) from other= WAVE/ETSI traffic.


I think isolated is better. WAVE= /ETSI have different=C2=A0users from Internet users.
=C2=A0=C2=A0

=C2=A0This= is wrong, as at least that at the current form (and similarly to attempts = of C-V2X to use ITS-G5 spectra), there is a complex debate on spectrum neut= rality=E2=80=A6but the current direction is that WAVE/ETSI have been specif= ied first and are there (and deployed now), so whatever comes not should no= t break anything.

I mea= n, people at IETF are expert in IP, and people who designed the OCB are exp= ect in L2 (with 10 years of experience in making OCB work - regardless of w= hat is on top/L3). Now, over the endless (and recurring) discussions over t= his thread, I have seen many hypothesis from IETF on what OCB could/would d= o, which has been corrected by some OCB experts (whom some of them even hav= e been involved in the writing of the very OCB specs). Of course, debate ar= e always possible, what about trusting the OCB people of what OCB does and = build IPv6 over it ?

<= u>
I trust all, but I=C2=A0would l= ike to discuss until the WG chair advices.=C2=A0

=C2=A0

I= f you think it could make sense, maybe can gather a team of OCB experts, ha= ve them on a telco for a one-time clear-all-issues discussion, and end all = debate after this.

<= u>
It is not debate but discussions.= =C2=A0IETF use discussion to get to consensus, and then=C2=A0editor update = draft as we are doing,

=

=C2=A0

I mean, it is a fully valid= to need to tweak OCB for IPv6 requirements, =C2=A0but we should take OCB a= s it is now, make a spec on top of it as good as possible, and enhance it l= ater if necessary.

<= /u>

As s= uch, I strongly push to complete the debate on the current OCB draft and mo= ve it to RFC, yet with leaving any L2 discussions/parameters outside the RF= C.

=C2=A0

Then, if IPv6 r= equires something that OCB does not provide, then let=E2=80=99s go to IEEE = and ask for change. But at least we have a spec=E2=80=A6as if we keep excha= nging long e-mails and keep having misunderstanding from what the IP commun= ity thinks of OCB and what OCB actually is, we will never complete the work= .


=
IEEE and IETF has an agreement.=C2=A0=C2=A0some in<= span>=C2=A0IETF=C2=A0=C2=A0 are in connection with IEEE, and we have = an officer that his/her job is for coordination between IEEE and IETF. We a= lways can use that through our AD.


AB




<= /u>
--001a113d0a54e003ee0566240d72-- From nobody Mon Feb 26 19:09:12 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8397412E047 for ; Mon, 26 Feb 2018 19:09:10 -0800 (PST) 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=us-toyota-itc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psVa83hwXRWY for ; Mon, 26 Feb 2018 19:09:07 -0800 (PST) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79FF212E045 for ; Mon, 26 Feb 2018 19:09:07 -0800 (PST) Received: by mail-io0-x230.google.com with SMTP id p78so19548514iod.13 for ; Mon, 26 Feb 2018 19:09:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=us-toyota-itc-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=72fJRR0ikEid/U01Zcesi9lUnED/ZmMgcu//Vvrx6ik=; b=qDpouPi3htPxHJFDglzAlMPO8n0uZ58VskJ//iUvQtPx5g7e2nFGg6aEdx8PLSoM+l aZLCN7hrET7TjRA6FQlKCtX5WrMExOiX0BdZJeWseAxrYVUCF8KV6FuqzYlf7HtMOO2t K8W8VSUbngWd0ABNHYblQL7Ajn7xKOsfrg6tHPbX83Orj1mbLR5U0qmKJJYMUlYc0D6h PsNZYV29DDJKE6DpsWBbGfIV35IV/mjbZGrD0UNHUmLNOiF3TuLyA+iWx3cPTOCu+Q2T tDSUhCyLSi4Fd2+CxsquR4ER2ieW5SJGI/N2xBJmdrxzjk8PdvVrVxed/UHL4b8NAhI1 L/+w== 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=72fJRR0ikEid/U01Zcesi9lUnED/ZmMgcu//Vvrx6ik=; b=YAwq5EeVqDcgms1gyj8lZmOxQupUVdr5Qaz04oJ6B4tFe0kmi19R6T17hMcHflUS1h th7c375p/WEEGydRVuDNjzCfis/jTQchCCcdM2WRK3E9hMo9xKeOLY+mzNup/E5x3Mkp 3aPpLQlibZnLfIVnbqHQDsje1iUsFq6TN9VkxIoMyM5sN1pEdGEpcao9Lq2qlx1uvrZl e07Ed2fiy1BGWNZg4Ojq8WHyqpQhimsnpdxlG1N24uzxhXiiKrBaReAFyd67zrRH3m4s EVAExxh+Qnob8vA+2T9tTv9AcFYjpZs7tH4DehBxgwcER7+Ente4PVFxSmjllwc//Rr1 SiCQ== X-Gm-Message-State: APf1xPA/AB5uJTFUZ+8q0tX0ayT4dB/bHbIP/ehlg2jn+zdzEW6JoMeO s1KIcwQ5X9us67dlkuDiy5vzYeeYh+Y2Wxk01bwurg== X-Google-Smtp-Source: AH8x225u6dZWd1QP71bL+hCbDsrKj1DfAq92f4muxuMje20KGxP2q+9XjhBxN6e8ZIjtKdy14Uw3FdYsV6nN4j3f9xs= X-Received: by 10.107.58.86 with SMTP id h83mr14149842ioa.284.1519700946600; Mon, 26 Feb 2018 19:09:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.24.135 with HTTP; Mon, 26 Feb 2018 19:09:05 -0800 (PST) In-Reply-To: <002901d3af20$b966e960$2c34bc20$@eurecom.fr> References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <9ada5591-2af3-272d-3bc3-031bf35454c3@gmail.com> <6cdc0835-fb4c-133b-77ff-0234cfdd9ef9@fischer-tech.eu> <00eb01d3af1d$7f4e8100$7deb8300$@gmail.com> <6187cb92-5c8f-d08b-dcc2-859652d629d0@gmail.com> <002901d3af20$b966e960$2c34bc20$@eurecom.fr> From: John Kenney Date: Mon, 26 Feb 2018 19:09:05 -0800 Message-ID: To: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= Cc: Alexandre Petrescu , =?UTF-8?Q?Fran=C3=A7ois_Simon?= , "Dr. Hans-Joachim Fischer" , Abdussalam Baryun , Tony Li , its Content-Type: multipart/alternative; boundary="001a114ac884166ee1056628f39f" Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 27 Feb 2018 03:09:10 -0000 --001a114ac884166ee1056628f39f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi All: J=C3=A9r=C3=B4me has made a very important point. Choosing to send IP traf= fic over DCF (i.e. non-QoS data frames) can be quite harmful to other DSRC services using EDCA. *It should not be done, period.* Some specific points: 1) WAVE standards explicitly require use of EDCA (IEEE 1609.4-2016, clause 4.1) 2) DCF is not really non-QoS. It is best thought of as "alternate" QoS, and in fact as "high QoS". In 802.11 the notion of QoS is manifested as channel access priority. As pointed out by others, this comes down to AIFSN and CWmin. DCF uses the equivalent of (AIFSN=3D2, CWmin =3D 15). Under moderate-to-heavy channel load, when QoS is important, AIFSN is the dominant factor. As J=C3=A9r=C3=B4me and Francois note, this puts DCF traff= ic at, or just below, the very highest priority EDCA traffic. So, this is quite different from Diffserv where "non-Diffserv" defaults to Best Effort. Here "non-EDCA" defaults to high channel access priority. This can be very harmful to very important DSRC/ITS G5 traffic, especially traffic using AC_VI and below. 3) I totally agree with the comments that caution not to be confused by the Voice/Video/Best Effort/Background labels. Those are historical and meant to be illustrative. In the ITS context it is simpler to think of Highest/High/Medium/Low channel access priority. Those are the terms used in SAE J2945/0 (clause 4.1.2.3), which makes recommendations for mapping application classes to 802.11 access categories. I believe the channel access priority will generally be independent of the L3 protocol [My personal opinion is if there is correlation in the DSRC case I expect we would see higher priority associated more often with WSMP (or ETSI equivalent) than with IPv6]. Therefore, not only should IP-over-OCB use EDCA, it should allow the actual user priority to come from higher layers. 4) EDCA parameters establish priority within a given channel. It is generally not possible (or necessary) to compare priority of packets sent on different channels. So, the EDCA parameter set may well vary by channel. This is exactly the case for the US DSRC band where SAE J2945/1 defines a non-default EDCA parameter set for Channel 172. Best Regards, John On Mon, Feb 26, 2018 at 8:41 AM, J=C3=A9r=C3=B4me H=C3=A4rri wrote: > Hi Alex, > > Well, from the IP layer, what you see is a 7 bit User Priority, nothing > else..feel free to label the 7 UP as you want....how it is translated is = L2 > business (and naming..)..so we should not care much about the names. > > Now, you raised an issue (that was also identified by other OCB people > reading the thread..and will probably also provide feedback soon) is the > coexistence between traffic. > > CAM uses AC_BE in ETSI, DENM uses AC_VI and AC_VO in ETSI. Event-based BS= M > uses AC_VI and non-even-based BSM uses AC_BE (I think)...so, if you send > IPv6 traffic with DCF (where DIFS =3D 2, same as AC_VI), then you will > compete directly with DENM and event-based BSM, which is * very* > problematic...thus my suggestion to keep QoSData so that we at least have > an option to avoid interfering with CAM/DENM. > > Now, if you want to transmit CAM with IPv6-over-OCB, then you 'clearly' > needs QoSData so that the pure IP CAM/BSN and ETSI/WAVE CAM/BSM have the > same L2 'priority' in accessing the channel, otherwise you risk creating > harmful interference and packet collisions. > > BR, > > J=C3=A9r=C3=B4me > > > > > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu > Sent: Monday 26 February 2018 17:23 > To: Fran=C3=A7ois Simon; 'Dr. Hans-Joachim Fischer'; 'Abdussalam Baryun' > Cc: 'Tony Li'; 'its' > Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in > IPv6-over-802.11-OCB > > > > Le 26/02/2018 =C3=A0 17:18, Fran=C3=A7ois Simon a =C3=A9crit : > > AC_VO (voice) is only a label indicating the highest priority; nothing > > more is implied. > > YEs, sure, but imagine someone sends real voice; that will compete with > CAM 'voice' - we dont want that either :-) > > In such situation, what one would like in standards is to see 'highest > priority' instead of 'voice'. > > Alex > > > > > *From:*its [mailto:its-bounces@ietf.org] *On Behalf Of *Dr. > > Hans-Joachim Fischer > > *Sent:* Monday, February 26, 2018 3:37 AM > > *To:* Abdussalam Baryun ; Alexandre > > Petrescu > > *Cc:* Tony Li ; its > > *Subject:* Re: [ipwave] 802.11 Data vs 802.11 QoS Data in > > IPv6-over-802.11-OCB > > > > Be careful with voice and audio transmission in ITS using 5,9 GHz. > > That seems to be prohibited by regulation in Europe; well, not > > explicitly, but this is a possible interpretation of the technical > > requirements presented in regulatory documents. In Germany, it is > prohibited. > > > > Hans-Joachim > > > > Am 26.02.2018 um 09:04 schrieb Abdussalam Baryun: > > > > The experience test you referred to is not clarified, was it a ITS > > environment experience or was it a fixed wireless experience. > > Furthermore, the WiFi technology ieee802.11 is developed so which > > WiFi technology was used. Moreover, did your experience use Video > > and voice communication or your proposal is only for data > > communication only. > > > > So if your IP packet are data then your experience is right, but if > > the IP packet is carrying voice or video I don't agree. IMO we coul= d > > not exclude from the draft voice and video communication in the ITS > > environment/use-case. > > > > On Sun, Feb 25, 2018 at 7:58 PM, Alexandre Petrescu > > = > > > wrote: > > > > > > > > Le 23/02/2018 =C3=A0 18:38, Tony Li a =C3=A9crit : > > > > If we put that CAM on IP there will still be lack of > > interoperability, > > unless we recommend IP to be carried by a particular > > 802.11 header (Data > > or QoS Data). > > > > > > > > I would propose that we use the Data header. My experience > > with the QoS Data with Wi-Fi was that there wasn=E2=80=99t = enough of > > a performance difference with QoS for it to make a > > difference to the IP layer. > > > > > > I agree. > > > > I propose the following text. > > > > OLD: > > > > In OCB mode, IPv6 packets MAY be transmitted either as > > "IEEE 802.11 > > Data" or alternatively as "IEEE 802.11 QoS Data", as > > illustrated in > > Figure 2. > > > > > > NEW: > > > > In OCB mode, it is RECOMMENDED to transmit IPv6 packets > > as "IEEE > > 802.11 Data" (the value of the field Subtype in the > > Frame Control > > Field is 0). > > > > > > 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 > > > > > > > > -- > > > > Dr. Hans-Joachim Fischer > > > > Managing Director > > > > ---------------------------------------------------------------------- > > ---------- > > > > ESF News edition 2018/1 > > > > https://fischer-tech.eu/Feeds/News/ESF-News-2018-01.pdf > > > > ---------------------------------------------------------------------- > > ---------- > > > > Towards deployment of C-ITS based on proven technology > > > > Avoid risks and delay by looking on potential future technologies. > > > > The real advocate on ITS is ISO TC204! > > > > ---------------------------------------------------------------------- > > ---------- > > > > + + + Instaurare omnia in Christo + + + > > > > ---------------------------------------------------------------------- > > ---------- > > > > The information contained in this message is confidential and may be > > legally > > > > privileged. This email is intended for the addressee(s). Addressees > > may be > > > > individual persons or members of mailing list. > > > > If you are not an addressee, you are hereby notified that any use, > > > > dissemination, or reproduction of this email and its optional > > attachements is > > > > strictly prohibited and may be unlawful. If you are not an addressee, > > please > > > > contact the sender by return e-mail and destroy all copies of the > > original > > > > message. > > > > ---------------------------------------------------------------------- > > ---------- > > > > ESF GmbH > > > > Fichtenweg 9 > > > > 89143 Blaubeuren > > > > +49 (7344) 175340 (Direct line Dr. Fischer) > > > > +49 (7344) 919188 (Central office) > > > > +49 (7344) 919123 (Fax) > > > > https://fischer-tech.eu : Main web of ESF GmbH > > > > http://its-standards.eu : News on cooperative ITS standardization > > > > http://its-testing.org : International consultancy for cooperative > > ITS > > > > ---------------------------------------------------------------------- > > ---------- > > > > ---------------------------------------------------------------------- > > ---------- > > > > ESF online-news:http://fischer-tech.eu/Feeds/esf.rss > > > > C-ITS online news:http://its-standards.info/Feeds/cits.rss > > > > ESF Online Nachrichten:http://fischer-tech.de/Feeds/esfD.rss > > > > ---------------------------------------------------------------------- > > --------- > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > --=20 John Kenney Director and Principal Researcher Toyota InfoTechnology Center, USA 465 Bernardo Avenue Mountain View, CA 94043 Tel: 650-694-4160. Mobile: 650-224-6644 --001a114ac884166ee1056628f39f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All:

J=C3=A9r=C3=B4me=C2=A0has made a very i= mportant point.=C2=A0 Choosing to send IP traffic over DCF (i.e. non-QoS da= ta frames) can be quite harmful to other DSRC services using EDCA. It sh= ould not be done, period.

Some specific po= ints:
1) WAVE standards explicitly require use of EDCA (IEEE 1609= .4-2016, clause 4.1)

2) DCF is not really non-QoS.= It is best thought of as "alternate" QoS, and in fact as "h= igh QoS".=C2=A0 In 802.11 the notion of QoS is manifested as channel a= ccess priority. As pointed out by others, this comes down to AIFSN and CWmi= n.=C2=A0 DCF uses the equivalent of (AIFSN=3D2, CWmin =3D 15). Under modera= te-to-heavy channel load, when QoS is important, AIFSN is the dominant fact= or. As J=C3=A9r=C3=B4me and Francois = note, this puts DCF traffic at, or just below, the very highest priority ED= CA traffic.=C2=A0 So, this is quite different from Diffserv where "non= -Diffserv" defaults to Best Effort.=C2=A0 Here "non-EDCA" de= faults to high channel access priority.=C2=A0 This can be very harmful to v= ery important DSRC/ITS G5 traffic, especially traffic using AC_VI and below= .

=
3) I totally agree = with the comments that caution not to be confused by the Voice/Video/Best E= ffort/Background labels. Those are historical and meant to be illustrative.= In the ITS context it is simpler to think of Highest/High/Medium/Low chann= el access priority. Those are the terms used in SAE J2945/0 (clause 4.1.2.3= ), which makes recommendations for mapping application classes to 802.11 ac= cess categories.=C2=A0 I believe the channel access priority will generally= be independent of the L3 protocol [My personal opinion is if there is corr= elation in the DSRC case I expect we would see higher priority associated m= ore often with WSMP (or ETSI equivalent) than with IPv6].=C2=A0 Therefore, = not only should IP-over-OCB use EDCA, it should allow the actual user prior= ity to come from higher layers.

4) EDCA parameters establish priority within a given channel. It= is generally not possible (or necessary) to compare priority of packets se= nt on different channels. So, the EDCA parameter set may well vary by chann= el. This is exactly the case for the US DSRC band where SAE J2945/1 defines= a non-default EDCA parameter set for Channel 172.=C2=A0=C2=A0
=

Best Regards,
John



On Mon, Feb 26, 201= 8 at 8:41 AM, J=C3=A9r=C3=B4me H=C3=A4rri <jerome.haerri@eurecom.fr= > wrote:
Hi Alex,

Well, from the IP layer, what you see is a 7 bit User Priority, nothing els= e..feel free to label the 7 UP as you want....how it is translated is L2 bu= siness (and naming..)..so we should not care much about the names.

Now, you raised an issue (that was also identified by other OCB people read= ing the thread..and will probably also provide feedback soon) is the coexis= tence between traffic.

CAM uses AC_BE in ETSI, DENM uses AC_VI and AC_VO in ETSI. Event-based BSM = uses AC_VI and non-even-based BSM uses AC_BE (I think)...so, if you send IP= v6 traffic with DCF (where DIFS =3D 2, same as AC_VI), then you will compet= e directly with=C2=A0 DENM and event-based BSM, which is * very* problemati= c...thus my suggestion to keep QoSData so that we at least have an option t= o avoid interfering with CAM/DENM.

Now, if you want to transmit CAM with IPv6-over-OCB, then you 'clearly&= #39; needs QoSData so that the pure IP CAM/BSN and ETSI/WAVE CAM/BSM have t= he same L2 'priority' in accessing the channel, otherwise you risk = creating harmful interference and packet collisions.

BR,

J=C3=A9r=C3=B4me




-----Original Message-----
From: its [mailto:its-bounces@ietf.= org] On Behalf Of Alexandre Petrescu
Sent: Monday 26 February 2018 17:23
To: Fran=C3=A7ois Simon; 'Dr. Hans-Joachim Fischer'; 'Abdussala= m Baryun'
Cc: 'Tony Li'; 'its'
Subject: Re: [ipwave] 802.11= Data vs 802.11 QoS Data in IPv6-over-802.11-OCB



Le 26/02/2018 =C3=A0 17:18, Fran=C3=A7ois Simon a =C3=A9crit :
> AC_VO (voice) is only a label indicating the highest priority; nothing=
> more is implied.

YEs, sure, but imagine someone sends real voice; that will compete with CAM= 'voice' - we dont want that either :-)

In such situation, what one would like in standards is to see 'highest = priority' instead of 'voice'.

Alex

>
> *From:*its [mailto:its-bounces= @ietf.org] *On Behalf Of *Dr.
> Hans-Joachim Fischer
> *Sent:* Monday, February 26, 2018 3:37 AM
> *To:* Abdussalam Baryun <abdussalambaryun@gmail.com>; Alexandre
> Petrescu <alexandre= .petrescu@gmail.com>
> *Cc:* Tony Li <tony1athome= @gmail.com>; its <its@ietf.org>
> *Subject:* Re: [ipwave] 802.11 Data vs 802.11 QoS Data in
> IPv6-over-802.11-OCB
>
> Be careful with voice and audio transmission in ITS using 5,9 GHz.
> That seems to be prohibited by regulation in Europe; well, not
> explicitly, but this is a possible interpretation of the technical
> requirements presented in regulatory documents. In Germany, it is proh= ibited.
>
> Hans-Joachim
>
> Am 26.02.2018 um 09:04 schrieb Abdussalam Baryun:
>
>=C2=A0 =C2=A0 =C2=A0The experience test you referred to is not clarifie= d, was it a ITS
>=C2=A0 =C2=A0 =C2=A0environment experience or was it a fixed wireless e= xperience.
>=C2=A0 =C2=A0 =C2=A0Furthermore, the WiFi technology ieee802.11 is deve= loped so which
>=C2=A0 =C2=A0 =C2=A0WiFi technology was used. Moreover, did your experi= ence use Video
>=C2=A0 =C2=A0 =C2=A0and voice communication or your proposal is only fo= r data
>=C2=A0 =C2=A0 =C2=A0communication only.
>
>=C2=A0 =C2=A0 =C2=A0So if your IP packet are data then your experience = is right, but if
>=C2=A0 =C2=A0 =C2=A0the IP packet is carrying voice or video I don'= t agree. IMO we could
>=C2=A0 =C2=A0 =C2=A0not exclude from the draft voice and video communic= ation in the ITS
>=C2=A0 =C2=A0 =C2=A0environment/use-case.
>
>=C2=A0 =C2=A0 =C2=A0On Sun, Feb 25, 2018 at 7:58 PM, Alexandre Petrescu=
>=C2=A0 =C2=A0 =C2=A0<alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>>
>=C2=A0 =C2=A0 =C2=A0wrote:
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Le 23/02/2018 =C3=A0 18:38, Tony Li a= =C3=A9crit :
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If we put= that CAM on IP there will still be lack of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0interoper= ability,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0unless we= recommend IP to be carried by a particular
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0802.11 he= ader (Data
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0or QoS Da= ta).
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I would propose that we= use the Data header. My experience
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0with the QoS Data with = Wi-Fi was that there wasn=E2=80=99t enough of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a performance differenc= e with QoS for it to make a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0difference to the IP la= yer.
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I agree.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I propose the following text.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0OLD:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In OCB mo= de, IPv6 packets MAY be transmitted either as
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"IEEE 802.11
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Data"= ; or alternatively as "IEEE 802.11 QoS Data", as
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0illustrated in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Figure 2.=
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0NEW:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In OCB mo= de, it is RECOMMENDED to transmit IPv6 packets
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0as "IEEE
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0802.11 Da= ta" (the value of the field Subtype in the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Frame Control
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Field is = 0).
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Alex
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0________________________________= _______________
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0its mailing list
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0its@i= etf.org <mailto:its@ietf.org>=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/= mailman/listinfo/its
>
>
>
>
>=C2=A0 =C2=A0 =C2=A0______________________________________________= _
>
>=C2=A0 =C2=A0 =C2=A0its mailing list
>
>=C2=A0 =C2=A0 =C2=A0its@ietf.org &l= t;mailto:its@ietf.org>
>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/l= istinfo/its
>
>
>
> --
>
> Dr. Hans-Joachim Fischer
>
> Managing Director
>
> ------------------------------------------------------------= ----------
> ----------
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ESF News = edition 2018/1
>
> https://fischer-tech.eu/Feeds/News/= ESF-News-2018-01.pdf
>
> ------------------------------------------------------------= ----------
> ----------
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Towards deployment of C-ITS based on proven= technology
>
> Avoid risks and delay by looking on potential future technologies.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The real = advocate on ITS is ISO TC204!
>
> ------------------------------------------------------------= ----------
> ----------
>
> + + + Instaurare omnia in Christo + + +
>
> ------------------------------------------------------------= ----------
> ----------
>
> The information contained in this message is confidential and may be > legally
>
> privileged. This email is intended for the addressee(s). Addressees > may be
>
> individual persons or members of mailing list.
>
> If you are not an addressee, you are hereby notified that any use,
>
> dissemination, or reproduction of this email and its optional
> attachements is
>
> strictly prohibited and may be unlawful. If you are not an addressee,<= br> > please
>
> contact the sender by return e-mail and destroy all copies of the
> original
>
> message.
>
> ------------------------------------------------------------= ----------
> ----------
>
> ESF GmbH
>
> Fichtenweg 9
>
> 89143 Blaubeuren
>
> +4= 9 (7344) 175340 (Direct line Dr. Fischer)
>
> +4= 9 (7344) 919188 (Central office)
>
> +4= 9 (7344) 919123 (Fax)
>
> https://fischer-tech.eu=C2=A0 :=C2=A0 Main web of ESF GmbH
>
> http://its-standards.eu=C2=A0 : News on cooperative ITS standardizat= ion
>
> http://its-testing.org=C2=A0 :=C2=A0 International consultancy for co= operative
> ITS
>
> ------------------------------------------------------------= ----------
> ----------
>
> ------------------------------------------------------------= ----------
> ----------
>
> ESF online-news:http://fischer-tech.eu/Feeds/esf.rss=
>
> C-ITS online news:http://its-standards.info/Feeds/= cits.rss
>
> ESF Online Nachrichten:http://fischer-tech.de/Feeds/e= sfD.rss
>
> ------------------------------------------------------------= ----------
> ---------
>

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

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



--
=
John Kenney
Director and Principal Researcher
Toyota InfoTechnology Center, USA
465 Bernardo Avenue
Mountain View, CA 94043
Tel: 650-694-4160. Mobile: 650-224-6644
--001a114ac884166ee1056628f39f-- From nobody Mon Feb 26 19:23:05 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A30C12E05C for ; Mon, 26 Feb 2018 19:23:04 -0800 (PST) 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 7BNpg1qJS_ZC for ; Mon, 26 Feb 2018 19:23:02 -0800 (PST) Received: from resqmta-po-07v.sys.comcast.net (resqmta-po-07v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:166]) (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 7381E12E056 for ; Mon, 26 Feb 2018 19:23:02 -0800 (PST) Received: from resomta-po-09v.sys.comcast.net ([96.114.154.233]) by resqmta-po-07v.sys.comcast.net with ESMTP id qVpteE4tf5t5LqVr4e8Jy7; Tue, 27 Feb 2018 03:23:02 +0000 Received: from [172.22.228.216] ([162.210.130.3]) by resomta-po-09v.sys.comcast.net with SMTP id qVome923Ge6XYqVooe3njU; Tue, 27 Feb 2018 03:21:00 +0000 From: Tony Li Message-Id: <5CFB283E-7E51-440D-BE70-05FB2CCDCF82@tony.li> Content-Type: multipart/alternative; boundary="Apple-Mail=_6C02FC9E-14FE-4559-A11B-4B5267974A5B" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Mon, 26 Feb 2018 19:20:39 -0800 In-Reply-To: Cc: =?utf-8?B?SsOpcsO0bWUgSMOkcnJp?= , Alexandre Petrescu , =?utf-8?Q?Fran=C3=A7ois_Simon?= , "Dr. Hans-Joachim Fischer" , Abdussalam Baryun , its To: John Kenney References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <9ada5591-2af3-272d-3bc3-031bf35454c3@gmail.com> <6cdc0835-fb4c-133b-77ff-0234cfdd9ef9@fischer-tech.eu> <00eb01d3af1d$7f4e8100$7deb8300$@gmail.com> <6187cb92-5c8f-d08b-dcc2-859652d629d0@gmail.com> <002901d3af20$b966e960$2c34bc20$@eurecom.fr> X-Mailer: Apple Mail (2.3445.5.20) X-CMAE-Envelope: MS4wfDjVXQ2JISbW0sZ+G8k2T/DZzBhmvbYZKkdemuFeo28MPGAAvCk3IdRyEBx3h2Qxe2mHphUzvfr5AoWMRFcwZJg2eJd/WQeuMK2r7Sy32SRv/pL1X1+q sGu3D4ztNe8LQuu+4gvOUDOmuBSp6AzmviVTa1P138oIZWadMSI08moRjQGN2vPpl35EwXK422EhHQcMP12eEnpijM1w5iusqqeTYboZaRJx1klopDktjaL3 9I1DVNLjOwz6N6YJaug49Uzgwj5y+D1P3kHbkk57Ktd5tlW8JtJa8oAGkSERz3uBsW5qv8ZgybyQQfJEfc3shScwVL6zdn5hbCMQlg1wyMVXGbcgb1LRJUlN a5Q0ItZ6+Nme5r9UHZA55ZhWJPconA== Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 27 Feb 2018 03:23:04 -0000 --Apple-Mail=_6C02FC9E-14FE-4559-A11B-4B5267974A5B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Therefore, not only should IP-over-OCB use EDCA, it should allow the = actual user priority to come from higher layers. Please recall that there is no security over the IPv6 header and that = users have full access to the priority field. The networks that actually = do try to implement some form of QoS are forced to explicitly reclassify = all traffic entering their networks, either from their immediate = customers or from peer networks. Any IP stack not under the complete control of a network operator should = be assumed to be compromised and the diffserv code points should not be = trusted. Now, are we sure we want to make use of this? I=E2=80=99ll also remind folks that IP is running in the application = channels and so is not going to be interfering with mission critical = uses.=20 Trying to control QoS between multiple applications, some of which are = under nefarious control is likely to be a recipe for simply hurting = those that are trying to be compliant. If we simply treat everything = uniformly, we give everyone less incentive to game the system. And we = have no way of stopping them from gaming the system. Tony --Apple-Mail=_6C02FC9E-14FE-4559-A11B-4B5267974A5B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Therefore, not only = should IP-over-OCB use EDCA, it should allow the actual user priority to = come from higher layers.


Please = recall that there is no security over the IPv6 header and that users = have full access to the priority field. The networks that actually do = try to implement some form of QoS are forced to explicitly reclassify = all traffic entering their networks, either from their immediate = customers or from peer networks.

Any IP stack not under the complete = control of a network operator should be assumed to be compromised and = the diffserv code points should not be trusted.

Now, are we sure we want to make use of = this?

I=E2=80=99= ll also remind folks that IP is running in the application channels and = so is not going to be interfering with mission critical = uses. 

Trying to control QoS between multiple applications, some of = which are under nefarious control is likely to be a recipe for simply = hurting those that are trying to be compliant.  If we simply treat = everything uniformly, we give everyone less incentive to game the = system.  And we have no way of stopping them from gaming the = system.

Tony

= --Apple-Mail=_6C02FC9E-14FE-4559-A11B-4B5267974A5B-- From nobody Mon Feb 26 22:29:41 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB3A9124207 for ; Mon, 26 Feb 2018 22:29:40 -0800 (PST) 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 PJ2JKtFE6891 for ; Mon, 26 Feb 2018 22:29:37 -0800 (PST) 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 48FE61200B9 for ; Mon, 26 Feb 2018 22:29:37 -0800 (PST) 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 w1R6TY5J127530; Tue, 27 Feb 2018 07:29:34 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 167FF200C8E; Tue, 27 Feb 2018 07:29:34 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 06D14200C45; Tue, 27 Feb 2018 07:29:34 +0100 (CET) Received: from [132.166.84.15] ([132.166.84.15]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w1R6TWiI008164; Tue, 27 Feb 2018 07:29:33 +0100 To: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , "=?UTF-8?Q?'Fran=c3=a7ois_Simon'?=" , its@ietf.org References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <006301d3ace3$25f9d500$71ed7f00$@eurecom.fr> <007901d3aee3$a9985ba0$fcc912e0$@eurecom.fr> <00da01d3aef6$574c4380$05e4ca80$@eurecom.fr> <003a01d3af41$c6674cb0$5335e610$@gmail.com> <008a01d3af42$cfcdcdf0$6f6969d0$@eurecom.fr> From: Alexandre Petrescu Message-ID: <72b23b14-7afc-c253-a541-c8ffeef6e969@gmail.com> Date: Tue, 27 Feb 2018 07:29:32 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <008a01d3af42$cfcdcdf0$6f6969d0$@eurecom.fr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 27 Feb 2018 06:29:41 -0000 Do they say what means VO in AC_VO. Maybe they will need an AC_VE to stand for Vehicular. Alex Le 26/02/2018 à 21:46, Jérôme Härri a écrit : > Hi François, > > They come from IEEE 802.11-2016, section p.899, section , 9.4.2.29 EDCA > Parameter Set element, Table 9-138—Default EDCA parameter set for STA > operation if dot11OCBActivated is true > > BR, > > Jérôme > > *From:*François Simon [mailto:fygsimon@gmail.com] > *Sent:* Monday 26 February 2018 21:39 > *To:* 'Jérôme Härri'; 'Alexandre Petrescu'; its@ietf.org > *Cc:* fygsimon@gmail.com > *Subject:* RE: [ipwave] 802.11 Data vs 802.11 QoS Data in > IPv6-over-802.11-OCB > > /QoS Data combinations for OCB:/ > > /AC_VO: AIFN=2, CWmin=4 CWmax=8/ > > /AC_VI: AIFN=3, CWmin=8 CWmax=16/ > > /AC_BE: AIFN=6, CWmin=16 CWmax=1024/ > > /AC_BK: AIFN=9, CWmin=16 CWmax=1024/ > > I am not sure where these values come from: > > AIFSN: The values assigned for each AC are the***DEFAULT*values. Those > values may not fit all applications. This attribute specifies the number > of slots, after a SIFS, that the STA, > > for a particular AC, senses the medium idle either before transmitting > or executing a backoff.  The value is (*2..15*); > > CWmin: The minimum contention window size is defined by the aCWmin > value. This attribute specifies the value of the minimum size of the > window that is used by a STA for a particular AC for generating a random > number for the backoff. It is calculated by 2^x – 1 where x is an > integer. aCWmin is***0..255* > > CWmax: The maximum contention window size is defined by aCWmax. The > aCWmax is ***0..65535* > > The defaults for CWmin and CWmax are specified in IEEE 802.11-2016, > Clause 9.4.2.29 EDCA Parameter Set element. > > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Jérôme Härri > Sent: Monday, February 26, 2018 6:39 AM > To: 'Alexandre Petrescu' >; its@ietf.org > Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB > > Hi Alex, All, > > After double checking IEEE802.11-2016, here are two aspects I need to > correct (sorry for my mistake)L: > > 1) both data and QoSData are allowed when Dot11OCBActivated=true; > > 2) EDCA parameters were wrong ( I wrongly used the nonOCB ones) > > QoS Data combinations for OCB: > > AC_VO: AIFN=2, CWmin=4 CWmax=8 > > AC_VI: AIFN=3, CWmin=8 CWmax=16 > > AC_BE: AIFN=6, CWmin=16 CWmax=1024 > > AC_BK: AIFN=9, CWmin=16 CWmax=1024 > > Both Data and QoSData are theoretically possible, so indeed the draft > should cover this aspect. > > Yet, I still suggest to keep QoS for IPv6, again as even if it does not > bring much 'now' for IPv6, it does not cost much either...and we should > not forgot that we might interact with EDCA transmissions (QoS) and as > such could create harmful interference on the DSRC/ITS-G5 channels. > > BR, > > Jérôme > > -----Original Message----- > > From: its [mailto:its-bounces@ietf.org] On Behalf Of Jérôme Härri > > Sent: Monday 26 February 2018 10:25 > > To: 'Alexandre Petrescu'; its@ietf.org > > Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB > > Hi Alex, > >> That is a requirement. > >> > >> But is there an implementation of mapping the priority of CAM over DENM into a QoS Control field in QoS Data Header? > >> > >> I doubt there is, because the implementations of CAM I see put the Priority field to 6, which means Voice.  So they transmit CAM as Voice even though it is not voice. > >> > >> We can not reckon in IPv6-over-OCB document something which makes little sense (send CAM as Voice). > > Of course there is....the QoS fields actually means the Access > Categories (AC) for WLAN, so EDCA. Both in ETSI and in WAVE they use the > QoS Control filed of IEE 802.11p to send CAM/BSM with higher priority > (from a MAC perspective)...When looking at the EDCA 'naming' you should > not care much of the 'name'...this was done at the time internet was > only composed of voice, video etc..you should look at the underlying > values of each AC. > > So, EDCA is composed of two fields: > > 1) AIFN - a deterministic idle time before even considering reducing CW > > 2) CW - a random timer to decrease each time the channel is idle. > > QoS Data combinations for OCB: > > AC_VO: AIFN=2, CW=8 > > AC_VI: AIFN=2, CW=16 > > AC_BE: AIFN=3, CW=32 > > AC_BK: AIFN=7, CW=32 > > So, it does not matter the name (Voice, video)..what matters is that in > implementation (BSM for instance), AIFN=2 so that it takes the fastest > access (deterministic) and as such has the highest priority. This is > also what you found: CAM on Priority field 6, so AC_VI so AIFN=2. BSM > uses the same strategy. > > Now, on the CAR 2 CAR specification, it is recommended a different > priority: AC_BE, as it uses DP2. The reason behind this is the CAR2CAR > provides a 'strict' prioritization between DENMs and CAMs. Emergency > DENMs uses AC_VI, normal DENM uses AC_VO, CAM uses AC_BE and any other > traffic AC_BK. > > So, bottom line is: all ETSI and WAVE implementation use the QoS Data > field as they use EDCA. If you found an implementation that does not use > the QoS, it is wrong according to the standard. > >>> Now, as you abstract ETSI and WAVE (thus pure IP), my understanding > >>> is that QoS remains required from the IEEE 802.11p (ok, IEEE > >>> 802.11-2016 OCB) as there is a specification of the EDCA parameters > >>> for OCB. Besides, I do not think it costs much to keep the EDCA in, > >>> as it first allows to safe a half of the MAC queueing time (the EDCA > >>> parameters for the two low AC are less, up to a quarter of a > >>> DIFS...so, it could be beneficial to allow this even for IP. Second, > >>> the EDCA allows TXOpps (Transmit Opportunities)..although put to > >>> 'zero' for OCB (I think), this mechanism still allows an AP to > >>> reserve a given time a long(er) connectivity with one device (e. > >>> streaming of video etc..). Finally, it does not cost anything..you > >>> can always take the lowest AC and you get the same behavior as non-QoS.. > >>Well, this text is more informal in nature.   It is something that > >>describes a potential behaviour but we have no proof of existing such behaviour, no proof of interoperability.  This could be part of an INFORMATIONAL Internet Draft. > > Well, my text is informal, but the specs are not. IEEE 802.11p (IEEE > 802.11-2016 OCB) uses EDCA not DCF...as this is L2 layer, I do not think > anything is required from IETF...just follow the IEEE 802.11-2016 specs > and do whatever is allows above it...I will double check again on the > IEEE 802.11-2016, but if what I think is confirmed, the whole discussion > does not make any sense..., as it is my understanding that the OCB > requires EDCA, so QoS_Data...so, you cannot change that at IP level. > >>> Bottom line, the fact that some IP implementation to decode OCB > >>> assume non-QoS frames looks more to me like an implementation error > >>> and we should not propagate this... > >>Well, wireshark has problems interpreting 802.11 QoS Data containing CAM messages.  Many receivers of QoS Data dont know what to do with the fields because they are not agreed. > > Yes, and this is why is the prototype we use, we actually have an parser > for CAM to be supported by Wireshark...it does not come by default. But > I am surprised..what kind of problem would wireshark face with the QoS > Data? > >> I don't want to propagate that disagreement into the IP-over-OCB draft. > > To me, this looks more like an implementation issue, rather than a > standard issue...but I will ask my team to check on our prototype... > >>> C-V2X will not use IP for CAM, > >>LTE-V2X will carry CAM in IP.  What is C-V2X and why does not it use IP? > > Sorry, it will not. In C-V2X (the widely known name...LTE-V2X is again a > bit like 802.11p...'LTE Prose for V2X' is the real name...), mode 4 > (ad-hoc mode..currently chosen by all vendors (except maybe Huawei, but > might have changed), there is two options for protocol stack: IPv6 > (again, only IPv6) and non-IP (L2)...you can use non-IP packets and it > is so mentioned that BSM and CAM will use the non-IP option, as it is > also required to use the ETSI/WAVE security provisions to secure the > C-V2X mode 4 (as no SIM= no security), as the ETSI/WAVE security > provisions works for non-IP packets (geonet or WSM)... > > Of course, it does not block from using IP...it is again the same > discussion we had with ITS-G5/DSRC...for safety communication, IP is not > required...you can do everything without and faster. And considering > that IEEE 802.11p (ok, OCB) and C-V2X mode 4 (no SIM=no SEC) DO NOT have > any form of security mechanism embedded, they must use the those > specified by ETSI/WAVE for accessing CCH. > > Again, C-V2X mode 4 (the current V2X techno for Safety-critical > communication) shall not be seen as following the same path as other > cellular techno. It does not provide QoS (at all), as it channel access > is contention-based (a bit like CSMA)...so collisions will occur (unlike > 4G and 5G operated, where you are either dropped or you pass). And as > such, IP is also not required, even if all 4G and 5G use IP. > >>> ETSI and WAVE will not use IP for CAM... > >>That is their problem. > > Disagree: you need to be compatible with them...so, whatever IETF will > do shall not break anything that has been done on ETSI or WAVE. This is > one of the requirement for accessing the ITS-G5 spectrum in EU, and I > believe the same in the US. > >>ETSI transports IP over GeoNetworking - that is not the right way to do it. > > Disagree: we need to integrate security mechanisms specified by ETSI > even if we use IPv6. Today, we do not have any security specification > providing 'trust', privacy and authentication for using 802.11-OCB (I > believe it is the work of IPWAVE and it is not completed yet...). > > The mistake ETSI did is to try to be nice with IETF and help them to > provide a way to use IPv6 over ITS-G5 in a secured way...WAVE took a > different path: 'not my problem', which then explain why ETSI officially > does not endorse IPWAVE (unfortunately, despite my many discussions with > them)...from an ETSI perspective, using IPv6 over ITS-G5 is > solved...(might be ugly, but it is solved). > >>> the basic CAMs are used for pure positioning > >>The mandatory fields in CAM or more than just lat/long/altitude.  There is also mandatory time in a strange format, car dimensions, curve, non standard precisions and more. > > Yes, correct...but these are configurable fields, which may or may not > be integrated...recent studies even showed that even the standard CAM > size is not clear anymore..you have a 'range' of size, and that is a > problem for wireless optimization...especially if you need to do > wireless congestion control. > >>> and the recent 'increase' of information put in CAM > >>If CAM worries about size, I think CAM should think about its existing redundancy.  For example, position is carried twice in a CAM message: in the CAM itself and in the GeoNetworking header.  That >is an issue they should address first. > > Well, of course, this is a waste...but one reason for such existence is > from the possibility to relay a packet (agnostic from the upper > messages, unfortunately, we cannot use a Zero-NET for CAM as it is pure > 1-hop TSB)... > > Yet, today we start seeing even BSM investigating ways to do multi-hop > 'position' based relaying to reach longer distance. > > And if you think about it, one day, your IPv6-over-OCB might need to use > a multi-hop networking protocol (e.g. MANET)..but doing the MANET way is > highly mobile environment will not be that efficient...position-based > mechanisms will be required (proven in various previous studies)...now, > your L3 will not be able to inspect the GPS position of your > CAM-over-IP...so, you will need to have GPS (or so) position at IP/L3, > which will end up being similar than now... > > If you do not want to do this, then the IRTF people might come with ICN, > but then would this be done above L3 or at L3...if still at L3, you > still will have a contextual L3 packet that might be redundant with > application/service layer messages...(the cost of using OSI) > > But this is just my personal view and very long term...for now, if we > only look at CAM, indeed we can have twice the GPS position (but wait: > not the same granularity and you do not have elevation in geonet). But > if you look at  the bigger picture: doing CAM-over-geonet only required > a single CAM, that's it. For IPv6-over-OCB, you need all the IPv6 > address autoconfiguration..that requires additional IPv6 packets to be > transmitted...this is similar to compare an apple with a tomato. > >>> looks to be like a bad strategy as we end up having a container > >>> carrying too many things and being too big for what it is... > >>I agree.  But I think we should compare header sizes and then there will be surprises. > >>CAM transported in IP may be a smaller packet than CAM transported in BTP and GeoNetworking. > > Not that much if you counts also all IPv6-related control/management > packets required to transmit your CAM-over-OCB, in a highly dynamic > environment... > >> (WLAN is good at squeezing various small packets but really not good > >> at big things especially in broadcast mode)...a better strategy would > >> be to define new messages tailored to the information needs, and have > >> smart service scheduling...(especially benefiting from IP-related > >> mechanisms) > >> I fully agree with this. > > :-) at least we do on this :-) > > Cheers, > > Jérôme > > _______________________________________________ > > its mailing list > > its@ietf.org > > https://www.ietf.org/mailman/listinfo/its > > _______________________________________________ > > its mailing list > > its@ietf.org > > https://www.ietf.org/mailman/listinfo/its > From nobody Mon Feb 26 22:57:29 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEACB126C0F for ; Mon, 26 Feb 2018 22:57:18 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=us-toyota-itc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obYQQh1jLkTJ for ; Mon, 26 Feb 2018 22:57:17 -0800 (PST) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04D91126DEE for ; Mon, 26 Feb 2018 22:57:17 -0800 (PST) Received: by mail-io0-x235.google.com with SMTP id l12so20045945ioc.10 for ; Mon, 26 Feb 2018 22:57:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=us-toyota-itc-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ln6O24MOAPESfhmNUbi2Fqk2U6kRM9Cxhn+LlSMseeA=; b=p3Rc/4ecRQE6EqNdcGWBs+FMb6cr9xTEuWJrPRI7fmbV2dtrcJxWFmg0801iM635Ag HsGnWZOb+pO+KcEVZVBPkTJITzFYTAqGRoKqVnEnnj5xbTEnjrxBAWpR9t3waWWbVFPQ wYL/tCTLTolQ3nFkcvTVgOdRVVPmdZWQdK99d0hX7YqmdFKqJJsiAAtYYeuq0hnDTWZJ pPJVKnDudlzAUT74PRzMkFeqMhsgatvZFrHuZV2TmVv4aOFbbSk1zGh1R9cMr3rZzjR2 8oiLO0qoAyjy4aYZqqBOjEMYpYucfp1bUj7/gmjSWwVPFSAd5lE34d7eCtJzt9s5/eYM 0yJw== 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=ln6O24MOAPESfhmNUbi2Fqk2U6kRM9Cxhn+LlSMseeA=; b=XvRM7ynzctVc9+w5HLTtux1ByNzybE0WyRrA3XV1sFxF3MYWXRtpCkaijI2DUoJQB7 0D7HInQ6gHh0IpkL0gQljv2OXEet72axciX7sbdmqDVi5Ksu1FbhAv+EEsZfBSWVIbhv 8jt/fkV4kwLTJGTqKlVGpwMNETTrMGlGIhfuso6mmucabtI1wgwf4gCu05ZXeQUgGDRu m0mhFnfLcGf9OfnWk7IMAdFI6QW+m5k80BQ93MT8hF9LEhVjuJeIz4dW9tnLzi6cz7Uv yYdzs2k0sLtkV79WAbevgZRQMn26+IWtgrhwBJiXPbgfKKtAlsq367O8tDhfu7SuSTOS DoFA== X-Gm-Message-State: APf1xPD1if3xP3B5PnOmqoMnvWIUpDgjSS3lPBYjZjSnbqHkqwkSnan5 GZq5nJE8niQmZep972Z1OC6CgXlOeDcEFaCgIfLf2Q== X-Google-Smtp-Source: AG47ELt/8pS/FqAivsDW50kGvy8RdHMzrb4dYyO3cZjXI76cKWQ33KiHXKnnEgplSq/N5lI2l9gRvhI91zwkjMr1mns= X-Received: by 10.107.146.86 with SMTP id u83mr14075689iod.235.1519714636249; Mon, 26 Feb 2018 22:57:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.24.135 with HTTP; Mon, 26 Feb 2018 22:57:15 -0800 (PST) In-Reply-To: <5CFB283E-7E51-440D-BE70-05FB2CCDCF82@tony.li> References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <9ada5591-2af3-272d-3bc3-031bf35454c3@gmail.com> <6cdc0835-fb4c-133b-77ff-0234cfdd9ef9@fischer-tech.eu> <00eb01d3af1d$7f4e8100$7deb8300$@gmail.com> <6187cb92-5c8f-d08b-dcc2-859652d629d0@gmail.com> <002901d3af20$b966e960$2c34bc20$@eurecom.fr> <5CFB283E-7E51-440D-BE70-05FB2CCDCF82@tony.li> From: John Kenney Date: Mon, 26 Feb 2018 22:57:15 -0800 Message-ID: To: Tony Li Cc: Abdussalam Baryun , Alexandre Petrescu , "Dr. Hans-Joachim Fischer" , =?UTF-8?Q?Fran=C3=A7ois_Simon?= , =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , its Content-Type: multipart/alternative; boundary="94eb2c054fa60de35a05662c23e0" Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 27 Feb 2018 06:57:19 -0000 --94eb2c054fa60de35a05662c23e0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tony, If priority settings passing through IPv6 can=E2=80=99t be trusted then I a= gree to treat all the IP traffic uniformly. In that case it is probably best to map it all to the AC_BK so it will not interfere with critical DSRC traffic. For the reasons previously stated, it can=E2=80=99t be DCF. BTW in the US band plan there are no non-critical channels or "application" channels. All channels are expected to carry critical traffic. See SAE J2945/0 (Table 4) for the recommended channel usage plan. You=E2=80=99ll se= e that IPv6 traffic is expected to share channels with I2V safety and mobility, with V2P safety, with automated driving support, etc. Table 3 shows recommended priority settings, and I note that SCMS communication, which is expected to use IPv6, is recommended to use AC_BK. In Europe it is similar, except that the lowest two channels are explicitly designated only for non-safety applications, though I would caution that non-safety does not mean =E2=80=9Clacking performance requirements =E2=80= =9C. Best Regards, John On Mon, Feb 26, 2018 at 7:23 PM Tony Li wrote: > > Therefore, not only should IP-over-OCB use EDCA, it should allow the > actual user priority to come from higher layers. > > > > Please recall that there is no security over the IPv6 header and that > users have full access to the priority field. The networks that actually = do > try to implement some form of QoS are forced to explicitly reclassify all > traffic entering their networks, either from their immediate customers or > from peer networks. > > Any IP stack not under the complete control of a network operator should > be assumed to be compromised and the diffserv code points should not be > trusted. > > Now, are we sure we want to make use of this? > > I=E2=80=99ll also remind folks that IP is running in the application chan= nels and > so is not going to be interfering with mission critical uses. > > Trying to control QoS between multiple applications, some of which are > under nefarious control is likely to be a recipe for simply hurting those > that are trying to be compliant. If we simply treat everything uniformly= , > we give everyone less incentive to game the system. And we have no way o= f > stopping them from gaming the system. > > Tony > > --94eb2c054fa60de35a05662c23e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tony,=C2=A0

If priority settings passing through IPv6 ca= n=E2=80=99t be trusted then I agree to treat all the IP traffic uniformly. = In that case it is probably best to map it all to the AC_BK so it will not = interfere with critical DSRC traffic. For the reasons previously stated, it= can=E2=80=99t be DCF.

B= TW in the US band plan there are no non-critical channels or "applicat= ion" channels. All channels are expected to carry critical traffic. Se= e SAE J2945/0 (Table 4) for the recommended channel usage plan. You=E2=80= =99ll see that IPv6 traffic is expected to share channels with I2V safety a= nd mobility, with V2P safety, with automated driving support, etc.=C2=A0 Ta= ble 3 shows recommended priority settings, and I note that SCMS communicati= on, which is expected to use IPv6, is recommended to use AC_BK.

In Europe it is similar, except tha= t the lowest two channels are explicitly designated only for non-safety app= lications, though I would caution that non-safety does not mean =E2=80=9Cla= cking performance requirements =E2=80=9C.

=
Best Regards,
John

On Mon, Feb 26, 2018 at 7:23 PM Tony Li <tony.li@tony.li> wrote:
=

Therefore, not only should IP-over-OCB use EDC= A, it should allow the actual user priority to come from higher layers.


Please recall that there is= no security over the IPv6 header and that users have full access to the pr= iority field. The networks that actually do try to implement some form of Q= oS are forced to explicitly reclassify all traffic entering their networks,= either from their immediate customers or from peer networks.
Any IP stack not under the complete control of a network operat= or should be assumed to be compromised and the diffserv code points should = not be trusted.

Now, are we sure we want to make u= se of this?

I=E2=80=99ll also remind folks that IP= is running in the application channels and so is not going to be interferi= ng with mission critical uses.=C2=A0

Trying to con= trol QoS between multiple applications, some of which are under nefarious c= ontrol is likely to be a recipe for simply hurting those that are trying to= be compliant.=C2=A0 If we simply treat everything uniformly, we give every= one less incentive to game the system.=C2=A0 And we have no way of stopping= them from gaming the system.

Tony

--94eb2c054fa60de35a05662c23e0-- From nobody Mon Feb 26 23:23:28 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B02DE124B18 for ; Mon, 26 Feb 2018 23:23:26 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=us-toyota-itc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V83lamQ2sR6w for ; Mon, 26 Feb 2018 23:23:18 -0800 (PST) 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 0513E1200B9 for ; Mon, 26 Feb 2018 23:23:18 -0800 (PST) Received: by mail-io0-x233.google.com with SMTP id l12so20115598ioc.10 for ; Mon, 26 Feb 2018 23:23:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=us-toyota-itc-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3lpbspsuuMQJU93DZb6fpmNyR+/ggOMa0ORM/eGe5a0=; b=aH8Hd7MuGZC24pE3Dxs0jjeg6e53Cie5IMoXhFW7lNJVAWwcLuZVQV0EVvvBsc4T6G zxuL2iB+CS77RYHQzMD0kRVOhoC7fyC/20CQNtbgGlCOhrVyk6sRHYXT2Z4M5m1fAhu3 vPyDiCMFLoDqqv+6j2q3CYVA1tkiqBLTCtdSL01kYmT+TabJyruIB3/Uvg2tYnVgDemV GNuIvxWQNppf1TgleSO9M7zx+2EVA4MXY7aAWUzo21Sij203K4APbZEP/6tAaH2sxhpf 3F+HjOZSGW3M2zgeIW7Nas1zGFPbjWqGYeobuUTtSTUHigx8saazkohfZlE4nTbz8end WoLw== 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=3lpbspsuuMQJU93DZb6fpmNyR+/ggOMa0ORM/eGe5a0=; b=lr9JYtz6hTD28eoeIZkOe4bfFg2U5nR32xYjOsNEO2zMjUSbjzFK33klFSGUa656Zk lPiLy+/HP1C6wwO+a7aj8yVMvqgUukRlr23dt88QKtZkyL/EgY9iaOXUuECuaNGtiySk zD3gehNQUdWNNq4TYxzlKyTjKLfT/ZrKzaDv67pKFv8c16IF+5Pn0KQbSoauylPuhFUP mB61rArj+v88AVG8CU5UVuGLvCqtAaADlbUSVji45BiB5Fq1sR/UlMbD4ww4U6gohXYj dGSdIQG3UWcYmmYMayFPD5FHIQinYErCWwX88F6CyDRUUMJKxPSjNE43mk6hmhdn0e3v qnNA== X-Gm-Message-State: APf1xPANx/T7U1wI0LY+ibQZdRCzNvhL3TZcJeenicpxeB+t877R8HHk cuGbNIYxSD4uydpdk5tNhcI3VJqCfw7bgS6UkV26bg== X-Google-Smtp-Source: AH8x2247qMMdBGGoPQUkh6cdDQoglU70TpSavcVLPiI/EBCkY7lB7KpKWZAQ56h8rhY10oi+nNEKRMaMV1eEwpthvbU= X-Received: by 10.107.131.218 with SMTP id n87mr15499840ioi.268.1519716197129; Mon, 26 Feb 2018 23:23:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.24.135 with HTTP; Mon, 26 Feb 2018 23:23:16 -0800 (PST) In-Reply-To: <72b23b14-7afc-c253-a541-c8ffeef6e969@gmail.com> References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <006301d3ace3$25f9d500$71ed7f00$@eurecom.fr> <007901d3aee3$a9985ba0$fcc912e0$@eurecom.fr> <00da01d3aef6$574c4380$05e4ca80$@eurecom.fr> <003a01d3af41$c6674cb0$5335e610$@gmail.com> <008a01d3af42$cfcdcdf0$6f6969d0$@eurecom.fr> <72b23b14-7afc-c253-a541-c8ffeef6e969@gmail.com> From: John Kenney Date: Mon, 26 Feb 2018 23:23:16 -0800 Message-ID: To: Alexandre Petrescu Cc: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , =?UTF-8?Q?Fran=C3=A7ois_Simon?= , its Content-Type: multipart/alternative; boundary="001a113ebe4e16f7b705662c80d1" Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 27 Feb 2018 07:23:27 -0000 --001a113ebe4e16f7b705662c80d1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alex, As I mentioned in another email, these labels VO/VI/BE/BK are historical (going back to the 2005 802.11e amendment) and merely illustrative of four application classes in a generic WLAN. AC_VO was never intended to be limited only to voice flows. 802.11 QoS is inherently relative, so you don't just create more access categories when new applications come along. There are only four access categories in standard EDCA. The labels don't mean much. What matters are the set of EDCA parameters associated with each AC. These could be from the default set or (as in the case of Ch. 172) something different. We wouldn't use AC_VE to mean vehicular because we use all four ACs in vehicular communication (OCB). The whole band is restricted to vehicular communication, and we need to prioritize within that universe. John On Mon, Feb 26, 2018 at 10:29 PM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > Do they say what means VO in AC_VO. > > Maybe they will need an AC_VE to stand for Vehicular. > > Alex > > Le 26/02/2018 =C3=A0 21:46, J=C3=A9r=C3=B4me H=C3=A4rri a =C3=A9crit : > >> Hi Fran=C3=A7ois, >> >> They come from IEEE 802.11-2016, section p.899, section , 9.4.2.29 EDCA >> Parameter Set element, Table 9-138=E2=80=94Default EDCA parameter set fo= r STA >> operation if dot11OCBActivated is true >> >> BR, >> >> J=C3=A9r=C3=B4me >> >> *From:*Fran=C3=A7ois Simon [mailto:fygsimon@gmail.com] >> *Sent:* Monday 26 February 2018 21:39 >> *To:* 'J=C3=A9r=C3=B4me H=C3=A4rri'; 'Alexandre Petrescu'; its@ietf.org >> *Cc:* fygsimon@gmail.com >> *Subject:* RE: [ipwave] 802.11 Data vs 802.11 QoS Data in >> IPv6-over-802.11-OCB >> >> /QoS Data combinations for OCB:/ >> >> /AC_VO: AIFN=3D2, CWmin=3D4 CWmax=3D8/ >> >> /AC_VI: AIFN=3D3, CWmin=3D8 CWmax=3D16/ >> >> /AC_BE: AIFN=3D6, CWmin=3D16 CWmax=3D1024/ >> >> /AC_BK: AIFN=3D9, CWmin=3D16 CWmax=3D1024/ >> >> I am not sure where these values come from: >> >> AIFSN: The values assigned for each AC are the***DEFAULT*values. Those >> values may not fit all applications. This attribute specifies the number= of >> slots, after a SIFS, that the STA, >> >> for a particular AC, senses the medium idle either before transmitting o= r >> executing a backoff. The value is (*2..15*); >> >> CWmin: The minimum contention window size is defined by the aCWmin value= . >> This attribute specifies the value of the minimum size of the window tha= t >> is used by a STA for a particular AC for generating a random number for = the >> backoff. It is calculated by 2^x =E2=80=93 1 where x is an integer. aCWm= in >> is***0..255* >> >> CWmax: The maximum contention window size is defined by aCWmax. The >> aCWmax is ***0..65535* >> >> The defaults for CWmin and CWmax are specified in IEEE 802.11-2016, >> Clause 9.4.2.29 EDCA Parameter Set element. >> >> -----Original Message----- >> From: its [mailto:its-bounces@ietf.org] On Behalf Of J=C3=A9r=C3=B4me H= =C3=A4rri >> Sent: Monday, February 26, 2018 6:39 AM >> To: 'Alexandre Petrescu' > alexandre.petrescu@gmail.com>>; its@ietf.org >> Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in >> IPv6-over-802.11-OCB >> >> Hi Alex, All, >> >> After double checking IEEE802.11-2016, here are two aspects I need to >> correct (sorry for my mistake)L: >> >> 1) both data and QoSData are allowed when Dot11OCBActivated=3Dtrue; >> >> 2) EDCA parameters were wrong ( I wrongly used the nonOCB ones) >> >> QoS Data combinations for OCB: >> >> AC_VO: AIFN=3D2, CWmin=3D4 CWmax=3D8 >> >> AC_VI: AIFN=3D3, CWmin=3D8 CWmax=3D16 >> >> AC_BE: AIFN=3D6, CWmin=3D16 CWmax=3D1024 >> >> AC_BK: AIFN=3D9, CWmin=3D16 CWmax=3D1024 >> >> Both Data and QoSData are theoretically possible, so indeed the draft >> should cover this aspect. >> >> Yet, I still suggest to keep QoS for IPv6, again as even if it does not >> bring much 'now' for IPv6, it does not cost much either...and we should = not >> forgot that we might interact with EDCA transmissions (QoS) and as such >> could create harmful interference on the DSRC/ITS-G5 channels. >> >> BR, >> >> J=C3=A9r=C3=B4me >> >> -----Original Message----- >> >> From: its [mailto:its-bounces@ietf.org] On Behalf Of J=C3=A9r=C3=B4me H= =C3=A4rri >> >> Sent: Monday 26 February 2018 10:25 >> >> To: 'Alexandre Petrescu'; its@ietf.org >> >> >> Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in >> IPv6-over-802.11-OCB >> >> Hi Alex, >> >> That is a requirement. >>> >> >> >>> >> But is there an implementation of mapping the priority of CAM over DENM >>> into a QoS Control field in QoS Data Header? >>> >> >> >>> >> I doubt there is, because the implementations of CAM I see put the >>> Priority field to 6, which means Voice. So they transmit CAM as Voice = even >>> though it is not voice. >>> >> >> >>> >> We can not reckon in IPv6-over-OCB document something which makes little >>> sense (send CAM as Voice). >>> >> >> Of course there is....the QoS fields actually means the Access Categorie= s >> (AC) for WLAN, so EDCA. Both in ETSI and in WAVE they use the QoS Contro= l >> filed of IEE 802.11p to send CAM/BSM with higher priority (from a MAC >> perspective)...When looking at the EDCA 'naming' you should not care muc= h >> of the 'name'...this was done at the time internet was only composed of >> voice, video etc..you should look at the underlying values of each AC. >> >> So, EDCA is composed of two fields: >> >> 1) AIFN - a deterministic idle time before even considering reducing CW >> >> 2) CW - a random timer to decrease each time the channel is idle. >> >> QoS Data combinations for OCB: >> >> AC_VO: AIFN=3D2, CW=3D8 >> >> AC_VI: AIFN=3D2, CW=3D16 >> >> AC_BE: AIFN=3D3, CW=3D32 >> >> AC_BK: AIFN=3D7, CW=3D32 >> >> So, it does not matter the name (Voice, video)..what matters is that in >> implementation (BSM for instance), AIFN=3D2 so that it takes the fastest >> access (deterministic) and as such has the highest priority. This is als= o >> what you found: CAM on Priority field 6, so AC_VI so AIFN=3D2. BSM uses = the >> same strategy. >> >> Now, on the CAR 2 CAR specification, it is recommended a different >> priority: AC_BE, as it uses DP2. The reason behind this is the CAR2CAR >> provides a 'strict' prioritization between DENMs and CAMs. Emergency DEN= Ms >> uses AC_VI, normal DENM uses AC_VO, CAM uses AC_BE and any other traffic >> AC_BK. >> >> So, bottom line is: all ETSI and WAVE implementation use the QoS Data >> field as they use EDCA. If you found an implementation that does not use >> the QoS, it is wrong according to the standard. >> >> Now, as you abstract ETSI and WAVE (thus pure IP), my understanding >>>> >>> >> is that QoS remains required from the IEEE 802.11p (ok, IEEE >>>> >>> >> 802.11-2016 OCB) as there is a specification of the EDCA parameters >>>> >>> >> for OCB. Besides, I do not think it costs much to keep the EDCA in, >>>> >>> >> as it first allows to safe a half of the MAC queueing time (the EDCA >>>> >>> >> parameters for the two low AC are less, up to a quarter of a >>>> >>> >> DIFS...so, it could be beneficial to allow this even for IP. Second, >>>> >>> >> the EDCA allows TXOpps (Transmit Opportunities)..although put to >>>> >>> >> 'zero' for OCB (I think), this mechanism still allows an AP to >>>> >>> >> reserve a given time a long(er) connectivity with one device (e. >>>> >>> >> streaming of video etc..). Finally, it does not cost anything..you >>>> >>> >> can always take the lowest AC and you get the same behavior as non-QoS.. >>>> >>> >> Well, this text is more informal in nature. It is something that >>> >> >> describes a potential behaviour but we have no proof of existing such >>> behaviour, no proof of interoperability. This could be part of an >>> INFORMATIONAL Internet Draft. >>> >> >> Well, my text is informal, but the specs are not. IEEE 802.11p (IEEE >> 802.11-2016 OCB) uses EDCA not DCF...as this is L2 layer, I do not think >> anything is required from IETF...just follow the IEEE 802.11-2016 specs = and >> do whatever is allows above it...I will double check again on the IEEE >> 802.11-2016, but if what I think is confirmed, the whole discussion does >> not make any sense..., as it is my understanding that the OCB requires >> EDCA, so QoS_Data...so, you cannot change that at IP level. >> >> Bottom line, the fact that some IP implementation to decode OCB >>>> >>> >> assume non-QoS frames looks more to me like an implementation error >>>> >>> >> and we should not propagate this... >>>> >>> >> Well, wireshark has problems interpreting 802.11 QoS Data containing CAM >>> messages. Many receivers of QoS Data dont know what to do with the fie= lds >>> because they are not agreed. >>> >> >> Yes, and this is why is the prototype we use, we actually have an parser >> for CAM to be supported by Wireshark...it does not come by default. But = I >> am surprised..what kind of problem would wireshark face with the QoS Dat= a? >> >> I don't want to propagate that disagreement into the IP-over-OCB draft. >>> >> >> To me, this looks more like an implementation issue, rather than a >> standard issue...but I will ask my team to check on our prototype... >> >> C-V2X will not use IP for CAM, >>>> >>> >> LTE-V2X will carry CAM in IP. What is C-V2X and why does not it use IP? >>> >> >> Sorry, it will not. In C-V2X (the widely known name...LTE-V2X is again a >> bit like 802.11p...'LTE Prose for V2X' is the real name...), mode 4 (ad-= hoc >> mode..currently chosen by all vendors (except maybe Huawei, but might ha= ve >> changed), there is two options for protocol stack: IPv6 (again, only IPv= 6) >> and non-IP (L2)...you can use non-IP packets and it is so mentioned that >> BSM and CAM will use the non-IP option, as it is also required to use th= e >> ETSI/WAVE security provisions to secure the C-V2X mode 4 (as no SIM=3D n= o >> security), as the ETSI/WAVE security provisions works for non-IP packets >> (geonet or WSM)... >> >> Of course, it does not block from using IP...it is again the same >> discussion we had with ITS-G5/DSRC...for safety communication, IP is not >> required...you can do everything without and faster. And considering tha= t >> IEEE 802.11p (ok, OCB) and C-V2X mode 4 (no SIM=3Dno SEC) DO NOT have an= y >> form of security mechanism embedded, they must use the those specified b= y >> ETSI/WAVE for accessing CCH. >> >> Again, C-V2X mode 4 (the current V2X techno for Safety-critical >> communication) shall not be seen as following the same path as other >> cellular techno. It does not provide QoS (at all), as it channel access = is >> contention-based (a bit like CSMA)...so collisions will occur (unlike 4G >> and 5G operated, where you are either dropped or you pass). And as such,= IP >> is also not required, even if all 4G and 5G use IP. >> >> ETSI and WAVE will not use IP for CAM... >>>> >>> >> That is their problem. >>> >> >> Disagree: you need to be compatible with them...so, whatever IETF will d= o >> shall not break anything that has been done on ETSI or WAVE. This is one= of >> the requirement for accessing the ITS-G5 spectrum in EU, and I believe t= he >> same in the US. >> >> ETSI transports IP over GeoNetworking - that is not the right way to do >>> it. >>> >> >> Disagree: we need to integrate security mechanisms specified by ETSI eve= n >> if we use IPv6. Today, we do not have any security specification providi= ng >> 'trust', privacy and authentication for using 802.11-OCB (I believe it i= s >> the work of IPWAVE and it is not completed yet...). >> >> The mistake ETSI did is to try to be nice with IETF and help them to >> provide a way to use IPv6 over ITS-G5 in a secured way...WAVE took a >> different path: 'not my problem', which then explain why ETSI officially >> does not endorse IPWAVE (unfortunately, despite my many discussions with >> them)...from an ETSI perspective, using IPv6 over ITS-G5 is solved...(mi= ght >> be ugly, but it is solved). >> >> the basic CAMs are used for pure positioning >>>> >>> >> The mandatory fields in CAM or more than just lat/long/altitude. There >>> is also mandatory time in a strange format, car dimensions, curve, non >>> standard precisions and more. >>> >> >> Yes, correct...but these are configurable fields, which may or may not b= e >> integrated...recent studies even showed that even the standard CAM size = is >> not clear anymore..you have a 'range' of size, and that is a problem for >> wireless optimization...especially if you need to do wireless congestion >> control. >> >> and the recent 'increase' of information put in CAM >>>> >>> >> If CAM worries about size, I think CAM should think about its existing >>> redundancy. For example, position is carried twice in a CAM message: i= n >>> the CAM itself and in the GeoNetworking header. That >is an issue they >>> should address first. >>> >> >> Well, of course, this is a waste...but one reason for such existence is >> from the possibility to relay a packet (agnostic from the upper messages= , >> unfortunately, we cannot use a Zero-NET for CAM as it is pure 1-hop TSB)= ... >> >> Yet, today we start seeing even BSM investigating ways to do multi-hop >> 'position' based relaying to reach longer distance. >> >> And if you think about it, one day, your IPv6-over-OCB might need to use >> a multi-hop networking protocol (e.g. MANET)..but doing the MANET way is >> highly mobile environment will not be that efficient...position-based >> mechanisms will be required (proven in various previous studies)...now, >> your L3 will not be able to inspect the GPS position of your >> CAM-over-IP...so, you will need to have GPS (or so) position at IP/L3, >> which will end up being similar than now... >> >> If you do not want to do this, then the IRTF people might come with ICN, >> but then would this be done above L3 or at L3...if still at L3, you stil= l >> will have a contextual L3 packet that might be redundant with >> application/service layer messages...(the cost of using OSI) >> >> But this is just my personal view and very long term...for now, if we >> only look at CAM, indeed we can have twice the GPS position (but wait: n= ot >> the same granularity and you do not have elevation in geonet). But if yo= u >> look at the bigger picture: doing CAM-over-geonet only required a singl= e >> CAM, that's it. For IPv6-over-OCB, you need all the IPv6 address >> autoconfiguration..that requires additional IPv6 packets to be >> transmitted...this is similar to compare an apple with a tomato. >> >> looks to be like a bad strategy as we end up having a container >>>> >>> >> carrying too many things and being too big for what it is... >>>> >>> >> I agree. But I think we should compare header sizes and then there will >>> be surprises. >>> >> >> CAM transported in IP may be a smaller packet than CAM transported in BT= P >>> and GeoNetworking. >>> >> >> Not that much if you counts also all IPv6-related control/management >> packets required to transmit your CAM-over-OCB, in a highly dynamic >> environment... >> >> (WLAN is good at squeezing various small packets but really not good >>> >> >> at big things especially in broadcast mode)...a better strategy would >>> >> >> be to define new messages tailored to the information needs, and have >>> >> >> smart service scheduling...(especially benefiting from IP-related >>> >> >> mechanisms) >>> >> >> I fully agree with this. >>> >> >> :-) at least we do on this :-) >> >> Cheers, >> >> J=C3=A9r=C3=B4me >> >> _______________________________________________ >> >> its mailing list >> >> its@ietf.org >> >> https://www.ietf.org/mailman/listinfo/its >> >> _______________________________________________ >> >> its mailing list >> >> its@ietf.org >> >> https://www.ietf.org/mailman/listinfo/its >> >> > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > --=20 John Kenney Director and Principal Researcher Toyota InfoTechnology Center, USA 465 Bernardo Avenue Mountain View, CA 94043 Tel: 650-694-4160. Mobile: 650-224-6644 --001a113ebe4e16f7b705662c80d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alex,
As I mentioned in another email, these labels= VO/VI/BE/BK are historical (going back to the 2005 802.11e amendment) and = merely illustrative of four application classes in a generic WLAN. AC_VO wa= s never intended to be limited only to voice flows.=C2=A0 802.11 QoS is inh= erently relative, so you don't just create more access categories when = new applications come along. There are only four access categories in stand= ard EDCA. The labels don't mean much. What matters are the set of EDCA = parameters associated with each AC. These could be from the default set or = (as in the case of Ch. 172) something different. We wouldn't use AC_VE = to mean vehicular because we use all four ACs in vehicular communication (O= CB). The whole band is restricted to vehicular communication, and we need t= o prioritize within that universe.

John
=

O= n Mon, Feb 26, 2018 at 10:29 PM, Alexandre Petrescu <<= a href=3D"mailto:alexandre.petrescu@gmail.com" target=3D"_blank">alexandre.= petrescu@gmail.com> wrote:
= Do they say what means VO in AC_VO.

Maybe they will need an AC_VE to stand for Vehicular.

Alex

Le 26/02/2018 =C3=A0 21:46, J=C3=A9r=C3=B4me H=C3=A4rri a =C3=A9crit=C2=A0:=
Hi Fran=C3=A7ois,

They come from IEEE 802.11-2016, section p.899, section , 9.4.2.29 EDCA Par= ameter Set element, Table 9-138=E2=80=94Default EDCA parameter set for STA = operation if dot11OCBActivated is true

BR,

J=C3=A9r=C3=B4me

 *From:*Fran=C3=A7ois Simon [mailto:fygsimon@gmail.com]
*Sent:* Monday 26 February 2018 21:39
*To:* 'J=C3=A9r=C3=B4me H=C3=A4rri'; 'Alexandre Petrescu'; = its@ietf.org
*Cc:* fygsimon@gmai= l.com
*Subject:* RE: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-= OCB

/QoS Data combinations for OCB:/

/AC_VO: AIFN=3D2, CWmin=3D4 CWmax=3D8/

/AC_VI: AIFN=3D3, CWmin=3D8 CWmax=3D16/

/AC_BE: AIFN=3D6, CWmin=3D16 CWmax=3D1024/

/AC_BK: AIFN=3D9, CWmin=3D16 CWmax=3D1024/

I am not sure where these values come from:

 AIFSN: The values assigned for each AC are the***DEFAULT*values. Those valu= es may not fit all applications. This attribute specifies the number of slo= ts, after a SIFS, that the STA,

for a particular AC, senses the medium idle either before transmitting or e= xecuting a backoff.=C2=A0 The value is (*2..15*);

CWmin: The minimum contention window size is defined by the aCWmin value. T= his attribute specifies the value of the minimum size of the window that is= used by a STA for a particular AC for generating a random number for the b= ackoff. It is calculated by 2^x =E2=80=93 1 where x is an integer. aCWmin i= s***0..255*

CWmax: The maximum contention window size is defined by aCWmax. The aCWmax = is ***0..65535*

The defaults for CWmin and CWmax are specified in IEEE 802.11-2016, Clause = 9.4.2.29 EDCA Parameter Set element.

-----Original Message-----
From: its [mailto:its-bounces@ietf.org] On Behalf Of J=C3=A9r=C3=B4me H=C3=A4rri
Sent: Monday, February 26, 2018 6:39 AM
 To: 'Alexandre Petrescu' <alexandre.petrescu@gmail.com <mailto:alexandre.pe= trescu@gmail.com>>; its@ietf.org <mailto:its@ietf.org>
Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OC= B

Hi Alex, All,

After double checking IEEE802.11-2016, here are two aspects I need to corre= ct (sorry for my mistake)L:

1) both data and QoSData are allowed when Dot11OCBActivated=3Dtrue;

2) EDCA parameters were wrong ( I wrongly used the nonOCB ones)

QoS Data combinations for OCB:

AC_VO: AIFN=3D2, CWmin=3D4 CWmax=3D8

AC_VI: AIFN=3D3, CWmin=3D8 CWmax=3D16

AC_BE: AIFN=3D6, CWmin=3D16 CWmax=3D1024

AC_BK: AIFN=3D9, CWmin=3D16 CWmax=3D1024

Both Data and QoSData are theoretically possible, so indeed the draft shoul= d cover this aspect.

Yet, I still suggest to keep QoS for IPv6, again as even if it does not bri= ng much 'now' for IPv6, it does not cost much either...and we shoul= d not forgot that we might interact with EDCA transmissions (QoS) and as su= ch could create harmful interference on the DSRC/ITS-G5 channels.

BR,

J=C3=A9r=C3=B4me

-----Original Message-----

From: its [mailto:its-bounces@ietf.org] On Behalf Of J=C3=A9r=C3=B4me H=C3=A4rri

Sent: Monday 26 February 2018 10:25

 To: 'Alexandre Petrescu'; its@ietf.org <mailto:its@ietf.org>


Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OC= B

Hi Alex,

That is a requirement.



But is there an implementation of mapping the priority of CAM over DENM int= o a QoS Control field in QoS Data Header?



I doubt there is, because the implementations of CAM I see put the Priority= field to 6, which means Voice.=C2=A0 So they transmit CAM as Voice even th= ough it is not voice.



We can not reckon in IPv6-over-OCB document something which makes little se= nse (send CAM as Voice).

Of course there is....the QoS fields actually means the Access Categories (= AC) for WLAN, so EDCA. Both in ETSI and in WAVE they use the QoS Control fi= led of IEE 802.11p to send CAM/BSM with higher priority (from a MAC perspec= tive)...When looking at the EDCA 'naming' you should not care much = of the 'name'...this was done at the time internet was only compose= d of voice, video etc..you should look at the underlying values of each AC.=

So, EDCA is composed of two fields:

1) AIFN - a deterministic idle time before even considering reducing CW

2) CW - a random timer to decrease each time the channel is idle.

QoS Data combinations for OCB:

AC_VO: AIFN=3D2, CW=3D8

AC_VI: AIFN=3D2, CW=3D16

AC_BE: AIFN=3D3, CW=3D32

AC_BK: AIFN=3D7, CW=3D32

So, it does not matter the name (Voice, video)..what matters is that in imp= lementation (BSM for instance), AIFN=3D2 so that it takes the fastest acces= s (deterministic) and as such has the highest priority. This is also what y= ou found: CAM on Priority field 6, so AC_VI so AIFN=3D2. BSM uses the same = strategy.

Now, on the CAR 2 CAR specification, it is recommended a different priority= : AC_BE, as it uses DP2. The reason behind this is the CAR2CAR provides a &= #39;strict' prioritization between DENMs and CAMs. Emergency DENMs uses= AC_VI, normal DENM uses AC_VO, CAM uses AC_BE and any other traffic AC_BK.=

So, bottom line is: all ETSI and WAVE implementation use the QoS Data field= as they use EDCA. If you found an implementation that does not use the QoS= , it is wrong according to the standard.

Now, as you abstract ETSI and WAVE (thus pure IP), my understanding

is that QoS remains required from the IEEE 802.11p (ok, IEEE

802.11-2016 OCB) as there is a specification of the EDCA parameters

for OCB. Besides, I do not think it costs much to keep the EDCA in,

as it first allows to safe a half of the MAC queueing time (the EDCA

parameters for the two low AC are less, up to a quarter of a

DIFS...so, it could be beneficial to allow this even for IP. Second,

the EDCA allows TXOpps (Transmit Opportunities)..although put to

'zero' for OCB (I think), this mechanism still allows an AP to

reserve a given time a long(er) connectivity with one device (e.

streaming of video etc..). Finally, it does not cost anything..you

can always take the lowest AC and you get the same behavior as non-QoS..

Well, this text is more informal in nature.=C2=A0=C2=A0 It is something tha= t

describes a potential behaviour but we have no proof of existing such behav= iour, no proof of interoperability.=C2=A0 This could be part of an INFORMAT= IONAL Internet Draft.

Well, my text is informal, but the specs are not. IEEE 802.11p (IEEE 802.11= -2016 OCB) uses EDCA not DCF...as this is L2 layer, I do not think anything= is required from IETF...just follow the IEEE 802.11-2016 specs and do what= ever is allows above it...I will double check again on the IEEE 802.11-2016= , but if what I think is confirmed, the whole discussion does not make any = sense..., as it is my understanding that the OCB requires EDCA, so QoS_Data= ...so, you cannot change that at IP level.

Bottom line, the fact that some IP implementation to decode OCB

assume non-QoS frames looks more to me like an implementation error

and we should not propagate this...

Well, wireshark has problems interpreting 802.11 QoS Data containing CAM me= ssages.=C2=A0 Many receivers of QoS Data dont know what to do with the fiel= ds because they are not agreed.

Yes, and this is why is the prototype we use, we actually have an parser fo= r CAM to be supported by Wireshark...it does not come by default. But I am = surprised..what kind of problem would wireshark face with the QoS Data?

I don't want to propagate that disagreement into the IP-over-OCB draft.=

To me, this looks more like an implementation issue, rather than a standard= issue...but I will ask my team to check on our prototype...

C-V2X will not use IP for CAM,

LTE-V2X will carry CAM in IP.=C2=A0 What is C-V2X and why does not it use I= P?

Sorry, it will not. In C-V2X (the widely known name...LTE-V2X is again a bi= t like 802.11p...'LTE Prose for V2X' is the real name...), mode 4 (= ad-hoc mode..currently chosen by all vendors (except maybe Huawei, but migh= t have changed), there is two options for protocol stack: IPv6 (again, only= IPv6) and non-IP (L2)...you can use non-IP packets and it is so mentioned = that BSM and CAM will use the non-IP option, as it is also required to use = the ETSI/WAVE security provisions to secure the C-V2X mode 4 (as no SIM=3D = no security), as the ETSI/WAVE security provisions works for non-IP packets= (geonet or WSM)...

Of course, it does not block from using IP...it is again the same discussio= n we had with ITS-G5/DSRC...for safety communication, IP is not required...= you can do everything without and faster. And considering that IEEE 802.11p= (ok, OCB) and C-V2X mode 4 (no SIM=3Dno SEC) DO NOT have any form of secur= ity mechanism embedded, they must use the those specified by ETSI/WAVE for = accessing CCH.

Again, C-V2X mode 4 (the current V2X techno for Safety-critical communicati= on) shall not be seen as following the same path as other cellular techno. = It does not provide QoS (at all), as it channel access is contention-based = (a bit like CSMA)...so collisions will occur (unlike 4G and 5G operated, wh= ere you are either dropped or you pass). And as such, IP is also not requir= ed, even if all 4G and 5G use IP.

ETSI and WAVE will not use IP for CAM...

That is their problem.

Disagree: you need to be compatible with them...so, whatever IETF will do s= hall not break anything that has been done on ETSI or WAVE. This is one of = the requirement for accessing the ITS-G5 spectrum in EU, and I believe the = same in the US.

ETSI transports IP over GeoNetworking - that is not the right way to do it.=

Disagree: we need to integrate security mechanisms specified by ETSI even i= f we use IPv6. Today, we do not have any security specification providing &= #39;trust', privacy and authentication for using 802.11-OCB (I believe = it is the work of IPWAVE and it is not completed yet...).

The mistake ETSI did is to try to be nice with IETF and help them to provid= e a way to use IPv6 over ITS-G5 in a secured way...WAVE took a different pa= th: 'not my problem', which then explain why ETSI officially does n= ot endorse IPWAVE (unfortunately, despite my many discussions with them)...= from an ETSI perspective, using IPv6 over ITS-G5 is solved...(might be ugly= , but it is solved).

the basic CAMs are used for pure positioning

The mandatory fields in CAM or more than just lat/long/altitude.=C2=A0 Ther= e is also mandatory time in a strange format, car dimensions, curve, non st= andard precisions and more.

Yes, correct...but these are configurable fields, which may or may not be i= ntegrated...recent studies even showed that even the standard CAM size is n= ot clear anymore..you have a 'range' of size, and that is a problem= for wireless optimization...especially if you need to do wireless congesti= on control.

and the recent 'increase' of information put in CAM

If CAM worries about size, I think CAM should think about its existing redu= ndancy.=C2=A0 For example, position is carried twice in a CAM message: in t= he CAM itself and in the GeoNetworking header.=C2=A0 That >is an issue t= hey should address first.

Well, of course, this is a waste...but one reason for such existence is fro= m the possibility to relay a packet (agnostic from the upper messages, unfo= rtunately, we cannot use a Zero-NET for CAM as it is pure 1-hop TSB)...

Yet, today we start seeing even BSM investigating ways to do multi-hop '= ;position' based relaying to reach longer distance.

And if you think about it, one day, your IPv6-over-OCB might need to use a = multi-hop networking protocol (e.g. MANET)..but doing the MANET way is high= ly mobile environment will not be that efficient...position-based mechanism= s will be required (proven in various previous studies)...now, your L3 will= not be able to inspect the GPS position of your CAM-over-IP...so, you will= need to have GPS (or so) position at IP/L3, which will end up being simila= r than now...

If you do not want to do this, then the IRTF people might come with ICN, bu= t then would this be done above L3 or at L3...if still at L3, you still wil= l have a contextual L3 packet that might be redundant with application/serv= ice layer messages...(the cost of using OSI)

But this is just my personal view and very long term...for now, if we only = look at CAM, indeed we can have twice the GPS position (but wait: not the s= ame granularity and you do not have elevation in geonet). But if you look a= t=C2=A0 the bigger picture: doing CAM-over-geonet only required a single CA= M, that's it. For IPv6-over-OCB, you need all the IPv6 address autoconf= iguration..that requires additional IPv6 packets to be transmitted...this i= s similar to compare an apple with a tomato.

looks to be like a bad strategy as we end up having a container

carrying too many things and being too big for what it is...

I agree.=C2=A0 But I think we should compare header sizes and then there wi= ll be surprises.

CAM transported in IP may be a smaller packet than CAM transported in BTP a= nd GeoNetworking.

Not that much if you counts also all IPv6-related control/management packet= s required to transmit your CAM-over-OCB, in a highly dynamic environment..= .

(WLAN is good at squeezing various small packets but really not good

at big things especially in broadcast mode)...a better strategy would

be to define new messages tailored to the information needs, and have

smart service scheduling...(especially benefiting from IP-related

mechanisms)

I fully agree with this.

:-) at least we do on this :-)

Cheers,

J=C3=A9r=C3=B4me

_______________________________________________

its mailing list

its@ietf.org<= /a> <mailto:its@ietf.o= rg>

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

_______________________________________________

its mailing list

its@ietf.org &= lt;mailto:its@ietf.org>

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


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



--
=
John Kenney
Director and Principal Researcher
Toyota InfoTechnology Center, USA
465 Bernardo Avenue
Mountain View, CA 94043
Tel: 650-694-4160. Mobile: 650-224-6644
--001a113ebe4e16f7b705662c80d1-- From nobody Tue Feb 27 02:30:57 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6D31274D2 for ; Tue, 27 Feb 2018 02:30:55 -0800 (PST) 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 EtVGg82VtVmg for ; Tue, 27 Feb 2018 02:30:52 -0800 (PST) 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 D7A5F1200F1 for ; Tue, 27 Feb 2018 02:30:51 -0800 (PST) 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 w1RAUlOt016315; Tue, 27 Feb 2018 11:30:47 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 41B35203856; Tue, 27 Feb 2018 11:30:47 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 277F220384F; Tue, 27 Feb 2018 11:30:47 +0100 (CET) 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 w1RAUjK4031505; Tue, 27 Feb 2018 11:30:46 +0100 To: John Kenney , =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= Cc: =?UTF-8?Q?Fran=c3=a7ois_Simon?= , "Dr. Hans-Joachim Fischer" , Abdussalam Baryun , Tony Li , its References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <9ada5591-2af3-272d-3bc3-031bf35454c3@gmail.com> <6cdc0835-fb4c-133b-77ff-0234cfdd9ef9@fischer-tech.eu> <00eb01d3af1d$7f4e8100$7deb8300$@gmail.com> <6187cb92-5c8f-d08b-dcc2-859652d629d0@gmail.com> <002901d3af20$b966e960$2c34bc20$@eurecom.fr> From: Alexandre Petrescu Message-ID: Date: Tue, 27 Feb 2018 11:30:45 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.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] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 27 Feb 2018 10:30:55 -0000 Le 27/02/2018 à 04:09, John Kenney a écrit : > Hi All: > > Jérôme has made a very important point.  Choosing to send IP traffic > over DCF (i.e. non-QoS data frames) can be quite harmful to other DSRC > services using EDCA. _It should not be done, period._ Hi John, Thank you for the remark. I think that that potential harm can be avoided by IEEE in the first place; I think IEEE could specify - if deemed necessary - that OCB must only use QoS Data, and not Data. Currently IEEE allows both. There is no open source available, as far as I know, that transmits ITS messages as QoS Data. The implementations I have seen that send CAM as QoS Data are closed source. They come from Unex, on ThreadX operating system, Autotalks chipset. There may be others. There is a lot of cheap open source available that transmits ITS messages, and IP, as Data. They are available on github.com, are called 'rendits', 'vanetza', 'driveits', 'btpsap' and others. Given that situation of software availability and IEEE situation, I do not know how the recommendation above could be implemented. Alex > Some specific points: > 1) WAVE standards explicitly require use of EDCA (IEEE 1609.4-2016, > clause 4.1) > > 2) DCF is not really non-QoS. It is best thought of as "alternate" QoS, > and in fact as "high QoS".  In 802.11 the notion of QoS is manifested as > channel access priority. As pointed out by others, this comes down to > AIFSN and CWmin.  DCF uses the equivalent of (AIFSN=2, CWmin = 15). > Under moderate-to-heavy channel load, when QoS is important, AIFSN is > the dominant factor. As Jérôme and Francois note, this puts DCF traffic > at, or just below, the very highest priority EDCA traffic.  So, this is > quite different from Diffserv where "non-Diffserv" defaults to Best > Effort.  Here "non-EDCA" defaults to high channel access priority.  This > can be very harmful to very important DSRC/ITS G5 traffic, especially > traffic using AC_VI and below. > > 3) I totally agree with the comments that caution not to be confused by > the Voice/Video/Best Effort/Background labels. Those are historical and > meant to be illustrative. In the ITS context it is simpler to think of > Highest/High/Medium/Low channel access priority. Those are the terms > used in SAE J2945/0 (clause 4.1.2.3), which makes recommendations for > mapping application classes to 802.11 access categories.  I believe the > channel access priority will generally be independent of the L3 protocol > [My personal opinion is if there is correlation in the DSRC case I > expect we would see higher priority associated more often with WSMP (or > ETSI equivalent) than with IPv6].  Therefore, not only should > IP-over-OCB use EDCA, it should allow the actual user priority to come > from higher layers. > > 4) EDCA parameters establish priority within a given channel. It is > generally not possible (or necessary) to compare priority of packets > sent on different channels. So, the EDCA parameter set may well vary by > channel. This is exactly the case for the US DSRC band where SAE J2945/1 > defines a non-default EDCA parameter set for Channel 172. > > Best Regards, > John > > > > On Mon, Feb 26, 2018 at 8:41 AM, Jérôme Härri > wrote: > > Hi Alex, > > Well, from the IP layer, what you see is a 7 bit User Priority, > nothing else..feel free to label the 7 UP as you want....how it is > translated is L2 business (and naming..)..so we should not care much > about the names. > > Now, you raised an issue (that was also identified by other OCB > people reading the thread..and will probably also provide feedback > soon) is the coexistence between traffic. > > CAM uses AC_BE in ETSI, DENM uses AC_VI and AC_VO in ETSI. > Event-based BSM uses AC_VI and non-even-based BSM uses AC_BE (I > think)...so, if you send IPv6 traffic with DCF (where DIFS = 2, same > as AC_VI), then you will compete directly with  DENM and event-based > BSM, which is * very* problematic...thus my suggestion to keep > QoSData so that we at least have an option to avoid interfering with > CAM/DENM. > > Now, if you want to transmit CAM with IPv6-over-OCB, then you > 'clearly' needs QoSData so that the pure IP CAM/BSN and ETSI/WAVE > CAM/BSM have the same L2 'priority' in accessing the channel, > otherwise you risk creating harmful interference and packet collisions. > > BR, > > Jérôme > > > > > -----Original Message----- > From: its [mailto:its-bounces@ietf.org > ] On Behalf Of Alexandre Petrescu > Sent: Monday 26 February 2018 17:23 > To: François Simon; 'Dr. Hans-Joachim Fischer'; 'Abdussalam Baryun' > Cc: 'Tony Li'; 'its' > Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in > IPv6-over-802.11-OCB > > > > Le 26/02/2018 à 17:18, François Simon a écrit : > > AC_VO (voice) is only a label indicating the highest priority; > nothing > > more is implied. > > YEs, sure, but imagine someone sends real voice; that will compete > with CAM 'voice' - we dont want that either :-) > > In such situation, what one would like in standards is to see > 'highest priority' instead of 'voice'. > > Alex > > > > > *From:*its [mailto:its-bounces@ietf.org > ] *On Behalf Of *Dr. > > Hans-Joachim Fischer > > *Sent:* Monday, February 26, 2018 3:37 AM > > *To:* Abdussalam Baryun >; Alexandre > > Petrescu > > > *Cc:* Tony Li >; its > > > *Subject:* Re: [ipwave] 802.11 Data vs 802.11 QoS Data in > > IPv6-over-802.11-OCB > > > > Be careful with voice and audio transmission in ITS using 5,9 GHz. > > That seems to be prohibited by regulation in Europe; well, not > > explicitly, but this is a possible interpretation of the technical > > requirements presented in regulatory documents. In Germany, it is > prohibited. > > > > Hans-Joachim > > > > Am 26.02.2018 um 09:04 schrieb Abdussalam Baryun: > > > >     The experience test you referred to is not clarified, was it > a ITS > >     environment experience or was it a fixed wireless experience. > >     Furthermore, the WiFi technology ieee802.11 is developed so which > >     WiFi technology was used. Moreover, did your experience use Video > >     and voice communication or your proposal is only for data > >     communication only. > > > >     So if your IP packet are data then your experience is right, > but if > >     the IP packet is carrying voice or video I don't agree. IMO > we could > >     not exclude from the draft voice and video communication in > the ITS > >     environment/use-case. > > > >     On Sun, Feb 25, 2018 at 7:58 PM, Alexandre Petrescu > >      > >> > >     wrote: > > > > > > > >         Le 23/02/2018 à 18:38, Tony Li a écrit : > > > >                 If we put that CAM on IP there will still be lack of > >                 interoperability, > >                 unless we recommend IP to be carried by a particular > >                 802.11 header (Data > >                 or QoS Data). > > > > > > > >             I would propose that we use the Data header. My > experience > >             with the QoS Data with Wi-Fi was that there wasn’t > enough of > >             a performance difference with QoS for it to make a > >             difference to the IP layer. > > > > > >         I agree. > > > >         I propose the following text. > > > >         OLD: > > > >                 In OCB mode, IPv6 packets MAY be transmitted > either as > >             "IEEE 802.11 > >                 Data" or alternatively as "IEEE 802.11 QoS Data", as > >             illustrated in > >                 Figure 2. > > > > > >         NEW: > > > >                 In OCB mode, it is RECOMMENDED to transmit IPv6 > packets > >             as "IEEE > >                 802.11 Data" (the value of the field Subtype in the > >             Frame Control > >                 Field is 0). > > > > > >         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 > > > > > > > > > -- > > > > Dr. Hans-Joachim Fischer > > > > Managing Director > > > > > ---------------------------------------------------------------------- > > ---------- > > > >                 ESF News edition 2018/1 > > > > https://fischer-tech.eu/Feeds/News/ESF-News-2018-01.pdf > > > > > > ---------------------------------------------------------------------- > > ---------- > > > >        Towards deployment of C-ITS based on proven technology > > > > Avoid risks and delay by looking on potential future technologies. > > > >                 The real advocate on ITS is ISO TC204! > > > > > ---------------------------------------------------------------------- > > ---------- > > > > + + + Instaurare omnia in Christo + + + > > > > > ---------------------------------------------------------------------- > > ---------- > > > > The information contained in this message is confidential and may be > > legally > > > > privileged. This email is intended for the addressee(s). Addressees > > may be > > > > individual persons or members of mailing list. > > > > If you are not an addressee, you are hereby notified that any use, > > > > dissemination, or reproduction of this email and its optional > > attachements is > > > > strictly prohibited and may be unlawful. If you are not an addressee, > > please > > > > contact the sender by return e-mail and destroy all copies of the > > original > > > > message. > > > > > ---------------------------------------------------------------------- > > ---------- > > > > ESF GmbH > > > > Fichtenweg 9 > > > > 89143 Blaubeuren > > > > +49 (7344) 175340 (Direct line > Dr. Fischer) > > > > +49 (7344) 919188 (Central office) > > > > +49 (7344) 919123 (Fax) > > > > https://fischer-tech.eu  :  Main web of ESF GmbH > > > > http://its-standards.eu  : News on cooperative ITS standardization > > > > http://its-testing.org  :  International consultancy for cooperative > > ITS > > > > > ---------------------------------------------------------------------- > > ---------- > > > > > ---------------------------------------------------------------------- > > ---------- > > > > ESF online-news:http://fischer-tech.eu/Feeds/esf.rss > > > > > C-ITS online news:http://its-standards.info/Feeds/cits.rss > > > > > ESF Online Nachrichten:http://fischer-tech.de/Feeds/esfD.rss > > > > > > ---------------------------------------------------------------------- > > --------- > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > > > > > -- > John Kenney > Director and Principal Researcher > Toyota InfoTechnology Center, USA > 465 Bernardo Avenue > Mountain View, CA 94043 > Tel: 650-694-4160. Mobile: 650-224-6644 From nobody Tue Feb 27 02:32:48 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50BE81204DA for ; Tue, 27 Feb 2018 02:32:47 -0800 (PST) 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 nAGblC-bjVXU for ; Tue, 27 Feb 2018 02:32:45 -0800 (PST) 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 3FEF71200F1 for ; Tue, 27 Feb 2018 02:32:45 -0800 (PST) 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 w1RAWgCf036914; Tue, 27 Feb 2018 11:32:42 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0957D20308B; Tue, 27 Feb 2018 11:32:42 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id E5922200E66; Tue, 27 Feb 2018 11:32:41 +0100 (CET) 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 w1RAWfYI001222; Tue, 27 Feb 2018 11:32:41 +0100 To: John Kenney , Tony Li Cc: Abdussalam Baryun , "Dr. Hans-Joachim Fischer" , =?UTF-8?Q?Fran=c3=a7ois_Simon?= , =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , its References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <9ada5591-2af3-272d-3bc3-031bf35454c3@gmail.com> <6cdc0835-fb4c-133b-77ff-0234cfdd9ef9@fischer-tech.eu> <00eb01d3af1d$7f4e8100$7deb8300$@gmail.com> <6187cb92-5c8f-d08b-dcc2-859652d629d0@gmail.com> <002901d3af20$b966e960$2c34bc20$@eurecom.fr> <5CFB283E-7E51-440D-BE70-05FB2CCDCF82@tony.li> From: Alexandre Petrescu Message-ID: Date: Tue, 27 Feb 2018 11:32:41 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.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] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 27 Feb 2018 10:32:47 -0000 Le 27/02/2018 à 07:57, John Kenney a écrit : > Hi Tony, > > If priority settings passing through IPv6 can’t be trusted then I agree > to treat all the IP traffic uniformly. In that case it is probably best > to map it all to the AC_BK so it will not interfere with critical DSRC > traffic. For the reasons previously stated, it can’t be DCF. Why BK and not BE ('Best Effort')? Alex > BTW in the US band plan there are no non-critical channels or > "application" channels. All channels are expected to carry critical > traffic. See SAE J2945/0 (Table 4) for the recommended channel usage > plan. You’ll see that IPv6 traffic is expected to share channels with > I2V safety and mobility, with V2P safety, with automated driving > support, etc.  Table 3 shows recommended priority settings, and I note > that SCMS communication, which is expected to use IPv6, is recommended > to use AC_BK. > > In Europe it is similar, except that the lowest two channels are > explicitly designated only for non-safety applications, though I would > caution that non-safety does not mean “lacking performance requirements “. > > Best Regards, > John > > On Mon, Feb 26, 2018 at 7:23 PM Tony Li > wrote: > > >> Therefore, not only should IP-over-OCB use EDCA, it should allow >> the actual user priority to come from higher layers. > > > Please recall that there is no security over the IPv6 header and > that users have full access to the priority field. The networks that > actually do try to implement some form of QoS are forced to > explicitly reclassify all traffic entering their networks, either > from their immediate customers or from peer networks. > > Any IP stack not under the complete control of a network operator > should be assumed to be compromised and the diffserv code points > should not be trusted. > > Now, are we sure we want to make use of this? > > I’ll also remind folks that IP is running in the application > channels and so is not going to be interfering with mission critical > uses. > > Trying to control QoS between multiple applications, some of which > are under nefarious control is likely to be a recipe for simply > hurting those that are trying to be compliant.  If we simply treat > everything uniformly, we give everyone less incentive to game the > system.  And we have no way of stopping them from gaming the system. > > Tony > From nobody Tue Feb 27 02:35:52 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 754981204DA for ; Tue, 27 Feb 2018 02:35:50 -0800 (PST) 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 fnmwPHxAP8o0 for ; Tue, 27 Feb 2018 02:35:49 -0800 (PST) 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 22F661200F1 for ; Tue, 27 Feb 2018 02:35:48 -0800 (PST) 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 w1RAZlE8018687; Tue, 27 Feb 2018 11:35:47 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 07993202D16; Tue, 27 Feb 2018 11:35:47 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id EA78C2025E5; Tue, 27 Feb 2018 11:35:46 +0100 (CET) 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 w1RAZkMH005397; Tue, 27 Feb 2018 11:35:46 +0100 To: John Kenney Cc: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , =?UTF-8?Q?Fran=c3=a7ois_Simon?= , its References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <006301d3ace3$25f9d500$71ed7f00$@eurecom.fr> <007901d3aee3$a9985ba0$fcc912e0$@eurecom.fr> <00da01d3aef6$574c4380$05e4ca80$@eurecom.fr> <003a01d3af41$c6674cb0$5335e610$@gmail.com> <008a01d3af42$cfcdcdf0$6f6969d0$@eurecom.fr> <72b23b14-7afc-c253-a541-c8ffeef6e969@gmail.com> From: Alexandre Petrescu Message-ID: Date: Tue, 27 Feb 2018 11:35:46 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.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] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 27 Feb 2018 10:35:50 -0000 Le 27/02/2018 à 08:23, John Kenney a écrit : > Hi Alex, > As I mentioned in another email, these labels VO/VI/BE/BK are historical > (going back to the 2005 802.11e amendment) and merely illustrative of > four application classes in a generic WLAN. AC_VO was never intended to > be limited only to voice flows.  802.11 QoS is inherently relative, so > you don't just create more access categories when new applications come > along. There are only four access categories in standard EDCA. The > labels don't mean much. What matters are the set of EDCA parameters > associated with each AC. These could be from the default set or (as in > the case of Ch. 172) something different. We wouldn't use AC_VE to mean > vehicular because we use all four ACs in vehicular communication (OCB). > The whole band is restricted to vehicular communication, and we need to > prioritize within that universe. I can agree to stay within a given universe. When a new draft is written about mapping 802.11 ACs (Access Classes?) into IPv6 Traffic Classes, maybe we will clarify the terminology at that time. Alex From nobody Tue Feb 27 02:38:48 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63D2712783A for ; Tue, 27 Feb 2018 02:38:47 -0800 (PST) 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 qiTg6l8IaSqt for ; Tue, 27 Feb 2018 02:38:45 -0800 (PST) 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 353E51200F1 for ; Tue, 27 Feb 2018 02:38:44 -0800 (PST) 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 w1RAchUU040234 for ; Tue, 27 Feb 2018 11:38:43 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 69DEA20387C for ; Tue, 27 Feb 2018 11:38:43 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 60748200D08 for ; Tue, 27 Feb 2018 11:38:43 +0100 (CET) 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 w1RAchrB008582 for ; Tue, 27 Feb 2018 11:38:43 +0100 To: its@ietf.org References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <006301d3ace3$25f9d500$71ed7f00$@eurecom.fr> <007901d3aee3$a9985ba0$fcc912e0$@eurecom.fr> <00da01d3aef6$574c4380$05e4ca80$@eurecom.fr> <003a01d3af41$c6674cb0$5335e610$@gmail.com> <008a01d3af42$cfcdcdf0$6f6969d0$@eurecom.fr> <72b23b14-7afc-c253-a541-c8ffeef6e969@gmail.com> From: Alexandre Petrescu Message-ID: <318ed1a2-10a7-bb11-a390-0880fb7e89b7@gmail.com> Date: Tue, 27 Feb 2018 11:38:43 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.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] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 27 Feb 2018 10:38:47 -0000 Le 27/02/2018 à 11:35, Alexandre Petrescu a écrit : > > > Le 27/02/2018 à 08:23, John Kenney a écrit : >> Hi Alex, >> As I mentioned in another email, these labels VO/VI/BE/BK are >> historical (going back to the 2005 802.11e amendment) and merely >> illustrative of four application classes in a generic WLAN. AC_VO was >> never intended to be limited only to voice flows.  802.11 QoS is >> inherently relative, so you don't just create more access categories >> when new applications come along. There are only four access >> categories in standard EDCA. The labels don't mean much. What matters >> are the set of EDCA parameters associated with each AC. These could be >> from the default set or (as in the case of Ch. 172) something >> different. We wouldn't use AC_VE to mean vehicular because we use all >> four ACs in vehicular communication (OCB). The whole band is >> restricted to vehicular communication, and we need to prioritize >> within that universe. > > I can agree to stay within a given universe. > > When a new draft is written about mapping 802.11 ACs (Access Classes?) > into IPv6 Traffic Classes, maybe we will clarify the terminology at that > time. Sorry to answer my own email. By 'access classes' I meant to say: Access Categories (AC): background (BK), best effort (BE), video (VI) and voice (VO). (copied from a poster). Alex > > Alex > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Tue Feb 27 02:43:59 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B486D127876 for ; Tue, 27 Feb 2018 02:43:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.612 X-Spam-Level: X-Spam-Status: No, score=-1.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, MISSING_HEADERS=1.021, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trFZNkV7cy3p for ; Tue, 27 Feb 2018 02:43:46 -0800 (PST) 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 3891612785F for ; Tue, 27 Feb 2018 02:43:46 -0800 (PST) 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 w1RAhiCM021529 for ; Tue, 27 Feb 2018 11:43:44 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 832F62038BE for ; Tue, 27 Feb 2018 11:43:44 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 79D8F2014F7 for ; Tue, 27 Feb 2018 11:43:44 +0100 (CET) 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 w1RAhiGS014165 for ; Tue, 27 Feb 2018 11:43:44 +0100 Cc: its@ietf.org References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <9ada5591-2af3-272d-3bc3-031bf35454c3@gmail.com> From: Alexandre Petrescu Message-ID: Date: Tue, 27 Feb 2018 11:43:44 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <9ada5591-2af3-272d-3bc3-031bf35454c3@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB - text modifications towards resolution 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, 27 Feb 2018 10:43:48 -0000 I propose the following modifications towards resolution of this QoS issue. Do you disagree? OLD: > In OCB mode, IPv6 packets MAY be transmitted either as "IEEE 802.11 > Data" or alternatively as "IEEE 802.11 QoS Data", as illustrated in > Figure 2. NEW: > In OCB mode, it is RECOMMENDED to transmit IPv6 packets as "IEEE > 802.11 Data" (the value of the field Subtype in the Frame Control > Field is 0). Remove this entire OLD text: > In OCB mode, IPv6 packets MAY be transmitted either as "IEEE 802.11 > Data" or alternatively as "IEEE 802.11 QoS Data", as illustrated in > Figure 2. > > +--------------------+-------------+-------------+---------+-----------+ > | 802.11 Data Header | LLC Header | IPv6 Header | Payload |.11 Trailer| > +--------------------+-------------+-------------+---------+-----------+ > > or > > +--------------------+-------------+-------------+---------+-----------+ > | 802.11 QoS Data Hdr| LLC Header | IPv6 Header | Payload |.11 Trailer| > +--------------------+-------------+-------------+---------+-----------+ > > Figure 2: 802.11 Data Header or 802.11 QoS Data Header > > 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 > [I-D.ietf-tsvwg-ieee-802-11], although it is not specific to OCB > mode. Alex Le 25/02/2018 à 18:58, Alexandre Petrescu a écrit : > I propose the following text. > > OLD: >>    In OCB mode, IPv6 packets MAY be transmitted either as "IEEE 802.11 >>    Data" or alternatively as "IEEE 802.11 QoS Data", as illustrated in >>    Figure 2. > > NEW: >>    In OCB mode, it is RECOMMENDED to transmit IPv6 packets as "IEEE >>    802.11 Data" (the value of the field Subtype in the Frame Control >>    Field is 0). > > Alex From nobody Tue Feb 27 02:45:00 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 798C1127867 for ; Tue, 27 Feb 2018 02:44:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 ZTt88HSOoRTz for ; Tue, 27 Feb 2018 02:44:55 -0800 (PST) Received: from smtp2.eurecom.fr (smtp2.eurecom.fr [193.55.113.211]) by ietfa.amsl.com (Postfix) with ESMTP id 30F76127869 for ; Tue, 27 Feb 2018 02:44:50 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.47,400,1515452400"; d="scan'208";a="7704384" Received: from monza.eurecom.fr ([192.168.106.15]) by drago2i.eurecom.fr with ESMTP; 27 Feb 2018 11:44:48 +0100 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 D7B191A2C; Tue, 27 Feb 2018 11:44:48 +0100 (CET) From: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= To: "'Alexandre Petrescu'" , "'John Kenney'" , "'Tony Li'" Cc: "'Abdussalam Baryun'" , "'Dr. Hans-Joachim Fischer'" , =?UTF-8?Q?'Fran=C3=A7ois_Simon'?= , "'its'" References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <9ada5591-2af3-272d-3bc3-031bf35454c3@gmail.com> <6cdc0835-fb4c-133b-77ff-0234cfdd9ef9@fischer-tech.eu> <00eb01d3af1d$7f4e8100$7deb8300$@gmail.com> <6187cb92-5c8f-d08b-dcc2-859652d629d0@gmail.com> <002901d3af20$b966e960$2c34bc20$@eurecom.fr> <5CFB283E-7E51-440D-BE70-05FB2CCDCF82@tony.li> In-Reply-To: Date: Tue, 27 Feb 2018 11:44:48 +0100 Organization: EURECOM Message-ID: <000c01d3afb7$fd5f8d10$f81ea730$@eurecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHelLAw/aN7IRfcwiTBG/gKcgHVEwGONDnFAivYBTcB5QRVgwFu9SHuAdIGJvACSXL3QAKWMu63Adu1s18A8/GqjwFm8QpOAKWrsCwBY2xvIgIfoiSvovFONRA= Content-Language: en-us Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 27 Feb 2018 10:44:57 -0000 Hi Alex, Because AC_BE is used by BSM, which is a critical DSRC traffic.=20 BR, J=C3=A9r=C3=B4me -----Original Message----- From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com]=20 Sent: Tuesday 27 February 2018 11:33 To: John Kenney; Tony Li Cc: Abdussalam Baryun; Dr. Hans-Joachim Fischer; Fran=C3=A7ois Simon; = J=C3=A9r=C3=B4me H=C3=A4rri; its Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in = IPv6-over-802.11-OCB Le 27/02/2018 =C3=A0 07:57, John Kenney a =C3=A9crit : > Hi Tony, >=20 > If priority settings passing through IPv6 can=E2=80=99t be trusted = then I=20 > agree to treat all the IP traffic uniformly. In that case it is=20 > probably best to map it all to the AC_BK so it will not interfere with = > critical DSRC traffic. For the reasons previously stated, it = can=E2=80=99t be DCF. Why BK and not BE ('Best Effort')? Alex > BTW in the US band plan there are no non-critical channels or=20 > "application" channels. All channels are expected to carry critical=20 > traffic. See SAE J2945/0 (Table 4) for the recommended channel usage=20 > plan. You=E2=80=99ll see that IPv6 traffic is expected to share = channels with=20 > I2V safety and mobility, with V2P safety, with automated driving=20 > support, etc. Table 3 shows recommended priority settings, and I note = > that SCMS communication, which is expected to use IPv6, is recommended = > to use AC_BK. >=20 > In Europe it is similar, except that the lowest two channels are=20 > explicitly designated only for non-safety applications, though I would = > caution that non-safety does not mean =E2=80=9Clacking performance = requirements =E2=80=9C. >=20 > Best Regards, > John >=20 > On Mon, Feb 26, 2018 at 7:23 PM Tony Li > wrote: >=20 >=20 >> Therefore, not only should IP-over-OCB use EDCA, it should allow >> the actual user priority to come from higher layers. >=20 >=20 > Please recall that there is no security over the IPv6 header and > that users have full access to the priority field. The networks = that > actually do try to implement some form of QoS are forced to > explicitly reclassify all traffic entering their networks, either > from their immediate customers or from peer networks. >=20 > Any IP stack not under the complete control of a network operator > should be assumed to be compromised and the diffserv code points > should not be trusted. >=20 > Now, are we sure we want to make use of this? >=20 > I=E2=80=99ll also remind folks that IP is running in the = application > channels and so is not going to be interfering with mission = critical > uses. >=20 > Trying to control QoS between multiple applications, some of which > are under nefarious control is likely to be a recipe for simply > hurting those that are trying to be compliant. If we simply treat > everything uniformly, we give everyone less incentive to game the > system. And we have no way of stopping them from gaming the = system. >=20 > Tony >=20 From nobody Tue Feb 27 02:50:13 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8322A12785F for ; Tue, 27 Feb 2018 02:50:11 -0800 (PST) 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 u5Gd-kDxZuP7 for ; Tue, 27 Feb 2018 02:50:09 -0800 (PST) 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 6F0021200F1 for ; Tue, 27 Feb 2018 02:50:09 -0800 (PST) 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 w1RAo5NR044571; Tue, 27 Feb 2018 11:50:05 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 85DDA2037DC; Tue, 27 Feb 2018 11:50:05 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 6D5F7202D1C; Tue, 27 Feb 2018 11:50:05 +0100 (CET) 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 w1RAo42v021115; Tue, 27 Feb 2018 11:50:04 +0100 To: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , "'John Kenney'" , "'Tony Li'" Cc: "'Abdussalam Baryun'" , "'Dr. Hans-Joachim Fischer'" , "=?UTF-8?Q?'Fran=c3=a7ois_Simon'?=" , "'its'" References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <9ada5591-2af3-272d-3bc3-031bf35454c3@gmail.com> <6cdc0835-fb4c-133b-77ff-0234cfdd9ef9@fischer-tech.eu> <00eb01d3af1d$7f4e8100$7deb8300$@gmail.com> <6187cb92-5c8f-d08b-dcc2-859652d629d0@gmail.com> <002901d3af20$b966e960$2c34bc20$@eurecom.fr> <5CFB283E-7E51-440D-BE70-05FB2CCDCF82@tony.li> <000c01d3afb7$fd5f8d10$f81ea730$@eurecom.fr> From: Alexandre Petrescu Message-ID: <90f7712d-8f8f-72ea-7736-d40c3a62bd67@gmail.com> Date: Tue, 27 Feb 2018 11:50:04 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <000c01d3afb7$fd5f8d10$f81ea730$@eurecom.fr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 27 Feb 2018 10:50:11 -0000 Le 27/02/2018 à 11:44, Jérôme Härri a écrit : > Hi Alex, > > Because AC_BE is used by BSM, which is a critical DSRC traffic. This use of the term 'Best Effort' strikes so different than 'Best Effort' on the Internet which is something like in RFC5290, i.e. that is not covered by QoS. Terminology... as usual :-) Alex > > BR, > > Jérôme > > -----Original Message----- > From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] > Sent: Tuesday 27 February 2018 11:33 > To: John Kenney; Tony Li > Cc: Abdussalam Baryun; Dr. Hans-Joachim Fischer; François Simon; Jérôme Härri; its > Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB > > > > Le 27/02/2018 à 07:57, John Kenney a écrit : >> Hi Tony, >> >> If priority settings passing through IPv6 can’t be trusted then I >> agree to treat all the IP traffic uniformly. In that case it is >> probably best to map it all to the AC_BK so it will not interfere with >> critical DSRC traffic. For the reasons previously stated, it can’t be DCF. > > Why BK and not BE ('Best Effort')? > > Alex > >> BTW in the US band plan there are no non-critical channels or >> "application" channels. All channels are expected to carry critical >> traffic. See SAE J2945/0 (Table 4) for the recommended channel usage >> plan. You’ll see that IPv6 traffic is expected to share channels with >> I2V safety and mobility, with V2P safety, with automated driving >> support, etc. Table 3 shows recommended priority settings, and I note >> that SCMS communication, which is expected to use IPv6, is recommended >> to use AC_BK. >> >> In Europe it is similar, except that the lowest two channels are >> explicitly designated only for non-safety applications, though I would >> caution that non-safety does not mean “lacking performance requirements “. >> >> Best Regards, >> John >> >> On Mon, Feb 26, 2018 at 7:23 PM Tony Li > > wrote: >> >> >>> Therefore, not only should IP-over-OCB use EDCA, it should allow >>> the actual user priority to come from higher layers. >> >> >> Please recall that there is no security over the IPv6 header and >> that users have full access to the priority field. The networks that >> actually do try to implement some form of QoS are forced to >> explicitly reclassify all traffic entering their networks, either >> from their immediate customers or from peer networks. >> >> Any IP stack not under the complete control of a network operator >> should be assumed to be compromised and the diffserv code points >> should not be trusted. >> >> Now, are we sure we want to make use of this? >> >> I’ll also remind folks that IP is running in the application >> channels and so is not going to be interfering with mission critical >> uses. >> >> Trying to control QoS between multiple applications, some of which >> are under nefarious control is likely to be a recipe for simply >> hurting those that are trying to be compliant. If we simply treat >> everything uniformly, we give everyone less incentive to game the >> system. And we have no way of stopping them from gaming the system. >> >> Tony >> > > From nobody Tue Feb 27 04:15:24 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97992129C6A for ; Tue, 27 Feb 2018 04:15:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 HYK1ZGRSoNKd for ; Tue, 27 Feb 2018 04:15:19 -0800 (PST) Received: from smtp2.eurecom.fr (smtp2.eurecom.fr [193.55.113.211]) by ietfa.amsl.com (Postfix) with ESMTP id CECBE127444 for ; Tue, 27 Feb 2018 04:15:18 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.47,400,1515452400"; d="scan'208";a="7704699" Received: from monza.eurecom.fr ([192.168.106.15]) by drago2i.eurecom.fr with ESMTP; 27 Feb 2018 13:15:17 +0100 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 6EABF1FBE; Tue, 27 Feb 2018 13:15:17 +0100 (CET) From: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= To: "'Alexandre Petrescu'" , "'John Kenney'" Cc: =?UTF-8?Q?'Fran=C3=A7ois_Simon'?= , "'Dr. Hans-Joachim Fischer'" , "'Abdussalam Baryun'" , "'Tony Li'" , "'its'" References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <9ada5591-2af3-272d-3bc3-031bf35454c3@gmail.com> <6cdc0835-fb4c-133b-77ff-0234cfdd9ef9@fischer-tech.eu> <00eb01d3af1d$7f4e8100$7deb8300$@gmail.com> <6187cb92-5c8f-d08b-dcc2-859652d629d0@gmail.com> <002901d3af20$b966e960$2c34bc20$@eurecom.fr> In-Reply-To: Date: Tue, 27 Feb 2018 13:15:17 +0100 Organization: EURECOM Message-ID: <002601d3afc4$a10fbb90$e32f32b0$@eurecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHelLAw/aN7IRfcwiTBG/gKcgHVEwGONDnFAivYBTcB5QRVgwFu9SHuAdIGJvACSXL3QAKWMu63Adu1s18A8/GqjwFm8QpOAZ+WrA+jBZgN4A== Content-Language: en-us Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 27 Feb 2018 12:15:22 -0000 Hi Alex, >Hi John, > >Thank you for the remark. > >I think that that potential harm can be avoided by IEEE in the first = place; I think IEEE could specify - if deemed necessary - that OCB must = only use QoS Data, and not Data. Currently IEEE allows both. > >There is no open source available, as far as I know, that transmits ITS = messages as QoS Data. The implementations I have seen that send CAM as = QoS Data are closed source. They come from Unex, on ThreadX operating = system, Autotalks chipset. There may be others. > >There is a lot of cheap open source available that transmits ITS = messages, and IP, as Data. They are available on github.com, are called = 'rendits', 'vanetza', 'driveits', 'btpsap' and others. > >Given that situation of software availability and IEEE situation, I do = not know how the recommendation above could be implemented. > >Alex Well IEEE 802.11-2016 OCB is agnostic to the criticality of the = traffic...(and I think it should remain so...). It is WAVE and ETSI, = which defined critical safety traffic and thus imposed QoSData, as it is = critically required for their implementations and congestion control. = Now, using IPv6-over-OCB on the ITS-G5 bands follows the same challenges = as both BRAN (WLAN) and C-V2X...if it is used for safety-related = traffic, they should not create harmful interferences with the current = technology (DSRC/ITS-G5), which suggests (I am not a lawyer) that IPWAVE = must use QoSData (at least) and differentiate traffic to have access = priority equivalent to those defined by SAE/ETSI.... As mentioned, what does it cost to IPWAVE to recommend using QoSData for = IPv6-over-OCB?=20 Now, I am also a bit surprised: I have not been long enough in IETF I = guess, but since when would IETF recommend a mechanism not because it is = good, but because it is the only open-source code available??=20 If QoSData implementations are not available, let's make one...by using = QoSData instead of Data for IPWAVE, you will save a lot of discussions = about spectrum neutrality and non-harmful interference, which might even = block implementations using this very RFC.=20 BR, J=C3=A9r=C3=B4me > Some specific points: > 1) WAVE standards explicitly require use of EDCA (IEEE 1609.4-2016,=20 > clause 4.1) >=20 > 2) DCF is not really non-QoS. It is best thought of as "alternate"=20 > QoS, and in fact as "high QoS". In 802.11 the notion of QoS is=20 > manifested as channel access priority. As pointed out by others, this=20 > comes down to AIFSN and CWmin. DCF uses the equivalent of (AIFSN=3D2, = CWmin =3D 15). > Under moderate-to-heavy channel load, when QoS is important, AIFSN is=20 > the dominant factor. As J=C3=A9r=C3=B4me and Francois note, this puts = DCF=20 > traffic at, or just below, the very highest priority EDCA traffic. =20 > So, this is quite different from Diffserv where "non-Diffserv"=20 > defaults to Best Effort. Here "non-EDCA" defaults to high channel=20 > access priority. This can be very harmful to very important DSRC/ITS=20 > G5 traffic, especially traffic using AC_VI and below. >=20 > 3) I totally agree with the comments that caution not to be confused=20 > by the Voice/Video/Best Effort/Background labels. Those are historical = > and meant to be illustrative. In the ITS context it is simpler to=20 > think of Highest/High/Medium/Low channel access priority. Those are=20 > the terms used in SAE J2945/0 (clause 4.1.2.3), which makes=20 > recommendations for mapping application classes to 802.11 access=20 > categories. I believe the channel access priority will generally be=20 > independent of the L3 protocol [My personal opinion is if there is=20 > correlation in the DSRC case I expect we would see higher priority=20 > associated more often with WSMP (or ETSI equivalent) than with IPv6]. = > Therefore, not only should IP-over-OCB use EDCA, it should allow the=20 > actual user priority to come from higher layers. >=20 > 4) EDCA parameters establish priority within a given channel. It is=20 > generally not possible (or necessary) to compare priority of packets=20 > sent on different channels. So, the EDCA parameter set may well vary=20 > by channel. This is exactly the case for the US DSRC band where SAE=20 > J2945/1 defines a non-default EDCA parameter set for Channel 172. >=20 > Best Regards, > John >=20 >=20 >=20 > On Mon, Feb 26, 2018 at 8:41 AM, J=C3=A9r=C3=B4me H=C3=A4rri=20 > > wrote: >=20 > Hi Alex, >=20 > Well, from the IP layer, what you see is a 7 bit User Priority, > nothing else..feel free to label the 7 UP as you want....how it is > translated is L2 business (and naming..)..so we should not care = much > about the names. >=20 > Now, you raised an issue (that was also identified by other OCB > people reading the thread..and will probably also provide feedback > soon) is the coexistence between traffic. >=20 > CAM uses AC_BE in ETSI, DENM uses AC_VI and AC_VO in ETSI. > Event-based BSM uses AC_VI and non-even-based BSM uses AC_BE (I > think)...so, if you send IPv6 traffic with DCF (where DIFS =3D 2, = same > as AC_VI), then you will compete directly with DENM and = event-based > BSM, which is * very* problematic...thus my suggestion to keep > QoSData so that we at least have an option to avoid interfering = with > CAM/DENM. >=20 > Now, if you want to transmit CAM with IPv6-over-OCB, then you > 'clearly' needs QoSData so that the pure IP CAM/BSN and ETSI/WAVE > CAM/BSM have the same L2 'priority' in accessing the channel, > otherwise you risk creating harmful interference and packet = collisions. >=20 > BR, >=20 > J=C3=A9r=C3=B4me >=20 >=20 >=20 >=20 > -----Original Message----- > From: its [mailto:its-bounces@ietf.org > ] On Behalf Of Alexandre Petrescu > Sent: Monday 26 February 2018 17:23 > To: Fran=C3=A7ois Simon; 'Dr. Hans-Joachim Fischer'; 'Abdussalam = Baryun' > Cc: 'Tony Li'; 'its' > Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in > IPv6-over-802.11-OCB >=20 >=20 >=20 > Le 26/02/2018 =C3=A0 17:18, Fran=C3=A7ois Simon a =C3=A9crit : > > AC_VO (voice) is only a label indicating the highest priority; > nothing > > more is implied. >=20 > YEs, sure, but imagine someone sends real voice; that will compete > with CAM 'voice' - we dont want that either :-) >=20 > In such situation, what one would like in standards is to see > 'highest priority' instead of 'voice'. >=20 > Alex >=20 > > > > *From:*its [mailto:its-bounces@ietf.org > ] *On Behalf Of *Dr. > > Hans-Joachim Fischer > > *Sent:* Monday, February 26, 2018 3:37 AM > > *To:* Abdussalam Baryun >; Alexandre > > Petrescu > > > *Cc:* Tony Li >; its > > > *Subject:* Re: [ipwave] 802.11 Data vs 802.11 QoS Data in > > IPv6-over-802.11-OCB > > > > Be careful with voice and audio transmission in ITS using 5,9 = GHz. > > That seems to be prohibited by regulation in Europe; well, not > > explicitly, but this is a possible interpretation of the = technical > > requirements presented in regulatory documents. In Germany, it = is > prohibited. > > > > Hans-Joachim > > > > Am 26.02.2018 um 09:04 schrieb Abdussalam Baryun: > > > > The experience test you referred to is not clarified, was = it > a ITS > > environment experience or was it a fixed wireless = experience. > > Furthermore, the WiFi technology ieee802.11 is developed so = which > > WiFi technology was used. Moreover, did your experience use = Video > > and voice communication or your proposal is only for data > > communication only. > > > > So if your IP packet are data then your experience is = right, > but if > > the IP packet is carrying voice or video I don't agree. IMO > we could > > not exclude from the draft voice and video communication in > the ITS > > environment/use-case. > > > > On Sun, Feb 25, 2018 at 7:58 PM, Alexandre Petrescu > > > >> > > wrote: > > > > > > > > Le 23/02/2018 =C3=A0 18:38, Tony Li a =C3=A9crit : > > > > If we put that CAM on IP there will still be = lack of > > interoperability, > > unless we recommend IP to be carried by a = particular > > 802.11 header (Data > > or QoS Data). > > > > > > > > I would propose that we use the Data header. My > experience > > with the QoS Data with Wi-Fi was that there = wasn=E2=80=99t > enough of > > a performance difference with QoS for it to make a > > difference to the IP layer. > > > > > > I agree. > > > > I propose the following text. > > > > OLD: > > > > In OCB mode, IPv6 packets MAY be transmitted > either as > > "IEEE 802.11 > > Data" or alternatively as "IEEE 802.11 QoS = Data", as > > illustrated in > > Figure 2. > > > > > > NEW: > > > > In OCB mode, it is RECOMMENDED to transmit IPv6 > packets > > as "IEEE > > 802.11 Data" (the value of the field Subtype in = the > > Frame Control > > Field is 0). > > > > > > 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 > > > > > > > > > -- > > > > Dr. Hans-Joachim Fischer > > > > Managing Director > > > > > = ---------------------------------------------------------------------- > > ---------- > > > > ESF News edition 2018/1 > > > > https://fischer-tech.eu/Feeds/News/ESF-News-2018-01.pdf > > > > > > = ---------------------------------------------------------------------- > > ---------- > > > > Towards deployment of C-ITS based on proven technology > > > > Avoid risks and delay by looking on potential future = technologies. > > > > The real advocate on ITS is ISO TC204! > > > > > = ---------------------------------------------------------------------- > > ---------- > > > > + + + Instaurare omnia in Christo + + + > > > > > = ---------------------------------------------------------------------- > > ---------- > > > > The information contained in this message is confidential and = may be > > legally > > > > privileged. This email is intended for the addressee(s). = Addressees > > may be > > > > individual persons or members of mailing list. > > > > If you are not an addressee, you are hereby notified that any = use, > > > > dissemination, or reproduction of this email and its optional > > attachements is > > > > strictly prohibited and may be unlawful. If you are not an = addressee, > > please > > > > contact the sender by return e-mail and destroy all copies of = the > > original > > > > message. > > > > > = ---------------------------------------------------------------------- > > ---------- > > > > ESF GmbH > > > > Fichtenweg 9 > > > > 89143 Blaubeuren > > > > +49 (7344) 175340 (Direct = line > Dr. Fischer) > > > > +49 (7344) 919188 (Central = office) > > > > +49 (7344) 919123 (Fax) > > > > https://fischer-tech.eu : Main web of ESF GmbH > > > > http://its-standards.eu : News on cooperative ITS = standardization > > > > http://its-testing.org : International consultancy for = cooperative > > ITS > > > > > = ---------------------------------------------------------------------- > > ---------- > > > > > = ---------------------------------------------------------------------- > > ---------- > > > > ESF online-news:http://fischer-tech.eu/Feeds/esf.rss > > > > > C-ITS online news:http://its-standards.info/Feeds/cits.rss > > > > > ESF Online Nachrichten:http://fischer-tech.de/Feeds/esfD.rss > > > > > > = ---------------------------------------------------------------------- > > --------- > > >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > >=20 >=20 >=20 >=20 > -- > John Kenney > Director and Principal Researcher > Toyota InfoTechnology Center, USA > 465 Bernardo Avenue > Mountain View, CA 94043 > Tel: 650-694-4160. Mobile: 650-224-6644 From nobody Tue Feb 27 05:18:44 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70CE2126BFD for ; Tue, 27 Feb 2018 05:18:42 -0800 (PST) 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 RiszO0chMh_g for ; Tue, 27 Feb 2018 05:18:40 -0800 (PST) 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 635DA126BF3 for ; Tue, 27 Feb 2018 05:18:40 -0800 (PST) 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 w1RDIadt069025; Tue, 27 Feb 2018 14:18:36 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7481E2037DC; Tue, 27 Feb 2018 14:18:36 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 5BD7C2037C7; Tue, 27 Feb 2018 14:18:36 +0100 (CET) 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 w1RDIZlY006653; Tue, 27 Feb 2018 14:18:36 +0100 To: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , "'John Kenney'" Cc: "=?UTF-8?Q?'Fran=c3=a7ois_Simon'?=" , "'Dr. Hans-Joachim Fischer'" , "'Abdussalam Baryun'" , "'Tony Li'" , "'its'" References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <9ada5591-2af3-272d-3bc3-031bf35454c3@gmail.com> <6cdc0835-fb4c-133b-77ff-0234cfdd9ef9@fischer-tech.eu> <00eb01d3af1d$7f4e8100$7deb8300$@gmail.com> <6187cb92-5c8f-d08b-dcc2-859652d629d0@gmail.com> <002901d3af20$b966e960$2c34bc20$@eurecom.fr> <002601d3afc4$a10fbb90$e32f32b0$@eurecom.fr> From: Alexandre Petrescu Message-ID: <71309c28-9d7e-d277-a3b0-46d1a3b4042e@gmail.com> Date: Tue, 27 Feb 2018 14:18:35 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <002601d3afc4$a10fbb90$e32f32b0$@eurecom.fr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 27 Feb 2018 13:18:42 -0000 Le 27/02/2018 à 13:15, Jérôme Härri a écrit : > Hi Alex, > > >> Hi John, >> >> Thank you for the remark. >> >> I think that that potential harm can be avoided by IEEE in the >> first place; I think IEEE could specify - if deemed necessary - >> that OCB must only use QoS Data, and not Data. Currently IEEE >> allows both. >> >> There is no open source available, as far as I know, that transmits >> ITS messages as QoS Data. The implementations I have seen that send >> CAM as QoS Data are closed source. They come from Unex, on ThreadX >> operating system, Autotalks chipset. There may be others. >> >> There is a lot of cheap open source available that transmits ITS >> messages, and IP, as Data. They are available on github.com, are >> called 'rendits', 'vanetza', 'driveits', 'btpsap' and others. >> >> Given that situation of software availability and IEEE situation, I >> do not know how the recommendation above could be implemented. >> >> Alex > > Well IEEE 802.11-2016 OCB is agnostic to the criticality of the > traffic...(and I think it should remain so...). I agree. > It is WAVE and ETSI, which defined critical safety traffic and thus > imposed QoSData, as it is critically required for their > implementations and congestion control. I did not know that. > Now, using IPv6-over-OCB on the ITS-G5 bands follows the same > challenges as both BRAN (WLAN) and C-V2X...if it is used for > safety-related traffic, they should not create harmful interferences > with the current technology (DSRC/ITS-G5), I agree with the principle to not create harmful interference. One of the tools to avoid interference is the use of a distinct EtherType for IP than for GeoNetworking (ETSI) and than for WSMP (WAVE). This draft does use 0x86DD distinct than the others. Other tools could be: QoSData vs Data, and Access Category1 vs Category2. If IP uses Data, and ETSI and WAVE use QoSData, then I suppose we are fine - there is no interference. > which suggests (I am not a lawyer) that IPWAVE must use QoSData (at > least) and differentiate traffic to have access priority equivalent > to those defined by SAE/ETSI.... I can agree. But it is impossible to impose the use of QoSData for IP in these circumstances: there is no widely available source code for it. One may also question the IPR and the licensing scheme of that IP and QoSData (since you say law). > As mentioned, what does it cost to IPWAVE to recommend using QoSData > for IPv6-over-OCB? The text that allows IP to be transported as QoSData costs nothing. You and I can write it. But: - is there running code for that text? - will that text propagate existing, or create new, interoperability problems? By interoperability problems I mean the following: - whenever we use the word MAY, the later implementer will not know what to do. E.g. "IPv6 MAY be transported as Data, or MAY be transported as QoSData" is a huge difficulty for implementer. Which one to implement? - the current interoperability problems: some stacks send CAM as QoSData and receivers expect it as Data. - wireshark red packets: because dont know how to transform a QoSData packet into a EthernetII packet. > Now, I am also a bit surprised: I have not been long enough in IETF I > guess, but since when would IETF recommend a mechanism not because it > is good, but because it is the only open-source code available?? Well, there is the mantra of 'rough consensus and running code'. We are in the 'running code' part. To make running code I use open source. That is IP transported on OCB with 802.11 Data headers. If someone else uses closed source, and have an implementation of IP over 802.11 OCB transported as QoSData, please speak up. > If QoSData implementations are not available, let's make one...by > using QoSData instead of Data for IPWAVE, I agree, but who is 'us' in 'let's make one'? On my side I can not make one. I know unex/autotalks/threadx make one, because I can hear their CAM packets on QoSData. But they dont say anything on this list, so I take that silence as absence. In this situation, maybe there is somebody else that writes code to transport IP as QoSData? > you will save a lot of discussions about spectrum neutrality and > non-harmful interference, which might even block implementations > using this very RFC. Well, I agree the discussions can be long, and I would like to avoid at this time. My speculation, is that with the RECOMMENDATION to transport IP only as Data (silence about QoSData), this draft can be pursued. Alex From nobody Tue Feb 27 05:39:34 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D030D12D876 for ; Tue, 27 Feb 2018 05:39:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjYFb19jTQ9G for ; Tue, 27 Feb 2018 05:39:29 -0800 (PST) Received: from smtp2.eurecom.fr (smtp2.eurecom.fr [193.55.113.211]) by ietfa.amsl.com (Postfix) with ESMTP id 28C05126BF3 for ; Tue, 27 Feb 2018 05:39:28 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.47,401,1515452400"; d="scan'208";a="7705009" Received: from monza.eurecom.fr ([192.168.106.15]) by drago2i.eurecom.fr with ESMTP; 27 Feb 2018 14:39:28 +0100 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 238E3770; Tue, 27 Feb 2018 14:39:28 +0100 (CET) From: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= To: "'Alexandre Petrescu'" , "'John Kenney'" Cc: =?UTF-8?Q?'Fran=C3=A7ois_Simon'?= , "'Dr. Hans-Joachim Fischer'" , "'Abdussalam Baryun'" , "'Tony Li'" , "'its'" References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <9ada5591-2af3-272d-3bc3-031bf35454c3@gmail.com> <6cdc0835-fb4c-133b-77ff-0234cfdd9ef9@fischer-tech.eu> <00eb01d3af1d$7f4e8100$7deb8300$@gmail.com> <6187cb92-5c8f-d08b-dcc2-859652d629d0@gmail.com> <002901d3af20$b966e960$2c34bc20$@eurecom.fr> <002601d3afc4$a10fbb90$e32f32b0$@eurecom.fr> <71309c28-9d7e-d277-a3b0-46d1a3b4042e@gmail.com> In-Reply-To: <71309c28-9d7e-d277-a3b0-46d1a3b4042e@gmail.com> Date: Tue, 27 Feb 2018 14:39:27 +0100 Organization: EURECOM Message-ID: <004701d3afd0$63867190$2a9354b0$@eurecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHelLAw/aN7IRfcwiTBG/gKcgHVEwGONDnFAivYBTcB5QRVgwFu9SHuAdIGJvACSXL3QAKWMu63Adu1s18A8/GqjwFm8QpOAZ+WrA8C5SaIrQKK7AZQotpEeeA= Content-Language: en-us Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 27 Feb 2018 13:39:32 -0000 Hi Alex,=20 A quick answer to the first part.. When I mention interference, I mean channel interference. The = interference is even before you decode the packet and you know it is not = WAVE/ETSI...it is fairness in accessing channel. If the (future) RFC = uses IPv6 to transmit a big packet for sensor data on DIFS (so AIFN=3D2, = so equivalent to AC_VI), it will access the channel at the same time as = a DENM/event-BSM and thus will create a collision. As there is no spec = (so far) in IETF on how to handle wireless congestion control (e.g. = DCC), then the collision will reappear through IP retransmit...this is = what I call harmful interference... As for the second part, I agree that it would be good to have = code...have you tried the open code from R. Lisov =CC=81y at CTU Prague? = "IEEE 802.11p Linux Kernel Implementation"...they integrated EDCA in the = 802.11 part (but did not check how the kernel 'handles' QoSData...) BR, J=C3=A9r=C3=B4me -----Original Message----- From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com]=20 Sent: Tuesday 27 February 2018 14:19 To: J=C3=A9r=C3=B4me H=C3=A4rri; 'John Kenney' Cc: 'Fran=C3=A7ois Simon'; 'Dr. Hans-Joachim Fischer'; 'Abdussalam = Baryun'; 'Tony Li'; 'its' Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in = IPv6-over-802.11-OCB Le 27/02/2018 =C3=A0 13:15, J=C3=A9r=C3=B4me H=C3=A4rri a =C3=A9crit : > Hi Alex, >=20 >=20 >> Hi John, >>=20 >> Thank you for the remark. >>=20 >> I think that that potential harm can be avoided by IEEE in the first=20 >> place; I think IEEE could specify - if deemed necessary - that OCB=20 >> must only use QoS Data, and not Data. Currently IEEE allows both. >>=20 >> There is no open source available, as far as I know, that transmits=20 >> ITS messages as QoS Data. The implementations I have seen that send=20 >> CAM as QoS Data are closed source. They come from Unex, on ThreadX=20 >> operating system, Autotalks chipset. There may be others. >>=20 >> There is a lot of cheap open source available that transmits ITS=20 >> messages, and IP, as Data. They are available on github.com, are=20 >> called 'rendits', 'vanetza', 'driveits', 'btpsap' and others. >>=20 >> Given that situation of software availability and IEEE situation, I=20 >> do not know how the recommendation above could be implemented. >>=20 >> Alex >=20 > Well IEEE 802.11-2016 OCB is agnostic to the criticality of the=20 > traffic...(and I think it should remain so...). I agree. > It is WAVE and ETSI, which defined critical safety traffic and thus=20 > imposed QoSData, as it is critically required for their=20 > implementations and congestion control. I did not know that. > Now, using IPv6-over-OCB on the ITS-G5 bands follows the same=20 > challenges as both BRAN (WLAN) and C-V2X...if it is used for=20 > safety-related traffic, they should not create harmful interferences =20 > with the current technology (DSRC/ITS-G5), I agree with the principle to not create harmful interference. One of the tools to avoid interference is the use of a distinct = EtherType for IP than for GeoNetworking (ETSI) and than for WSMP (WAVE). This draft does use 0x86DD distinct than the others. Other tools could be: QoSData vs Data, and Access Category1 vs = Category2. If IP uses Data, and ETSI and WAVE use QoSData, then I suppose we are = fine - there is no interference. > which suggests (I am not a lawyer) that IPWAVE must use QoSData (at > least) and differentiate traffic to have access priority equivalent to = > those defined by SAE/ETSI.... I can agree. But it is impossible to impose the use of QoSData for IP = in these circumstances: there is no widely available source code for it. One may also question the IPR and the licensing scheme of that IP and = QoSData (since you say law). > As mentioned, what does it cost to IPWAVE to recommend using QoSData =20 > for IPv6-over-OCB? The text that allows IP to be transported as QoSData costs nothing. You = and I can write it. But: - is there running code for that text? - will that text propagate existing, or create new, interoperability problems? By interoperability problems I mean the following: - whenever we use the word MAY, the later implementer will not know what to do. E.g. "IPv6 MAY be transported as Data, or MAY be transported as QoSData" is a huge difficulty for implementer. Which one to implement? - the current interoperability problems: some stacks send CAM as QoSData and receivers expect it as Data. - wireshark red packets: because dont know how to transform a QoSData packet into a EthernetII packet. > Now, I am also a bit surprised: I have not been long enough in IETF I=20 > guess, but since when would IETF recommend a mechanism not because it=20 > is good, but because it is the only open-source code available?? Well, there is the mantra of 'rough consensus and running code'. We are = in the 'running code' part. To make running code I use open source. That is IP transported on OCB = with 802.11 Data headers. If someone else uses closed source, and have an implementation of IP = over 802.11 OCB transported as QoSData, please speak up. > If QoSData implementations are not available, let's make one...by=20 > using QoSData instead of Data for IPWAVE, I agree, but who is 'us' in 'let's make one'? On my side I can not make = one. I know unex/autotalks/threadx make one, because I can hear their CAM = packets on QoSData. But they dont say anything on this list, so I take = that silence as absence. In this situation, maybe there is somebody else that writes code to = transport IP as QoSData? > you will save a lot of discussions about spectrum neutrality and=20 > non-harmful interference, which might even block implementations using = > this very RFC. Well, I agree the discussions can be long, and I would like to avoid at = this time. My speculation, is that with the RECOMMENDATION to transport IP only as = Data (silence about QoSData), this draft can be pursued. Alex From nobody Tue Feb 27 06:54:08 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44E2A12DA00 for ; Tue, 27 Feb 2018 06:54:06 -0800 (PST) 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 qHTEQ1h8tcaJ for ; Tue, 27 Feb 2018 06:54:03 -0800 (PST) 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 4787412D965 for ; Tue, 27 Feb 2018 06:54:03 -0800 (PST) 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 w1RErx8C032821; Tue, 27 Feb 2018 15:53:59 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 967F6202AC4; Tue, 27 Feb 2018 15:53:59 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 7CA132060A3; Tue, 27 Feb 2018 15:53:59 +0100 (CET) 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 w1RErxfg017748; Tue, 27 Feb 2018 15:53:59 +0100 To: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , "'John Kenney'" Cc: "=?UTF-8?Q?'Fran=c3=a7ois_Simon'?=" , "'Dr. Hans-Joachim Fischer'" , "'Abdussalam Baryun'" , "'Tony Li'" , "'its'" References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <9ada5591-2af3-272d-3bc3-031bf35454c3@gmail.com> <6cdc0835-fb4c-133b-77ff-0234cfdd9ef9@fischer-tech.eu> <00eb01d3af1d$7f4e8100$7deb8300$@gmail.com> <6187cb92-5c8f-d08b-dcc2-859652d629d0@gmail.com> <002901d3af20$b966e960$2c34bc20$@eurecom.fr> <002601d3afc4$a10fbb90$e32f32b0$@eurecom.fr> <71309c28-9d7e-d277-a3b0-46d1a3b4042e@gmail.com> <004701d3afd0$63867190$2a9354b0$@eurecom.fr> From: Alexandre Petrescu Message-ID: <9acb0e4d-42bf-22bf-3397-66a14f004aaf@gmail.com> Date: Tue, 27 Feb 2018 15:53:59 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <004701d3afd0$63867190$2a9354b0$@eurecom.fr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 27 Feb 2018 14:54:06 -0000 Le 27/02/2018 à 14:39, Jérôme Härri a écrit : > Hi Alex, > > A quick answer to the first part.. > > When I mention interference, I mean channel interference. The > interference is even before you decode the packet and you know it is > not WAVE/ETSI...it is fairness in accessing channel. If the (future) > RFC uses IPv6 to transmit a big packet for sensor data on DIFS (so > AIFN=2, so equivalent to AC_VI), it will access the channel at the > same time as a DENM/event-BSM and thus will create a collision. As > there is no spec (so far) in IETF on how to handle wireless > congestion control (e.g. DCC), then the collision will reappear > through IP retransmit...this is what I call harmful interference... > > > As for the second part, I agree that it would be good to have > code...have you tried the open code from R. Lisov ́y at CTU Prague? > "IEEE 802.11p Linux Kernel Implementation"... That paper refers to a 2014 OCB submission to the kernel. Since then OCB was integrated in the mainline. And yes, we do use that OCB. > they integrated EDCA in the 802.11 part How to use that EDCA? There is no kernel option called 'EDCA' nor 'DCF'. There is no option 'EDCA' or 'DCF' for the iw tool. > (but did not check how the > kernel 'handles' QoSData...) I checked the 'rendits' software at github.com that generates CAM and Co. messages and none of them is transported as QoSData. They are transported as Data. Do you know how to make that work? Alex > > > BR, > > Jérôme > > -----Original Message----- From: Alexandre Petrescu > [mailto:alexandre.petrescu@gmail.com] Sent: Tuesday 27 February 2018 > 14:19 To: Jérôme Härri; 'John Kenney' Cc: 'François Simon'; 'Dr. > Hans-Joachim Fischer'; 'Abdussalam Baryun'; 'Tony Li'; 'its' > Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in > IPv6-over-802.11-OCB > > > > Le 27/02/2018 à 13:15, Jérôme Härri a écrit : >> Hi Alex, >> >> >>> Hi John, >>> >>> Thank you for the remark. >>> >>> I think that that potential harm can be avoided by IEEE in the >>> first place; I think IEEE could specify - if deemed necessary - >>> that OCB must only use QoS Data, and not Data. Currently IEEE >>> allows both. >>> >>> There is no open source available, as far as I know, that >>> transmits ITS messages as QoS Data. The implementations I have >>> seen that send CAM as QoS Data are closed source. They come from >>> Unex, on ThreadX operating system, Autotalks chipset. There may >>> be others. >>> >>> There is a lot of cheap open source available that transmits ITS >>> messages, and IP, as Data. They are available on github.com, are >>> called 'rendits', 'vanetza', 'driveits', 'btpsap' and others. >>> >>> Given that situation of software availability and IEEE >>> situation, I do not know how the recommendation above could be >>> implemented. >>> >>> Alex >> >> Well IEEE 802.11-2016 OCB is agnostic to the criticality of the >> traffic...(and I think it should remain so...). > > I agree. > >> It is WAVE and ETSI, which defined critical safety traffic and thus >> imposed QoSData, as it is critically required for their >> implementations and congestion control. > > I did not know that. > >> Now, using IPv6-over-OCB on the ITS-G5 bands follows the same >> challenges as both BRAN (WLAN) and C-V2X...if it is used for >> safety-related traffic, they should not create harmful >> interferences with the current technology (DSRC/ITS-G5), > > I agree with the principle to not create harmful interference. > > One of the tools to avoid interference is the use of a distinct > EtherType for IP than for GeoNetworking (ETSI) and than for WSMP > (WAVE). This draft does use 0x86DD distinct than the others. > > Other tools could be: QoSData vs Data, and Access Category1 vs > Category2. > > If IP uses Data, and ETSI and WAVE use QoSData, then I suppose we > are fine - there is no interference. > >> which suggests (I am not a lawyer) that IPWAVE must use QoSData (at >> least) and differentiate traffic to have access priority equivalent >> to those defined by SAE/ETSI.... > > I can agree. But it is impossible to impose the use of QoSData for > IP in these circumstances: there is no widely available source code > for it. One may also question the IPR and the licensing scheme of > that IP and QoSData (since you say law). > >> As mentioned, what does it cost to IPWAVE to recommend using >> QoSData for IPv6-over-OCB? > > The text that allows IP to be transported as QoSData costs nothing. > You and I can write it. > > But: - is there running code for that text? - will that text > propagate existing, or create new, interoperability problems? > > By interoperability problems I mean the following: - whenever we use > the word MAY, the later implementer will not know what to do. E.g. > "IPv6 MAY be transported as Data, or MAY be transported as QoSData" > is a huge difficulty for implementer. Which one to implement? - the > current interoperability problems: some stacks send CAM as QoSData > and receivers expect it as Data. - wireshark red packets: because > dont know how to transform a QoSData packet into a EthernetII > packet. > >> Now, I am also a bit surprised: I have not been long enough in >> IETF I guess, but since when would IETF recommend a mechanism not >> because it is good, but because it is the only open-source code >> available?? > > Well, there is the mantra of 'rough consensus and running code'. We > are in the 'running code' part. > > To make running code I use open source. That is IP transported on > OCB with 802.11 Data headers. > > If someone else uses closed source, and have an implementation of IP > over 802.11 OCB transported as QoSData, please speak up. > >> If QoSData implementations are not available, let's make one...by >> using QoSData instead of Data for IPWAVE, > > I agree, but who is 'us' in 'let's make one'? On my side I can not > make one. > > I know unex/autotalks/threadx make one, because I can hear their CAM > packets on QoSData. But they dont say anything on this list, so I > take that silence as absence. > > In this situation, maybe there is somebody else that writes code to > transport IP as QoSData? > >> you will save a lot of discussions about spectrum neutrality and >> non-harmful interference, which might even block implementations >> using this very RFC. > > Well, I agree the discussions can be long, and I would like to avoid > at this time. > > My speculation, is that with the RECOMMENDATION to transport IP only > as Data (silence about QoSData), this draft can be pursued. > > Alex > > From nobody Tue Feb 27 07:57:48 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05723126C22 for ; Tue, 27 Feb 2018 07:57:46 -0800 (PST) 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 i9a7kUizy0HM for ; Tue, 27 Feb 2018 07:57:44 -0800 (PST) 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 CECB81242F5 for ; Tue, 27 Feb 2018 07:57:43 -0800 (PST) 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 w1RFveSt048217; Tue, 27 Feb 2018 16:57:40 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D11AE20732A; Tue, 27 Feb 2018 16:57:40 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id B88422073C1; Tue, 27 Feb 2018 16:57:40 +0100 (CET) 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 w1RFveeZ021385; Tue, 27 Feb 2018 16:57:40 +0100 To: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , "'John Kenney'" Cc: "=?UTF-8?Q?'Fran=c3=a7ois_Simon'?=" , "'Dr. Hans-Joachim Fischer'" , "'Abdussalam Baryun'" , "'Tony Li'" , "'its'" References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <9ada5591-2af3-272d-3bc3-031bf35454c3@gmail.com> <6cdc0835-fb4c-133b-77ff-0234cfdd9ef9@fischer-tech.eu> <00eb01d3af1d$7f4e8100$7deb8300$@gmail.com> <6187cb92-5c8f-d08b-dcc2-859652d629d0@gmail.com> <002901d3af20$b966e960$2c34bc20$@eurecom.fr> <002601d3afc4$a10fbb90$e32f32b0$@eurecom.fr> <71309c28-9d7e-d277-a3b0-46d1a3b4042e@gmail.com> <004701d3afd0$63867190$2a9354b0$@eurecom.fr> From: Alexandre Petrescu Message-ID: <461166f2-f3cc-e749-3628-f1d87104200b@gmail.com> Date: Tue, 27 Feb 2018 16:57:40 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <004701d3afd0$63867190$2a9354b0$@eurecom.fr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 27 Feb 2018 15:57:46 -0000 Le 27/02/2018 à 14:39, Jérôme Härri a écrit : > Hi Alex, > > A quick answer to the first part.. > > When I mention interference, I mean channel interference. The > interference is even before you decode the packet and you know it is > not WAVE/ETSI...it is fairness in accessing channel. If the (future) > RFC uses IPv6 to transmit a big packet for sensor data on DIFS (so > AIFN=2, so equivalent to AC_VI), it will access the channel at the > same time as a DENM/event-BSM and thus will create a collision. As > there is no spec (so far) in IETF on how to handle wireless > congestion control (e.g. DCC), then the collision will reappear > through IP retransmit...this is what I call harmful interference... > > > As for the second part, I agree that it would be good to have > code...have you tried the open code from R. Lisov ́y at CTU Prague? > "IEEE 802.11p Linux Kernel Implementation"...they integrated EDCA in > the 802.11 part (but did not check how the kernel 'handles' > QoSData...) FYI, we also tried to ping -Q which does set a proper DSCP in the IPv4 headers, yet there is no QoS Data header. If someone knows how to generate a QoSData transported IP packet with linux open source then I am all ears. Alex From nobody Tue Feb 27 08:13:07 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 355A1129C6A for ; Tue, 27 Feb 2018 08:13:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h30LxEfcinNl for ; Tue, 27 Feb 2018 08:13:04 -0800 (PST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (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 61F8212D7F1 for ; Tue, 27 Feb 2018 08:13:04 -0800 (PST) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1eqhsD-0000rm-00; Tue, 27 Feb 2018 17:13:01 +0100 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id EC79A420F42; Tue, 27 Feb 2018 17:13:00 +0100 (CET) To: Alexandre Petrescu , =?UTF-8?Q?Fran=c3=a7ois_Simon?= , =?UTF-8?B?J0rDqXLDtG1lIEjDpHJyaSc=?= , its@ietf.org References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <006301d3ace3$25f9d500$71ed7f00$@eurecom.fr> <007901d3aee3$a9985ba0$fcc912e0$@eurecom.fr> <00f801d3af1d$f20ce4c0$d626ae40$@gmail.com> From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology Message-ID: Date: Tue, 27 Feb 2018 17:13:00 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1519747981.048928288 Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 27 Feb 2018 16:13:06 -0000 Hi, Am 26.02.2018 um 17:40 schrieb Alexandre Petrescu: > Le 26/02/2018 à 17:22, François Simon a écrit : >> Correct ! > > Is there a mapping between the Access Categories and IPv6 Traffic Class > fields? Yes, since Traffic Class is currently used for the DSCP and ECN, see rfc8325. Regards, Roland From nobody Tue Feb 27 08:26:20 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 142E712D969 for ; Tue, 27 Feb 2018 08:26:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pkd-zTXOhCey for ; Tue, 27 Feb 2018 08:26:17 -0800 (PST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (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 A03B11242F5 for ; Tue, 27 Feb 2018 08:26:17 -0800 (PST) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1eqi51-0001xC-IH; Tue, 27 Feb 2018 17:26:15 +0100 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 830F8420F42; Tue, 27 Feb 2018 17:26:15 +0100 (CET) To: Alexandre Petrescu , =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , =?UTF-8?Q?'Fran=c3=a7ois_Simon'?= , its@ietf.org References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <006301d3ace3$25f9d500$71ed7f00$@eurecom.fr> <007901d3aee3$a9985ba0$fcc912e0$@eurecom.fr> <00f801d3af1d$f20ce4c0$d626ae40$@gmail.com> <002b01d3af21$6e779a70$4b66cf50$@eurecom.fr> From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology Message-ID: Date: Tue, 27 Feb 2018 17:26:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1519748775.623226986 Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 27 Feb 2018 16:26:19 -0000 Hi Alex, see inline. Am 26.02.2018 um 18:07 schrieb Alexandre Petrescu: > Le 26/02/2018 à 17:47, Jérôme Härri a écrit : >> Hi Alex, All, >> >> Made a minor mistake: the 802.1D UP are actually 8 values, 0-7. So 8 >> bits, and accordingly you can directly map the IPv6 TC to the >> UP...there is a spec in ETSI for that, but not sure if there is one >> spec in IETF for that. > > At IETF there is a spec that says that the Traffic Class field in the > IPv6 header contains a DSCP (differentiated service code point) of > length 6bit and the other 2bits are 'currently' unused. (RFC2474). > > As such, I dont think a one-to-one mapping between a 802.1D UP value and > a DSCP value is possible, unless some compression algorithm is used. RFC 8325 provides DSCP-to-UP mapping recommendations, so it's at least a suggestion for a default mapping. DSCPs can be chosen freely by DiffServ providers, so a custom DSCP configuration needs also a customized mapping then... > So, I dont think that mapping is as straightforward as one might see it > at a first sight. > >> (did not have time to read Roland's identified RFC yet...maybe it is >> there...) > > I looked at the RFC8325 referred to by Roland.  As the mapping of an > 8-bit value to a 6-bit value is not straightforward they do agree on a > number of inconsistencies and potential conflicts. It is actually a DSCP 6-bit value to a 3-bit UP value, which is then mapped to one of the four AC values. > That is why I thik RFC8325 could be a good starting point, but there > should be more. Then you should clearly state what is actually missing there... Regards Roland From nobody Tue Feb 27 08:52:41 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29EFE12DA2C for ; Tue, 27 Feb 2018 08:52:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 i5NlEjAae-vL for ; Tue, 27 Feb 2018 08:52:38 -0800 (PST) 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 DC3B9124217 for ; Tue, 27 Feb 2018 08:52:38 -0800 (PST) Received: from resomta-po-10v.sys.comcast.net ([96.114.154.234]) by resqmta-po-12v.sys.comcast.net with ESMTP id qiTdeC7Yk4WkeqiUYeBswB; Tue, 27 Feb 2018 16:52:38 +0000 Received: from [172.22.228.216] ([162.210.130.3]) by resomta-po-10v.sys.comcast.net with SMTP id qiSGe5caW5vXJqiSIe7olM; Tue, 27 Feb 2018 16:50:36 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Tony Li In-Reply-To: <461166f2-f3cc-e749-3628-f1d87104200b@gmail.com> Date: Tue, 27 Feb 2018 08:50:15 -0800 Cc: =?utf-8?B?SsOpcsO0bWUgSMOkcnJp?= , John Kenney , =?utf-8?Q?Fran=C3=A7ois_Simon?= , "Dr. Hans-Joachim Fischer" , Abdussalam Baryun , its Content-Transfer-Encoding: quoted-printable Message-Id: <4997BFDE-1B3F-4F17-9742-28F23F082A15@tony.li> References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <9ada5591-2af3-272d-3bc3-031bf35454c3@gmail.com> <6cdc0835-fb4c-133b-77ff-0234cfdd9ef9@fischer-tech.eu> <00eb01d3af1d$7f4e8100$7deb8300$@gmail.com> <6187cb92-5c8f-d08b-dcc2-859652d629d0@gmail.com> <002901d3af20$b966e960$2c34bc20$@eurecom.fr> <002601d3afc4$a10fbb90$e32f32b0$@eurecom.fr> <71309c28-9d7e-d277-a3b0-46d1a3b4042e@gmail.com> <004701d3afd0$63867190$2a9354b0$@eurecom.fr> <461166f2-f3cc-e749-3628-f1d87104200b@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3445.5.20) X-CMAE-Envelope: MS4wfF+8o7Yy1/SvWa1ZigwXTDKprfE5QJeUUBVTmEBmIjM/MGX1t8QxEW2bEkMp/XyB7pGSSXOTDSa97qAR5cwC05ukfFgB6Xrk+Gqjlw0FAfFEUzeNsPGt KMEnHUIEoqo9yGpn9UaCsNdZsTIs5CBLqlNXLbVOalihZEWPE8Oplu3VLSO/DGkdu52Ox4McmG0mCb+3TW6tzHxwixEs8a2hpUFy0OT4vCdY4bFY9rxLsijt IbseIyKXJAu6/y7w7w3vSl9qV+iMSnwywmZEN2rx/ZH9ZcgIfaqRkU5VfTDaMrFk+zL1YYGxqvWmzZ96QvH6GGqFAilhpeh/V0dM0/5GMjWTo9Ot1IFT7p70 wz5RzTASHobiXAUmD/OkNi9WTGf4LA== Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 27 Feb 2018 16:52:40 -0000 > If someone knows how to generate a QoSData transported IP packet with = linux open source then I am all ears. This is just a Small Matter Of Programming for anyone with a bit of = kernel hacking experience and driver sources. Tony From nobody Tue Feb 27 15:13:33 2018 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 D418A12E8EB; Tue, 27 Feb 2018 15:11:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: suresh@kaloom.com, its@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151977307086.5200.12281073484960483495.idtracker@ietfa.amsl.com> Date: Tue, 27 Feb 2018 15:11:10 -0800 Archived-At: Subject: [ipwave] ipwave - Requested session has been scheduled for IETF 101 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, 27 Feb 2018 23:11:11 -0000 Dear Carlos Bernardos, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. ipwave Session 1 (2:30:00) Monday, Morning Session I 0930-1200 Room Name: Sandringham size: 300 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: IP Wireless Access in Vehicular Environments Area Name: Internet Area Session Requester: Carlos Bernardos Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: dmm detnet nfvrg lamps stir intarea 6lo 6man manet rtgarea saag l2sm suit Second Priority: sfc cfrg dhc roll ospf i2nsf isis lime Third Priority: mtgvenue iasa20 People who must be present: Russ Housley Suresh Krishnan Carlos J. Bernardos Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue Feb 27 18:29:37 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D45D212D95A for ; Tue, 27 Feb 2018 18:29:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=us-toyota-itc-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LFGMqhDp0hP for ; Tue, 27 Feb 2018 18:29:34 -0800 (PST) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F4C5127775 for ; Tue, 27 Feb 2018 18:29:34 -0800 (PST) Received: by mail-it0-x235.google.com with SMTP id a75so1679880itd.0 for ; Tue, 27 Feb 2018 18:29:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=us-toyota-itc-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=x3e3VwLknaElxYRcEV4JImogqsMwQlvXTOSRLNGUAAM=; b=Jq4ttdLdGTHSU0sdgYSNdtA0t/TuiCwq+Jc09xkSKVFUy9SD0upifkpVim6bd7oWS8 OHPXvk1MuM/dH4DqOCncbADJtCQXwFn8+Xby6QHRynkDSQW9QZqU+uiszVhreyWAuQW7 M5od63bHd9NXJxtV4rUzKeG9XrFHIA2wpmwNd+Qe87DKCDiqew1doG5M/aUmca9PfJbo 7Ws0/ITmtCJLKrxNLE+1X192CpmfghRIldaO6wII00p8egnJz/p11JJlUFGCgpO9t1Ga LhLuyXT2EY3FsoodOy0RjY2hlowxHsERgJf92TIcqNBmjE39yNW2/e0/GV8UB5Db755P PW2w== 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=x3e3VwLknaElxYRcEV4JImogqsMwQlvXTOSRLNGUAAM=; b=J9wV2jGquwjFB+W5BPcA8ZWsVzH3ip7TZATq/NYWjn+XpUJydRzQurEvHmMYoSu3cW PwRpqDOQ3cGje6IgYH1siUZecN58qZZ+Vpk1Gjc05Q3nWTr6gIoc2+aYzhaCNsP0K5SO T7Y4QJ1lWCQG444DrASlvai037arkeAGQb5E/3teMhjb5vQDOCRa24WwAK0aloJ/CIAU VYqtiEM/fH5Q9MZA/grcj2KpzI60ngWg8pNFiYxLmbEVrfgmJezNlCNqZkG7zjiseOTS 0baNMoPkYHjR2FjyaBHXjJcGKITaN+FHD4oJPZkjh2o3GKB0WAemkoT4pi0tOvSQRdto kpvQ== X-Gm-Message-State: APf1xPCIgoBLb3sIGehwZRcTszzP0lFLl+lp0VKjHVi4o+ZEGd038vJk OTiNG4n/Mcps5jiZP6WmIPpiQUd7sIj7gL9e/dFSgg== X-Google-Smtp-Source: AG47ELv7C+NrKxWTGGMcSn+3MD5qePmCxzlzAeNw7NXSnA6XhE3/gFf5v7EcC2aeKFUXPqOKoddstoZTx2zX6bCnC7Y= X-Received: by 10.36.2.75 with SMTP id 72mr19444106itu.83.1519784973588; Tue, 27 Feb 2018 18:29:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.24.135 with HTTP; Tue, 27 Feb 2018 18:29:33 -0800 (PST) In-Reply-To: References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <9ada5591-2af3-272d-3bc3-031bf35454c3@gmail.com> From: John Kenney Date: Tue, 27 Feb 2018 18:29:33 -0800 Message-ID: To: Alexandre Petrescu Cc: its Content-Type: multipart/alternative; boundary="001a1144a6547c7f4205663c83c5" Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB - text modifications towards resolution 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, 28 Feb 2018 02:29:37 -0000 --001a1144a6547c7f4205663c83c5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, I disagree. I suggest: NEW: > In OCB mode, an IPv6 packet MUST be transmitted as an "IEEE 802.11 QoS Data" frame. In the QoS Control Field, the TID subfield (Bits 0-3) MUST be set equal to binary 0001, corresponding to UP =3D 1. Apologies if I don't have the IETF normative syntax right. Note that UP =3D 1 maps to AC_BK. Best Regards, John On Tue, Feb 27, 2018 at 2:43 AM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > I propose the following modifications towards resolution of this QoS issu= e. > > Do you disagree? > > OLD: > > In OCB mode, IPv6 packets MAY be transmitted either as "IEEE 802.11 > > Data" or alternatively as "IEEE 802.11 QoS Data", as illustrated in > > Figure 2. > > NEW: > > In OCB mode, it is RECOMMENDED to transmit IPv6 packets as "IEEE > > 802.11 Data" (the value of the field Subtype in the Frame Control > > Field is 0). > > Remove this entire OLD text: > >> In OCB mode, IPv6 packets MAY be transmitted either as "IEEE 802.11 >> Data" or alternatively as "IEEE 802.11 QoS Data", as illustrated in >> Figure 2. >> >> +--------------------+-------------+-------------+---------+-----------+ >> | 802.11 Data Header | LLC Header | IPv6 Header | Payload |.11 Trailer| >> +--------------------+-------------+-------------+---------+-----------+ >> >> or >> >> +--------------------+-------------+-------------+---------+-----------+ >> | 802.11 QoS Data Hdr| LLC Header | IPv6 Header | Payload |.11 Trailer| >> +--------------------+-------------+-------------+---------+-----------+ >> >> Figure 2: 802.11 Data Header or 802.11 QoS Data Header >> >> 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 >> [I-D.ietf-tsvwg-ieee-802-11], although it is not specific to OCB >> mode. >> > > Alex > > > Le 25/02/2018 =C3=A0 18:58, Alexandre Petrescu a =C3=A9crit : > >> I propose the following text. >> >> OLD: >> >>> In OCB mode, IPv6 packets MAY be transmitted either as "IEEE 802.11 >>> Data" or alternatively as "IEEE 802.11 QoS Data", as illustrated in >>> Figure 2. >>> >> >> NEW: >> >>> In OCB mode, it is RECOMMENDED to transmit IPv6 packets as "IEEE >>> 802.11 Data" (the value of the field Subtype in the Frame Control >>> Field is 0). >>> >> >> Alex >> > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > --=20 John Kenney Director and Principal Researcher Toyota InfoTechnology Center, USA 465 Bernardo Avenue Mountain View, CA 94043 Tel: 650-694-4160. Mobile: 650-224-6644 --001a1144a6547c7f4205663c83c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, I disagree.

I suggest:
NEW:
>=C2=A0 In = OCB mode, an IPv6 packet MUST be transmitted as an "IEEE=C2=A0<= span style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:sm= all;font-style:normal;font-variant-ligatures:normal;font-variant-caps:norma= l;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;te= xt-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(= 255,255,255);text-decoration-style:initial;text-decoration-color:initial;fl= oat:none;display:inline">802.11 QoS Data" frame. In the QoS Control Fi= eld, the TID subfield (Bits 0-3) MUST be set equal to binary 0001, correspo= nding to UP =3D 1.=C2=A0
=
Apologies if I don't ha= ve the IETF normative syntax right.

Note that UP = =3D 1 maps to AC_BK.

Best Regards,
John<= /div>


On Tue, Feb 27, 2018 at 2:43 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:
I propose the following modifications towa= rds resolution of this QoS issue.

Do you disagree?

OLD:
>=C2=A0 =C2=A0 In OCB mode, IPv6 packets MAY be transmitted either as &q= uot;IEEE 802.11
>=C2=A0 =C2=A0 Data" or alternatively as "IEEE 802.11 QoS Data= ", as illustrated in
>=C2=A0 =C2=A0 Figure 2.

NEW:
>=C2=A0 =C2=A0 In OCB mode, it is RECOMMENDED to transmit IPv6 packets a= s "IEEE
>=C2=A0 =C2=A0 802.11 Data" (the value of the field Subtype in the = Frame Control
>=C2=A0 =C2=A0 Field is 0).

Remove this entire OLD text:
=C2=A0 =C2=A0In OCB mode, IPv6 packets MAY be transmitted either as "I= EEE 802.11
=C2=A0 =C2=A0Data" or alternatively as "IEEE 802.11 QoS Data"= ;, as illustrated in
=C2=A0 =C2=A0Figure 2.

+--------------------+-------------+-------------+---------+-----= ------+
| 802.11 Data Header | LLC Header=C2=A0 | IPv6 Header | Payload |.11 Traile= r|
+--------------------+-------------+-------------+---------+-----= ------+

or

+--------------------+-------------+-------------+---------+-----= ------+
| 802.11 QoS Data Hdr| LLC Header=C2=A0 | IPv6 Header | Payload |.11 Traile= r|
+--------------------+-------------+-------------+---------+-----= ------+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Figure 2: 802.11 Data Header or 802.11 Q= oS Data Header

=C2=A0 =C2=A0The distinction between the two formats is given by the value = of the
=C2=A0 =C2=A0field "Type/Subtype".=C2=A0 The value of the field &= quot;Type/Subtype" in the
=C2=A0 =C2=A0802.11 Data header is 0x0020.=C2=A0 The value of the field &qu= ot;Type/Subtype"
=C2=A0 =C2=A0in the 802.11 QoS header is 0x0028.

=C2=A0 =C2=A0The mapping between qos-related fields in the IPv6 header (e.g= .
=C2=A0 =C2=A0"Traffic Class", "Flow label") and fields = in the "802.11 QoS Data
=C2=A0 =C2=A0Header" (e.g.=C2=A0 "QoS Control") are not spec= ified in this document.
=C2=A0 =C2=A0Guidance for a potential mapping is provided in
=C2=A0 =C2=A0[I-D.ietf-tsvwg-ieee-802-11], although it is not specific to O= CB
=C2=A0 =C2=A0mode.

Alex


Le 25/02/2018 =C3=A0 18:58, Alexandre Petrescu a =C3=A9crit=C2=A0:
I propose the following text.

OLD:
=C2=A0=C2=A0 In OCB mode, IPv6 packets MAY be transmitted either as "I= EEE 802.11
=C2=A0=C2=A0 Data" or alternatively as "IEEE 802.11 QoS Data"= ;, as illustrated in
=C2=A0=C2=A0 Figure 2.

NEW:
=C2=A0=C2=A0 In OCB mode, it is RECOMMENDED to transmit IPv6 packets as &qu= ot;IEEE
=C2=A0=C2=A0 802.11 Data" (the value of the field Subtype in the Frame= Control
=C2=A0=C2=A0 Field is 0).

Alex

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



--
John Kenney
Director and Principal Researcher
Toyota InfoTechnology Center, USA
465 Bernardo Avenue
Mountain View, CA 94043
Tel: 650-694-4160. Mobile: 650-224-6644
--001a1144a6547c7f4205663c83c5-- From nobody Tue Feb 27 18:37:16 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C78E127775 for ; Tue, 27 Feb 2018 18:37:15 -0800 (PST) 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 mPgOAtMLXG2z for ; Tue, 27 Feb 2018 18:37:14 -0800 (PST) Received: from resqmta-po-07v.sys.comcast.net (resqmta-po-07v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:166]) (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 EF954126CE8 for ; Tue, 27 Feb 2018 18:37:13 -0800 (PST) Received: from resomta-po-04v.sys.comcast.net ([96.114.154.228]) by resqmta-po-07v.sys.comcast.net with ESMTP id qrcHe60oF61RxqrcHe2rwb; Wed, 28 Feb 2018 02:37:13 +0000 Received: from [172.22.228.216] ([162.210.130.3]) by resomta-po-04v.sys.comcast.net with SMTP id qra7ejgN2No7Wqra9e452S; Wed, 28 Feb 2018 02:35:11 +0000 From: Tony Li Message-Id: <52ADDCC5-5AF1-4657-AE0C-AD9240ED6093@tony.li> Content-Type: multipart/alternative; boundary="Apple-Mail=_C827AF30-3035-43D4-926C-FD6A0B6EF094" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Tue, 27 Feb 2018 18:34:58 -0800 In-Reply-To: Cc: Alexandre Petrescu , its To: John Kenney References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <9ada5591-2af3-272d-3bc3-031bf35454c3@gmail.com> X-Mailer: Apple Mail (2.3445.5.20) X-CMAE-Envelope: MS4wfECLLlCorh+A9+GaZ/hj4+uGsKBoaXpvMMTlA7ANNO6qRQOtrmiyv28xFFiKLo6fCWX+Q0oMQE0NwodP5dK0osbxTka4LQ+1RxPK1xf7ekEcpstJO4fT FT4JlIDH97p1D1ECapl4BIjW6BeOwuo+/JTj8EXsXjwoGWRxLwvbzJqJCthDRMKDZLsGcLoDsL0oFhkkadqrbvxuy2MxNNB7sv6S1ah728fURkvW1w1zyDlI fgRmeSLrAGLnmgtEXvRAKg== Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB - text modifications towards resolution 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, 28 Feb 2018 02:37:15 -0000 --Apple-Mail=_C827AF30-3035-43D4-926C-FD6A0B6EF094 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > I suggest: > NEW: > > In OCB mode, an IPv6 packet MUST be transmitted as an "IEEE 802.11 = QoS Data" frame. In the QoS Control Field, the TID subfield (Bits 0-3) = MUST be set equal to binary 0001, corresponding to UP =3D 1.=20 >=20 > Apologies if I don't have the IETF normative syntax right. The normative syntax looks fine to me. As long as you capitalize your = MUSTs and it=E2=80=99s clear, it=E2=80=99s usually just fine. Why is this somehow better than just sending it as data? It=E2=80=99s = worse, in that it=E2=80=99s more bits in the ether. What are we getting = for the cost? Tony --Apple-Mail=_C827AF30-3035-43D4-926C-FD6A0B6EF094 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

I suggest:
NEW:
>  In OCB mode, an IPv6 = packet MUST be transmitted as an "IEEE 802.11 QoS Data" frame. In the QoS = Control Field, the TID subfield (Bits 0-3) MUST be set equal to binary = 0001, corresponding to UP =3D 1. 

Apologies if I don't have the IETF normative syntax = right.


The normative syntax looks fine to me. As long as you = capitalize your MUSTs and it=E2=80=99s clear, it=E2=80=99s usually just = fine.

Why is this somehow better = than just sending it as data?  It=E2=80=99s worse, in that it=E2=80=99= s more bits in the ether.  What are we getting for the = cost?

Tony


= --Apple-Mail=_C827AF30-3035-43D4-926C-FD6A0B6EF094-- From nobody Tue Feb 27 22:08:29 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D49C512D96B for ; Tue, 27 Feb 2018 22:08:28 -0800 (PST) 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 MUKnX4ero7dL for ; Tue, 27 Feb 2018 22:08:26 -0800 (PST) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69E82120713 for ; Tue, 27 Feb 2018 22:08:26 -0800 (PST) Received: by mail-vk0-x232.google.com with SMTP id y127so792681vky.9 for ; Tue, 27 Feb 2018 22:08:26 -0800 (PST) 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=//FUwot8eMqDw56TtwPXsHoOFP/VAs6stfbpIl28W7o=; b=iroxYP0xw4QVZ0C5yAvrH0IXE0szPknkTXwiIdRaSxBiOyOhoLoExocG/vLqVNE9g5 78ePpQxiVzME3bHzqPwQ2C9xO2lHq4cb2ZDqzI9r7R46FHgvA5AdWlGeJO4YJiQAdWPN wQxrtZeOLhJRgkPfQ3JyjsMXcVW0v/AwZBRmTYrGh1cGNxdj/kQtn1dwayXvj2k3Lp8n /8yG6aQAwTTUhd+SNX2ZU5jXx7b4YC8tuNNu6jM3nDS251bsoeSnNHsf+RCRjZUs9z2D 8maGD5aAg77dRPCh7ie0H24FPiue8fJVoHwhtiUFQ+EIj6qhmOM6gMkw9ODRA2FhzuBM a43w== 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=//FUwot8eMqDw56TtwPXsHoOFP/VAs6stfbpIl28W7o=; b=H5U1out1F0BzkJjcwzQgXxnRJFBXXUKSfdN/+pLgTulGSZqr+Fmt9t/niDmdwRzem1 n97G9gQM7gfDAqTB7ovAkCl5Drn8CfErDTHNv9bKGguf866CCck3zwstYZoPI5zPQhxT fJNFxz0+m1C3/Gn11gaaEywEshSuRYGTI7/Jy7BEDNn/bG+TWFcjDSEzd/Uvs7ltMuKf n3L4us4oHdKDrAcYh1yW0N5likHkl6do6pPlSh/6DLy8soNGy9Y8aIRrEs23UjXeC15s LTwLia60bmGY7zJfwLhRWenDhUWU8YMY+U12ZCcaafeSzbpv8WvY8Q9vvbyQBAvoSzbu T8tw== X-Gm-Message-State: APf1xPBU8hBsbQjVWx+aYqjyoIZWUQfgkGLupNIK/9Pu3Ebe247qN/h2 Ac7pWBj+xMXRLon695Zq7YctOVr1loAEiV2nEk8= X-Google-Smtp-Source: AG47ELuiPwIFUzVipXn9oxBQekpcUR5/glebSQl7RZ4A8TMhrj1MdgOU6oNW4808NbCVdJJitHmY9hsW/UMosgfEci4= X-Received: by 10.31.152.139 with SMTP id a133mr13178195vke.96.1519798105369; Tue, 27 Feb 2018 22:08:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.144.92 with HTTP; Tue, 27 Feb 2018 22:08:24 -0800 (PST) In-Reply-To: <4997BFDE-1B3F-4F17-9742-28F23F082A15@tony.li> References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <9ada5591-2af3-272d-3bc3-031bf35454c3@gmail.com> <6cdc0835-fb4c-133b-77ff-0234cfdd9ef9@fischer-tech.eu> <00eb01d3af1d$7f4e8100$7deb8300$@gmail.com> <6187cb92-5c8f-d08b-dcc2-859652d629d0@gmail.com> <002901d3af20$b966e960$2c34bc20$@eurecom.fr> <002601d3afc4$a10fbb90$e32f32b0$@eurecom.fr> <71309c28-9d7e-d277-a3b0-46d1a3b4042e@gmail.com> <004701d3afd0$63867190$2a9354b0$@eurecom.fr> <461166f2-f3cc-e749-3628-f1d87104200b@gmail.com> <4997BFDE-1B3F-4F17-9742-28F23F082A15@tony.li> From: =?UTF-8?Q?Katrin_Sj=C3=B6berg?= Date: Wed, 28 Feb 2018 07:08:24 +0100 Message-ID: To: Tony Li Cc: Alexandre Petrescu , its , =?UTF-8?Q?Fran=C3=A7ois_Simon?= , =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , John Kenney , "Dr. Hans-Joachim Fischer" , Abdussalam Baryun Content-Type: multipart/alternative; boundary="001a114266b233734e05663f92ac" Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 28 Feb 2018 06:08:29 -0000 --001a114266b233734e05663f92ac Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi All, I have followed the discussion in this thread from a helicopter perspective and I might have missed emails and details but I would like to make a comment regarding transmitting IPv6 over DCF. In Europe, an IEEE 802.11p STA must use EDCA when transmitting data on the 5.9 GHz band (see Clause 4.6 in ETSI EN 302 663, standardizing layer 1 and layer 2 of the OSI model for the 5.9 GHz band). This implies that the current IETF proposal of using IPv6 over DCF would be impossible to use in Europe. If all IPv6 trafffic has to use a common EDCA access category, I would support John's suggestion from an earlier email to fix IPv6 traffic to AC_BK. As J=C3=AAr=C3=B3me pointed out, we use AC_BE for CAMs, and I know t= he US uses AC_BE for some of their safety messages as well. Best regards, Katrin Sj=C3=B6berg 2018-02-27 17:50 GMT+01:00 Tony Li : > > > If someone knows how to generate a QoSData transported IP packet with > linux open source then I am all ears. > > > This is just a Small Matter Of Programming for anyone with a bit of kerne= l > hacking experience and driver sources. > > Tony > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > --001a114266b233734e05663f92ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

I have followed the discussion in this=20 thread from a helicopter perspective and I might have missed emails and=20 details but I would like to make a comment regarding transmitting IPv6=20 over DCF.

In Europe, an IEEE 802.11p STA must use EDCA when= =20 transmitting data on the 5.9 GHz band (see Clause 4.6 in ETSI EN 302=20 663, standardizing layer 1 and layer 2 of the OSI model for the 5.9 GHz=20 band). This implies that the current IETF proposal of using IPv6 over=20 DCF would be impossible to use in Europe.=20

If all IPv6 trafffic has to use a common EDCA access category= , I would support John's suggestion from an earlier email to fix IPv6 t= raffic to AC_BK. As J=C3=AAr=C3=B3me pointed out, we use AC_BE for CAMs, an= d I know the US uses AC_BE for some of their safety messages as well.
<= br>
Best regards,
Katrin Sj=C3=B6berg

=

2018-02-27 17:50 GMT+01:00 Tony Li <tony.li@tony.li>:

> If someone knows how to generate a QoSData transported IP packet with = linux open source then I am all ears.


This is just a Small Matter Of Programming for anyone with a bit of = kernel hacking experience and driver sources.

Tony

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

--001a114266b233734e05663f92ac-- From nobody Tue Feb 27 22:47:23 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B042B12DA26 for ; Tue, 27 Feb 2018 22:47:22 -0800 (PST) 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 H0BczLMY0iaj for ; Tue, 27 Feb 2018 22:47:21 -0800 (PST) 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 A182712DA14 for ; Tue, 27 Feb 2018 22:47:20 -0800 (PST) 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 w1S6lHfn058460; Wed, 28 Feb 2018 07:47:17 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9D632200F54; Wed, 28 Feb 2018 07:47:17 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 8BB16200ED6; Wed, 28 Feb 2018 07:47:17 +0100 (CET) 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 w1S6lHcY008367; Wed, 28 Feb 2018 07:47:17 +0100 To: "Bless, Roland (TM)" , =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , "=?UTF-8?Q?'Fran=c3=a7ois_Simon'?=" , its@ietf.org References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <006301d3ace3$25f9d500$71ed7f00$@eurecom.fr> <007901d3aee3$a9985ba0$fcc912e0$@eurecom.fr> <00f801d3af1d$f20ce4c0$d626ae40$@gmail.com> <002b01d3af21$6e779a70$4b66cf50$@eurecom.fr> From: Alexandre Petrescu Message-ID: Date: Wed, 28 Feb 2018 07:47:17 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.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] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 28 Feb 2018 06:47:23 -0000 Le 27/02/2018 à 17:26, Bless, Roland (TM) a écrit : > Hi Alex, > > see inline. > > Am 26.02.2018 um 18:07 schrieb Alexandre Petrescu: >> Le 26/02/2018 à 17:47, Jérôme Härri a écrit : >>> Hi Alex, All, >>> >>> Made a minor mistake: the 802.1D UP are actually 8 values, 0-7. So 8 >>> bits, and accordingly you can directly map the IPv6 TC to the >>> UP...there is a spec in ETSI for that, but not sure if there is one >>> spec in IETF for that. >> >> At IETF there is a spec that says that the Traffic Class field in the >> IPv6 header contains a DSCP (differentiated service code point) of >> length 6bit and the other 2bits are 'currently' unused. (RFC2474). >> >> As such, I dont think a one-to-one mapping between a 802.1D UP value and >> a DSCP value is possible, unless some compression algorithm is used. > > RFC 8325 provides DSCP-to-UP mapping recommendations, so it's at least a > suggestion for a default mapping. DSCPs can be chosen freely by DiffServ > providers, so a custom DSCP configuration needs also a customized > mapping then... > >> So, I dont think that mapping is as straightforward as one might see it >> at a first sight. >> >>> (did not have time to read Roland's identified RFC yet...maybe it is >>> there...) >> >> I looked at the RFC8325 referred to by Roland.  As the mapping of an >> 8-bit value to a 6-bit value is not straightforward they do agree on a >> number of inconsistencies and potential conflicts. > > It is actually a DSCP 6-bit value to a 3-bit UP value, which is then > mapped to one of the four AC values. > >> That is why I thik RFC8325 could be a good starting point, but there >> should be more. > > Then you should clearly state what is actually missing there... I clearly state that what is missing is implementation. We need this to work: ping -Q to issue 802.11 QoSData (instead of 802.11 Data) at 5.9GHz in OCB mode. We tried to make it work but to no avail: - OCB mode at 5.9GHz works fine with mainline linux kernel, driver ath9k. - ping -Q works fine, it generates the proper DSCP fields in the IP header. - the diffserv DSCP options are checked in the kernel. - there is DSCP in the IP header but there is no 802.11 QoSData header (there is 802.11 Data header). Have you seen RFC8325 working? Alex > > Regards > Roland > From nobody Tue Feb 27 22:56:49 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE3E12DA14 for ; Tue, 27 Feb 2018 22:56:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPhSC3PieMi4 for ; Tue, 27 Feb 2018 22:56:45 -0800 (PST) Received: from smtp2.eurecom.fr (smtp2.eurecom.fr [193.55.113.211]) by ietfa.amsl.com (Postfix) with ESMTP id CEAF412DA40 for ; Tue, 27 Feb 2018 22:56:44 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.47,404,1515452400"; d="scan'208,217";a="7706907" Received: from monza.eurecom.fr ([192.168.106.15]) by drago2i.eurecom.fr with ESMTP; 28 Feb 2018 07:56:43 +0100 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 B74771C9D; Wed, 28 Feb 2018 07:56:43 +0100 (CET) From: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= To: "'Tony Li'" , "'John Kenney'" Cc: "'Alexandre Petrescu'" , "'its'" , =?UTF-8?Q?'Katrin_Sj=C3=B6berg'?= References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <9ada5591-2af3-272d-3bc3-031bf35454c3@gmail.com> <52ADDCC5-5AF1-4657-AE0C-AD9240ED6093@tony.li> In-Reply-To: <52ADDCC5-5AF1-4657-AE0C-AD9240ED6093@tony.li> Date: Wed, 28 Feb 2018 07:56:43 +0100 Organization: EURECOM Message-ID: <004601d3b061$4adadcd0$e0909670$@eurecom.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0047_01D3B069.ACA07D50" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQHelLAw/aN7IRfcwiTBG/gKcgHVEwGONDnFAivYBTcB5QRVgwFu9SHuAcUCuOgBh4H86QFt4Lrjo0VVZnA= Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB - text modifications towards resolution 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, 28 Feb 2018 06:56:48 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0047_01D3B069.ACA07D50 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tony, =20 If you count every bits, then I would seriously argue why do we need the = heavy IPv6 machinery to transmit over OCB, when WSN/Geonet would do it = without (I called heavy machinery the ND, DAD, etc=E2=80=A6).=20 =20 Now, what we get is plain simple: coexistence=E2=80=A6there is nothing = without this. =20 BR, =20 J=C3=A9r=C3=B4me =20 From: its [mailto:its-bounces@ietf.org] On Behalf Of Tony Li Sent: Wednesday 28 February 2018 03:35 To: John Kenney Cc: Alexandre Petrescu; its Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in = IPv6-over-802.11-OCB - text modifications towards resolution =20 =20 I suggest: NEW: > In OCB mode, an IPv6 packet MUST be transmitted as an "IEEE 802.11 = QoS Data" frame. In the QoS Control Field, the TID subfield (Bits 0-3) = MUST be set equal to binary 0001, corresponding to UP =3D 1.=20 Apologies if I don't have the IETF normative syntax right. =20 =20 The normative syntax looks fine to me. As long as you capitalize your = MUSTs and it=E2=80=99s clear, it=E2=80=99s usually just fine. =20 Why is this somehow better than just sending it as data? It=E2=80=99s = worse, in that it=E2=80=99s more bits in the ether. What are we getting = for the cost? =20 Tony =20 =20 ------=_NextPart_000_0047_01D3B069.ACA07D50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Tony,

 

If you count every bits, then I would seriously argue why do we need = the heavy IPv6 machinery to transmit over OCB, when WSN/Geonet would do = it without (I called heavy machinery the ND, DAD, etc=E2=80=A6). =

 

Now, what we get is plain simple: coexistence=E2=80=A6there is = nothing without this.

 

BR,

 

J=C3=A9r=C3=B4me

 

From:= = its [mailto:its-bounces@ietf.org] On Behalf Of Tony = Li
Sent: Wednesday 28 February 2018 03:35
To: John = Kenney
Cc: Alexandre Petrescu; its
Subject: Re: = [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB - text = modifications towards resolution

 

 



I = suggest:

NEW:
>  In OCB mode, an IPv6 packet MUST = be transmitted as an "IEEE 802.11 QoS Data" frame. In the = QoS Control Field, the TID subfield (Bits 0-3) MUST be set equal to = binary 0001, corresponding to UP =3D = 1. 



Apologies = if I don't have the IETF normative syntax = right.

 

 

The = normative syntax looks fine to me. As long as you capitalize your MUSTs = and it=E2=80=99s clear, it=E2=80=99s usually just = fine.

 

Why is this somehow better than just sending it as = data?  It=E2=80=99s worse, in that it=E2=80=99s more bits in the = ether.  What are we getting for the = cost?

 

Tony

 

 

------=_NextPart_000_0047_01D3B069.ACA07D50-- From nobody Tue Feb 27 23:07:51 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0438F12D942 for ; Tue, 27 Feb 2018 23:07:50 -0800 (PST) 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 5_EuYxFqIE2y for ; Tue, 27 Feb 2018 23:07:48 -0800 (PST) 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 E1C3412D7F5 for ; Tue, 27 Feb 2018 23:07:47 -0800 (PST) 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 w1S77ine040865; Wed, 28 Feb 2018 08:07:44 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A97CC201430; Wed, 28 Feb 2018 08:07:44 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 8ED62200808; Wed, 28 Feb 2018 08:07:44 +0100 (CET) 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 w1S77icB029177; Wed, 28 Feb 2018 08:07:44 +0100 To: =?UTF-8?Q?Katrin_Sj=c3=b6berg?= Cc: Tony Li , its , =?UTF-8?Q?Fran=c3=a7ois_Simon?= , =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , John Kenney , "Dr. Hans-Joachim Fischer" , Abdussalam Baryun References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <9ada5591-2af3-272d-3bc3-031bf35454c3@gmail.com> <6cdc0835-fb4c-133b-77ff-0234cfdd9ef9@fischer-tech.eu> <00eb01d3af1d$7f4e8100$7deb8300$@gmail.com> <6187cb92-5c8f-d08b-dcc2-859652d629d0@gmail.com> <002901d3af20$b966e960$2c34bc20$@eurecom.fr> <002601d3afc4$a10fbb90$e32f32b0$@eurecom.fr> <71309c28-9d7e-d277-a3b0-46d1a3b4042e@gmail.com> <004701d3afd0$63867190$2a9354b0$@eurecom.fr> <461166f2-f3cc-e749-3628-f1d87104200b@gmail.com> <4997BFDE-1B3F-4F17-9742-28F23F082A15@tony.li> From: Alexandre Petrescu Message-ID: Date: Wed, 28 Feb 2018 08:07:44 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.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] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 28 Feb 2018 07:07:50 -0000 Thank you for the message. Le 28/02/2018 à 07:08, Katrin Sjöberg a écrit : [...] > This implies that the current IETF proposal of using IPv6 over DCF > would be impossible to use in Europe. Unless, of course, we suggest modify the ETSI specification to allow for 802.11 Data headers as well as 802.11 QoS Data headers. (there are many reasons to ponder over a major rehaul of ETSI ITS specifications, starting at the CAM itself, that I could explain separately). > If all IPv6 trafffic has to use a common EDCA access category, I > would support John's suggestion from an earlier email to fix IPv6 > traffic to AC_BK. This could be done. On my side I would need to see running code for it, and then there is need of consensus (could be obvious from your standpoint). > As Jêróme pointed out, we use AC_BE for CAMs, Thank you for this message. I understand you have an implementation of CAM sent with IEEE 802.11 QoSData header. Is it the one from Unex with Autotalks chipset? (the CAM implementations I use are from github.com and ath9k driver; they dont generate 802.11 QoSData header, but use 802.11 Data header, hence no AC_BE). > and I know the US uses AC_BE for some of their safety messages as > well. I think me too, I have seen BSM messages carried with 802.11 QoSData headers, field Priority value 2 Spare (Background); I guess that stands for AC_BK. But I could not figure out what was the software that implemented it. Alex > > Best regards, Katrin Sjöberg > > > > 2018-02-27 17:50 GMT+01:00 Tony Li >: > > >> If someone knows how to generate a QoSData transported IP packet >> with linux open source then I am all ears. > > > This is just a Small Matter Of Programming for anyone with a bit of > kernel hacking experience and driver sources. > > Tony > > _______________________________________________ its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > > From nobody Tue Feb 27 23:13:26 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE7A120725 for ; Tue, 27 Feb 2018 23:13:24 -0800 (PST) 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 OYSPaeCPCUCo for ; Tue, 27 Feb 2018 23:13:23 -0800 (PST) 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 D66B612D942 for ; Tue, 27 Feb 2018 23:13:22 -0800 (PST) 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 w1S7DK44064814; Wed, 28 Feb 2018 08:13:20 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6F7AE200FAE; Wed, 28 Feb 2018 08:13:20 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 59BFB200B95; Wed, 28 Feb 2018 08:13:20 +0100 (CET) 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 w1S7DKnQ002812; Wed, 28 Feb 2018 08:13:20 +0100 To: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , "'Tony Li'" , "'John Kenney'" Cc: "'its'" , "=?UTF-8?Q?'Katrin_Sj=c3=b6berg'?=" References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <9ada5591-2af3-272d-3bc3-031bf35454c3@gmail.com> <52ADDCC5-5AF1-4657-AE0C-AD9240ED6093@tony.li> <004601d3b061$4adadcd0$e0909670$@eurecom.fr> From: Alexandre Petrescu Message-ID: <78bc7114-a661-9524-e4d8-631910a7c789@gmail.com> Date: Wed, 28 Feb 2018 08:13:20 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <004601d3b061$4adadcd0$e0909670$@eurecom.fr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB - text modifications towards resolution 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, 28 Feb 2018 07:13:24 -0000 Jérôme, Please count the bits. The IPv6 header is 40bytes. How long are the BTP and GeoNetworking headers? I do not understand what do you mean more precisely by 'heavy machinery' and ND and DAD? ND is just a request/reply, and DAD is optional in some cases. Alex Le 28/02/2018 à 07:56, Jérôme Härri a écrit : > Hi Tony, > > If you count every bits, then I would seriously argue why do we need the > heavy IPv6 machinery to transmit over OCB, when WSN/Geonet would do it > without (I called heavy machinery the ND, DAD, etc…). > > Now, what we get is plain simple: coexistence…there is nothing without this. > > BR, > > Jérôme > > *From:*its [mailto:its-bounces@ietf.org] *On Behalf Of *Tony Li > *Sent:* Wednesday 28 February 2018 03:35 > *To:* John Kenney > *Cc:* Alexandre Petrescu; its > *Subject:* Re: [ipwave] 802.11 Data vs 802.11 QoS Data in > IPv6-over-802.11-OCB - text modifications towards resolution > > > > I suggest: > > NEW: >>  In OCB mode, an IPv6 packet MUST be transmitted as an "IEEE 802.11 QoS Data" frame. In the QoS Control Field, the TID subfield (Bits 0-3) MUST be set equal to binary 0001, corresponding to UP = 1. > > > > Apologies if I don't have the IETF normative syntax right. > > The normative syntax looks fine to me. As long as you capitalize your > MUSTs and it’s clear, it’s usually just fine. > > Why is this somehow better than just sending it as data?  It’s worse, in > that it’s more bits in the ether.  What are we getting for the cost? > > Tony > From nobody Tue Feb 27 23:39:19 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD78124207 for ; Tue, 27 Feb 2018 23:39:17 -0800 (PST) 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 nDIaYcV1Ld0P for ; Tue, 27 Feb 2018 23:39:15 -0800 (PST) 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 89A4F120725 for ; Tue, 27 Feb 2018 23:39:15 -0800 (PST) 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 w1S7dDD3071893; Wed, 28 Feb 2018 08:39:13 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8B409200C3D; Wed, 28 Feb 2018 08:39:13 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 7DE0D200C32; Wed, 28 Feb 2018 08:39:13 +0100 (CET) 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 w1S7dDIK031491; Wed, 28 Feb 2018 08:39:13 +0100 To: John Kenney Cc: its References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <9ada5591-2af3-272d-3bc3-031bf35454c3@gmail.com> From: Alexandre Petrescu Message-ID: Date: Wed, 28 Feb 2018 08:39:13 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.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] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB - text modifications towards resolution 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, 28 Feb 2018 07:39:17 -0000 John, Thank you for the message. Obviously, we disagree. If I had access to code that implements what you suggest then I would not hesitate to write that text as you suggest ("MUST QoS Data, Qos Control Field and TID 0001 and UP==1"). Until then, I ponder over removal altogher of the section Ethernet Adaptation Layer from this draft, and move these QoS aspects in another document. Maybe Carlos questioning of this EAL was right in the end. Alex Le 28/02/2018 à 03:29, John Kenney a écrit : > Yes, I disagree. > > I suggest: NEW: >> In OCB mode, an IPv6 packet MUST be transmitted as an "IEEE 802.11 >> QoS Data" frame. In the QoS Control Field, the TID subfield (Bits > 0-3) MUST be set equal to binary 0001, corresponding to UP = 1. > > Apologies if I don't have the IETF normative syntax right. > > Note that UP = 1 maps to AC_BK. > > Best Regards, John > > > On Tue, Feb 27, 2018 at 2:43 AM, Alexandre Petrescu > > > wrote: > > I propose the following modifications towards resolution of this QoS > issue. > > Do you disagree? > > OLD: >> In OCB mode, IPv6 packets MAY be transmitted either as "IEEE > 802.11 >> Data" or alternatively as "IEEE 802.11 QoS Data", as > illustrated in >> Figure 2. > > NEW: >> In OCB mode, it is RECOMMENDED to transmit IPv6 packets as "IEEE >> 802.11 Data" (the value of the field Subtype in the Frame Control >> Field is 0). > > Remove this entire OLD text: > > In OCB mode, IPv6 packets MAY be transmitted either as "IEEE 802.11 > Data" or alternatively as "IEEE 802.11 QoS Data", as illustrated in > Figure 2. > > +--------------------+-------------+-------------+---------+-----------+ > > | 802.11 Data Header | LLC Header | IPv6 Header | Payload |.11 > Trailer| > +--------------------+-------------+-------------+---------+-----------+ > > or > > +--------------------+-------------+-------------+---------+-----------+ > > | 802.11 QoS Data Hdr| LLC Header | IPv6 Header | Payload |.11 > Trailer| > +--------------------+-------------+-------------+---------+-----------+ > > Figure 2: 802.11 Data Header or 802.11 QoS Data Header > > 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 > [I-D.ietf-tsvwg-ieee-802-11], although it is not specific to OCB > mode. > > > Alex > > > Le 25/02/2018 à 18:58, Alexandre Petrescu a écrit : > > I propose the following text. > > OLD: > > In OCB mode, IPv6 packets MAY be transmitted either as "IEEE 802.11 > Data" or alternatively as "IEEE 802.11 QoS Data", as illustrated in > Figure 2. > > > NEW: > > In OCB mode, it is RECOMMENDED to transmit IPv6 packets as "IEEE > 802.11 Data" (the value of the field Subtype in the Frame Control > Field is 0). > > > Alex > > > _______________________________________________ its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > > > > > -- John Kenney Director and Principal Researcher Toyota > InfoTechnology Center, USA 465 Bernardo Avenue Mountain View, CA > 94043 Tel: 650-694-4160. Mobile: 650-224-6644 From nobody Tue Feb 27 23:53:57 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE6612D7EF for ; Tue, 27 Feb 2018 23:53:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHiQDFRB9wHM for ; Tue, 27 Feb 2018 23:53:55 -0800 (PST) Received: from smtp2.eurecom.fr (smtp2.eurecom.fr [193.55.113.211]) by ietfa.amsl.com (Postfix) with ESMTP id B0FB5124207 for ; Tue, 27 Feb 2018 23:53:54 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.47,404,1515452400"; d="scan'208";a="7707060" Received: from monza.eurecom.fr ([192.168.106.15]) by drago2i.eurecom.fr with ESMTP; 28 Feb 2018 08:53:53 +0100 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 BA5AD2080; Wed, 28 Feb 2018 08:53:53 +0100 (CET) From: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= To: "'Alexandre Petrescu'" , "'Tony Li'" , "'John Kenney'" Cc: "'its'" , =?UTF-8?Q?'Katrin_Sj=C3=B6berg'?= References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <9ada5591-2af3-272d-3bc3-031bf35454c3@gmail.com> <52ADDCC5-5AF1-4657-AE0C-AD9240ED6093@tony.li> <004601d3b061$4adadcd0$e0909670$@eurecom.fr> <78bc7114-a661-9524-e4d8-631910a7c789@gmail.com> In-Reply-To: <78bc7114-a661-9524-e4d8-631910a7c789@gmail.com> Date: Wed, 28 Feb 2018 08:53:53 +0100 Organization: EURECOM Message-ID: <007901d3b069$47453950$d5cfabf0$@eurecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQHelLAw/aN7IRfcwiTBG/gKcgHVEwGONDnFAivYBTcB5QRVgwFu9SHuAcUCuOgBh4H86QFt4LrjAn2u9AYCta3nBqMbwdvQ Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB - text modifications towards resolution 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, 28 Feb 2018 07:53:56 -0000 Hi Alex, Sure, it is indeed 'just a request/reply', but these are bits as well = and counts in the total IPv6' overhead. Btw, if you add BTP, then you = need to add UDPv6/TCPv6 headers for IPv6 (ok, UDP to remain fair) as = well, so 8 bytes..=20 Now, BTP is 4 bytes only (so we already save half from UDP), then Geonet = common header is 35bytes, which is more or less all if you use Geonet = for SHB...now of course, you need to add security trailers, which will = be there for IPv6 as well... And if you use geonet with geobroadcast, indeed the header is indeed = increased by an extra 48 bytes...but you will need this on top of IP as = well if you need to do multi-hop routing anyways...so, when comparing = geonet with pure IPv6, we should define it on a similar task: 1-hop = broadcast (no routing)..if you need to do routing, in particular geonet = routing, then things get messy in both cases (let's look at MANET = headers then...). =20 For ETSI, beside the 'indeed' unfortunate double position in geonet and = CAM, there is no extra overhead, no need for request/reply, no need for = DAD under any circumstance....We get our address directly and the = neighbors are obtained through the Geonet header of CAM/DENN (CAM = compulsory at 2Hz minimum in EU, so largely enough for NET routing)... I yet already mentioned that indeed, using IPv6 over Geonet then creates = overhead (kind of double), as you still have the IPv6 machinery and you = encapsulate IPv6 in geonet (so, triple header)...that is my initial = reason for working on IPWAVE...so, for use cases clearly requiring IPv6, = it could be worth going directly with OCB rather than Geonet...but my = assumption here is that what I need to transmit cannot be transmitted = efficiently with pure Geonet/WAVE... BR, J=C3=A9r=C3=B4me -----Original Message----- From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com]=20 Sent: Wednesday 28 February 2018 08:13 To: J=C3=A9r=C3=B4me H=C3=A4rri; 'Tony Li'; 'John Kenney' Cc: 'its'; 'Katrin Sj=C3=B6berg' Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in = IPv6-over-802.11-OCB - text modifications towards resolution J=C3=A9r=C3=B4me, Please count the bits. The IPv6 header is 40bytes. How long are the BTP and GeoNetworking headers? I do not understand what do you mean more precisely by 'heavy machinery' = and ND and DAD? ND is just a request/reply, and DAD is optional in some = cases. Alex Le 28/02/2018 =C3=A0 07:56, J=C3=A9r=C3=B4me H=C3=A4rri a =C3=A9crit : > Hi Tony, >=20 > If you count every bits, then I would seriously argue why do we need=20 > the heavy IPv6 machinery to transmit over OCB, when WSN/Geonet would=20 > do it without (I called heavy machinery the ND, DAD, etc=E2=80=A6). >=20 > Now, what we get is plain simple: coexistence=E2=80=A6there is nothing = without this. >=20 > BR, >=20 > J=C3=A9r=C3=B4me >=20 > *From:*its [mailto:its-bounces@ietf.org] *On Behalf Of *Tony Li > *Sent:* Wednesday 28 February 2018 03:35 > *To:* John Kenney > *Cc:* Alexandre Petrescu; its > *Subject:* Re: [ipwave] 802.11 Data vs 802.11 QoS Data in=20 > IPv6-over-802.11-OCB - text modifications towards resolution >=20 >=20 >=20 > I suggest: >=20 > NEW: >> In OCB mode, an IPv6 packet MUST be transmitted as an "IEEE 802.11 = QoS Data" frame. In the QoS Control Field, the TID subfield (Bits 0-3) = MUST be set equal to binary 0001, corresponding to UP =3D 1.=20 >=20 >=20 >=20 > Apologies if I don't have the IETF normative syntax right. >=20 > The normative syntax looks fine to me. As long as you capitalize your=20 > MUSTs and it=E2=80=99s clear, it=E2=80=99s usually just fine. >=20 > Why is this somehow better than just sending it as data? It=E2=80=99s = worse,=20 > in that it=E2=80=99s more bits in the ether. What are we getting for = the cost? >=20 > Tony >=20 From nobody Wed Feb 28 00:19:30 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0DD1271FD for ; Wed, 28 Feb 2018 00:19:29 -0800 (PST) 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 zdkiBB1ZRJI0 for ; Wed, 28 Feb 2018 00:19:27 -0800 (PST) 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 8F6AB1270A0 for ; Wed, 28 Feb 2018 00:19:27 -0800 (PST) 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 w1S8JPBI014125; Wed, 28 Feb 2018 09:19:25 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 188C0201C5B; Wed, 28 Feb 2018 09:19:25 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 037B9200808; Wed, 28 Feb 2018 09:19:25 +0100 (CET) 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 w1S8JOBf021857; Wed, 28 Feb 2018 09:19:24 +0100 To: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , "'Tony Li'" , "'John Kenney'" Cc: "'its'" , "=?UTF-8?Q?'Katrin_Sj=c3=b6berg'?=" References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <9ada5591-2af3-272d-3bc3-031bf35454c3@gmail.com> <52ADDCC5-5AF1-4657-AE0C-AD9240ED6093@tony.li> <004601d3b061$4adadcd0$e0909670$@eurecom.fr> <78bc7114-a661-9524-e4d8-631910a7c789@gmail.com> <007901d3b069$47453950$d5cfabf0$@eurecom.fr> From: Alexandre Petrescu Message-ID: <7ffac3d6-db35-0538-94f3-743439bf7caa@gmail.com> Date: Wed, 28 Feb 2018 09:19:24 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <007901d3b069$47453950$d5cfabf0$@eurecom.fr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB - costs 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, 28 Feb 2018 08:19:29 -0000 Le 28/02/2018 à 08:53, Jérôme Härri a écrit : > Hi Alex, > > Sure, it is indeed 'just a request/reply', but these are bits as well > and counts in the total IPv6' overhead. Btw, if you add BTP, then you > need to add UDPv6/TCPv6 headers for IPv6 (ok, UDP to remain fair) as > well, so 8 bytes.. > > Now, BTP is 4 bytes only (so we already save half from UDP), then > Geonet common header is 35bytes, Ah, so 39 bytes of Geonet-plus-BTP is smaller than 40 bytes of IPv6 header. > which is more or less all if you use Geonet for SHB...now of course, > you need to add security trailers, which will be there for IPv6 as > well... > > And if you use geonet with geobroadcast, indeed the header is indeed > increased by an extra 48 bytes...but you will need this on top of IP > as well if you need to do multi-hop routing anyways...so, when > comparing geonet with pure IPv6, we should define it on a similar > task: 1-hop broadcast (no routing)..if you need to do routing, in > particular geonet routing, then things get messy in both cases (let's > look at MANET headers then...). > > For ETSI, beside the 'indeed' unfortunate double position in geonet > and CAM, there is no extra overhead, no need for request/reply, no > need for DAD under any circumstance.... (IPv6 can also work that way: send the CAM as IPv6 payload, as multicast. There is no need of ND nor DAD for that to work.) > We get our address directly > and the neighbors are obtained through the Geonet header of CAM/DENN > (CAM compulsory at 2Hz minimum in EU, so largely enough for NET > routing)... > > I yet already mentioned that indeed, using IPv6 over Geonet then > creates overhead (kind of double), as you still have the IPv6 > machinery and you encapsulate IPv6 in geonet (so, triple > header)...that is my initial reason for working on IPWAVE...so, for > use cases clearly requiring IPv6, it could be worth going directly > with OCB rather than Geonet...but my assumption here is that what I > need to transmit cannot be transmitted efficiently with pure > Geonet/WAVE... I agree. Let me go back to the cost comparison request of Tony. An 802.11 QoS Data Header is longer than a 802.11 Data Header by two bytes. This 2-byte 'QoS Control' field is only present in the QoS Data header, but absent from the Data header. Is its presence worth? Alex > > BR, > > Jérôme > > > -----Original Message----- From: Alexandre Petrescu > [mailto:alexandre.petrescu@gmail.com] Sent: Wednesday 28 February > 2018 08:13 To: Jérôme Härri; 'Tony Li'; 'John Kenney' Cc: 'its'; > 'Katrin Sjöberg' Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data > in IPv6-over-802.11-OCB - text modifications towards resolution > > Jérôme, > > Please count the bits. > > The IPv6 header is 40bytes. > > How long are the BTP and GeoNetworking headers? > > I do not understand what do you mean more precisely by 'heavy > machinery' and ND and DAD? ND is just a request/reply, and DAD is > optional in some cases. > > Alex > > Le 28/02/2018 à 07:56, Jérôme Härri a écrit : >> Hi Tony, >> >> If you count every bits, then I would seriously argue why do we >> need the heavy IPv6 machinery to transmit over OCB, when WSN/Geonet >> would do it without (I called heavy machinery the ND, DAD, etc…). >> >> Now, what we get is plain simple: coexistence…there is nothing >> without this. >> >> BR, >> >> Jérôme >> >> *From:*its [mailto:its-bounces@ietf.org] *On Behalf Of *Tony Li >> *Sent:* Wednesday 28 February 2018 03:35 *To:* John Kenney *Cc:* >> Alexandre Petrescu; its *Subject:* Re: [ipwave] 802.11 Data vs >> 802.11 QoS Data in IPv6-over-802.11-OCB - text modifications >> towards resolution >> >> >> >> I suggest: >> >> NEW: >>> In OCB mode, an IPv6 packet MUST be transmitted as an "IEEE >>> 802.11 QoS Data" frame. In the QoS Control Field, the TID >>> subfield (Bits 0-3) MUST be set equal to binary 0001, >>> corresponding to UP = 1. >> >> >> >> Apologies if I don't have the IETF normative syntax right. >> >> The normative syntax looks fine to me. As long as you capitalize >> your MUSTs and it’s clear, it’s usually just fine. >> >> Why is this somehow better than just sending it as data? It’s >> worse, in that it’s more bits in the ether. What are we getting >> for the cost? >> >> Tony >> > > From nobody Wed Feb 28 00:43:02 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA5991243F6 for ; Wed, 28 Feb 2018 00:43:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKp1lfOzxMpB for ; Wed, 28 Feb 2018 00:42:58 -0800 (PST) Received: from smtp2.eurecom.fr (smtp2.eurecom.fr [193.55.113.211]) by ietfa.amsl.com (Postfix) with ESMTP id 629B41243F3 for ; Wed, 28 Feb 2018 00:42:58 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.47,404,1515452400"; d="scan'208";a="7707282" Received: from monza.eurecom.fr ([192.168.106.15]) by drago2i.eurecom.fr with ESMTP; 28 Feb 2018 09:42:57 +0100 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 5F8F624A0; Wed, 28 Feb 2018 09:42:57 +0100 (CET) From: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= To: "'Alexandre Petrescu'" , "'Tony Li'" , "'John Kenney'" Cc: "'its'" , =?UTF-8?Q?'Katrin_Sj=C3=B6berg'?= References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <9ada5591-2af3-272d-3bc3-031bf35454c3@gmail.com> <52ADDCC5-5AF1-4657-AE0C-AD9240ED6093@tony.li> <004601d3b061$4adadcd0$e0909670$@eurecom.fr> <78bc7114-a661-9524-e4d8-631910a7c789@gmail.com> <007901d3b069$47453950$d5cfabf0$@eurecom.fr> <7ffac3d6-db35-0538-94f3-743439bf7caa@gmail.com> In-Reply-To: <7ffac3d6-db35-0538-94f3-743439bf7caa@gmail.com> Date: Wed, 28 Feb 2018 09:42:57 +0100 Organization: EURECOM Message-ID: <00df01d3b070$21cf3610$656da230$@eurecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQHelLAw/aN7IRfcwiTBG/gKcgHVEwGONDnFAivYBTcB5QRVgwFu9SHuAcUCuOgBh4H86QFt4LrjAn2u9AYCta3nBgHkHtpTAXAyS6ujATWoAA== Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB - costs 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, 28 Feb 2018 08:43:01 -0000 Hi Alex, >I agree. > >Let me go back to the cost comparison request of Tony. > >An 802.11 QoS Data Header is longer than a 802.11 Data Header by two = bytes. This 2-byte 'QoS Control' field is only present in the QoS Data = header, but absent from the Data header. Is its presence worth? >From my perspective, it does...two bytes is not much if it avoids issues = with other technologies...let's call it coexistence cost :-)=20 BR, J=C3=A9r=C3=B4me >=20 > BR, >=20 > J=C3=A9r=C3=B4me >=20 >=20 > -----Original Message----- From: Alexandre Petrescu=20 > [mailto:alexandre.petrescu@gmail.com] Sent: Wednesday 28 February > 2018 08:13 To: J=C3=A9r=C3=B4me H=C3=A4rri; 'Tony Li'; 'John Kenney' = Cc: 'its';=20 > 'Katrin Sj=C3=B6berg' Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS = Data=20 > in IPv6-over-802.11-OCB - text modifications towards resolution >=20 > J=C3=A9r=C3=B4me, >=20 > Please count the bits. >=20 > The IPv6 header is 40bytes. >=20 > How long are the BTP and GeoNetworking headers? >=20 > I do not understand what do you mean more precisely by 'heavy=20 > machinery' and ND and DAD? ND is just a request/reply, and DAD is=20 > optional in some cases. >=20 > Alex >=20 > Le 28/02/2018 =C3=A0 07:56, J=C3=A9r=C3=B4me H=C3=A4rri a =C3=A9crit : >> Hi Tony, >>=20 >> If you count every bits, then I would seriously argue why do we need=20 >> the heavy IPv6 machinery to transmit over OCB, when WSN/Geonet would=20 >> do it without (I called heavy machinery the ND, DAD, etc=E2=80=A6). >>=20 >> Now, what we get is plain simple: coexistence=E2=80=A6there is = nothing=20 >> without this. >>=20 >> BR, >>=20 >> J=C3=A9r=C3=B4me >>=20 >> *From:*its [mailto:its-bounces@ietf.org] *On Behalf Of *Tony Li >> *Sent:* Wednesday 28 February 2018 03:35 *To:* John Kenney *Cc:*=20 >> Alexandre Petrescu; its *Subject:* Re: [ipwave] 802.11 Data vs >> 802.11 QoS Data in IPv6-over-802.11-OCB - text modifications towards=20 >> resolution >>=20 >>=20 >>=20 >> I suggest: >>=20 >> NEW: >>> In OCB mode, an IPv6 packet MUST be transmitted as an "IEEE >>> 802.11 QoS Data" frame. In the QoS Control Field, the TID subfield=20 >>> (Bits 0-3) MUST be set equal to binary 0001, corresponding to UP =3D = >>> 1. >>=20 >>=20 >>=20 >> Apologies if I don't have the IETF normative syntax right. >>=20 >> The normative syntax looks fine to me. As long as you capitalize your = >> MUSTs and it=E2=80=99s clear, it=E2=80=99s usually just fine. >>=20 >> Why is this somehow better than just sending it as data? = It=E2=80=99s worse,=20 >> in that it=E2=80=99s more bits in the ether. What are we getting for = the=20 >> cost? >>=20 >> Tony >>=20 >=20 >=20 From nobody Wed Feb 28 00:58:36 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6335012711D for ; Wed, 28 Feb 2018 00:58:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9O8MlvLZTUM for ; Wed, 28 Feb 2018 00:58:33 -0800 (PST) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::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 3F66812DFDB for ; Wed, 28 Feb 2018 00:58:01 -0800 (PST) Received: by mail-yw0-x22e.google.com with SMTP id p70so552116ywg.10 for ; Wed, 28 Feb 2018 00:58:01 -0800 (PST) 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=bGyzOw9oAUW85O/8mj2Y3/d0jI6OL6Y+/01dhYghv/8=; b=WIasFOcHgx5nakU5MFWsnaGBgk6zeA3x7KH29/G37/hrs27sHibp0J9GXu2Rb4IsEY g1BL3RqfgO9Av9+uIK9BJrzTouyLRiQk5oCM6H5DuMaGNLA06+5tjae2lXQxWbn0bRAU WvWqTKwV3WiyW/V/EpOuiQJaNoyjipiK0waKjXDAq4FWrWVpycCxlTWtUNYXcaYMTwK6 pMLjtxD4zTUM5RncYIVaRH+mVqw0DBk0UKfHUAGpJFBdALINw/emEzB/2taSmINsNKTd sNxRNJuO2g+oEZhKgInLdznrt4k2sZKn+ugKWGcclnltqFfFjOfa8Hv2fepNxUeobTZg bhrg== 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=bGyzOw9oAUW85O/8mj2Y3/d0jI6OL6Y+/01dhYghv/8=; b=WNeorJAtD6Jtk9t4G5sPo51kLNFGumG8WgfLNm+eb6Fw4X82WF9S66sF91Us1tqceV 8wDgtTHjowCm/uMPJ6c417vy/M0yMpdeqP4p8phTWFP4Njg8/MdSNZxviBN2Jk3nVwmE Hp05/DyFQb65zhNiky+RCGnl83UPPenAP6lhXCTdjnSlAT6MFOkP5QviuDa9fGVVzbSl wKvcwf8oB2kFig/3r4FLHzAo+9Ic1Qc5BQcubwThYyzBU4H/4DJcePygm6DpdGDQnXGG QGp7LzJL61aDtmSMnNdxazB74Qh+qbCVENLVPFFHAVDv5sUwj2eA6MCzPWnzUCB6JZWa bM0w== X-Gm-Message-State: APf1xPBWEu4jWTz1OHe7+O4HczycCQqx9zlFQfuAxGvSS0yHzxkxUqeu XsFm8upmQhEayISBiP4IoBBaUIhrk/IpqCwUPts= X-Google-Smtp-Source: AH8x224HVnItdMPk0xZZcnrvFq7MZGZpegN4iP7skGJqyfMnPGLwjcoY96ELw0NMSOTiXSDfuV43TreYJC9rTuNLZeE= X-Received: by 10.129.40.196 with SMTP id o187mr11714521ywo.497.1519808280555; Wed, 28 Feb 2018 00:58:00 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a25:b942:0:0:0:0:0 with HTTP; Wed, 28 Feb 2018 00:58:00 -0800 (PST) In-Reply-To: References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <9ada5591-2af3-272d-3bc3-031bf35454c3@gmail.com> <6cdc0835-fb4c-133b-77ff-0234cfdd9ef9@fischer-tech.eu> <00eb01d3af1d$7f4e8100$7deb8300$@gmail.com> <6187cb92-5c8f-d08b-dcc2-859652d629d0@gmail.com> <002901d3af20$b966e960$2c34bc20$@eurecom.fr> <002601d3afc4$a10fbb90$e32f32b0$@eurecom.fr> <71309c28-9d7e-d277-a3b0-46d1a3b4042e@gmail.com> <004701d3afd0$63867190$2a9354b0$@eurecom.fr> <461166f2-f3cc-e749-3628-f1d87104200b@gmail.com> <4997BFDE-1B3F-4F17-9742-28F23F082A15@tony.li> From: Michelle Wetterwald Date: Wed, 28 Feb 2018 09:58:00 +0100 Message-ID: To: Alexandre Petrescu Cc: =?UTF-8?Q?Katrin_Sj=C3=B6berg?= , its , =?UTF-8?Q?Fran=C3=A7ois_Simon?= , =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , John Kenney , "Dr. Hans-Joachim Fischer" , Tony Li , Abdussalam Baryun Content-Type: multipart/alternative; boundary="001a11408bc0b075f6056641f023" Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 28 Feb 2018 08:58:35 -0000 --001a11408bc0b075f6056641f023 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alex, I fully agree with Katrin and was about to send a similar post, as the EDCA queues are used also by ITS-G5 for the DCC, which is mandated by the new EU regulation. Unless you want to rewrite all ETSI standards and related European norms in a couple of weeks, I would suggest to keep the old text and guarantee openness for using the IEEE 802.16-16 standard while complying to local regulations. I would also suggest to bring this topic, as well as the handling of QoS for IPWAVE, which is an interesting topic, to the re-chartering discussion that was proposed by Carlos-Jesus a few weeks ago. The same as we did for ND or this nice multicast address that would be reserved for IPWAVE services. BTW, you really plan to send CAMs directly over IPv6, without any transport layer? I thought you would use UDP, which has a "large" header as well. (found in an "old" post dated back from 4 days ago. ) : >> CAM transported in IP may be a smaller packet than CAM transported in BTP and GeoNetworking. Michelle 2018-02-28 8:07 GMT+01:00 Alexandre Petrescu = : > Thank you for the message. > > Le 28/02/2018 =C3=A0 07:08, Katrin Sj=C3=B6berg a =C3=A9crit : > [...] > >> This implies that the current IETF proposal of using IPv6 over DCF would >> be impossible to use in Europe. >> > > Unless, of course, we suggest modify the ETSI specification to allow for > 802.11 Data headers as well as 802.11 QoS Data headers. > > (there are many reasons to ponder over a major rehaul of ETSI ITS > specifications, starting at the CAM itself, that I could explain > separately). > > If all IPv6 trafffic has to use a common EDCA access category, I would >> support John's suggestion from an earlier email to fix IPv6 traffic to >> AC_BK. >> > > This could be done. On my side I would need to see running code for it, > and then there is need of consensus (could be obvious from your > standpoint). > > As J=C3=AAr=C3=B3me pointed out, we use AC_BE for CAMs, >> > > Thank you for this message. I understand you have an implementation of > CAM sent with IEEE 802.11 QoSData header. Is it the one from Unex with > Autotalks chipset? > > (the CAM implementations I use are from github.com and ath9k driver; > they dont generate 802.11 QoSData header, but use 802.11 Data header, > hence no AC_BE). > > and I know the US uses AC_BE for some of their safety messages as >> well. >> > > I think me too, I have seen BSM messages carried with 802.11 QoSData > headers, field Priority value 2 Spare (Background); I guess that stands > for AC_BK. But I could not figure out what was the software that > implemented it. > > Alex > > >> Best regards, Katrin Sj=C3=B6berg >> >> >> >> 2018-02-27 17:50 GMT+01:00 Tony Li > tony.li@tony.li>>: >> >> >> If someone knows how to generate a QoSData transported IP packet with >>> linux open source then I am all ears. >>> >> >> >> This is just a Small Matter Of Programming for anyone with a bit of >> kernel hacking experience and driver sources. >> >> Tony >> >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/l >> istinfo/its >> >> >> > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > --=20 Michelle Wetterwald michelle.wetterwald@gmail.com --001a11408bc0b075f6056641f023 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Alex,

I fully agree with Katrin and was about = to send a similar post, as the EDCA queues are used also by ITS-G5 for the = DCC, which is mandated by the new EU regulation.

Unless you want to r= ewrite all ETSI standards and related European norms in a couple of=C2=A0 w= eeks, I would suggest to keep the old text and guarantee openness for using= the IEEE 802.16-16 standard while complying to local regulations.

I= would also suggest to bring this topic, as well as the handling of QoS for= IPWAVE, which is an interesting topic, to the re-chartering discussion tha= t was proposed by Carlos-Jesus a few weeks ago. The same as we did for ND o= r this nice multicast address that would be reserved for IPWAVE services.

BTW, you really plan to send CAMs directly over IPv6, without any tran= sport layer? I thought you would use UDP, which has a "large" hea= der as well.

=C2=A0(found in an "old" post dated back fro= m 4 days ago. ) :
>> CAM transported in IP may be a smalle= r packet than CAM transported in=20 BTP and GeoNetworking.

Michelle

2018-02-28 8:07 GMT+01:00 Alex= andre Petrescu <alexandre.petrescu@gmail.com>:
Thank you for the message.

Le 28/02/2018 =C3=A0 07:08, Katrin Sj=C3=B6berg a =C3=A9crit :
[...]
This implies that the current IETF proposal of using IPv6 over DCF would be= impossible to use in Europe.

 Unless, of course, we suggest modify the ETSI specification to allow for 802.11 Data headers as well as 802.11 QoS Data headers.

(there are many reasons to ponder over a major rehaul of ETSI ITS
specifications, starting at the CAM itself, that I could explain
separately).

If all IPv6 trafffic has to use a common EDCA access category, I would supp= ort John's suggestion from an earlier email to fix IPv6 traffic to AC_B= K.

 This could be done.=C2=A0 On my side I would need to see running code for i= t,
and then there is need of consensus (could be obvious from your standpoint)= .

As J=C3=AAr=C3=B3me pointed out, we use AC_BE for CAMs,

 Thank you for this message.=C2=A0 I understand you have an implementation o= f
CAM sent with IEEE 802.11 QoSData header.=C2=A0 Is it the one from Unex wit= h
Autotalks chipset?

(the CAM implementations I use are from github.com and ath9k driver;
they dont generate 802.11 QoSData header, but use 802.11 Data header,
hence no AC_BE).

and I know the US uses AC_BE for some of their safety messages as
well.

 I think me too, I have seen BSM messages carried with 802.11 QoSData
headers, field Priority value 2 Spare (Background); I guess that stands
for AC_BK.=C2=A0 But I could not figure out what was the software that
implemented it.

Alex


Best regards, Katrin Sj=C3=B6berg



2018-02-27 17:50 GMT+01:00 Tony Li <tony.li@tony.li <mailto:tony.li@tony.li>>:


If someone knows how to generate a QoSData transported IP packet with linux= open source then I am all ears.


This is just a Small Matter Of Programming for anyone with a bit of kernel = hacking experience and driver sources.

Tony

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



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



--
Michelle Wetterwald
michelle.w= etterwald@gmail.com
--001a11408bc0b075f6056641f023-- From nobody Wed Feb 28 01:03:26 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22D5112DA50 for ; Wed, 28 Feb 2018 01:03:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4qMM3WQ70h0 for ; Wed, 28 Feb 2018 01:03:17 -0800 (PST) Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002: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 A0C2E12DA49 for ; Wed, 28 Feb 2018 01:02:28 -0800 (PST) Received: by mail-yb0-x231.google.com with SMTP id e135-v6so586790ybb.3 for ; Wed, 28 Feb 2018 01:02:28 -0800 (PST) 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=yRlGbkHqBA0K+cobwTs6djxSkVeuuggh/zzdbvVfqhc=; b=sDqGOP+qmwkVC015CcAvfHnixPQJ5mn/8TCGv87/Sx04e2tk8cZrdPtg9jjT7FgCfz wbTEI/OcX+lQiK4rJZVVdChu+3D3sDEowfsfyARYBEW9UJyjU0Xc5TWKSU2TYdDByGCb kU67GWVkzh843yfc4DmuQoVx4hZMDbWwEoF5pp4XE5HHyqcEkmBFjUUBg7DyvCvIvNiE WhCtGrTxYp9jd2NFZr9vxXM4+WKXn4b6LFdU4pl3u0fAxUgIlDbDVl3jsDqbO+SBj23v QYxvV+G277VBNNozv5lrg2x2nKYqe6PkxACKqDdqjRGEZC2qh/M/UQnpyrXenqVsNFoO Fw2g== 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=yRlGbkHqBA0K+cobwTs6djxSkVeuuggh/zzdbvVfqhc=; b=cQ7q08kCxOGykOJeiP/YqwqFfCmi32Bz7KDOoIewdeuWtpw4kKSTE2C4H16TT7ugpO aFFjroLBQWyYmhAHrrMUrE3KkxLBFNHM8ui5fJbuyhP+yVPQMzlvu1Hn5LzFu3tnzbaY P/Ik8c4QRNL01zKBEuWZ+be+mKBimCqyMefoJrcPfACJ8dX0gEtrt5xxnJCs6GAZqg8w Q/w7/mlTXqdXyEkdym2YA2okclmPa54rtaocAo7ZaUcNAsbHjezqlGXtKneRuhsLjVMA 3AGl3K8Jcr3eK22J2HykHofF4vA0YPRwNzxIQIjIGjcI4NtTpff1yJnfB0wFUuVUKHCl 5cVw== X-Gm-Message-State: APf1xPBgEAqTnYMHlp8fY5rOj2/URL5bCbU3g1gH9/V3i6FfU/3Fp75p sHSCpQ34yakuPzoixcqGzB3nmcZ+lQv86NFNcyo= X-Google-Smtp-Source: AG47ELufTr6PcjYHx+62rTDBfTQ+/KbNo1HLgP08p+qC7D7noPF+MAeILQUppL/SvPB2IF6HFV3Labr0WCaWo/Vp3tA= X-Received: by 2002:a25:a082:: with SMTP id y2-v6mr11949570ybh.240.1519808547850; Wed, 28 Feb 2018 01:02:27 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a25:b942:0:0:0:0:0 with HTTP; Wed, 28 Feb 2018 01:02:27 -0800 (PST) In-Reply-To: References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <9ada5591-2af3-272d-3bc3-031bf35454c3@gmail.com> <6cdc0835-fb4c-133b-77ff-0234cfdd9ef9@fischer-tech.eu> <00eb01d3af1d$7f4e8100$7deb8300$@gmail.com> <6187cb92-5c8f-d08b-dcc2-859652d629d0@gmail.com> <002901d3af20$b966e960$2c34bc20$@eurecom.fr> <002601d3afc4$a10fbb90$e32f32b0$@eurecom.fr> <71309c28-9d7e-d277-a3b0-46d1a3b4042e@gmail.com> <004701d3afd0$63867190$2a9354b0$@eurecom.fr> <461166f2-f3cc-e749-3628-f1d87104200b@gmail.com> <4997BFDE-1B3F-4F17-9742-28F23F082A15@tony.li> From: Michelle Wetterwald Date: Wed, 28 Feb 2018 10:02:27 +0100 Message-ID: To: Alexandre Petrescu Cc: =?UTF-8?Q?Katrin_Sj=C3=B6berg?= , its , =?UTF-8?Q?Fran=C3=A7ois_Simon?= , =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , John Kenney , "Dr. Hans-Joachim Fischer" , Tony Li , Abdussalam Baryun Content-Type: multipart/alternative; boundary="0000000000009f0dca05664200be" Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 28 Feb 2018 09:03:24 -0000 --0000000000009f0dca05664200be Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I meant IEEE 802.11-2016, of course... 2018-02-28 9:58 GMT+01:00 Michelle Wetterwald : > Hi Alex, > > I fully agree with Katrin and was about to send a similar post, as the > EDCA queues are used also by ITS-G5 for the DCC, which is mandated by the > new EU regulation. > > Unless you want to rewrite all ETSI standards and related European norms > in a couple of weeks, I would suggest to keep the old text and guarantee > openness for using the IEEE 802.16-16 standard while complying to local > regulations. > > I would also suggest to bring this topic, as well as the handling of QoS > for IPWAVE, which is an interesting topic, to the re-chartering discussio= n > that was proposed by Carlos-Jesus a few weeks ago. The same as we did for > ND or this nice multicast address that would be reserved for IPWAVE > services. > > BTW, you really plan to send CAMs directly over IPv6, without any > transport layer? I thought you would use UDP, which has a "large" header = as > well. > (found in an "old" post dated back from 4 days ago. ) : > >> CAM transported in IP may be a smaller packet than CAM transported in > BTP and GeoNetworking. > > Michelle > > 2018-02-28 8:07 GMT+01:00 Alexandre Petrescu >: > >> Thank you for the message. >> >> Le 28/02/2018 =C3=A0 07:08, Katrin Sj=C3=B6berg a =C3=A9crit : >> [...] >> >>> This implies that the current IETF proposal of using IPv6 over DCF woul= d >>> be impossible to use in Europe. >>> >> >> Unless, of course, we suggest modify the ETSI specification to allow for >> 802.11 Data headers as well as 802.11 QoS Data headers. >> >> (there are many reasons to ponder over a major rehaul of ETSI ITS >> specifications, starting at the CAM itself, that I could explain >> separately). >> >> If all IPv6 trafffic has to use a common EDCA access category, I would >>> support John's suggestion from an earlier email to fix IPv6 traffic to >>> AC_BK. >>> >> >> This could be done. On my side I would need to see running code for it, >> and then there is need of consensus (could be obvious from your >> standpoint). >> >> As J=C3=AAr=C3=B3me pointed out, we use AC_BE for CAMs, >>> >> >> Thank you for this message. I understand you have an implementation of >> CAM sent with IEEE 802.11 QoSData header. Is it the one from Unex with >> Autotalks chipset? >> >> (the CAM implementations I use are from github.com and ath9k driver; >> they dont generate 802.11 QoSData header, but use 802.11 Data header, >> hence no AC_BE). >> >> and I know the US uses AC_BE for some of their safety messages as >>> well. >>> >> >> I think me too, I have seen BSM messages carried with 802.11 QoSData >> headers, field Priority value 2 Spare (Background); I guess that stands >> for AC_BK. But I could not figure out what was the software that >> implemented it. >> >> Alex >> >> >>> Best regards, Katrin Sj=C3=B6berg >>> >>> >>> >>> 2018-02-27 17:50 GMT+01:00 Tony Li >> tony.li@tony.li>>: >>> >>> >>> If someone knows how to generate a QoSData transported IP packet with >>>> linux open source then I am all ears. >>>> >>> >>> >>> This is just a Small Matter Of Programming for anyone with a bit of >>> kernel hacking experience and driver sources. >>> >>> Tony >>> >>> _______________________________________________ its mailing list >>> its@ietf.org https://www.ietf.org/mailman/l >>> istinfo/its >>> >>> >>> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >> > > > > -- > Michelle Wetterwald > michelle.wetterwald@gmail.com > --=20 Michelle Wetterwald michelle.wetterwald@gmail.com --0000000000009f0dca05664200be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I meant IEEE 802.11-2016, of course...

2018-02-28 9:58 GMT+01:00 Michelle We= tterwald <mlwetterwald@gmail.com>:
=

Hi Alex,

I fully agree with Katrin and was about = to send a similar post, as the EDCA queues are used also by ITS-G5 for the = DCC, which is mandated by the new EU regulation.

Unless you want to r= ewrite all ETSI standards and related European norms in a couple of=C2=A0 w= eeks, I would suggest to keep the old text and guarantee openness for using= the IEEE 802.16-16 standard while complying to local regulations.

I= would also suggest to bring this topic, as well as the handling of QoS for= IPWAVE, which is an interesting topic, to the re-chartering discussion tha= t was proposed by Carlos-Jesus a few weeks ago. The same as we did for ND o= r this nice multicast address that would be reserved for IPWAVE services.

BTW, you really plan to send CAMs directly over IPv6, without any tran= sport layer? I thought you would use UDP, which has a "large" hea= der as well.

=C2=A0(found in an "old" post dated back fro= m 4 days ago. ) :
>> CAM transported in IP may be a = smaller packet than CAM transported in=20 BTP and GeoNetworking.

Michelle

= 2018-02-28 8:07 GMT+01:00 Alexandre Petrescu <alexandre.petres= cu@gmail.com>:
Thank you for the mes= sage.

Le 28/02/2018 =C3=A0 07:08, Katrin Sj=C3=B6berg a =C3=A9crit :
[...]
This implies that the current IETF proposal of using IPv6 over DCF would be= impossible to use in Europe.

 Unless, of course, we suggest modify the ETSI specification to allow for 802.11 Data headers as well as 802.11 QoS Data headers.

(there are many reasons to ponder over a major rehaul of ETSI ITS
specifications, starting at the CAM itself, that I could explain
separately).

If all IPv6 trafffic has to use a common EDCA access category, I would supp= ort John's suggestion from an earlier email to fix IPv6 traffic to AC_B= K.

 This could be done.=C2=A0 On my side I would need to see running code for i= t,
and then there is need of consensus (could be obvious from your standpoint)= .

As J=C3=AAr=C3=B3me pointed out, we use AC_BE for CAMs,

 Thank you for this message.=C2=A0 I understand you have an implementation o= f
CAM sent with IEEE 802.11 QoSData header.=C2=A0 Is it the one from Unex wit= h
Autotalks chipset?

(the CAM implementations I use are from github.com and ath9k driver;
they dont generate 802.11 QoSData header, but use 802.11 Data header,
hence no AC_BE).

and I know the US uses AC_BE for some of their safety messages as
well.

 I think me too, I have seen BSM messages carried with 802.11 QoSData
headers, field Priority value 2 Spare (Background); I guess that stands
for AC_BK.=C2=A0 But I could not figure out what was the software that
implemented it.

Alex


Best regards, Katrin Sj=C3=B6berg



2018-02-27 17:50 GMT+01:00 Tony Li <tony.li@tony.li <mailto:tony.li@tony.li>>:


If someone knows how to generate a QoSData transported IP packet with linux= open source then I am all ears.


This is just a Small Matter Of Programming for anyone with a bit of kernel = hacking experience and driver sources.

Tony

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



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



--



--
Michelle W= etterwald
--0000000000009f0dca05664200be-- From nobody Wed Feb 28 01:03:39 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 248BB12E04F for ; Wed, 28 Feb 2018 01:03:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsYK8Xap5pTc for ; Wed, 28 Feb 2018 01:03:24 -0800 (PST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (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 579A212DA51 for ; Wed, 28 Feb 2018 01:03:06 -0800 (PST) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1eqxde-0008RG-Hq; Wed, 28 Feb 2018 10:03:02 +0100 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 7E86742032D; Wed, 28 Feb 2018 10:03:02 +0100 (CET) To: Alexandre Petrescu , =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , =?UTF-8?Q?'Fran=c3=a7ois_Simon'?= , its@ietf.org References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <006301d3ace3$25f9d500$71ed7f00$@eurecom.fr> <007901d3aee3$a9985ba0$fcc912e0$@eurecom.fr> <00f801d3af1d$f20ce4c0$d626ae40$@gmail.com> <002b01d3af21$6e779a70$4b66cf50$@eurecom.fr> From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology Message-ID: Date: Wed, 28 Feb 2018 10:03:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1519808582.613525138 Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 28 Feb 2018 09:03:26 -0000 Hi, Am 28.02.2018 um 07:47 schrieb Alexandre Petrescu: > I clearly state that what is missing is implementation. > > We need this to work: ping -Q to issue 802.11 QoSData (instead of 802.11 > Data) at 5.9GHz in OCB mode. > > We tried to make it work but to no avail: > - OCB mode at 5.9GHz works fine with mainline linux kernel, driver > ath9k. > - ping -Q works fine, it generates the proper DSCP fields in the IP > header. > - the diffserv DSCP options are checked in the kernel. > - there is DSCP in the IP header but there is no 802.11 QoSData header > (there is 802.11 Data header). > > Have you seen RFC8325 working? Thanks for the clarification. IMHO this is a pure implementation problem, not a conceptual problem with the standards. RFC8325 is pretty new, but I expect that some recent APs from a larger vendor will support this, since they did the proposal. Regards Roland From nobody Wed Feb 28 01:27:39 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 616FF12EAEC for ; Wed, 28 Feb 2018 01:27:38 -0800 (PST) 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 2kiKLGbN1sob for ; Wed, 28 Feb 2018 01:27:36 -0800 (PST) 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 7423212EAE7 for ; Wed, 28 Feb 2018 01:27:35 -0800 (PST) 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 w1S9RW2n115181; Wed, 28 Feb 2018 10:27:32 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8DB05200808; Wed, 28 Feb 2018 10:27:32 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 6FBB6203028; Wed, 28 Feb 2018 10:27:32 +0100 (CET) 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 w1S9RWKW015228; Wed, 28 Feb 2018 10:27:32 +0100 To: Mie Eur Cc: =?UTF-8?Q?Katrin_Sj=c3=b6berg?= , its , =?UTF-8?Q?Fran=c3=a7ois_Simon?= , =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , John Kenney , "Dr. Hans-Joachim Fischer" , Tony Li , Abdussalam Baryun References: <9ada5591-2af3-272d-3bc3-031bf35454c3@gmail.com> <6cdc0835-fb4c-133b-77ff-0234cfdd9ef9@fischer-tech.eu> <00eb01d3af1d$7f4e8100$7deb8300$@gmail.com> <6187cb92-5c8f-d08b-dcc2-859652d629d0@gmail.com> <002901d3af20$b966e960$2c34bc20$@eurecom.fr> <002601d3afc4$a10fbb90$e32f32b0$@eurecom.fr> <71309c28-9d7e-d277-a3b0-46d1a3b4042e@gmail.com> <004701d3afd0$63867190$2a9354b0$@eurecom.fr> <461166f2-f3cc-e749-3628-f1d87104200b@gmail.com> <4997BFDE-1B3F-4F17-9742-28F23F082A15@tony.li> From: Alexandre Petrescu Message-ID: <596b8280-af45-aca2-9ea9-b05dce716ff1@gmail.com> Date: Wed, 28 Feb 2018 10:27:31 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.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] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 28 Feb 2018 09:27:38 -0000 Le 28/02/2018 à 09:50, Mie Eur a écrit : > Hi Alex, > > I fully agree with Katrin and was about to send a similar post, as > the EDCA queues are used also by ITS-G5 for the DCC, which is > mandated by the new EU regulation. I would really be surprised that EU mandates something that depends on closed source, potentially favoring a competitive edge to a particular private interest. But I am optimistic: given all the stimulation of open source in EU projects I believe EU regulators understand the implications related to cost, licensing, and interoperability. > Unless you want to rewrite all ETSI standards and related European > norms in a couple of weeks, In one of these days I will post a critique of the CAM specification. > I would suggest to keep the old text and guarantee openness for using > the IEEE 802.11-16 standard while complying to local regulations. YEs, we need that. But the old text says: > "In OCB mode, IPv6 packets MAY be transmitted either as "IEEE 802.11 > Data" or alternatively as "IEEE 802.11 QoS Data" I implement only the 802.11 Data and my partner(s) use equipment bought from Unex that only implements QoS Data. I want our software to interoperate. If the text said just 'Data', then I could direct my partners to the open source on the Internet. But in current situation my partners direct me to Unex, which is expensive - it has a cost. I do not agree to continue this situation. Either the QoSData supporters direct me to an open source implementation of QoSData now, or we relegate the QoS discussion for later. > I would also suggest to bring this topic, as well as the handling of > QoS for IPWAVE, which is an interesting topic, to the re-chartering > discussion that was proposed by Carlos-Jesus a few weeks ago. The > same as we did for ND or this nice multicast address that would be > reserved for IPWAVE services. I agree. > BTW, you really plan to send CAMs directly over IPv6, without any > transport layer? I thought you would use UDP, which has a "large" > header as well. (found in an "old" post dated back from 4 days ago. > ) At this time, with partners, we ponder the idea of a different CAM if you wish (not sure whether UDP, or just IP, or 802.11 Data, or 802.11 QoS Data). This different CAM is interoperable and cheap to produce. CAM over UDP over IPv6 was already produced by others in other project. I think they didnt bother to standardise it, but it worked for them. I am tempted to copy from them. Alex > : >>> CAM transported in IP may be a smaller packet than CAM >>> transported > in BTP and GeoNetworking. > > > 2018-02-28 8:07 GMT+01:00 Alexandre Petrescu > >: > > Thank you for the message. > > Le 28/02/2018 à 07:08, Katrin Sjöberg a écrit : [...] > > This implies that the current IETF proposal of using IPv6 over DCF > would be impossible to use in Europe. > > > Unless, of course, we suggest modify the ETSI specification to allow > for 802.11 Data headers as well as 802.11 QoS Data headers. > > (there are many reasons to ponder over a major rehaul of ETSI ITS > specifications, starting at the CAM itself, that I could explain > separately). > > If all IPv6 trafffic has to use a common EDCA access category, I > would support John's suggestion from an earlier email to fix IPv6 > traffic to AC_BK. > > > This could be done. On my side I would need to see running code for > it, and then there is need of consensus (could be obvious from your > standpoint). > > As Jêróme pointed out, we use AC_BE for CAMs, > > > Thank you for this message. I understand you have an implementation > of CAM sent with IEEE 802.11 QoSData header. Is it the one from > Unex with Autotalks chipset? > > (the CAM implementations I use are from github.com > and ath9k driver; they dont generate 802.11 > QoSData header, but use 802.11 Data header, hence no AC_BE). > > and I know the US uses AC_BE for some of their safety messages as > well. > > > I think me too, I have seen BSM messages carried with 802.11 QoSData > headers, field Priority value 2 Spare (Background); I guess that > stands for AC_BK. But I could not figure out what was the software > that implemented it. > > Alex > > > Best regards, Katrin Sjöberg > > > > 2018-02-27 17:50 GMT+01:00 Tony Li >>: > > > If someone knows how to generate a QoSData transported IP packet with > linux open source then I am all ears. > > > > This is just a Small Matter Of Programming for anyone with a bit of > kernel hacking experience and driver sources. > > Tony > > _______________________________________________ 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 > > > > > > -- Michelle WETTERWALD From nobody Wed Feb 28 01:41:26 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 384DF1276AF for ; Wed, 28 Feb 2018 01:41:24 -0800 (PST) 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 omsKrlKQNc-K for ; Wed, 28 Feb 2018 01:41:22 -0800 (PST) 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 21A2512EAEE for ; Wed, 28 Feb 2018 01:41:21 -0800 (PST) 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 w1S9fJhl016726; Wed, 28 Feb 2018 10:41:19 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id CD387202EA4; Wed, 28 Feb 2018 10:41:19 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id BB890201FDD; Wed, 28 Feb 2018 10:41:19 +0100 (CET) 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 w1S9fJEi000620; Wed, 28 Feb 2018 10:41:19 +0100 To: "Bless, Roland (TM)" , =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , "=?UTF-8?Q?'Fran=c3=a7ois_Simon'?=" , its@ietf.org References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <006301d3ace3$25f9d500$71ed7f00$@eurecom.fr> <007901d3aee3$a9985ba0$fcc912e0$@eurecom.fr> <00f801d3af1d$f20ce4c0$d626ae40$@gmail.com> <002b01d3af21$6e779a70$4b66cf50$@eurecom.fr> From: Alexandre Petrescu Message-ID: <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> Date: Wed, 28 Feb 2018 10:41:19 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.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] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 28 Feb 2018 09:41:24 -0000 Le 28/02/2018 à 10:03, Bless, Roland (TM) a écrit : > Hi, > > Am 28.02.2018 um 07:47 schrieb Alexandre Petrescu: > >> I clearly state that what is missing is implementation. >> >> We need this to work: ping -Q to issue 802.11 QoSData (instead of 802.11 >> Data) at 5.9GHz in OCB mode. >> >> We tried to make it work but to no avail: >> - OCB mode at 5.9GHz works fine with mainline linux kernel, driver >> ath9k. >> - ping -Q works fine, it generates the proper DSCP fields in the IP >> header. >> - the diffserv DSCP options are checked in the kernel. >> - there is DSCP in the IP header but there is no 802.11 QoSData header >> (there is 802.11 Data header). >> >> Have you seen RFC8325 working? > > Thanks for the clarification. IMHO this is a pure implementation > problem, not a conceptual problem with the standards. Right, it is not a conceptual problem with the standards - it's just a mapping. It can work. It _can_. When do we want to submit a draft to IESG to consider to become an RFC: when the implementation exists already? or before? Because some drafts get submitted, some become RFCs, and some never get the success one expects them to (read: no implementation). > RFC8325 is pretty new, but I expect that some recent APs from > a larger vendor will support this, since they did the proposal. Thanks for the clarification. Since RFC8325 is on the Standards Track, I believe there should be more than just one vendor supporting it (otherwise it were EXPERIMENTAL or INFORMATIONAL). Maybe that vendor proposed an implementation as open source, and agreed somehow by some non-that-vendor implementers. If the vendor tells us what is the implementation of RFC8325, we can tell them how to use it on an additional kind of Access Points: an IP Road-Side Unit to connect cars. Alex > > Regards > Roland > From nobody Wed Feb 28 01:48:01 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79E1F12EAD8 for ; Wed, 28 Feb 2018 01:47:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmwDNgcPR2r6 for ; Wed, 28 Feb 2018 01:47:54 -0800 (PST) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::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 E4F6012EAF1 for ; Wed, 28 Feb 2018 01:47:53 -0800 (PST) Received: by mail-ua0-x233.google.com with SMTP id z3so1113755uae.12 for ; Wed, 28 Feb 2018 01:47:53 -0800 (PST) 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=usNvAOiwUimBPZDpY2J9oR4weD8l25y2JTf9vG23pKU=; b=EI272ZfSd1kb/plHE2IdVc5gSl9hJ3FsCBwnjr6cPp9VCMod7Bq4n01WJVIu7icRBF ruYnhhZnsLWsq28CiUHrWbUZUXteb2SJcnhl3TmPn8DS8kjITdfqUBkVMkL7Xp/HPdT4 Yn9aQ1r2VbB2jfVaUWj9C9nWnXy9W9FlNNWOvP9FXDtsQkGYJUcxeegWsVR5mjJ9gqyz I85WgNtleVDOc5WP0bzDGkxWrdfmj0/xieo3D3PYbRy/EVebFVqz0pdf5+xjLqw/L4mw EloFeL6Hf8W5OKNl/krNc8h7s53/oqpqXjL8alZhcG9fFFDzC1HkYQ3nKH9CCaFf1Bhn Vxiw== 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=usNvAOiwUimBPZDpY2J9oR4weD8l25y2JTf9vG23pKU=; b=YUF9R7IAGpuzRemSxeJhGDyWFbddzFBDdDdDY7YnUQpOzj5Mg5gXrSX6cE+yKWR3LF i9W8WyrGzZ++SSGni6CSuNJ9rpgVATg7nkqUEJSd4Ie12j2mS1JBA5JGhmSiYk8mU7Qr oBptCwrt+tjzj4H9SJKZVsrw3cFgxDeYfrx8PRq3tZNJqSdfiLVZ+WTplSKmqLxzTP7a dEYxDmUYBw5sapkphsjBMa3MuEteyi5zBpdzMkJgw12qoh8j2tqDJ1LXb0LFtPCU0hgS kPxZYZahCgRaY5L64gBBB2gpkfHL7K/g0ag96TTjaen/QyIusRYAGAz67BnLjN+J0DjZ QwoQ== X-Gm-Message-State: APf1xPBX6UmF9BRgIBUerog6Ez8bcaKDg+vLFxDhKDyPu+DaBuKTgQOK KF8uiUDjCQfNRnEln/qyDbqrDWYZb8Gl2lUWxGE= X-Google-Smtp-Source: AG47ELuTzegLVRmGBJ55T87beueHZ1b1K/nK2zllildtTdyo/GHbMqYLmRa9FYhLGTqOs6SfQA23/zv1t9KOFSuovAc= X-Received: by 10.159.59.161 with SMTP id r33mr13058561uah.22.1519811270051; Wed, 28 Feb 2018 01:47:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.144.92 with HTTP; Wed, 28 Feb 2018 01:47:49 -0800 (PST) In-Reply-To: <596b8280-af45-aca2-9ea9-b05dce716ff1@gmail.com> References: <9ada5591-2af3-272d-3bc3-031bf35454c3@gmail.com> <6cdc0835-fb4c-133b-77ff-0234cfdd9ef9@fischer-tech.eu> <00eb01d3af1d$7f4e8100$7deb8300$@gmail.com> <6187cb92-5c8f-d08b-dcc2-859652d629d0@gmail.com> <002901d3af20$b966e960$2c34bc20$@eurecom.fr> <002601d3afc4$a10fbb90$e32f32b0$@eurecom.fr> <71309c28-9d7e-d277-a3b0-46d1a3b4042e@gmail.com> <004701d3afd0$63867190$2a9354b0$@eurecom.fr> <461166f2-f3cc-e749-3628-f1d87104200b@gmail.com> <4997BFDE-1B3F-4F17-9742-28F23F082A15@tony.li> <596b8280-af45-aca2-9ea9-b05dce716ff1@gmail.com> From: =?UTF-8?Q?Katrin_Sj=C3=B6berg?= Date: Wed, 28 Feb 2018 10:47:49 +0100 Message-ID: To: Alexandre Petrescu Cc: Mie Eur , its , =?UTF-8?Q?Fran=C3=A7ois_Simon?= , =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , John Kenney , "Dr. Hans-Joachim Fischer" , Tony Li , Abdussalam Baryun Content-Type: multipart/alternative; boundary="f403043eddcce08ceb056642a2c0" Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 28 Feb 2018 09:47:56 -0000 --f403043eddcce08ceb056642a2c0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alexandre, All, We are mixing apples and pears in this discussion and it is very frustrating. On one hand, the discussion is about detailed open source software implementations that do not support QoS data with how the EU mandate will look like. First of all, the QoS data is handled by the chipset covering MAC+PHY on top of this LLC resides. IPv6 is on top of LLC. And suddenly the CAM specification, which is residing in the facilities layer is discussed. What is the problem with making EDCA mandatory in this standard? The amendment IEEE 802.11e, which introduced the concept of EDCA, was approved in 2005 and it was a unique selling point for WiFi APs in the beginning. EDCA has been around for 13 years and this standard developed in 2018 for supporting IPv6 in VANETs when using IEEE 802.11p wants to use DCF due to some existing implementation... For me this is like being thrown back to the stone age. I am working for an OEM and I cannot accept that this standard will allow IPv6 traffic over IEEE 802.11p using DCF since it might adventure road traffic safety applications that are under development. We want to reduce the number of accidents and the impact of the same by using IEEE 802.11p with EDCA and suddenly messages such as CAMs might be starved out because someone is transmitting IPv6 traffic using DCF. This is not acceptable and once again I want to emphasize that EN 302 663 in Europe requires EDCA, which would prohibit this standard to use the 5.9 GHz band. Best regards, Katrin 2018-02-28 10:27 GMT+01:00 Alexandre Petrescu : > > > Le 28/02/2018 =C3=A0 09:50, Mie Eur a =C3=A9crit : > >> Hi Alex, >> >> I fully agree with Katrin and was about to send a similar post, as the >> EDCA queues are used also by ITS-G5 for the DCC, which is mandated by th= e >> new EU regulation. >> > > I would really be surprised that EU mandates something that depends > on closed source, potentially favoring a competitive edge to a > particular private interest. But I am optimistic: given all the > stimulation of open source in EU projects I believe EU regulators > understand the implications related to cost, licensing, and > interoperability. > > Unless you want to rewrite all ETSI standards and related European norms >> in a couple of weeks, >> > > In one of these days I will post a critique of the CAM specification. > > I would suggest to keep the old text and guarantee openness for using >> the IEEE 802.11-16 standard while complying to local regulations. >> > > YEs, we need that. > > But the old text says: > >> "In OCB mode, IPv6 packets MAY be transmitted either as "IEEE 802.11 >> Data" or alternatively as "IEEE 802.11 QoS Data" >> > > I implement only the 802.11 Data and my partner(s) use equipment bought > from Unex that only implements QoS Data. I want our software to > interoperate. > > If the text said just 'Data', then I could direct my partners to the > open source on the Internet. But in current situation my partners > direct me to Unex, which is expensive - it has a cost. > > I do not agree to continue this situation. > > Either the QoSData supporters direct me to an open source implementation > of QoSData now, or we relegate the QoS discussion for later. > > I would also suggest to bring this topic, as well as the handling of >> QoS for IPWAVE, which is an interesting topic, to the re-chartering >> discussion that was proposed by Carlos-Jesus a few weeks ago. The same >> as we did for ND or this nice multicast address that would be reserved f= or >> IPWAVE services. >> > > I agree. > > BTW, you really plan to send CAMs directly over IPv6, without any >> transport layer? I thought you would use UDP, which has a "large" header= as >> well. (found in an "old" post dated back from 4 days ago. ) >> > > At this time, with partners, we ponder the idea of a different CAM if > you wish (not sure whether UDP, or just IP, or 802.11 Data, or 802.11 > QoS Data). This different CAM is interoperable and cheap to produce. > > CAM over UDP over IPv6 was already produced by others in other project. > I think they didnt bother to standardise it, but it worked for them. I > am tempted to copy from them. > > Alex > > : >> >>> CAM transported in IP may be a smaller packet than CAM transported >>>> >>> in BTP and GeoNetworking. >> >> >> 2018-02-28 8:07 GMT+01:00 Alexandre Petrescu < >> alexandre.petrescu@gmail.com >: >> >> Thank you for the message. >> >> Le 28/02/2018 =C3=A0 07:08, Katrin Sj=C3=B6berg a =C3=A9crit : [...] >> >> This implies that the current IETF proposal of using IPv6 over DCF would >> be impossible to use in Europe. >> >> >> Unless, of course, we suggest modify the ETSI specification to allow >> for 802.11 Data headers as well as 802.11 QoS Data headers. >> >> (there are many reasons to ponder over a major rehaul of ETSI ITS >> specifications, starting at the CAM itself, that I could explain >> separately). >> >> If all IPv6 trafffic has to use a common EDCA access category, I would >> support John's suggestion from an earlier email to fix IPv6 traffic to >> AC_BK. >> >> >> This could be done. On my side I would need to see running code for >> it, and then there is need of consensus (could be obvious from your >> standpoint). >> >> As J=C3=AAr=C3=B3me pointed out, we use AC_BE for CAMs, >> >> >> Thank you for this message. I understand you have an implementation >> of CAM sent with IEEE 802.11 QoSData header. Is it the one from >> Unex with Autotalks chipset? >> >> (the CAM implementations I use are from github.com >> and ath9k driver; they dont generate 802.11 QoSData header, but use 802.= 11 >> Data header, hence no AC_BE). >> >> and I know the US uses AC_BE for some of their safety messages as well. >> >> >> I think me too, I have seen BSM messages carried with 802.11 QoSData >> headers, field Priority value 2 Spare (Background); I guess that stands = for >> AC_BK. But I could not figure out what was the software that implemente= d >> it. >> >> Alex >> >> >> Best regards, Katrin Sj=C3=B6berg >> >> >> >> 2018-02-27 17:50 GMT+01:00 Tony Li > tony.li@tony.li> >>: >> >> >> If someone knows how to generate a QoSData transported IP packet with >> linux open source then I am all ears. >> >> >> >> This is just a Small Matter Of Programming for anyone with a bit of >> kernel hacking experience and driver sources. >> >> Tony >> >> _______________________________________________ its mailing list >> its@ietf.org > its@ietf.org>> https://www.ietf.org/mailman/listinfo/its < >> https://www.ietf.org/mailman/listinfo/its> > listinfo/its > >> >> >> >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/l >> istinfo/its >> >> >> >> >> -- Michelle WETTERWALD >> > --f403043eddcce08ceb056642a2c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alexandre, All,

We are mixing apples and pears i= n this discussion and it is very frustrating. On one hand, the discussion i= s about detailed open source software implementations that do not support Q= oS data with how the EU mandate will look like.

First of= all, the QoS data is handled by the chipset covering MAC+PHY on top of thi= s LLC resides. IPv6 is on top of LLC. And suddenly the CAM specification, w= hich is residing in the facilities layer is discussed. What is the problem = with making EDCA mandatory in this standard? The=20 amendment IEEE 802.11e, which introduced the concept of EDCA, was=20 approved in 2005 and it was a unique selling point for WiFi APs in the=20 beginning. EDCA has been around for 13 years and this standard developed in 2018 for supporting IPv6 in VANETs when using IEEE 802.11p wants to=20 use DCF due to some existing implementation... For me this is like being thrown back to the stone age.

I am working for an OEM and I = cannot accept that this=20 standard will allow IPv6 traffic over IEEE 802.11p using DCF since it might adventure road traffic safety applications that are under development. We = want to reduce the number of accidents and the impact of the same by using = IEEE 802.11p with EDCA and suddenly messages such as CAMs might be starved = out because someone is transmitting IPv6 traffic using DCF. This is not acc= eptable and once again I want to emphasize that EN 302 663 in Europe requir= es EDCA, which would prohibit this standard to use the 5.9 GHz band.
Best regards,
Katrin

2018-02-28 10:27 GMT+01:00 Alexandre Petres= cu <alexandre.petrescu@gmail.com>:


Le 28/02/2018 =C3=A0 09:50, Mie Eur a =C3=A9crit :
Hi Alex,

I fully agree with Katrin and was about to send a similar post, as the EDCA= queues are used also by ITS-G5 for the DCC, which is mandated by the new E= U regulation.

 I would really be surprised that EU mandates something that depends
on closed source, potentially favoring a competitive edge to a
particular private interest.=C2=A0 But I am optimistic: given all the
stimulation of open source in EU projects I believe EU regulators
understand the implications related to cost, licensing, and
interoperability.

Unless you want to rewrite all ETSI standards and related European norms in= a couple of=C2=A0 weeks,

 In one of these days I will post a critique of the CAM specification.

I would suggest to keep the old text and guarantee openness for using
the IEEE 802.11-16 standard while complying to local regulations.

YEs, we need that.

But the old text says:
"In OCB mode, IPv6 packets MAY be transmitted either as "IEEE 802= .11
=C2=A0Data" or alternatively as "IEEE 802.11 QoS Data"

 I implement only the 802.11 Data and my partner(s) use equipment bought
from Unex that only implements QoS Data.=C2=A0 I want our software to
interoperate.

If the text said just 'Data', then I could direct my partners to th= e
open source on the Internet.=C2=A0 But in current situation my partners
direct me to Unex, which is expensive - it has a cost.

I do not agree to continue this situation.

Either the QoSData supporters direct me to an open source implementation of QoSData now, or we relegate the QoS discussion for later.

I would also suggest to bring this topic, as well as the handling of
=C2=A0QoS for IPWAVE, which is an interesting topic, to the re-chartering =C2=A0discussion that was proposed by Carlos-Jesus a few weeks ago. The sam= e as we did for ND or this nice multicast address that would be reserved fo= r IPWAVE services.

 I agree.

BTW, you really plan to send CAMs directly over IPv6, without any transport= layer? I thought you would use UDP, which has a "large" header a= s well. (found in an "old" post dated back from 4 days ago. )

 At this time, with partners, we ponder the idea of a different CAM if
you wish (not sure whether UDP, or just IP, or 802.11 Data, or 802.11
QoS Data).=C2=A0 This different CAM is interoperable and cheap to produce.<= br>
CAM over UDP over IPv6 was already produced by others in other project.
=C2=A0I think they didnt bother to standardise it, but it worked for them.= =C2=A0 I
am tempted to copy from them.

Alex

:
CAM transported in IP may be a smaller packet than CAM transported
in BTP and GeoNetworking.


 2018-02-28 8:07 GMT+01:00 Alexandre Petrescu <alexandre.petrescu@gmail.com &l= t;mailto:= alexandre.petrescu@gmail.com>>:

Thank you for the message.

Le 28/02/2018 =C3=A0 07:08, Katrin Sj=C3=B6berg a =C3=A9crit : [...]

This implies that the current IETF proposal of using IPv6 over DCF would be= impossible to use in Europe.


Unless, of course, we suggest modify the ETSI specification to allow
=C2=A0for 802.11 Data headers as well as 802.11 QoS Data headers.

(there are many reasons to ponder over a major rehaul of ETSI ITS specifica= tions, starting at the CAM itself, that I could explain separately).

If all IPv6 trafffic has to use a common EDCA access category, I would supp= ort John's suggestion from an earlier email to fix IPv6 traffic to AC_B= K.


This could be done.=C2=A0 On my side I would need to see running code for =C2=A0it, and then there is need of consensus (could be obvious from your =C2=A0standpoint).

As J=C3=AAr=C3=B3me pointed out, we use AC_BE for CAMs,


Thank you for this message.=C2=A0 I understand you have an implementation =C2=A0of CAM sent with IEEE 802.11 QoSData header.=C2=A0 Is it the one from=
Unex with Autotalks chipset?

 (the CAM implementations I use are from github.com <http://github.com> and = ath9k driver; they dont generate 802.11 QoSData header, but use 802.11 Data= header, hence no AC_BE).

and I know the US uses AC_BE for some of their safety messages as well.


I think me too, I have seen BSM messages carried with 802.11 QoSData header= s, field Priority value 2 Spare (Background); I guess that stands for AC_BK= .=C2=A0 But I could not figure out what was the software that implemented i= t.

Alex


Best regards, Katrin Sj=C3=B6berg



 2018-02-27 17:50 GMT+01:00 Tony Li <tony.li@tony.li <mailto:tony.li@tony.li> <mailto:tony.li@tony.li <mailto:tony.li@tony.li>>= >:


If someone knows how to generate a QoSData transported IP packet with
linux open source then I am all ears.



This is just a Small Matter Of Programming for anyone with a bit of kernel = hacking experience and driver sources.

Tony

 _______________________________________________ its mailing list its@ietf.org <mailto:its@ietf.org> <ma= ilto:its@ietf.org <= ;mailto:its@ietf.org&= gt;> https://www.ietf.org/mailman/listinfo/its = <https://www.ietf.org/mailman/listinfo/its> = <https://www.ietf.org/mailman/listinfo/its <= https://www.ietf.org/mailman/listinfo/its>><= span class=3D"">



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




-- Michelle WETTERWALD

--f403043eddcce08ceb056642a2c0-- From nobody Wed Feb 28 01:48:40 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5485A1276AF for ; Wed, 28 Feb 2018 01:48:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfBONAmAg7Z9 for ; Wed, 28 Feb 2018 01:48:36 -0800 (PST) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C23E41200B9 for ; Wed, 28 Feb 2018 01:48:35 -0800 (PST) Received: by mail-lf0-x229.google.com with SMTP id h127so1509860lfg.12 for ; Wed, 28 Feb 2018 01:48:35 -0800 (PST) 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=4aPDlJq9SUOxQClAgp8eJATRJlbueP4nLMPfvEElBVM=; b=BSq5/09vwE3gHj80lCuSoE89pfYAdYLmthX4NDV2N+o/JtyP9mlpZSMIYhhQ7edvnq nwy3GK+ApPzBXbY53f4GpJibjrndV5g6/HLSomGdo6g6crP2yZ8AoJzkbMZ8excWCHv/ jTRFJ7Z+MnX0k+GHJ5UV5toS3SFEbQOicl8+9mTa1/7nsOb9Xg4jh1/wQiXWwNKOj36S gRTsv2oD8iqO5KdPeppA4CE9WkHjdS8GP9w1xdxKU4PYTGIKtpQ56gtn/YswtQhCouhG 6MvcmAw3ybyD57WsUQclMFYCWv/7Nov0Kx5R0NF09fZrXIqFyGFQihPiq8DcsV+7JYBu 8qnw== 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=4aPDlJq9SUOxQClAgp8eJATRJlbueP4nLMPfvEElBVM=; b=PHuYqxT0wv4Zqyg5J4H0gL2YiLqvSF4eypz7ju0u/JuXcR752vw9AlnRhjukkgcFMu eKYNNK1uQXRcj7fkpuSMo7GJ9rYOXQIHQz92vtsLzHSCWQPPf12iCvGWPzuX4AI9lh7s H1WjtIBuYK/thtuV6+qQYETriWZwsgbXAwCMVoY0RFMqKvKe7c9BbNzeRvM/5OYVSdv2 5UE063qxM/voxWXdBGtA9FGZj3U7MCHQ8nyDC3gqGh/5yf222aPwNDrjqRNK9m3t7qcz 23WGIHM9tJdIJVIz3gX7gpFuE16fmOvSq0Ym9NpI2CBZpKBg002c9Te8MeIDMXaAVvDa azbw== X-Gm-Message-State: APf1xPAJq62kDKXokU59A128x2D8Zj4jAPPlHObHciFD/jxDj0+DFnnZ D1m3Xqy1hhJEm2ZEnncDXpB70XbDrf/mnTQ768Y= X-Google-Smtp-Source: AG47ELsRUcpOKobUaO5ltGeezgxx9nWz69JxKnuLKTzILoj/6ubVblRaN/c2+E22dGMhWk/WKC7HbypTeb2fMCz6s1E= X-Received: by 10.25.212.19 with SMTP id l19mr12279879lfg.83.1519811313907; Wed, 28 Feb 2018 01:48:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.24.20 with HTTP; Wed, 28 Feb 2018 01:48:33 -0800 (PST) In-Reply-To: <004601d3b061$4adadcd0$e0909670$@eurecom.fr> References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <9ada5591-2af3-272d-3bc3-031bf35454c3@gmail.com> <52ADDCC5-5AF1-4657-AE0C-AD9240ED6093@tony.li> <004601d3b061$4adadcd0$e0909670$@eurecom.fr> From: Nabil Benamar Date: Wed, 28 Feb 2018 09:48:33 +0000 Message-ID: To: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= Cc: Tony Li , John Kenney , Alexandre Petrescu , =?UTF-8?Q?Katrin_Sj=C3=B6berg?= , its Content-Type: multipart/alternative; boundary="001a114064767dbfd4056642a572" Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB - text modifications towards resolution 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, 28 Feb 2018 09:48:38 -0000 --001a114064767dbfd4056642a572 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 J=C3=A9r=C3=B4me Best regards Nabil Benamar ------------------- =D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88 On Wed, Feb 28, 2018 at 6:56 AM, J=C3=A9r=C3=B4me H=C3=A4rri wrote: > Hi Tony, > > > > If you count every bits, then I would seriously argue why do we need the > heavy IPv6 machinery to transmit over OCB, when WSN/Geonet would do it > without (I called heavy machinery the ND, DAD, etc=E2=80=A6). > > > > Now, what we get is plain simple: coexistence=E2=80=A6there is nothing wi= thout > this. > > > > BR, > > > > J=C3=A9r=C3=B4me > > > > *From:* its [mailto:its-bounces@ietf.org] *On Behalf Of *Tony Li > *Sent:* Wednesday 28 February 2018 03:35 > *To:* John Kenney > *Cc:* Alexandre Petrescu; its > *Subject:* Re: [ipwave] 802.11 Data vs 802.11 QoS Data in > IPv6-over-802.11-OCB - text modifications towards resolution > > > > > > > > I suggest: > > NEW: > > In OCB mode, an IPv6 packet MUST be transmitted as an "IEEE 802.11 QoS > Data" frame. In the QoS Control Field, the TID subfield (Bits 0-3) MUST b= e > set equal to binary 0001, corresponding to UP =3D 1. > > > > Apologies if I don't have the IETF normative syntax right. > > > > > > The normative syntax looks fine to me. As long as you capitalize your > MUSTs and it=E2=80=99s clear, it=E2=80=99s usually just fine. > > > > Why is this somehow better than just sending it as data? It=E2=80=99s wo= rse, in > that it=E2=80=99s more bits in the ether. What are we getting for the co= st? > > > > Tony > > > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > --001a114064767dbfd4056642a572 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 J=C3=A9r=C3=B4me

<= br>

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



<= div>


On Wed, Feb 28, 2018 at 6:56 AM, J=C3=A9r=C3= =B4me H=C3=A4rri <jerome.haerri@eurecom.fr> wrote:

Hi Tony,

=C2=A0

If you count every bits, th= en I would seriously argue why do we need the heavy IPv6 machinery to trans= mit over OCB, when WSN/Geonet would do it without (I called heavy machinery= the ND, DAD, etc=E2=80=A6).

=C2=A0

Now, what we get is plain simple: coexis= tence=E2=80=A6there is nothing without this.

=C2=A0

=

BR,<= /p>

=C2=A0

J=C3=A9r=C3=B4me=

= =C2=A0

From: its [mailto:its-bounces@ietf.org] On Behalf Of <= /b>Tony Li
Sent: Wednesday 28 February 2018 03:35
To: J= ohn Kenney
Cc: Alexandre Petrescu; its
Subject: Re: [ip= wave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB - text modific= ations towards resolution

=C2=A0

=C2=A0



=

I suggest:

=

NEW:
>=C2=A0 In OCB mode, an IPv6 pack= et MUST be transmitted as an "IEEE=C2=A0802.11 QoS Data" frame. I= n the QoS Control Field, the TID subfield (Bits 0-3) MUST be set equal to b= inary 0001, corresponding to UP =3D 1.=C2=A0



=

Apologies if I don'= t have the IETF normative syntax right.

=

=C2=A0

=C2=A0

The normati= ve syntax looks fine to me. As long as you capitalize your MUSTs and it=E2= =80=99s clear, it=E2=80=99s usually just fine.

=

=C2=A0

Why is this somehow better than just sending it as data?=C2=A0 It=E2= =80=99s worse, in that it=E2=80=99s more bits in the ether.=C2=A0 What are = we getting for the cost?

=C2=A0

Tony

=C2=A0

=

=C2=A0


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


--001a114064767dbfd4056642a572-- From nobody Wed Feb 28 01:57:42 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E610D12EB02 for ; Wed, 28 Feb 2018 01:57:28 -0800 (PST) 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 nJwLMWeQiIM2 for ; Wed, 28 Feb 2018 01:57:27 -0800 (PST) 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 EAFD112EAFB for ; Wed, 28 Feb 2018 01:57:25 -0800 (PST) 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 w1S9vNCh022642; Wed, 28 Feb 2018 10:57:23 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B33C0202EA4; Wed, 28 Feb 2018 10:57:23 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9E60C2016B9; Wed, 28 Feb 2018 10:57:23 +0100 (CET) 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 w1S9vNhd020943; Wed, 28 Feb 2018 10:57:23 +0100 To: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , "'Tony Li'" , "'John Kenney'" Cc: "'its'" , "=?UTF-8?Q?'Katrin_Sj=c3=b6berg'?=" References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <9ada5591-2af3-272d-3bc3-031bf35454c3@gmail.com> <52ADDCC5-5AF1-4657-AE0C-AD9240ED6093@tony.li> <004601d3b061$4adadcd0$e0909670$@eurecom.fr> <78bc7114-a661-9524-e4d8-631910a7c789@gmail.com> <007901d3b069$47453950$d5cfabf0$@eurecom.fr> <7ffac3d6-db35-0538-94f3-743439bf7caa@gmail.com> <00df01d3b070$21cf3610$656da230$@eurecom.fr> From: Alexandre Petrescu Message-ID: Date: Wed, 28 Feb 2018 10:57:23 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <00df01d3b070$21cf3610$656da230$@eurecom.fr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB - costs 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, 28 Feb 2018 09:57:29 -0000 Le 28/02/2018 à 09:42, Jérôme Härri a écrit : > Hi Alex, > >> I agree. >> >> Let me go back to the cost comparison request of Tony. >> >> An 802.11 QoS Data Header is longer than a 802.11 Data Header by >> two bytes. This 2-byte 'QoS Control' field is only present in the >> QoS Data header, but absent from the Data header. Is its presence >> worth? > >> From my perspective, it does...two bytes is not much if it avoids >> issues with other technologies...let's call it coexistence cost :-) We need coexistence. To achieve it, these are the costs from my perspective at this time: - cost of proving the interoperability of at least two distinct implementations of QoS Data header. - cost of writing open source code to make QoS Data header work or, alternatively, - cost of acquiring a QoS Data implementation (I can quote Euro costs from two distinct manufacturers; it's in the range of thousand Euros per license, but includes many other ITS G5 functionalities) - cost of two bytes on wire for QoS Data - cost of two lines of text in an Internet Draft Do you see other costs? Alex >> > > BR, > > Jérôme > >> >> BR, >> >> Jérôme >> >> >> -----Original Message----- From: Alexandre Petrescu >> [mailto:alexandre.petrescu@gmail.com] Sent: Wednesday 28 February >> 2018 08:13 To: Jérôme Härri; 'Tony Li'; 'John Kenney' Cc: 'its'; >> 'Katrin Sjöberg' Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS >> Data in IPv6-over-802.11-OCB - text modifications towards >> resolution >> >> Jérôme, >> >> Please count the bits. >> >> The IPv6 header is 40bytes. >> >> How long are the BTP and GeoNetworking headers? >> >> I do not understand what do you mean more precisely by 'heavy >> machinery' and ND and DAD? ND is just a request/reply, and DAD is >> optional in some cases. >> >> Alex >> >> Le 28/02/2018 à 07:56, Jérôme Härri a écrit : >>> Hi Tony, >>> >>> If you count every bits, then I would seriously argue why do we >>> need the heavy IPv6 machinery to transmit over OCB, when >>> WSN/Geonet would do it without (I called heavy machinery the ND, >>> DAD, etc…). >>> >>> Now, what we get is plain simple: coexistence…there is nothing >>> without this. >>> >>> BR, >>> >>> Jérôme >>> >>> *From:*its [mailto:its-bounces@ietf.org] *On Behalf Of *Tony Li >>> *Sent:* Wednesday 28 February 2018 03:35 *To:* John Kenney *Cc:* >>> Alexandre Petrescu; its *Subject:* Re: [ipwave] 802.11 Data vs >>> 802.11 QoS Data in IPv6-over-802.11-OCB - text modifications >>> towards resolution >>> >>> >>> >>> I suggest: >>> >>> NEW: >>>> In OCB mode, an IPv6 packet MUST be transmitted as an "IEEE >>>> 802.11 QoS Data" frame. In the QoS Control Field, the TID >>>> subfield (Bits 0-3) MUST be set equal to binary 0001, >>>> corresponding to UP = 1. >>> >>> >>> >>> Apologies if I don't have the IETF normative syntax right. >>> >>> The normative syntax looks fine to me. As long as you capitalize >>> your MUSTs and it’s clear, it’s usually just fine. >>> >>> Why is this somehow better than just sending it as data? It’s >>> worse, in that it’s more bits in the ether. What are we getting >>> for the cost? >>> >>> Tony >>> >> >> > > From nobody Wed Feb 28 02:04:55 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 683CA12EAD8 for ; Wed, 28 Feb 2018 02:04:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0RuQNkROfNP for ; Wed, 28 Feb 2018 02:04:46 -0800 (PST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (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 9733B1276AF for ; Wed, 28 Feb 2018 02:04:46 -0800 (PST) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1eqybL-0004N9-AE; Wed, 28 Feb 2018 11:04:43 +0100 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 42E324202FA; Wed, 28 Feb 2018 11:04:43 +0100 (CET) To: Alexandre Petrescu , =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , =?UTF-8?Q?'Fran=c3=a7ois_Simon'?= , its@ietf.org References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <006301d3ace3$25f9d500$71ed7f00$@eurecom.fr> <007901d3aee3$a9985ba0$fcc912e0$@eurecom.fr> <00f801d3af1d$f20ce4c0$d626ae40$@gmail.com> <002b01d3af21$6e779a70$4b66cf50$@eurecom.fr> <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology Message-ID: Date: Wed, 28 Feb 2018 11:04:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1519812283.422593932 Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 28 Feb 2018 10:04:54 -0000 Hi Alexandre, Am 28.02.2018 um 10:41 schrieb Alexandre Petrescu: > Right, it is not a conceptual problem with the standards - it's just a > mapping.  It can work.  It _can_. > When do we want to submit a draft to IESG to consider to become an RFC: > when the implementation exists already?  or before? Short answer: Right now we have only two standard maturity levels left: Proposed Standard and Internet Standard. Normally (exception mentioned below) you don't need two independent different interoperable implementations for publishing a Proposed Standard. Longer answer: However, more detailed guidance provides https://tools.ietf.org/html/rfc7127 A Proposed Standard specification is stable, has resolved known design choices, has received significant community review, and appears to enjoy enough community interest to be considered valuable. [...] The IESG may require implementation and/or operational experience prior to granting Proposed Standard status to a specification that materially affects the core Internet protocols or that specifies behavior that may have significant operational impact on the Internet. So for Internet Standard: A specification for which significant implementation and successful operational experience has been obtained may be elevated to the Internet Standard level. > Because some drafts get submitted, some become RFCs, and some never get > the success one expects them to (read: no implementation). Even if you have implementations it does not mean that it is widely used. So implementations are hardly a measure for success, but running code is always good to have to show that it's viable. I was involved in a WG where people had strong objections and found the protocols too complex. This really wasn't the case as we had several implementations done by students...however, the opponents just ignored the running code... >> RFC8325 is pretty new, but I expect that some recent APs from >> a larger vendor will support this, since they did the proposal. > > Thanks for the clarification. > > Since RFC8325 is on the Standards Track, I believe there should be more > than just one vendor supporting it (otherwise it were EXPERIMENTAL or > INFORMATIONAL).  Maybe that vendor proposed an implementation as open > source, and agreed somehow by some non-that-vendor implementers. No, it's not how it works, see above. Proposed Standard is usually considered to be good enough to get interoperable implementations. Internet-Drafts with available (or even open) implementations are often considered as being better than those without. So running code is usually considered being a plus for I-Ds or PS documents, but it's normally not required unless solicited by the IESG. Regards Roland From nobody Wed Feb 28 02:09:20 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BBDE12EAF2 for ; Wed, 28 Feb 2018 02:09:18 -0800 (PST) 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 X0XMDaYmzpR8 for ; Wed, 28 Feb 2018 02:09:11 -0800 (PST) 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 91F7812EAF8 for ; Wed, 28 Feb 2018 02:09:10 -0800 (PST) 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 w1SA973B008245; Wed, 28 Feb 2018 11:09:07 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C7350203870; Wed, 28 Feb 2018 11:09:07 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A97CC203844; Wed, 28 Feb 2018 11:09:07 +0100 (CET) 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 w1SA97ET004780; Wed, 28 Feb 2018 11:09:07 +0100 To: =?UTF-8?Q?Katrin_Sj=c3=b6berg?= Cc: Mie Eur , its , =?UTF-8?Q?Fran=c3=a7ois_Simon?= , =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , John Kenney , "Dr. Hans-Joachim Fischer" , Tony Li , Abdussalam Baryun References: <6cdc0835-fb4c-133b-77ff-0234cfdd9ef9@fischer-tech.eu> <00eb01d3af1d$7f4e8100$7deb8300$@gmail.com> <6187cb92-5c8f-d08b-dcc2-859652d629d0@gmail.com> <002901d3af20$b966e960$2c34bc20$@eurecom.fr> <002601d3afc4$a10fbb90$e32f32b0$@eurecom.fr> <71309c28-9d7e-d277-a3b0-46d1a3b4042e@gmail.com> <004701d3afd0$63867190$2a9354b0$@eurecom.fr> <461166f2-f3cc-e749-3628-f1d87104200b@gmail.com> <4997BFDE-1B3F-4F17-9742-28F23F082A15@tony.li> <596b8280-af45-aca2-9ea9-b05dce716ff1@gmail.com> From: Alexandre Petrescu Message-ID: <88030b0f-128a-b185-e9b8-f13b76878a74@gmail.com> Date: Wed, 28 Feb 2018 11:09:07 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.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] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 28 Feb 2018 10:09:18 -0000 Le 28/02/2018 à 10:47, Katrin Sjöberg a écrit : > Hi Alexandre, All, > > We are mixing apples and pears in this discussion and it is very > frustrating. On one hand, the discussion is about detailed open > source software implementations that do not support QoS data with > how the EU mandate will look like. EU must take great care when mandating technologies. > First of all, the QoS data is handled by the chipset covering > MAC+PHY on top of this LLC resides. I agree. We use ath9k driver and mac80211 module in the linux kernel. > IPv6 is on top of LLC. Yes. > And suddenly the CAM specification, which is residing in the > facilities layer is discussed. I agree. Speaking CAM here is a stretch. The stretch comes from my single possible way (with BSM) to notice the existence of these QoS Data headers. I should have rather said "QoS Data transported message, e.g. CAM or BSM". When I say I have problems with CAM, and I will post a critique of it, is with the CAM message encoding, and lack of interoperability of that CAM. I do not critique the fact that QoS Data transports CAM. > What is the problem with making EDCA mandatory in this standard? The problem is the lack of implementations. > The amendment IEEE 802.11e, which introduced the concept of EDCA, was > approved in 2005 and it was a unique selling point for WiFi APs in > the beginning. EDCA has been around for 13 years and this standard > developed in 2018 for supporting IPv6 in VANETs when using IEEE > 802.11p wants to use DCF due to some existing implementation... For > me this is like being thrown back to the stone age. Sorry, not the intention to throw back to stone age. But I need implementation. > I am working for an OEM Is OEM implementing QoS Data? > and I cannot accept that this standard will > allow IPv6 traffic over IEEE 802.11p using DCF since it might > adventure road traffic safety applications that are under > development. We want to reduce the number of accidents and the > impact of the same by using IEEE 802.11p with EDCA and suddenly > messages such as CAMs might be starved out because someone is > transmitting IPv6 traffic using DCF. This is not acceptable and once > again I want to emphasize that EN 302 663 in Europe requires EDCA, > which would prohibit this standard to use the 5.9 GHz band. Hold on, hold on. Excuse me. Road traffic safety applications is also a huge worry for designers using IP packets. But, the spectrum is for everyone to coexist and interoperate. Alex > > Best regards, Katrin > > 2018-02-28 10:27 GMT+01:00 Alexandre Petrescu > >: > > > > Le 28/02/2018 à 09:50, Mie Eur a écrit : > > Hi Alex, > > I fully agree with Katrin and was about to send a similar post, as > the EDCA queues are used also by ITS-G5 for the DCC, which is > mandated by the new EU regulation. > > > I would really be surprised that EU mandates something that depends > on closed source, potentially favoring a competitive edge to a > particular private interest. But I am optimistic: given all the > stimulation of open source in EU projects I believe EU regulators > understand the implications related to cost, licensing, and > interoperability. > > Unless you want to rewrite all ETSI standards and related European > norms in a couple of weeks, > > > In one of these days I will post a critique of the CAM > specification. > > I would suggest to keep the old text and guarantee openness for using > the IEEE 802.11-16 standard while complying to local regulations. > > > YEs, we need that. > > But the old text says: > > "In OCB mode, IPv6 packets MAY be transmitted either as "IEEE 802.11 > Data" or alternatively as "IEEE 802.11 QoS Data" > > > I implement only the 802.11 Data and my partner(s) use equipment > bought from Unex that only implements QoS Data. I want our software > to interoperate. > > If the text said just 'Data', then I could direct my partners to the > open source on the Internet. But in current situation my partners > direct me to Unex, which is expensive - it has a cost. > > I do not agree to continue this situation. > > Either the QoSData supporters direct me to an open source > implementation of QoSData now, or we relegate the QoS discussion for > later. > > I would also suggest to bring this topic, as well as the handling of > QoS for IPWAVE, which is an interesting topic, to the re-chartering > discussion that was proposed by Carlos-Jesus a few weeks ago. The > same as we did for ND or this nice multicast address that would be > reserved for IPWAVE services. > > > I agree. > > BTW, you really plan to send CAMs directly over IPv6, without any > transport layer? I thought you would use UDP, which has a "large" > header as well. (found in an "old" post dated back from 4 days ago. > ) > > > At this time, with partners, we ponder the idea of a different CAM if > you wish (not sure whether UDP, or just IP, or 802.11 Data, or 802.11 > QoS Data). This different CAM is interoperable and cheap to > produce. > > CAM over UDP over IPv6 was already produced by others in other > project. I think they didnt bother to standardise it, but it worked > for them. I am tempted to copy from them. > > Alex > > : > > CAM transported in IP may be a smaller packet than CAM transported > > in BTP and GeoNetworking. > > > 2018-02-28 8:07 GMT+01:00 Alexandre Petrescu > > >>: > > Thank you for the message. > > Le 28/02/2018 à 07:08, Katrin Sjöberg a écrit : [...] > > This implies that the current IETF proposal of using IPv6 over DCF > would be impossible to use in Europe. > > > Unless, of course, we suggest modify the ETSI specification to allow > for 802.11 Data headers as well as 802.11 QoS Data headers. > > (there are many reasons to ponder over a major rehaul of ETSI ITS > specifications, starting at the CAM itself, that I could explain > separately). > > If all IPv6 trafffic has to use a common EDCA access category, I > would support John's suggestion from an earlier email to fix IPv6 > traffic to AC_BK. > > > This could be done. On my side I would need to see running code for > it, and then there is need of consensus (could be obvious from your > standpoint). > > As Jêróme pointed out, we use AC_BE for CAMs, > > > Thank you for this message. I understand you have an implementation > of CAM sent with IEEE 802.11 QoSData header. Is it the one from > Unex with Autotalks chipset? > > (the CAM implementations I use are from github.com > and ath9k driver; they dont > generate 802.11 QoSData header, but use 802.11 Data header, hence no > AC_BE). > > and I know the US uses AC_BE for some of their safety messages as > well. > > > I think me too, I have seen BSM messages carried with 802.11 QoSData > headers, field Priority value 2 Spare (Background); I guess that > stands for AC_BK. But I could not figure out what was the software > that implemented it. > > Alex > > > Best regards, Katrin Sjöberg > > > > 2018-02-27 17:50 GMT+01:00 Tony Li > >>>: > > > If someone knows how to generate a QoSData transported IP packet with > linux open source then I am all ears. > > > > This is just a Small Matter Of Programming for anyone with a bit of > kernel hacking experience and driver sources. > > Tony > > _______________________________________________ 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 > > > > > > > > -- Michelle WETTERWALD > > From nobody Wed Feb 28 02:36:30 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 374C112EAF1 for ; Wed, 28 Feb 2018 02:36:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVo0rAxHHQee for ; Wed, 28 Feb 2018 02:36:27 -0800 (PST) Received: from smtp2.eurecom.fr (smtp2.eurecom.fr [193.55.113.211]) by ietfa.amsl.com (Postfix) with ESMTP id 1F634127909 for ; Wed, 28 Feb 2018 02:36:26 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.47,405,1515452400"; d="scan'208";a="7708391" Received: from monza.eurecom.fr ([192.168.106.15]) by drago2i.eurecom.fr with ESMTP; 28 Feb 2018 11:36:25 +0100 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 AF0AB2C6A; Wed, 28 Feb 2018 11:36:25 +0100 (CET) From: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= To: "'Alexandre Petrescu'" , "'Tony Li'" , "'John Kenney'" Cc: "'its'" , =?UTF-8?Q?'Katrin_Sj=C3=B6berg'?= References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <9ada5591-2af3-272d-3bc3-031bf35454c3@gmail.com> <52ADDCC5-5AF1-4657-AE0C-AD9240ED6093@tony.li> <004601d3b061$4adadcd0$e0909670$@eurecom.fr> <78bc7114-a661-9524-e4d8-631910a7c789@gmail.com> <007901d3b069$47453950$d5cfabf0$@eurecom.fr> <7ffac3d6-db35-0538-94f3-743439bf7caa@gmail.com> <00df01d3b070$21cf3610$656da230$@eurecom.fr> In-Reply-To: Date: Wed, 28 Feb 2018 11:36:25 +0100 Organization: EURECOM Message-ID: <014401d3b07f$fbe2db40$f3a891c0$@eurecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQHelLAw/aN7IRfcwiTBG/gKcgHVEwGONDnFAivYBTcB5QRVgwFu9SHuAcUCuOgBh4H86QFt4LrjAn2u9AYCta3nBgHkHtpTAXAyS6sB8uU9CQIXhIbxouD+oUA= Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB - costs 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, 28 Feb 2018 10:36:29 -0000 Hi Alex, The biggest cost I see is the RFC being blocked for being used both in = US and EU, which means hundreds of hours of work by the IETF for = nothing. This should not be underestimated... If a standard cannot be passed because there is no open-source = implementation, well nothing will work...the world is full of closed = source implementation that we need to pay for it (look at 3GPP and the = cellular world...)...I mean you preach to the choir, I am a strong = supporter to open-source implementation, but I am not ready to block a = specification because no open source exist.=20 BR, J=C3=A9r=C3=B4me From nobody Wed Feb 28 02:38:14 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97F3C12EAF4 for ; Wed, 28 Feb 2018 02:38:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5fMI0rCERhX for ; Wed, 28 Feb 2018 02:38:10 -0800 (PST) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BAA5127909 for ; Wed, 28 Feb 2018 02:38:10 -0800 (PST) Received: by mail-yw0-x232.google.com with SMTP id u84so629606ywg.9 for ; Wed, 28 Feb 2018 02:38:10 -0800 (PST) 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=LBkKG7NYnXb4KjF+95zELrzGM6BrcDyXVmAFSRGi3qk=; b=JMG+YylEzFnB2Mqqpmf1BhPB8eT3vH/0490hWIIi0Tl/YMJ8hU/a+IeDWjkMJOgeZc t0c/z1HsJ1BGL7WcIcO6+RMaDO+PKXUOoKn3NNp+HQe0PYZBtLS9D5p+z6/X0BczLIy+ ouwmNb8V+wieDggywXv2pvudJ2GWwrqdtrkX4bEhdZ6K4Vm6ukX4CLTDzMrX+KKVyYr0 58Qke4yYYZ9J6EUziuwOQhkDSnKKY4XqFqQ/fV6I3sJhbeTjhAX0wkBTfg8UWi0UItVG CyDWUyAZNtRH1i73CQ9F7MJJbOjCgr+9xX7BWP5Fmbk7M5l5OvwzFhXMlQIJ347n/lHU 33Hw== 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=LBkKG7NYnXb4KjF+95zELrzGM6BrcDyXVmAFSRGi3qk=; b=sPh+X8l+r//Q5n/DwLiqXLNW/34YW/5RhX/GJ7tx5UcuVH7ME5G9qq4d7P2XsQnODC CKDIeYTvFOWqkZ6NAHWQF7gZXcauieHP12BN3sHNYnSThZKkH3+KFoG8BgZn4JUoL6+j 3hFgyRET/w1BiMZ0bUtjhW1CTgoIOjhJvYQCY8hWAlIuXKT8MYFJLoHou0sPy5XNtyEk UaPOIyrIIHheoHTksDTo/R6Xr/0bmKXYV/w89Klc7DpdsQh/zfSl1qzlh+g61y1tDaGX Kf0l4HkQa23+6RwZ5ugatjC60O2+JZMLUysFG+6VIcdZ9VTkukEM9lW1ifwi0Al0zUfp sCRA== X-Gm-Message-State: APf1xPB8T+XkqfF83cP3GZgDfiB0hMz1JMhk0URnLsOZ9ijGvc5IIskG a2cNgpqWuh4txMz2lIjNQNMJVeJQ51vr24Tl9Iq6gEXj X-Google-Smtp-Source: AH8x226Tzwv+ELZJ90Q8+TtbOuxC2owUTeWDdtHRNfum7hovrtaqX/g+k5GaJLkuwdoZVqtNjcMae5Y+ulAK1i2ih1Q= X-Received: by 10.13.244.70 with SMTP id d67mr11478562ywf.127.1519814289618; Wed, 28 Feb 2018 02:38:09 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a25:b942:0:0:0:0:0 with HTTP; Wed, 28 Feb 2018 02:38:08 -0800 (PST) In-Reply-To: <88030b0f-128a-b185-e9b8-f13b76878a74@gmail.com> References: <6cdc0835-fb4c-133b-77ff-0234cfdd9ef9@fischer-tech.eu> <00eb01d3af1d$7f4e8100$7deb8300$@gmail.com> <6187cb92-5c8f-d08b-dcc2-859652d629d0@gmail.com> <002901d3af20$b966e960$2c34bc20$@eurecom.fr> <002601d3afc4$a10fbb90$e32f32b0$@eurecom.fr> <71309c28-9d7e-d277-a3b0-46d1a3b4042e@gmail.com> <004701d3afd0$63867190$2a9354b0$@eurecom.fr> <461166f2-f3cc-e749-3628-f1d87104200b@gmail.com> <4997BFDE-1B3F-4F17-9742-28F23F082A15@tony.li> <596b8280-af45-aca2-9ea9-b05dce716ff1@gmail.com> <88030b0f-128a-b185-e9b8-f13b76878a74@gmail.com> From: Michelle Wetterwald Date: Wed, 28 Feb 2018 11:38:08 +0100 Message-ID: To: its Content-Type: multipart/alternative; boundary="94eb2c035770db7aff0566435638" Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 28 Feb 2018 10:38:14 -0000 --94eb2c035770db7aff0566435638 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alex, Regarding the interoperability between different implementations, it has been fully validated during numerous plugtests events in EU and US, gathering a large set of different implementations. For the EU ones, the reports are freely available on the ETSI web site. I am sorry to hear that the open source implementation that you are using has some limitations. I remember that one of the participants to the last PlugTest in Livorno (Nov 2016) explained to me he had extended the open source software to use his computer to monitor the traffic exchanged on the 802.11p. So he made his Ath implementation fully interoperable with those from the other vendors. Maybe you can apply similar upgrades to your testing implementations? Again, I disagree with the change you propose in the text of the draft, as it goes against the *existing* EU regulations. Compliance with the modified text would prevent vendors from accessing the EU market. BR, Michelle 2018-02-28 11:09 GMT+01:00 Alexandre Petrescu : > > > Le 28/02/2018 =C3=A0 10:47, Katrin Sj=C3=B6berg a =C3=A9crit : > >> Hi Alexandre, All, >> >> We are mixing apples and pears in this discussion and it is very >> frustrating. On one hand, the discussion is about detailed open source >> software implementations that do not support QoS data with >> how the EU mandate will look like. >> > > EU must take great care when mandating technologies. > > First of all, the QoS data is handled by the chipset covering >> MAC+PHY on top of this LLC resides. >> > > I agree. > > We use ath9k driver and mac80211 module in the linux kernel. > > IPv6 is on top of LLC. >> > > Yes. > > And suddenly the CAM specification, which is residing in the facilities >> layer is discussed. >> > > I agree. Speaking CAM here is a stretch. The stretch comes from my > single possible way (with BSM) to notice the existence of these QoS Data > headers. I should have rather said "QoS Data transported message, e.g. > CAM or BSM". > > When I say I have problems with CAM, and I will post a critique of it, > is with the CAM message encoding, and lack of interoperability of that > CAM. I do not critique the fact that QoS Data transports CAM. > > What is the problem with making EDCA mandatory in this standard? >> > > The problem is the lack of implementations. > > The amendment IEEE 802.11e, which introduced the concept of EDCA, was >> approved in 2005 and it was a unique selling point for WiFi APs in >> the beginning. EDCA has been around for 13 years and this standard >> developed in 2018 for supporting IPv6 in VANETs when using IEEE >> 802.11p wants to use DCF due to some existing implementation... For >> me this is like being thrown back to the stone age. >> > > Sorry, not the intention to throw back to stone age. > > But I need implementation. > > I am working for an OEM >> > > Is OEM implementing QoS Data? > > and I cannot accept that this standard will allow IPv6 traffic over IEEE >> 802.11p using DCF since it might adventure road traffic safety applicati= ons >> that are under development. We want to reduce the number of accidents an= d >> the >> impact of the same by using IEEE 802.11p with EDCA and suddenly >> messages such as CAMs might be starved out because someone is >> transmitting IPv6 traffic using DCF. This is not acceptable and once >> again I want to emphasize that EN 302 663 in Europe requires EDCA, >> which would prohibit this standard to use the 5.9 GHz band. >> > > Hold on, hold on. Excuse me. > > Road traffic safety applications is also a huge worry for designers using > IP packets. > > But, the spectrum is for everyone to coexist and interoperate. > > Alex > > >> Best regards, Katrin >> >> 2018-02-28 10:27 GMT+01:00 Alexandre Petrescu < >> alexandre.petrescu@gmail.com >: >> >> >> >> >> Le 28/02/2018 =C3=A0 09:50, Mie Eur a =C3=A9crit : >> >> Hi Alex, >> >> I fully agree with Katrin and was about to send a similar post, as the >> EDCA queues are used also by ITS-G5 for the DCC, which is mandated by th= e >> new EU regulation. >> >> >> I would really be surprised that EU mandates something that depends on >> closed source, potentially favoring a competitive edge to a particular >> private interest. But I am optimistic: given all the stimulation of ope= n >> source in EU projects I believe EU regulators understand the implication= s >> related to cost, licensing, and interoperability. >> >> Unless you want to rewrite all ETSI standards and related European norms >> in a couple of weeks, >> >> >> In one of these days I will post a critique of the CAM specification. >> >> I would suggest to keep the old text and guarantee openness for using >> the IEEE 802.11-16 standard while complying to local regulations. >> >> >> YEs, we need that. >> >> But the old text says: >> >> "In OCB mode, IPv6 packets MAY be transmitted either as "IEEE 802.11 >> Data" or alternatively as "IEEE 802.11 QoS Data" >> >> >> I implement only the 802.11 Data and my partner(s) use equipment bought >> from Unex that only implements QoS Data. I want our software to >> interoperate. >> >> If the text said just 'Data', then I could direct my partners to the >> open source on the Internet. But in current situation my partners >> direct me to Unex, which is expensive - it has a cost. >> >> I do not agree to continue this situation. >> >> Either the QoSData supporters direct me to an open source implementation >> of QoSData now, or we relegate the QoS discussion for later. >> >> I would also suggest to bring this topic, as well as the handling of >> QoS for IPWAVE, which is an interesting topic, to the re-chartering >> discussion that was proposed by Carlos-Jesus a few weeks ago. The same >> as we did for ND or this nice multicast address that would be reserved f= or >> IPWAVE services. >> >> >> I agree. >> >> BTW, you really plan to send CAMs directly over IPv6, without any >> transport layer? I thought you would use UDP, which has a "large" header= as >> well. (found in an "old" post dated back from 4 days ago. ) >> >> >> At this time, with partners, we ponder the idea of a different CAM if >> you wish (not sure whether UDP, or just IP, or 802.11 Data, or 802.11 >> QoS Data). This different CAM is interoperable and cheap to produce. >> >> CAM over UDP over IPv6 was already produced by others in other project. = I >> think they didnt bother to standardise it, but it worked for them. I am >> tempted to copy from them. >> >> Alex >> >> : >> >> CAM transported in IP may be a smaller packet than CAM transported >> >> in BTP and GeoNetworking. >> >> >> 2018-02-28 8:07 GMT+01:00 Alexandre Petrescu < >> alexandre.petrescu@gmail.com >> > >>>: >> >> Thank you for the message. >> >> Le 28/02/2018 =C3=A0 07:08, Katrin Sj=C3=B6berg a =C3=A9crit : [...] >> >> This implies that the current IETF proposal of using IPv6 over DCF would >> be impossible to use in Europe. >> >> >> Unless, of course, we suggest modify the ETSI specification to allow >> for 802.11 Data headers as well as 802.11 QoS Data headers. >> >> (there are many reasons to ponder over a major rehaul of ETSI ITS >> specifications, starting at the CAM itself, that I could explain >> separately). >> >> If all IPv6 trafffic has to use a common EDCA access category, I would >> support John's suggestion from an earlier email to fix IPv6 traffic to >> AC_BK. >> >> >> This could be done. On my side I would need to see running code for >> it, and then there is need of consensus (could be obvious from your >> standpoint). >> >> As J=C3=AAr=C3=B3me pointed out, we use AC_BE for CAMs, >> >> >> Thank you for this message. I understand you have an implementation >> of CAM sent with IEEE 802.11 QoSData header. Is it the one from >> Unex with Autotalks chipset? >> >> (the CAM implementations I use are from github.com < >> http://github.com> and ath9k driver; they dont generate 802.11 QoSData >> header, but use 802.11 Data header, hence no AC_BE). >> >> and I know the US uses AC_BE for some of their safety messages as well. >> >> >> I think me too, I have seen BSM messages carried with 802.11 QoSData >> headers, field Priority value 2 Spare (Background); I guess that stands = for >> AC_BK. But I could not figure out what was the software that implemente= d >> it. >> >> Alex >> >> >> Best regards, Katrin Sj=C3=B6berg >> >> >> >> 2018-02-27 17:50 GMT+01:00 Tony Li > tony.li@tony.li> > >> > >>>: >> >> >> If someone knows how to generate a QoSData transported IP packet with >> linux open source then I am all ears. >> >> >> >> This is just a Small Matter Of Programming for anyone with a bit of >> kernel hacking experience and driver sources. >> >> Tony >> >> _______________________________________________ its mailing list >> its@ietf.org > its@ietf.org>> > its@ietf.org >> https://www.ietf.org/mailman/l >> istinfo/its < >> https://www.ietf.org/mailman/listinfo/its > listinfo/its>> > https://www.ietf.org/mailman/listinfo/its> > listinfo/its >> >> >> >> >> _______________________________________________ its mailing list >> its@ietf.org > its@ietf.org>> https://www.ietf.org/mailman/listinfo/its < >> https://www.ietf.org/mailman/listinfo/its> > listinfo/its > >> >> >> >> >> -- Michelle WETTERWALD >> >> >> > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > --=20 Michelle Wetterwald michelle.wetterwald@gmail.com --94eb2c035770db7aff0566435638 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alex,

Regarding the inter= operability between different implementations, it has been fully validated = during numerous plugtests events=C2=A0in EU and US, gathering a large set o= f different implementations. For the EU ones, the reports are freely availa= ble on the ETSI=C2=A0web site.

I am sorry to hear = that the open source implementation that you are using has some limitations= . I remember that one of the participants to the last PlugTest in Livorno (= Nov 2016) explained to me he had extended the open source software to use h= is computer=C2=A0to monitor=C2=A0the traffic exchanged on the 802.11p. So h= e made his Ath implementation fully interoperable with those from the other= vendors. Maybe you can apply=C2=A0similar upgrades to your testing impleme= ntations?

Again, I disagree = with the change you propose in the text of the draft, as it=C2=A0goes again= st=C2=A0the *existing* EU regulations.=C2=A0Compliance with the modified te= xt would prevent=C2=A0vendors from accessing the EU market.
=C2=A0
BR,
Michelle

2018-02-28 11:09 GMT+01:00 Alexandre Petrescu <alexandre.petrescu@gmail.com>:

Le 28/02/2018 =C3=A0 10:47, Katrin Sj=C3=B6berg a =C3=A9crit :
Hi Alexandre, All,

We are mixing apples and pears in this discussion and it is very frustratin= g. On one hand, the discussion is about detailed open source software imple= mentations that do not support QoS data with
how the EU mandate will look like.

 EU must take great care when mandating technologies.

First of all, the QoS data is handled by the chipset covering
MAC+PHY on top of this LLC resides.

 I agree.

We use ath9k driver and mac80211 module in the linux kernel.

IPv6 is on top of LLC.

 Yes.

And suddenly the CAM specification, which is residing in the facilities lay= er is discussed.

 I agree.=C2=A0 Speaking CAM here is a stretch.=C2=A0 The stretch comes from= my
single possible way (with BSM) to notice the existence of these QoS Data headers.=C2=A0 I should have rather said "QoS Data transported message= , e.g.
CAM or BSM".

When I say I have problems with CAM, and I will post a critique of it,
is with the CAM message encoding, and lack of interoperability of that
CAM.=C2=A0 I do not critique the fact that QoS Data transports CAM.
What is the problem with making EDCA mandatory in this standard?

 The problem is the lack of implementations.

The amendment IEEE 802.11e, which introduced the concept of EDCA, was
approved in 2005 and it was a unique selling point for WiFi APs in
the beginning. EDCA has been around for 13 years and this standard
developed in 2018 for supporting IPv6 in VANETs when using IEEE
802.11p wants to use DCF due to some existing implementation... For
me this is like being thrown back to the stone age.

 Sorry, not the intention to throw back to stone age.

But I need implementation.

I am working for an OEM

 Is OEM implementing QoS Data?

and I cannot accept that this standard will allow IPv6 traffic over IEEE 80= 2.11p using DCF since it might adventure road traffic safety applications t= hat are under development. We want to reduce the number of accidents and th= e
impact of the same by using IEEE 802.11p with EDCA and suddenly
messages such as CAMs might be starved out because someone is
transmitting IPv6 traffic using DCF. This is not acceptable and once
again I want to emphasize that EN 302 663 in Europe requires EDCA,
which would prohibit this standard to use the 5.9 GHz band.

 Hold on, hold on.=C2=A0 Excuse me.

Road traffic safety applications is also a huge worry for designers using I= P packets.

But, the spectrum is for everyone to coexist and interoperate.

Alex


Best regards, Katrin

2018-02-28 10:27 GMT+01:00 Alexandre Petrescu <alexandre.petrescu@gmail.com &= lt;mailto:alexandre.petrescu@gmail.com>>:




Le 28/02/2018 =C3=A0 09:50, Mie Eur a =C3=A9crit :

Hi Alex,

I fully agree with Katrin and was about to send a similar post, as the EDCA= queues are used also by ITS-G5 for the DCC, which is mandated by the new E= U regulation.


I would really be surprised that EU mandates something that depends on clos= ed source, potentially favoring a competitive edge to a particular private = interest.=C2=A0 But I am optimistic: given all the stimulation of open sour= ce in EU projects I believe EU regulators understand the implications relat= ed to cost, licensing, and interoperability.

Unless you want to rewrite all ETSI standards and related European norms in= a couple of=C2=A0 weeks,


In one of these days I will post a critique of the CAM specification.

I would suggest to keep the old text and guarantee openness for using
the IEEE 802.11-16 standard while complying to local regulations.


YEs, we need that.

But the old text says:

"In OCB mode, IPv6 packets MAY be transmitted either as "IEEE 802= .11
=C2=A0Data" or alternatively as "IEEE 802.11 QoS Data"


I implement only the 802.11 Data and my partner(s) use equipment bought fro= m Unex that only implements QoS Data.=C2=A0 I want our software to interope= rate.

If the text said just 'Data', then I could direct my partners to th= e
=C2=A0open source on the Internet.=C2=A0 But in current situation my partne= rs direct me to Unex, which is expensive - it has a cost.

I do not agree to continue this situation.

Either the QoSData supporters direct me to an open source implementation of= QoSData now, or we relegate the QoS discussion for later.

I would also suggest to bring this topic, as well as the handling of
=C2=A0QoS for IPWAVE, which is an interesting topic, to the re-chartering =C2=A0discussion that was proposed by Carlos-Jesus a few weeks ago. The sam= e as we did for ND or this nice multicast address that would be reserved fo= r IPWAVE services.


I agree.

BTW, you really plan to send CAMs directly over IPv6, without any transport= layer? I thought you would use UDP, which has a "large" header a= s well. (found in an "old" post dated back from 4 days ago. )


At this time, with partners, we ponder the idea of a different CAM if
you wish (not sure whether UDP, or just IP, or 802.11 Data, or 802.11
QoS Data).=C2=A0 This different CAM is interoperable and cheap to produce.<= br>
CAM over UDP over IPv6 was already produced by others in other project. I t= hink they didnt bother to standardise it, but it worked for them.=C2=A0 I a= m tempted to copy from them.

Alex

:

CAM transported in IP may be a smaller packet than CAM transported

in BTP and GeoNetworking.


2018-02-28 8:07 GMT+01:00 Alexandre Petrescu <alexandre.petrescu@gmail.com &l= t;mailto:= alexandre.petrescu@gmail.com> <mailto:alexandre.petrescu@gmail.c= om <mailto:alexandre.petrescu@gmail.com>>>:

Thank you for the message.

Le 28/02/2018 =C3=A0 07:08, Katrin Sj=C3=B6berg a =C3=A9crit : [...]

This implies that the current IETF proposal of using IPv6 over DCF would be= impossible to use in Europe.


Unless, of course, we suggest modify the ETSI specification to allow
=C2=A0for 802.11 Data headers as well as 802.11 QoS Data headers.

(there are many reasons to ponder over a major rehaul of ETSI ITS specifica= tions, starting at the CAM itself, that I could explain separately).

If all IPv6 trafffic has to use a common EDCA access category, I would supp= ort John's suggestion from an earlier email to fix IPv6 traffic to AC_B= K.


This could be done.=C2=A0 On my side I would need to see running code for =C2=A0it, and then there is need of consensus (could be obvious from your =C2=A0standpoint).

As J=C3=AAr=C3=B3me pointed out, we use AC_BE for CAMs,


Thank you for this message.=C2=A0 I understand you have an implementation =C2=A0of CAM sent with IEEE 802.11 QoSData header.=C2=A0 Is it the one from=
Unex with Autotalks chipset?

 (the CAM implementations I use are from github.com <http://github.com> <http://git= hub.com> and ath9k driver; they dont generate 802.11 QoSData header,= but use 802.11 Data header, hence no AC_BE).

and I know the US uses AC_BE for some of their safety messages as well.


I think me too, I have seen BSM messages carried with 802.11 QoSData header= s, field Priority value 2 Spare (Background); I guess that stands for AC_BK= .=C2=A0 But I could not figure out what was the software that implemented i= t.

Alex


Best regards, Katrin Sj=C3=B6berg



 2018-02-27 17:50 GMT+01:00 Tony Li <tony.li@tony.li <mailto:tony.li@tony.li> <mailto:tony.li@tony.li <mailto:tony.li@tony.li>>= <mailto:tony.li@to= ny.li <mailto:t= ony.li@tony.li> <mailto:tony.li@tony.li <mailto:tony.li@tony.li>>>>:


If someone knows how to generate a QoSData transported IP packet with
linux open source then I am all ears.



This is just a Small Matter Of Programming for anyone with a bit of kernel = hacking experience and driver sources.

Tony

 _______________________________________________ its mailing list its@ietf.org <mailto:its@ietf.org> <ma= ilto:its@ietf.org <= ;mailto:its@ietf.org&= gt;> <mailto:its@ie= tf.org <mailto:its= @ietf.org> <mailto:its@ietf.org <mailto:its@ietf.org>>> https://www.ietf.org/ma= ilman/listinfo/its <https://www.ietf.org/mailma= n/listinfo/its> <https://www.ietf.org/mailma= n/listinfo/its <https://www.ietf.org/mailman/listinfo/its>> <https://www.ietf.org/mailma= n/listinfo/its <https://www.ietf.org/mailman/listinfo/its> <https://www.ietf.org/mailman/listinfo/its <https://www.ietf.org/mailman/l= istinfo/its>>>



_______________________________________________ its mailing list its@ietf.org <mailto:its@ietf.org> <ma= ilto:its@ietf.org <= ;mailto:its@ietf.org&= gt;> https://www.ietf.org/mailman/listinfo/its = <https://www.ietf.org/mailman/listinfo/its> = <https://www.ietf.org/mailman/listinfo/its <= https://www.ietf.org/mailman/listinfo/its>><= br>



-- Michelle WETTERWALD



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



--
Michelle W= etterwald
--94eb2c035770db7aff0566435638-- From nobody Wed Feb 28 03:16:05 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23577128D2E for ; Wed, 28 Feb 2018 03:16:04 -0800 (PST) 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 RCkXhCdXbZ5w for ; Wed, 28 Feb 2018 03:16:02 -0800 (PST) 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 E443C1200F1 for ; Wed, 28 Feb 2018 03:16:01 -0800 (PST) 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 w1SBFweu156680; Wed, 28 Feb 2018 12:15:58 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B17C6205803; Wed, 28 Feb 2018 12:15:58 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9F2122057FF; Wed, 28 Feb 2018 12:15:58 +0100 (CET) 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 w1SBFwjx023259; Wed, 28 Feb 2018 12:15:58 +0100 To: "Bless, Roland (TM)" , =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , "=?UTF-8?Q?'Fran=c3=a7ois_Simon'?=" , its@ietf.org References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <006301d3ace3$25f9d500$71ed7f00$@eurecom.fr> <007901d3aee3$a9985ba0$fcc912e0$@eurecom.fr> <00f801d3af1d$f20ce4c0$d626ae40$@gmail.com> <002b01d3af21$6e779a70$4b66cf50$@eurecom.fr> <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> From: Alexandre Petrescu Message-ID: Date: Wed, 28 Feb 2018 12:15:58 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.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] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB - implementations 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, 28 Feb 2018 11:16:04 -0000 Le 28/02/2018 à 11:04, Bless, Roland (TM) a écrit : [...] > However, more detailed guidance provides https://tools.ietf.org/html/rfc7127 > > A Proposed Standard specification is stable, has resolved known > design choices, has received significant community review, and > appears to enjoy enough community interest to be considered valuable. > > [...] > > The IESG may require implementation and/or operational experience > prior to granting Proposed Standard status to a specification that > materially affects the core Internet protocols or that specifies > behavior that may have significant operational impact on the > Internet. In my humble oppinion, this draft IPv6-over-OCB -19: - has not resolved known design choices. (Data vs QoSData) - has received significant review - appears to enjoy community interest I am not IESG so I dont know what to think about what IESG will request. From past experience in other RFCs I learned it is always good to have interoprable implementations before going to IESG. > > So for Internet Standard: > > A specification for which significant implementation and successful > operational experience has been obtained may be elevated to the > Internet Standard level. > >> Because some drafts get submitted, some become RFCs, and some never get >> the success one expects them to (read: no implementation). > > Even if you have implementations it does not mean that it is widely > used. So implementations are hardly a measure for success, but running > code is always good to have to show that it's viable. I was involved in > a WG where people had strong objections and found the protocols too > complex. This really wasn't the case as we had several implementations > done by students...however, the opponents just ignored the running code... > >>> RFC8325 is pretty new, but I expect that some recent APs from >>> a larger vendor will support this, since they did the proposal. >> >> Thanks for the clarification. >> >> Since RFC8325 is on the Standards Track, I believe there should be more >> than just one vendor supporting it (otherwise it were EXPERIMENTAL or >> INFORMATIONAL).  Maybe that vendor proposed an implementation as open >> source, and agreed somehow by some non-that-vendor implementers. > > No, it's not how it works, see above. Proposed Standard is usually > considered to be good enough to get interoperable implementations. > Internet-Drafts with available (or even open) implementations are often > considered as being better than those without. So running code is > usually considered being a plus for I-Ds or PS documents, but it's > normally not required unless solicited by the IESG. You think we dont need two different implementations to interoperate before going to IESG? Alex From nobody Wed Feb 28 03:23:11 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80FE512EB12 for ; Wed, 28 Feb 2018 03:22:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLYRvhdqMM7o for ; Wed, 28 Feb 2018 03:22:56 -0800 (PST) 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 B32CC1200F1 for ; Wed, 28 Feb 2018 03:22:55 -0800 (PST) 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 w1SBMrQS008110; Wed, 28 Feb 2018 12:22:53 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A48CC2007FE; Wed, 28 Feb 2018 12:22:53 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 95EF62057E9; Wed, 28 Feb 2018 12:22:53 +0100 (CET) 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 w1SBMrs4001203; Wed, 28 Feb 2018 12:22:53 +0100 From: Alexandre PETRESCU To: Michelle Wetterwald Cc: its References: <00eb01d3af1d$7f4e8100$7deb8300$@gmail.com> <6187cb92-5c8f-d08b-dcc2-859652d629d0@gmail.com> <002901d3af20$b966e960$2c34bc20$@eurecom.fr> <002601d3afc4$a10fbb90$e32f32b0$@eurecom.fr> <71309c28-9d7e-d277-a3b0-46d1a3b4042e@gmail.com> <004701d3afd0$63867190$2a9354b0$@eurecom.fr> <461166f2-f3cc-e749-3628-f1d87104200b@gmail.com> <4997BFDE-1B3F-4F17-9742-28F23F082A15@tony.li> <596b8280-af45-aca2-9ea9-b05dce716ff1@gmail.com> <88030b0f-128a-b185-e9b8-f13b76878a74@gmail.com> Organization: CEA Message-ID: Date: Wed, 28 Feb 2018 12:22:52 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020308020201090204070002" Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 28 Feb 2018 11:22:59 -0000 This is a cryptographically signed message in MIME format. --------------ms020308020201090204070002 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: quoted-printable [trimmed the CC because mailer problems] Le 28/02/2018 =C3=A0 11:34, Michelle Wetterwald a =C3=A9crit=C2=A0: > Hi Alex, >=20 > Regarding the interoperability between different implementations, it ha= s=20 > been fully validated during numerous plugtests events=C2=A0in EU and US= ,=20 > gathering a large set of different implementations. For the EU ones, th= e=20 > reports are freely available on the ETSI=C2=A0web site. I am using the wireshark dissectors on the ETSI web site. I can tell they show lack of interoperability: several CAM messages from = several stacks are not understood by these wireshark dissectors. The ETSI wireshark dissectors have another problem themselves: they are=20 not integrated in the main wireshark software. It's just ETSI's point=20 of view. > I am sorry to hear that the open source implementation that you are=20 > using has some limitations. I remember that one of the participants to = > the last PlugTest in Livorno (Nov 2016) explained to me he had extended= =20 > the open source software to use his computer=C2=A0to monitor=C2=A0the t= raffic=20 > exchanged on the 802.11p. So he made his Ath implementation fully=20 > interoperable with those from the other vendors. Maybe you can=20 > apply=C2=A0similar upgrades to your testing implementations? Can you tell me who is that participant so I can contact? > Again, I disagree with the change you propose in the text of the draft,= =20 > as it=C2=A0goes against=C2=A0the *existing* EU regulations.=C2=A0Compli= ance with the=20 > modified text would prevent=C2=A0vendors from accessing the EU market. Accessing EU market is a good thing, but customer lock in may not be=20 that good. Alex > BR, > Michelle >=20 >=20 > 2018-02-28 11:09 GMT+01:00 Alexandre Petrescu=20 > >: >=20 >=20 >=20 > Le 28/02/2018 =C3=A0 10:47, Katrin Sj=C3=B6berg a =C3=A9crit : >=20 > Hi Alexandre, All, >=20 > We are mixing apples and pears in this discussion and it is ver= y > frustrating. On one hand, the discussion is about detailed open= > source software implementations that do not support QoS data wi= th > how the EU mandate will look like. >=20 >=20 > EU must take great care when mandating technologies. >=20 > First of all, the QoS data is handled by the chipset covering > MAC+PHY on top of this LLC resides. >=20 >=20 > I agree. >=20 > We use ath9k driver and mac80211 module in the linux kernel. >=20 > IPv6 is on top of LLC. >=20 >=20 > Yes. >=20 > And suddenly the CAM specification, which is residing in the > facilities layer is discussed. >=20 >=20 > I agree.=C2=A0 Speaking CAM here is a stretch.=C2=A0 The stretch co= mes from my > single possible way (with BSM) to notice the existence of these QoS= Data > headers.=C2=A0 I should have rather said "QoS Data transported mess= age, e.g. > CAM or BSM". >=20 > When I say I have problems with CAM, and I will post a critique of = it, > is with the CAM message encoding, and lack of interoperability of t= hat > CAM.=C2=A0 I do not critique the fact that QoS Data transports CAM.= >=20 > What is the problem with making EDCA mandatory in this standard= ? >=20 >=20 > The problem is the lack of implementations. >=20 > The amendment IEEE 802.11e, which introduced the concept of > EDCA, was > approved in 2005 and it was a unique selling point for WiFi APs= in > the beginning. EDCA has been around for 13 years and this stand= ard > developed in 2018 for supporting IPv6 in VANETs when using IEEE= > 802.11p wants to use DCF due to some existing implementation...= For > me this is like being thrown back to the stone age. >=20 >=20 > Sorry, not the intention to throw back to stone age. >=20 > But I need implementation. >=20 > I am working for an OEM >=20 >=20 > Is OEM implementing QoS Data? >=20 > and I cannot accept that this standard will allow IPv6 traffic > over IEEE 802.11p using DCF since it might adventure road > traffic safety applications that are under development. We want= > to reduce the number of accidents and the > impact of the same by using IEEE 802.11p with EDCA and suddenly= > messages such as CAMs might be starved out because someone is > transmitting IPv6 traffic using DCF. This is not acceptable and= once > again I want to emphasize that EN 302 663 in Europe requires ED= CA, > which would prohibit this standard to use the 5.9 GHz band. >=20 >=20 > Hold on, hold on.=C2=A0 Excuse me. >=20 > Road traffic safety applications is also a huge worry for designers= > using IP packets. >=20 > But, the spectrum is for everyone to coexist and interoperate. >=20 > Alex >=20 >=20 > Best regards, Katrin >=20 > 2018-02-28 10:27 GMT+01:00 Alexandre Petrescu > > >>: >=20 >=20 >=20 >=20 > Le 28/02/2018 =C3=A0 09:50, Mie Eur a =C3=A9crit : >=20 > Hi Alex, >=20 > I fully agree with Katrin and was about to send a similar post,= > as the EDCA queues are used also by ITS-G5 for the DCC, which i= s > mandated by the new EU regulation. >=20 >=20 > I would really be surprised that EU mandates something that > depends on closed source, potentially favoring a competitive > edge to a particular private interest.=C2=A0 But I am optimisti= c: > given all the stimulation of open source in EU projects I > believe EU regulators understand the implications related to > cost, licensing, and interoperability. >=20 > Unless you want to rewrite all ETSI standards and related > European norms in a couple of=C2=A0 weeks, >=20 >=20 > In one of these days I will post a critique of the CAM > specification. >=20 > I would suggest to keep the old text and guarantee openness for= > using > the IEEE 802.11-16 standard while complying to local regulation= s. >=20 >=20 > YEs, we need that. >=20 > But the old text says: >=20 > "In OCB mode, IPv6 packets MAY be transmitted either as "IEEE 8= 02.11 > =C2=A0Data" or alternatively as "IEEE 802.11 QoS Data" >=20 >=20 > I implement only the 802.11 Data and my partner(s) use equipmen= t > bought from Unex that only implements QoS Data.=C2=A0 I want ou= r > software to interoperate. >=20 > If the text said just 'Data', then I could direct my partners t= o the > =C2=A0open source on the Internet.=C2=A0 But in current situat= ion my > partners direct me to Unex, which is expensive - it has a cost.= >=20 > I do not agree to continue this situation. >=20 > Either the QoSData supporters direct me to an open source > implementation of QoSData now, or we relegate the QoS discussio= n > for later. >=20 > I would also suggest to bring this topic, as well as the handli= ng of > =C2=A0QoS for IPWAVE, which is an interesting topic, to the > re-chartering > =C2=A0discussion that was proposed by Carlos-Jesus a few weeks= ago. > The same as we did for ND or this nice multicast address that > would be reserved for IPWAVE services. >=20 >=20 > I agree. >=20 > BTW, you really plan to send CAMs directly over IPv6, without > any transport layer? I thought you would use UDP, which has a > "large" header as well. (found in an "old" post dated back from= > 4 days ago. ) >=20 >=20 > At this time, with partners, we ponder the idea of a different > CAM if > you wish (not sure whether UDP, or just IP, or 802.11 Data, or > 802.11 > QoS Data).=C2=A0 This different CAM is interoperable and cheap = to > produce. >=20 > CAM over UDP over IPv6 was already produced by others in other > project. I think they didnt bother to standardise it, but it > worked for them.=C2=A0 I am tempted to copy from them. >=20 > Alex >=20 > : >=20 > CAM transported in IP may be a smaller packet than CAM transpor= ted >=20 > in BTP and GeoNetworking. >=20 >=20 > 2018-02-28 8:07 GMT+01:00 Alexandre Petrescu > > > > > >>>: >=20 > Thank you for the message. >=20 > Le 28/02/2018 =C3=A0 07:08, Katrin Sj=C3=B6berg a =C3=A9crit : = [...] >=20 > This implies that the current IETF proposal of using IPv6 over > DCF would be impossible to use in Europe. >=20 >=20 > Unless, of course, we suggest modify the ETSI specification to = allow > =C2=A0for 802.11 Data headers as well as 802.11 QoS Data heade= rs. >=20 > (there are many reasons to ponder over a major rehaul of ETSI > ITS specifications, starting at the CAM itself, that I could > explain separately). >=20 > If all IPv6 trafffic has to use a common EDCA access category, = I > would support John's suggestion from an earlier email to fix > IPv6 traffic to AC_BK. >=20 >=20 > This could be done.=C2=A0 On my side I would need to see runnin= g code for > =C2=A0it, and then there is need of consensus (could be obviou= s from > your > =C2=A0standpoint). >=20 > As J=C3=AAr=C3=B3me pointed out, we use AC_BE for CAMs, >=20 >=20 > Thank you for this message.=C2=A0 I understand you have an impl= ementation > =C2=A0of CAM sent with IEEE 802.11 QoSData header.=C2=A0 Is it= the one from > Unex with Autotalks chipset? >=20 > (the CAM implementations I use are from github.com > and= > ath9k driver; they dont generate 802.11 QoSData header, but use= > 802.11 Data header, hence no AC_BE). >=20 > and I know the US uses AC_BE for some of their safety messages > as well. >=20 >=20 > I think me too, I have seen BSM messages carried with 802.11 > QoSData headers, field Priority value 2 Spare (Background); I > guess that stands for AC_BK.=C2=A0 But I could not figure out w= hat > was the software that implemented it. >=20 > Alex >=20 >=20 > Best regards, Katrin Sj=C3=B6berg >=20 >=20 >=20 > 2018-02-27 17:50 GMT+01:00 Tony Li > >> > >>>>: >=20 >=20 > If someone knows how to generate a QoSData transported IP packe= t > with > linux open source then I am all ears. >=20 >=20 >=20 > This is just a Small Matter Of Programming for anyone with a bi= t > of kernel hacking experience and driver sources. >=20 > Tony >=20 > _______________________________________________ its mailing lis= t > its@ietf.org > >> > >>> > https://www.ietf.org/mailman/listinfo/its > > > > > >> > > > > > >>> >=20 >=20 >=20 > _______________________________________________ its mailing lis= t > its@ietf.org > >> > https://www.ietf.org/mailman/listinfo/its > > > > > >> >=20 >=20 >=20 >=20 > -- Michelle WETTERWALD >=20 >=20 >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > >=20 >=20 >=20 >=20 > --=20 > Michelle Wetterwald > michelle.wetterwald@gmail.com --------------ms020308020201090204070002 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 C2AwggWCMIIEaqADAgECAgIYEjANBgkqhkiG9w0BAQsFADA9MQswCQYDVQQGEwJGUjEMMAoG A1UECgwDQ0VBMSAwHgYDVQQDDBdDRUEgQUMgVXRpbGlzYXRldXIgMjAzMTAeFw0xNzExMjcx MTUzMThaFw0yMDExMjcxMTUzMThaMFUxCzAJBgNVBAYTAkZSMQwwCgYDVQQKDANjZWExFDAS BgNVBAsMC1V0aWxpc2F0ZXVyMSIwIAYDVQQDDBlQRVRSRVNDVSBBbGV4YW5kcmUgMjIyMDQw MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxflZNm4uFO1gfpGFsdm8+ijK5FnS fr24rrT8KW0oz8cV8u+UZ55M/bqidvqSXGGz3C480T6DZsfXoTsvqD5ZLE+F8II6J2g5NU8J mKX95WafZuQo8DC2EnkDu2jH0kU58PGyJqzlQ1ThJw+E90C4yg55q5ekRRv13L7W4D38+eO6 2LLQyplKiyjXJRFnrYPCQWKdmaoa3+gXm88N0z9SH1VnKDB7nN0WKcgkB8xFFW9ShkDriTj4 WOtBlX5I49L6nc2f5jgRR7ur63vWwWV57guJDYgdbciTIMsoanyOMkblfZko71HlcYOQcext cIzx7W14tLdo5Lbk5sbTLTPCUwIDAQABo4ICcjCCAm4wHQYDVR0OBBYEFJiCut4KQg9+Gt1J iu2nte1qatj0MB8GA1UdIwQYMBaAFOEcbJodbegbsvFP/cZ0LCdXBYhzMIHIBgNVHSAEgcAw gb0wgboGCisGAQQB4GABBgcwgaswJQYIKwYBBQUHAgEWGWh0dHA6Ly93d3ctaWdjLmNlYS5m ci9wYy8wgYEGCCsGAQUFBwICMHUwDRYDQ0VBMAYCAQICAQAaZFZvdXMgZGV2ZXogYWNjZXB0 ZXIgbGEgcG9saXRpcXVlIGRlIGNlcnRpZmljYXRpb24gYXZhbnQgZCd1dGlsaXNlciBjZSBj ZXJ0aWZpY2F0LCBjZi4gd3d3LWlnYy5jZWEuZnIwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAkBgNVHREEHTAbgRlhbGV4YW5kcmUucGV0cmVzY3VAY2VhLmZyMFEGA1Ud HwRKMEgwRqBEoEKGQGh0dHA6Ly9jcmwtYWMtdXRpbGlzYXRldXIuY2VhLmZyL2NybC9jZWFf YWNfdXRpbGlzYXRldXJfMjAzMS5jcmwwcwYJYIZIAYb4QgENBGYWZFZvdXMgZGV2ZXogYWNj ZXB0ZXIgbGEgcG9saXRpcXVlIGRlIGNlcnRpZmljYXRpb24gYXZhbnQgZCd1dGlsaXNlciBj ZSBjZXJ0aWZpY2F0LCBjZi4gd3d3LWlnYy5jZWEuZnIwUAYIKwYBBQUHAQEERDBCMEAGCCsG AQUFBzAChjRodHRwOi8vd3d3LWlnYy5jZWEuZnIvYWMvY2VhX2FjX3V0aWxpc2F0ZXVyXzIw MzEuY2VyMA0GCSqGSIb3DQEBCwUAA4IBAQC77Z707Ko1uZGK3utBHUQUUyTD4pRjmFxFozU2 kwdk6a8hdHTaaRqjPSUIbfeoZVpZCynd12VynalWcoXM40Bf+bhMN3pAavULka7+oAEQyYuI 7OQ8dE/t3R43Ai8dx0npk+ziPQrlD7tAgMsK8Qd+V7ZhUI0A1ANJXWzZ7DYV6jR4t9nwxlsk Kll2PaD+hTIiP86YVsiHMiu0ZhRGrYJf/U1myMQc28b4LdTofpwh22z8DLHlFoGjGipwYbpb oFn998AOsc2fvujB0Y+AahlKK8lecqOTXJNQaRUrE1dl/n2Xu8GK3KIRtcoo7QTDOTzx/BiN 5EC8XdsqNMRXmc1GMIIF1jCCA76gAwIBAgIBCTANBgkqhkiG9w0BAQsFADBeMQswCQYDVQQG EwJGUjEMMAoGA1UECgwDQ0VBMRcwFQYDVQQLDA4wMDAyIDc3NTY4NTAxOTELMAkGA1UECwwC QUMxGzAZBgNVBAMMEkNFQSBBQyBSYWNpbmUgMjA0MTAeFw0xNjA0MTkwNzM0NTNaFw0zMTA0 MTYwNzM0NTNaMD0xCzAJBgNVBAYTAkZSMQwwCgYDVQQKDANDRUExIDAeBgNVBAMMF0NFQSBB QyBVdGlsaXNhdGV1ciAyMDMxMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvWDF ixM71KL9p38YSLTYgXRTceZWAD0RSg7NylBGPXNHYbceuGKDhRIeX58FIi+JiVFFejFI6jpE impm3MgsXQ5O08clieLLBNCjVzpAMPTO5lXuz0j28ey5AVPwhEw7ngUCtmHaWh8v1eY6xrLV C/porFjHycFbd4oj6QLfyghoo/RXWglYPNjilkCBrRe+jKxM3QYYVD6rouvGrF58SlpGCfwX FA88OcYC24kH8YOOYvh8Ld/p+ty7QUiDq53YmVZ5iDUc3pt3r9pN61zJ83FPEhZbC8+KHDTb D0TXaot2No4u8wk0s0jBpicVN4hxfS+LiFcTsFmsorDW6L7GIwIDAQABo4IBvjCCAbowDwYD VR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQU4Rxsmh1t6Buy8U/9xnQsJ1cFiHMwHwYDVR0jBBgw FoAUoBGJ+Jq/poSxKQc3U0Htl5VCex0wgcgGA1UdIASBwDCBvTCBugYKKwYBBAHgYAEGBzCB qzAlBggrBgEFBQcCARYZaHR0cDovL3d3dy1pZ2MuY2VhLmZyL3BjLzCBgQYIKwYBBQUHAgIw dTANFgNDRUEwBgIBAgIBABpkVm91cyBkZXZleiBhY2NlcHRlciBsYSBwb2xpdGlxdWUgZGUg Y2VydGlmaWNhdGlvbiBhdmFudCBkJ3V0aWxpc2VyIGNlIGNlcnRpZmljYXQsIGNmLiB3d3ct aWdjLmNlYS5mcjAOBgNVHQ8BAf8EBAMCAQYwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2Ny bC1hYy1yYWNpbmUuY2VhLmZyL2NybC9hYy1yYWNpbmUtMjA0MS5jcmwwRwYIKwYBBQUHAQEE OzA5MDcGCCsGAQUFBzAChitodHRwOi8vd3d3LWlnYy5jZWEuZnIvYWMvYWMtcmFjaW5lLTIw NDEuY2VyMA0GCSqGSIb3DQEBCwUAA4ICAQALtUqrZEfol/oEtIOlM3SaHCPHblVt8TdY88IB 3qCpg5lJ8rWU7g8jAsc0moYYor0hrvb17XjXECYL76MOJBCQYEKfWnkTYqAyMTsKee+kK8Xw 5P8wzPPjXA3tUvRm8oHEGYcSfLEzdj+UT+F+E4MnkV1nUOCEJq2Krx+lu1IJQJRCbjUQF+ES ICwTDQE7FHzGGKVsGOEjkbYhDS/+4r5GPbc983y5d94S0ISYmM1klOSeRNGelcnl0fJbH0zs 1y8+YJWg3gWL1j7aNo+sQQCrPrYQnmufAm3HQr42+u0AbFvOX5XKwF1YAx7XpJWuUGeXkjqx 8xIWisShEc/S+Gm4mdKcUgym5C7gkA0nzbmBIJI3iSLRqk/m2Re7R5vC3fF3uyfT9mGeAnNa E9b7ZkBzhrSfFToylbvqnAYvxVcYFCE1XhVMHxKvRiiW9L/u9vHuAbTRaXBFzObrXF6UohLR XNqJKKaPYkRLgrVm6b303Ogp50u6DiSgvI4Dh7x9K9IqpJ/+csqdXpoVdhQjhcA5JZRNrv3q 0zVf/Q93GT3VHOgaeMkEa9Sn30x4GmZfuNon/zSagJZkLO72K3wa6XQbGf8MZP/QtSMGPzrN eVUgp4H6l9hcQINVHmimTrcZa7/22K0FD56epY/OqAXwIWOb9i+jdDIoW5c5pW+/BDDasTGC AvMwggLvAgEBMEMwPTELMAkGA1UEBhMCRlIxDDAKBgNVBAoMA0NFQTEgMB4GA1UEAwwXQ0VB IEFDIFV0aWxpc2F0ZXVyIDIwMzECAhgSMA0GCWCGSAFlAwQCAQUAoIIBgTAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODAyMjgxMTIyNTJaMC8GCSqGSIb3 DQEJBDEiBCDMQzkc6iTC6GNGBWzW+LGSlr/lCAfUPDizELTxlYwKmzBSBgkrBgEEAYI3EAQx RTBDMD0xCzAJBgNVBAYTAkZSMQwwCgYDVQQKDANDRUExIDAeBgNVBAMMF0NFQSBBQyBVdGls aXNhdGV1ciAyMDMxAgIYEjBUBgsqhkiG9w0BCRACCzFFoEMwPTELMAkGA1UEBhMCRlIxDDAK BgNVBAoMA0NFQTEgMB4GA1UEAwwXQ0VBIEFDIFV0aWxpc2F0ZXVyIDIwMzECAhgSMGwGCSqG SIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJ KoZIhvcNAQEBBQAEggEAOiME3DQ3M048zEoGirHsJjgesxc0xjN6OMjhds/KJp0wbXRdSP+V NLAz/nH8iY4hSOuEeMH4bbTiuChOUcXAwwxQTtC1KIZzixZ5WpnZsV+vwK7WCvzJdkmKQ345 0mM6NshIuN+lwAWI4tytrzNmCkuWAmWXD1QKIPdXFeCXQWQ7es3jiYQ5vRdLlI1lAZktbpRw tpF+b3lJHs06LYmK8PKQB1wXH6FbSYH0kvBUmQ2U72QzjYmJrIjIR8RC8s6ItK32YDplNnhT gmdI7VgPQ1creRH2aqnOuWzIwiL43uCnfNjHKJMVh52ZNbt4mHELmhppH0LLjUWLlz9YTUv0 XQAAAAAAAA== --------------ms020308020201090204070002-- From nobody Wed Feb 28 03:24:30 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8830612EB04 for ; Wed, 28 Feb 2018 03:24:28 -0800 (PST) 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 g7EQfyjcU12N for ; Wed, 28 Feb 2018 03:24:27 -0800 (PST) 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 209D012EB07 for ; Wed, 28 Feb 2018 03:24:12 -0800 (PST) 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 w1SBOANH008431; Wed, 28 Feb 2018 12:24:11 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E7AA42033B7; Wed, 28 Feb 2018 12:24:10 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id D3248200B42; Wed, 28 Feb 2018 12:24:10 +0100 (CET) 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 w1SBOAI7004198; Wed, 28 Feb 2018 12:24:10 +0100 To: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , "'Tony Li'" , "'John Kenney'" Cc: "'its'" , "=?UTF-8?Q?'Katrin_Sj=c3=b6berg'?=" References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <9ada5591-2af3-272d-3bc3-031bf35454c3@gmail.com> <52ADDCC5-5AF1-4657-AE0C-AD9240ED6093@tony.li> <004601d3b061$4adadcd0$e0909670$@eurecom.fr> <78bc7114-a661-9524-e4d8-631910a7c789@gmail.com> <007901d3b069$47453950$d5cfabf0$@eurecom.fr> <7ffac3d6-db35-0538-94f3-743439bf7caa@gmail.com> <00df01d3b070$21cf3610$656da230$@eurecom.fr> <014401d3b07f$fbe2db40$f3a891c0$@eurecom.fr> From: Alexandre Petrescu Message-ID: <37dadd16-51b8-36a0-cb68-2da27983bf70@gmail.com> Date: Wed, 28 Feb 2018 12:24:10 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <014401d3b07f$fbe2db40$f3a891c0$@eurecom.fr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB - costs 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, 28 Feb 2018 11:24:28 -0000 Le 28/02/2018 à 11:36, Jérôme Härri a écrit : > Hi Alex, > > The biggest cost I see is the RFC being blocked for being used both > in US and EU, which means hundreds of hours of work by the IETF for > nothing. This should not be underestimated... > > If a standard cannot be passed because there is no open-source > implementation, well nothing will work...the world is full of closed > source implementation that we need to pay for it (look at 3GPP and > the cellular world...)...I mean you preach to the choir, I am a > strong supporter to open-source implementation, but I am not ready to > block a specification because no open source exist. This is why, maybe, it is just good to free away the part that disturbs (Ethernet Adaptation Layer with the QoS doubt). Alex > > BR, > > Jérôme > > From nobody Wed Feb 28 04:07:37 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27EE612785F for ; Wed, 28 Feb 2018 04:07:36 -0800 (PST) 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 iTnWeOKet_5m for ; Wed, 28 Feb 2018 04:07:34 -0800 (PST) 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 5510B1204DA for ; Wed, 28 Feb 2018 04:07:33 -0800 (PST) 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 w1SC7W4L048590 for ; Wed, 28 Feb 2018 13:07:32 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 56F0920386D for ; Wed, 28 Feb 2018 13:07:32 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 4DB532007F1 for ; Wed, 28 Feb 2018 13:07:32 +0100 (CET) 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 w1SC7Vr9016783 for ; Wed, 28 Feb 2018 13:07:32 +0100 To: its@ietf.org References: <002901d3af20$b966e960$2c34bc20$@eurecom.fr> <002601d3afc4$a10fbb90$e32f32b0$@eurecom.fr> <71309c28-9d7e-d277-a3b0-46d1a3b4042e@gmail.com> <004701d3afd0$63867190$2a9354b0$@eurecom.fr> <461166f2-f3cc-e749-3628-f1d87104200b@gmail.com> <4997BFDE-1B3F-4F17-9742-28F23F082A15@tony.li> <596b8280-af45-aca2-9ea9-b05dce716ff1@gmail.com> <88030b0f-128a-b185-e9b8-f13b76878a74@gmail.com> <14621_1519817026_5A969141_14621_16048_1_c1dce555-5262-5a75-730d-401a1b6251e1@cea.fr> From: Alexandre Petrescu Message-ID: <3622fb0f-c859-9f08-1441-6b5f1d6d531f@gmail.com> Date: Wed, 28 Feb 2018 13:07:31 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <14621_1519817026_5A969141_14621_16048_1_c1dce555-5262-5a75-730d-401a1b6251e1@cea.fr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [ipwave] Critique of CAM message format 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, 28 Feb 2018 12:07:36 -0000 Michelle, This is a critique of the CAM message format ETSI EN 302 637-2 V1.3.1 interpreted together with ETSI TS 102 894-2 V1.2.1 "Applications and facilities layer common data dictionary". (I purposefully exclude the QoSData vs Data part; it is another discussion) Here is my critique of specification of CAM message format: - in general, it is impossible to say, when reading the specification of the CAM message, what is the length of some of the fields. Because of this reason, it is impossible to decide what is the total length of a minimal CAM without optional parts. It is impossible to answer whether a CAM fits in the MTU of IPv6-over-OCB. Because of this, it is impossible to easily obtain interoperable implementations. Example: what is the length of the Latitude field? The spec gives the value range -900000000..900000001, but does not say on how many bits. That value range can fit in 31bit (upper (log_2 (1800000002))). Some implementations do it on 32bit. But why 32 bit and not 31bit? (other fields where this doubt exists can be listed here: Acceleration Confidence values 0 to 102 but on how many bits, and many others). - the encoding is not expressed as Type Length Value (TLV). This is a common way of expressing message encoding when writing Internet Drafts. Because of this, a receiver of CAM has difficulty in dealing with options, variable lengths, etc. - the GenerationDeltaTime field is within a given window of width 16bit in milliseconds, and does not represent absolute time. It is the remainder of timestamp/65k. The timestamp itself is not sent. This is obviously a problem. Ideally, one should the use 64bit timestamp instead, not some remainder results or modulo calculation. - the latitude and longitude are expressed in relationship to WGS84, whereas an international standard would be more appropriate. Europe? - the latitude and longitude seems to be represented on same number of 32 bits by some implementations, whereas the range of values is obviously different (-90 to +90 vs -180 to +180). It could also be 31bit vs 32bit. - the confidence values are different than what GNSS chips offer as standard (HDOP, VDOP, HDOP). Because of this conversion will be needed, add to the lack of confidence. - when transported with a GeoNetworking header, one can find lat/long expressed twice: once in the CAM and once in the geonet header. - the speed values, as specified, can not go higher than 589kmph. But there are cars that go faster than that on circuit (check the record). - there is nothing about alignment of data. The alignment of different fields on boundaries (like 8bit, or other) are of utmost importance to implementer. This lead to necessity of padding sometimes, and padding must be specified. Alex From nobody Wed Feb 28 05:58:26 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB1E129C70 for ; Wed, 28 Feb 2018 05:58:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3NLmVxtSaRP for ; Wed, 28 Feb 2018 05:58:20 -0800 (PST) Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002: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 9E274128959 for ; Wed, 28 Feb 2018 05:58:20 -0800 (PST) Received: by mail-yb0-x22a.google.com with SMTP id e142-v6so832750ybc.13 for ; Wed, 28 Feb 2018 05:58:20 -0800 (PST) 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=Prswyl6fDHDJK9CBxcsqBRAKeaRzMG/kPkJWdZiyzEc=; b=k9s4Z0nAzrsSBnNvGvc2d9yRjD8u+sU/LjTMKXB529ee3PPAnF0GBtEYGnP+DU85Uj K2nk2oLBKLCSEibjtU4u9rXY0UeA3Hc77DGzJgOXcDGrVkotkobSYYQCBr9sWyz1BgBs wtMwIUYsT5lbaM3d/zMq5t77ny80P9GwrKtGQiWtTV7v6xd3sQS1uNxAyOOMT1w6XuFG DhVBl+p3ZEAUMfFkjVV9MEylNZlkA86haun07F6Zn1A7PgRt3zVrRql8MKj0FZoOsLWs JjfCPBOwOuAu9gJQ3W9YknPNdBNfjLP6sgS/VVy+LX96Px5/DorDZsWrsXzvWEUEhmik sqzQ== 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=Prswyl6fDHDJK9CBxcsqBRAKeaRzMG/kPkJWdZiyzEc=; b=QC+dh89HjvQ7n//PiQ6DfvJwOV5XnAdPlDJCILHuv29NFZC6aJS4LBJhmMP8ig6HDN QjfP2i3Gbj46hcKwlpwFW/YpTQsbUQ1iK7TmLsvlCS4ge2CY1ZfSygsHPjLBV5JbuuWj 3YyB1bNTu30rUxsLGHgRLQhiOjeYn60NRvr6KWKpw5NSickVUuUL+HSF60VH4ZbIAZ9H C7e9/Yu4XlU1kIkeMf9Bn03Z/yxhmyaMO+YY6oNQC96vUYwQpWHOEMCm1NXr7wzjrUn5 PuK/fYwV1lG4ZaIAVKj9hz/HYFmHtVh4rUIizDNwhcnbWjv56UUhWU7C4zRsA68rEatY iL+Q== X-Gm-Message-State: APf1xPAeG3GB7lR0Qds2+RyX9OCOderGK1o6Ozy5v2XMM+9FXuCT7t/p T1GWVamRy2L/wKcnViVc8m7rII9RyC9movnfJh8= X-Google-Smtp-Source: AG47ELt1eBwaAWrcxG9JApIMusqDjlenFWUEgowTiTD2/p/lG51JSTcId2IEdp8JhNstw+SdB2dpZ9W71CPNaQojmo8= X-Received: by 2002:a25:a082:: with SMTP id y2-v6mr12499061ybh.240.1519826299698; Wed, 28 Feb 2018 05:58:19 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a25:b942:0:0:0:0:0 with HTTP; Wed, 28 Feb 2018 05:58:19 -0800 (PST) In-Reply-To: References: <00eb01d3af1d$7f4e8100$7deb8300$@gmail.com> <6187cb92-5c8f-d08b-dcc2-859652d629d0@gmail.com> <002901d3af20$b966e960$2c34bc20$@eurecom.fr> <002601d3afc4$a10fbb90$e32f32b0$@eurecom.fr> <71309c28-9d7e-d277-a3b0-46d1a3b4042e@gmail.com> <004701d3afd0$63867190$2a9354b0$@eurecom.fr> <461166f2-f3cc-e749-3628-f1d87104200b@gmail.com> <4997BFDE-1B3F-4F17-9742-28F23F082A15@tony.li> <596b8280-af45-aca2-9ea9-b05dce716ff1@gmail.com> <88030b0f-128a-b185-e9b8-f13b76878a74@gmail.com> From: Michelle Wetterwald Date: Wed, 28 Feb 2018 14:58:19 +0100 Message-ID: To: Alexandre PETRESCU Cc: its Content-Type: multipart/alternative; boundary="000000000000b6c0aa056646224b" Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 28 Feb 2018 13:58:24 -0000 --000000000000b6c0aa056646224b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alex, Answers inline. 2018-02-28 12:22 GMT+01:00 Alexandre PETRESCU : > [trimmed the CC because mailer problems] > > Le 28/02/2018 =C3=A0 11:34, Michelle Wetterwald a =C3=A9crit : > >> Hi Alex, >> >> Regarding the interoperability between different implementations, it has >> been fully validated during numerous plugtests events in EU and US, >> gathering a large set of different implementations. For the EU ones, the >> reports are freely available on the ETSI web site. >> > > I am using the wireshark dissectors on the ETSI web site. > > I can tell they show lack of interoperability: several CAM messages from > several stacks are not understood by these wireshark dissectors. > Can you give references to these stacks? > > The ETSI wireshark dissectors have another problem themselves: they are > not integrated in the main wireshark software. It's just ETSI's point of > view. > > I am sorry to hear that the open source implementation that you are using >> has some limitations. I remember that one of the participants to the las= t >> PlugTest in Livorno (Nov 2016) explained to me he had extended the open >> source software to use his computer to monitor the traffic exchanged on = the >> 802.11p. So he made his Ath implementation fully interoperable with thos= e >> from the other vendors. Maybe you can apply similar upgrades to your >> testing implementations? >> > > Can you tell me who is that participant so I can contact? > Sorry, NDA applies here. But the list of vendors is in the report. > > Again, I disagree with the change you propose in the text of the draft, a= s >> it goes against the *existing* EU regulations. Compliance with the modif= ied >> text would prevent vendors from accessing the EU market. >> > > Accessing EU market is a good thing, but customer lock in may not be that > good. > This is not customer lock-in, there are several and diverse implementations available (BTW, this is more an L2 than an L3-IETF related topic), the only thing is that you have to pay for getting them, which is often part of the market rules, right? Is there a requirement that an RFC can be approved only if several open source implementations are available? I am not sure what to think about that. What would be the usefulness of a standard that prevents accessing part of the main markets? If you believe that the standard is not relevant any more, then it would be better to state it clearly and the WG can proceed on this basis. BR, Michelle > > Alex > > BR, >> Michelle >> >> >> 2018-02-28 11:09 GMT+01:00 Alexandre Petrescu < >> alexandre.petrescu@gmail.com >: >> >> >> >> >> Le 28/02/2018 =C3=A0 10:47, Katrin Sj=C3=B6berg a =C3=A9crit : >> >> Hi Alexandre, All, >> >> We are mixing apples and pears in this discussion and it is very >> frustrating. On one hand, the discussion is about detailed open >> source software implementations that do not support QoS data wit= h >> how the EU mandate will look like. >> >> >> EU must take great care when mandating technologies. >> >> First of all, the QoS data is handled by the chipset covering >> MAC+PHY on top of this LLC resides. >> >> >> I agree. >> >> We use ath9k driver and mac80211 module in the linux kernel. >> >> IPv6 is on top of LLC. >> >> >> Yes. >> >> And suddenly the CAM specification, which is residing in the >> facilities layer is discussed. >> >> >> I agree. Speaking CAM here is a stretch. The stretch comes from my >> single possible way (with BSM) to notice the existence of these QoS >> Data >> headers. I should have rather said "QoS Data transported message, >> e.g. >> CAM or BSM". >> >> When I say I have problems with CAM, and I will post a critique of i= t, >> is with the CAM message encoding, and lack of interoperability of th= at >> CAM. I do not critique the fact that QoS Data transports CAM. >> >> What is the problem with making EDCA mandatory in this standard? >> >> >> The problem is the lack of implementations. >> >> The amendment IEEE 802.11e, which introduced the concept of >> EDCA, was >> approved in 2005 and it was a unique selling point for WiFi APs = in >> the beginning. EDCA has been around for 13 years and this standa= rd >> developed in 2018 for supporting IPv6 in VANETs when using IEEE >> 802.11p wants to use DCF due to some existing implementation... >> For >> me this is like being thrown back to the stone age. >> >> >> Sorry, not the intention to throw back to stone age. >> >> But I need implementation. >> >> I am working for an OEM >> >> >> Is OEM implementing QoS Data? >> >> and I cannot accept that this standard will allow IPv6 traffic >> over IEEE 802.11p using DCF since it might adventure road >> traffic safety applications that are under development. We want >> to reduce the number of accidents and the >> impact of the same by using IEEE 802.11p with EDCA and suddenly >> messages such as CAMs might be starved out because someone is >> transmitting IPv6 traffic using DCF. This is not acceptable and >> once >> again I want to emphasize that EN 302 663 in Europe requires EDC= A, >> which would prohibit this standard to use the 5.9 GHz band. >> >> >> Hold on, hold on. Excuse me. >> >> Road traffic safety applications is also a huge worry for designers >> using IP packets. >> >> But, the spectrum is for everyone to coexist and interoperate. >> >> Alex >> >> >> Best regards, Katrin >> >> 2018-02-28 10:27 GMT+01:00 Alexandre Petrescu >> > >> > >> >>: >> >> >> >> >> Le 28/02/2018 =C3=A0 09:50, Mie Eur a =C3=A9crit : >> >> Hi Alex, >> >> I fully agree with Katrin and was about to send a similar post, >> as the EDCA queues are used also by ITS-G5 for the DCC, which is >> mandated by the new EU regulation. >> >> >> I would really be surprised that EU mandates something that >> depends on closed source, potentially favoring a competitive >> edge to a particular private interest. But I am optimistic: >> given all the stimulation of open source in EU projects I >> believe EU regulators understand the implications related to >> cost, licensing, and interoperability. >> >> Unless you want to rewrite all ETSI standards and related >> European norms in a couple of weeks, >> >> >> In one of these days I will post a critique of the CAM >> specification. >> >> I would suggest to keep the old text and guarantee openness for >> using >> the IEEE 802.11-16 standard while complying to local regulations= . >> >> >> YEs, we need that. >> >> But the old text says: >> >> "In OCB mode, IPv6 packets MAY be transmitted either as "IEEE >> 802.11 >> Data" or alternatively as "IEEE 802.11 QoS Data" >> >> >> I implement only the 802.11 Data and my partner(s) use equipment >> bought from Unex that only implements QoS Data. I want our >> software to interoperate. >> >> If the text said just 'Data', then I could direct my partners to >> the >> open source on the Internet. But in current situation my >> partners direct me to Unex, which is expensive - it has a cost. >> >> I do not agree to continue this situation. >> >> Either the QoSData supporters direct me to an open source >> implementation of QoSData now, or we relegate the QoS discussion >> for later. >> >> I would also suggest to bring this topic, as well as the handlin= g >> of >> QoS for IPWAVE, which is an interesting topic, to the >> re-chartering >> discussion that was proposed by Carlos-Jesus a few weeks ago. >> The same as we did for ND or this nice multicast address that >> would be reserved for IPWAVE services. >> >> >> I agree. >> >> BTW, you really plan to send CAMs directly over IPv6, without >> any transport layer? I thought you would use UDP, which has a >> "large" header as well. (found in an "old" post dated back from >> 4 days ago. ) >> >> >> At this time, with partners, we ponder the idea of a different >> CAM if >> you wish (not sure whether UDP, or just IP, or 802.11 Data, or >> 802.11 >> QoS Data). This different CAM is interoperable and cheap to >> produce. >> >> CAM over UDP over IPv6 was already produced by others in other >> project. I think they didnt bother to standardise it, but it >> worked for them. I am tempted to copy from them. >> >> Alex >> >> : >> >> CAM transported in IP may be a smaller packet than CAM transport= ed >> >> in BTP and GeoNetworking. >> >> >> 2018-02-28 8:07 GMT+01:00 Alexandre Petrescu >> > >> > > >> > >> > >>>: >> >> Thank you for the message. >> >> Le 28/02/2018 =C3=A0 07:08, Katrin Sj=C3=B6berg a =C3=A9crit : [= ...] >> >> This implies that the current IETF proposal of using IPv6 over >> DCF would be impossible to use in Europe. >> >> >> Unless, of course, we suggest modify the ETSI specification to >> allow >> for 802.11 Data headers as well as 802.11 QoS Data headers. >> >> (there are many reasons to ponder over a major rehaul of ETSI >> ITS specifications, starting at the CAM itself, that I could >> explain separately). >> >> If all IPv6 trafffic has to use a common EDCA access category, I >> would support John's suggestion from an earlier email to fix >> IPv6 traffic to AC_BK. >> >> >> This could be done. On my side I would need to see running code >> for >> it, and then there is need of consensus (could be obvious from >> your >> standpoint). >> >> As J=C3=AAr=C3=B3me pointed out, we use AC_BE for CAMs, >> >> >> Thank you for this message. I understand you have an >> implementation >> of CAM sent with IEEE 802.11 QoSData header. Is it the one fr= om >> Unex with Autotalks chipset? >> >> (the CAM implementations I use are from github.com >> and >> ath9k driver; they dont generate 802.11 QoSData header, but use >> 802.11 Data header, hence no AC_BE). >> >> and I know the US uses AC_BE for some of their safety messages >> as well. >> >> >> I think me too, I have seen BSM messages carried with 802.11 >> QoSData headers, field Priority value 2 Spare (Background); I >> guess that stands for AC_BK. But I could not figure out what >> was the software that implemented it. >> >> Alex >> >> >> Best regards, Katrin Sj=C3=B6berg >> >> >> >> 2018-02-27 17:50 GMT+01:00 Tony Li > > > > > >> > > > > > >>>>: >> >> >> If someone knows how to generate a QoSData transported IP packet >> with >> linux open source then I am all ears. >> >> >> >> This is just a Small Matter Of Programming for anyone with a bit >> of kernel hacking experience and driver sources. >> >> Tony >> >> _______________________________________________ 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 >> >> > > >> > >> > >> >> >> >> >> >> -- Michelle WETTERWALD >> >> >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >> >> >> >> >> >> -- >> Michelle Wetterwald >> michelle.wetterwald@gmail.com >> > > --=20 Michelle Wetterwald michelle.wetterwald@gmail.com --000000000000b6c0aa056646224b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alex,

Answers inline.
=

2018-02-28 = 12:22 GMT+01:00 Alexandre PETRESCU <alexandre.petrescu@cea.fr&= gt;:
[trimmed the CC because mailer problems]

Le 28/02/2018 =C3=A0 11:34, Michelle Wetterwald a =C3=A9crit=C2=A0:
Hi Alex,

Regarding the interoperability between different implementations, it has be= en fully validated during numerous plugtests events=C2=A0in EU and US, gath= ering a large set of different implementations. For the EU ones, the report= s are freely available on the ETSI=C2=A0web site.

I am using the wireshark dissectors on the ETSI web site.

I can tell they show lack of interoperability: several CAM messages from se= veral stacks are not understood by these wireshark dissectors.

Can you give references to these stacks?=C2= =A0=C2=A0

The ETSI wireshark dissectors have another problem themselves: they are not= integrated in the main wireshark software.=C2=A0 It's just ETSI's = point of view.

I am sorry to hear that the open source implementation that you are using h= as some limitations. I remember that one of the participants to the last Pl= ugTest in Livorno (Nov 2016) explained to me he had extended the open sourc= e software to use his computer=C2=A0to monitor=C2=A0the traffic exchanged o= n the 802.11p. So he made his Ath implementation fully interoperable with t= hose from the other vendors. Maybe you can apply=C2=A0similar upgrades to y= our testing implementations?

Can you tell me who is that participant so I can contact?

Sorry, NDA applies here.=C2=A0But the list of ven= dors is in the report.

Again, I disagree with the change you propose in the text of the draft, as = it=C2=A0goes against=C2=A0the *existing* EU regulations.=C2=A0Compliance wi= th the modified text would prevent=C2=A0vendors from accessing the EU marke= t.

 Accessing EU market is a good thing, but customer lock in may not be that g= ood.

This is not customer lock-in, ther= e are several and diverse implementations available (BTW, this is more an L= 2 than an L3-IETF related=C2=A0topic), the only thing is that you have to p= ay for getting them, which is=C2=A0often part=C2=A0of the market rules, rig= ht? Is there a requirement that an RFC can be approved only if several open= source implementations are available?

I am not su= re what to think about that. What would be the usefulness of a standard tha= t prevents accessing part of the main markets?
If you believe th= at the standard is not relevant any more, then it would be better to state = it clearly and the WG can proceed on this basis.

B= R, Michelle
=C2=A0

Alex

BR,
Michelle


2018-02-28 11:09 GMT+01:00 Alexandre Petrescu <alexandre.petrescu@gmail.com &= lt;mailto:alexandre.petrescu@gmail.com>>:




=C2=A0 =C2=A0 Le 28/02/2018 =C3=A0 10:47, Katrin Sj=C3=B6berg a =C3=A9crit = :

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi Alexandre, All,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 We are mixing apples and pears in this discussi= on and it is very
=C2=A0 =C2=A0 =C2=A0 =C2=A0 frustrating. On one hand, the discussion is abo= ut detailed open
=C2=A0 =C2=A0 =C2=A0 =C2=A0 source software implementations that do not sup= port QoS data with
=C2=A0 =C2=A0 =C2=A0 =C2=A0 how the EU mandate will look like.


=C2=A0 =C2=A0 EU must take great care when mandating technologies.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 First of all, the QoS data is handled by the ch= ipset covering
=C2=A0 =C2=A0 =C2=A0 =C2=A0 MAC+PHY on top of this LLC resides.


=C2=A0 =C2=A0 I agree.

=C2=A0 =C2=A0 We use ath9k driver and mac80211 module in the linux kernel.<= br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6 is on top of LLC.


=C2=A0 =C2=A0 Yes.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 And suddenly the CAM specification, which is re= siding in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 facilities layer is discussed.


=C2=A0 =C2=A0 I agree.=C2=A0 Speaking CAM here is a stretch.=C2=A0 The stre= tch comes from my
=C2=A0 =C2=A0 single possible way (with BSM) to notice the existence of the= se QoS Data
=C2=A0 =C2=A0 headers.=C2=A0 I should have rather said "QoS Data trans= ported message, e.g.
=C2=A0 =C2=A0 CAM or BSM".

=C2=A0 =C2=A0 When I say I have problems with CAM, and I will post a critiq= ue of it,
=C2=A0 =C2=A0 is with the CAM message encoding, and lack of interoperabilit= y of that
=C2=A0 =C2=A0 CAM.=C2=A0 I do not critique the fact that QoS Data transport= s CAM.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 What is the problem with making EDCA mandatory = in this standard?


=C2=A0 =C2=A0 The problem is the lack of implementations.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 The amendment IEEE 802.11e, which introduced th= e concept of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 EDCA, was
=C2=A0 =C2=A0 =C2=A0 =C2=A0 approved in 2005 and it was a unique selling po= int for WiFi APs in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the beginning. EDCA has been around for 13 year= s and this standard
=C2=A0 =C2=A0 =C2=A0 =C2=A0 developed in 2018 for supporting IPv6 in VANETs= when using IEEE
=C2=A0 =C2=A0 =C2=A0 =C2=A0 802.11p wants to use DCF due to some existing i= mplementation... For
=C2=A0 =C2=A0 =C2=A0 =C2=A0 me this is like being thrown back to the stone = age.


=C2=A0 =C2=A0 Sorry, not the intention to throw back to stone age.

=C2=A0 =C2=A0 But I need implementation.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I am working for an OEM


=C2=A0 =C2=A0 Is OEM implementing QoS Data?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 and I cannot accept that this standard will all= ow IPv6 traffic
=C2=A0 =C2=A0 =C2=A0 =C2=A0 over IEEE 802.11p using DCF since it might adve= nture road
=C2=A0 =C2=A0 =C2=A0 =C2=A0 traffic safety applications that are under deve= lopment. We want
=C2=A0 =C2=A0 =C2=A0 =C2=A0 to reduce the number of accidents and the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 impact of the same by using IEEE 802.11p with E= DCA and suddenly
=C2=A0 =C2=A0 =C2=A0 =C2=A0 messages such as CAMs might be starved out beca= use someone is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 transmitting IPv6 traffic using DCF. This is no= t acceptable and once
=C2=A0 =C2=A0 =C2=A0 =C2=A0 again I want to emphasize that EN 302 663 in Eu= rope requires EDCA,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 which would prohibit this standard to use the 5= .9 GHz band.


=C2=A0 =C2=A0 Hold on, hold on.=C2=A0 Excuse me.

=C2=A0 =C2=A0 Road traffic safety applications is also a huge worry for des= igners
=C2=A0 =C2=A0 using IP packets.

=C2=A0 =C2=A0 But, the spectrum is for everyone to coexist and interoperate= .

=C2=A0 =C2=A0 Alex


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Best regards, Katrin

=C2=A0 =C2=A0 =C2=A0 =C2=A0 2018-02-28 10:27 GMT+01:00 Alexandre Petrescu =C2=A0 =C2=A0 =C2=A0 =C2=A0 <alexandre.petrescu@gmail.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:alexandre.petrescu@gmail.com>
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:alexandre.petrescu@gmail.com

=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:alexandre.petrescu@gmail.com>>= >:




=C2=A0 =C2=A0 =C2=A0 =C2=A0 Le 28/02/2018 =C3=A0 09:50, Mie Eur a =C3=A9cri= t :

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi Alex,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I fully agree with Katrin and was about to send= a similar post,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 as the EDCA queues are used also by ITS-G5 for = the DCC, which is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mandated by the new EU regulation.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 I would really be surprised that EU mandates so= mething that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 depends on closed source, potentially favoring = a competitive
=C2=A0 =C2=A0 =C2=A0 =C2=A0 edge to a particular private interest.=C2=A0 Bu= t I am optimistic:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 given all the stimulation of open source in EU = projects I
=C2=A0 =C2=A0 =C2=A0 =C2=A0 believe EU regulators understand the implicatio= ns related to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cost, licensing, and interoperability.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Unless you want to rewrite all ETSI standards a= nd related
=C2=A0 =C2=A0 =C2=A0 =C2=A0 European norms in a couple of=C2=A0 weeks,


=C2=A0 =C2=A0 =C2=A0 =C2=A0 In one of these days I will post a critique of = the CAM
=C2=A0 =C2=A0 =C2=A0 =C2=A0 specification.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I would suggest to keep the old text and guaran= tee openness for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 using
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the IEEE 802.11-16 standard while complying to = local regulations.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 YEs, we need that.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 But the old text says:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "In OCB mode, IPv6 packets MAY be transmit= ted either as "IEEE 802.11
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0Data" or alternatively as &quo= t;IEEE 802.11 QoS Data"


=C2=A0 =C2=A0 =C2=A0 =C2=A0 I implement only the 802.11 Data and my partner= (s) use equipment
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bought from Unex that only implements QoS Data.= =C2=A0 I want our
=C2=A0 =C2=A0 =C2=A0 =C2=A0 software to interoperate.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 If the text said just 'Data', then I co= uld direct my partners to the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0open source on the Internet.=C2=A0 = But in current situation my
=C2=A0 =C2=A0 =C2=A0 =C2=A0 partners direct me to Unex, which is expensive = - it has a cost.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I do not agree to continue this situation.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Either the QoSData supporters direct me to an o= pen source
=C2=A0 =C2=A0 =C2=A0 =C2=A0 implementation of QoSData now, or we relegate t= he QoS discussion
=C2=A0 =C2=A0 =C2=A0 =C2=A0 for later.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I would also suggest to bring this topic, as we= ll as the handling of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0QoS for IPWAVE, which is an interes= ting topic, to the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 re-chartering
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0discussion that was proposed by Car= los-Jesus a few weeks ago.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 The same as we did for ND or this nice multicas= t address that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 would be reserved for IPWAVE services.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 I agree.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 BTW, you really plan to send CAMs directly over= IPv6, without
=C2=A0 =C2=A0 =C2=A0 =C2=A0 any transport layer? I thought you would use UD= P, which has a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "large" header as well. (found in an = "old" post dated back from
=C2=A0 =C2=A0 =C2=A0 =C2=A0 4 days ago. )


=C2=A0 =C2=A0 =C2=A0 =C2=A0 At this time, with partners, we ponder the idea= of a different
=C2=A0 =C2=A0 =C2=A0 =C2=A0 CAM if
=C2=A0 =C2=A0 =C2=A0 =C2=A0 you wish (not sure whether UDP, or just IP, or = 802.11 Data, or
=C2=A0 =C2=A0 =C2=A0 =C2=A0 802.11
=C2=A0 =C2=A0 =C2=A0 =C2=A0 QoS Data).=C2=A0 This different CAM is interope= rable and cheap to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 produce.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 CAM over UDP over IPv6 was already produced by = others in other
=C2=A0 =C2=A0 =C2=A0 =C2=A0 project. I think they didnt bother to standardi= se it, but it
=C2=A0 =C2=A0 =C2=A0 =C2=A0 worked for them.=C2=A0 I am tempted to copy fro= m them.

=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 CAM transported in IP may be a smaller packet t= han CAM transported

=C2=A0 =C2=A0 =C2=A0 =C2=A0 in BTP and GeoNetworking.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 2018-02-28 8:07 GMT+01:00 Alexandre Petrescu =C2=A0 =C2=A0 =C2=A0 =C2=A0 <alexandre.petrescu@gmail.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:alexandre.petrescu@gmail.com>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:alexandre.petrescu@gmail.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:alexandre.petrescu@gmail.com>>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:alexandre.petrescu@gmail.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:alexandre.petrescu@gmail.com>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:alexandre.petrescu@gmail.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:alexandre.petrescu@gmail.com>>= >>:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thank you for the message.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Le 28/02/2018 =C3=A0 07:08, Katrin Sj=C3=B6berg= a =C3=A9crit : [...]

=C2=A0 =C2=A0 =C2=A0 =C2=A0 This implies that the current IETF proposal of = using IPv6 over
=C2=A0 =C2=A0 =C2=A0 =C2=A0 DCF would be impossible to use in Europe.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Unless, of course, we suggest modify the ETSI s= pecification to allow
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0for 802.11 Data headers as well as = 802.11 QoS Data headers.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 (there are many reasons to ponder over a major = rehaul of ETSI
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ITS specifications, starting at the CAM itself,= that I could
=C2=A0 =C2=A0 =C2=A0 =C2=A0 explain separately).

=C2=A0 =C2=A0 =C2=A0 =C2=A0 If all IPv6 trafffic has to use a common EDCA a= ccess category, I
=C2=A0 =C2=A0 =C2=A0 =C2=A0 would support John's suggestion from an ear= lier email to fix
=C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6 traffic to AC_BK.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 This could be done.=C2=A0 On my side I would ne= ed to see running code for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0it, and then there is need of conse= nsus (could be obvious from
=C2=A0 =C2=A0 =C2=A0 =C2=A0 your
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0standpoint).

=C2=A0 =C2=A0 =C2=A0 =C2=A0 As J=C3=AAr=C3=B3me pointed out, we use AC_BE f= or CAMs,


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thank you for this message.=C2=A0 I understand = you have an implementation
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0of CAM sent with IEEE 802.11 QoSDat= a header.=C2=A0 Is it the one from
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Unex with Autotalks chipset?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 (the CAM implementations I use are from github.com<= br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <http://github.com> <http://github.com> <= ;http://= github.com> and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ath9k driver; they dont generate 802.11 QoSData= header, but use
=C2=A0 =C2=A0 =C2=A0 =C2=A0 802.11 Data header, hence no AC_BE).

=C2=A0 =C2=A0 =C2=A0 =C2=A0 and I know the US uses AC_BE for some of their = safety messages
=C2=A0 =C2=A0 =C2=A0 =C2=A0 as well.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 I think me too, I have seen BSM messages carrie= d with 802.11
=C2=A0 =C2=A0 =C2=A0 =C2=A0 QoSData headers, field Priority value 2 Spare (= Background); I
=C2=A0 =C2=A0 =C2=A0 =C2=A0 guess that stands for AC_BK.=C2=A0 But I could = not figure out what
=C2=A0 =C2=A0 =C2=A0 =C2=A0 was the software that implemented it.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Alex


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Best regards, Katrin Sj=C3=B6berg



=C2=A0 =C2=A0 =C2=A0 =C2=A0 2018-02-27 17:50 GMT+01:00 Tony Li <tony.li@tony.li
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:tony.li@tony.li> <mailto:tony.li@tony.li
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:tony.li@tony.li>> <mailto:tony.li@tony.li
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:tony.li@tony.li> <mailto:tony.li@tony.li
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:tony.li@tony.li>>> <mailto:tony.li@tony.li
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:tony.li@tony.li> <mailto:tony.li@tony.li
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:tony.li@tony.li>> <mailto:tony.li@tony.li
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:tony.li@tony.li> <mailto:tony.li@tony.li
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:tony.li@tony.li>>>>>:


=C2=A0 =C2=A0 =C2=A0 =C2=A0 If someone knows how to generate a QoSData tran= sported IP packet
=C2=A0 =C2=A0 =C2=A0 =C2=A0 with
=C2=A0 =C2=A0 =C2=A0 =C2=A0 linux open source then I am all ears.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 This is just a Small Matter Of Programming for = anyone with a bit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 of kernel hacking experience and driver sources= .

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Tony

=C2=A0 =C2=A0 =C2=A0 =C2=A0 __________________________________________= _____ its mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 its@ietf.org <mailto:its@ietf.org> <mailto:its@ietf.org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:its@ietf.org>> <mailto:its@ietf.org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:its@ietf.org> <mailto:its@ietf.org
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:its@ietf.org>>> <mailto:its@ietf.org
<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:its@ietf.org> <mailto:its@ietf.org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:its@ietf.org>> <mailto:its@ietf.org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:its@ietf.org> <mailto:its@ietf.org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:its@ietf.org>>>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/l<= wbr>istinfo/its
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailma= n/listinfo/its>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailma= n/listinfo/its
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailma= n/listinfo/its>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailma= n/listinfo/its
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailma= n/listinfo/its>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailma= n/listinfo/its
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailma= n/listinfo/its>>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailma= n/listinfo/its
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailma= n/listinfo/its>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailma= n/listinfo/its
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailma= n/listinfo/its>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailma= n/listinfo/its
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailma= n/listinfo/its>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailma= n/listinfo/its
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailma= n/listinfo/its>>>>



=C2=A0 =C2=A0 =C2=A0 =C2=A0 __________________________________________= _____ its mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 its@ietf.org <mailto:its@ietf.org> <mailto:its@ietf.org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:its@ietf.org>> <mailto:its@ietf.org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:its@ietf.org> <mailto:its@ietf.org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:its@ietf.org>>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/l<= wbr>istinfo/its
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailma= n/listinfo/its>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailma= n/listinfo/its
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailma= n/listinfo/its>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailma= n/listinfo/its
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailma= n/listinfo/its>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailma= n/listinfo/its
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailma= n/listinfo/its>>>




=C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Michelle WETTERWALD



=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/i= ts
=C2=A0 =C2=A0 <https://www.ietf.org/mailman/listinf= o/its>




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



--
--000000000000b6c0aa056646224b-- From nobody Wed Feb 28 06:00:01 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFE2912AAB6 for ; Wed, 28 Feb 2018 05:59:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJ1KLWfJH7Ex for ; Wed, 28 Feb 2018 05:59:58 -0800 (PST) Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002:c09::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 C4523128959 for ; Wed, 28 Feb 2018 05:59:57 -0800 (PST) Received: by mail-yb0-x22b.google.com with SMTP id i13-v6so837081ybl.9 for ; Wed, 28 Feb 2018 05:59:57 -0800 (PST) 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=i9rJ2GTtISZRsURE2akjO7INFSQVSfjdTaq3u8Cf0wM=; b=ab0tZyni6rCeXzx0XXvIe8Z06s5ne3Y7jiTh9rA11w0J04wOa+b+bzFrToGjQ+ZLF+ MVng8gHVw2od3GzctAE8BVnAb9IN7rwU+HSULNVZu9IU/e6/3i3krSv1qU9s2+Nri53Q z9uA7O94Ae8iU1Q4wXyc+gJmkpw70VqKQi0ZG8eYMCxo3wmmq/s/4w63QuA2atK2czo5 1Lv0j4gkWKQaZJ+BXZ+3jjGosjB2yfcfBV5xde7E8GMLkZDIsYcfrkhqyG9njJ0NoXkO ITI4lVcAqj3AhVmgGdAB1TyF/G9qIQxuzzwQQewjSg9Y1oy8ljzZvesrDSOAJ0+0EC7i CMZg== 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=i9rJ2GTtISZRsURE2akjO7INFSQVSfjdTaq3u8Cf0wM=; b=TZRzNJvjUAVQLq62ybdiaPl9P7JHLtLU2r3JZKnJcWVD501QK+pFvSvksMG4Fz9s6U C3900J/eDyQ7RVJGSxZki3FxYg0csxH0NvklPF9xN8pYpjaG+u8J+0F6zhXFybIF7xaK rqYB5qcZl+qktzSL3kJflyCKoQrzFDbFEHrH7E7lJfMuHXOwZPkw6wSJcfq97zUrdXPA WjU1oFhjsg+3QakmlQdcJ2O4n3aT4b0srfnWdv/4HbfiDkVOCdDVvTEZNRhh+sKk6RTx IZsTSWgGTcKiuEvu3++Wgy5a8Hd9Gv7H23TA4k7yS6do/9ir6r9o+x2Fo6XqCFkbvpHe H4MQ== X-Gm-Message-State: APf1xPD6FAf92vLJPisTqqKAjAMagD3W4OUu3g9XWkhtVvtDEOt7ysi/ Yqf//e4evPz+89MPbeAJ87ewCxnq2/AXdbFJx10kMg== X-Google-Smtp-Source: AG47ELvGwzYqaB4lISc7YjAYhs4BebObpauYboFD0BVue76WPrRgH0Q8QYgBLdoMeuY4WQLple+r8D68bMEMKSQMlsw= X-Received: by 2002:a25:7649:: with SMTP id r70-v6mr11847917ybc.342.1519826397033; Wed, 28 Feb 2018 05:59:57 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a25:b942:0:0:0:0:0 with HTTP; Wed, 28 Feb 2018 05:59:56 -0800 (PST) In-Reply-To: <3622fb0f-c859-9f08-1441-6b5f1d6d531f@gmail.com> References: <002901d3af20$b966e960$2c34bc20$@eurecom.fr> <002601d3afc4$a10fbb90$e32f32b0$@eurecom.fr> <71309c28-9d7e-d277-a3b0-46d1a3b4042e@gmail.com> <004701d3afd0$63867190$2a9354b0$@eurecom.fr> <461166f2-f3cc-e749-3628-f1d87104200b@gmail.com> <4997BFDE-1B3F-4F17-9742-28F23F082A15@tony.li> <596b8280-af45-aca2-9ea9-b05dce716ff1@gmail.com> <88030b0f-128a-b185-e9b8-f13b76878a74@gmail.com> <14621_1519817026_5A969141_14621_16048_1_c1dce555-5262-5a75-730d-401a1b6251e1@cea.fr> <3622fb0f-c859-9f08-1441-6b5f1d6d531f@gmail.com> From: Michelle Wetterwald Date: Wed, 28 Feb 2018 14:59:56 +0100 Message-ID: To: Alexandre Petrescu Cc: its Content-Type: multipart/alternative; boundary="00000000000083f905056646288e" Archived-At: Subject: Re: [ipwave] Critique of CAM message format 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, 28 Feb 2018 14:00:00 -0000 --00000000000083f905056646288e Content-Type: text/plain; charset="UTF-8" Hi Alex, I am not representing ETSI and I am wondering whether this is the right place to discuss about the content of ETSI standards. I rather encourage you to submit a contribution to that group. BR, Michelle 2018-02-28 13:07 GMT+01:00 Alexandre Petrescu : > Michelle, > > This is a critique of the CAM message format ETSI EN 302 637-2 V1.3.1 > interpreted together with ETSI TS 102 894-2 V1.2.1 "Applications and > facilities layer common data dictionary". > > (I purposefully exclude the QoSData vs Data part; it is another discussion) > > Here is my critique of specification of CAM message format: > > - in general, it is impossible to say, when reading the specification of > the CAM message, what is the length of some of the fields. > Because of this reason, it is impossible to decide what is the total > length of a minimal CAM without optional parts. > It is impossible to answer whether a CAM fits in the MTU of > IPv6-over-OCB. > Because of this, it is impossible to easily obtain interoperable > implementations. > > Example: what is the length of the Latitude field? The spec gives the > value range -900000000..900000001, but does not say on how many bits. > That value range can fit in 31bit (upper (log_2 (1800000002))). > Some implementations do it on 32bit. But why 32 bit and not 31bit? > > (other fields where this doubt exists can be listed here: Acceleration > Confidence values 0 to 102 but on how many bits, and many others). > > - the encoding is not expressed as Type Length Value (TLV). This is a > common way of expressing message encoding when writing Internet > Drafts. > > Because of this, a receiver of CAM has difficulty in dealing with > options, variable lengths, etc. > > - the GenerationDeltaTime field is within a given window of width 16bit > in milliseconds, and does not represent absolute time. It is the > remainder of timestamp/65k. The timestamp itself is not sent. This > is obviously a problem. Ideally, one should the use 64bit timestamp > instead, not some remainder results or modulo calculation. > > - the latitude and longitude are expressed in relationship to WGS84, > whereas an international standard would be more appropriate. Europe? > > - the latitude and longitude seems to be represented on same number of > 32 bits by some implementations, whereas the range of values is > obviously different (-90 to +90 vs -180 to +180). It could also be > 31bit vs 32bit. > > - the confidence values are different than what GNSS chips offer as > standard (HDOP, VDOP, HDOP). Because of this conversion will be > needed, add to the lack of confidence. > > - when transported with a GeoNetworking header, one can find lat/long > expressed twice: once in the CAM and once in the geonet header. > > - the speed values, as specified, can not go higher than 589kmph. But > there are cars that go faster than that on circuit (check the record). > > - there is nothing about alignment of data. The alignment of different > fields on boundaries (like 8bit, or other) are of utmost importance to > implementer. This lead to necessity of padding sometimes, and padding > must be specified. > > Alex > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > -- Michelle Wetterwald michelle.wetterwald@gmail.com --00000000000083f905056646288e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alex,

I am not representi= ng ETSI and I am wondering whether this is the right place to discuss about= the content of ETSI standards.
I rather encourage you to submit = a contribution to that group.

BR, Michelle

2018-02-28 13:0= 7 GMT+01:00 Alexandre Petrescu <alexandre.petrescu@gmail.com>:
Michelle,

This is a critique of the CAM message format ETSI EN 302 637-2 V1.3.1
interpreted together with ETSI TS 102 894-2 V1.2.1 "Applications and facilities layer common data dictionary".

(I purposefully exclude the QoSData vs Data part; it is another discussion)=

Here is my critique of specification of CAM message format:

- in general, it is impossible to say, when reading the specification of =C2=A0 the CAM message, what is the length of some of the fields.
=C2=A0 Because of this reason, it is impossible to decide what is the total=
=C2=A0 length of a minimal CAM without optional parts.
=C2=A0 It is impossible to answer whether a CAM fits in the MTU of
=C2=A0 IPv6-over-OCB.
=C2=A0 Because of this, it is impossible to easily obtain interoperable
=C2=A0 implementations.

=C2=A0 Example: what is the length of the Latitude field?=C2=A0 The spec gi= ves the
=C2=A0 value range -900000000..900000001, but=C2=A0 does not say on how man= y bits.
=C2=A0 That value range can fit in 31bit (upper (log_2 (1800000002))).
=C2=A0 Some implementations do it on 32bit.=C2=A0 But why 32 bit and not 31= bit?

=C2=A0 (other fields where this doubt exists can be listed here: Accelerati= on
=C2=A0 =C2=A0Confidence values 0 to 102 but on how many bits, and many othe= rs).

- the encoding is not expressed as Type Length Value (TLV).=C2=A0 This is a=
=C2=A0 common way of expressing message encoding when writing Internet
=C2=A0 Drafts.

=C2=A0 Because of this, a receiver of CAM has difficulty in dealing with =C2=A0 options, variable lengths, etc.

- the GenerationDeltaTime field is within a given window of width 16bit
=C2=A0 in milliseconds, and does not represent absolute time.=C2=A0 It is t= he
=C2=A0 remainder of timestamp/65k.=C2=A0 The timestamp itself is not sent.= =C2=A0 This
=C2=A0 is obviously a problem.=C2=A0 Ideally, one should the use 64bit time= stamp
=C2=A0 instead, not some remainder results or modulo calculation.

- the latitude and longitude are expressed in relationship to WGS84,
=C2=A0 whereas an international standard would be more appropriate.=C2=A0 E= urope?

- the latitude and longitude seems to be represented on same number of
=C2=A0 32 bits by some implementations, whereas the range of values is
=C2=A0 obviously different (-90 to +90 vs -180 to +180).=C2=A0 It could als= o be
=C2=A0 31bit vs 32bit.

- the confidence values are different than what GNSS chips offer as
=C2=A0 standard (HDOP, VDOP, HDOP).=C2=A0 Because of this conversion will b= e
=C2=A0 needed, add to the lack of confidence.

- when transported with a GeoNetworking header, one can find lat/long
=C2=A0 expressed twice: once in the CAM and once in the geonet header.

- the speed values, as specified, can not go higher than 589kmph.=C2=A0 But=
=C2=A0 there are cars that go faster than that on circuit (check the record= ).

- there is nothing about alignment of data.=C2=A0 The alignment of differen= t
=C2=A0 fields on boundaries (like 8bit, or other) are of utmost importance = to
=C2=A0 implementer.=C2=A0 This lead to necessity of padding sometimes, and = padding
=C2=A0 must be specified.

Alex

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



--
Michelle W= etterwald
--00000000000083f905056646288e-- From nobody Wed Feb 28 06:08:56 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FAAD129C6D for ; Wed, 28 Feb 2018 06:08:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LkW1iD7m-UL0 for ; Wed, 28 Feb 2018 06:08:50 -0800 (PST) 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 83DB1128959 for ; Wed, 28 Feb 2018 06:08:49 -0800 (PST) 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 w1SE8kCw012945; Wed, 28 Feb 2018 15:08:46 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D283620596C; Wed, 28 Feb 2018 15:08:46 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id BB1A8205965; Wed, 28 Feb 2018 15:08:46 +0100 (CET) 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 w1SE8kXE031536; Wed, 28 Feb 2018 15:08:46 +0100 To: Michelle Wetterwald Cc: its References: <002601d3afc4$a10fbb90$e32f32b0$@eurecom.fr> <71309c28-9d7e-d277-a3b0-46d1a3b4042e@gmail.com> <004701d3afd0$63867190$2a9354b0$@eurecom.fr> <461166f2-f3cc-e749-3628-f1d87104200b@gmail.com> <4997BFDE-1B3F-4F17-9742-28F23F082A15@tony.li> <596b8280-af45-aca2-9ea9-b05dce716ff1@gmail.com> <88030b0f-128a-b185-e9b8-f13b76878a74@gmail.com> From: Alexandre PETRESCU Organization: CEA Message-ID: Date: Wed, 28 Feb 2018 15:08:46 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080103040804000601090504" Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 28 Feb 2018 14:08:54 -0000 This is a cryptographically signed message in MIME format. --------------ms080103040804000601090504 Content-Type: multipart/alternative; boundary="------------3C3691B8A5CCEFFAAE6EE6E3" Content-Language: fr This is a multi-part message in MIME format. --------------3C3691B8A5CCEFFAAE6EE6E3 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable -- Alexandre Petrescu alexandre.petrescu@cea.fr, t=C3=A9l 0169089223 Le 28/02/2018 =C3=A0 14:58, Michelle Wetterwald a =C3=A9crit=C2=A0: > Hi Alex, > > Answers inline. > > 2018-02-28 12:22 GMT+01:00 Alexandre PETRESCU=20 > >: > > [trimmed the CC because mailer problems] > > Le 28/02/2018 =C3=A0 11:34, Michelle Wetterwald a =C3=A9crit=C2=A0:= > > Hi Alex, > > Regarding the interoperability between different > implementations, it has been fully validated during numerous > plugtests events=C2=A0in EU and US, gathering a large set of > different implementations. For the EU ones, the reports are > freely available on the ETSI=C2=A0web site. > > > I am using the wireshark dissectors on the ETSI web site. > > I can tell they show lack of interoperability: several CAM > messages from several stacks are not understood by these wireshark > dissectors. > > > Can you give references to these stacks? github.com 'rendits', 'vanetza', 'driveits', 'geonetworking', 'btpsap'. None puts a QoSData header, each puts a 'Data' header. (but none sends CAM as IP messages either). > > The ETSI wireshark dissectors have another problem themselves: > they are not integrated in the main wireshark software.=C2=A0 It's = just > ETSI's point of view. > > I am sorry to hear that the open source implementation that > you are using has some limitations. I remember that one of the > participants to the last PlugTest in Livorno (Nov 2016) > explained to me he had extended the open source software to > use his computer=C2=A0to monitor=C2=A0the traffic exchanged on = the > 802.11p. So he made his Ath implementation fully interoperable > with those from the other vendors. Maybe you can apply=C2=A0sim= ilar > upgrades to your testing implementations? > > > Can you tell me who is that participant so I can contact? > > > Sorry, NDA applies here.=C2=A0But the list of vendors is in the report.= The reference to the report please? > > Again, I disagree with the change you propose in the text of > the draft, as it=C2=A0goes against=C2=A0the *existing* EU > regulations.=C2=A0Compliance with the modified text would > prevent=C2=A0vendors from accessing the EU market. > > > Accessing EU market is a good thing, but customer lock in may not > be that good. > > > This is not customer lock-in, there are several and diverse=20 > implementations available (BTW, this is more an L2 than an L3-IETF=20 > related=C2=A0topic), the only thing is that you have to pay for getting= =20 > them, which is=C2=A0often part=C2=A0of the market rules, right? There are software features in limited deployment that deserve a certain = amount of money. But key aspects like running IP are free of charge. For example, it is worth attaching a price tag for software in a limited = deployment (e.g. this highway), but IP is much wider scale. You cant put = a price tag on it. > Is there a requirement that an RFC can be approved only if several=20 > open source implementations are available? No, there is no such requirement. But there is requirement for interoperability.=C2=A0 I can test for=20 interoperability because I can use some open-source stacks.=C2=A0 For one= ,=20 they are not interoperable among themselves when it comes to QoSData,=20 but _are_ interoperable if they use Data. > > I am not sure what to think about that. What would be the usefulness=20 > of a standard that prevents accessing part of the main markets? There are key core standards and extensions.=C2=A0=C2=A0 One cant put IPR= and=20 request paid expensive licenses for key standards. Extensions is another thing. May I ask you: are the markets open to entry of newcomers, or is it=20 locked by this and that manufacturer? Alex > If you believe that the standard is not relevant any more, then it=20 > would be better to state it clearly and the WG can proceed on this basi= s. > > BR, Michelle > > > Alex > > BR, > Michelle > > > 2018-02-28 11:09 GMT+01:00 Alexandre Petrescu > > >>: > > > > > =C2=A0 =C2=A0 Le 28/02/2018 =C3=A0 10:47, Katrin Sj=C3=B6berg a= =C3=A9crit : > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi Alexandre, All, > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 We are mixing apples and pears in t= his discussion and > it is very > =C2=A0 =C2=A0 =C2=A0 =C2=A0 frustrating. On one hand, the discu= ssion is about > detailed open > =C2=A0 =C2=A0 =C2=A0 =C2=A0 source software implementations tha= t do not support > QoS data with > =C2=A0 =C2=A0 =C2=A0 =C2=A0 how the EU mandate will look like. > > > =C2=A0 =C2=A0 EU must take great care when mandating technologi= es. > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 First of all, the QoS data is handl= ed by the chipset > covering > =C2=A0 =C2=A0 =C2=A0 =C2=A0 MAC+PHY on top of this LLC resides.= > > > =C2=A0 =C2=A0 I agree. > > =C2=A0 =C2=A0 We use ath9k driver and mac80211 module in the li= nux kernel. > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6 is on top of LLC. > > > =C2=A0 =C2=A0 Yes. > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 And suddenly the CAM specification,= which is residing > in the > =C2=A0 =C2=A0 =C2=A0 =C2=A0 facilities layer is discussed. > > > =C2=A0 =C2=A0 I agree.=C2=A0 Speaking CAM here is a stretch.=C2= =A0 The stretch > comes from my > =C2=A0 =C2=A0 single possible way (with BSM) to notice the exis= tence of > these QoS Data > =C2=A0 =C2=A0 headers.=C2=A0 I should have rather said "QoS Dat= a transported > message, e.g. > =C2=A0 =C2=A0 CAM or BSM". > > =C2=A0 =C2=A0 When I say I have problems with CAM, and I will p= ost a > critique of it, > =C2=A0 =C2=A0 is with the CAM message encoding, and lack of > interoperability of that > =C2=A0 =C2=A0 CAM.=C2=A0 I do not critique the fact that QoS Da= ta transports CAM. > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 What is the problem with making EDC= A mandatory in this > standard? > > > =C2=A0 =C2=A0 The problem is the lack of implementations. > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 The amendment IEEE 802.11e, which i= ntroduced the > concept of > =C2=A0 =C2=A0 =C2=A0 =C2=A0 EDCA, was > =C2=A0 =C2=A0 =C2=A0 =C2=A0 approved in 2005 and it was a uniqu= e selling point for > WiFi APs in > =C2=A0 =C2=A0 =C2=A0 =C2=A0 the beginning. EDCA has been around= for 13 years and > this standard > =C2=A0 =C2=A0 =C2=A0 =C2=A0 developed in 2018 for supporting IP= v6 in VANETs when > using IEEE > =C2=A0 =C2=A0 =C2=A0 =C2=A0 802.11p wants to use DCF due to som= e existing > implementation... For > =C2=A0 =C2=A0 =C2=A0 =C2=A0 me this is like being thrown back t= o the stone age. > > > =C2=A0 =C2=A0 Sorry, not the intention to throw back to stone a= ge. > > =C2=A0 =C2=A0 But I need implementation. > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 I am working for an OEM > > > =C2=A0 =C2=A0 Is OEM implementing QoS Data? > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 and I cannot accept that this stand= ard will allow IPv6 > traffic > =C2=A0 =C2=A0 =C2=A0 =C2=A0 over IEEE 802.11p using DCF since i= t might adventure road > =C2=A0 =C2=A0 =C2=A0 =C2=A0 traffic safety applications that ar= e under > development. We want > =C2=A0 =C2=A0 =C2=A0 =C2=A0 to reduce the number of accidents a= nd the > =C2=A0 =C2=A0 =C2=A0 =C2=A0 impact of the same by using IEEE 80= 2.11p with EDCA and > suddenly > =C2=A0 =C2=A0 =C2=A0 =C2=A0 messages such as CAMs might be star= ved out because > someone is > =C2=A0 =C2=A0 =C2=A0 =C2=A0 transmitting IPv6 traffic using DCF= =2E This is not > acceptable and once > =C2=A0 =C2=A0 =C2=A0 =C2=A0 again I want to emphasize that EN 3= 02 663 in Europe > requires EDCA, > =C2=A0 =C2=A0 =C2=A0 =C2=A0 which would prohibit this standard = to use the 5.9 GHz > band. > > > =C2=A0 =C2=A0 Hold on, hold on.=C2=A0 Excuse me. > > =C2=A0 =C2=A0 Road traffic safety applications is also a huge w= orry for > designers > =C2=A0 =C2=A0 using IP packets. > > =C2=A0 =C2=A0 But, the spectrum is for everyone to coexist and = interoperate. > > =C2=A0 =C2=A0 Alex > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 Best regards, Katrin > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 2018-02-28 10:27 GMT+01:00 Alexandr= e Petrescu > =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 Le 28/02/2018 =C3=A0 09:50, Mie Eur= a =C3=A9crit : > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi Alex, > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 I fully agree with Katrin and was a= bout to send a > similar post, > =C2=A0 =C2=A0 =C2=A0 =C2=A0 as the EDCA queues are used also by= ITS-G5 for the > DCC, which is > =C2=A0 =C2=A0 =C2=A0 =C2=A0 mandated by the new EU regulation. > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 I would really be surprised that EU= mandates something > that > =C2=A0 =C2=A0 =C2=A0 =C2=A0 depends on closed source, potential= ly favoring a > competitive > =C2=A0 =C2=A0 =C2=A0 =C2=A0 edge to a particular private intere= st.=C2=A0 But I am > optimistic: > =C2=A0 =C2=A0 =C2=A0 =C2=A0 given all the stimulation of open s= ource in EU projects I > =C2=A0 =C2=A0 =C2=A0 =C2=A0 believe EU regulators understand th= e implications > related to > =C2=A0 =C2=A0 =C2=A0 =C2=A0 cost, licensing, and interoperabili= ty. > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 Unless you want to rewrite all ETSI= standards and related > =C2=A0 =C2=A0 =C2=A0 =C2=A0 European norms in a couple of=C2=A0= weeks, > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 In one of these days I will post a = critique of the CAM > =C2=A0 =C2=A0 =C2=A0 =C2=A0 specification. > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 I would suggest to keep the old tex= t and guarantee > openness for > =C2=A0 =C2=A0 =C2=A0 =C2=A0 using > =C2=A0 =C2=A0 =C2=A0 =C2=A0 the IEEE 802.11-16 standard while c= omplying to local > regulations. > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 YEs, we need that. > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 But the old text says: > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 "In OCB mode, IPv6 packets MAY be t= ransmitted either > as "IEEE 802.11 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0Data" or alternatively = as "IEEE 802.11 QoS Data" > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 I implement only the 802.11 Data an= d my partner(s) use > equipment > =C2=A0 =C2=A0 =C2=A0 =C2=A0 bought from Unex that only implemen= ts QoS Data.=C2=A0 I > want our > =C2=A0 =C2=A0 =C2=A0 =C2=A0 software to interoperate. > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 If the text said just 'Data', then = I could direct my > partners to the > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0open source on the Inte= rnet.=C2=A0 But in current > situation my > =C2=A0 =C2=A0 =C2=A0 =C2=A0 partners direct me to Unex, which i= s expensive - it > has a cost. > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 I do not agree to continue this sit= uation. > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 Either the QoSData supporters direc= t me to an open source > =C2=A0 =C2=A0 =C2=A0 =C2=A0 implementation of QoSData now, or w= e relegate the QoS > discussion > =C2=A0 =C2=A0 =C2=A0 =C2=A0 for later. > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 I would also suggest to bring this = topic, as well as > the handling of > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0QoS for IPWAVE, which i= s an interesting topic, to the > =C2=A0 =C2=A0 =C2=A0 =C2=A0 re-chartering > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0discussion that was pro= posed by Carlos-Jesus a few > weeks ago. > =C2=A0 =C2=A0 =C2=A0 =C2=A0 The same as we did for ND or this n= ice multicast > address that > =C2=A0 =C2=A0 =C2=A0 =C2=A0 would be reserved for IPWAVE servic= es. > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 I agree. > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 BTW, you really plan to send CAMs d= irectly over IPv6, > without > =C2=A0 =C2=A0 =C2=A0 =C2=A0 any transport layer? I thought you = would use UDP, > which has a > =C2=A0 =C2=A0 =C2=A0 =C2=A0 "large" header as well. (found in a= n "old" post dated > back from > =C2=A0 =C2=A0 =C2=A0 =C2=A0 4 days ago. ) > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 At this time, with partners, we pon= der the idea of a > different > =C2=A0 =C2=A0 =C2=A0 =C2=A0 CAM if > =C2=A0 =C2=A0 =C2=A0 =C2=A0 you wish (not sure whether UDP, or = just IP, or 802.11 > Data, or > =C2=A0 =C2=A0 =C2=A0 =C2=A0 802.11 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 QoS Data).=C2=A0 This different CAM= is interoperable and > cheap to > =C2=A0 =C2=A0 =C2=A0 =C2=A0 produce. > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 CAM over UDP over IPv6 was already = produced by others > in other > =C2=A0 =C2=A0 =C2=A0 =C2=A0 project. I think they didnt bother = to standardise it, > but it > =C2=A0 =C2=A0 =C2=A0 =C2=A0 worked for them.=C2=A0 I am tempted= to copy from them. > > =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 CAM transported in IP may be a smal= ler packet than CAM > transported > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 in BTP and GeoNetworking. > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 2018-02-28 8:07 GMT+01:00 Alexandre= Petrescu > =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 Thank you for the message. > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 Le 28/02/2018 =C3=A0 07:08, Katrin = Sj=C3=B6berg a =C3=A9crit : [...] > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 This implies that the current IETF = proposal of using > IPv6 over > =C2=A0 =C2=A0 =C2=A0 =C2=A0 DCF would be impossible to use in E= urope. > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 Unless, of course, we suggest modif= y the ETSI > specification to allow > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0for 802.11 Data headers= as well as 802.11 QoS Data > headers. > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 (there are many reasons to ponder o= ver a major rehaul > of ETSI > =C2=A0 =C2=A0 =C2=A0 =C2=A0 ITS specifications, starting at the= CAM itself, that I > could > =C2=A0 =C2=A0 =C2=A0 =C2=A0 explain separately). > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 If all IPv6 trafffic has to use a c= ommon EDCA access > category, I > =C2=A0 =C2=A0 =C2=A0 =C2=A0 would support John's suggestion fro= m an earlier email > to fix > =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6 traffic to AC_BK. > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 This could be done.=C2=A0 On my sid= e I would need to see > running code for > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0it, and then there is n= eed of consensus (could be > obvious from > =C2=A0 =C2=A0 =C2=A0 =C2=A0 your > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0standpoint). > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 As J=C3=AAr=C3=B3me pointed out, we= use AC_BE for CAMs, > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thank you for this message.=C2=A0 I= understand you have an > implementation > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0of CAM sent with IEEE 8= 02.11 QoSData header.=C2=A0 Is it > the one from > =C2=A0 =C2=A0 =C2=A0 =C2=A0 Unex with Autotalks chipset? > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 (the CAM implementations I use are = from github.com > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 > and > =C2=A0 =C2=A0 =C2=A0 =C2=A0 ath9k driver; they dont generate 80= 2.11 QoSData > header, but use > =C2=A0 =C2=A0 =C2=A0 =C2=A0 802.11 Data header, hence no AC_BE)= =2E > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 and I know the US uses AC_BE for so= me of their safety > messages > =C2=A0 =C2=A0 =C2=A0 =C2=A0 as well. > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 I think me too, I have seen BSM mes= sages carried with > 802.11 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 QoSData headers, field Priority val= ue 2 Spare > (Background); I > =C2=A0 =C2=A0 =C2=A0 =C2=A0 guess that stands for AC_BK.=C2=A0 = But I could not figure > out what > =C2=A0 =C2=A0 =C2=A0 =C2=A0 was the software that implemented i= t. > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 Alex > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 Best regards, Katrin Sj=C3=B6berg > > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 2018-02-27 17:50 GMT+01:00 Tony Li = > =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 If someone knows how to generate a = QoSData transported > IP packet > =C2=A0 =C2=A0 =C2=A0 =C2=A0 with > =C2=A0 =C2=A0 =C2=A0 =C2=A0 linux open source then I am all ear= s. > > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 This is just a Small Matter Of Prog= ramming for anyone > with a bit > =C2=A0 =C2=A0 =C2=A0 =C2=A0 of kernel hacking experience and dr= iver sources. > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 Tony > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 ___________________________________= ____________ its > mailing list > its@ietf.org > > =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 >>>> > https://www.ietf.org/mailman/listinfo/its > > =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 ___________________________________= ____________ its > mailing list > its@ietf.org > > =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://www.ietf.org/mailman/listinfo/its > > =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 -- Michelle WETTERWALD > > > > =C2=A0 =C2=A0 _______________________________________________ > =C2=A0 =C2=A0 its mailing list > its@ietf.org > > https://www.ietf.org/mailman/listinfo/its > > =C2=A0 =C2=A0 > > > > > > --=20 > Michelle Wetterwald > michelle.wetterwald@gmail.com > > > > > > > > > --=20 > Michelle Wetterwald > michelle.wetterwald@gmail.com --------------3C3691B8A5CCEFFAAE6EE6E3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable 


--
Alexandre Petrescu
alexandre.petrescu@cea.fr, t=C3=A9l 0169089223
Le 28/02/2018 =C3=A0 14:58, Michelle Wetterwald a =C3=A9crit=C2=A0:
Hi Alex,

Answers inline.

2018-02-28 12:22 GMT+01:00 Alexandre= PETRESCU <alexandre.petrescu@cea.fr>= ;:
[trimmed the CC because mailer problems]

Le 28/02/2018 =C3=A0 11:34, Michelle Wetterwald a =C3=A9c= rit=C2=A0:
Hi Alex,

Regarding the interoperability between different implementations, it has been fully validated during numerous plugtests events=C2=A0in EU and US, gathering = a large set of different implementations. For the EU ones, the reports are freely available on the ETSI=C2=A0= web site.

I am using the wireshark dissectors on the ETSI web site.

I can tell they show lack of interoperability: several CAM messages from several stacks are not understood by these wireshark dissectors.

Can you give references to these stacks?=C2=A0

github.com 'rendits', 'vanetza', 'driveits', 'geonetworking', 'btpsap'.

None puts a QoSData header, each puts a 'Data' header.

(but none sends CAM as IP messages either).


The ETSI wireshark dissectors have another problem themselves: they are not integrated in the main wireshark software.=C2=A0 It's just ETSI's point of view.=

I am sorry to hear that the open source implementation that you are using has some limitations. I remember that one of the participants to the last PlugTest in Livorno (Nov 2016) explained to me he had extended the open source software to use his computer=C2=A0to monitor=C2=A0the traffic exchanged on the 802.11p. So h= e made his Ath implementation fully interoperable with those from the other vendors. Maybe you can apply=C2=A0similar upgrades to your testing implementations?

Can you tell me who is that participant so I can contact?

Sorry, NDA applies here.=C2=A0But the list of vendors is= in the report.

The reference to the report please?


Again, I disagree with the change you propose in the text of the draft, as it=C2=A0goes against=C2=A0the *existing* = EU regulations.=C2=A0Compliance with the modified text wou= ld prevent=C2=A0vendors from accessing the EU market.

 Accessing EU market is a good thing, but customer lock in may not be that good.

This is not customer lock-in, there are several and diverse implementations available (BTW, this is more an L2 than an L3-IETF related=C2=A0topic), the only thing is that= you have to pay for getting them, which is=C2=A0often part=C2=A0= of the market rules, right?

There are software features in limited deployment that deserve a certain amount of money.
But key aspects like running IP are free of charge.

For example, it is worth attaching a price tag for software in a limited deployment (e.g. this highway), but IP is much wider scale.=C2= =A0 You cant put a price tag on it.

Is there a requirement that an RFC can be approved only if several open source implementations are available?<= /div>

No, there is no such requirement.

But there is requirement for interoperability.=C2=A0 I can test for interoperability because I can use some open-source stacks.=C2=A0 For= one, they are not interoperable among themselves when it comes to QoSData, but _are_ interoperable if they use Data.


I am not sure what to think about that. What would be the usefulness of a standard that prevents accessing part of the main markets?

There are key core standards and extensions.=C2=A0=C2=A0 One cant put= IPR and request paid expensive licenses for key standards.

Extensions is another thing.

May I ask you: are the markets open to entry of newcomers, or is it locked by this and that manufacturer?

Alex

If you believe that the standard is not relevant any more, then it would be better to state it clearly and the WG can proceed on this basis.

BR, Michelle
=C2=A0

Alex

BR,
Michelle


2018-02-28 11:09 GMT+01:00 Alexandre Petrescu <alexandre.pe= trescu@gmail.com <mailto:alexandre.pe= trescu@gmail.com>>:




=C2=A0 =C2=A0 Le 28/02/2018 =C3=A0 10:47, Katrin Sj=C3= =B6berg a =C3=A9crit :

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi Alexandre, All,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 We are mixing apples and = pears in this discussion and it is very
=C2=A0 =C2=A0 =C2=A0 =C2=A0 frustrating. On one hand,= the discussion is about detailed open
=C2=A0 =C2=A0 =C2=A0 =C2=A0 source software implement= ations that do not support QoS data with
=C2=A0 =C2=A0 =C2=A0 =C2=A0 how the EU mandate will l= ook like.


=C2=A0 =C2=A0 EU must take great care when mandating technologies.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 First of all, the QoS dat= a is handled by the chipset covering
=C2=A0 =C2=A0 =C2=A0 =C2=A0 MAC+PHY on top of this LL= C resides.


=C2=A0 =C2=A0 I agree.

=C2=A0 =C2=A0 We use ath9k driver and mac80211 module= in the linux kernel.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6 is on top of LLC.

=C2=A0 =C2=A0 Yes.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 And suddenly the CAM spec= ification, which is residing in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 facilities layer is discu= ssed.


=C2=A0 =C2=A0 I agree.=C2=A0 Speaking CAM here is a s= tretch.=C2=A0 The stretch comes from my
=C2=A0 =C2=A0 single possible way (with BSM) to notic= e the existence of these QoS Data
=C2=A0 =C2=A0 headers.=C2=A0 I should have rather sai= d "QoS Data transported message, e.g.
=C2=A0 =C2=A0 CAM or BSM".

=C2=A0 =C2=A0 When I say I have problems with CAM, an= d I will post a critique of it,
=C2=A0 =C2=A0 is with the CAM message encoding, and l= ack of interoperability of that
=C2=A0 =C2=A0 CAM.=C2=A0 I do not critique the fact t= hat QoS Data transports CAM.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 What is the problem with = making EDCA mandatory in this standard?


=C2=A0 =C2=A0 The problem is the lack of implementati= ons.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 The amendment IEEE 802.11= e, which introduced the concept of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 EDCA, was
=C2=A0 =C2=A0 =C2=A0 =C2=A0 approved in 2005 and it w= as a unique selling point for WiFi APs in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the beginning. EDCA has b= een around for 13 years and this standard
=C2=A0 =C2=A0 =C2=A0 =C2=A0 developed in 2018 for sup= porting IPv6 in VANETs when using IEEE
=C2=A0 =C2=A0 =C2=A0 =C2=A0 802.11p wants to use DCF = due to some existing implementation... For
=C2=A0 =C2=A0 =C2=A0 =C2=A0 me this is like being thr= own back to the stone age.


=C2=A0 =C2=A0 Sorry, not the intention to throw back = to stone age.

=C2=A0 =C2=A0 But I need implementation.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I am working for an OEM

=C2=A0 =C2=A0 Is OEM implementing QoS Data?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 and I cannot accept that = this standard will allow IPv6 traffic
=C2=A0 =C2=A0 =C2=A0 =C2=A0 over IEEE 802.11p using D= CF since it might adventure road
=C2=A0 =C2=A0 =C2=A0 =C2=A0 traffic safety applicatio= ns that are under development. We want
=C2=A0 =C2=A0 =C2=A0 =C2=A0 to reduce the number of a= ccidents and the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 impact of the same by usi= ng IEEE 802.11p with EDCA and suddenly
=C2=A0 =C2=A0 =C2=A0 =C2=A0 messages such as CAMs mig= ht be starved out because someone is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 transmitting IPv6 traffic= using DCF. This is not acceptable and once
=C2=A0 =C2=A0 =C2=A0 =C2=A0 again I want to emphasize= that EN 302 663 in Europe requires EDCA,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 which would prohibit this= standard to use the 5.9 GHz band.


=C2=A0 =C2=A0 Hold on, hold on.=C2=A0 Excuse me.

=C2=A0 =C2=A0 Road traffic safety applications is als= o a huge worry for designers
=C2=A0 =C2=A0 using IP packets.

=C2=A0 =C2=A0 But, the spectrum is for everyone to co= exist and interoperate.

=C2=A0 =C2=A0 Alex


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Best regards, Katrin

=C2=A0 =C2=A0 =C2=A0 =C2=A0 2018-02-28 10:27 GMT+01:0= 0 Alexandre Petrescu
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <alexandr= e.petrescu@gmail.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:alexandr= e.petrescu@gmail.com>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:alexandre.pe= trescu@gmail.com

=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:alexandr= e.petrescu@gmail.com>>>:




=C2=A0 =C2=A0 =C2=A0 =C2=A0 Le 28/02/2018 =C3=A0 09:5= 0, Mie Eur a =C3=A9crit :

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi Alex,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I fully agree with Katrin= and was about to send a similar post,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 as the EDCA queues are us= ed also by ITS-G5 for the DCC, which is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mandated by the new EU re= gulation.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 I would really be surpris= ed that EU mandates something that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 depends on closed source,= potentially favoring a competitive
=C2=A0 =C2=A0 =C2=A0 =C2=A0 edge to a particular priv= ate interest.=C2=A0 But I am optimistic:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 given all the stimulation= of open source in EU projects I
=C2=A0 =C2=A0 =C2=A0 =C2=A0 believe EU regulators und= erstand the implications related to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cost, licensing, and inte= roperability.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Unless you want to rewrit= e all ETSI standards and related
=C2=A0 =C2=A0 =C2=A0 =C2=A0 European norms in a coupl= e of=C2=A0 weeks,


=C2=A0 =C2=A0 =C2=A0 =C2=A0 In one of these days I wi= ll post a critique of the CAM
=C2=A0 =C2=A0 =C2=A0 =C2=A0 specification.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I would suggest to keep t= he old text and guarantee openness for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 using
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the IEEE 802.11-16 standa= rd while complying to local regulations.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 YEs, we need that.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 But the old text says:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "In OCB mode, IPv6 packet= s MAY be transmitted either as "IEEE 802.11
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0Data" or alte= rnatively as "IEEE 802.11 QoS Data"


=C2=A0 =C2=A0 =C2=A0 =C2=A0 I implement only the 802.= 11 Data and my partner(s) use equipment
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bought from Unex that onl= y implements QoS Data.=C2=A0 I want our
=C2=A0 =C2=A0 =C2=A0 =C2=A0 software to interoperate.=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 If the text said just 'Da= ta', then I could direct my partners to the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0open source o= n the Internet.=C2=A0 But in current situation my
=C2=A0 =C2=A0 =C2=A0 =C2=A0 partners direct me to Une= x, which is expensive - it has a cost.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I do not agree to continu= e this situation.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Either the QoSData suppor= ters direct me to an open source
=C2=A0 =C2=A0 =C2=A0 =C2=A0 implementation of QoSData= now, or we relegate the QoS discussion
=C2=A0 =C2=A0 =C2=A0 =C2=A0 for later.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I would also suggest to b= ring this topic, as well as the handling of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0QoS for IPWAV= E, which is an interesting topic, to the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 re-chartering
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0discussion th= at was proposed by Carlos-Jesus a few weeks ago.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 The same as we did for ND= or this nice multicast address that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 would be reserved for IPW= AVE services.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 I agree.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 BTW, you really plan to s= end CAMs directly over IPv6, without
=C2=A0 =C2=A0 =C2=A0 =C2=A0 any transport layer? I th= ought you would use UDP, which has a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "large" header as well. (= found in an "old" post dated back from
=C2=A0 =C2=A0 =C2=A0 =C2=A0 4 days ago. )


=C2=A0 =C2=A0 =C2=A0 =C2=A0 At this time, with partne= rs, we ponder the idea of a different
=C2=A0 =C2=A0 =C2=A0 =C2=A0 CAM if
=C2=A0 =C2=A0 =C2=A0 =C2=A0 you wish (not sure whethe= r UDP, or just IP, or 802.11 Data, or
=C2=A0 =C2=A0 =C2=A0 =C2=A0 802.11
=C2=A0 =C2=A0 =C2=A0 =C2=A0 QoS Data).=C2=A0 This dif= ferent CAM is interoperable and cheap to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 produce.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 CAM over UDP over IPv6 wa= s already produced by others in other
=C2=A0 =C2=A0 =C2=A0 =C2=A0 project. I think they did= nt bother to standardise it, but it
=C2=A0 =C2=A0 =C2=A0 =C2=A0 worked for them.=C2=A0 I = am tempted to copy from them.

=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 CAM transported in IP may= be a smaller packet than CAM transported

=C2=A0 =C2=A0 =C2=A0 =C2=A0 in BTP and GeoNetworking.=


=C2=A0 =C2=A0 =C2=A0 =C2=A0 2018-02-28 8:07 GMT+01:00= Alexandre Petrescu
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <alexandr= e.petrescu@gmail.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:alexandr= e.petrescu@gmail.com>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:alexandr= e.petrescu@gmail.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:alexandr= e.petrescu@gmail.com>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:alexandr= e.petrescu@gmail.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:alexandr= e.petrescu@gmail.com>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:alexandr= e.petrescu@gmail.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:alexandr= e.petrescu@gmail.com>>>>:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thank you for the message= =2E

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Le 28/02/2018 =C3=A0 07:0= 8, Katrin Sj=C3=B6berg a =C3=A9crit : [...]

=C2=A0 =C2=A0 =C2=A0 =C2=A0 This implies that the cur= rent IETF proposal of using IPv6 over
=C2=A0 =C2=A0 =C2=A0 =C2=A0 DCF would be impossible t= o use in Europe.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Unless, of course, we sug= gest modify the ETSI specification to allow
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0for 802.11 Da= ta headers as well as 802.11 QoS Data headers.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 (there are many reasons t= o ponder over a major rehaul of ETSI
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ITS specifications, start= ing at the CAM itself, that I could
=C2=A0 =C2=A0 =C2=A0 =C2=A0 explain separately).

=C2=A0 =C2=A0 =C2=A0 =C2=A0 If all IPv6 trafffic has = to use a common EDCA access category, I
=C2=A0 =C2=A0 =C2=A0 =C2=A0 would support John's sugg= estion from an earlier email to fix
=C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6 traffic to AC_BK.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 This could be done.=C2=A0= On my side I would need to see running code for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0it, and then = there is need of consensus (could be obvious from
=C2=A0 =C2=A0 =C2=A0 =C2=A0 your
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0standpoint).<= br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 As J=C3=AAr=C3=B3me point= ed out, we use AC_BE for CAMs,


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thank you for this messag= e.=C2=A0 I understand you have an implementation
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0of CAM sent w= ith IEEE 802.11 QoSData header.=C2=A0 Is it the one from
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Unex with Autotalks chips= et?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 (the CAM implementations = I use are from github.= com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <http://gith= ub.com> <http://gith= ub.com> <http://gith= ub.com> and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ath9k driver; they dont gen= erate 802.11 QoSData header, but use
=C2=A0 =C2=A0 =C2=A0 =C2=A0 802.11 Data header, hence n= o AC_BE).

=C2=A0 =C2=A0 =C2=A0 =C2=A0 and I know the US uses AC_B= E for some of their safety messages
=C2=A0 =C2=A0 =C2=A0 =C2=A0 as well.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 I think me too, I have seen= BSM messages carried with 802.11
=C2=A0 =C2=A0 =C2=A0 =C2=A0 QoSData headers, field Prio= rity value 2 Spare (Background); I
=C2=A0 =C2=A0 =C2=A0 =C2=A0 guess that stands for AC_BK= =2E=C2=A0 But I could not figure out what
=C2=A0 =C2=A0 =C2=A0 =C2=A0 was the software that imple= mented it.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Alex


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Best regards, Katrin Sj=C3=B6= berg



=C2=A0 =C2=A0 =C2=A0 =C2=A0 2018-02-27 17:50 GMT+01:00 = Tony Li <tony.li@tony.li
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:tony.li@to= ny.li> <mailto:tony.li@to= ny.li
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:tony.li@to= ny.li>> <mailto:tony.li@to= ny.li
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:tony.li@to= ny.li> <mailto:tony.li@to= ny.li
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:tony.li@tony= =2Eli>>> <mailto:tony.li@tony= =2Eli
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:tony.li@to= ny.li> <mailto:tony.li@to= ny.li
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:tony.li@to= ny.li>> <mailto:tony.li@to= ny.li
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:tony.li@to= ny.li> <mailto:tony.li@to= ny.li
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:tony.li@to= ny.li>>>>>:


=C2=A0 =C2=A0 =C2=A0 =C2=A0 If someone knows how to gen= erate a QoSData transported IP packet
=C2=A0 =C2=A0 =C2=A0 =C2=A0 with
=C2=A0 =C2=A0 =C2=A0 =C2=A0 linux open source then I am= all ears.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 This is just a Small Matter= Of Programming for anyone with a bit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 of kernel hacking experienc= e and driver sources.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Tony

=C2=A0 =C2=A0 =C2=A0 =C2=A0 ___________________________= ____________________ its mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 its@ietf.org <mailto:= its@ietf.org> <mailto:its@ietf.o= rg
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:its@ietf.o= rg>> <mailto:its@ietf.o= rg
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:its@ietf.o= rg> <mailto:its@ietf.o= rg
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:its@ietf.org= >>> <mailto:its@ietf.org

=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:its@ietf= =2Eorg> <mailto:its@ietf= =2Eorg
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:its@ietf= =2Eorg>> <mailto:its@ietf= =2Eorg
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:its@ietf= =2Eorg> <mailto:its@ietf= =2Eorg
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:its@ietf= =2Eorg>>>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailm= an/listinfo/its
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailm= an/listinfo/its>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailm= an/listinfo/its
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailm= an/listinfo/its>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailm= an/listinfo/its
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailm= an/listinfo/its>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailm= an/listinfo/its
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailm= an/listinfo/its>>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailm= an/listinfo/its
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailm= an/listinfo/its>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailm= an/listinfo/its
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailm= an/listinfo/its>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailm= an/listinfo/its
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailm= an/listinfo/its>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailm= an/listinfo/its
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailm= an/listinfo/its>>>>



=C2=A0 =C2=A0 =C2=A0 =C2=A0 _________________________= ______________________ its mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 its@ietf= =2Eorg <mailto:its@ietf= =2Eorg> <mailto:its@ietf= =2Eorg
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:its@ietf= =2Eorg>> <mailto:its@ietf= =2Eorg
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:its@ietf= =2Eorg> <mailto:its@ietf= =2Eorg
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:its@ietf= =2Eorg>>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailm= an/listinfo/its
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailm= an/listinfo/its>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailm= an/listinfo/its
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailm= an/listinfo/its>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailm= an/listinfo/its
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailm= an/listinfo/its>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailm= an/listinfo/its
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailm= an/listinfo/its>>>




=C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Michelle WETTERWALD



=C2=A0 =C2=A0 ____________________________________= ___________
=C2=A0 =C2=A0 its mailing list
 =C2=A0 =C2=A0 its@ietf.org <mailto:= its@ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman= /listinfo/its
=C2=A0 =C2=A0 <https://www.ietf.org/mailman= /listinfo/its>




 --
Michelle Wetterwald
michelle.w= etterwald@gmail.com <mailto:michelle.w= etterwald@gmail.com>




--
Michelle Wetterwald

--------------3C3691B8A5CCEFFAAE6EE6E3-- --------------ms080103040804000601090504 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 C2AwggWCMIIEaqADAgECAgIYEjANBgkqhkiG9w0BAQsFADA9MQswCQYDVQQGEwJGUjEMMAoG A1UECgwDQ0VBMSAwHgYDVQQDDBdDRUEgQUMgVXRpbGlzYXRldXIgMjAzMTAeFw0xNzExMjcx MTUzMThaFw0yMDExMjcxMTUzMThaMFUxCzAJBgNVBAYTAkZSMQwwCgYDVQQKDANjZWExFDAS BgNVBAsMC1V0aWxpc2F0ZXVyMSIwIAYDVQQDDBlQRVRSRVNDVSBBbGV4YW5kcmUgMjIyMDQw MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxflZNm4uFO1gfpGFsdm8+ijK5FnS fr24rrT8KW0oz8cV8u+UZ55M/bqidvqSXGGz3C480T6DZsfXoTsvqD5ZLE+F8II6J2g5NU8J mKX95WafZuQo8DC2EnkDu2jH0kU58PGyJqzlQ1ThJw+E90C4yg55q5ekRRv13L7W4D38+eO6 2LLQyplKiyjXJRFnrYPCQWKdmaoa3+gXm88N0z9SH1VnKDB7nN0WKcgkB8xFFW9ShkDriTj4 WOtBlX5I49L6nc2f5jgRR7ur63vWwWV57guJDYgdbciTIMsoanyOMkblfZko71HlcYOQcext cIzx7W14tLdo5Lbk5sbTLTPCUwIDAQABo4ICcjCCAm4wHQYDVR0OBBYEFJiCut4KQg9+Gt1J iu2nte1qatj0MB8GA1UdIwQYMBaAFOEcbJodbegbsvFP/cZ0LCdXBYhzMIHIBgNVHSAEgcAw gb0wgboGCisGAQQB4GABBgcwgaswJQYIKwYBBQUHAgEWGWh0dHA6Ly93d3ctaWdjLmNlYS5m ci9wYy8wgYEGCCsGAQUFBwICMHUwDRYDQ0VBMAYCAQICAQAaZFZvdXMgZGV2ZXogYWNjZXB0 ZXIgbGEgcG9saXRpcXVlIGRlIGNlcnRpZmljYXRpb24gYXZhbnQgZCd1dGlsaXNlciBjZSBj ZXJ0aWZpY2F0LCBjZi4gd3d3LWlnYy5jZWEuZnIwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAkBgNVHREEHTAbgRlhbGV4YW5kcmUucGV0cmVzY3VAY2VhLmZyMFEGA1Ud HwRKMEgwRqBEoEKGQGh0dHA6Ly9jcmwtYWMtdXRpbGlzYXRldXIuY2VhLmZyL2NybC9jZWFf YWNfdXRpbGlzYXRldXJfMjAzMS5jcmwwcwYJYIZIAYb4QgENBGYWZFZvdXMgZGV2ZXogYWNj ZXB0ZXIgbGEgcG9saXRpcXVlIGRlIGNlcnRpZmljYXRpb24gYXZhbnQgZCd1dGlsaXNlciBj ZSBjZXJ0aWZpY2F0LCBjZi4gd3d3LWlnYy5jZWEuZnIwUAYIKwYBBQUHAQEERDBCMEAGCCsG AQUFBzAChjRodHRwOi8vd3d3LWlnYy5jZWEuZnIvYWMvY2VhX2FjX3V0aWxpc2F0ZXVyXzIw MzEuY2VyMA0GCSqGSIb3DQEBCwUAA4IBAQC77Z707Ko1uZGK3utBHUQUUyTD4pRjmFxFozU2 kwdk6a8hdHTaaRqjPSUIbfeoZVpZCynd12VynalWcoXM40Bf+bhMN3pAavULka7+oAEQyYuI 7OQ8dE/t3R43Ai8dx0npk+ziPQrlD7tAgMsK8Qd+V7ZhUI0A1ANJXWzZ7DYV6jR4t9nwxlsk Kll2PaD+hTIiP86YVsiHMiu0ZhRGrYJf/U1myMQc28b4LdTofpwh22z8DLHlFoGjGipwYbpb oFn998AOsc2fvujB0Y+AahlKK8lecqOTXJNQaRUrE1dl/n2Xu8GK3KIRtcoo7QTDOTzx/BiN 5EC8XdsqNMRXmc1GMIIF1jCCA76gAwIBAgIBCTANBgkqhkiG9w0BAQsFADBeMQswCQYDVQQG EwJGUjEMMAoGA1UECgwDQ0VBMRcwFQYDVQQLDA4wMDAyIDc3NTY4NTAxOTELMAkGA1UECwwC QUMxGzAZBgNVBAMMEkNFQSBBQyBSYWNpbmUgMjA0MTAeFw0xNjA0MTkwNzM0NTNaFw0zMTA0 MTYwNzM0NTNaMD0xCzAJBgNVBAYTAkZSMQwwCgYDVQQKDANDRUExIDAeBgNVBAMMF0NFQSBB QyBVdGlsaXNhdGV1ciAyMDMxMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvWDF ixM71KL9p38YSLTYgXRTceZWAD0RSg7NylBGPXNHYbceuGKDhRIeX58FIi+JiVFFejFI6jpE impm3MgsXQ5O08clieLLBNCjVzpAMPTO5lXuz0j28ey5AVPwhEw7ngUCtmHaWh8v1eY6xrLV C/porFjHycFbd4oj6QLfyghoo/RXWglYPNjilkCBrRe+jKxM3QYYVD6rouvGrF58SlpGCfwX FA88OcYC24kH8YOOYvh8Ld/p+ty7QUiDq53YmVZ5iDUc3pt3r9pN61zJ83FPEhZbC8+KHDTb D0TXaot2No4u8wk0s0jBpicVN4hxfS+LiFcTsFmsorDW6L7GIwIDAQABo4IBvjCCAbowDwYD VR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQU4Rxsmh1t6Buy8U/9xnQsJ1cFiHMwHwYDVR0jBBgw FoAUoBGJ+Jq/poSxKQc3U0Htl5VCex0wgcgGA1UdIASBwDCBvTCBugYKKwYBBAHgYAEGBzCB qzAlBggrBgEFBQcCARYZaHR0cDovL3d3dy1pZ2MuY2VhLmZyL3BjLzCBgQYIKwYBBQUHAgIw dTANFgNDRUEwBgIBAgIBABpkVm91cyBkZXZleiBhY2NlcHRlciBsYSBwb2xpdGlxdWUgZGUg Y2VydGlmaWNhdGlvbiBhdmFudCBkJ3V0aWxpc2VyIGNlIGNlcnRpZmljYXQsIGNmLiB3d3ct aWdjLmNlYS5mcjAOBgNVHQ8BAf8EBAMCAQYwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2Ny bC1hYy1yYWNpbmUuY2VhLmZyL2NybC9hYy1yYWNpbmUtMjA0MS5jcmwwRwYIKwYBBQUHAQEE OzA5MDcGCCsGAQUFBzAChitodHRwOi8vd3d3LWlnYy5jZWEuZnIvYWMvYWMtcmFjaW5lLTIw NDEuY2VyMA0GCSqGSIb3DQEBCwUAA4ICAQALtUqrZEfol/oEtIOlM3SaHCPHblVt8TdY88IB 3qCpg5lJ8rWU7g8jAsc0moYYor0hrvb17XjXECYL76MOJBCQYEKfWnkTYqAyMTsKee+kK8Xw 5P8wzPPjXA3tUvRm8oHEGYcSfLEzdj+UT+F+E4MnkV1nUOCEJq2Krx+lu1IJQJRCbjUQF+ES ICwTDQE7FHzGGKVsGOEjkbYhDS/+4r5GPbc983y5d94S0ISYmM1klOSeRNGelcnl0fJbH0zs 1y8+YJWg3gWL1j7aNo+sQQCrPrYQnmufAm3HQr42+u0AbFvOX5XKwF1YAx7XpJWuUGeXkjqx 8xIWisShEc/S+Gm4mdKcUgym5C7gkA0nzbmBIJI3iSLRqk/m2Re7R5vC3fF3uyfT9mGeAnNa E9b7ZkBzhrSfFToylbvqnAYvxVcYFCE1XhVMHxKvRiiW9L/u9vHuAbTRaXBFzObrXF6UohLR XNqJKKaPYkRLgrVm6b303Ogp50u6DiSgvI4Dh7x9K9IqpJ/+csqdXpoVdhQjhcA5JZRNrv3q 0zVf/Q93GT3VHOgaeMkEa9Sn30x4GmZfuNon/zSagJZkLO72K3wa6XQbGf8MZP/QtSMGPzrN eVUgp4H6l9hcQINVHmimTrcZa7/22K0FD56epY/OqAXwIWOb9i+jdDIoW5c5pW+/BDDasTGC AvMwggLvAgEBMEMwPTELMAkGA1UEBhMCRlIxDDAKBgNVBAoMA0NFQTEgMB4GA1UEAwwXQ0VB IEFDIFV0aWxpc2F0ZXVyIDIwMzECAhgSMA0GCWCGSAFlAwQCAQUAoIIBgTAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODAyMjgxNDA4NDZaMC8GCSqGSIb3 DQEJBDEiBCCgmx12o0U/vXnUsJbFtlI7df0BX+b0vPYDxBr0x47d5TBSBgkrBgEEAYI3EAQx RTBDMD0xCzAJBgNVBAYTAkZSMQwwCgYDVQQKDANDRUExIDAeBgNVBAMMF0NFQSBBQyBVdGls aXNhdGV1ciAyMDMxAgIYEjBUBgsqhkiG9w0BCRACCzFFoEMwPTELMAkGA1UEBhMCRlIxDDAK BgNVBAoMA0NFQTEgMB4GA1UEAwwXQ0VBIEFDIFV0aWxpc2F0ZXVyIDIwMzECAhgSMGwGCSqG SIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJ KoZIhvcNAQEBBQAEggEAeCdNJgOp/ayCZ8zbCgejVZz+mxEX43miXTbiNnkSlrqmh1W2u7kV jjEtoKCjBZb5QKcBQMsIretcLowqxE3PuPXcFq9NSO+8ZzXyiWeyVREUgUSkpiu5Wipk/WTK B6Tif8YnUQ1tqQrl6BBjIUdmAHcv0zhvkKhpLc6kxz37NwB4U5GZ8jAJuRwzhHqr7d6osBtN 3XMT51d2ZctmqeJ8R1XWmKGni4udUsKnj82ztMSuZfx20PqeKyqhjc/LZVgrCMcTSgZfL2qB i5C/GbB6diu0ugUqciJ+HQvvACZ+78fEiFLJOTUCS+8jj1Yd9YqTFOTvrnWRhUwajz96RnjR OQAAAAAAAA== --------------ms080103040804000601090504-- From nobody Wed Feb 28 06:11:45 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C20A2126BFD for ; Wed, 28 Feb 2018 06:11:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (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 qr7eGvgdXunX for ; Wed, 28 Feb 2018 06:11:41 -0800 (PST) Received: from mail-pg0-x244.google.com (mail-pg0-x244.google.com [IPv6:2607:f8b0:400e:c05::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B2B5126DED for ; Wed, 28 Feb 2018 06:11:41 -0800 (PST) Received: by mail-pg0-x244.google.com with SMTP id l131so980622pga.2 for ; Wed, 28 Feb 2018 06:11:41 -0800 (PST) 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=4XFsp0JZrLeFMgBxtxdyxyl71G3ftgAcGXBcdSLSaog=; b=RRj+l+zS5hKt5X9CzmrxMztHtICjKiQ4XSCkVtyXjSdUQNgpVCmUa+k/XQJ62AEdR5 y7Pw3/k3RBzO5i1xKtIwr6l8YBsav/MLIeTh8Chh1QElVJl+C1E7WJG4pb3tQ0OX4i/3 QXbjIvIIAKTF69vjsHBq5gkq0SAXy28oSyD5I= 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=4XFsp0JZrLeFMgBxtxdyxyl71G3ftgAcGXBcdSLSaog=; b=ItzRKLXguSuNpugk2501S/vfDEMx9JPdnHP72ZSpVmVJdW4sKzxWgpIB500PQYCRHN w9ZMgIKZB60fQamGqZqdDAANOvh3m/MeaJ7xEiG6cbTGWbPwQKOfeCQ7yxrIga+vcsyi uGq9QQDkyaQGHs0y2DBHzclydJ8zbRIY1oWfjfo6nppPNfb42o1MNN7g04Emp3LNjQKF V1AItVi0buAmoCjl049Af8lIfjV590PL3KFzoxSwo+8d8MoQc1TCjtWZecG//0lkfdu2 WsAYNAmSFPrLXqBeXnsBFwyfTbY21pVDrBwN0fYc8+nuxDQmHQuiDiuVwapZ6XctF+lt fkmA== X-Gm-Message-State: APf1xPDV+mx+hII4S8eGHywMF5pz4FarHYhUPbUHf21ROS8Myh1RMnWl AzMH2+nj4LzOFKi25ZwA0Q/cDMwRdy/jNYB7heJPJw== X-Google-Smtp-Source: AH8x224ZMt1GS3XFtSb2B3jqUG0piecqI/GAV2ojlWqajanxE39OfBXvYLyHJE2nPeBMNZ0ck4ud++Yz8FZSIEEJZfA= X-Received: by 10.99.122.86 with SMTP id j22mr14389842pgn.351.1519827100204; Wed, 28 Feb 2018 06:11:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.186.163 with HTTP; Wed, 28 Feb 2018 06:11:19 -0800 (PST) In-Reply-To: References: <002901d3af20$b966e960$2c34bc20$@eurecom.fr> <002601d3afc4$a10fbb90$e32f32b0$@eurecom.fr> <71309c28-9d7e-d277-a3b0-46d1a3b4042e@gmail.com> <004701d3afd0$63867190$2a9354b0$@eurecom.fr> <461166f2-f3cc-e749-3628-f1d87104200b@gmail.com> <4997BFDE-1B3F-4F17-9742-28F23F082A15@tony.li> <596b8280-af45-aca2-9ea9-b05dce716ff1@gmail.com> <88030b0f-128a-b185-e9b8-f13b76878a74@gmail.com> <14621_1519817026_5A969141_14621_16048_1_c1dce555-5262-5a75-730d-401a1b6251e1@cea.fr> <3622fb0f-c859-9f08-1441-6b5f1d6d531f@gmail.com> From: William Whyte Date: Wed, 28 Feb 2018 09:11:19 -0500 Message-ID: To: Michelle Wetterwald Cc: Alexandre Petrescu , its Content-Type: multipart/alternative; boundary="f403045c63c46da84e056646528a" Archived-At: Subject: Re: [ipwave] Critique of CAM message format 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, 28 Feb 2018 14:11:44 -0000 --f403045c63c46da84e056646528a Content-Type: text/plain; charset="UTF-8" Hi Alex -- I'm with Michelle that this isn't the forum for that discussion, but just to note, the CAM specification is in ASN.1. ASN.1 identifies the information fields to be included in a data structure, and a given data structure can then be encoded with one of a number of standardized encoding rules. For CAM, the encoding rules are the Unaligned Packed Encoding Rules. These are all well defined, and the encoding of CAM is unambiguous. Cheers, William On Wed, Feb 28, 2018 at 8:59 AM, Michelle Wetterwald wrote: > Hi Alex, > > I am not representing ETSI and I am wondering whether this is the right > place to discuss about the content of ETSI standards. > I rather encourage you to submit a contribution to that group. > > BR, Michelle > > 2018-02-28 13:07 GMT+01:00 Alexandre Petrescu < > alexandre.petrescu@gmail.com>: > >> Michelle, >> >> This is a critique of the CAM message format ETSI EN 302 637-2 V1.3.1 >> interpreted together with ETSI TS 102 894-2 V1.2.1 "Applications and >> facilities layer common data dictionary". >> >> (I purposefully exclude the QoSData vs Data part; it is another >> discussion) >> >> Here is my critique of specification of CAM message format: >> >> - in general, it is impossible to say, when reading the specification of >> the CAM message, what is the length of some of the fields. >> Because of this reason, it is impossible to decide what is the total >> length of a minimal CAM without optional parts. >> It is impossible to answer whether a CAM fits in the MTU of >> IPv6-over-OCB. >> Because of this, it is impossible to easily obtain interoperable >> implementations. >> >> Example: what is the length of the Latitude field? The spec gives the >> value range -900000000..900000001, but does not say on how many bits. >> That value range can fit in 31bit (upper (log_2 (1800000002))). >> Some implementations do it on 32bit. But why 32 bit and not 31bit? >> >> (other fields where this doubt exists can be listed here: Acceleration >> Confidence values 0 to 102 but on how many bits, and many others). >> >> - the encoding is not expressed as Type Length Value (TLV). This is a >> common way of expressing message encoding when writing Internet >> Drafts. >> >> Because of this, a receiver of CAM has difficulty in dealing with >> options, variable lengths, etc. >> >> - the GenerationDeltaTime field is within a given window of width 16bit >> in milliseconds, and does not represent absolute time. It is the >> remainder of timestamp/65k. The timestamp itself is not sent. This >> is obviously a problem. Ideally, one should the use 64bit timestamp >> instead, not some remainder results or modulo calculation. >> >> - the latitude and longitude are expressed in relationship to WGS84, >> whereas an international standard would be more appropriate. Europe? >> >> - the latitude and longitude seems to be represented on same number of >> 32 bits by some implementations, whereas the range of values is >> obviously different (-90 to +90 vs -180 to +180). It could also be >> 31bit vs 32bit. >> >> - the confidence values are different than what GNSS chips offer as >> standard (HDOP, VDOP, HDOP). Because of this conversion will be >> needed, add to the lack of confidence. >> >> - when transported with a GeoNetworking header, one can find lat/long >> expressed twice: once in the CAM and once in the geonet header. >> >> - the speed values, as specified, can not go higher than 589kmph. But >> there are cars that go faster than that on circuit (check the record). >> >> - there is nothing about alignment of data. The alignment of different >> fields on boundaries (like 8bit, or other) are of utmost importance to >> implementer. This lead to necessity of padding sometimes, and padding >> must be specified. >> >> Alex >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >> > > > > -- > Michelle Wetterwald > michelle.wetterwald@gmail.com > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > -- PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS: wwhyte@onboardsecurity.com --f403045c63c46da84e056646528a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alex -- I'm with Michelle that this isn't the f= orum for that discussion, but just to note, the CAM specification is in ASN= .1. ASN.1 identifies the information fields to be included in a data struct= ure, and a given data structure can then be encoded with one of a number of= standardized encoding rules. For CAM, the encoding rules are the Unaligned= Packed Encoding Rules. These are all well defined, and the encoding of CAM= is unambiguous.

Cheers,

Willia= m

On W= ed, Feb 28, 2018 at 8:59 AM, Michelle Wetterwald <mlwetterwald@gmail.= com> wrote:
Hi Alex,

I am not representing ETSI and I a= m wondering whether this is the right place to discuss about the content of= ETSI standards.
I rather encourage you to submit a contribution = to that group.

BR, Michelle

2018-02= -28 13:07 GMT+01:00 Alexandre Petrescu <alexandre.petrescu@gmai= l.com>:
Michelle,

This is a critique of the CAM message format ETSI EN 302 637-2 V1.3.1
interpreted together with ETSI TS 102 894-2 V1.2.1 "Applications and facilities layer common data dictionary".

(I purposefully exclude the QoSData vs Data part; it is another discussion)=

Here is my critique of specification of CAM message format:

- in general, it is impossible to say, when reading the specification of =C2=A0 the CAM message, what is the length of some of the fields.
=C2=A0 Because of this reason, it is impossible to decide what is the total=
=C2=A0 length of a minimal CAM without optional parts.
=C2=A0 It is impossible to answer whether a CAM fits in the MTU of
=C2=A0 IPv6-over-OCB.
=C2=A0 Because of this, it is impossible to easily obtain interoperable
=C2=A0 implementations.

=C2=A0 Example: what is the length of the Latitude field?=C2=A0 The spec gi= ves the
=C2=A0 value range -900000000..900000001, but=C2=A0 does not say on how man= y bits.
=C2=A0 That value range can fit in 31bit (upper (log_2 (1800000002))).
=C2=A0 Some implementations do it on 32bit.=C2=A0 But why 32 bit and not 31= bit?

=C2=A0 (other fields where this doubt exists can be listed here: Accelerati= on
=C2=A0 =C2=A0Confidence values 0 to 102 but on how many bits, and many othe= rs).

- the encoding is not expressed as Type Length Value (TLV).=C2=A0 This is a=
=C2=A0 common way of expressing message encoding when writing Internet
=C2=A0 Drafts.

=C2=A0 Because of this, a receiver of CAM has difficulty in dealing with =C2=A0 options, variable lengths, etc.

- the GenerationDeltaTime field is within a given window of width 16bit
=C2=A0 in milliseconds, and does not represent absolute time.=C2=A0 It is t= he
=C2=A0 remainder of timestamp/65k.=C2=A0 The timestamp itself is not sent.= =C2=A0 This
=C2=A0 is obviously a problem.=C2=A0 Ideally, one should the use 64bit time= stamp
=C2=A0 instead, not some remainder results or modulo calculation.

- the latitude and longitude are expressed in relationship to WGS84,
=C2=A0 whereas an international standard would be more appropriate.=C2=A0 E= urope?

- the latitude and longitude seems to be represented on same number of
=C2=A0 32 bits by some implementations, whereas the range of values is
=C2=A0 obviously different (-90 to +90 vs -180 to +180).=C2=A0 It could als= o be
=C2=A0 31bit vs 32bit.

- the confidence values are different than what GNSS chips offer as
=C2=A0 standard (HDOP, VDOP, HDOP).=C2=A0 Because of this conversion will b= e
=C2=A0 needed, add to the lack of confidence.

- when transported with a GeoNetworking header, one can find lat/long
=C2=A0 expressed twice: once in the CAM and once in the geonet header.

- the speed values, as specified, can not go higher than 589kmph.=C2=A0 But=
=C2=A0 there are cars that go faster than that on circuit (check the record= ).

- there is nothing about alignment of data.=C2=A0 The alignment of differen= t
=C2=A0 fields on boundaries (like 8bit, or other) are of utmost importance = to
=C2=A0 implementer.=C2=A0 This lead to necessity of padding sometimes, and = padding
=C2=A0 must be specified.

Alex

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



--
Miche= lle Wetterwald

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




--
=


PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW = ADDRESS: ww= hyte@onboardsecurity.com
--f403045c63c46da84e056646528a-- From nobody Wed Feb 28 06:14:16 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A731E128959 for ; Wed, 28 Feb 2018 06:14:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.633 X-Spam-Level: X-Spam-Status: No, score=-1.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFx8J6EGfbve for ; Wed, 28 Feb 2018 06:14:13 -0800 (PST) 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 EEAE5126BFD for ; Wed, 28 Feb 2018 06:14:12 -0800 (PST) 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 w1SEEAv4014430; Wed, 28 Feb 2018 15:14:10 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C442F2059E5; Wed, 28 Feb 2018 15:14:10 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id BBC502059F0; Wed, 28 Feb 2018 15:14:10 +0100 (CET) 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 w1SEEATC006005; Wed, 28 Feb 2018 15:14:10 +0100 To: Michelle Wetterwald Cc: its References: <002601d3afc4$a10fbb90$e32f32b0$@eurecom.fr> <71309c28-9d7e-d277-a3b0-46d1a3b4042e@gmail.com> <004701d3afd0$63867190$2a9354b0$@eurecom.fr> <461166f2-f3cc-e749-3628-f1d87104200b@gmail.com> <4997BFDE-1B3F-4F17-9742-28F23F082A15@tony.li> <596b8280-af45-aca2-9ea9-b05dce716ff1@gmail.com> <88030b0f-128a-b185-e9b8-f13b76878a74@gmail.com> <14621_1519817026_5A969141_14621_16048_1_c1dce555-5262-5a75-730d-401a1b6251e1@cea.fr> <3622fb0f-c859-9f08-1441-6b5f1d6d531f@gmail.com> From: Alexandre Petrescu Message-ID: <766cbb70-0275-7f1a-631a-e0b2f4e6a994@gmail.com> Date: Wed, 28 Feb 2018 15:14:10 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.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] Critique of CAM message format 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, 28 Feb 2018 14:14:15 -0000 Le 28/02/2018 à 14:59, Michelle Wetterwald a écrit : > Hi Alex, > > I am not representing ETSI and I am wondering whether this is the right > place to discuss about the content of ETSI standards. > I rather encourage you to submit a contribution to that group. Me and my organisation are no longer members of ETSI. I dont think we'll become again, but exploring. Alex > > BR, Michelle > > 2018-02-28 13:07 GMT+01:00 Alexandre Petrescu > >: > > Michelle, > > This is a critique of the CAM message format ETSI EN 302 637-2 V1.3.1 > interpreted together with ETSI TS 102 894-2 V1.2.1 "Applications and > facilities layer common data dictionary". > > (I purposefully exclude the QoSData vs Data part; it is another > discussion) > > Here is my critique of specification of CAM message format: > > - in general, it is impossible to say, when reading the specification of >   the CAM message, what is the length of some of the fields. >   Because of this reason, it is impossible to decide what is the total >   length of a minimal CAM without optional parts. >   It is impossible to answer whether a CAM fits in the MTU of >   IPv6-over-OCB. >   Because of this, it is impossible to easily obtain interoperable >   implementations. > >   Example: what is the length of the Latitude field?  The spec > gives the >   value range -900000000..900000001, but  does not say on how many > bits. >   That value range can fit in 31bit (upper (log_2 (1800000002))). >   Some implementations do it on 32bit.  But why 32 bit and not 31bit? > >   (other fields where this doubt exists can be listed here: > Acceleration >    Confidence values 0 to 102 but on how many bits, and many others). > > - the encoding is not expressed as Type Length Value (TLV).  This is a >   common way of expressing message encoding when writing Internet >   Drafts. > >   Because of this, a receiver of CAM has difficulty in dealing with >   options, variable lengths, etc. > > - the GenerationDeltaTime field is within a given window of width 16bit >   in milliseconds, and does not represent absolute time.  It is the >   remainder of timestamp/65k.  The timestamp itself is not sent.  This >   is obviously a problem.  Ideally, one should the use 64bit timestamp >   instead, not some remainder results or modulo calculation. > > - the latitude and longitude are expressed in relationship to WGS84, >   whereas an international standard would be more appropriate.  Europe? > > - the latitude and longitude seems to be represented on same number of >   32 bits by some implementations, whereas the range of values is >   obviously different (-90 to +90 vs -180 to +180).  It could also be >   31bit vs 32bit. > > - the confidence values are different than what GNSS chips offer as >   standard (HDOP, VDOP, HDOP).  Because of this conversion will be >   needed, add to the lack of confidence. > > - when transported with a GeoNetworking header, one can find lat/long >   expressed twice: once in the CAM and once in the geonet header. > > - the speed values, as specified, can not go higher than 589kmph.  But >   there are cars that go faster than that on circuit (check the > record). > > - there is nothing about alignment of data.  The alignment of different >   fields on boundaries (like 8bit, or other) are of utmost > importance to >   implementer.  This lead to necessity of padding sometimes, and > padding >   must be specified. > > Alex > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > > > > > -- > Michelle Wetterwald > michelle.wetterwald@gmail.com From nobody Wed Feb 28 06:21:37 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EFBB129C5D for ; Wed, 28 Feb 2018 06:21:36 -0800 (PST) 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 l9lgbmcIDztC for ; Wed, 28 Feb 2018 06:21:34 -0800 (PST) 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 DB9D1128959 for ; Wed, 28 Feb 2018 06:21:33 -0800 (PST) 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 w1SELVof016914; Wed, 28 Feb 2018 15:21:31 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A7AFC2059D0; Wed, 28 Feb 2018 15:21:31 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 955FD2027DB; Wed, 28 Feb 2018 15:21:31 +0100 (CET) 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 w1SELVXJ015487; Wed, 28 Feb 2018 15:21:31 +0100 To: William Whyte , Michelle Wetterwald Cc: its References: <71309c28-9d7e-d277-a3b0-46d1a3b4042e@gmail.com> <004701d3afd0$63867190$2a9354b0$@eurecom.fr> <461166f2-f3cc-e749-3628-f1d87104200b@gmail.com> <4997BFDE-1B3F-4F17-9742-28F23F082A15@tony.li> <596b8280-af45-aca2-9ea9-b05dce716ff1@gmail.com> <88030b0f-128a-b185-e9b8-f13b76878a74@gmail.com> <14621_1519817026_5A969141_14621_16048_1_c1dce555-5262-5a75-730d-401a1b6251e1@cea.fr> <3622fb0f-c859-9f08-1441-6b5f1d6d531f@gmail.com> From: Alexandre Petrescu Message-ID: Date: Wed, 28 Feb 2018 15:21:31 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.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] Critique of CAM message format 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, 28 Feb 2018 14:21:36 -0000 Le 28/02/2018 à 15:11, William Whyte a écrit : > Hi Alex -- I'm with Michelle that this isn't the forum for that > discussion, but just to note, the CAM specification is in ASN.1. ASN.1 > identifies the information fields to be included in a data structure, > and a given data structure can then be encoded with one of a number of > standardized encoding rules. For CAM, the encoding rules are the > Unaligned Packed Encoding Rules. These are all well defined, and the > encoding of CAM is unambiguous. I will not debug that here. I posted my critique. Alex > > Cheers, > > William > > On Wed, Feb 28, 2018 at 8:59 AM, Michelle Wetterwald > > wrote: > > Hi Alex, > > I am not representing ETSI and I am wondering whether this is the > right place to discuss about the content of ETSI standards. > I rather encourage you to submit a contribution to that group. > > BR, Michelle > > 2018-02-28 13:07 GMT+01:00 Alexandre Petrescu > >: > > Michelle, > > This is a critique of the CAM message format ETSI EN 302 637-2 > V1.3.1 > interpreted together with ETSI TS 102 894-2 V1.2.1 "Applications and > facilities layer common data dictionary". > > (I purposefully exclude the QoSData vs Data part; it is another > discussion) > > Here is my critique of specification of CAM message format: > > - in general, it is impossible to say, when reading the > specification of >   the CAM message, what is the length of some of the fields. >   Because of this reason, it is impossible to decide what is > the total >   length of a minimal CAM without optional parts. >   It is impossible to answer whether a CAM fits in the MTU of >   IPv6-over-OCB. >   Because of this, it is impossible to easily obtain interoperable >   implementations. > >   Example: what is the length of the Latitude field?  The spec > gives the >   value range -900000000..900000001, but  does not say on how > many bits. >   That value range can fit in 31bit (upper (log_2 (1800000002))). >   Some implementations do it on 32bit.  But why 32 bit and not > 31bit? > >   (other fields where this doubt exists can be listed here: > Acceleration >    Confidence values 0 to 102 but on how many bits, and many > others). > > - the encoding is not expressed as Type Length Value (TLV). > This is a >   common way of expressing message encoding when writing Internet >   Drafts. > >   Because of this, a receiver of CAM has difficulty in dealing with >   options, variable lengths, etc. > > - the GenerationDeltaTime field is within a given window of > width 16bit >   in milliseconds, and does not represent absolute time.  It is the >   remainder of timestamp/65k.  The timestamp itself is not > sent.  This >   is obviously a problem.  Ideally, one should the use 64bit > timestamp >   instead, not some remainder results or modulo calculation. > > - the latitude and longitude are expressed in relationship to WGS84, >   whereas an international standard would be more appropriate. > Europe? > > - the latitude and longitude seems to be represented on same > number of >   32 bits by some implementations, whereas the range of values is >   obviously different (-90 to +90 vs -180 to +180).  It could > also be >   31bit vs 32bit. > > - the confidence values are different than what GNSS chips offer as >   standard (HDOP, VDOP, HDOP).  Because of this conversion will be >   needed, add to the lack of confidence. > > - when transported with a GeoNetworking header, one can find > lat/long >   expressed twice: once in the CAM and once in the geonet header. > > - the speed values, as specified, can not go higher than > 589kmph.  But >   there are cars that go faster than that on circuit (check the > record). > > - there is nothing about alignment of data.  The alignment of > different >   fields on boundaries (like 8bit, or other) are of utmost > importance to >   implementer.  This lead to necessity of padding sometimes, > and padding >   must be specified. > > Alex > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > > > > > -- > Michelle Wetterwald > michelle.wetterwald@gmail.com > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > > > > > -- > > > PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS: > wwhyte@onboardsecurity.com From nobody Wed Feb 28 06:24:04 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65866129C6E for ; Wed, 28 Feb 2018 06:24:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bt1235248pop.onmicrosoft.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 z5bZTYIXpAUN for ; Wed, 28 Feb 2018 06:24:00 -0800 (PST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00096.outbound.protection.outlook.com [40.107.0.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11FE9128959 for ; Wed, 28 Feb 2018 06:23:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bt1235248pop.onmicrosoft.com; s=selector1-cadzow-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=H3VL/5bP7ONYerhKBklV5IPzgKl3jNXIiytne1Mth1w=; b=NHz1KX4P/J74GwDB83GAkQQBMAMIlnpqk7tlhqCILgLMTkwdIB7thU9qbj+mZ3ezV+7ds1LtmbcydrGpO0WeftirqR1d0z7yeDcoFdPn4rCb1u4BqQLBrfGkgWDmG9V2pfCxDRjgWdIu0pJYyzniSmXmqOZXaZAZdydZ7vG6vXw= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=scott@cadzow.com; Received: from [172.28.1.82] (195.238.226.2) by AM3PR07MB0728.eurprd07.prod.outlook.com (2a01:111:e400:883b::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.548.6; Wed, 28 Feb 2018 14:23:54 +0000 User-Agent: Microsoft-MacOutlook/10.a.0.180210 Date: Wed, 28 Feb 2018 14:23:51 +0000 From: Scott Cadzow To: Alexandre Petrescu , Michelle Wetterwald CC: its Message-ID: <3EFC2F2E-7FAB-4768-82E1-6955474A28D6@cadzow.com> Thread-Topic: [ipwave] Critique of CAM message format References: <002601d3afc4$a10fbb90$e32f32b0$@eurecom.fr> <71309c28-9d7e-d277-a3b0-46d1a3b4042e@gmail.com> <004701d3afd0$63867190$2a9354b0$@eurecom.fr> <461166f2-f3cc-e749-3628-f1d87104200b@gmail.com> <4997BFDE-1B3F-4F17-9742-28F23F082A15@tony.li> <596b8280-af45-aca2-9ea9-b05dce716ff1@gmail.com> <88030b0f-128a-b185-e9b8-f13b76878a74@gmail.com> <14621_1519817026_5A969141_14621_16048_1_c1dce555-5262-5a75-730d-401a1b6251e1@cea.fr> <3622fb0f-c859-9f08-1441-6b5f1d6d531f@gmail.com> <766cbb70-0275-7f1a-631a-e0b2f4e6a994@gmail.com> In-Reply-To: <766cbb70-0275-7f1a-631a-e0b2f4e6a994@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-Originating-IP: [195.238.226.2] X-ClientProxiedBy: VI1PR0701CA0062.eurprd07.prod.outlook.com (2603:10a6:800:5f::24) To AM3PR07MB0728.eurprd07.prod.outlook.com (2a01:111:e400:883b::19) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 2cfc76ed-7d4b-4e04-0f57-08d57eb6e5ee X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(5600026)(4604075)(2017052603307)(7153060)(7193020); SRVR:AM3PR07MB0728; X-Microsoft-Exchange-Diagnostics: 1; AM3PR07MB0728; 3:GH+uMgrRw8J5pzQV73PfwW6RUF/KmUqdGsHYi3kLxx0PRu/7vXSMI7ZNt7PcjYbMW0vlCWdT83zYyGWJ7ARe2ktzwXxVmzWGk2IksloqdtX18JTwNUraKtnUIMu8tpbRgmFlN4pPgXfZeuczWIXU+0sR/tCdWYiomqQWb/MWaSMlnLPo0mZIRpX7LXtZB2KW91VLr4WGagBpNwLiNU7Ha42jgJPgoDbKV0YUHvr4N6hVrbH2AP+4kcOIePgcX4bN; 25:wsEfx7NrkmPQRhCjhjrFgsRWUHZiXQW7W62VW6v6YihiS6UqN2vjGVNC8+05BctKQOuoVk+I+5mmqfcxo4+LgFL0p2lSzQ73beIiRJqM2ThRWxJsI1I4T2CZhekWUQJUvfGrPaffKK1QEPNfvM94Atb0FL66E2jPmcwONj6Ukehm7eUvG+jNmcLYKFs4Mt7BGxBfbG0iiLjbdjlLmeYzCUuzYYyn2OG80vZtSuxRr3J7/11OYKT5rF+OrBFVA2j7tidl0SqJOfqLqbKKY2jnuwCO4vEqvhxvy4rJKMpMa7kS+CEk/JoXgyoBWAyCFCPilW/6DWvxZZz0hT576NDDxw==; 31:HslbKXHKTsBGH1K0tJhEocKpyFvdaKYOpKFBDZ1bmDDGp7FNSG7HoBbxtGWheZTKJ2lQ3MFS+Ra8y1o3PVRcRO22tDkM0El30qajWHDfGULrS+KtUKRUFErtOHBKCT7zyhq8dDdMdTqpd4Lgk2kDYI1c4h5xt4c5ImNKf6Xzi+LF1QUcnvwpdtyzYwICXWsXLksl7u1/o8pRnYZcbjNUogBh5RHLUrUuj4wtuV7LryM= X-MS-TrafficTypeDiagnostic: AM3PR07MB0728: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(85827821059158); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231220)(944501161)(93006095)(93001095)(6041288)(2016111802025)(20161123560045)(20161123562045)(20161123564045)(20161123558120)(6043046)(6072148)(201708071742011); SRVR:AM3PR07MB0728; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB0728; X-Microsoft-Exchange-Diagnostics: 1; AM3PR07MB0728; 4:2levdAQzG0XPufXGfB96pUYwSiAsyiGDT+JHjHTFiwsqlSLBoFZje88fsr6bsB/GsdnuiXLXg0zKweu7HfumEnN7rcdhgmHEHC2y1kbs5ffQGI/G34VJXPaQ1z4OiBFT5Jg73eBJ+Uq6QSQKEWwX5G4TaFV7+7HK/x+v0U+bwJSuK6R/Vg8ThHaCNdrRQUEj6DcZ1bvglyZRcGTzb/EhipRlmwkcrEmPNR/93FGz5fLIzpraQfdpMR7FLX7JyjBGfTjUhID9hyeRO7WZbajhChmvG507Do0sOgaDfkprrvZBm2QrIZ8Fi22Eqd27bqRZ X-Forefront-PRVS: 0597911EE1 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(366004)(39380400002)(39830400003)(346002)(396003)(376002)(199004)(189003)(50466002)(5660300001)(39060400002)(23676004)(229853002)(2906002)(6116002)(3846002)(106356001)(26005)(25786009)(386003)(33656002)(52116002)(76176011)(16576012)(58126008)(16526019)(110136005)(6486002)(186003)(316002)(93886005)(2950100002)(6666003)(53936002)(86362001)(83716003)(5820100001)(77096007)(82746002)(36756003)(478600001)(6246003)(105586002)(66066001)(8746002)(81156014)(81166006)(8936002)(8676002)(68736007)(7736002)(4326008)(305945005)(47776003)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3PR07MB0728; H:[172.28.1.82]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: cadzow.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTNQUjA3TUIwNzI4OzIzOnh1Z0I3aitqRGEyRkxtZUpoV29GaHVxL1hl?= =?utf-8?B?NWxXNDJLWG9KZVU4aERFaVRIZWRKR0JCN0tRTlhsZ0J1YlJBaHh5TW96MUlJ?= =?utf-8?B?QmxsTlNFaC9aVVl3dDRxY2NwSHovSVlIOFhEaVFTSDlXejNYSmlJcVhobTdh?= =?utf-8?B?bmN4THB6eEdBa2c5cnBIOXFBS2pISnArL2ZuWHR2STVibHJEdUZqLzN1MzRz?= =?utf-8?B?dWY5emlkRzhCTUhwZHFSOWM5UGdlSjNwNHllNDlxRU9MRUxUa0swYUdjWmxN?= =?utf-8?B?Ri9OdlRyVDNjRUIvdnViZHV3SmtIUis5NlBQb3hpbVBlZnRWQU04SUc0V0R3?= =?utf-8?B?WU9ZSktvRmQ4cEs5VTdscGh5QmxLMWNDbzNPTFJRTmcwYlhUTlhYMEN4V1dZ?= =?utf-8?B?Mklab2NBL25LWVlsYnRvRWVCcnh2N1N0TFRqVG5qdUZ2VlZBUjl1RHE2UTNn?= =?utf-8?B?ZkxlZ1lZa21DaGlTK08wVnFNNTFGSVU2STBxWmFyUWhVM0RTOFI2Z2ljVkdS?= =?utf-8?B?THZFeHJwK1dmOWY2OVhlZ2lpTHdOb1RaMFJmaEJGYkwrdk4veHFCSFFhelNj?= =?utf-8?B?NFlFMVNQa3RBWEZHSmU4Y0ZvNit3cGl4bDMySFoyejhrZzc5MWUwMUhpRGVG?= =?utf-8?B?NElGZ0h5MEpMSW52SnlEY3NybVdkaWxtNnlKeXdXRmNFQXN6SGRTY2xyeVcr?= =?utf-8?B?Q2VjaW9tRDB0cU9yZ0dZZTFqaWh3bFhyNHBnVUlwcUtjbURkbjVybit0UWdl?= =?utf-8?B?ZUwzRXJQQU9Gd2JGZFVKNHgxRDlOUUZ2UHZoUWZzTDE0SDBWd05MOGNiekhn?= =?utf-8?B?Vy9qNTl1TjBORXQrTVI5V0swRTFHWU9SWXladnhGNlV6bzFjR2FYT2E0dmdw?= =?utf-8?B?QmY0ZjBqNU5IM21NeUlPNE52Ylg3SWVWYXQ5emwwSTd4elFwOHhWQ2thVzdO?= =?utf-8?B?V2hxbURlc2pHSWhOQUtnOEFIb3I3WkJUd3pYNWxmc1FUdVMzT3U5SlpVbkhN?= =?utf-8?B?SWh1VlpzbGdpdmtXdXNuWmxaclNIU3J1TUkzc3YzVFZaZjBrb0Q3Uy95RCtk?= =?utf-8?B?c3Fqb3ljTFZkK3k1eW82RFptbVk0UFFzS2ZhYXVtM0xubTlmT1hqQzdzdktT?= =?utf-8?B?ZCtUWTFVWktNWC93OVFCTFI2Z29kcXBXWWRhSGFXL0x1L3M3QnNlcTlYUERD?= =?utf-8?B?QUlqYTZpRkVEalZ4Rk1YWXdpTlk2L0FNODdUQVVrQ0tmb2RLemsrdHV2UExa?= =?utf-8?B?MVFoWC8yNGpCd2owMGdIVWo2amNuNlRxNzBOZURReVpBc0VjdUJ1ZXhoN00z?= =?utf-8?B?S2g2QkNGZ1VRbG5BRzZpeGVucWl2RXZlc2hkTDhIOEYwMThGZTVGK2NxdW9s?= =?utf-8?B?T0tSWVpldWFRNDE1UjNtTWZjdGY1aHhlTXJUMElrUGJrVElxZXhJVkk3UFZ2?= =?utf-8?B?U2NTaVZtOUVJalhvaTMzM2VzaE4yU3lIeURWbFdJMHdnZFp3SzZsem94NzlF?= =?utf-8?B?ZjBIaHhVUjcxZ1hyWWs1SS9id0N6RnU1KzMvc21KZUd2YVJuZmZ4d1pWYTRt?= =?utf-8?B?VmVLclNsUFkxSXpKelFGR0JUYnBhdUZxRzFkRGtxT0U2YzVhbkdwOWtYR205?= =?utf-8?B?cG9BVnJhUDBDZTBodzQza055ZmhMYnlFNm9CeEd4bzZ4TzlvbXk5MC95VjAy?= =?utf-8?B?SlIwcG5TTkdnOHVzYitGeGdJTXBPL1A1VGhuU3RybzA4OGFzdXpDUnN3bUVX?= =?utf-8?B?QWphVm1WQjBUWVZPZi9RZz09?= X-Microsoft-Exchange-Diagnostics: 1; AM3PR07MB0728; 6:6X7JOqFrGEaTjiwhz2p6prWEVYqaLIcy+IItbczKo0BU7fpAHk+WtvifwZMTnkVHjNVY88mUjIO8f+D2i4u0n0fNNfiI/hTLIZs1sOmKirB9ClMmJMD+ZzDtUgKknUElRoyZKpxJ8RiWPEghfowt7DUvGoSGvoUJkfM9AgY3SLHGcmPplC7OuIDxy2fe1LSfT2laOB9ySjWVHi0j9XcqjAL1c0+f8mXP+K3smqibF57Ng33/+r2x5966j7KDWhyaV+fuTaogaH7keLyFceVG6+vDcKoTU12vWnwVEH+v5zjnwGid27YnRfoDDTe0QR3Bd/oB1v4nCu43YgScXlZaVh+vDL1ImsxIWi3jWeuq/ew=; 5:tv65R3QKIgd71+81hBwZjkFZzaNCCdwmbj7lt5bm5WTmmbT5L/rTZnhuVrCnB01E0UHGk6i/qPdbVrkbOtT+Hipw+sZcvdkOLItdM9BFCCSCUcHjhzmy5nOJvbUAflRj71YuLIyX6Fy0hIsqTIP7srzs9V2X7LNNECSTO3hoPpk=; 24:hxCLpCLN0ZhKpLpJ5TxCZCiRoOvfJ0RcnHqtXBNG2Qp30mh24RF6uk9yVUqgEaGUle1hHtYthM8ffVoLcmoXA+cKwfofVnKJWik45JfiIPs=; 7:2ZvXDfDd2VJ/nNAPn73S92FWMXHHJyOlTzy0Us6F8p5p72F6d9+mPTbEkRaZFMpIofJC2XnCJ+bvPocbJ6u3G19oK9y5JUOdiX9mPWW4y+rjVOzfBOTi5+OyMgc5yz0t1TA5U8DYEkZllvOMue8+jmi9bUmUwGajitj8O71m5LdJo6tAOQJytC8ECcrF7calSXfDV4LPrdWNrQCKv1FGAh1mjOs9SAahsu/F0m8qJHb3OjWZjmsPdmXuhsoHR4Av SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: cadzow.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Feb 2018 14:23:54.6682 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 2cfc76ed-7d4b-4e04-0f57-08d57eb6e5ee X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 09f50b23-3737-462c-809e-ebe9416b266a X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB0728 Archived-At: Subject: Re: [ipwave] Critique of CAM message format 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, 28 Feb 2018 14:24:02 -0000 Latest versions of the CAM specs have moved on apace. TS 102 894-2 is now a= t v1.2.10; EN 302 637-2 is at V1.3.2 now. As noted by William these use ASN.= 1 for data description and packed encoding rules so ought to be unambiguous.= If there are issues, again as noted by Michelle, you ought to inform ETSI a= s indicated on the front material of the published standard. Scott Cadzow =20 =EF=BB=BFOn 28/02/2018, 14:14, "its on behalf of Alexandre Petrescu" wrote: TS 102 894-2 From nobody Wed Feb 28 06:26:10 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82EC912D82F for ; Wed, 28 Feb 2018 06:26:08 -0800 (PST) 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 9XfMDszvPYQc for ; Wed, 28 Feb 2018 06:26:07 -0800 (PST) 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 C5CBC128959 for ; Wed, 28 Feb 2018 06:25:43 -0800 (PST) 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 w1SEPbxM044821; Wed, 28 Feb 2018 15:25:37 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C0AEB2059AB; Wed, 28 Feb 2018 15:25:37 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id B1187201DC6; Wed, 28 Feb 2018 15:25:37 +0100 (CET) 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 w1SEPbjJ021036; Wed, 28 Feb 2018 15:25:37 +0100 To: Scott Cadzow , Michelle Wetterwald Cc: its References: <71309c28-9d7e-d277-a3b0-46d1a3b4042e@gmail.com> <004701d3afd0$63867190$2a9354b0$@eurecom.fr> <461166f2-f3cc-e749-3628-f1d87104200b@gmail.com> <4997BFDE-1B3F-4F17-9742-28F23F082A15@tony.li> <596b8280-af45-aca2-9ea9-b05dce716ff1@gmail.com> <88030b0f-128a-b185-e9b8-f13b76878a74@gmail.com> <14621_1519817026_5A969141_14621_16048_1_c1dce555-5262-5a75-730d-401a1b6251e1@cea.fr> <3622fb0f-c859-9f08-1441-6b5f1d6d531f@gmail.com> <766cbb70-0275-7f1a-631a-e0b2f4e6a994@gmail.com> <3EFC2F2E-7FAB-4768-82E1-6955474A28D6@cadzow.com> From: Alexandre Petrescu Message-ID: Date: Wed, 28 Feb 2018 15:25:37 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <3EFC2F2E-7FAB-4768-82E1-6955474A28D6@cadzow.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Critique of CAM message format 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, 28 Feb 2018 14:26:08 -0000 Le 28/02/2018 à 15:23, Scott Cadzow a écrit : > Latest versions of the CAM specs have moved on apace. TS 102 894-2 is > now at v1.2.10; EN 302 637-2 is at V1.3.2 now. As noted by William > these use ASN.1 for data description and packed encoding rules so > ought to be unambiguous. If there are issues, again as noted by > Michelle, you ought to inform ETSI as indicated on the front material > of the published standard. ... or agree with my partners to write our own CAM. I dont understand why have to go through ETSI. Alex > > Scott Cadzow > > > On 28/02/2018, 14:14, "its on behalf of Alexandre Petrescu" > > wrote: > > TS 102 894-2 > > > From nobody Wed Feb 28 08:02:31 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9607612EB05 for ; Wed, 28 Feb 2018 03:21:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.633 X-Spam-Level: X-Spam-Status: No, score=-1.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Q3oTajsNLu4 for ; Wed, 28 Feb 2018 03:21:16 -0800 (PST) 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 22EB81200F1 for ; Wed, 28 Feb 2018 03:21:14 -0800 (PST) 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 w1SBLCNB035987; Wed, 28 Feb 2018 12:21:12 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 380162057E1; Wed, 28 Feb 2018 12:21:12 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 1DE72202AC6; Wed, 28 Feb 2018 12:21:12 +0100 (CET) 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 w1SBLBQl030656; Wed, 28 Feb 2018 12:21:11 +0100 To: Michelle Wetterwald Cc: =?UTF-8?Q?Katrin_Sj=c3=b6berg?= , its , =?UTF-8?Q?Fran=c3=a7ois_Simon?= , Mie Eur , =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , John Kenney , "Dr. Hans-Joachim Fischer" , Tony Li , Abdussalam Baryun References: <00eb01d3af1d$7f4e8100$7deb8300$@gmail.com> <6187cb92-5c8f-d08b-dcc2-859652d629d0@gmail.com> <002901d3af20$b966e960$2c34bc20$@eurecom.fr> <002601d3afc4$a10fbb90$e32f32b0$@eurecom.fr> <71309c28-9d7e-d277-a3b0-46d1a3b4042e@gmail.com> <004701d3afd0$63867190$2a9354b0$@eurecom.fr> <461166f2-f3cc-e749-3628-f1d87104200b@gmail.com> <4997BFDE-1B3F-4F17-9742-28F23F082A15@tony.li> <596b8280-af45-aca2-9ea9-b05dce716ff1@gmail.com> <88030b0f-128a-b185-e9b8-f13b76878a74@gmail.com> From: Alexandre Petrescu Message-ID: <1ee2f960-0650-d585-8325-26eaf1639dc7@gmail.com> Date: Wed, 28 Feb 2018 12:21:11 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.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: X-Mailman-Approved-At: Wed, 28 Feb 2018 08:02:29 -0800 Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB 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, 28 Feb 2018 11:21:17 -0000 Le 28/02/2018 à 11:34, Michelle Wetterwald a écrit : > Hi Alex, > > Regarding the interoperability between different implementations, it has > been fully validated during numerous plugtests events in EU and US, > gathering a large set of different implementations. For the EU ones, the > reports are freely available on the ETSI web site. I am using the wireshark dissectors on the ETSI web site. I can tell they show lack of interoperability: several CAM messages from several stacks are not understood by these wireshark dissectors. The ETSI wireshark dissectors have another problem themselves: they are not integrated in the main wireshark software. It's just ETSI's point of view. > I am sorry to hear that the open source implementation that you are > using has some limitations. I remember that one of the participants to > the last PlugTest in Livorno (Nov 2016) explained to me he had extended > the open source software to use his computer to monitor the traffic > exchanged on the 802.11p. So he made his Ath implementation fully > interoperable with those from the other vendors. Maybe you can > apply similar upgrades to your testing implementations? Can you tell me who is that participant so I can contact? > Again, I disagree with the change you propose in the text of the draft, > as it goes against the *existing* EU regulations. Compliance with the > modified text would prevent vendors from accessing the EU market. Accessing EU market is a good thing, but customer lock in is not that good. Alex > BR, > Michelle > > > 2018-02-28 11:09 GMT+01:00 Alexandre Petrescu > >: > > > > Le 28/02/2018 à 10:47, Katrin Sjöberg a écrit : > > Hi Alexandre, All, > > We are mixing apples and pears in this discussion and it is very > frustrating. On one hand, the discussion is about detailed open > source software implementations that do not support QoS data with > how the EU mandate will look like. > > > EU must take great care when mandating technologies. > > First of all, the QoS data is handled by the chipset covering > MAC+PHY on top of this LLC resides. > > > I agree. > > We use ath9k driver and mac80211 module in the linux kernel. > > IPv6 is on top of LLC. > > > Yes. > > And suddenly the CAM specification, which is residing in the > facilities layer is discussed. > > > I agree.  Speaking CAM here is a stretch.  The stretch comes from my > single possible way (with BSM) to notice the existence of these QoS Data > headers.  I should have rather said "QoS Data transported message, e.g. > CAM or BSM". > > When I say I have problems with CAM, and I will post a critique of it, > is with the CAM message encoding, and lack of interoperability of that > CAM.  I do not critique the fact that QoS Data transports CAM. > > What is the problem with making EDCA mandatory in this standard? > > > The problem is the lack of implementations. > > The amendment IEEE 802.11e, which introduced the concept of > EDCA, was > approved in 2005 and it was a unique selling point for WiFi APs in > the beginning. EDCA has been around for 13 years and this standard > developed in 2018 for supporting IPv6 in VANETs when using IEEE > 802.11p wants to use DCF due to some existing implementation... For > me this is like being thrown back to the stone age. > > > Sorry, not the intention to throw back to stone age. > > But I need implementation. > > I am working for an OEM > > > Is OEM implementing QoS Data? > > and I cannot accept that this standard will allow IPv6 traffic > over IEEE 802.11p using DCF since it might adventure road > traffic safety applications that are under development. We want > to reduce the number of accidents and the > impact of the same by using IEEE 802.11p with EDCA and suddenly > messages such as CAMs might be starved out because someone is > transmitting IPv6 traffic using DCF. This is not acceptable and once > again I want to emphasize that EN 302 663 in Europe requires EDCA, > which would prohibit this standard to use the 5.9 GHz band. > > > Hold on, hold on.  Excuse me. > > Road traffic safety applications is also a huge worry for designers > using IP packets. > > But, the spectrum is for everyone to coexist and interoperate. > > Alex > > > Best regards, Katrin > > 2018-02-28 10:27 GMT+01:00 Alexandre Petrescu > > >>: > > > > > Le 28/02/2018 à 09:50, Mie Eur a écrit : > > Hi Alex, > > I fully agree with Katrin and was about to send a similar post, > as the EDCA queues are used also by ITS-G5 for the DCC, which is > mandated by the new EU regulation. > > > I would really be surprised that EU mandates something that > depends on closed source, potentially favoring a competitive > edge to a particular private interest.  But I am optimistic: > given all the stimulation of open source in EU projects I > believe EU regulators understand the implications related to > cost, licensing, and interoperability. > > Unless you want to rewrite all ETSI standards and related > European norms in a couple of  weeks, > > > In one of these days I will post a critique of the CAM > specification. > > I would suggest to keep the old text and guarantee openness for > using > the IEEE 802.11-16 standard while complying to local regulations. > > > YEs, we need that. > > But the old text says: > > "In OCB mode, IPv6 packets MAY be transmitted either as "IEEE 802.11 >  Data" or alternatively as "IEEE 802.11 QoS Data" > > > I implement only the 802.11 Data and my partner(s) use equipment > bought from Unex that only implements QoS Data.  I want our > software to interoperate. > > If the text said just 'Data', then I could direct my partners to the >  open source on the Internet.  But in current situation my > partners direct me to Unex, which is expensive - it has a cost. > > I do not agree to continue this situation. > > Either the QoSData supporters direct me to an open source > implementation of QoSData now, or we relegate the QoS discussion > for later. > > I would also suggest to bring this topic, as well as the handling of >  QoS for IPWAVE, which is an interesting topic, to the > re-chartering >  discussion that was proposed by Carlos-Jesus a few weeks ago. > The same as we did for ND or this nice multicast address that > would be reserved for IPWAVE services. > > > I agree. > > BTW, you really plan to send CAMs directly over IPv6, without > any transport layer? I thought you would use UDP, which has a > "large" header as well. (found in an "old" post dated back from > 4 days ago. ) > > > At this time, with partners, we ponder the idea of a different > CAM if > you wish (not sure whether UDP, or just IP, or 802.11 Data, or > 802.11 > QoS Data).  This different CAM is interoperable and cheap to > produce. > > CAM over UDP over IPv6 was already produced by others in other > project. I think they didnt bother to standardise it, but it > worked for them.  I am tempted to copy from them. > > Alex > > : > > CAM transported in IP may be a smaller packet than CAM transported > > in BTP and GeoNetworking. > > > 2018-02-28 8:07 GMT+01:00 Alexandre Petrescu > > > > > >>>: > > Thank you for the message. > > Le 28/02/2018 à 07:08, Katrin Sjöberg a écrit : [...] > > This implies that the current IETF proposal of using IPv6 over > DCF would be impossible to use in Europe. > > > Unless, of course, we suggest modify the ETSI specification to allow >  for 802.11 Data headers as well as 802.11 QoS Data headers. > > (there are many reasons to ponder over a major rehaul of ETSI > ITS specifications, starting at the CAM itself, that I could > explain separately). > > If all IPv6 trafffic has to use a common EDCA access category, I > would support John's suggestion from an earlier email to fix > IPv6 traffic to AC_BK. > > > This could be done.  On my side I would need to see running code for >  it, and then there is need of consensus (could be obvious from > your >  standpoint). > > As Jêróme pointed out, we use AC_BE for CAMs, > > > Thank you for this message.  I understand you have an implementation >  of CAM sent with IEEE 802.11 QoSData header.  Is it the one from > Unex with Autotalks chipset? > > (the CAM implementations I use are from github.com > and > ath9k driver; they dont generate 802.11 QoSData header, but use > 802.11 Data header, hence no AC_BE). > > and I know the US uses AC_BE for some of their safety messages > as well. > > > I think me too, I have seen BSM messages carried with 802.11 > QoSData headers, field Priority value 2 Spare (Background); I > guess that stands for AC_BK.  But I could not figure out what > was the software that implemented it. > > Alex > > > Best regards, Katrin Sjöberg > > > > 2018-02-27 17:50 GMT+01:00 Tony Li > >> > >>>>: > > > If someone knows how to generate a QoSData transported IP packet > with > linux open source then I am all ears. > > > > This is just a Small Matter Of Programming for anyone with a bit > of kernel hacking experience and driver sources. > > Tony > > _______________________________________________ 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 > > > > > >> > > > > > -- Michelle WETTERWALD > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > > > > > -- > Michelle Wetterwald > michelle.wetterwald@gmail.com From nobody Wed Feb 28 08:39:15 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55A0E12D871 for ; Wed, 28 Feb 2018 08:39:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iv6SqzG7Q-6a for ; Wed, 28 Feb 2018 08:39:12 -0800 (PST) Received: from smtp2.eurecom.fr (smtp2.eurecom.fr [193.55.113.211]) by ietfa.amsl.com (Postfix) with ESMTP id 66028124B17 for ; Wed, 28 Feb 2018 08:39:12 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.47,406,1515452400"; d="scan'208";a="7710063" Received: from monza.eurecom.fr ([192.168.106.15]) by drago2i.eurecom.fr with ESMTP; 28 Feb 2018 17:39:11 +0100 Received: from xerus29 (unknown [192.168.200.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by monza.eurecom.fr (Postfix) with ESMTPSA id 5656CB57; Wed, 28 Feb 2018 17:39:11 +0100 (CET) From: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= To: "'Alexandre Petrescu'" , "'Scott Cadzow'" , "'Michelle Wetterwald'" Cc: "'its'" References: <71309c28-9d7e-d277-a3b0-46d1a3b4042e@gmail.com> <004701d3afd0$63867190$2a9354b0$@eurecom.fr> <461166f2-f3cc-e749-3628-f1d87104200b@gmail.com> <4997BFDE-1B3F-4F17-9742-28F23F082A15@tony.li> <596b8280-af45-aca2-9ea9-b05dce716ff1@gmail.com> <88030b0f-128a-b185-e9b8-f13b76878a74@gmail.com> <14621_1519817026_5A969141_14621_16048_1_c1dce555-5262-5a75-730d-401a1b6251e1@cea.fr> <3622fb0f-c859-9f08-1441-6b5f1d6d531f@gmail.com> <766cbb70-0275-7f1a-631a-e0b2f4e6a994@gmail.com> <3EFC2F2E-7FAB-4768-82E1-6955474A28D6@cadzow.com> < dbcce9fe-edc0- 22b0-4082-2063cd0999d6@gmail.com> In-Reply-To: Date: Wed, 28 Feb 2018 17:39:10 +0100 Organization: EURECOM Message-ID: <007c01d3b0b2$a94f7360$fbee5a20$@eurecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQHelLAw/aN7IRfcwiTBG/gKcgHVEwKK7AZQAWDM+KcCfnkWwAH+vF+eAog3fVwA+UNzzgJKSfslAdHHC5IC7hT6TANPbyPOAtb2hTQBrVUHoAHU1qbrAdpzDasCX7WCUwJOXhYgAdgFvryifEwc4A== Archived-At: Subject: Re: [ipwave] Critique of CAM message format 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, 28 Feb 2018 16:39:14 -0000 Hi Alex, I do not know how we could get drifted so far away from the RFC = discussions and now discuss redoing CAMs. But as a quick answer, to the best of my knowledge, you can't. ETSI has = the mandate from the EC to 1) access the ITS-G5 spectrum 2) specify the = C-ITS services (notably safety) for interoperability (cross-border, = EU-wide, even enforcing interop with BSM, etc..)... Even the C-V2X people, not the strongest supporters of ETSI C-ITS, are = currently applying changes to ETSI and planning to use CAMs and DENMs... BR, J=C3=A9r=C3=B4me =20 -----Original Message----- From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu Sent: Wednesday 28 February 2018 15:26 To: Scott Cadzow; Michelle Wetterwald Cc: its Subject: Re: [ipwave] Critique of CAM message format Le 28/02/2018 =C3=A0 15:23, Scott Cadzow a =C3=A9crit : > Latest versions of the CAM specs have moved on apace. TS 102 894-2 is=20 > now at v1.2.10; EN 302 637-2 is at V1.3.2 now. As noted by William=20 > these use ASN.1 for data description and packed encoding rules so=20 > ought to be unambiguous. If there are issues, again as noted by=20 > Michelle, you ought to inform ETSI as indicated on the front material=20 > of the published standard. ... or agree with my partners to write our own CAM. I dont understand why have to go through ETSI. Alex >=20 > Scott Cadzow >=20 >=20 > =EF=BB=BFOn 28/02/2018, 14:14, "its on behalf of Alexandre Petrescu" > > wrote: >=20 > TS 102 894-2 >=20 >=20 >=20 _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its From nobody Wed Feb 28 09:52:05 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5223B124C27 for ; Wed, 28 Feb 2018 09:52:03 -0800 (PST) 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 MtcSee7zTmfD for ; Wed, 28 Feb 2018 09:51:59 -0800 (PST) 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 C2124124319 for ; Wed, 28 Feb 2018 09:51:58 -0800 (PST) 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 w1SHpsAH030063; Wed, 28 Feb 2018 18:51:54 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 98149205B64; Wed, 28 Feb 2018 18:51:54 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 86563205B2F; Wed, 28 Feb 2018 18:51:54 +0100 (CET) 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 w1SHpswu025375; Wed, 28 Feb 2018 18:51:54 +0100 To: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , "'Scott Cadzow'" , "'Michelle Wetterwald'" Cc: "'its'" References: <4997BFDE-1B3F-4F17-9742-28F23F082A15@tony.li> <596b8280-af45-aca2-9ea9-b05dce716ff1@gmail.com> <88030b0f-128a-b185-e9b8-f13b76878a74@gmail.com> <14621_1519817026_5A969141_14621_16048_1_c1dce555-5262-5a75-730d-401a1b6251e1@cea.fr> <3622fb0f-c859-9f08-1441-6b5f1d6d531f@gmail.com> <766cbb70-0275-7f1a-631a-e0b2f4e6a994@gmail.com> <3EFC2F2E-7FAB-4768-82E1-6955474A28D6@cadz! ow.com> < dbcce9fe-edc0- 22b0-4082-2063cd0999d6@gmail.com> <007c01d3b0b2$a94f7360$fbee5a20$@eurecom.fr> From: Alexandre Petrescu Message-ID: Date: Wed, 28 Feb 2018 18:51:54 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <007c01d3b0b2$a94f7360$fbee5a20$@eurecom.fr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Critique of CAM message format 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, 28 Feb 2018 17:52:03 -0000 Le 28/02/2018 à 17:39, Jérôme Härri a écrit : > ETSI > has the mandate from the EC to 1) access the ITS-G5 spectrum I manage an RSU sending IPv6 RAs over 802.11OCB on CCH at 5.9GHz at 25dBm in OCB mode with IEEE 802.11 Data headers, on the street in front of my desk. Wants EC me to stop it? Alex > > Even the C-V2X people, not the strongest supporters of ETSI C-ITS, > are currently applying changes to ETSI and planning to use CAMs and > DENMs... > > BR, > > Jérôme > > -----Original Message----- From: its [mailto:its-bounces@ietf.org] On > Behalf Of Alexandre Petrescu Sent: Wednesday 28 February 2018 15:26 > To: Scott Cadzow; Michelle Wetterwald Cc: its Subject: Re: [ipwave] > Critique of CAM message format > > > > Le 28/02/2018 à 15:23, Scott Cadzow a écrit : >> Latest versions of the CAM specs have moved on apace. TS 102 894-2 >> is now at v1.2.10; EN 302 637-2 is at V1.3.2 now. As noted by >> William these use ASN.1 for data description and packed encoding >> rules so ought to be unambiguous. If there are issues, again as >> noted by Michelle, you ought to inform ETSI as indicated on the >> front material of the published standard. > > ... or agree with my partners to write our own CAM. > > I dont understand why have to go through ETSI. > > Alex > >> >> Scott Cadzow >> >> >> On 28/02/2018, 14:14, "its on behalf of Alexandre Petrescu" >> >> wrote: >> >> TS 102 894-2 >> >> >> > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > > From nobody Wed Feb 28 10:41:24 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF91E124319 for ; Wed, 28 Feb 2018 10:41:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 6pP-sIEEp-Ge for ; Wed, 28 Feb 2018 10:41:21 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BDE612426E for ; Wed, 28 Feb 2018 10:41:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 42612300590 for ; Wed, 28 Feb 2018 13:41:19 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id QDbF-_uObnR5 for ; Wed, 28 Feb 2018 13:41:18 -0500 (EST) Received: from [172.22.112.5] (unknown [65.132.39.155]) by mail.smeinc.net (Postfix) with ESMTPSA id 8D6F2300435 for ; Wed, 28 Feb 2018 13:41:18 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 28 Feb 2018 13:41:19 -0500 References: <71309c28-9d7e-d277-a3b0-46d1a3b4042e@gmail.com> <004701d3afd0$63867190$2a9354b0$@eurecom.fr> <461166f2-f3cc-e749-3628-f1d87104200b@gmail.com> <4997BFDE-1B3F-4F17-9742-28F23F082A15@tony.li> <596b8280-af45-aca2-9ea9-b05dce716ff1@gmail.com> <88030b0f-128a-b185-e9b8-f13b76878a74@gmail.com> <14621_1519817026_5A969141_14621_16048_1_c1dce555-5262-5a75-730d-401a1b6251e1@cea.fr> <3622fb0f-c859-9f08-1441-6b5f1d6d531f@gmail.com> <766cbb70-0275-7f1a-631a-e0b2f4e6a994@gmail.com> <3EFC2F2E-7FAB-4768-82E1-6955474A28D6@cadzow.com> < dbcce9fe-edc0- 22b0-4082-2063cd0999d6@gmail.com> <007c01d3b0b2$a94f7360$fbee5a20$@eurecom.fr> To: its In-Reply-To: <007c01d3b0b2$a94f7360$fbee5a20$@eurecom.fr> Message-Id: <9A73A3A8-A7E3-4472-BCD0-BBB4D8D103A6@vigilsec.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [ipwave] Critique of CAM message format 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, 28 Feb 2018 18:41:22 -0000 I cannot see how the discussion of Cooperative Awareness Message (CAM) = is helping us complete the WG Last Call on the IPv6-over-802.11-OCB = document. Please focus on our deliverable. Russ= From nobody Wed Feb 28 14:19:45 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70699126D73 for ; Wed, 28 Feb 2018 14:19:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 cIBXVrtFehCc for ; Wed, 28 Feb 2018 14:19:41 -0800 (PST) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::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 126D9126B6D for ; Wed, 28 Feb 2018 14:19:41 -0800 (PST) Received: by mail-oi0-x22e.google.com with SMTP id t185so3012840oif.6 for ; Wed, 28 Feb 2018 14:19:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=K3twXCf7153js6qd6z/xsklDa1U/SlSOzyPQFpQMB7w=; b=Y5baiipSnYUWSSiXmr61dpfJ8Zv2kgfCT8MU8miUMyGGtarsTFW8SE5vdBaQ+AsxuZ n3/1p0W7TLKWvPgMrI6OHoUGJAeqyN5NVJlCU895pCL40riXxRrFpHuVhNci5GYj5D3Y rnO3rnrKV8ek6KPWSXMfYmiYL+GPJ2G60UthzQ1ndZVeKy61GqWyUqZ1BSFRXXk0PECd H4BvuePLzPFbLV9B02gIa5nBWI7W0JQZJFmU5Cxzyu4/O2udmnnbfs+emY7f2hiYth8Y z2GhPCDsHiyNG0xY3bZ1HUa+JfNQdLlcgIuSuzu1VJqRo5HZ/xB1duetSUiHvG1Yyym4 LsPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=K3twXCf7153js6qd6z/xsklDa1U/SlSOzyPQFpQMB7w=; b=ZB77/kMaCnj0kLagHiF9IbJlW7rJtOmmLZnzRokrhnxrD8CUnbOV98kbQw1HsfzOhI 39IpDDHnvm4DlcTV0dgny/BMfna77LK54/WZHBcNszqPjRl19YxKy8PvFK0GinWfbj2G JkotzPfR89ltK//7JgCzwjC3hZHj6gSVdaqKF9bQTYOJgoO29UJXS+C2emMKcRokXRkA IoGX20d0NoJtoc1Gu8fQ270zRyBuqceaPWEdcqZt7PjS4W3dxKpeC9Tih7KrjFdyh/iC 1A3bBfy1Azm4GSz8hMcQ9mbWQ3dTld0an9+VrmdIrBGZRmcCbCFNWx7CmhaElomXZQj0 RE6w== X-Gm-Message-State: APf1xPBNeaQDG4O6KBtdksLlQpV4g//P/pp7QtqRIrsLrQaxq6lj4DK9 DXKekYOh9vqxMrzWY8Re+mzML/25RTnlpoqooFE= X-Google-Smtp-Source: AG47ELtydeQr3zJZErKpszARrH2gEeqNq1VLcMjoxcztxKsRY4jIOY2QrwjG5mlsIEi4rE0Gu7CZFSHnguiHNCv2G7k= X-Received: by 10.202.48.211 with SMTP id w202mr11902353oiw.29.1519856380366; Wed, 28 Feb 2018 14:19:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.36 with HTTP; Wed, 28 Feb 2018 14:19:39 -0800 (PST) From: Abdussalam Baryun Date: Thu, 1 Mar 2018 00:19:39 +0200 Message-ID: To: Alexandre PETRESCU Cc: Michelle Wetterwald , its Content-Type: multipart/alternative; boundary="001a113cde9ea9545905664d2310" Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB- interoperability 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, 28 Feb 2018 22:19:43 -0000 --001a113cde9ea9545905664d2310 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 28, 2018 at 4:08 PM, Alexandre PETRESCU < alexandre.petrescu@cea.fr> wrote: > > -- > Alexandre Petrescualexandre.petrescu@cea.fr, t=C3=A9l 0169089223 > > > Le 28/02/2018 =C3=A0 14:58, Michelle Wetterwald a =C3=A9crit : > > Hi Alex, > > Answers inline. > > 2018-02-28 12:22 GMT+01:00 Alexandre PETRESCU = : > >> [trimmed the CC because mailer problems] >> >> Le 28/02/2018 =C3=A0 11:34, Michelle Wetterwald a =C3=A9crit : >> >>> Hi Alex, >>> >>> Regarding the interoperability between different implementations, it ha= s >>> been fully validated during numerous plugtests events in EU and US, >>> gathering a large set of different implementations. For the EU ones, th= e >>> reports are freely available on the ETSI web site. >>> >> >> I am using the wireshark dissectors on the ETSI web site. >> >> I can tell they show lack of interoperability: several CAM messages from >> several stacks are not understood by these wireshark dissectors. >> > > Can you give references to these stacks? > > > github.com 'rendits', 'vanetza', 'driveits', 'geonetworking', 'btpsap'. > > None puts a QoSData header, each puts a 'Data' header. > > (but none sends CAM as IP messages either). > Any implementer uses the easy way to transmit, so future work can develop it. > > > >> The ETSI wireshark dissectors have another problem themselves: they are >> not integrated in the main wireshark software. It's just ETSI's point o= f >> view. >> >> I am sorry to hear that the open source implementation that you are usin= g >>> has some limitations. I remember that one of the participants to the la= st >>> PlugTest in Livorno (Nov 2016) explained to me he had extended the open >>> source software to use his computer to monitor the traffic exchanged on= the >>> 802.11p. So he made his Ath implementation fully interoperable with tho= se >>> from the other vendors. Maybe you can apply similar upgrades to your >>> testing implementations? >>> >> >> Can you tell me who is that participant so I can contact? >> > > Sorry, NDA applies here. But the list of vendors is in the report. > > > The reference to the report please? > > >> Again, I disagree with the change you propose in the text of the draft, >>> as it goes against the *existing* EU regulations. Compliance with the >>> modified text would prevent vendors from accessing the EU market. >>> >> >> Accessing EU market is a good thing, but customer lock in may not be tha= t >> good. >> > > This is not customer lock-in, there are several and diverse > implementations available (BTW, this is more an L2 than an L3-IETF > related topic), the only thing is that you have to pay for getting them, > which is often part of the market rules, right? > > > There are software features in limited deployment that deserve a certain > amount of money. > But key aspects like running IP are free of charge. > > For example, it is worth attaching a price tag for software in a limited > deployment (e.g. this highway), but IP is much wider scale. You cant put= a > price tag on it. > > Is there a requirement that an RFC can be approved only if several open > source implementations are available? > > > No, there is no such requirement. > There is no requirement, and it can be solved if required, so IMO we should not ask for it because this draft is only transmission over. > > But there is requirement for interoperability. I can test for > interoperability because I can use some open-source stacks. > The open source software are not standards or they are standards? if not they may not follow our standards, and if yes they need to follow the use requirement of ieee802.11-ocb > For one, they are not interoperable among themselves when it comes to > QoSData, but _are_ interoperable if they use Data. > Why test results are not interoperable for QoS? AB --001a113cde9ea9545905664d2310 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Feb 28, 2018 at 4:08 PM, Alexandre PETRESCU &= lt;alexandre= .petrescu@cea.fr> wrote:
=20 =20 =20 


--
Alexandre Petrescu
alexandre.petrescu@cea.fr, =
t=C3=A9l 0169089223
Le 28/02/2018 =C3= =A0 14:58, Michelle Wetterwald a =C3=A9crit=C2=A0:
=20
Hi Alex,

Answers inline.

2018-02-28 12:22 GMT+01:00 Alexandre PETRESCU <alexandre.petrescu@cea.fr>:
[trimmed the CC because mailer problems]

Le 28/02/2018 =C3=A0 11:34, Michelle Wetterwald a =C3=A9cri= t=C2=A0:
Hi Alex,

Regarding the interoperability between different implementations, it has been fully validated during numerous plugtests events=C2=A0in EU and US, gathering a large set of different implementations. For the EU ones, the reports are freely available on the ETSI=C2=A0w= eb site.

I am using the wireshark dissectors on the ETSI web site.

I can tell they show lack of interoperability: several CAM messages from several stacks are not understood by these wireshark dissectors.

Can you give references to these stacks?=C2=A0

github.com &= #39;rendits', 'vanetza', 'driveits', 'geonetworking= ', 'btpsap'.

None puts a QoSData header, each puts a 'Data' header.

(but none sends CAM as IP messages either).

=
Any implementer uses the easy way to transmit,=C2=A0so future wo= rk can=C2=A0develop it.=C2=A0



The ETSI wireshark dissectors have another problem themselves: they are not integrated in the main wireshark software.=C2=A0 It's just ETSI's point of= view.

I am sorry to hear that the open source implementation that you are using has some limitations. I remember that one of the participants to the last PlugTest in Livorno (Nov 2016) explained to me he had extended the open source software to use his computer=C2=A0to monitor=C2=A0the traffic exchanged on the 802.11p. So he made his Ath implementation fully interoperable with those from the other vendors. Maybe you can apply=C2=A0similar upgrades to your testing implementations?

Can you tell me who is that participant so I can contact?

Sorry, NDA applies here.=C2=A0But the list of vendors is i= n the report.

The reference to the report please?


Again, I disagree with the change you propose in the text of the draft, as it=C2=A0goes against=C2=A0the *existing* EU regulations.=C2=A0Compliance with the modified text would prevent=C2=A0vendors from accessing the EU market.

 Accessing EU market is a good thing, but customer lock in may not be that good.

This is not customer lock-in, there are several and diverse implementations available (BTW, this is more an L2 than an L3-IETF related=C2=A0topic), the only thing is that y= ou have to pay for getting them, which is=C2=A0often part=C2=A0o= f the market rules, right?

 There are software features in limited deployment that deserve a certain amount of money.
But key aspects like running IP are free of charge.

For example, it is worth attaching a price tag for software in a limited deployment (e.g. this highway), but IP is much wider scale.=C2= =A0 You cant put a price tag on it.

Is there a requirement that an RFC can be approved only if several open source implementations are available?

No, there is no such requirement.

=
There is no requirement, and it can be solved if required, so IMO we s= hould not ask for it because this draft=C2=A0is only transmission over.
=C2=A0

But there is requirement for interoperability.=C2=A0 I can test for interoperability because I can use some open-source stacks.=C2=A0
=

The open source=C2=A0software are not stan= dards or they are standards? if not they may not follow our standards, and = if yes they need to follow the use requirement of ieee802.11-ocb
=
=C2=A0
For one, they are not interoperable among themselves when it comes to QoSData, but _are_ interoperable if they use Data.

Why test results are not interoperable for QoS?=C2=A0

AB

--001a113cde9ea9545905664d2310-- From nobody Wed Feb 28 14:48:28 2018 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5CE126FDC for ; Wed, 28 Feb 2018 14:48:26 -0800 (PST) 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 tmJDlF-VxDsu for ; Wed, 28 Feb 2018 14:48:24 -0800 (PST) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0523126FB3 for ; Wed, 28 Feb 2018 14:48:24 -0800 (PST) Received: by mail-oi0-x22d.google.com with SMTP id x12so3060793oie.13 for ; Wed, 28 Feb 2018 14:48:24 -0800 (PST) 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=V6qHJKwRBZTR3FxhNwWNiT2IDykpC0fliVh+lgDr6iw=; b=FHLybrQucaLGFP0aISpIO7EHPZmCiWU/ohTB0lRuFk3+Tq1wIYBymnw6zqOrrqoaqD AOMZoDMAFzOdz0/kQVIpCDAt/ThWVIlFlE8iSqYNPAR06PWSsA+5oPyU38yF290/bx9d rmoobbbgLpMqnKlwITr27CTTPkgi+s3NOlUo4koCnqxlKuUNg0m07jLQ3ylpzM5nMbVr Uze4Iuky+mVoxNP9+pk6G6+YK6G6wXZbqB6CkRZ0QrVsdHTB6z0shOc5m4Koeo3tXjHB xRcjzeD/Fq7Ox4p2V7yUJwHzMndoQq6hndH+jvoYb/PqpkePH2O9b64nI5kqrprqf+A+ V8GQ== 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=V6qHJKwRBZTR3FxhNwWNiT2IDykpC0fliVh+lgDr6iw=; b=O6LEf8fLdcT056pqNt3e61qor+XIPWF8IrKI0CVOIySU2OJSLmiKnt9d+JAZ4kmrLK ty/iW59UtpmRDg/60d4CH7gjZjyGRsq0xNs+z06QLVlVRSVlyqI4l1SF1hDPswn8OpCI ZSWzhXthxEjjM1fneLe+DLVAec3F85k8AAOpSB/FdgvPD5le7F4dHozoeZjhDeYumCTx oyCg9xlbfdaO+zTPHnb6gMsYJe2/rNMtImR64vHIQkpbh1nnH84DbOcCJs10fniVPFpA yDqqQukXEIo1GgjDN5nXZF+AxB/q9gMxmhTBJd0y/thlpvPw6hYoC+thQApbvkCkG1hC ch3w== X-Gm-Message-State: APf1xPAPUyyR3mrRCI0qqhJuGZBBrnXeeVj34FKOA510hpTT2H29PTw7 imVlwO1hVxc8OEz7kWXg6LzpLqwoY5cS9VL358Q= X-Google-Smtp-Source: AG47ELvPxUZw0OmYjpOa6BH6URhXzvsNSQKm8HhcJW03r5SESKdIFvzk/+jwrDLQrF/JGR5gabLAOYGcjA5l55aQ8as= X-Received: by 10.202.204.203 with SMTP id c194mr13057260oig.156.1519858103676; Wed, 28 Feb 2018 14:48:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.36 with HTTP; Wed, 28 Feb 2018 14:48:23 -0800 (PST) In-Reply-To: References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <006301d3ace3$25f9d500$71ed7f00$@eurecom.fr> <007901d3aee3$a9985ba0$fcc912e0$@eurecom.fr> <00f801d3af1d$f20ce4c0$d626ae40$@gmail.com> <002b01d3af21$6e779a70$4b66cf50$@eurecom.fr> <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> From: Abdussalam Baryun Date: Thu, 1 Mar 2018 00:48:23 +0200 Message-ID: To: Alexandre Petrescu Cc: "Bless, Roland (TM)" , =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , =?UTF-8?Q?Fran=C3=A7ois_Simon?= , its Content-Type: multipart/alternative; boundary="001a1134f34260f24905664d8aba" Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB - implementations 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, 28 Feb 2018 22:48:26 -0000 --001a1134f34260f24905664d8aba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 28, 2018 at 1:15 PM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > > > Le 28/02/2018 =C3=A0 11:04, Bless, Roland (TM) a =C3=A9crit : > [...] > >> However, more detailed guidance provides https://tools.ietf.org/html/rf >> c7127 >> >> A Proposed Standard specification is stable, has resolved known >> design choices, has received significant community review, and >> appears to enjoy enough community interest to be considered valuable= . >> >> [...] >> >> The IESG may require implementation and/or operational experience >> prior to granting Proposed Standard status to a specification that >> materially affects the core Internet protocols or that specifies >> behavior that may have significant operational impact on the >> Internet. >> > > In my humble oppinion, this draft IPv6-over-OCB -19: > - has not resolved known design choices. (Data vs QoSData) > we need to work on this, by using the ieee802.11ocb procedures/requirements > - has received significant review > - appears to enjoy community interest > > I am not IESG so I dont know what to think about what IESG will request. > we should not worry about it. > > From past experience in other RFCs I learned it is always good to have > interoprable implementations before going to IESG. > My experience seen some standards with no open-implementations, I don't think we should worry about this. I will change the word good in your sentence to the word 'excellent', if available. Many companies close implementations for different good purposes. Yes we need to make sure of interoperability, but how can we know to test while the draft still does not say what is the way to transmit voice packets or video packets. Let us say first in the draft/proposal then test. > >> So for Internet Standard: >> >> A specification for which significant implementation and successful >> operational experience has been obtained may be elevated to the >> Internet Standard level. >> >> Because some drafts get submitted, some become RFCs, and some never get >>> the success one expects them to (read: no implementation). >>> >> >> Even if you have implementations it does not mean that it is widely >> used. So implementations are hardly a measure for success, but running >> code is always good to have to show that it's viable. I was involved in >> a WG where people had strong objections and found the protocols too >> complex. This really wasn't the case as we had several implementations >> done by students...however, the opponents just ignored the running code.= .. >> >> RFC8325 is pretty new, but I expect that some recent APs from >>>> a larger vendor will support this, since they did the proposal. >>>> >>> >>> Thanks for the clarification. >>> >>> Since RFC8325 is on the Standards Track, I believe there should be more >>> than just one vendor supporting it (otherwise it were EXPERIMENTAL or >>> INFORMATIONAL). Maybe that vendor proposed an implementation as open >>> source, and agreed somehow by some non-that-vendor implementers. >>> >> my understanding is usually implementations happen after standardization specially when doing L2 or L1, it is better that all interested-industry agree on standard then they implement. for above layers like L3-L7, we can do both ways, but best way to implement then standardization. For this draft we are doing IPv6 over L2 protocol, so it is different situation, because both layers are implemented, so IMHO we have implementations within companies but we need to recommend the standard for best practices. > >> No, it's not how it works, see above. Proposed Standard is usually >> considered to be good enough to get interoperable implementations. >> Internet-Drafts with available (or even open) implementations are often >> considered as being better than those without. So running code is >> usually considered being a plus for I-Ds or PS documents, but it's >> normally not required unless solicited by the IESG. >> > > You think we dont need two different implementations to interoperate > before going to IESG? > ieee802.11ocb protocol is already implemented/tested and it is interoperable, but what is the problem, sorry maybe I did not follow the discussion well, AB --001a1134f34260f24905664d8aba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Feb 28, 2018 at 1:15 PM, Alexandre Petrescu &= lt;alexan= dre.petrescu@gmail.com> wrote:


Le 28/02/2018 =C3=A0 11:04, Bless, Roland (TM) a =C3=A9crit=C2=A0:
[...]
However, more detailed guidance provides https://tools.ietf.org/h= tml/rfc7127

=C2=A0 =C2=A0 A Proposed Standard specification is stable, has resolved kno= wn
=C2=A0 =C2=A0 design choices, has received significant community review, an= d
=C2=A0 =C2=A0 appears to enjoy enough community interest to be considered v= aluable.

=C2=A0 =C2=A0 [...]

=C2=A0 =C2=A0 The IESG may require implementation and/or operational experi= ence
=C2=A0 =C2=A0 prior to granting Proposed Standard status to a specification= that
=C2=A0 =C2=A0 materially affects the core Internet protocols or that specif= ies
=C2=A0 =C2=A0 behavior that may have significant operational impact on the<= br> =C2=A0 =C2=A0 Internet.

In my humble oppinion, this draft IPv6-over-OCB -19:
- has not resolved known design choices. (Data vs QoSData)
=

we need to work on this, by using the ieee802.11ocb pro= cedures/requirements
=C2=A0
- has received significant review
- appears to enjoy community interest

I am not IESG so I dont know what to think about what IESG will request.

we should not worry about it.=C2=A0
=

>From past experience in other RFCs I learned it is always good to have inte= roprable implementations before going to IESG.

My experience seen some standards with no open-implementations, I d= on't think we should worry about this. I will change the word good in y= our sentence to the word 'excellent', if available. Many companies = close implementations for different good purposes. Yes we need to make sure= of interoperability, but how can we know to test while the draft still doe= s not say what is the way to transmit voice packets or video packets. Let u= s say first in the draft/proposal then test.



So for Internet Standard:

=C2=A0 =C2=A0 A specification for which significant implementation and succ= essful
=C2=A0 =C2=A0 operational experience has been obtained may be elevated to t= he
=C2=A0 =C2=A0 Internet Standard level.

Because some drafts get submitted, some become RFCs, and some never get
the success one expects them to (read: no implementation).

Even if you have implementations it does not mean that it is widely
used. So implementations are hardly a measure for success, but running
code is always good to have to show that it's viable. I was involved in=
a WG where people had strong objections and found the protocols too
complex. This really wasn't the case as we had several implementations<= br> done by students...however, the opponents just ignored the running code...<= br>
RFC8325 is pretty new, but I expect that some recent APs from
a larger vendor will support this, since they did the proposal.

Thanks for the clarification.

Since RFC8325 is on the Standards Track, I believe there should be more
than just one vendor supporting it (otherwise it were EXPERIMENTAL or
INFORMATIONAL).=C2=A0 Maybe that vendor proposed an implementation as open<= br> source, and agreed somehow by some non-that-vendor implementers.

my understanding is usu= ally implementations happen after standardization specially when doing L2 o= r L1, it is better that all interested-industry agree on standard then they= implement. for above layers like L3-L7, we can do both ways, but best way = to implement then standardization.

For this draft = we are doing IPv6 over L2 protocol, so it is different situation, because b= oth layers are implemented, so IMHO we have implementations within companie= s but we need to recommend the standard for best practices.
=C2= =A0

No, it's not how it works, see above. Proposed Standard is usually
considered to be good enough to get interoperable implementations.
Internet-Drafts with available (or even open) implementations are often
considered as being better than those without. So running code is
usually considered being a plus for I-Ds or PS documents, but it's
normally not required unless solicited by the IESG.

You think we dont need two different implementations to interoperate before= going to IESG?

ieee802.11ocb protocol = is already implemented/tested and it is interoperable, but what is the prob= lem, sorry maybe I did not follow the discussion well,

=
AB
--001a1134f34260f24905664d8aba--