From nobody Thu Mar 1 06: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 A435F12E057 for ; Thu, 1 Mar 2018 06:19:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 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, 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 JIRfFpIZ1Ruw for ; Thu, 1 Mar 2018 06:18: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 608ED12E053 for ; Thu, 1 Mar 2018 06:18:58 -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 w21EItps125452; Thu, 1 Mar 2018 15:18:55 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 721D6206118; Thu, 1 Mar 2018 15:18: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 5D29E2060AC; Thu, 1 Mar 2018 15:18: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 w21EItDh031926; Thu, 1 Mar 2018 15:18:55 +0100 To: Abdussalam Baryun Cc: Michelle Wetterwald , its References: From: Alexandre PETRESCU Organization: CEA Message-ID: <85f60bbf-b821-750a-98a2-f253ce1f136f@cea.fr> Date: Thu, 1 Mar 2018 15:18: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: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060904010505030906070805" 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: Thu, 01 Mar 2018 14:19:02 -0000 This is a cryptographically signed message in MIME format. --------------ms060904010505030906070805 Content-Type: multipart/alternative; boundary="------------D6607365292D443195F49309" Content-Language: fr This is a multi-part message in MIME format. --------------D6607365292D443195F49309 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 23:19, Abdussalam Baryun a =C3=A9crit=C2=A0: > > > On Wed, Feb 28, 2018 at 4:08 PM, Alexandre PETRESCU=20 > > wrote: > > > -- > Alexandre Petrescu > alexandre.petrescu@cea.fr , t=C3=A9= l 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 >> >: >> >> [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 l= arge >> 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). > > > Any implementer uses the easy way to transmit,=C2=A0so future work=20 > can=C2=A0develop it. > > > >> >> 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=A0t= he >> 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 t= o >> 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 re= port. > > 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 you have to pa= y >> for getting them, which is=C2=A0often part=C2=A0of the market rule= s, 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=20 > should not ask for it because this draft=C2=A0is only transmission over= =2E > > > But there is requirement for interoperability.=C2=A0 I can test for= > interoperability because I can use some open-source stacks. > > > The open source=C2=A0software are not standards or they are standards? = if=20 > not they may not follow our standards, and if yes they need to follow=20 > the use requirement of ieee802.11-ocb Open source is a good thing.=C2=A0 It was instrumental in validating many= =20 Internet Drafts before. > > 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? Because if someone sends QoS Data (like the proprietary V2X stacks) and=20 other people send Data instead of QoS Data at the same time (like the=20 open source implementations of IP-over-OCB, or like the open source=20 implementations of V2X), there is no quarantee that the QoS expectations = of the first be satisfied. Alex > > AB > --------------D6607365292D443195F49309 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 23:19, Abdussalam= Baryun a =C3=A9crit=C2=A0:


On Wed, Feb 28, 2018 at 4:08 PM, Alexandre PETRESCU <alexandre.petrescu@cea.fr>= ; wrote:


--
Alexandre Petrescu
al=
exandre.petrescu@cea.fr, t=C3=A9l 0169089223
Le 28/02/2018 =C3=A0 14:58, Michelle Wetterwald a =C3=A9= crit=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 Wetter= wald 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, gathe= ring 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?=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).

Any implementer uses the easy way to transmit,=C2=A0so future work 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 v= iew.

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 yo= ur 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 implementations available (BTW, this is more an L2 than an L3-IETF related=C2=A0topic), the only thing i= s that you have to pay for getting 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.=C2=A0 You cant put a price ta= g 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=C2=A0is only transmission over.
=C2=A0

But there is requirement for interoperability.=C2=A0 I ca= n test for interoperability because I can use some open-source stacks.=C2=A0

The open source=C2=A0software 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

Open source is a good thing.=C2=A0 It was instrumental in validating = many Internet Drafts before.


=C2=A0
For one, they ar= e not interoperable among themselves when it comes to QoSData, but _are_ interoperable if they use Data.

Why test results are not interoperable for QoS?

Because if someone sends QoS Data (like the proprietary V2X stacks) and other people send Data instead of QoS Data at the same time (like the open source implementations of IP-over-OCB, or like the open source implementations of V2X), there is no quarantee that the QoS expectations of the first be satisfied.

Alex


AB


--------------D6607365292D443195F49309-- --------------ms060904010505030906070805 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 CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODAzMDExNDE4NTVaMC8GCSqGSIb3 DQEJBDEiBCDZCLpAmkSKVfYzzM0Zp2QhnKs2WC+BwL2/N5XELEbY+zBSBgkrBgEEAYI3EAQx RTBDMD0xCzAJBgNVBAYTAkZSMQwwCgYDVQQKDANDRUExIDAeBgNVBAMMF0NFQSBBQyBVdGls aXNhdGV1ciAyMDMxAgIYEjBUBgsqhkiG9w0BCRACCzFFoEMwPTELMAkGA1UEBhMCRlIxDDAK BgNVBAoMA0NFQTEgMB4GA1UEAwwXQ0VBIEFDIFV0aWxpc2F0ZXVyIDIwMzECAhgSMGwGCSqG SIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJ KoZIhvcNAQEBBQAEggEABUkV8lmZOOWUrp8KyMecoQesfl0JKjljSs7RhRsO7WEKF0UlRyFR koKJSDC/l0b1v0jfL7HiyMFtUSBmWobNE5x+obHrffZdtsT2hKhQS19qOoI+bhDSfK8QbonL yVBXz2rV3Fez74Gnp46N4jaPs1x2VlHw5Ij6i9dByaQeIYbCPFtU68YYF+IGFqk4dIuMVUWD AR47XzAwW3g8D2rD5KRB4aFRW/U7zYdaRubvN5j+Lx3VIAHKnEPJbTpUsjlU/Flu1p0LOopN gg/fZsZvrIDtjY5Jht4pkTtwS1+qYBcK2VtT6g1hfzVkrvUfZ9znxHJ+trEMmY2JTOwfyRfW hwAAAAAAAA== --------------ms060904010505030906070805-- From nobody Thu Mar 1 06:20: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 2ED0D12E053 for ; Thu, 1 Mar 2018 06:20: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 2133p7AeK2ps for ; Thu, 1 Mar 2018 06:20:09 -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 B5102126D3F for ; Thu, 1 Mar 2018 06:20:08 -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 w21EK66u126006; Thu, 1 Mar 2018 15:20:06 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 245832060E9; Thu, 1 Mar 2018 15:20: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 069F42060A7; Thu, 1 Mar 2018 15:20:06 +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 w21EK5wI001134; Thu, 1 Mar 2018 15:20:05 +0100 To: Abdussalam Baryun Cc: "Bless, Roland (TM)" , =?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> <00f801d3af1d$f20ce4c0$d626ae40$@gmail.com> <002b01d3af21$6e779a70$4b66cf50$@eurecom.fr> <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> From: Alexandre Petrescu Message-ID: <2cd6f697-abbe-7d2b-33f4-5dd6a41a61d1@gmail.com> Date: Thu, 1 Mar 2018 15:20: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] 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: Thu, 01 Mar 2018 14:20:10 -0000 Le 28/02/2018 à 23:48, Abdussalam Baryun a écrit : [...] > 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, It is a QoS problem. I think we can set it aside. I will propose again separate text. Alex From nobody Thu Mar 1 06:32: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 C076A12E858 for ; Thu, 1 Mar 2018 06:32: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 Oz9K_djlkW1u for ; Thu, 1 Mar 2018 06:32: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 27B6612E86D for ; Thu, 1 Mar 2018 06:32: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 w21EWfAM002981; Thu, 1 Mar 2018 15:32:41 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7545E205F25; Thu, 1 Mar 2018 15:32: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 6190D2013C0; Thu, 1 Mar 2018 15: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 w21EWfjh014813; Thu, 1 Mar 2018 15:32:41 +0100 To: Abdussalam Baryun Cc: "Bless, Roland (TM)" , =?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> <00f801d3af1d$f20ce4c0$d626ae40$@gmail.com> <002b01d3af21$6e779a70$4b66cf50$@eurecom.fr> <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> From: Alexandre Petrescu Message-ID: Date: Thu, 1 Mar 2018 15: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 - 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: Thu, 01 Mar 2018 14:32:45 -0000 I received some feedback from programmer. Le 28/02/2018 à 23:48, Abdussalam Baryun a écrit : [...] > 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, Here is the QoS problem for IP over 802.11 OCB in implementations. In short, in open source on linux, we dont know how to send IP packets transported as 802.11 QoSData, all IP packets are transported as 802.11 Data instead. - if you ping -Q at 5.9GHz in OCB mode, the DSCP fields do get set properly in IP headers of Echorequest, but there is no .11 QoSData headers in packets. Normally, one expects the QoSData headers to be present there when the DSCP (an IP field) is set. - if you want to modify kernel, and force always to use QoSData headers on WiFi, including OCB at 5.9GHz, there is a net/mac80211/tx.c file with a flag called wme_sta that you could set to true. But take care that the C comments there say that it's not normal to use QoSData headers in OCB mode, because a terminal sending QoSData has no guarantee that receivers also use QoSData (the negotiation of QoS capabilities are absent in OCB). As you can see, this can be long to try and fix. Until then I will propose to set QoS aside from IP-over-OCB at this time. Alex From nobody Thu Mar 1 06:48: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 3F6B312DA46 for ; Thu, 1 Mar 2018 06:48:19 -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 cda525roiqU6 for ; Thu, 1 Mar 2018 06:48: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 8F054129502 for ; Thu, 1 Mar 2018 06:48:16 -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 w21EmECW019919 for ; Thu, 1 Mar 2018 15:48:14 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E154220619C for ; Thu, 1 Mar 2018 15:48:14 +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 D2ED5206199 for ; Thu, 1 Mar 2018 15:48:14 +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 w21EmEEs031940 for ; Thu, 1 Mar 2018 15:48:14 +0100 To: 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: <1eca0280-0931-fa39-5706-cadc22cca17c@gmail.com> Date: Thu, 1 Mar 2018 15:48:14 +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 - new text proposal X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 01 Mar 2018 14:48:19 -0000 Hi, I propose this new resolution: say "802.11 headers" instead of "Data Headers" and of "QoS Data Headers". Which header to use is left outside the scope of this document. OLD: > At reception, this layer takes as input the IEEE 802.11 Data Header > and the Logical-Link Layer Control Header and produces an Ethernet II > Header. NEW: > At reception, this layer takes as input the IEEE 802.11 header and the > Logical-Link Layer Control Header and produces an Ethernet II Header. OLD: > 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. NEW: > The Receiver and Transmitter Address fields in the 802.11 header MUST > contain the same values as the Destination and the Source Address > fields in the Ethernet II Header, respectively. 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. [...] > [I-D.ietf-tsvwg-ieee-802-11], although it is not specific to OCB > mode. NEW: > The specification of the 802.11 header used to transmit IP packets is > outside the scope of this document. I hope you dont disagree. Alex Le 28/02/2018 à 08:39, Alexandre Petrescu a écrit : > 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 > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its From nobody Thu Mar 1 07:48: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 AC28212EC05 for ; Thu, 1 Mar 2018 07:48: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, 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 IPWl1--HA8rg for ; Thu, 1 Mar 2018 07:48: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 18C0812D7E6 for ; Thu, 1 Mar 2018 07:47: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 w21FllqC030688 for ; Thu, 1 Mar 2018 16:47:47 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 799C9205F23 for ; Thu, 1 Mar 2018 16:47: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 6EB3A206246 for ; Thu, 1 Mar 2018 16:47: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 w21Fllvj032553 for ; Thu, 1 Mar 2018 16:47:47 +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> <00f801d3af1d$f20ce4c0$d626ae40$@gmail.com> <002b01d3af21$6e779a70$4b66cf50$@eurecom.fr> <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> From: Alexandre Petrescu Message-ID: <5ccad588-bcd8-d179-165b-7936a34220fb@gmail.com> Date: Thu, 1 Mar 2018 16:47: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: multipart/mixed; boundary="------------16921B385F8C43910E426398" Content-Language: fr 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: Thu, 01 Mar 2018 15:48:07 -0000 This is a multi-part message in MIME format. --------------16921B385F8C43910E426398 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit In a private discussion, this question came up: Is there a packet dump showing an IP packet transported with .11 QoSData headers in OCB mode at 5.9GHz. (there are some packet dumps with IP packets transported with .11 Data headers in OCB mode at 5.9GHz, e.g. attached). Alex Le 01/03/2018 à 15:32, Alexandre Petrescu a écrit : > I received some feedback from programmer. > > Le 28/02/2018 à 23:48, Abdussalam Baryun a écrit : > [...] >> 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, > > Here is the QoS problem for IP over 802.11 OCB in implementations. > > In short, in open source on linux, we dont know how to send IP packets > transported as 802.11 QoSData, all IP packets are transported as 802.11 > Data instead. > > - if you ping -Q at 5.9GHz in OCB mode, the DSCP fields do get >   set properly in IP headers of Echorequest, but there is no .11 QoSData >   headers in packets.  Normally, one expects the QoSData headers to be >   present there when the DSCP (an IP field) is set. > > - if you want to modify kernel, and force always to use QoSData headers >   on WiFi, including OCB at 5.9GHz, there is a net/mac80211/tx.c file >   with a flag called wme_sta that you could set to true.  But take care >   that the C comments there say that it's not normal to use QoSData >   headers in OCB mode, because a terminal sending QoSData has no >   guarantee that receivers also use QoSData (the negotiation of QoS >   capabilities are absent in OCB). > > As you can see, this can be long to try and fix. > > Until then I will propose to set QoS aside from IP-over-OCB at this time. > > Alex > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its --------------16921B385F8C43910E426398 Content-Type: application/octet-stream; name="captura_cams2.pcap" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="captura_cams2.pcap" 1MOyoQIABAAAAAAAAAAAAP//AAB/AAAAX5GHVwBVAACfAAAAnwAAAAAAIgAvSAAAfUJVNgEA AAAQGAwXQAHnAQAAAAAAAAAAAAAIAAAAMzMAAAABMBRK5keZ////////kOyqqgMAAACG3WAA AAAAMREB/oAAAAAAAAAyFEr//uZHmf8CAAAAAAAAAAAAAAAAAAGZ+8NQADH9BgECAAAAFxBg ACmJ2UWtUtIEaLzdoAA291gAdBAAACIBMEqAC6mAD//AcCIO0mCRh1eMRgAAnwAAAJ8AAAAA ACIAL0gAABl1ZDYBAAAAEBgMF0AB6AEAAAAAAAAAAAAACAAAADMzAAAAATAUSuZHmf////// /9DsqqoDAAAAht1gAAAAADERAf6AAAAAAAAAMhRK//7mR5n/AgAAAAAAAAAAAAAAAAABiAPD UAAxDv4BAgAAABcQYQApidlFrVLSBGi83aAANvdYAHQQAAAiATBKgAupgA//wMbTbMVgkYdX nvcAAHYAAAB2AAAAAAAiAC9IAABOJmU2AQAAABAYDBdAAegBAAAAAAAAAAAAAAgAAAAzMwAA AAIwFErmR5n////////g7KqqAwAAAIbdYAAAAAAIOv8AAAAAAAAAAAAAAAAAAAAA/wIAAAAA AAAAAAAAAAAAAoUAe7gAAAAAyZigI2GRh1cCMAAAnwAAAJ8AAAAAACIAL0gAAMWfczYBAAAA EBgMF0AB6AEAAAAAAAAAAAAACAAAADMzAAAAATAUSuZHmf///////yDtqqoDAAAAht1gAAAA ADERAf6AAAAAAAAAMhRK//7mR5n/AgAAAAAAAAAAAAAAAAAB4T7DUAAxtcEBAgAAABcQYgAp idlFrVLSBGi83aAANvdYAHQQAAAiATBKgAupgA//wCMp+uRikYdX8nEAAJ8AAACfAAAAAAAi AC9IAADXIoM2AQAAABAYDBdAAegBAAAAAAAAAAAAAAgAAAAzMwAAAAEwFErmR5n///////9g 7aqqAwAAAIbdYAAAAAAxEQH+gAAAAAAAADIUSv/+5keZ/wIAAAAAAAAAAAAAAAAAAbBuw1AA MeZwAQIAAAAXEGMAKYnZRc1S0gRovN2gADb3WAB0EAAAIgEwSoALqYAP/8BOhpOoY5GHVzJk AACfAAAAnwAAAAAAIgAvSAAAN1aSNgEAAAAQGAwXQAHoAQAAAAAAAAAAAAAIAAAAMzMAAAAB MBRK5keZ////////oO2qqgMAAACG3WAAAAAAMREB/oAAAAAAAAAyFEr//uZHmf8CAAAAAAAA AAAAAAAAAAHnH8NQADGv3gECAAAAFxBkACmJ2UWtUtIEaLzdoAA291gAdBAAACIBMEqAC6mA D//ApuOGLmSRh1f8TgAAnwAAAJ8AAAAAACIAL0gAACuCoTYBAAAAEBgMF0AB6AEAAAAAAAAA AAAACAAAADMzAAAAATAUSuZHmf///////+DtqqoDAAAAht1gAAAAADERAf6AAAAAAAAAMhRK //7mR5n/AgAAAAAAAAAAAAAAAAABoCHDUAAx+SIBAgAAABcQZQApidlFrVLSBGkglkAANvdY AHQQAAAcATBKgAupgA//wH84dV9kkYdXyAQBAHYAAAB2AAAAAAAiAC9IAAAGOKI2AQAAABAY DBdAAecBAAAAAAAAAAAAAAgAAAAzMwAAAAIwFErmR5n////////w7aqqAwAAAIbdYAAAAAAI Ov8AAAAAAAAAAAAAAAAAAAAA/wIAAAAAAAAAAAAAAAAAAoUAe7gAAAAAG6ZcTGWRh1fCGw4A nwAAAJ8AAAAAACIAL0gAAOmOvjYBAAAAEBgMF0AB6AEAAAAAAAAAAAAACAAAADMzAAAAATAU SuZHmf///////1DuqqoDAAAAht1gAAAAADERAf6AAAAAAAAAMhRK//7mR5n/AgAAAAAAAAAA AAAAAAABvUTDUAAx2vkBAgAAABcQZgApidlNLVLSAukglkAANvxYAHQQAAAXATBKgAupgA// wPREXwlmkYdXWm0BAJ8AAACfAAAAAAAiAC9IAACzIsE2AQAAABAYDBdAAegBAAAAAAAAAAAA AAgAAAAzMwAAAAEwFErmR5n///////9w7qqqAwAAAIbdYAAAAAAxEQH+gAAAAAAAADIUSv/+ 5keZ/wIAAAAAAAAAAAAAAAAAAeG7w1AAMa4GAQIAAAAXEGcAKYnZU+1S0gGnpI8AADcAGAB0 EAAAFgEwSoALqYAP/8DRScfLZ5GHVyg8AACfAAAAnwAAAAAAIgAvSAAAozLPNgEAAAAQGAwX QAHoAQAAAAAAAAAAAAAIAAAAMzMAAAABMBRK5keZ////////oO6qqgMAAACG3WAAAAAAMREB /oAAAAAAAAAyFEr//uZHmf8CAAAAAAAAAAAAAAAAAAGDAMNQADHNfwECAAAAFxBoACmJ2VQt UtIBp6SPAAA3AVgAdBAAABUBMEqAC6mAD//A3uqyx2iRh1cOQgAAnwAAAJ8AAAAAACIAL0gA AKV53jYBAAAAEBgMF0AB6AEAAAAAAAAAAAAACAAAADMzAAAAATAUSuZHmf///////+DuqqoD AAAAht1gAAAAADERAf6AAAAAAAAAMhRK//7mR5n/AgAAAAAAAAAAAAAAAAAB5DHDUAAxb4YB AgAAABcQaQApidlUDVLSAcdTVkAANwFWAHQQAAAlATBKgAupgA//wFiFZoVokYdXRgkBAHYA AAB2AAAAAAAiAC9IAADsQN82AQAAABAYDBdAAegBAAAAAAAAAAAAAAgAAAAzMwAAAAIwFErm R5n///////8A76qqAwAAAIbdYAAAAAAIOv8AAAAAAAAAAAAAAAAAAAAA/wIAAAAAAAAAAAAA AAAAAoUAe7gAAAAAouqN7mmRh1dSZwAAnwAAAJ8AAAAAACIAL0gAAC3g7TYBAAAAEBgMF0AB 5wEAAAAAAAAAAAAACAAAADMzAAAAATAUSuZHmf///////0DvqqoDAAAAht1gAAAAADERAf6A AAAAAAAAMhRK//7mR5n/AgAAAAAAAAAAAAAAAAABxQ3DUAAxfqkBAgAAABcQagApidlULVLS AadTVkAANwFWAHQQAAA1ATBKgAupgA//wLlgN7dqkYdX9mMAAJ8AAACfAAAAAAAiAC9IAADX Hf02AQAAABAYDBdAAegBAAAAAAAAAAAAAAgAAAAzMwAAAAEwFErmR5n///////9w76qqAwAA AIbdYAAAAAAxEQH+gAAAAAAAADIUSv/+5keZ/wIAAAAAAAAAAAAAAAAAAcS7w1AAMX76AQIA AAAXEGsAKYnZVC1S0gGnU1ZAADcBVgB0EAAANQEwSoALqYAP/8AeDmdi --------------16921B385F8C43910E426398-- From nobody Thu Mar 1 07:50: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 DD7FA12E9DD for ; Thu, 1 Mar 2018 07:50:25 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=onboardsecurity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWBUlQlFnIA0 for ; Thu, 1 Mar 2018 07:50:24 -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 F37B612E8FA for ; Thu, 1 Mar 2018 07:50:23 -0800 (PST) Received: by mail-qt0-x235.google.com with SMTP id n12so8086886qtl.5 for ; Thu, 01 Mar 2018 07:50:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onboardsecurity.com; s=google; h=message-id:mime-version:to:from:subject:date:importance:in-reply-to :references; bh=wP7N5XUSYL/R73LcOeWXM0P+r6b7+gyTJyaslEOWTUI=; b=crN5VVkZ1uj3jH6wWkA61wk0rgENFqJuUC1E0OFJp+Nwx8q+cSPHwclzmr/o/7GDgn 1od6l4rKn94a9I7FRMsi917XwoReUn1W9KqWC8iUzH9cXxW7g3RygNhAUCaUHBPBMBjL Va3PgD+awZjptDa7xXRI5U6EdrluO75Z0q5gE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:mime-version:to:from:subject:date :importance:in-reply-to:references; bh=wP7N5XUSYL/R73LcOeWXM0P+r6b7+gyTJyaslEOWTUI=; b=fnXhR3iw2OW3YhNGeTo5sDIs67qWSJVycly0JNE6T2YmhOJdX13mDh/vpOb8/nz1NU LmYtG+w3vbQP93kYjYMTfzbBDNImIeyxHp4c3fAp25SuNrQWQnCeeyXG/3LInfC1qrtr X9Ndh1BQDE0eiKyBuWIH0x79hgT+NZnOkZCufOkCxnd0k+q0P7V+RSjQCMVoZ/KECzHh tvZ+ul21g3Km0UZLX4pYAf65m9zhCot8bP/dWRsnO6rRdUHvSKR71zYNQjvEWRfi1vhF eRZPaKguVPLFphKHPquzz7WMwYN2HDWeAqqREHZgXCQz7gixYv8HLkjImCxYNDbSacjF 80qw== X-Gm-Message-State: AElRT7GL9WhOkZ7v+iWm5u3u6u9TFfJe41XORn8gFH31buqCMhDDpC3/ C9ELLxpFXpTUSaqz9CMzII7K7g== X-Google-Smtp-Source: AG47ELuqdgKlBNtFb3hGz/V7zeoW9KkaLQTbru3YQxBW2zNHIRRdto0R66rlk3A4FcLHgEczgmbqBw== X-Received: by 10.237.54.230 with SMTP id f93mr3431306qtb.139.1519919422919; Thu, 01 Mar 2018 07:50:22 -0800 (PST) Received: from ?IPv6:::ffff:192.168.0.141? ([207.251.68.132]) by smtp.gmail.com with ESMTPSA id g17sm3129991qtc.67.2018.03.01.07.50.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Mar 2018 07:50:21 -0800 (PST) Message-ID: <5a98213d.d138c80a.ababc.519f@mx.google.com> MIME-Version: 1.0 To: Alexandre Petrescu , "its@ietf.org" From: William Whyte Date: Thu, 1 Mar 2018 10:50:21 -0500 Importance: normal X-Priority: 3 In-Reply-To: <5ccad588-bcd8-d179-165b-7936a34220fb@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> <00f801d3af1d$f20ce4c0$d626ae40$@gmail.com> <002b01d3af21$6e779a70$4b66cf50$@eurecom.fr> <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> <5ccad588-bcd8-d179-165b-7936a34220fb@gmail.com> Content-Type: multipart/alternative; boundary="_0F69F397-72C7-4F9E-A2CD-484520175A5B_" 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: Thu, 01 Mar 2018 15:50:26 -0000 --_0F69F397-72C7-4F9E-A2CD-484520175A5B_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" >> (there are some packet dumps with IP packets transported with .11 Data=20 headers in OCB mode at 5.9GHz, e.g. attached). My understanding is OCB mode requires QoSData, so those packets aren=E2=80= =99t conformant to the standard. Cheers, William Sent from Mail for Windows 10 From: Alexandre Petrescu Sent: Thursday, March 1, 2018 10:48 AM To: its@ietf.org Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OC= B -implementations In a private discussion, this question came up: Is there a packet dump showing an IP packet transported with .11 QoSData=20 headers in OCB mode at 5.9GHz. (there are some packet dumps with IP packets transported with .11 Data=20 headers in OCB mode at 5.9GHz, e.g. attached). Alex Le 01/03/2018 =C3=A0 15:32, Alexandre Petrescu a =C3=A9crit=C2=A0: > I received some feedback from programmer. >=20 > Le 28/02/2018 =C3=A0 23:48, Abdussalam Baryun a =C3=A9crit=C2=A0: > [...] >> ieee802.11ocb protocol is already implemented/tested and it is=20 >> interoperable, but what is the problem, sorry maybe I did not follow=20 >> the discussion well, >=20 > Here is the QoS problem for IP over 802.11 OCB in implementations. >=20 > In short, in open source on linux, we dont know how to send IP packets=20 > transported as 802.11 QoSData, all IP packets are transported as 802.11=20 > Data instead. >=20 > - if you ping -Q at 5.9GHz in OCB mode, the DSCP fields do get > =C2=A0 set properly in IP headers of Echorequest, but there is no .11 Qo= SData > =C2=A0 headers in packets.=C2=A0 Normally, one expects the QoSData heade= rs to be > =C2=A0 present there when the DSCP (an IP field) is set. >=20 > - if you want to modify kernel, and force always to use QoSData headers > =C2=A0 on WiFi, including OCB at 5.9GHz, there is a net/mac80211/tx.c fi= le > =C2=A0 with a flag called wme_sta that you could set to true.=C2=A0 But = take care > =C2=A0 that the C comments there say that it's not normal to use QoSData > =C2=A0 headers in OCB mode, because a terminal sending QoSData has no > =C2=A0 guarantee that receivers also use QoSData (the negotiation of QoS > =C2=A0 capabilities are absent in OCB). >=20 > As you can see, this can be long to try and fix. >=20 > Until then I will propose to set QoS aside from IP-over-OCB at this time. >=20 > Alex >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its --_0F69F397-72C7-4F9E-A2CD-484520175A5B_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

>> (there are some packet dump= s with IP packets transported with .11 Data

headers in OCB mode at 5.9GHz, e.g. attached).

 

My understanding is = OCB mode requires QoSData, so those packets aren=E2=80=99t conformant to th= e standard.

 

Cheers,

 

William

 

Sent from Mai= l for Windows 10

 

From: Alexan= dre Petrescu
Sent: Thursday, March 1, 2018 10:48 AM
To:= its@ietf.org
Subject: Re= : [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB -implemen= tations

 

In a private discussion, this question came up:

 

Is there a packet dump showing = an IP packet transported with .11 QoSData

headers = in OCB mode at 5.9GHz.

 

(there are some packet dumps with IP packets transported with= .11 Data

headers in OCB mode at 5.9GHz, e.g. atta= ched).

 

Al= ex

 

Le 01/= 03/2018 =C3=A0 15:32, Alexandre Petrescu a =C3=A9crit :

> I received some feedback from programmer.

>

> Le 28/02/2018 =C3=A0 23:48, Abduss= alam Baryun a =C3=A9crit :

> [...]

>> ieee802.11ocb protocol is already implemented/test= ed and it is

>> interoperable, but what is t= he problem, sorry maybe I did not follow

>> = the discussion well,

>

= > Here is the QoS problem for IP over 802.11 OCB in implementations.

=

>

> In short, in open s= ource on linux, we dont know how to send IP packets

> transported as 802.11 QoSData, all IP packets are transported as 802= .11

> Data instead.

>= ;

> - if you ping -Q at 5.9GHz in OCB mode, the= DSCP fields do get

>=C2=A0   set properly = in IP headers of Echorequest, but there is no .11 QoSData

>=C2=A0   headers in packets.  Normally, one expects th= e QoSData headers to be

>=C2=A0   present t= here when the DSCP (an IP field) is set.

>

<= p class=3DMsoNormal>> - if you want to modify kernel, and force always t= o use QoSData headers

>=C2=A0   on WiFi, in= cluding OCB at 5.9GHz, there is a net/mac80211/tx.c file

>=C2=A0   with a flag called wme_sta that you could set to tr= ue.  But take care

>=C2=A0   that the = C comments there say that it's not normal to use QoSData

>=C2=A0   headers in OCB mode, because a terminal sending QoS= Data has no

>=C2=A0   guarantee that receiv= ers also use QoSData (the negotiation of QoS

>= =C2=A0   capabilities are absent in OCB).

>=

> As you can see, this can be long to try and = fix.

>

> Until then = I will propose to set QoS aside from IP-over-OCB at this time.

>

> Alex

>

> ______________________________________= _________

> its mailing list

> its@ietf.org

> https://www.ietf.org/ma= ilman/listinfo/its

 

= --_0F69F397-72C7-4F9E-A2CD-484520175A5B_-- From nobody Thu Mar 1 07:54: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 03ECB12EA24 for ; Thu, 1 Mar 2018 07:54:28 -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 wGGsros-O4AX for ; Thu, 1 Mar 2018 07:54:26 -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 1B17012D885 for ; Thu, 1 Mar 2018 07:54:25 -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 w21FsOnD044126; Thu, 1 Mar 2018 16:54:24 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7446C206171; Thu, 1 Mar 2018 16:54: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 6768F205EEC; Thu, 1 Mar 2018 16:54: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 w21FsO2F006489; Thu, 1 Mar 2018 16:54:24 +0100 To: William Whyte , "its@ietf.org" References: <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> <5ccad588-bcd8-d179-165b-7936a34220fb@gmail.com> <5a98213d.d138c80a.ababc.519f@mx.google.com> From: Alexandre Petrescu Message-ID: Date: Thu, 1 Mar 2018 16:54: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: <5a98213d.d138c80a.ababc.519f@mx.google.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 -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: Thu, 01 Mar 2018 15:54:28 -0000 Le 01/03/2018 à 16:50, William Whyte a écrit : > >> (there are some packet dumps with IP packets transported with .11 Data > > headers in OCB mode at 5.9GHz, e.g. attached). > > My understanding is OCB mode requires QoSData, so those packets aren’t > conformant to the standard. I propose we rename 'OCB' into 'IP-OCB' in the draft. 'IP-OCB' is an OCB mode that can be transport IP packets with .11 Data headers or with .11 QoS Data headers. Alex > > Cheers, > > William > > Sent from Mail for > Windows 10 > > *From: *Alexandre Petrescu > *Sent: *Thursday, March 1, 2018 10:48 AM > *To: *its@ietf.org > *Subject: *Re: [ipwave] 802.11 Data vs 802.11 QoS Data in > IPv6-over-802.11-OCB -implementations > > In a private discussion, this question came up: > > Is there a packet dump showing an IP packet transported with .11 QoSData > > headers in OCB mode at 5.9GHz. > > (there are some packet dumps with IP packets transported with .11 Data > > headers in OCB mode at 5.9GHz, e.g. attached). > > Alex > > Le 01/03/2018 à 15:32, Alexandre Petrescu a écrit : > > > I received some feedback from programmer. > > > > > > Le 28/02/2018 à 23:48, Abdussalam Baryun a écrit : > > > [...] > > >> 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, > > > > > > Here is the QoS problem for IP over 802.11 OCB in implementations. > > > > > > In short, in open source on linux, we dont know how to send IP packets > > > transported as 802.11 QoSData, all IP packets are transported as 802.11 > > > Data instead. > > > > > > - if you ping -Q at 5.9GHz in OCB mode, the DSCP fields do get > > >    set properly in IP headers of Echorequest, but there is no .11 QoSData > > >    headers in packets.  Normally, one expects the QoSData headers to be > > >    present there when the DSCP (an IP field) is set. > > > > > > - if you want to modify kernel, and force always to use QoSData headers > > >    on WiFi, including OCB at 5.9GHz, there is a net/mac80211/tx.c file > > >    with a flag called wme_sta that you could set to true.  But take care > > >    that the C comments there say that it's not normal to use QoSData > > >    headers in OCB mode, because a terminal sending QoSData has no > > >    guarantee that receivers also use QoSData (the negotiation of QoS > > >    capabilities are absent in OCB). > > > > > > As you can see, this can be long to try and fix. > > > > > > Until then I will propose to set QoS aside from IP-over-OCB at this time. > > > > > > Alex > > > > > > _______________________________________________ > > > its mailing list > > > its@ietf.org > > > https://www.ietf.org/mailman/listinfo/its > From nobody Thu Mar 1 07:59: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 6252712E8D3 for ; Thu, 1 Mar 2018 07:59: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=onboardsecurity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovOOoaFhQOpu for ; Thu, 1 Mar 2018 07:59:52 -0800 (PST) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::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 E0B0312D72F for ; Thu, 1 Mar 2018 07:59:51 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id j4so8116039qth.8 for ; Thu, 01 Mar 2018 07:59:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onboardsecurity.com; s=google; h=message-id:mime-version:to:from:subject:date:importance:in-reply-to :references; bh=GEtbyt/Sb0tw1uOlavIiShcJ4Gh3xuOWdOeitW9lqwM=; b=eEorJ+CUT4SByjaHo5wD0Y7ma5J2kCklpE+TzlRqQIF94c3dT90sbAecnKmGbnpfZO 9mlixt3vLqFhuqAicNuZ9NfWNXbd8Ig6ku1zHnveX8JWAIOTdIScAqHu/SY3/GBN4cKD yWgrT2gSxJObAG6jvdBBywefYa8ofRdDx1Y/A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:mime-version:to:from:subject:date :importance:in-reply-to:references; bh=GEtbyt/Sb0tw1uOlavIiShcJ4Gh3xuOWdOeitW9lqwM=; b=kinDpx3g56mT+cubIJb7qGn5qFDvynRnOXG4cF5sDNzwS+f0V/TqgNQCaeUEstq2Y8 oKLM4mE6xMcfX7ATDUwzL2uILjALq40cZ+u7LAKvMf9RaadQPhD7gFmDIEwq8hPXXT7b Yr+0XzTIlXN2bYJLHWGiuESMf5t5PqDZa6BI4jSIBZomOl7c02mKPv1COLfvSQR6s+Xz pBaILxZ36pI1mhGxA/Ggw6vxjg6X0zajkcJXLPE6uXaJavrU2tB75+lVLJUIt6PGMU3P tZuz2/0fDIZbtiYOOP5z8DpJj4N6XGK50Ia2olNqz8mzYDcELUGhT43XMkT2hGrEiAou Izyg== X-Gm-Message-State: AElRT7HqS2HqsbeuPyzKsVAW6MXcNY8Ynp2IT8g2JnfrsZ9zId0n7q4F Rso49qufgzJ8+ZzoerIrAeROiw== X-Google-Smtp-Source: AG47ELsuAc/3RQCiDiLsuYllcoRN4/Y1RkuX58/n0Jb94RAP1eFFemWmdm9Y/0GzYG6/aeI7Sc+ZoQ== X-Received: by 10.200.26.55 with SMTP id v52mr3761751qtj.53.1519919990812; Thu, 01 Mar 2018 07:59:50 -0800 (PST) Received: from ?IPv6:::ffff:192.168.0.141? ([207.251.68.132]) by smtp.gmail.com with ESMTPSA id p4sm3015871qtd.55.2018.03.01.07.59.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Mar 2018 07:59:49 -0800 (PST) Message-ID: <5a982375.042bed0a.1271f.4afc@mx.google.com> MIME-Version: 1.0 To: Alexandre Petrescu , "its@ietf.org" From: William Whyte Date: Thu, 1 Mar 2018 10:59:49 -0500 Importance: normal X-Priority: 3 In-Reply-To: References: <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> <5ccad588-bcd8-d179-165b-7936a34220fb@gmail.com> <5a98213d.d138c80a.ababc.519f@mx.google.com> Content-Type: multipart/alternative; boundary="_60477C9E-38BB-4B27-8DB4-F5DABFE1FFBF_" 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: Thu, 01 Mar 2018 15:59:54 -0000 --_60477C9E-38BB-4B27-8DB4-F5DABFE1FFBF_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" > I propose we rename 'OCB' into 'IP-OCB' in the draft. > 'IP-OCB' is an OCB mode that can be transport IP packets with .11 Data=20 > headers or with .11 QoS Data headers. If it=E2=80=99s over OCB, then it needs to use QoSData. If you=E2=80=99re d= oing Data, you=E2=80=99re not conformant to OCB. There can=E2=80=99t be an = OCB mode that transports packets with .11 Data, because OCB by definition u= ses QoSData. If the draft implies that you can do non-conformant OCB, that= =E2=80=99s a serious defect in the draft. Some implementations may not yet have implemented this, but that=E2=80=99s = on those developers. Cheers, William Sent from Mail for Windows 10 From: Alexandre Petrescu Sent: Thursday, March 1, 2018 10:54 AM To: William Whyte; its@ietf.org Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OC= B-implementations Le 01/03/2018 =C3=A0 16:50, William Whyte a =C3=A9crit=C2=A0: > >> (there are some packet dumps with IP packets transported with .11 Dat= a >=20 > headers in OCB mode at 5.9GHz, e.g. attached). >=20 > My understanding is OCB mode requires QoSData, so those packets aren=E2= =80=99t=20 > conformant to the standard. I propose we rename 'OCB' into 'IP-OCB' in the draft. 'IP-OCB' is an OCB mode that can be transport IP packets with .11 Data=20 headers or with .11 QoS Data headers. Alex >=20 > Cheers, >=20 > William >=20 > Sent from Mail for=20 > Windows 10 >=20 > *From: *Alexandre Petrescu > *Sent: *Thursday, March 1, 2018 10:48 AM > *To: *its@ietf.org > *Subject: *Re: [ipwave] 802.11 Data vs 802.11 QoS Data in=20 > IPv6-over-802.11-OCB -implementations >=20 > In a private discussion, this question came up: >=20 > Is there a packet dump showing an IP packet transported with .11 QoSData >=20 > headers in OCB mode at 5.9GHz. >=20 > (there are some packet dumps with IP packets transported with .11 Data >=20 > headers in OCB mode at 5.9GHz, e.g. attached). >=20 > Alex >=20 > Le 01/03/2018 =C3=A0 15:32, Alexandre Petrescu a =C3=A9crit=C2=A0: >=20 > > I received some feedback from programmer. >=20 > > >=20 > > Le 28/02/2018 =C3=A0 23:48, Abdussalam Baryun a =C3=A9crit=C2=A0: >=20 > > [...] >=20 > >> ieee802.11ocb protocol is already implemented/tested and it is >=20 > >> interoperable, but what is the problem, sorry maybe I did not follow >=20 > >> the discussion well, >=20 > > >=20 > > Here is the QoS problem for IP over 802.11 OCB in implementations. >=20 > > >=20 > > In short, in open source on linux, we dont know how to send IP packets >=20 > > transported as 802.11 QoSData, all IP packets are transported as 802.1= 1 >=20 > > Data instead. >=20 > > >=20 > > - if you ping -Q at 5.9GHz in OCB mode, the DSCP fields do get >=20 > >=C2=A0 =C2=A0 set properly in IP headers of Echorequest, but there is n= o .11 QoSData >=20 > >=C2=A0 =C2=A0 headers in packets.=C2=A0 Normally, one expects the QoSDa= ta headers to be >=20 > >=C2=A0 =C2=A0 present there when the DSCP (an IP field) is set. >=20 > > >=20 > > - if you want to modify kernel, and force always to use QoSData header= s >=20 > >=C2=A0 =C2=A0 on WiFi, including OCB at 5.9GHz, there is a net/mac80211= /tx.c file >=20 > >=C2=A0 =C2=A0 with a flag called wme_sta that you could set to true.=C2= =A0 But take care >=20 > >=C2=A0 =C2=A0 that the C comments there say that it's not normal to use= QoSData >=20 > >=C2=A0 =C2=A0 headers in OCB mode, because a terminal sending QoSData h= as no >=20 > >=C2=A0 =C2=A0 guarantee that receivers also use QoSData (the negotiatio= n of QoS >=20 > >=C2=A0 =C2=A0 capabilities are absent in OCB). >=20 > > >=20 > > As you can see, this can be long to try and fix. >=20 > > >=20 > > Until then I will propose to set QoS aside from IP-over-OCB at this ti= me. >=20 > > >=20 > > Alex >=20 > > >=20 > > _______________________________________________ >=20 > > its mailing list >=20 > > its@ietf.org >=20 > > https://www.ietf.org/mailman/listinfo/its >=20 --_60477C9E-38BB-4B27-8DB4-F5DABFE1FFBF_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

> I propose we rename 'OCB' into = 'IP-OCB' in the draft.

 =

> 'IP-OCB' is an OCB mode that can be transport= IP packets with .11 Data

> headers = or with .11 QoS Data headers.

 = ;

If it=E2=80=99s over OCB, then it needs to = use QoSData. If you=E2=80=99re doing Data, you=E2=80=99re not conformant to= OCB. There can=E2=80=99t be an OCB mode that transports packets with .11 D= ata, because OCB by definition uses QoSData. If the draft implies that you = can do non-conformant OCB, that=E2=80=99s a serious defect in the draft.

 

Some implem= entations may not yet have implemented this, but that=E2=80=99s on those de= velopers.

 

Cheers,

 

= William

 

<= o:p> 

 

Sent from Mail for Windows 10

 

From: Alexandre Petrescu
Sent: Thursday, March 1, 2018 10:54 AMTo: William Whyte= ; its@ietf.org
Subject: Re: [= ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB-implementati= ons

 

 

 

Le 01/03/2018 =C3=A0 16:50, William Whyte a =C3=A9crit :

=

>=C2=A0 >> (there are some packet dumps with = IP packets transported with .11 Data

>

> headers in OCB mode at 5.9GHz, e.g. attached).

>

> My understanding is OCB= mode requires QoSData, so those packets aren=E2=80=99t

> conformant to the standard.

 <= /o:p>

I propose we rename 'OCB' into 'IP-OCB' in th= e draft.

 

= 'IP-OCB' is an OCB mode that can be transport IP packets with .11 Data

=

headers or with .11 QoS Data headers.

 

Alex

 

>

> Cheers,

>

> Wi= lliam

>

> Sent from = Mail <https://go.microsoft.com/fwlink/?LinkId=3D550986> for

> Windows 10

>

> *From: *Alexandre Petrescu <mailto:alexandre.petrescu@= gmail.com>

> *Sent: *Thursday, March 1, 2018 = 10:48 AM

> *To: *its@ietf.org <mailto:its@iet= f.org>

> *Subject: *Re: [ipwave] 802.11 Data = vs 802.11 QoS Data in

> IPv6-over-802.11-OCB -i= mplementations

>

> I= n a private discussion, this question came up:

>=

> Is there a packet dump showing an IP packet = transported with .11 QoSData

>

> headers in OCB mode at 5.9GHz.

>

> (there are some packet dumps with IP packets tr= ansported with .11 Data

>

> headers in OCB mode at 5.9GHz, e.g. attached).

>

> Alex

>

> Le 01/03/2018 =C3=A0 15:32, Alexandre Petrescu = a =C3=A9crit :

>

&= gt;=C2=A0 > I received some feedback from programmer.

>

>=C2=A0 >

>

>=C2=A0 > Le 28/02/2018 =C3=A0 23:48, = Abdussalam Baryun a =C3=A9crit :

>

>=C2=A0 > [...]

>

>=C2=A0 >> ieee802.11ocb protocol is already imp= lemented/tested and it is

>

>=C2=A0 >> interoperable, but what is the problem, sorry mayb= e I did not follow

>

&g= t;=C2=A0 >> the discussion well,

>

>=C2=A0 >

>

>=C2=A0 > Here is the QoS problem for IP over 802.11 OCB= in implementations.

>

= >=C2=A0 >

>

>= =C2=A0 > In short, in open source on linux, we dont know how to send IP = packets

>

>=C2=A0 &g= t; transported as 802.11 QoSData, all IP packets are transported as 802.11<= /p>

>

>=C2=A0 > Data = instead.

>

>=C2=A0 &= gt;

>

>=C2=A0 > -= if you ping -Q at 5.9GHz in OCB mode, the DSCP fields do get

>

>=C2=A0 >    set= properly in IP headers of Echorequest, but there is no .11 QoSData

>

>=C2=A0 >   = headers in packets.  Normally, one expects the QoSData headers to be<= /p>

>

>=C2=A0 > =   present there when the DSCP (an IP field) is set.

>

>=C2=A0 >

>

>=C2=A0 > - if you want to modify ker= nel, and force always to use QoSData headers

> <= /p>

>=C2=A0 >    on WiFi, including OCB= at 5.9GHz, there is a net/mac80211/tx.c file

> =

>=C2=A0 >    with a flag called wm= e_sta that you could set to true.  But take care

>

>=C2=A0 >    that the C co= mments there say that it's not normal to use QoSData

>

>=C2=A0 >    headers in OCB= mode, because a terminal sending QoSData has no

&g= t;

>=C2=A0 >    guarantee that rec= eivers also use QoSData (the negotiation of QoS

>= ;

>=C2=A0 >    capabilities are ab= sent in OCB).

>

>=C2= =A0 >

>

>=C2=A0 &= gt; As you can see, this can be long to try and fix.

>

>=C2=A0 >

>= ;

>=C2=A0 > Until then I will propose to set= QoS aside from IP-over-OCB at this time.

>

=

>=C2=A0 >

>

>=C2=A0 > Alex

>

>=C2=A0 >

>

>=C2=A0 > ______________________________________________= _

>

>=C2=A0 > its= mailing list

>

>=C2= =A0 > its@ietf.org

>

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

>

 

= --_60477C9E-38BB-4B27-8DB4-F5DABFE1FFBF_-- From nobody Thu Mar 1 08:05: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 DDE2212EABE for ; Thu, 1 Mar 2018 08:05:18 -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 kHPp5vJ05aFy for ; Thu, 1 Mar 2018 08:05: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 B2D6212EAA9 for ; Thu, 1 Mar 2018 08:05: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 w21G5EeP161565; Thu, 1 Mar 2018 17:05:14 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A899E206257; Thu, 1 Mar 2018 17:05:14 +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 9B728206215; Thu, 1 Mar 2018 17:05:14 +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 w21G5EUr017421; Thu, 1 Mar 2018 17:05:14 +0100 To: William Whyte , "its@ietf.org" References: <007901d3aee3$a9985ba0$fcc912e0$@eurecom.fr> <00f801d3af1d$f20ce4c0$d626ae40$@gmail.com> <002b01d3af21$6e779a70$4b66cf50$@eurecom.fr> <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> <5ccad588-bcd8-d179-165b-7936a34220fb@gmail.com> <5a98213d.d138c80a.ababc.519f@mx.google.com> <5a982375.042bed0a.1271f.4afc@mx.google.com> From: Alexandre Petrescu Message-ID: <86a2077a-ea46-c99b-c048-60ab78f69ec3@gmail.com> Date: Thu, 1 Mar 2018 17:05:14 +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: <5a982375.042bed0a.1271f.4afc@mx.google.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-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: Thu, 01 Mar 2018 16:05:19 -0000 William, Le 01/03/2018 à 16:59, William Whyte a écrit : > > I propose we rename 'OCB' into 'IP-OCB' in the draft. > > > 'IP-OCB' is an OCB mode that can be transport IP packets with .11 Data > > > headers or with .11 QoS Data headers. > > If it’s over OCB, then it needs to use QoSData. If you’re doing Data, > you’re not conformant to OCB. There can’t be an OCB mode that transports > packets with .11 Data, because OCB by definition uses QoSData. If the > draft implies that you can do non-conformant OCB, that’s a serious > defect in the draft. > > Some implementations may not yet have implemented this, but that’s on > those developers. For one second, allow me the benefit of the doubt about specifications that may not be implemented. I would like to know whether there is an implementation of IP over OCB with QoSData headers? Packet dump is sufficient, or any other kind of statement. I agree with you that many times it is good to write specification first and implementation after. Alex > > Cheers, > > William > > Sent from Mail for > Windows 10 > > *From: *Alexandre Petrescu > *Sent: *Thursday, March 1, 2018 10:54 AM > *To: *William Whyte ; its@ietf.org > > *Subject: *Re: [ipwave] 802.11 Data vs 802.11 QoS Data in > IPv6-over-802.11-OCB-implementations > > Le 01/03/2018 à 16:50, William Whyte a écrit : > > >  >> (there are some packet dumps with IP packets transported with .11 > Data > > > > > > headers in OCB mode at 5.9GHz, e.g. attached). > > > > > > My understanding is OCB mode requires QoSData, so those packets aren’t > > > conformant to the standard. > > I propose we rename 'OCB' into 'IP-OCB' in the draft. > > 'IP-OCB' is an OCB mode that can be transport IP packets with .11 Data > > headers or with .11 QoS Data headers. > > Alex > > > > > > Cheers, > > > > > > William > > > > > > Sent from Mail for > > > Windows 10 > > > > > > *From: *Alexandre Petrescu > > > *Sent: *Thursday, March 1, 2018 10:48 AM > > > *To: *its@ietf.org > > > *Subject: *Re: [ipwave] 802.11 Data vs 802.11 QoS Data in > > > IPv6-over-802.11-OCB -implementations > > > > > > In a private discussion, this question came up: > > > > > > Is there a packet dump showing an IP packet transported with .11 QoSData > > > > > > headers in OCB mode at 5.9GHz. > > > > > > (there are some packet dumps with IP packets transported with .11 Data > > > > > > headers in OCB mode at 5.9GHz, e.g. attached). > > > > > > Alex > > > > > > Le 01/03/2018 à 15:32, Alexandre Petrescu a écrit : > > > > > >  > I received some feedback from programmer. > > > > > >  > > > > > > >  > Le 28/02/2018 à 23:48, Abdussalam Baryun a écrit : > > > > > >  > [...] > > > > > >  >> 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, > > > > > >  > > > > > > >  > Here is the QoS problem for IP over 802.11 OCB in implementations. > > > > > >  > > > > > > >  > In short, in open source on linux, we dont know how to send IP packets > > > > > >  > transported as 802.11 QoSData, all IP packets are transported as > 802.11 > > > > > >  > Data instead. > > > > > >  > > > > > > >  > - if you ping -Q at 5.9GHz in OCB mode, the DSCP fields do get > > > > > >  >    set properly in IP headers of Echorequest, but there is no .11 > QoSData > > > > > >  >    headers in packets.  Normally, one expects the QoSData headers > to be > > > > > >  >    present there when the DSCP (an IP field) is set. > > > > > >  > > > > > > >  > - if you want to modify kernel, and force always to use QoSData > headers > > > > > >  >    on WiFi, including OCB at 5.9GHz, there is a net/mac80211/tx.c file > > > > > >  >    with a flag called wme_sta that you could set to true.  But > take care > > > > > >  >    that the C comments there say that it's not normal to use QoSData > > > > > >  >    headers in OCB mode, because a terminal sending QoSData has no > > > > > >  >    guarantee that receivers also use QoSData (the negotiation of QoS > > > > > >  >    capabilities are absent in OCB). > > > > > >  > > > > > > >  > As you can see, this can be long to try and fix. > > > > > >  > > > > > > >  > Until then I will propose to set QoS aside from IP-over-OCB at > this time. > > > > > >  > > > > > > >  > Alex > > > > > >  > > > > > > >  > _______________________________________________ > > > > > >  > its mailing list > > > > > >  > its@ietf.org > > > > > >  > https://www.ietf.org/mailman/listinfo/its > > > > From nobody Thu Mar 1 08:26: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 82A2212D94B for ; Thu, 1 Mar 2018 08:26:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 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, 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 gDuJUBoJpmkp for ; Thu, 1 Mar 2018 08:26:27 -0800 (PST) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) (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 6B91112D948 for ; Thu, 1 Mar 2018 08:26:26 -0800 (PST) X-IronPort-AV: E=Sophos; i="5.47,408,1515452400"; d="scan'208,217"; a="20976648" Received: from UCP13.tsn.tno.nl (134.221.225.173) by UCP12.tsn.tno.nl (134.221.225.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.845.34; Thu, 1 Mar 2018 17:26:24 +0100 Received: from UCP13.tsn.tno.nl ([fe80::c142:976e:5281:8298]) by UCP13.tsn.tno.nl ([fe80::c142:976e:5281:8298%7]) with mapi id 15.01.0845.034; Thu, 1 Mar 2018 17:26:24 +0100 From: "Velt, R. (Ronald) in 't" To: William Whyte , Alexandre Petrescu , "its@ietf.org" Thread-Topic: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB -implementations Thread-Index: AQHTsXUJ+ZMDOpJSYEq3nz7RS8LsYqO7j41A Date: Thu, 1 Mar 2018 16:26:24 +0000 Message-ID: <637ecbf37e7448568264692f5dc3af3e@tno.nl> 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> <5ccad588-bcd8-d179-165b-7936a34220fb@gmail.com> <5a98213d.d138c80a.ababc.519f@mx.google.com> In-Reply-To: <5a98213d.d138c80a.ababc.519f@mx.google.com> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.191] x-esetresult: clean, is OK x-esetid: 37303A29064AB36F607364 Content-Type: multipart/alternative; boundary="_000_637ecbf37e7448568264692f5dc3af3etnonl_" MIME-Version: 1.0 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: Thu, 01 Mar 2018 16:26:29 -0000 --_000_637ecbf37e7448568264692f5dc3af3etnonl_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 V2lsbGlhbSwNCg0KKGlubGluZSkNCg0KRnJvbTogaXRzIFttYWlsdG86aXRzLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBXaWxsaWFtIFdoeXRlDQpTZW50OiBkb25kZXJkYWcgMSBtYWFy dCAyMDE4IDE2OjUwDQpUbzogQWxleGFuZHJlIFBldHJlc2N1IDxhbGV4YW5kcmUucGV0cmVzY3VA Z21haWwuY29tPjsgaXRzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2lwd2F2ZV0gODAyLjExIERh dGEgdnMgODAyLjExIFFvUyBEYXRhIGluIElQdjYtb3Zlci04MDIuMTEtT0NCIC1pbXBsZW1lbnRh dGlvbnMNCg0KPj4gKHRoZXJlIGFyZSBzb21lIHBhY2tldCBkdW1wcyB3aXRoIElQIHBhY2tldHMg dHJhbnNwb3J0ZWQgd2l0aCAuMTEgRGF0YQ0KaGVhZGVycyBpbiBPQ0IgbW9kZSBhdCA1LjlHSHos IGUuZy4gYXR0YWNoZWQpLg0KDQpNeSB1bmRlcnN0YW5kaW5nIGlzIE9DQiBtb2RlIHJlcXVpcmVz IFFvU0RhdGEsIHNvIHRob3NlIHBhY2tldHMgYXJlbuKAmXQgY29uZm9ybWFudCB0byB0aGUgc3Rh bmRhcmQuDQoNCk5vdCB0cnVlLCBwZXIgODAyLjExLTIwMTYsIGNsYXVzZSAxMS4yMSAuDQoNClRo YW5rcywNClJvbmFsZA0KDQpDaGVlcnMsDQoNCldpbGxpYW0NCg0KU2VudCBmcm9tIE1haWw8aHR0 cHM6Ly9nby5taWNyb3NvZnQuY29tL2Z3bGluay8/TGlua0lkPTU1MDk4Nj4gZm9yIFdpbmRvd3Mg MTANCg0KRnJvbTogQWxleGFuZHJlIFBldHJlc2N1PG1haWx0bzphbGV4YW5kcmUucGV0cmVzY3VA Z21haWwuY29tPg0KU2VudDogVGh1cnNkYXksIE1hcmNoIDEsIDIwMTggMTA6NDggQU0NClRvOiBp dHNAaWV0Zi5vcmc8bWFpbHRvOml0c0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbaXB3YXZlXSA4 MDIuMTEgRGF0YSB2cyA4MDIuMTEgUW9TIERhdGEgaW4gSVB2Ni1vdmVyLTgwMi4xMS1PQ0IgLWlt cGxlbWVudGF0aW9ucw0KDQpJbiBhIHByaXZhdGUgZGlzY3Vzc2lvbiwgdGhpcyBxdWVzdGlvbiBj YW1lIHVwOg0KDQpJcyB0aGVyZSBhIHBhY2tldCBkdW1wIHNob3dpbmcgYW4gSVAgcGFja2V0IHRy YW5zcG9ydGVkIHdpdGggLjExIFFvU0RhdGENCmhlYWRlcnMgaW4gT0NCIG1vZGUgYXQgNS45R0h6 Lg0KDQoodGhlcmUgYXJlIHNvbWUgcGFja2V0IGR1bXBzIHdpdGggSVAgcGFja2V0cyB0cmFuc3Bv cnRlZCB3aXRoIC4xMSBEYXRhDQpoZWFkZXJzIGluIE9DQiBtb2RlIGF0IDUuOUdIeiwgZS5nLiBh dHRhY2hlZCkuDQoNCkFsZXgNCg0KTGUgMDEvMDMvMjAxOCDDoCAxNTozMiwgQWxleGFuZHJlIFBl dHJlc2N1IGEgw6ljcml0IDoNCj4gSSByZWNlaXZlZCBzb21lIGZlZWRiYWNrIGZyb20gcHJvZ3Jh bW1lci4NCj4NCj4gTGUgMjgvMDIvMjAxOCDDoCAyMzo0OCwgQWJkdXNzYWxhbSBCYXJ5dW4gYSDD qWNyaXQgOg0KPiBbLi4uXQ0KPj4gaWVlZTgwMi4xMW9jYiBwcm90b2NvbCBpcyBhbHJlYWR5IGlt cGxlbWVudGVkL3Rlc3RlZCBhbmQgaXQgaXMNCj4+IGludGVyb3BlcmFibGUsIGJ1dCB3aGF0IGlz IHRoZSBwcm9ibGVtLCBzb3JyeSBtYXliZSBJIGRpZCBub3QgZm9sbG93DQo+PiB0aGUgZGlzY3Vz c2lvbiB3ZWxsLA0KPg0KPiBIZXJlIGlzIHRoZSBRb1MgcHJvYmxlbSBmb3IgSVAgb3ZlciA4MDIu MTEgT0NCIGluIGltcGxlbWVudGF0aW9ucy4NCj4NCj4gSW4gc2hvcnQsIGluIG9wZW4gc291cmNl IG9uIGxpbnV4LCB3ZSBkb250IGtub3cgaG93IHRvIHNlbmQgSVAgcGFja2V0cw0KPiB0cmFuc3Bv cnRlZCBhcyA4MDIuMTEgUW9TRGF0YSwgYWxsIElQIHBhY2tldHMgYXJlIHRyYW5zcG9ydGVkIGFz IDgwMi4xMQ0KPiBEYXRhIGluc3RlYWQuDQo+DQo+IC0gaWYgeW91IHBpbmcgLVEgYXQgNS45R0h6 IGluIE9DQiBtb2RlLCB0aGUgRFNDUCBmaWVsZHMgZG8gZ2V0DQo+ICAgIHNldCBwcm9wZXJseSBp biBJUCBoZWFkZXJzIG9mIEVjaG9yZXF1ZXN0LCBidXQgdGhlcmUgaXMgbm8gLjExIFFvU0RhdGEN Cj4gICAgaGVhZGVycyBpbiBwYWNrZXRzLiAgTm9ybWFsbHksIG9uZSBleHBlY3RzIHRoZSBRb1NE YXRhIGhlYWRlcnMgdG8gYmUNCj4gICAgcHJlc2VudCB0aGVyZSB3aGVuIHRoZSBEU0NQIChhbiBJ UCBmaWVsZCkgaXMgc2V0Lg0KPg0KPiAtIGlmIHlvdSB3YW50IHRvIG1vZGlmeSBrZXJuZWwsIGFu ZCBmb3JjZSBhbHdheXMgdG8gdXNlIFFvU0RhdGEgaGVhZGVycw0KPiAgICBvbiBXaUZpLCBpbmNs dWRpbmcgT0NCIGF0IDUuOUdIeiwgdGhlcmUgaXMgYSBuZXQvbWFjODAyMTEvdHguYyBmaWxlDQo+ ICAgIHdpdGggYSBmbGFnIGNhbGxlZCB3bWVfc3RhIHRoYXQgeW91IGNvdWxkIHNldCB0byB0cnVl LiAgQnV0IHRha2UgY2FyZQ0KPiAgICB0aGF0IHRoZSBDIGNvbW1lbnRzIHRoZXJlIHNheSB0aGF0 IGl0J3Mgbm90IG5vcm1hbCB0byB1c2UgUW9TRGF0YQ0KPiAgICBoZWFkZXJzIGluIE9DQiBtb2Rl LCBiZWNhdXNlIGEgdGVybWluYWwgc2VuZGluZyBRb1NEYXRhIGhhcyBubw0KPiAgICBndWFyYW50 ZWUgdGhhdCByZWNlaXZlcnMgYWxzbyB1c2UgUW9TRGF0YSAodGhlIG5lZ290aWF0aW9uIG9mIFFv Uw0KPiAgICBjYXBhYmlsaXRpZXMgYXJlIGFic2VudCBpbiBPQ0IpLg0KPg0KPiBBcyB5b3UgY2Fu IHNlZSwgdGhpcyBjYW4gYmUgbG9uZyB0byB0cnkgYW5kIGZpeC4NCj4NCj4gVW50aWwgdGhlbiBJ IHdpbGwgcHJvcG9zZSB0byBzZXQgUW9TIGFzaWRlIGZyb20gSVAtb3Zlci1PQ0IgYXQgdGhpcyB0 aW1lLg0KPg0KPiBBbGV4DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IGl0cyBtYWlsaW5nIGxpc3QNCj4gaXRzQGlldGYub3JnPG1haWx0bzpp dHNAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXRz DQoNClRoaXMgbWVzc2FnZSBtYXkgY29udGFpbiBpbmZvcm1hdGlvbiB0aGF0IGlzIG5vdCBpbnRl bmRlZCBmb3IgeW91LiBJZiB5b3UgYXJlIG5vdCB0aGUgYWRkcmVzc2VlIG9yIGlmIHRoaXMgbWVz c2FnZSB3YXMgc2VudCB0byB5b3UgYnkgbWlzdGFrZSwgeW91IGFyZSByZXF1ZXN0ZWQgdG8gaW5m b3JtIHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZS4gVE5PIGFjY2VwdHMgbm8gbGlh YmlsaXR5IGZvciB0aGUgY29udGVudCBvZiB0aGlzIGUtbWFpbCwgZm9yIHRoZSBtYW5uZXIgaW4g d2hpY2ggeW91IHVzZSBpdCBhbmQgZm9yIGRhbWFnZSBvZiBhbnkga2luZCByZXN1bHRpbmcgZnJv bSB0aGUgcmlza3MgaW5oZXJlbnQgdG8gdGhlIGVsZWN0cm9uaWMgdHJhbnNtaXNzaW9uIG9mIG1l c3NhZ2VzLgo= --_000_637ecbf37e7448568264692f5dc3af3etnonl_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0 RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29u b3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBw dCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJOTCIgbGluaz0iYmx1ZSIgdmxpbms9IiM5NTRGNzIiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+V2lsbGlhbSw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+KGlubGluZSk8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4w cHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gaXRzIFttYWlsdG86aXRzLWJvdW5jZXNAaWV0Zi5vcmdd DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPldpbGxpYW0gV2h5dGU8YnI+DQo8Yj5TZW50OjwvYj4gZG9u ZGVyZGFnIDEgbWFhcnQgMjAxOCAxNjo1MDxicj4NCjxiPlRvOjwvYj4gQWxleGFuZHJlIFBldHJl c2N1ICZsdDthbGV4YW5kcmUucGV0cmVzY3VAZ21haWwuY29tJmd0OzsgaXRzQGlldGYub3JnPGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbaXB3YXZlXSA4MDIuMTEgRGF0YSB2cyA4MDIuMTEgUW9T IERhdGEgaW4gSVB2Ni1vdmVyLTgwMi4xMS1PQ0IgLWltcGxlbWVudGF0aW9uczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzUuNHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7 Jmd0OyAodGhlcmUgYXJlIHNvbWUgcGFja2V0IGR1bXBzIHdpdGggSVAgcGFja2V0cyB0cmFuc3Bv cnRlZCB3aXRoIC4xMSBEYXRhDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+aGVh ZGVycyBpbiBPQ0IgbW9kZSBhdCA1LjlHSHosIGUuZy4gYXR0YWNoZWQpLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJFTi1V UyI+TXkgdW5kZXJzdGFuZGluZyBpcyBPQ0IgbW9kZSByZXF1aXJlcyBRb1NEYXRhLCBzbyB0aG9z ZSBwYWNrZXRzIGFyZW7igJl0IGNvbmZvcm1hbnQgdG8gdGhlIHN0YW5kYXJkLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+Tm90IHRydWUsIHBlciA4MDIuMTEtMjAxNiwgY2xhdXNlIDExLjIxIC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Um9uYWxkPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5DaGVlcnMs PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxz cGFuIGxhbmc9IkVOLVVTIj5XaWxsaWFtPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5TZW50IGZyb20gPGEgaHJl Zj0iaHR0cHM6Ly9nby5taWNyb3NvZnQuY29tL2Z3bGluay8/TGlua0lkPTU1MDk4NiI+DQpNYWls PC9hPiBmb3IgV2luZG93cyAxMDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48Yj48c3BhbiBsYW5n PSJFTi1VUyI+RnJvbTogPC9zcGFuPg0KPC9iPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJt YWlsdG86YWxleGFuZHJlLnBldHJlc2N1QGdtYWlsLmNvbSI+QWxleGFuZHJlIFBldHJlc2N1PC9h Pjxicj4NCjxiPlNlbnQ6IDwvYj5UaHVyc2RheSwgTWFyY2ggMSwgMjAxOCAxMDo0OCBBTTxicj4N CjxiPlRvOiA8L2I+PGEgaHJlZj0ibWFpbHRvOml0c0BpZXRmLm9yZyI+aXRzQGlldGYub3JnPC9h Pjxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW2lwd2F2ZV0gODAyLjExIERhdGEgdnMgODAyLjEx IFFvUyBEYXRhIGluIElQdjYtb3Zlci04MDIuMTEtT0NCIC1pbXBsZW1lbnRhdGlvbnM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNS40cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+SW4gYSBwcml2YXRlIGRpc2N1c3Npb24sIHRoaXMgcXVlc3Rpb24g Y2FtZSB1cDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1 LjRwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPklzIHRoZXJlIGEgcGFja2V0IGR1bXAgc2hvd2luZyBh biBJUCBwYWNrZXQgdHJhbnNwb3J0ZWQgd2l0aCAuMTEgUW9TRGF0YQ0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+ PHNwYW4gbGFuZz0iRU4tVVMiPmhlYWRlcnMgaW4gT0NCIG1vZGUgYXQgNS45R0h6LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz NS40cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5n PSJFTi1VUyI+KHRoZXJlIGFyZSBzb21lIHBhY2tldCBkdW1wcyB3aXRoIElQIHBhY2tldHMgdHJh bnNwb3J0ZWQgd2l0aCAuMTEgRGF0YQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRU4tVVMi PmhlYWRlcnMgaW4gT0NCIG1vZGUgYXQgNS45R0h6LCBlLmcuIGF0dGFjaGVkKS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUu NHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0i RU4tVVMiPkFsZXg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM1LjRwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPkxlIDAxLzAzLzIwMTggw6AgMTU6MzIsIEFsZXhh bmRyZSBQZXRyZXNjdSBhIMOpY3JpdCZuYnNwOzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+Jmd0OyBJIHJlY2VpdmVkIHNvbWUgZmVlZGJhY2sgZnJvbSBwcm9ncmFtbWVyLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNS40cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFuIGxh bmc9IkVOLVVTIj4mZ3Q7IExlIDI4LzAyLzIwMTggw6AgMjM6NDgsIEFiZHVzc2FsYW0gQmFyeXVu IGEgw6ljcml0Jm5ic3A7OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IFsu Li5dPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsmZ3Q7IGllZWU4MDIuMTFv Y2IgcHJvdG9jb2wgaXMgYWxyZWFkeSBpbXBsZW1lbnRlZC90ZXN0ZWQgYW5kIGl0IGlzDQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyZndDsgaW50ZXJvcGVyYWJsZSwgYnV0 IHdoYXQgaXMgdGhlIHByb2JsZW0sIHNvcnJ5IG1heWJlIEkgZGlkIG5vdCBmb2xsb3cNCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNS40cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7Jmd0OyB0aGUgZGlzY3Vzc2lvbiB3ZWxs LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNS40cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxz cGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IEhlcmUgaXMgdGhlIFFvUyBwcm9ibGVtIGZvciBJUCBvdmVy IDgwMi4xMSBPQ0IgaW4gaW1wbGVtZW50YXRpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj4mZ3Q7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IEluIHNo b3J0LCBpbiBvcGVuIHNvdXJjZSBvbiBsaW51eCwgd2UgZG9udCBrbm93IGhvdyB0byBzZW5kIElQ IHBhY2tldHMNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IHRyYW5zcG9y dGVkIGFzIDgwMi4xMSBRb1NEYXRhLCBhbGwgSVAgcGFja2V0cyBhcmUgdHJhbnNwb3J0ZWQgYXMg ODAyLjExDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBEYXRhIGluc3Rl YWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgLSBpZiB5b3UgcGluZyAtUSBhdCA1LjlHSHogaW4gT0NC IG1vZGUsIHRoZSBEU0NQIGZpZWxkcyBkbyBnZXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+Jmd0OyZuYnNwOyAmbmJzcDsgc2V0IHByb3Blcmx5IGluIElQIGhlYWRlcnMgb2YgRWNo b3JlcXVlc3QsIGJ1dCB0aGVyZSBpcyBubyAuMTEgUW9TRGF0YTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFu IGxhbmc9IkVOLVVTIj4mZ3Q7Jm5ic3A7ICZuYnNwOyBoZWFkZXJzIGluIHBhY2tldHMuJm5ic3A7 IE5vcm1hbGx5LCBvbmUgZXhwZWN0cyB0aGUgUW9TRGF0YSBoZWFkZXJzIHRvIGJlPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1 LjRwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsmbmJzcDsgJm5ic3A7IHByZXNlbnQgdGhlcmUg d2hlbiB0aGUgRFNDUCAoYW4gSVAgZmllbGQpIGlzIHNldC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBs YW5nPSJFTi1VUyI+Jmd0OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAt IGlmIHlvdSB3YW50IHRvIG1vZGlmeSBrZXJuZWwsIGFuZCBmb3JjZSBhbHdheXMgdG8gdXNlIFFv U0RhdGEgaGVhZGVyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7Jm5ic3A7 ICZuYnNwOyBvbiBXaUZpLCBpbmNsdWRpbmcgT0NCIGF0IDUuOUdIeiwgdGhlcmUgaXMgYSBuZXQv bWFjODAyMTEvdHguYyBmaWxlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsm bmJzcDsgJm5ic3A7IHdpdGggYSBmbGFnIGNhbGxlZCB3bWVfc3RhIHRoYXQgeW91IGNvdWxkIHNl dCB0byB0cnVlLiZuYnNwOyBCdXQgdGFrZSBjYXJlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0i RU4tVVMiPiZndDsmbmJzcDsgJm5ic3A7IHRoYXQgdGhlIEMgY29tbWVudHMgdGhlcmUgc2F5IHRo YXQgaXQncyBub3Qgbm9ybWFsIHRvIHVzZSBRb1NEYXRhPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZndDsmbmJzcDsgJm5ic3A7IGhlYWRlcnMgaW4gT0NCIG1vZGUsIGJlY2F1c2Ug YSB0ZXJtaW5hbCBzZW5kaW5nIFFvU0RhdGEgaGFzIG5vPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZndDsmbmJzcDsgJm5ic3A7IGd1YXJhbnRlZSB0aGF0IHJlY2VpdmVycyBhbHNv IHVzZSBRb1NEYXRhICh0aGUgbmVnb3RpYXRpb24gb2YgUW9TPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4g bGFuZz0iRU4tVVMiPiZndDsmbmJzcDsgJm5ic3A7IGNhcGFiaWxpdGllcyBhcmUgYWJzZW50IGlu IE9DQikuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRw dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgQXMgeW91IGNhbiBzZWUsIHRoaXMgY2FuIGJlIGxv bmcgdG8gdHJ5IGFuZCBmaXguPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsg PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgVW50aWwgdGhlbiBJIHdpbGwg cHJvcG9zZSB0byBzZXQgUW9TIGFzaWRlIGZyb20gSVAtb3Zlci1PQ0IgYXQgdGhpcyB0aW1lLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNS40cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFu IGxhbmc9IkVOLVVTIj4mZ3Q7IEFsZXg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+ Jmd0OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFuIGxh bmc9IkVOLVVTIj4mZ3Q7IGl0cyBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5n PSJFTi1VUyI+Jmd0OyA8YSBocmVmPSJtYWlsdG86aXRzQGlldGYub3JnIj4NCml0c0BpZXRmLm9y ZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyA8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2l0cyI+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2l0czwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBzdHlsZT0iTUFS R0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFN SUxZOiAnQXJpYWwnLCdzYW5zLXNlcmlmJzsgRk9OVC1TSVpFOiA4cHQ7IG1zby1iaWRpLWZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWJpZGktZm9udC1zaXplOiAxMS4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48Zm9udCBzdHlsZT0iRk9OVC1TSVpFOiAxMXB4IiBz aXplPSIzIj4NCjwvZm9udD48cCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9Ik1z b05vcm1hbCI+PGZvbnQgc3R5bGU9IkZPTlQtU0laRTogMTFweCIgc2l6ZT0iMyI+PHNwYW4gc3R5 bGU9IkZPTlQtRkFNSUxZOiAnQXJpYWwnLCdzYW5zLXNlcmlmJzsgRk9OVC1TSVpFOiA4cHQ7IG1z by1iaWRpLWZvbnQtc2l6ZTogOC41cHQiPlRoaXMgbWVzc2FnZSBtYXkgY29udGFpbiBpbmZvcm1h dGlvbiB0aGF0IGlzIG5vdCBpbnRlbmRlZCBmb3IgeW91LiBJZiB5b3UgYXJlIG5vdCB0aGUgYWRk cmVzc2VlIG9yIGlmIHRoaXMgbWVzc2FnZSB3YXMgc2VudCB0byB5b3UgYnkgbWlzdGFrZSwgeW91 IGFyZSByZXF1ZXN0ZWQgdG8gaW5mb3JtIHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGUgbWVzc2Fn ZS4gVE5PIGFjY2VwdHMgbm8gbGlhYmlsaXR5IGZvciB0aGUgY29udGVudCBvZiB0aGlzIGUtbWFp bCwgZm9yIHRoZSBtYW5uZXIgaW4gd2hpY2ggeW91IHVzZSBpdCBhbmQgZm9yIGRhbWFnZSBvZiBh bnkga2luZCByZXN1bHRpbmcgZnJvbSB0aGUgcmlza3MgaW5oZXJlbnQgdG8gdGhlIGVsZWN0cm9u aWMgdHJhbnNtaXNzaW9uIG9mIG1lc3NhZ2VzLjxicj48YnI+PC9zcGFuPjwvZm9udD48L3A+PC9i b2R5Pg0KPC9odG1sPg0K --_000_637ecbf37e7448568264692f5dc3af3etnonl_-- From nobody Thu Mar 1 08:28:27 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 D930B12EB1B for ; Thu, 1 Mar 2018 08:28:24 -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 v3vsfRvyxzBd for ; Thu, 1 Mar 2018 08:28:22 -0800 (PST) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::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 423E912EB19 for ; Thu, 1 Mar 2018 08:28:22 -0800 (PST) Received: by mail-it0-x230.google.com with SMTP id n7so8250113ita.5 for ; Thu, 01 Mar 2018 08:28: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=BeqUZ357YRIfGXChwJU1WhGqDefmxl7jFvzjkTHyDII=; b=SttTZjj753LrtMDi4wRwvhRZMEzOcgNDhxNUZD8UAzgmzzMYiy80lQ9TUOKm8WB6X1 BO72L5i0EV42Ri/gSeEuoZrnOCXDfy7WsrbDU09F41WDR3PhcjMg6rDZjkgzH9bMWwOI CYpjaLOv0OQxwy3eIGkfM2rMjBpSBNnnNCuvkNY7hxJRxaMAnnjxnhYSRBtIq1M12vk1 tlh9yNKoCgS3JnnOkglGtvn8xYhRu+DhFRp7bSnGl3K0JCaFFqOuxdwkqBEShbiJvXbb CwTrI4Dw3h3rtV2vn50XCB7jJo2d2pN2k8d78nCfGzms6JC9h7qFU+P6Is3cqEQIT46B xV6g== 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=BeqUZ357YRIfGXChwJU1WhGqDefmxl7jFvzjkTHyDII=; b=lK+ijI2lMo3lrPWIONbxv/t29ZNzJbzPpBDvuZX8GXfae4bRav5x70NX8xFgUW7BSl Tuv/qMzFAe5Rom1qBnL/Sw4fcwZ2gCglyZM+VEmRZjC4cYozRQ/+04ro80zHHsOrtB/H P1S7kp6MXNc952aFSt56JasbGb9Y/VMd5hPgbChO/IkA9EP39VxNesuZ43mXJZltka+Q z5j6cuaf5W7iBsn4KcofRFtrbO2KNi7u9oVC8rYhM0iRiXz33pWcLSV5UbmAkqoCBEBd FWVdNUCQ/j15ka/euepl/KfB83Tz/ueoZkJzagfgKc4QOSJRf1oaqzBV2Z0RCJcFTtUZ NaDw== X-Gm-Message-State: APf1xPCQwTxiSFzGOIsbXVXxef0XOgJC1clHhgXKzAEvaQfX5Inam6Lc NucLRibjZCz1+NRVqu4tZ9sbIVCIomPzmqgEwn8= X-Google-Smtp-Source: AG47ELsrYiOHwNOemNUvpYtzVx/qTfT55UKBGxZ9alwkSLTVSXf8YrWYbgPGnvClSGDWNizzaR62kniKlSWNy/5bI+U= X-Received: by 10.36.200.3 with SMTP id w3mr3145225itf.12.1519921701405; Thu, 01 Mar 2018 08:28:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.28.81 with HTTP; Thu, 1 Mar 2018 08:28:20 -0800 (PST) In-Reply-To: <5a98213d.d138c80a.ababc.519f@mx.google.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> <00f801d3af1d$f20ce4c0$d626ae40$@gmail.com> <002b01d3af21$6e779a70$4b66cf50$@eurecom.fr> <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> <5ccad588-bcd8-d179-165b-7936a34220fb@gmail.com> <5a98213d.d138c80a.ababc.519f@mx.google.com> From: Dorothy Stanley Date: Thu, 1 Mar 2018 08:28:20 -0800 Message-ID: To: William Whyte Cc: Alexandre Petrescu , "its@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c05fdc81949c205665c5932" 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: Thu, 01 Mar 2018 16:28:25 -0000 --94eb2c05fdc81949c205665c5932 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Data frames are allowed, see IEEE Std 802.11-2016, clause 11.21, list item c: When dot11OCBActivated is true in a STA: The STA may send Data frames of subtype Data, Null, QoS Data, and QoS Null ---------------------- Dorothy Stanley Hewlett Packard Enterprise dorothy.stanley@hpe.com dstanley1389@gmail.com +1 630-363-1389 <630-363-1389> On Thu, Mar 1, 2018 at 7:50 AM, William Whyte wrote: > >> (there are some packet dumps with IP packets transported with .11 Data > > headers in OCB mode at 5.9GHz, e.g. attached). > > > > My understanding is OCB mode requires QoSData, so those packets aren=E2= =80=99t > conformant to the standard. > > > > Cheers, > > > > William > > > > Sent from Mail for > Windows 10 > > > > *From: *Alexandre Petrescu > *Sent: *Thursday, March 1, 2018 10:48 AM > *To: *its@ietf.org > *Subject: *Re: [ipwave] 802.11 Data vs 802.11 QoS Data in > IPv6-over-802.11-OCB -implementations > > > > In a private discussion, this question came up: > > > > Is there a packet dump showing an IP packet transported with .11 QoSData > > headers in OCB mode at 5.9GHz. > > > > (there are some packet dumps with IP packets transported with .11 Data > > headers in OCB mode at 5.9GHz, e.g. attached). > > > > Alex > > > > Le 01/03/2018 =C3=A0 15:32, Alexandre Petrescu a =C3=A9crit : > > > I received some feedback from programmer. > > > > > > Le 28/02/2018 =C3=A0 23:48, Abdussalam Baryun a =C3=A9crit : > > > [...] > > >> 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, > > > > > > Here is the QoS problem for IP over 802.11 OCB in implementations. > > > > > > In short, in open source on linux, we dont know how to send IP packets > > > transported as 802.11 QoSData, all IP packets are transported as 802.11 > > > Data instead. > > > > > > - if you ping -Q at 5.9GHz in OCB mode, the DSCP fields do get > > > set properly in IP headers of Echorequest, but there is no .11 QoSDa= ta > > > headers in packets. Normally, one expects the QoSData headers to be > > > present there when the DSCP (an IP field) is set. > > > > > > - if you want to modify kernel, and force always to use QoSData headers > > > on WiFi, including OCB at 5.9GHz, there is a net/mac80211/tx.c file > > > with a flag called wme_sta that you could set to true. But take car= e > > > that the C comments there say that it's not normal to use QoSData > > > headers in OCB mode, because a terminal sending QoSData has no > > > guarantee that receivers also use QoSData (the negotiation of QoS > > > capabilities are absent in OCB). > > > > > > As you can see, this can be long to try and fix. > > > > > > Until then I will propose to set QoS aside from IP-over-OCB at this tim= e. > > > > > > 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 > > --94eb2c05fdc81949c205665c5932 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Data frames are allowed, see IEEE Std 802.11-201= 6, clause 11.21, list item c:

When dot11OCBActivated is true in a STA:=20
<snip>
The STA may send Data frames of subtype Data, Null, QoS Data, = and QoS Null=20
<snip>


On Thu, Mar 1, 2018 at 7:50 AM, William Whyt= e <wwhyte@onboardsecurity.com> wrote:

>> (there are some packet dumps with IP packets transport= ed with .11 Data

headers in OCB mo= de at 5.9GHz, e.g. attached).

=C2=A0

My understanding is OCB mo= de requires QoSData, so those packets aren=E2=80=99t conformant to the stan= dard.

=C2=A0

Cheers,

=C2=A0

William

=C2=A0

Sent from Mail for Windows 10

=C2=A0

From: Alexandre Petrescu
Sent: Thursday, Ma= rch 1, 2018 10:48 AM
To: its@ietf.org
Subject: Re: [ipwave] 802.11 Data vs= 802.11 QoS Data in IPv6-over-802.11-OCB -implementations

=C2=A0

In a private discussion, this question came up:

=C2=A0

Is there a packet d= ump showing an IP packet transported with .11 QoSData

headers in OCB mode at 5.9GHz.

=C2= =A0

(there are some packet dumps with IP p= ackets transported with .11 Data

headers in OCB = mode at 5.9GHz, e.g. attached).

=C2=A0<= /u>

Alex

=C2=A0<= u>

Le 01/03/2018 =C3=A0 15:32, Alexandre Petr= escu a =C3=A9crit=C2=A0:

> I received some fee= dback from programmer.

>

> Le 28/02/2018 =C3=A0 23:48, Abdussalam Baryun a =C3=A9crit=C2=A0= :

> [...]

>> i= eee802.11ocb protocol is already implemented/tested and it is

>> interoperable, but what is the problem, sorry maybe= I did not follow

>> the discussion well,<= /p>

>

> Here is the = QoS problem for IP over 802.11 OCB in implementations.

>

> In short, in open source on linu= x, we dont know how to send IP packets

> tran= sported as 802.11 QoSData, all IP packets are transported as 802.11

> Data instead.

>

<= p class=3D"MsoNormal">> - if you ping -Q at 5.9GHz in OCB mode, the DSCP= fields do get

>=C2=A0 =C2=A0 set properly in = IP headers of Echorequest, but there is no .11 QoSData

>=C2=A0 =C2=A0 headers in packets.=C2=A0 Normally, one expects the= QoSData headers to be

>=C2=A0 =C2=A0 present = there when the DSCP (an IP field) is set.

>

> - if you want to modify kernel, and force alw= ays to use QoSData headers

>=C2=A0 =C2=A0 on W= iFi, including OCB at 5.9GHz, there is a net/mac80211/tx.c file

>=C2=A0 =C2=A0 with a flag called wme_sta that you could = set to true.=C2=A0 But take care

>=C2=A0 =C2= =A0 that the C comments there say that it's not normal to use QoSData

>=C2=A0 =C2=A0 headers in OCB mode, because a t= erminal sending QoSData has no

>=C2=A0 =C2=A0 = guarantee that receivers also use QoSData (the negotiation of QoS

>=C2=A0 =C2=A0 capabilities are absent in OCB).

>

> As you can see, thi= s can be long to try and fix.

>

> Until then I will propose to set QoS aside from IP-over= -OCB at this time.

>

> Alex

>

> = _______________________________________________

> its mailing list

> its@ietf.org

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

=C2=A0


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


--94eb2c05fdc81949c205665c5932-- From nobody Thu Mar 1 08:28: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 1733312EB1B for ; Thu, 1 Mar 2018 08:28:48 -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 WybxCYKPUvNm for ; Thu, 1 Mar 2018 08:28: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 CEF0412EB1D for ; Thu, 1 Mar 2018 08:28: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 w21GSdIe045314; Thu, 1 Mar 2018 17:28:39 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 439FD206281; Thu, 1 Mar 2018 17:28:39 +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 334A4205F23; Thu, 1 Mar 2018 17:28:39 +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 w21GScpO008349; Thu, 1 Mar 2018 17:28:39 +0100 To: dickroy@alum.mit.edu, "'William Whyte'" , its@ietf.org References: <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> <5ccad588-bcd8-d179-165b-7936a34220fb@gmail.com> <5a98213d.d138c80a.ababc.519f! @mx.googl e.com> From: Alexandre Petrescu Message-ID: Date: Thu, 1 Mar 2018 17:28: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: Content-Type: text/plain; charset=windows-1252; 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: Thu, 01 Mar 2018 16:28:48 -0000 Le 01/03/2018 17:22, Dick Roy a crit: > Actually I believe the QoSData restriction is in J2945/1 having only to > do with operation in the US in 5.9GHz. Data and QoSData are permitted > according to 802.11 (and 1609.x). This is not to say I believe this > discussion is relevant to the task of the ITS group, but :^))) Dick, it is very relevant. The current text in the IP-over-OCB draft says that "OCB mode requires transmission of QoS data frames". I cant remember why we wrote it so. Do you think we should modify this text? OLD: > 802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB > attribute dot11OCBActivited is true. The OCB mode requires > transmission of QoS data frames (IEEE Std 802.11e), half-clocked > operation (IEEE Std 802.11j), and use of 5.9 GHz frequency band. > Nota: any implementation should comply with standards and regulations > set in the different countries for using that frequency band. Alex > > Cheers, > > RR > > ------------------------------------------------------------------------ > > *From:*its [mailto:its-bounces@ietf.org] *On Behalf Of *William Whyte > *Sent:* Thursday, March 1, 2018 7:50 AM > *To:* Alexandre Petrescu; its@ietf.org > *Subject:* Re: [ipwave] 802.11 Data vs 802.11 QoS Data in > IPv6-over-802.11-OCB -implementations > >>> (there are some packet dumps with IP packets transported with .11 Data > > headers in OCB mode at 5.9GHz, e.g. attached). > > My understanding is OCB mode requires QoSData, so those packets arent > conformant to the standard. > > Cheers, > > William > > Sent from Mail for > Windows 10 > > *From: *Alexandre Petrescu > *Sent: *Thursday, March 1, 2018 10:48 AM > *To: *its@ietf.org > *Subject: *Re: [ipwave] 802.11 Data vs 802.11 QoS Data in > IPv6-over-802.11-OCB -implementations > > In a private discussion, this question came up: > > Is there a packet dump showing an IP packet transported with .11 QoSData > > headers in OCB mode at 5.9GHz. > > (there are some packet dumps with IP packets transported with .11 Data > > headers in OCB mode at 5.9GHz, e.g. attached). > > Alex > > Le 01/03/2018 15:32, Alexandre Petrescu a crit: > >> I received some feedback from programmer. > >> > >> Le 28/02/2018 23:48, Abdussalam Baryun a crit: > >> [...] > >>> 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, > >> > >> Here is the QoS problem for IP over 802.11 OCB in implementations. > >> > >> In short, in open source on linux, we dont know how to send IP packets > >> transported as 802.11 QoSData, all IP packets are transported as 802.11 > >> Data instead. > >> > >> - if you ping -Q at 5.9GHz in OCB mode, the DSCP fields do get > >> set properly in IP headers of Echorequest, but there is no .11 QoSData > >> headers in packets. Normally, one expects the QoSData headers to be > >> present there when the DSCP (an IP field) is set. > >> > >> - if you want to modify kernel, and force always to use QoSData headers > >> on WiFi, including OCB at 5.9GHz, there is a net/mac80211/tx.c file > >> with a flag called wme_sta that you could set to true. But take care > >> that the C comments there say that it's not normal to use QoSData > >> headers in OCB mode, because a terminal sending QoSData has no > >> guarantee that receivers also use QoSData (the negotiation of QoS > >> capabilities are absent in OCB). > >> > >> As you can see, this can be long to try and fix. > >> > >> Until then I will propose to set QoS aside from IP-over-OCB at this time. > >> > >> Alex > >> > >> _______________________________________________ > >> its mailing list > >> its@ietf.org > >> https://www.ietf.org/mailman/listinfo/its > From nobody Thu Mar 1 08:29:27 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 BDB9212EB1B for ; Thu, 1 Mar 2018 08:29:25 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=onboardsecurity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdguzFkITX0z for ; Thu, 1 Mar 2018 08:29:23 -0800 (PST) Received: from mail-pl0-x241.google.com (mail-pl0-x241.google.com [IPv6:2607:f8b0:400e:c01::241]) (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 3542112EB19 for ; Thu, 1 Mar 2018 08:29:23 -0800 (PST) Received: by mail-pl0-x241.google.com with SMTP id v9-v6so3914036plp.12 for ; Thu, 01 Mar 2018 08:29:23 -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=vSMdYp5nB+QtlvedN3ezKAfdZ700NohtH1Et99w+lNE=; b=a0HHKpFwEZVuxxnOUdynLDAPoxx0GrIRBPDoXv/nbnFYaTPkoxeVdZCgwnuM0OpOIE 7q7mFaMhleE3h6va+OGyfhy6URrO6CO5aRbm1Omm/o2ufDzheuBRtPHt/JJU6gXD7r9H ZEO8v9v4gPsZeZeSLb6k7eI40OA2IeNarhQLA= 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=vSMdYp5nB+QtlvedN3ezKAfdZ700NohtH1Et99w+lNE=; b=hlMnJ7+pykZSKaQhRjSW7aiIyx27qpjPULAkX12SKpS05gu/Y44yW87zQdjnUBZjgN fs7KPMOJnzCyI5k3HLDSXRvrUS2MDt2xpq836DC8P+qN4CEQakAatq4qzZcwHPrdSysO oz2jscfqjfx5aozN7N8/2CDyPz6Q3oBTVgdYho2zs8G2/QPbpGA2INi9CaUNthGvQQuH eU8gdxn7/lyvy5bZ4bdVQEHE/kbsvcKBZOE/PibuiqDag1Xu+Kz7oLT855kuTledcX99 C2TKqJr6GyQm/nMZ6IyuLAdD5twKHUwyac5t3gOLHCdhbodfAoX6sPgIXORW7wrafYnm 41xw== X-Gm-Message-State: APf1xPBMQVF+n4lx24JABFClcqayYg+q+PDbXmFcRSi8cnGpWCFjOOLM xA7/lARQPs8T0nVOVOUzWHgiXXrY0mFCR2gdNx6qdw== X-Google-Smtp-Source: AG47ELs1aCpZmX2lrSyvS3Chs1nPqFJQaXDT5EFryj2v9OwmKZu7EfggO49ZTs5UT8IirZDIWjhCzYQ8428PoLhIE/U= X-Received: by 2002:a17:902:4581:: with SMTP id n1-v6mr2495912pld.135.1519921762494; Thu, 01 Mar 2018 08:29:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.186.163 with HTTP; Thu, 1 Mar 2018 08:29:01 -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> <5ccad588-bcd8-d179-165b-7936a34220fb@gmail.com> <5a98213d.d138c80a.ababc.519f@mx.google.com> From: William Whyte Date: Thu, 1 Mar 2018 11:29:01 -0500 Message-ID: To: Dick Roy Cc: Alexandre Petrescu , "its@ietf.org" Content-Type: multipart/alternative; boundary="000000000000bd83b305665c5ce6" 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: Thu, 01 Mar 2018 16:29:26 -0000 --000000000000bd83b305665c5ce6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If that's the case, I don't have an issue with the draft allowing Data and QoSData, though I'd note that the definition of OCB in the Terminology section of the draft states that QoSData is required and should be changed if it's wrong. On the question of implementations: I don't have pcaps to hand, but the USDOT RSU spec, available from https://transportationops.org/publications/dedicated-short-range-communicat= ions-roadside-unit-specifications, requires QoSData, and OmniAir has been testing conformance to that spec, so it's safe to assume that it's been implemented. Cheers, William On Thu, Mar 1, 2018 at 11:22 AM, Dick Roy wrote: > Actually I believe the QoSData restriction is in J2945/1 having only to d= o > with operation in the US in 5.9GHz. Data and QoSData are permitted > according to 802.11 (and 1609.x). This is not to say I believe this > discussion is relevant to the task of the ITS group, but =E2=80=A6 :^))) > > > > Cheers, > > > > RR > ------------------------------ > > *From:* its [mailto:its-bounces@ietf.org] *On Behalf Of *William Whyte > *Sent:* Thursday, March 1, 2018 7:50 AM > *To:* Alexandre Petrescu; its@ietf.org > > *Subject:* Re: [ipwave] 802.11 Data vs 802.11 QoS Data in > IPv6-over-802.11-OCB -implementations > > > > >> (there are some packet dumps with IP packets transported with .11 Data > > headers in OCB mode at 5.9GHz, e.g. attached). > > > > My understanding is OCB mode requires QoSData, so those packets aren=E2= =80=99t > conformant to the standard. > > > > Cheers, > > > > William > > > > Sent from Mail for > Windows 10 > > > > *From: *Alexandre Petrescu > *Sent: *Thursday, March 1, 2018 10:48 AM > *To: *its@ietf.org > *Subject: *Re: [ipwave] 802.11 Data vs 802.11 QoS Data in > IPv6-over-802.11-OCB -implementations > > > > In a private discussion, this question came up: > > > > Is there a packet dump showing an IP packet transported with .11 QoSData > > headers in OCB mode at 5.9GHz. > > > > (there are some packet dumps with IP packets transported with .11 Data > > headers in OCB mode at 5.9GHz, e.g. attached). > > > > Alex > > > > Le 01/03/2018 =C3=A0 15:32, Alexandre Petrescu a =C3=A9crit : > > > I received some feedback from programmer. > > > > > > Le 28/02/2018 =C3=A0 23:48, Abdussalam Baryun a =C3=A9crit : > > > [...] > > >> 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, > > > > > > Here is the QoS problem for IP over 802.11 OCB in implementations. > > > > > > In short, in open source on linux, we dont know how to send IP packets > > > transported as 802.11 QoSData, all IP packets are transported as 802.11 > > > Data instead. > > > > > > - if you ping -Q at 5.9GHz in OCB mode, the DSCP fields do get > > > set properly in IP headers of Echorequest, but there is no .11 QoSDa= ta > > > headers in packets. Normally, one expects the QoSData headers to be > > > present there when the DSCP (an IP field) is set. > > > > > > - if you want to modify kernel, and force always to use QoSData headers > > > on WiFi, including OCB at 5.9GHz, there is a net/mac80211/tx.c file > > > with a flag called wme_sta that you could set to true. But take car= e > > > that the C comments there say that it's not normal to use QoSData > > > headers in OCB mode, because a terminal sending QoSData has no > > > guarantee that receivers also use QoSData (the negotiation of QoS > > > capabilities are absent in OCB). > > > > > > As you can see, this can be long to try and fix. > > > > > > Until then I will propose to set QoS aside from IP-over-OCB at this tim= e. > > > > > > Alex > > > > > > _______________________________________________ > > > its mailing list > > > its@ietf.org > > > https://www.ietf.org/mailman/listinfo/its > > > --=20 PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS: wwhyte@onboardsecurity.com --000000000000bd83b305665c5ce6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If that's the case, I don't have an issue with the= draft allowing Data and QoSData, though I'd note that the definition o= f OCB in the Terminology section of the draft states that QoSData is requir= ed and should be changed if it's wrong.

On the quest= ion of implementations: I don't have pcaps to hand, but the USDOT RSU s= pec, available from https://t= ransportationops.org/publications/dedicated-short-range-communications-road= side-unit-specifications, requires QoSData, and OmniAir has been testin= g conformance to that spec, so it's safe to assume that it's been i= mplemented.

Cheers,

W= illiam

On Thu, Mar 1, 2018 at 11:22 AM, Dick Roy <dickroy@alum.mit.edu>= ; wrote:

Actually I believe= the QoSData restriction is in J2945/1 having only to do with operation in the US in 5.9GHz.=C2=A0 Data and QoSData are permitted according to 802.11 (and 1609.x).=C2=A0 This is n= ot to say I believe this discussion is relevant to the task of the ITS group, but =E2= =80=A6 :^)))

=C2=A0

Cheers,<= /u>

=C2=A0

RR

From: its [mailto:its-bounc= es@ietf.org] On Behalf Of William Whyte
Sent: Thursday, March 1, 201= 8 7:50 AM
To: Alexandre Petrescu; its@ietf.org


Subject: Re: [ipwave] 802.11= Data vs 802.11 QoS Data in IPv6-over-802.11-OCB -implementations

<= /p>

=C2=A0

>> (there are some packet dumps with IP packets transported with .11 Data <= /u>

headers in OCB mode at 5.9GHz, e.g. attached).

=C2=A0

My understanding is OCB mode requires QoSData, so those packets aren=E2=80=99t= conformant to the standard.

=C2=A0

Cheers,

=C2=A0

William

=C2=A0

Sent from Mail for Windows 10

=C2=A0

From: Alexandre Petrescu Sent: Thursday, March 1, 201= 8 10:48 AM
To: its@ietf.org
Subject: Re: [ipwave] 802.11= Data vs 802.11 QoS Data in IPv6-over-802.11-OCB -implementations

=C2=A0

In a private discussion, this question came up:

=C2=A0

Is there a packet dump showing an IP packet transported with .11 QoSData

headers in OCB mode at 5.9GHz.

=C2=A0

(there are some packet dumps with IP packets transported with .11 Data <= /u>

headers in OCB mode at 5.9GHz, e.g. attached).

=C2=A0

Alex

=C2=A0

Le 01/03/2018 =C3=A0 15:32, Alexandre Petrescu a =C3=A9crit=C2=A0:

> I received some feedback from programmer.

>

> Le 28/02/2018 =C3=A0 23:48, Abdussalam Baryun a =C3=A9crit=C2=A0:=

> [...]

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

>

> Here is the QoS problem for IP over 802.11 OCB in implementations.

>

> In short, in open source on linux, we dont know how to send IP packets <= /u>

> transported as 802.11 QoSData, all IP packets are transported as 802.11 =

> Data instead.

>

> - if you ping -Q at 5.9GHz in OCB mode, the DSCP fields do get

>=C2=A0 =C2=A0 set properly in IP headers of Echorequest, but there is no .11 QoSDa= ta

>=C2=A0 =C2=A0 headers in packets.=C2=A0 Normally, one expects the QoSData headers = to be

>=C2=A0 =C2=A0 present there when the DSCP (an IP field) is set.

>

> - if you want to modify kernel, and force always to use QoSData headers<= /u>

>=C2=A0 =C2=A0 on WiFi, including OCB at 5.9GHz, there is a net/mac80211/tx.c file<= u>

>=C2=A0 =C2=A0 with a flag called wme_sta that you could set to true.=C2=A0 But tak= e care

>=C2=A0 =C2=A0 that the C comments there say that it's not normal to use QoSDat= a

>=C2=A0 =C2=A0 headers in OCB mode, because a terminal sending QoSData has no

>=C2=A0 =C2=A0 guarantee that receivers also use QoSData (the negotiation of QoS=

>=C2=A0 =C2=A0 capabilities are absent in OCB).

>

> As you can see, this can be long to try and fix.

>

> Until then I will propose to set QoS aside from IP-over-OCB at this time.

>

> Alex

>

> _______________________________________________

> its mailing list

> its@ietf.org

> htt= ps://www.ietf.org/mailman/listinfo/its=

=C2=A0




--


PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW AD= DRESS: wwhy= te@onboardsecurity.com
--000000000000bd83b305665c5ce6-- From nobody Thu Mar 1 08:32: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 D0BBC12EB15 for ; Thu, 1 Mar 2018 08:32:20 -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 psV4Dm2GtjI0 for ; Thu, 1 Mar 2018 08:32:19 -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 2501512EB08 for ; Thu, 1 Mar 2018 08:32:18 -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 w21GWE5J007442; Thu, 1 Mar 2018 17:32:14 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7C59620629A; Thu, 1 Mar 2018 17:32:14 +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 6AFDF206264; Thu, 1 Mar 2018 17:32:14 +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 w21GWDS2011890; Thu, 1 Mar 2018 17:32:14 +0100 To: William Whyte , Dick Roy Cc: "its@ietf.org" References: <007901d3aee3$a9985ba0$fcc912e0$@eurecom.fr> <00f801d3af1d$f20ce4c0$d626ae40$@gmail.com> <002b01d3af21$6e779a70$4b66cf50$@eurecom.fr> <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> <5ccad588-bcd8-d179-165b-7936a34220fb@gmail.com> <5a98213d.d138c80a.ababc.519f@mx.google.com> From: Alexandre Petrescu Message-ID: Date: Thu, 1 Mar 2018 17:32: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 -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: Thu, 01 Mar 2018 16:32:21 -0000 William, Le 01/03/2018 à 17:29, William Whyte a écrit : > If that's the case, I don't have an issue with the draft allowing Data > and QoSData, though I'd note that the definition of OCB in the > Terminology section of the draft states that QoSData is required and > should be changed if it's wrong. I agree. > On the question of implementations: I don't have pcaps to hand, but the > USDOT RSU spec, available from > https://transportationops.org/publications/dedicated-short-range-communications-roadside-unit-specifications, > requires QoSData, and OmniAir has been testing conformance to that spec, > so it's safe to assume that it's been implemented. Thanks for the pointer. I hope their RSU uses IPv6 on the air (not on the Ethernet plug). Can this be confirmed. Alex > > Cheers, > > William > > On Thu, Mar 1, 2018 at 11:22 AM, Dick Roy > wrote: > > __ __ > > Actually I believe the QoSData restriction is in J2945/1 having only > to do with operation in the ____US____ in 5.9GHz.  Data and QoSData > are permitted according to 802.11 (and 1609.x).  This is not to say > I believe this discussion is relevant to the task of the ITS group, > but … :^)))____ > > __ __ > > Cheers,____ > > __ __ > > RR____ > > ------------------------------------------------------------------------ > > *From:*its [mailto:its-bounces@ietf.org > ] *On Behalf Of *William Whyte > *Sent:* Thursday, March 1, 2018 7:50 AM > *To:* Alexandre Petrescu; its@ietf.org > > > *Subject:* Re: [ipwave] 802.11 Data vs 802.11 QoS Data in > IPv6-over-802.11-OCB -implementations > ____ > > __ __ > > >> (there are some packet dumps with IP packets transported with .11 > Data ____ > > headers in OCB mode at 5.9GHz, e.g. attached).____ > > __ __ > > My understanding is OCB mode requires QoSData, so those packets > aren’t conformant to the standard.____ > > __ __ > > Cheers,____ > > __ __ > > William____ > > __ __ > > Sent from Mail for > Windows 10____ > > __ __ > > *From: *Alexandre Petrescu > *Sent: *Thursday, March 1, 2018 10:48 AM > *To: *its@ietf.org > *Subject: *Re: [ipwave] 802.11 Data vs 802.11 QoS Data in > IPv6-over-802.11-OCB -implementations____ > > __ __ > > In a private discussion, this question came up:____ > > __ __ > > Is there a packet dump showing an IP packet transported with .11 > QoSData ____ > > headers in OCB mode at 5.9GHz.____ > > __ __ > > (there are some packet dumps with IP packets transported with .11 > Data ____ > > headers in OCB mode at 5.9GHz, e.g. attached).____ > > __ __ > > Alex____ > > __ __ > > Le 01/03/2018 à 15:32, Alexandre Petrescu a écrit :____ > > > I received some feedback from programmer.____ > > > ____ > > > Le 28/02/2018 à 23:48, Abdussalam Baryun a écrit :____ > > > [...]____ > > >> 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,____ > > > ____ > > > Here is the QoS problem for IP over 802.11 OCB in implementations.____ > > > ____ > > > In short, in open source on linux, we dont know how to send IP > packets ____ > > > transported as 802.11 QoSData, all IP packets are transported as > 802.11 ____ > > > Data instead.____ > > > ____ > > > - if you ping -Q at 5.9GHz in OCB mode, the DSCP fields do get____ > > >   set properly in IP headers of Echorequest, but there is no .11 > QoSData____ > > >   headers in packets.  Normally, one expects the QoSData headers to > be____ > > >   present there when the DSCP (an IP field) is set.____ > > > ____ > > > - if you want to modify kernel, and force always to use QoSData > headers____ > > >   on WiFi, including OCB at 5.9GHz, there is a net/mac80211/tx.c > file____ > > >   with a flag called wme_sta that you could set to true.  But take > care____ > > >   that the C comments there say that it's not normal to use QoSData____ > > >   headers in OCB mode, because a terminal sending QoSData has no____ > > >   guarantee that receivers also use QoSData (the negotiation of QoS____ > > >   capabilities are absent in OCB).____ > > > ____ > > > As you can see, this can be long to try and fix.____ > > > ____ > > > Until then I will propose to set QoS aside from IP-over-OCB at > this time.____ > > > ____ > > > Alex____ > > > ____ > > > ___________________________________________________ > > > 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 Thu Mar 1 08:38: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 6E0FE12E8E7 for ; Thu, 1 Mar 2018 08:38:10 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=onboardsecurity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8_yc5_C_08b2 for ; Thu, 1 Mar 2018 08:38:07 -0800 (PST) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::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 2C45B12EB25 for ; Thu, 1 Mar 2018 08:38:03 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id n12so8295891qtl.5 for ; Thu, 01 Mar 2018 08:38:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onboardsecurity.com; s=google; h=message-id:mime-version:to:cc:from:subject:date:importance :in-reply-to:references; bh=YXdplarSgC+XAEULUQxnIHqe+j5BT34hBtOokt4JP/4=; b=YaOyv0XiD3M8qlx+aQAMQ/VAj/YMXNz3bB/iCqtvJXgyRSNDYQodfbDqk4IIU7yeFa oXSTBtiZPz1IaySXXy3hK4UdMP67CJ2CWBtw+iAzRB54tV+pg1TqetFmzmv6hAURmFHv Vy0F6aluEwISKfoFPLOUvuQu4CBseMbFnKRH8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:mime-version:to:cc:from:subject:date :importance:in-reply-to:references; bh=YXdplarSgC+XAEULUQxnIHqe+j5BT34hBtOokt4JP/4=; b=RV3YiQ3hSktinx7jusolrP84dTO6Ul2N/9SbXDsSEqwZUGISii1/afERDgldr8Ydoo +GFu07+R2CR9/IDQ3kSicJKKgveZJkJgOyTmiPNb3exlmso/aEL9QftzSlX/gF6YeGw3 Lg4vzCSE5NHkUpCeSsRbAz33Hzc9NiUptqadduRDUg0Fi7xUmHBF5+aw0IFiGMUsvDJF X/LsRRY/8H5Yu/Ooy2/auLRMrLfuxUlwbEUfBSmm626GBvvKV0IBLksuBE2vnU864cRv cuGJt+pO/w6THgsMk2nsh07oNnrFgOekVKmO2xnRqcpd4PSujdnG3cDjnLzkfU8ntuNK nL9A== X-Gm-Message-State: AElRT7HdhaPv3QIQ0ZBTRoZ9nT27FNnmE7xlb5AH386brwa5AcR7qpkZ 4bkYuqoreIRielFllUQarDuj+w== X-Google-Smtp-Source: AG47ELut3X+EJYGIDXXNuvkgbZwyAJBjcH/Fdw0A+9ywNlv4i5UBRW2Klzqvi2UhVmruxgd3bm5Ojg== X-Received: by 10.200.51.13 with SMTP id t13mr3735897qta.263.1519922282070; Thu, 01 Mar 2018 08:38:02 -0800 (PST) Received: from ?IPv6:::ffff:192.168.0.141? ([207.251.68.132]) by smtp.gmail.com with ESMTPSA id z5sm2842562qka.31.2018.03.01.08.38.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Mar 2018 08:38:00 -0800 (PST) Message-ID: <5a982c68.054c370a.a23eb.3a09@mx.google.com> MIME-Version: 1.0 To: Alexandre Petrescu , Dick Roy Cc: "its@ietf.org" From: William Whyte Date: Thu, 1 Mar 2018 11:38:00 -0500 Importance: normal X-Priority: 3 In-Reply-To: References: <007901d3aee3$a9985ba0$fcc912e0$@eurecom.fr> <00f801d3af1d$f20ce4c0$d626ae40$@gmail.com> <002b01d3af21$6e779a70$4b66cf50$@eurecom.fr> <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> <5ccad588-bcd8-d179-165b-7936a34220fb@gmail.com> <5a98213d.d138c80a.ababc.519f@mx.google.com> Content-Type: multipart/alternative; boundary="_90F3F644-0099-46EE-AC00-25FDF8C188C4_" 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: Thu, 01 Mar 2018 16:38:10 -0000 --_90F3F644-0099-46EE-AC00-25FDF8C188C4_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hi Alex, > I hope their RSU uses IPv6 on the air (not on the Ethernet plug). Can=20 > this be confirmed. Section 2.2 of the RSU spec says: IPv6 Access The RSU provides DSRC-equipped mobile devices with access to Back Office se= rvices by way of IPv6. =E2=80=A6 and (as you=E2=80=99d expect) there are references to providing I= Pv6 service throughout the document. Cheers, William Sent from Mail for Windows 10 From: Alexandre Petrescu Sent: Thursday, March 1, 2018 11:32 AM To: William Whyte; Dick Roy Cc: its@ietf.org Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OC= B-implementations William, Le 01/03/2018 =C3=A0 17:29, William Whyte a =C3=A9crit=C2=A0: > If that's the case, I don't have an issue with the draft allowing Data=20 > and QoSData, though I'd note that the definition of OCB in the=20 > Terminology section of the draft states that QoSData is required and=20 > should be changed if it's wrong. I agree. > On the question of implementations: I don't have pcaps to hand, but the=20 > USDOT RSU spec, available from=20 > https://transportationops.org/publications/dedicated-short-range-communic= ations-roadside-unit-specifications,=20 > requires QoSData, and OmniAir has been testing conformance to that spec,= =20 > so it's safe to assume that it's been implemented. Thanks for the pointer. I hope their RSU uses IPv6 on the air (not on the Ethernet plug). Can=20 this be confirmed. Alex >=20 > Cheers, >=20 > William >=20 > On Thu, Mar 1, 2018 at 11:22 AM, Dick Roy > wrote: >=20 > __ __ >=20 > Actually I believe the QoSData restriction is in J2945/1 having only > to do with operation in the ____US____ in 5.9GHz.=C2=A0 Data and QoSD= ata > are permitted according to 802.11 (and 1609.x).=C2=A0 This is not to = say > I believe this discussion is relevant to the task of the ITS group, > but =E2=80=A6 :^)))____ >=20 > __ __ >=20 > Cheers,____ >=20 > __ __ >=20 > RR____ >=20 > ---------------------------------------------------------------------= --- >=20 > *From:*its [mailto:its-bounces@ietf.org > ] *On Behalf Of *William Whyte > *Sent:* Thursday, March 1, 2018 7:50 AM > *To:* Alexandre Petrescu; its@ietf.org >=20 >=20 > *Subject:* Re: [ipwave] 802.11 Data vs 802.11 QoS Data in > IPv6-over-802.11-OCB -implementations > ____ >=20 > __ __ >=20 > >> (there are some packet dumps with IP packets transported with .11 > Data ____ >=20 > headers in OCB mode at 5.9GHz, e.g. attached).____ >=20 > __ __ >=20 > My understanding is OCB mode requires QoSData, so those packets > aren=E2=80=99t conformant to the standard.____ >=20 > __ __ >=20 > Cheers,____ >=20 > __ __ >=20 > William____ >=20 > __ __ >=20 > Sent from Mail for > Windows 10____ >=20 > __ __ >=20 > *From: *Alexandre Petrescu > *Sent: *Thursday, March 1, 2018 10:48 AM > *To: *its@ietf.org > *Subject: *Re: [ipwave] 802.11 Data vs 802.11 QoS Data in > IPv6-over-802.11-OCB -implementations____ >=20 > __ __ >=20 > In a private discussion, this question came up:____ >=20 > __ __ >=20 > Is there a packet dump showing an IP packet transported with .11 > QoSData ____ >=20 > headers in OCB mode at 5.9GHz.____ >=20 > __ __ >=20 > (there are some packet dumps with IP packets transported with .11 > Data ____ >=20 > headers in OCB mode at 5.9GHz, e.g. attached).____ >=20 > __ __ >=20 > Alex____ >=20 > __ __ >=20 > Le 01/03/2018 =C3=A0 15:32, Alexandre Petrescu a =C3=A9crit=C2=A0:___= _ >=20 > > I received some feedback from programmer.____ >=20 > > ____ >=20 > > Le 28/02/2018 =C3=A0 23:48, Abdussalam Baryun a =C3=A9crit=C2=A0:_= ___ >=20 > > [...]____ >=20 > >> ieee802.11ocb protocol is already implemented/tested and it is __= __ >=20 > >> interoperable, but what is the problem, sorry maybe I did not > follow ____ >=20 > >> the discussion well,____ >=20 > > ____ >=20 > > Here is the QoS problem for IP over 802.11 OCB in implementations.= ____ >=20 > > ____ >=20 > > In short, in open source on linux, we dont know how to send IP > packets ____ >=20 > > transported as 802.11 QoSData, all IP packets are transported as > 802.11 ____ >=20 > > Data instead.____ >=20 > > ____ >=20 > > - if you ping -Q at 5.9GHz in OCB mode, the DSCP fields do get____ >=20 > > =C2=A0 set properly in IP headers of Echorequest, but there is no = .11 > QoSData____ >=20 > > =C2=A0 headers in packets.=C2=A0 Normally, one expects the QoSData= headers to > be____ >=20 > > =C2=A0 present there when the DSCP (an IP field) is set.____ >=20 > > ____ >=20 > > - if you want to modify kernel, and force always to use QoSData > headers____ >=20 > > =C2=A0 on WiFi, including OCB at 5.9GHz, there is a net/mac80211/t= x.c > file____ >=20 > > =C2=A0 with a flag called wme_sta that you could set to true.=C2= =A0 But take > care____ >=20 > > =C2=A0 that the C comments there say that it's not normal to use Q= oSData____ >=20 > > =C2=A0 headers in OCB mode, because a terminal sending QoSData has= no____ >=20 > > =C2=A0 guarantee that receivers also use QoSData (the negotiation = of QoS____ >=20 > > =C2=A0 capabilities are absent in OCB).____ >=20 > > ____ >=20 > > As you can see, this can be long to try and fix.____ >=20 > > ____ >=20 > > Until then I will propose to set QoS aside from IP-over-OCB at > this time.____ >=20 > > ____ >=20 > > Alex____ >=20 > > ____ >=20 > > ___________________________________________________ >=20 > > its mailing list____ >=20 > > its@ietf.org ____ >=20 > > https://www.ietf.org/mailman/listinfo/its > ____ >=20 > __ __ >=20 >=20 >=20 >=20 > --=20 >=20 >=20 > PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS:=20 > wwhyte@onboardsecurity.com --_90F3F644-0099-46EE-AC00-25FDF8C188C4_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

Hi Alex,

 

> I hope their RSU uses IPv6 on t= he air (not on the Ethernet plug).=C2=A0 Can

> this be confirmed.

 = ;

Section 2.2 of the RSU spec says:

 

IPv6 Acces= s

The RSU provides DSRC-equipped mobile devices with acces= s to Back Office services by way of IPv6.

&nbs= p;

=E2=80=A6 and (as you=E2=80=99d expect) th= ere are references to providing IPv6 service throughout the document.

 

Cheers,

 

William

 

Sent from Mail for Windows= 10

 

From: = Alexandre Petrescu<= br>Sent: Thursday, March 1, 2018 11:32 AM
To: William Whyte; Dick Roy
Cc: its@ietf.org
Subject: Re: [ipwave] 802.11 Data vs 802.11 Qo= S Data in IPv6-over-802.11-OCB-implementations

 

William,

 

Le 01/03/2018 =C3=A0 17:29, Wil= liam Whyte a =C3=A9crit :

> If that's the c= ase, I don't have an issue with the draft allowing Data

> and QoSData, though I'd note that the definition of OCB in the <= /p>

> Terminology section of the draft states that Q= oSData is required and

> should be changed if i= t's wrong.

 

I agree.

 

> On the question of implementations: I don't have pcaps to hand, but = the

> USDOT RSU spec, available from

> https://transportationops.org/publications/dedicated-sh= ort-range-communications-roadside-unit-specifications,

> requires QoSData, and OmniAir has been testing conformance to tha= t spec,

> so it's safe to assume that it's been= implemented.

 

Thanks for the pointer.

 

<= p class=3DMsoNormal>I hope their RSU uses IPv6 on the air (not on the Ether= net plug).=C2=A0 Can

this be confirmed.

 

Alex

 

>

> Cheers,

>

&= gt; William

>

> On T= hu, Mar 1, 2018 at 11:22 AM, Dick Roy <dickroy@alum.mit.edu

> <mailto:dickroy@alum.mit.edu>> wrote:

>

>=C2=A0=C2=A0=C2=A0=C2=A0 __= __

>

>=C2=A0=C2=A0= =C2=A0=C2=A0 Actually I believe the QoSData restriction is in J2945/1 havin= g only

>=C2=A0=C2=A0=C2=A0=C2=A0 to do with oper= ation in the ____US____ in 5.9GHz.  Data and QoSData

>=C2=A0=C2=A0=C2=A0=C2=A0 are permitted according to 802.11 (and = 1609.x).  This is not to say

>=C2=A0=C2=A0= =C2=A0=C2=A0 I believe this discussion is relevant to the task of the ITS g= roup,

>=C2=A0=C2=A0=C2=A0=C2=A0 but =E2=80=A6 :^= )))____

>

>=C2=A0=C2= =A0=C2=A0=C2=A0 __ __

>

>=C2=A0=C2=A0=C2=A0=C2=A0 Cheers,____

>

=

>=C2=A0=C2=A0=C2=A0=C2=A0 __ __

>

>=C2=A0=C2=A0=C2=A0=C2=A0 RR____

<= p class=3DMsoNormal>>

>=C2=A0=C2=A0=C2=A0=C2= =A0 -----------------------------------------------------------------------= -

>

>=C2=A0=C2=A0=C2= =A0=C2=A0 *From:*its [mailto:its-bounces@ietf.org

&= gt;=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:its-bounces@ietf.org>] *On Behalf= Of *William Whyte

>=C2=A0=C2=A0=C2=A0=C2=A0 *Se= nt:* Thursday, March 1, 2018 7:50 AM

>=C2=A0=C2= =A0=C2=A0=C2=A0 *To:* Alexandre Petrescu; its@ietf.org <mailto:its@ietf.= org>

>

>

>=C2=A0=C2=A0=C2=A0=C2=A0 *Subject:* Re: [ipwave] 802.1= 1 Data vs 802.11 QoS Data in

> =C2=A0=C2=A0=C2= =A0=C2=A0IPv6-over-802.11-OCB -implementations

>= =C2=A0=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 a= re some packet dumps with IP packets transported with .11

>=C2=A0=C2=A0=C2=A0=C2=A0 Data ____

> =

>=C2=A0=C2=A0=C2=A0=C2=A0 headers in OCB mode a= t 5.9GHz, e.g. attached).____

>

>=C2=A0=C2=A0=C2=A0=C2=A0 __ __

>

>=C2=A0=C2=A0=C2=A0=C2=A0 My understanding is OCB= mode requires QoSData, so those packets

>=C2=A0= =C2=A0=C2=A0=C2=A0 aren=E2=80=99t conformant to the standard.____

>

>=C2=A0=C2=A0=C2=A0=C2=A0 _= _ __

>

>=C2=A0=C2=A0= =C2=A0=C2=A0 Cheers,____

>

>=C2=A0=C2=A0=C2=A0=C2=A0 __ __

>

>=C2=A0=C2=A0=C2=A0=C2=A0 William____

>

>=C2=A0=C2=A0=C2=A0=C2=A0 __ __

>

>=C2=A0=C2=A0=C2=A0= =C2=A0 Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=3D550986&= gt; for

>=C2=A0=C2=A0=C2=A0=C2=A0 Windows 10____=

>

>=C2=A0=C2=A0=C2= =A0=C2=A0 __ __

>

>= =C2=A0=C2=A0=C2=A0=C2=A0 *From: *Alexandre Petrescu <mailto:alexandre.pe= trescu@gmail.com>

>=C2=A0=C2=A0=C2=A0=C2=A0 *= Sent: *Thursday, March 1, 2018 10:48 AM

>=C2=A0= =C2=A0=C2=A0=C2=A0 *To: *its@ietf.org <mailto:its@ietf.org>

>=C2=A0=C2=A0=C2=A0=C2=A0 *Subject: *Re: [ipwave] 802.11 = Data vs 802.11 QoS Data in

>=C2=A0=C2=A0=C2=A0= =C2=A0 IPv6-over-802.11-OCB -implementations____

&g= t;

>=C2=A0=C2=A0=C2=A0=C2=A0 __ __

>

>=C2=A0=C2=A0=C2=A0=C2=A0 In = a private discussion, this question came up:____

&g= t;

>=C2=A0=C2=A0=C2=A0=C2=A0 __ __

>

>=C2=A0=C2=A0=C2=A0=C2=A0 Is = there a packet dump showing an IP packet transported with .11

>=C2=A0=C2=A0=C2=A0=C2=A0 QoSData ____

>

>=C2=A0=C2=A0=C2=A0=C2=A0 headers in O= CB mode at 5.9GHz.____

>

>=C2=A0=C2=A0=C2=A0=C2=A0 __ __

>

>=C2=A0=C2=A0=C2=A0=C2=A0 (there are some packet dumps w= ith IP packets transported with .11

>=C2=A0=C2= =A0=C2=A0=C2=A0 Data ____

>

>=C2=A0=C2=A0=C2=A0=C2=A0 headers in OCB mode at 5.9GHz, e.g. attac= hed).____

>

>=C2=A0 = =C2=A0=C2=A0=C2=A0__ __

>

>=C2=A0=C2=A0=C2=A0=C2=A0 Alex____

>

<= p class=3DMsoNormal>>=C2=A0=C2=A0=C2=A0=C2=A0 __ __

>

>=C2=A0=C2=A0=C2=A0=C2=A0 Le 01/03/201= 8 =C3=A0 15:32, Alexandre Petrescu a =C3=A9crit :____

>

>=C2=A0=C2=A0=C2=A0=C2=A0 >=C2= =A0 I received some feedback from programmer.____

&= gt;

>=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 23:48, Abdussalam Baryun a =C3=A9cri= t :____

>

>=C2= =A0=C2=A0=C2=A0=C2=A0 >=C2=A0 [...]____

>

>=C2=A0=C2=A0=C2=A0=C2=A0 >>=C2=A0 ieee802.1= 1ocb protocol is already implemented/tested and it is ____

>

>=C2=A0=C2=A0=C2=A0=C2=A0 >>= =C2=A0 interoperable, but what is the problem, sorry maybe I did not

>=C2=A0=C2=A0=C2=A0=C2=A0 follow ____

>

>=C2=A0=C2=A0=C2=A0=C2=A0 >>= =C2=A0 the discussion well,____

>

>=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 ____

>

>=C2=A0=C2=A0=C2=A0 =C2=A0>=C2= =A0 Here is the QoS problem for IP over 802.11 OCB in implementations.____<= /p>

>

>=C2=A0=C2=A0=C2= =A0=C2=A0 >=C2=A0 ____

>

>=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 In short, in open source on li= nux, we dont know how to send IP

>=C2=A0=C2=A0= =C2=A0=C2=A0 packets ____

>

>=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 transported as 802.11 QoSData,= all IP packets are transported as

>=C2=A0=C2=A0= =C2=A0=C2=A0 802.11 ____

>

>=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 Data instead.____

>

>=C2=A0=C2=A0=C2=A0=C2=A0 >= ;=C2=A0 ____

>

>=C2= =A0=C2=A0=C2=A0=C2=A0 >=C2=A0 - if you ping -Q at 5.9GHz in OCB mode, th= e DSCP fields do get____

>

>=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0   set properly in IP heade= rs of Echorequest, but there is no .11

>=C2=A0= =C2=A0=C2=A0=C2=A0 QoSData____

>

>=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0   headers in packets= .  Normally, one expects the QoSData headers to

>=C2=A0=C2=A0=C2=A0=C2=A0 be____

>

>=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0   present the= re when the DSCP (an IP field) is set.____

>

>=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 ____

>

>=C2=A0=C2=A0=C2=A0=C2=A0 = >=C2=A0 - if you want to modify kernel, and force always to use QoSData<= /p>

>=C2=A0=C2=A0=C2=A0 =C2=A0headers____

>

>=C2=A0=C2=A0=C2=A0=C2=A0 &g= t;=C2=A0   on WiFi, including OCB at 5.9GHz, there is a net/mac80211/t= x.c

>=C2=A0=C2=A0=C2=A0=C2=A0 file____

>

>=C2=A0=C2=A0=C2=A0=C2=A0 &= gt;=C2=A0   with a flag called wme_sta that you could set to true.&nbs= p; But take

>=C2=A0=C2=A0=C2=A0=C2=A0 care____

>

>=C2=A0=C2=A0=C2=A0= =C2=A0 >=C2=A0   that the C comments there say that it's not normal= to use QoSData____

>

&= gt;=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0   headers in OCB mode, because = a terminal sending QoSData has no____

>

>=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0   guarantee t= hat receivers also use QoSData (the negotiation of QoS____

>

>=C2=A0=C2=A0=C2=A0=C2=A0 >=C2= =A0   capabilities are absent in OCB).____

>= ;

>=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 ____

=

>

>=C2=A0=C2=A0=C2=A0= =C2=A0 >=C2=A0 As you can see, this can be long to try and fix.____

<= p class=3DMsoNormal>>

>=C2=A0=C2=A0=C2=A0=C2= =A0 >=C2=A0 ____

>

&= gt;=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 Until then I will propose to set QoS= aside from IP-over-OCB at

>=C2=A0=C2=A0=C2=A0= =C2=A0 this time.____

>

>=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 ____

> =

>=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 Alex____

>

>=C2=A0=C2=A0=C2=A0= =C2=A0 >=C2=A0 ____

>

>=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 _________________________________= __________________

>

&g= t;=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 its mailing list____

>

>=C2=A0=C2=A0=C2=A0=C2=A0 >=C2= =A0 its@ietf.org <mailto:its@ietf.org>____

&g= t;

>=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 <https://www.ietf.org/mailman/listinfo/its>____

>

>=C2=A0=C2=A0=C2=A0=C2=A0 = __ __

>

>

>

>

= > --

>

>

> PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS= :

> wwhyte@onboardsecurity.com <mailto:wwhyt= e@onboardsecurity.com>

 

= --_90F3F644-0099-46EE-AC00-25FDF8C188C4_-- From nobody Thu Mar 1 08:40: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 A77FD12EB08 for ; Thu, 1 Mar 2018 08:40:03 -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 8wHBmOBuyEw1 for ; Thu, 1 Mar 2018 08:40: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 44B0612EB25 for ; Thu, 1 Mar 2018 08:40:01 -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 w21Gdx1W010147 for ; Thu, 1 Mar 2018 17:39:59 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9CE4E20626D for ; Thu, 1 Mar 2018 17:39: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 932F8206203 for ; Thu, 1 Mar 2018 17:39: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 w21GdwgU018660 for ; Thu, 1 Mar 2018 17:39:59 +0100 To: 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> <1eca0280-0931-fa39-5706-cadc22cca17c@gmail.com> From: Alexandre Petrescu Message-ID: <526c8e1d-652b-56e7-c113-1ae52ef720e6@gmail.com> Date: Thu, 1 Mar 2018 17:39: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: <1eca0280-0931-fa39-5706-cadc22cca17c@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 - new text proposal X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 01 Mar 2018 16:40:04 -0000 In the Terminology section, I propose this resolution. OLD: > 802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB > attribute dot11OCBActivited is true. The OCB mode requires > transmission of QoS data frames (IEEE Std 802.11e), half-clocked > operation (IEEE Std 802.11j), and use of 5.9 GHz frequency band. > Nota: any implementation should comply with standards and > regulations set in the different countries for using that frequency > band. NEW: > 802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB > attribute dot11OCBActivited is true. The OCB mode permits the > transmission of 802.11 Data frames, of 802.11 QoS Data frames (IEEE > Std 802.11e), half-clocked operation (IEEE Std 802.11j), and use of > 5.9 GHz frequency band. Nota: any implementation should comply with > standards and regulations set in the different countries for using > that frequency band. I hope you dont disagree with this proposal. Alex Le 01/03/2018 à 15:48, Alexandre Petrescu a écrit : > Hi, > > I propose this new resolution: say "802.11 headers" instead of "Data > Headers" and of "QoS Data Headers".  Which header to use is left outside > the scope of this document. > > OLD: >> At reception, this layer takes as input the IEEE 802.11 Data Header >> and the Logical-Link Layer Control Header and produces an Ethernet II >> Header. > > NEW: >> At reception, this layer takes as input the IEEE 802.11 header and the >> Logical-Link Layer Control Header and produces an Ethernet II Header. > > OLD: >> 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. > > NEW: >> The Receiver and Transmitter Address fields in the 802.11 header MUST >> contain the same values as the Destination and the Source Address >> fields in the Ethernet II Header, respectively. > > 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. > [...] >>    [I-D.ietf-tsvwg-ieee-802-11], although it is not specific to OCB >>    mode. > > NEW: >> The specification of the 802.11 header used to transmit IP packets is >> outside the scope of this document. > > I hope you dont disagree. > > Alex > > > > Le 28/02/2018 à 08:39, Alexandre Petrescu a écrit : >> 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 >> >> _______________________________________________ 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 Mar 1 08: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 73F1512EB49 for ; Thu, 1 Mar 2018 08:46: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 lQ1Q78BSogZu for ; Thu, 1 Mar 2018 08:46:03 -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 7BC0D12EB3C for ; Thu, 1 Mar 2018 08:46:03 -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 w21GjwaP174140; Thu, 1 Mar 2018 17:45:58 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 212E9201401; Thu, 1 Mar 2018 17:45: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 106F120629D; Thu, 1 Mar 2018 17:45: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 w21Gjv6D023980; Thu, 1 Mar 2018 17:45:57 +0100 To: William Whyte Cc: Dick Roy , "its@ietf.org" References: <00f801d3af1d$f20ce4c0$d626ae40$@gmail.com> <002b01d3af21$6e779a70$4b66cf50$@eurecom.fr> <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> <5ccad588-bcd8-d179-165b-7936a34220fb@gmail.com> <5a98213d.d138c80a.ababc.519f@mx.google.com> <5a982c68.054c370a.a23eb.3a09@mx.google.com> From: Alexandre Petrescu Message-ID: <2bde85e7-d401-8a84-20e4-c9b25192b76d@gmail.com> Date: Thu, 1 Mar 2018 17:45:57 +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: <5a982c68.054c370a.a23eb.3a09@mx.google.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-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: Thu, 01 Mar 2018 16:46:06 -0000 Le 01/03/2018 à 17:38, William Whyte a écrit : > Hi Alex, > > > I hope their RSU uses IPv6 on the air (not on the Ethernet plug).  Can > > > this be confirmed. > > Section 2.2 of the RSU spec says: > > /IPv6 Access/// > > The RSU provides DSRC-equipped mobile devices with access to Back Office > services by way of IPv6. > > … and (as you’d expect) there are references to providing IPv6 service > throughout the document. It's very good to know. The IPv6-over-OCB document allows the use of IPv6 over the air interface of an RSU (even though it calls it an IP-RSU instead :-) Let us hope for the best for the FHWA&ITS "Dedicated Short-Range Communications Roadside Unit Specifications". Alex > > Cheers, > > William > > Sent from Mail for > Windows 10 > > *From: *Alexandre Petrescu > *Sent: *Thursday, March 1, 2018 11:32 AM > *To: *William Whyte ; Dick Roy > > *Cc: *its@ietf.org > *Subject: *Re: [ipwave] 802.11 Data vs 802.11 QoS Data in > IPv6-over-802.11-OCB-implementations > > William, > > Le 01/03/2018 à 17:29, William Whyte a écrit : > > > If that's the case, I don't have an issue with the draft allowing Data > > > and QoSData, though I'd note that the definition of OCB in the > > > Terminology section of the draft states that QoSData is required and > > > should be changed if it's wrong. > > I agree. > > > On the question of implementations: I don't have pcaps to hand, but the > > > USDOT RSU spec, available from > > > > https://transportationops.org/publications/dedicated-short-range-communications-roadside-unit-specifications, > > > > requires QoSData, and OmniAir has been testing conformance to that spec, > > > so it's safe to assume that it's been implemented. > > Thanks for the pointer. > > I hope their RSU uses IPv6 on the air (not on the Ethernet plug).  Can > > this be confirmed. > > Alex > > > > > > Cheers, > > > > > > William > > > > > > On Thu, Mar 1, 2018 at 11:22 AM, Dick Roy > > > wrote: > > > > > >     __ __ > > > > > >     Actually I believe the QoSData restriction is in J2945/1 having only > > >     to do with operation in the ____US____ in 5.9GHz.  Data and QoSData > > >     are permitted according to 802.11 (and 1609.x).  This is not to say > > >     I believe this discussion is relevant to the task of the ITS group, > > >     but … :^)))____ > > > > > >     __ __ > > > > > >     Cheers,____ > > > > > >     __ __ > > > > > >     RR____ > > > > > > > ------------------------------------------------------------------------ > > > > > >     *From:*its [mailto:its-bounces@ietf.org > > >     ] *On Behalf Of *William Whyte > > >     *Sent:* Thursday, March 1, 2018 7:50 AM > > >     *To:* Alexandre Petrescu; its@ietf.org > > > > > > > > >     *Subject:* Re: [ipwave] 802.11 Data vs 802.11 QoS Data in > > >     IPv6-over-802.11-OCB -implementations > > >     ____ > > > > > >     __ __ > > > > > >     >>  (there are some packet dumps with IP packets transported with .11 > > >     Data ____ > > > > > >     headers in OCB mode at 5.9GHz, e.g. attached).____ > > > > > >     __ __ > > > > > >     My understanding is OCB mode requires QoSData, so those packets > > >     aren’t conformant to the standard.____ > > > > > >     __ __ > > > > > >     Cheers,____ > > > > > >     __ __ > > > > > >     William____ > > > > > >     __ __ > > > > > >     Sent from Mail for > > >     Windows 10____ > > > > > >     __ __ > > > > > >     *From: *Alexandre Petrescu > > >     *Sent: *Thursday, March 1, 2018 10:48 AM > > >     *To: *its@ietf.org > > >     *Subject: *Re: [ipwave] 802.11 Data vs 802.11 QoS Data in > > >     IPv6-over-802.11-OCB -implementations____ > > > > > >     __ __ > > > > > >     In a private discussion, this question came up:____ > > > > > >     __ __ > > > > > >     Is there a packet dump showing an IP packet transported with .11 > > >     QoSData ____ > > > > > >     headers in OCB mode at 5.9GHz.____ > > > > > >     __ __ > > > > > >     (there are some packet dumps with IP packets transported with .11 > > >     Data ____ > > > > > >     headers in OCB mode at 5.9GHz, e.g. attached).____ > > > > > >     __ __ > > > > > >     Alex____ > > > > > >     __ __ > > > > > >     Le 01/03/2018 à 15:32, Alexandre Petrescu a écrit :____ > > > > > >     >  I received some feedback from programmer.____ > > > > > >     >  ____ > > > > > >     >  Le 28/02/2018 à 23:48, Abdussalam Baryun a écrit :____ > > > > > >     >  [...]____ > > > > > >     >>  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,____ > > > > > >     >  ____ > > > > > >     >  Here is the QoS problem for IP over 802.11 OCB in > implementations.____ > > > > > >     >  ____ > > > > > >     >  In short, in open source on linux, we dont know how to send IP > > >     packets ____ > > > > > >     >  transported as 802.11 QoSData, all IP packets are transported as > > >     802.11 ____ > > > > > >     >  Data instead.____ > > > > > >     >  ____ > > > > > >     >  - if you ping -Q at 5.9GHz in OCB mode, the DSCP fields do get____ > > > > > >     >    set properly in IP headers of Echorequest, but there is no .11 > > >     QoSData____ > > > > > >     >    headers in packets.  Normally, one expects the QoSData > headers to > > >     be____ > > > > > >     >    present there when the DSCP (an IP field) is set.____ > > > > > >     >  ____ > > > > > >     >  - if you want to modify kernel, and force always to use QoSData > > >     headers____ > > > > > >     >    on WiFi, including OCB at 5.9GHz, there is a net/mac80211/tx.c > > >     file____ > > > > > >     >    with a flag called wme_sta that you could set to true.  But take > > >     care____ > > > > > >     >    that the C comments there say that it's not normal to use > QoSData____ > > > > > >     >    headers in OCB mode, because a terminal sending QoSData has > no____ > > > > > >     >    guarantee that receivers also use QoSData (the negotiation > of QoS____ > > > > > >     >    capabilities are absent in OCB).____ > > > > > >     >  ____ > > > > > >     >  As you can see, this can be long to try and fix.____ > > > > > >     >  ____ > > > > > >     >  Until then I will propose to set QoS aside from IP-over-OCB at > > >     this time.____ > > > > > >     >  ____ > > > > > >     >  Alex____ > > > > > >     >  ____ > > > > > >     >  ___________________________________________________ > > > > > >     >  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 Thu Mar 1 09:05: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 623A312EB70 for ; Thu, 1 Mar 2018 09:05:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, 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 qNtBqO1P0I1K for ; Thu, 1 Mar 2018 09:05:49 -0800 (PST) Received: from smtp2.eurecom.fr (smtp2.eurecom.fr [193.55.113.211]) by ietfa.amsl.com (Postfix) with ESMTP id E31CB12EB6B for ; Thu, 1 Mar 2018 09:05:47 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.47,408,1515452400"; d="scan'208,217";a="7729127" Received: from monza.eurecom.fr ([192.168.106.15]) by drago2i.eurecom.fr with ESMTP; 01 Mar 2018 18:05:43 +0100 Received: from xerus29 (unknown [192.168.200.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by monza.eurecom.fr (Postfix) with ESMTPSA id C5A9A29C1; Thu, 1 Mar 2018 18:05:42 +0100 (CET) From: =?utf-8?B?SsOpcsO0bWUgSMOkcnJp?= To: "'William Whyte'" , "'Dick Roy'" Cc: "'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> <00f801d3af1d$f20ce4c0$d626ae40$@gmail.com> <002b01d3af21$6e779a70$4b66cf50$@eurecom.fr> <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> <5ccad588-bcd8-d179-165b-7936a34220fb@gmail.com> <5a98213d.d138c80a.ababc.519f@mx.googl e.com> In-Reply-To: Date: Thu, 1 Mar 2018 18:05:42 +0100 Organization: EURECOM Message-ID: <006c01d3b17f$88506750$98f135f0$@eurecom.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006D_01D3B187.EA1BFB40" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHelLAw/aN7IRfcwiTBG/gKcgHVEwGONDnFAivYBTcBDgW0eQFK9evKAbex+qQCF4nJkAMphqaUAo/H9voB/QVRSwGgjFsGAtvA4TEBm9hPkAKafOT2Adw4FVkBhOPELQGWvTywAi3roigCMY3M2QGvyPIVAMY4kOMBvqj5jKJnErpA Content-Language: en-us 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: Thu, 01 Mar 2018 17:05:53 -0000 This is a multipart message in MIME format. ------=_NextPart_000_006D_01D3B187.EA1BFB40 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Dear All, =20 With the risk of repeating information already sent in the thread, the = issue has never been if Data or QoSData is allowed for OCB. It is clear = it is.=20 =20 BUT considering that SAE 2945/1 (BSM) and ETSI geonet-media dependent = functionalities, both specify to use QoSData to differentiate = event-based BSM (very urgent) from periodic BMS (normal) / DENM (very = urgent) from CAM (normal) using QoSData with AC_VI (DENM/event-based = BSM) and AC_BE (CAM/periodic BSM), we have a =E2=80=98coexistence = issue=E2=80=99 . =20 Indeed, 802.11 data frame use DCF, which use a DIFS equal to 2 slot + = SIFS. Now, AC_VI (the urgent DENM/BSM) use EDCA AC_VI, also with 2 slot = + SIFS. And CAM/periodic BSM use *6* slot + SIFS. =20 In short, any IP-over-OCB will access the channel before CAM/BSM at best = and generate collisions with ITS-G5 and DSRC. This can be seem as = =E2=80=98harmful=E2=80=99 interferences with an existing system, which = must be avoided.=20 =20 That is the reason I am suggesting to use QoSData for IP-over-OCB, so = that depending on your traffic (e.g. if you transmit CAM-over-IP, or = video feeds) you can tweak the right AC_ and not interfere with = DSRC/ITS-G5..much. That would avoid a lot of issues=E2=80=A6and it does = not cost much (ok some extra bits, but come on=E2=80=A6we are not doing = ROLL here, so is it that dramatic?=20 =20 Even though not the task of IETF, it is important to make sure that any = specification will not interfere with an existing system. So, = Alex=E2=80=99s suggestion to remove any explicit mention to QoSData or = Data is probably a good trade-off, and leave it open to profiling as = function of in which channel IP-over-OCB would be used (i.e if = interference is expected or not)=E2=80=A6 =20 BR, =20 J=C3=A9r=C3=B4me =20 =20 From: its [mailto:its-bounces@ietf.org] On Behalf Of William Whyte Sent: Thursday 01 March 2018 17:29 To: Dick Roy Cc: Alexandre Petrescu; its@ietf.org Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in = IPv6-over-802.11-OCB -implementations =20 If that's the case, I don't have an issue with the draft allowing Data = and QoSData, though I'd note that the definition of OCB in the = Terminology section of the draft states that QoSData is required and = should be changed if it's wrong. =20 On the question of implementations: I don't have pcaps to hand, but the = USDOT RSU spec, available from = https://transportationops.org/publications/dedicated-short-range-communic= ations-roadside-unit-specifications, requires QoSData, and OmniAir has = been testing conformance to that spec, so it's safe to assume that it's = been implemented. =20 Cheers, =20 William =20 On Thu, Mar 1, 2018 at 11:22 AM, Dick Roy wrote: Actually I believe the QoSData restriction is in J2945/1 having only to = do with operation in the US in 5.9GHz. Data and QoSData are permitted = according to 802.11 (and 1609.x). This is not to say I believe this = discussion is relevant to the task of the ITS group, but =E2=80=A6 :^))) =20 Cheers, =20 RR _____ =20 From: its [mailto:its-bounces@ietf.org] On Behalf Of William Whyte Sent: Thursday, March 1, 2018 7:50 AM To: Alexandre Petrescu; its@ietf.org Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in = IPv6-over-802.11-OCB -implementations =20 >> (there are some packet dumps with IP packets transported with .11 = Data=20 headers in OCB mode at 5.9GHz, e.g. attached). =20 My understanding is OCB mode requires QoSData, so those packets = aren=E2=80=99t conformant to the standard. =20 Cheers, =20 William =20 Sent from Mail for = Windows 10 =20 From: Alexandre Petrescu =20 Sent: Thursday, March 1, 2018 10:48 AM To: its@ietf.org Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in = IPv6-over-802.11-OCB -implementations =20 In a private discussion, this question came up: =20 Is there a packet dump showing an IP packet transported with .11 QoSData = headers in OCB mode at 5.9GHz. =20 (there are some packet dumps with IP packets transported with .11 Data=20 headers in OCB mode at 5.9GHz, e.g. attached). =20 Alex =20 Le 01/03/2018 =C3=A0 15:32, Alexandre Petrescu a =C3=A9crit : > I received some feedback from programmer. >=20 > Le 28/02/2018 =C3=A0 23:48, Abdussalam Baryun a =C3=A9crit : > [...] >> ieee802.11ocb protocol is already implemented/tested and it is=20 >> interoperable, but what is the problem, sorry maybe I did not follow=20 >> the discussion well, >=20 > Here is the QoS problem for IP over 802.11 OCB in implementations. >=20 > In short, in open source on linux, we dont know how to send IP packets = > transported as 802.11 QoSData, all IP packets are transported as = 802.11=20 > Data instead. >=20 > - if you ping -Q at 5.9GHz in OCB mode, the DSCP fields do get > set properly in IP headers of Echorequest, but there is no .11 = QoSData > headers in packets. Normally, one expects the QoSData headers to = be > present there when the DSCP (an IP field) is set. >=20 > - if you want to modify kernel, and force always to use QoSData = headers > on WiFi, including OCB at 5.9GHz, there is a net/mac80211/tx.c file > with a flag called wme_sta that you could set to true. But take = care > that the C comments there say that it's not normal to use QoSData > headers in OCB mode, because a terminal sending QoSData has no > guarantee that receivers also use QoSData (the negotiation of QoS > capabilities are absent in OCB). >=20 > As you can see, this can be long to try and fix. >=20 > Until then I will propose to set QoS aside from IP-over-OCB at this = time. >=20 > Alex >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its =20 =20 --=20 =20 =20 PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS: = wwhyte@onboardsecurity.com ------=_NextPart_000_006D_01D3B187.EA1BFB40 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Dear All,

 

With the risk of repeating information already sent in the thread, = the issue has never been if Data or QoSData is allowed for OCB. It is = clear it is.

 

BUT considering that SAE 2945/1 (BSM) and ETSI geonet-media dependent = functionalities, both specify to use QoSData to differentiate = event-based BSM (very urgent) from periodic BMS (normal) / DENM (very = urgent) from CAM (normal) using QoSData with AC_VI (DENM/event-based = BSM) and AC_BE (CAM/periodic BSM), we have a =E2=80=98coexistence = issue=E2=80=99 .

 

Indeed, 802.11 data frame use DCF, which use a DIFS equal to 2 slot + = SIFS. Now, AC_VI (the urgent DENM/BSM) use EDCA AC_VI, also with 2 slot = + SIFS. And CAM/periodic BSM use *6* slot + = SIFS.

 

In short, any IP-over-OCB will access the channel before CAM/BSM at = best and generate collisions with ITS-G5 and DSRC. This can be seem as = =E2=80=98harmful=E2=80=99 interferences with an existing system, which = must be avoided.

 

That is the reason I am suggesting to use QoSData for IP-over-OCB, so = that depending on your traffic (e.g. if you transmit CAM-over-IP, or = video feeds) you can tweak the right AC_ and not interfere with = DSRC/ITS-G5..much. That would avoid a lot of issues=E2=80=A6and it does = not cost much (ok some extra bits, but come on=E2=80=A6we are not doing = ROLL here, so is it that dramatic?

 

Even though not the task of IETF, it is important to make sure that = any specification will not interfere with an existing system. So, = Alex=E2=80=99s suggestion to remove any explicit mention to QoSData or = Data is probably a good trade-off, and leave it open to profiling as = function of in which channel IP-over-OCB would be used (i.e if = interference is expected or not)=E2=80=A6

 

BR,

 

J=C3=A9r=C3=B4me

 

 

From:= = its [mailto:its-bounces@ietf.org] On Behalf Of William = Whyte
Sent: Thursday 01 March 2018 17:29
To: Dick = Roy
Cc: Alexandre Petrescu; its@ietf.org
Subject: = Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB = -implementations

 

If = that's the case, I don't have an issue with the draft allowing Data and = QoSData, though I'd note that the definition of OCB in the Terminology = section of the draft states that QoSData is required and should be = changed if it's wrong.

 

On the question of implementations: I don't have pcaps = to hand, but the USDOT RSU spec, available from https://transportationops.or= g/publications/dedicated-short-range-communications-roadside-unit-specifi= cations, requires QoSData, and OmniAir has been testing conformance = to that spec, so it's safe to assume that it's been = implemented.

 

Cheers,

 

William

 

On Thu, = Mar 1, 2018 at 11:22 AM, Dick Roy <dickroy@alum.mit.edu> = wrote:

Ac= tually I believe the QoSData restriction is in J2945/1 having only to do = with operation in the US in 5.9GHz.  Data and QoSData are permitted = according to 802.11 (and 1609.x).  This is not to say I believe = this discussion is relevant to the task of the ITS group, but =E2=80=A6 = :^)))

&n= bsp;

Ch= eers,

&n= bsp;

RR=

From:= = its [mailto:its-bounces@ietf.org] On Behalf Of William = Whyte
Sent: Thursday, March 1, 2018 7:50 AM
To: = Alexandre Petrescu; its@ietf.org


Subje= ct: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in = IPv6-over-802.11-OCB = -implementations

 

>> = (there are some packet dumps with IP packets transported with .11 Data =

headers in = OCB mode at 5.9GHz, e.g. attached).

 

My = understanding is OCB mode requires QoSData, so those packets = aren=E2=80=99t conformant to the standard.

 

Cheers,

 

William

 

Sent from = Mail for Windows 10

 

From: = Alexandre Petrescu
Sent: Thursday, March = 1, 2018 10:48 AM
To: its@ietf.org
Subject: Re: [ipwave] = 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB = -implementations

 

In a = private discussion, this question came up:

 

Is there a = packet dump showing an IP packet transported with .11 QoSData =

headers in = OCB mode at 5.9GHz.

 

(there are = some packet dumps with IP packets transported with .11 Data =

headers in = OCB mode at 5.9GHz, e.g. attached).

 

Alex=

 

Le = 01/03/2018 =C3=A0 15:32, Alexandre Petrescu a = =C3=A9crit :

> I = received some feedback from programmer.

> =

> Le = 28/02/2018 =C3=A0 23:48, Abdussalam Baryun a = =C3=A9crit :

> = [...]

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

> =

> Here = is the QoS problem for IP over 802.11 OCB in = implementations.

> =

> In = short, in open source on linux, we dont know how to send IP packets =

> = transported as 802.11 QoSData, all IP packets are transported as 802.11 =

> Data = instead.

> =

> - if = you ping -Q at 5.9GHz in OCB mode, the DSCP fields do = get

>  =   set properly in IP headers of Echorequest, but there is no .11 = QoSData

>  =   headers in packets.  Normally, one expects the QoSData = headers to be

>  =   present there when the DSCP (an IP field) is = set.

> =

> - if = you want to modify kernel, and force always to use QoSData = headers

>  =   on WiFi, including OCB at 5.9GHz, there is a net/mac80211/tx.c = file

>  =   with a flag called wme_sta that you could set to true.  But = take care

>  =   that the C comments there say that it's not normal to use = QoSData

>  =   headers in OCB mode, because a terminal sending QoSData has = no

>  =   guarantee that receivers also use QoSData (the negotiation of = QoS

>  =   capabilities are absent in OCB).

> =

> As = you can see, this can be long to try and fix.

> =

> Until = then I will propose to set QoS aside from IP-over-OCB at this = time.

> =

> = Alex

> =

> = _______________________________________________

> 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

------=_NextPart_000_006D_01D3B187.EA1BFB40-- From nobody Thu Mar 1 09:08: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 4836912EB83 for ; Thu, 1 Mar 2018 09:08:44 -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 GkZ0FjBqho3A for ; Thu, 1 Mar 2018 09:08:38 -0800 (PST) Received: from smtp2.eurecom.fr (smtp2.eurecom.fr [193.55.113.211]) by ietfa.amsl.com (Postfix) with ESMTP id A315B12EB8F for ; Thu, 1 Mar 2018 09:08:37 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.47,408,1515452400"; d="scan'208";a="7729130" Received: from monza.eurecom.fr ([192.168.106.15]) by drago2i.eurecom.fr with ESMTP; 01 Mar 2018 18:08:36 +0100 Received: from xerus29 (unknown [192.168.200.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by monza.eurecom.fr (Postfix) with ESMTPSA id 8D45129DF; Thu, 1 Mar 2018 18:08:36 +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> <9ada5591-2af3-272d-3bc3-031bf35454c3@gmail.com> <1eca0280-0931-fa39-5706-cadc22cca17c@gmail.com> <526c8e1d-652b-56e7-c113-1ae52ef720e6@gmail.com> In-Reply-To: <526c8e1d-652b-56e7-c113-1ae52ef720e6@gmail.com> Date: Thu, 1 Mar 2018 18:08:36 +0100 Organization: EURECOM Message-ID: <007f01d3b17f$efd51b00$cf7f5100$@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/gKcgHVEwGONDnFAivYBTcB5QRVgwFu9SHuAcUCuOgBh4H86QDW1OMrAMcTuCUBjmWUcaM5n6bw Content-Language: en-us Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB - new text proposal X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 01 Mar 2018 17:08:44 -0000 Agreed..indeed, that was wrong :-) BR, J=C3=A9r=C3=B4me -----Original Message----- From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu Sent: Thursday 01 March 2018 17:40 To: its@ietf.org Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in = IPv6-over-802.11-OCB - new text proposal In the Terminology section, I propose this resolution. OLD: > 802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB=20 > attribute dot11OCBActivited is true. The OCB mode requires=20 > transmission of QoS data frames (IEEE Std 802.11e), half-clocked=20 > operation (IEEE Std 802.11j), and use of 5.9 GHz frequency band. > Nota: any implementation should comply with standards and regulations=20 > set in the different countries for using that frequency band. NEW: > 802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB=20 > attribute dot11OCBActivited is true. The OCB mode permits the=20 > transmission of 802.11 Data frames, of 802.11 QoS Data frames (IEEE=20 > Std 802.11e), half-clocked operation (IEEE Std 802.11j), and use of > 5.9 GHz frequency band. Nota: any implementation should comply with=20 > standards and regulations set in the different countries for using=20 > that frequency band. I hope you dont disagree with this proposal. Alex Le 01/03/2018 =C3=A0 15:48, Alexandre Petrescu a =C3=A9crit : > Hi, >=20 > I propose this new resolution: say "802.11 headers" instead of "Data=20 > Headers" and of "QoS Data Headers". Which header to use is left=20 > outside the scope of this document. >=20 > OLD: >> At reception, this layer takes as input the IEEE 802.11 Data Header=20 >> and the Logical-Link Layer Control Header and produces an Ethernet II = >> Header. >=20 > NEW: >> At reception, this layer takes as input the IEEE 802.11 header and=20 >> the Logical-Link Layer Control Header and produces an Ethernet II = Header. >=20 > OLD: >> The Receiver and Transmitter Address fields in the 802.11 Data Header = >> MUST contain the same values as the Destination and the Source=20 >> Address fields in the Ethernet II Header, respectively. >=20 > NEW: >> The Receiver and Transmitter Address fields in the 802.11 header MUST = >> contain the same values as the Destination and the Source Address=20 >> fields in the Ethernet II Header, respectively. >=20 > OLD: >> In OCB mode, IPv6 packets MAY be transmitted either as "IEEE=20 >> 802.11 >> Data" or alternatively as "IEEE 802.11 QoS Data", as illustrated=20 >> in >> Figure 2. > [...] >> [I-D.ietf-tsvwg-ieee-802-11], although it is not specific to OCB >> mode. >=20 > NEW: >> The specification of the 802.11 header used to transmit IP packets is = >> outside the scope of this document. >=20 > I hope you dont disagree. >=20 > Alex >=20 >=20 >=20 > Le 28/02/2018 =C3=A0 08:39, Alexandre Petrescu a =C3=A9crit : >> 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=20 >> Control Field and TID 0001 and UP=3D=3D1"). >> >> Until then, I ponder over removal altogher of the section Ethernet=20 >> Adaptation Layer from this draft, and move these QoS aspects in=20 >> another document. Maybe Carlos questioning of this EAL was right in=20 >> the end. >> >> Alex >> >> Le 28/02/2018 =C3=A0 03:29, John Kenney a =C3=A9crit : >>> 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=20 >>>> (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=20 >>> > = >>> 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=20 >>>> 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|=20 >>> = +--------------------+-------------+-------------+---------+-----------+ >>> >>> >>> > or >>> >>> = +--------------------+-------------+-------------+---------+-----------+ >>> >>> >> >>> > | 802.11 QoS Data Hdr| LLC Header | IPv6 Header | Payload |.11 >>> Trailer|=20 >>> = +--------------------+-------------+-------------+---------+-----------+ >>> >>> >>> > 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=20 >>> 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.=20 >>> "Traffic Class", "Flow label") and fields in the "802.11 QoS Data=20 >>> Header" (e.g. "QoS Control") are not specified in this document. >>> Guidance for a potential mapping is provided in=20 >>> [I-D.ietf-tsvwg-ieee-802-11], although it is not specific to OCB=20 >>> 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=20 >>> Field is 0). >>> >>> >>> Alex >>> >>> >>> _______________________________________________ its mailing list=20 >>> its@ietf.org =20 >>> https://www.ietf.org/mailman/listinfo/its >>> >>> >>> >>> >>> >>> -- John Kenney Director and Principal Researcher Toyota=20 >>> InfoTechnology Center, USA 465 Bernardo Avenue Mountain View, CA >>> 94043 Tel: 650-694-4160. Mobile: 650-224-6644 >> >> _______________________________________________ its mailing list=20 >> its@ietf.org https://www.ietf.org/mailman/listinfo/its >=20 > _______________________________________________ > 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 Mar 1 09:16: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 86B5112EB9A for ; Thu, 1 Mar 2018 09:16:48 -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 2umXtm_S9Qoc for ; Thu, 1 Mar 2018 09:16:46 -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 4C20912EB8E for ; Thu, 1 Mar 2018 09:16:36 -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 w21HGVRl010533; Thu, 1 Mar 2018 18:16:31 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 1C861206278; Thu, 1 Mar 2018 18:16: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 11C582061D3; Thu, 1 Mar 2018 18:16: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 w21HGUTn019326; Thu, 1 Mar 2018 18:16:30 +0100 To: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , "'William Whyte'" , "'Dick Roy'" Cc: its@ietf.org References: <007901d3aee3$a9985ba0$fcc912e0$@eurecom.fr> <00f801d3af1d$f20ce4c0$d626ae40$@gmail.com> <002b01d3af21$6e779a70$4b66cf50$@eurecom.fr> <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> <5ccad588-bcd8-d179-165b-7936a34220fb@gmail.com> <5a98213d.d138c80a.ababc.519f! @mx.googl e.com> <006c01d3b17f$88506750$98f135f0$@eurecom.fr> From: Alexandre Petrescu Message-ID: Date: Thu, 1 Mar 2018 18:16: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: <006c01d3b17f$88506750$98f135f0$@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 -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: Thu, 01 Mar 2018 17:16:48 -0000 Jérôme, Thank you for the explanation. Le 01/03/2018 à 18:05, Jérôme Härri a écrit : [...] > That is the reason I am suggesting to use QoSData for IP-over-OCB, so > that depending on your traffic (e.g. if you transmit CAM-over-IP, or > video feeds) you can tweak the right AC_ and not interfere with > DSRC/ITS-G5..much. That would avoid a lot of issues…and it does not cost > much (ok some extra bits, but come on…we are not doing ROLL here, so is > it that dramatic? I agree with you. Can one maybe write a separate draft for this. I think implementation can be written. I think the existing draft IP-over-OCB with the recent tweaks allows for such a draft. I may ask you: what do you think could be a title of QoSData IP/OCB be? Alex > > Even though not the task of IETF, it is important to make sure that any > specification will not interfere with an existing system. So, Alex’s > suggestion to remove any explicit mention to QoSData or Data is probably > a good trade-off, and leave it open to profiling as function of in which > channel IP-over-OCB would be used (i.e if interference is expected or not)… > > BR, > > Jérôme > > *From:*its [mailto:its-bounces@ietf.org] *On Behalf Of *William Whyte > *Sent:* Thursday 01 March 2018 17:29 > *To:* Dick Roy > *Cc:* Alexandre Petrescu; its@ietf.org > *Subject:* Re: [ipwave] 802.11 Data vs 802.11 QoS Data in > IPv6-over-802.11-OCB -implementations > > If that's the case, I don't have an issue with the draft allowing Data > and QoSData, though I'd note that the definition of OCB in the > Terminology section of the draft states that QoSData is required and > should be changed if it's wrong. > > On the question of implementations: I don't have pcaps to hand, but the > USDOT RSU spec, available from > https://transportationops.org/publications/dedicated-short-range-communications-roadside-unit-specifications, > requires QoSData, and OmniAir has been testing conformance to that spec, > so it's safe to assume that it's been implemented. > > Cheers, > > William > > On Thu, Mar 1, 2018 at 11:22 AM, Dick Roy > wrote: > > Actually I believe the QoSData restriction is in J2945/1 having only to > do with operation in the US in 5.9GHz.  Data and QoSData are permitted > according to 802.11 (and 1609.x).  This is not to say I believe this > discussion is relevant to the task of the ITS group, but … :^))) > > Cheers, > > RR > > ------------------------------------------------------------------------ > > *From:*its [mailto:its-bounces@ietf.org ] > *On Behalf Of *William Whyte > *Sent:* Thursday, March 1, 2018 7:50 AM > *To:* Alexandre Petrescu; its@ietf.org > > > *Subject:* Re: [ipwave] 802.11 Data vs 802.11 QoS Data in > IPv6-over-802.11-OCB -implementations > >>> (there are some packet dumps with IP packets transported with .11 Data > > headers in OCB mode at 5.9GHz, e.g. attached). > > My understanding is OCB mode requires QoSData, so those packets aren’t > conformant to the standard. > > Cheers, > > William > > Sent from Mail for > Windows 10 > > *From: *Alexandre Petrescu > *Sent: *Thursday, March 1, 2018 10:48 AM > *To: *its@ietf.org > *Subject: *Re: [ipwave] 802.11 Data vs 802.11 QoS Data in > IPv6-over-802.11-OCB -implementations > > In a private discussion, this question came up: > > Is there a packet dump showing an IP packet transported with .11 QoSData > > headers in OCB mode at 5.9GHz. > > (there are some packet dumps with IP packets transported with .11 Data > > headers in OCB mode at 5.9GHz, e.g. attached). > > Alex > > Le 01/03/2018 à 15:32, Alexandre Petrescu a écrit : > >> I received some feedback from programmer. > >> > >> Le 28/02/2018 à 23:48, Abdussalam Baryun a écrit : > >> [...] > >>> 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, > >> > >> Here is the QoS problem for IP over 802.11 OCB in implementations. > >> > >> In short, in open source on linux, we dont know how to send IP packets > >> transported as 802.11 QoSData, all IP packets are transported as 802.11 > >> Data instead. > >> > >> - if you ping -Q at 5.9GHz in OCB mode, the DSCP fields do get > >>    set properly in IP headers of Echorequest, but there is no .11 QoSData > >>    headers in packets.  Normally, one expects the QoSData headers to be > >>    present there when the DSCP (an IP field) is set. > >> > >> - if you want to modify kernel, and force always to use QoSData headers > >>    on WiFi, including OCB at 5.9GHz, there is a net/mac80211/tx.c file > >>    with a flag called wme_sta that you could set to true.  But take care > >>    that the C comments there say that it's not normal to use QoSData > >>    headers in OCB mode, because a terminal sending QoSData has no > >>    guarantee that receivers also use QoSData (the negotiation of QoS > >>    capabilities are absent in OCB). > >> > >> As you can see, this can be long to try and fix. > >> > >> Until then I will propose to set QoS aside from IP-over-OCB at this time. > >> > >> Alex > >> > >> _______________________________________________ > >> 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 Thu Mar 1 10:00: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 CB11312EC06 for ; Thu, 1 Mar 2018 10:00:27 -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 YQ6WoiLxwm-6 for ; Thu, 1 Mar 2018 10:00:25 -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 D49B312EC00 for ; Thu, 1 Mar 2018 10:00:24 -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 w21I0KB0021125; Thu, 1 Mar 2018 19:00:21 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E75BC206339; Thu, 1 Mar 2018 19:00: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 D6F492061D3; Thu, 1 Mar 2018 19:00: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 w21I0KpN021261; Thu, 1 Mar 2018 19:00:20 +0100 To: dickroy@alum.mit.edu, =?UTF-8?B?J0rDqXLDtG1lIEjDpHJyaSc=?= , 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> <1eca0280-0931-fa39-5706-cadc22cca17c@gmail.com> <526c8e1d-652b-56e7-c113-1ae52ef720e6@gmail.com> <007f01d3b17f$efd51b00$cf7f5100$@eurecom.fr> <78E78E385EDA4F78AEDC5BB5EC248A2A@SRA6> From: Alexandre Petrescu Message-ID: <84364d10-c4a1-9eaa-0cef-e8858e3d06e9@gmail.com> Date: Thu, 1 Mar 2018 19:00: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: <78E78E385EDA4F78AEDC5BB5EC248A2A@SRA6> Content-Type: text/plain; charset=windows-1252; 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 - new text proposal X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 01 Mar 2018 18:00:28 -0000 Then how about this suggestion. OLD: > 802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB > attribute dot11OCBActivited is true. The OCB mode requires > transmission of QoS data frames (IEEE Std 802.11e), half-clocked > operation (IEEE Std 802.11j), and use of 5.9 GHz frequency band. > Nota: any implementation should comply with standards and regulations > set in the different countries for using that frequency band. NEW: > 802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB > attribute dot11OCBActivited is true. Alex Le 01/03/2018 18:33, Dick Roy a crit : > Not quite right yet ... :^((((( OCB-mode does not "permit use of > 5.9GHz, OCB mode is required in the 5.9GHz band in the US and > Europe according to 802.11. Secondly, if youre going to list the > frames allowed, list them all. Otherwise dont list any. > > RR > > -----Original Message----- From: its [mailto:its-bounces@ietf.org] On > Behalf Of Jrme Hrri Sent: Thursday, March 1, 2018 9:09 AM To: > 'Alexandre Petrescu'; its@ietf.org Subject: Re: [ipwave] 802.11 Data > vs 802.11 QoS Data in IPv6-over-802.11-OCB - new text proposal > > Agreed..indeed, that was wrong :-) > > BR, > > Jrme > > -----Original Message----- > > From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre > Petrescu > > Sent: Thursday 01 March 2018 17:40 > > To: its@ietf.org > > Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in > IPv6-over-802.11-OCB - new text proposal > > In the Terminology section, I propose this resolution. > > OLD: > >> 802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB > >> attribute dot11OCBActivited is true. The OCB mode requires > >> transmission of QoS data frames (IEEE Std 802.11e), half-clocked > >> operation (IEEE Std 802.11j), and use of 5.9 GHz frequency band. > >> Nota: any implementation should comply with standards and >> regulations > >> set in the different countries for using that frequency band. > > NEW: > >> 802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB > >> attribute dot11OCBActivited is true. The OCB mode permits the > >> transmission of 802.11 Data frames, of 802.11 QoS Data frames >> (IEEE > >> Std 802.11e), half-clocked operation (IEEE Std 802.11j), and use >> of > >> 5.9 GHz frequency band. Nota: any implementation should comply >> with > >> standards and regulations set in the different countries for using > >> that frequency band. > > I hope you dont disagree with this proposal. > > Alex > > Le 01/03/2018 15:48, Alexandre Petrescu a crit : > >> Hi, > >> > >> I propose this new resolution: say "802.11 headers" instead of >> "Data > >> Headers" and of "QoS Data Headers". Which header to use is left > >> outside the scope of this document. > >> > >> OLD: > >>> At reception, this layer takes as input the IEEE 802.11 Data >>> Header > >>> and the Logical-Link Layer Control Header and produces an >>> Ethernet II > >>> Header. > >> > >> NEW: > >>> At reception, this layer takes as input the IEEE 802.11 header >>> and > >>> the Logical-Link Layer Control Header and produces an Ethernet >>> II Header. > >> > >> OLD: > >>> 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. > >> > >> NEW: > >>> The Receiver and Transmitter Address fields in the 802.11 header >>> MUST > >>> contain the same values as the Destination and the Source >>> Address > >>> fields in the Ethernet II Header, respectively. > >> > >> 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. > >> [...] > >>> [I-D.ietf-tsvwg-ieee-802-11], although it is not specific to >>> OCB > >>> mode. > >> > >> NEW: > >>> The specification of the 802.11 header used to transmit IP >>> packets is > >>> outside the scope of this document. > >> > >> I hope you dont disagree. > >> > >> Alex > >> > >> > >> > >> Le 28/02/2018 08:39, Alexandre Petrescu a crit : > >>> 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 > >>> > >>> _______________________________________________ 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 Fri Mar 2 00:59: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 065261241F8 for ; Fri, 2 Mar 2018 00:59: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 gjSqc1qidv5u for ; Fri, 2 Mar 2018 00:59: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 DADF31205D3 for ; Fri, 2 Mar 2018 00:59:40 -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 w228xZBO015673; Fri, 2 Mar 2018 09:59:35 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 48F862035E7; Fri, 2 Mar 2018 09:59:35 +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 3B8F92035FA; Fri, 2 Mar 2018 09:59:35 +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 w228xYsD003917; Fri, 2 Mar 2018 09:59:35 +0100 To: dickroy@alum.mit.edu References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <9ada5591-2af3-272d-3bc3-031bf35454c3@gmail.com> <1eca0280-0931-fa39-5706-cadc22cca17c@gmail.com> <36063FD97F6C469AA6B00ADDE6C63DE1@SRA6> From: Alexandre Petrescu Cc: its@ietf.org Message-ID: <21c76a7b-614c-1d10-a809-8722d52efff7@gmail.com> Date: Fri, 2 Mar 2018 09:59:34 +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: <36063FD97F6C469AA6B00ADDE6C63DE1@SRA6> Content-Type: text/plain; charset=windows-1252; 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 - new text proposal X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 08:59:43 -0000 Dick, My understanding is in explanation further below. I hope I have it right, but I never know. Essentially, I would like to ask you: do you agree that IPv6 currently runs on top of EthernetII (aka DIX) and not directly on top of 802.11? (even when IPv6 packets are sent on 802.11 interfaces). Alex Le 01/03/2018 19:24, Dick Roy a crit : [...] > NEW: > >> At reception, this layer takes as input the IEEE 802.11 header and >> the Logical-Link Layer Control Header and produces an Ethernet II >> Header. > > */[RR] What layer? This makes little to no sense. The 'layer' is the 802.11-to-Ethernet Adaptation Layer, in the title of the section. As far as I can tell IPv6 does not run directly over 802.11 layer, but over the Ethernet layer. So it needs an adaptation layer. > Why would any layer take as input DLL headers (MAC and LLC sublayer > headers) and produce another MAC (and LLC) header??? An adaptation layer helps the IP stack adapt to various link layers, like 802.11 or 802.15.4. The IP stack stays the same: always constructs EthernetII headers. And an adaptation layer converts that to 802.11 or 802.15.4 or oher. In linux, the copy operations of this layer are in net/mac80211/tx.c ether_addr_copy(amsdu_hdr->h_source, h_80211_src). The 'amsdu' is DIX. This adaptation layer, one day maybe, may set that AC_BK field for IP-over-OCB-with-QoSData by copying it from the IP header. The 802.11-to-Ethernet Adaptation Layer outputs a MAC header, but not an LLC header, even though in input there is an LLC header in 802.11. > Thats the function of a bridge! In principle yes, but it depends what you call a bridge. In software, a bridge tool like brctl can do the function of a bridge. The adaptation layer is not brctl. > Why are you even mentioning Ethernet II headers in a draft concerned > with IEEE 802.11 MACs & PHYs!/* Because there is no draft concerned with IP over 802.11 per se, and in this draft we are concerned only with the OCB part of 802.11. If you want, maybe someone can develop an IP stack that is specific to 802.11, and eliminate this adaptation layer that seems superfluos. That could be put in an IP-over-802.11 document. But I am afraid there is too much software to write. > > OLD: > >> 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. > > NEW: > >> The Receiver and Transmitter Address fields in the 802.11 header >> MUST > >> contain the same values as the Destination and the Source Address > >> fields in the Ethernet II Header, respectively. > > */[RR] This seems wrong. Where in the heck did the Ethernet II > header come from in the first place?? One can see the EthernetII headers in wireshark packet dumps in normal mode (not in monitor mode). > Where is 802.3 in a document dealing with IPv6 and 802.11??? I agree with this questioning. My answer is this: we need to write IPv6 over the OCB part of 802.11. But there is no IPv6 over 802.11 in first place. What there is is IPv6-over-Ethernet. > More importantly, I would also not make any specification of this > sort in the document. I can try another rephrasing. > The four address format of 802.11 may prove very useful in the > future, I agree. For that you would need an IPv6-over-802.11 document, and the software. > especially when the group does its job of simply defining new > IPv6 functionality for rapidly varying wireless networks. Then all > mention of OCB mode simply dies away, as well it should! Immediately! > And then all the good work performed can be used with any and all > Wi-Fi (802.11) LANs and others! Which is a real good thing, because > the probability that 5.9GHz OCB operations are actually going to be > deployed in the forseeable future is declining to zero at a rate that > will make your heads spin. /* Noted. [...] > NEW: > >> The specification of the 802.11 header used to transmit IP packets >> is >> outside the scope of this document. > > */[RR] Nice! And the right idea! However it is in direct conflict > with the change you suggest above. Leave this statement in, and > REMOVE all the rest!/* I keep that paragraph. But the EthernetII header is always there, even when IP appears to run on 802.11. I dont know how you want me to not talk about EthernetII, aka DIX. Alex [...] From nobody Fri Mar 2 01:21: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 5202E127201 for ; Fri, 2 Mar 2018 01:21: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 Y0xCXluIVHu7 for ; Fri, 2 Mar 2018 01:21: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 D48A41267BB for ; Fri, 2 Mar 2018 01:21: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 w229LSLA027789; Fri, 2 Mar 2018 10:21:28 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 327FB2036A2; Fri, 2 Mar 2018 10:21:28 +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 241B52036B5; Fri, 2 Mar 2018 10:21:28 +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 w229LR1n027029; Fri, 2 Mar 2018 10:21:28 +0100 To: dickroy@alum.mit.edu References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <9ada5591-2af3-272d-3bc3-031bf35454c3@gmail.com> <1eca0280-0931-fa39-5706-cadc22cca17c@gmail.com> <36063FD97F6C469AA6B00ADDE6C63DE1@SRA6> Cc: its@ietf.org From: Alexandre Petrescu Message-ID: <0b34a046-3868-1332-a33d-094b7180df84@gmail.com> Date: Fri, 2 Mar 2018 10:21: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: <36063FD97F6C469AA6B00ADDE6C63DE1@SRA6> Content-Type: text/plain; charset=windows-1252; 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 - new text proposal X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 09:21:37 -0000 Dick, One more thing. I am trying to remove all text about this WiFi-to-Ethernet Adaptation Layer. And what I am left with is IPv6-over-Ethernet: > IP packets are transmitted over 802.11-OCB as standard Ethernet > packets. Do you think I can just leave it at that? Alex Le 01/03/2018 19:24, Dick Roy a crit: > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu > Sent: Thursday, March 1, 2018 6:48 AM > To: its@ietf.org > Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in > IPv6-over-802.11-OCB - new text proposal > > Hi, > > I propose this new resolution: say "802.11 headers" instead of "Data > > Headers" and of "QoS Data Headers". Which header to use is left outside > > the scope of this document. > > OLD: > >> At reception, this layer takes as input the IEEE 802.11 Data Header > >> and the Logical-Link Layer Control Header and produces an Ethernet II > >> Header. > > NEW: > >> At reception, this layer takes as input the IEEE 802.11 header and the > >> Logical-Link Layer Control Header and produces an Ethernet II Header. > > */[RR] What layer? This makes little to no sense. Why would any > layer take as input DLL headers (MAC and LLC sublayer headers) and > produce another MAC (and LLC) header??? Thats the function of a > bridge! Why are you even mentioning Ethernet II headers in a draft > concerned with IEEE 802.11 MACs & PHYs!/* > > OLD: > >> 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. > > NEW: > >> The Receiver and Transmitter Address fields in the 802.11 header MUST > >> contain the same values as the Destination and the Source Address > >> fields in the Ethernet II Header, respectively. > > */[RR] This seems wrong. Where in the heck did the Ethernet II header > come from in the first place?? Where is 802.3 in a document dealing with > IPv6 and 802.11??? More importantly, I would also not make any > specification of this sort in the document. The four address format of > 802.11 may prove very useful in the future, especially when the group > does its job of simply defining new IPv6 functionality for rapidly > varying wireless networks. Then all mention of OCB mode simply dies > away, as well it should! Immediately! And then all the good work > performed can be used with any and all Wi-Fi (802.11) LANs and others! > Which is a real good thing, because the probability that 5.9GHz OCB > operations are actually going to be deployed in the forseeable future is > declining to zero at a rate that will make your heads spin. /* > > 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. > > [...] > >> [I-D.ietf-tsvwg-ieee-802-11], although it is not specific to OCB > >> mode. > > NEW: > >> The specification of the 802.11 header used to transmit IP packets is > >> outside the scope of this document. > > */[RR] Nice! And the right idea! However it is in direct conflict with > the change you suggest above. Leave this statement in, and REMOVE all > the rest!/* > > *//* > > */Cheers,/* > > */ > RR/* > > I hope you dont disagree. > > Alex > > Le 28/02/2018 08:39, Alexandre Petrescu a crit : > >> 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 > >> > >> _______________________________________________ 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 Fri Mar 2 01:31: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 D849C1270AE for ; Fri, 2 Mar 2018 01:31:28 -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 QC1crrFGLOXO for ; Fri, 2 Mar 2018 01:31:25 -0800 (PST) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002: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 71C9C1267BB for ; Fri, 2 Mar 2018 01:31:25 -0800 (PST) Received: by mail-yb0-x229.google.com with SMTP id i13-v6so3159091ybl.9 for ; Fri, 02 Mar 2018 01:31:25 -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=EFh0qSuuFFAapNlsCys3zSopU5Jih6RqpCfJAUE0lcg=; b=kELh43m8dXk46x0l9YgY40bSrsMkgIAh/qnRhFYWUl0Zmm9qZ+zlGOkaRvDbhEHUHg el/9uaJF19phkTcoVg+lfXsW9kKDjVdzI8lz9wikPhHPIY4BPfRHradiiGz8ucxWezzf ArIoxfPQUSD1Ok2VU2CJifmZCknRhZ36rT4A9/rqomCdUvHQYVYx+PwYHTOLNO6Fl2Q9 QPDtn3rFKnm3hIDWmazym7VjkeiN+hHe2GHQ96aMrihb40L/DOQDD/WAY6/cT8/gUKbj K6jvP47z0T7pQFaLUcPFvuInzfF6jDVqYfvO/yZq6I0XI89PPz9yOtjTlZ5lH9CnBIPg oKrw== 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=EFh0qSuuFFAapNlsCys3zSopU5Jih6RqpCfJAUE0lcg=; b=RgRt1uzvOXavyJo0S2lDrgM+LNUdgt6hG/WryQDfMu9qYbIl+7Bx7/aC5fOP696CP0 qkaXkQduEHHz6PgVHcjdeQU0VFt+f83JpQZhyDw5yNzG2n2lIbDaqnv+ode7CvBpLy+Z Lv+lGkqcL+0eQ0zj7w3oB+NNFzJb7YgLuRvbsMDHEvOepN83FL6o4PDmulV3U+gV4ChJ a4205a+cshHSR3uFrGRzEVWGV9JuU0j+9GQwwsxBFIfecpUpuLqreti4TTNtHctDd4ED yNLsPR5m7KsqD7olTTAzsPXCiHYXg7PhOxqN9hBydgVbKvpDUjpB+7Ie6MFEe7ndtc9y xknw== X-Gm-Message-State: APf1xPDaxLRrUoBxoOod66JIHQDI337l/n1kNud4aDe5NbeGlNKFTddz 8pESbnuZXtUkdrzstMMrJ4iL1yJ4UnT4QvUPNK4= X-Google-Smtp-Source: AG47ELutrqRgMmv9GSyUq4mWHpopQ3gnbmNVQioJOXJAWzMux19k0TNQiy2vvXw070ENSTzLkT9K1I/Y5vZZ7C53oAY= X-Received: by 2002:a25:2e4f:: with SMTP id b15-v6mr3109689ybn.42.1519983084642; Fri, 02 Mar 2018 01:31:24 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a25:b942:0:0:0:0:0 with HTTP; Fri, 2 Mar 2018 01:31:24 -0800 (PST) In-Reply-To: <84364d10-c4a1-9eaa-0cef-e8858e3d06e9@gmail.com> References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <9ada5591-2af3-272d-3bc3-031bf35454c3@gmail.com> <1eca0280-0931-fa39-5706-cadc22cca17c@gmail.com> <526c8e1d-652b-56e7-c113-1ae52ef720e6@gmail.com> <007f01d3b17f$efd51b00$cf7f5100$@eurecom.fr> <78E78E385EDA4F78AEDC5BB5EC248A2A@SRA6> <84364d10-c4a1-9eaa-0cef-e8858e3d06e9@gmail.com> From: Michelle Wetterwald Date: Fri, 2 Mar 2018 10:31:24 +0100 Message-ID: To: Alexandre Petrescu Cc: Richard Roy , =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , its Content-Type: multipart/alternative; boundary="000000000000d328d605666aa3a8" Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB - new text proposal X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 09:31:29 -0000 --000000000000d328d605666aa3a8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alex, May I make a suggestion for that? OLD: 802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB attribute dot11OCBActivited is true. The OCB mode requires transmission of QoS data frames (IEEE Std 802.11e), half-clocked operation (IEEE Std 802.11j), and use of 5.9 GHz frequency band. Nota: any implementation should comply with standards and regulations set in the different countries for using that frequency band. NEW: 802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB attribute dot11OCBActivited is true. Nota: any implementation should comply with standards and regulations set in the different countries when using the 5.9 GHz frequency band. Best regards, Michelle 2018-03-01 19:00 GMT+01:00 Alexandre Petrescu : > Then how about this suggestion. > > OLD: > >> 802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB attribut= e >> dot11OCBActivited is true. The OCB mode requires transmission of QoS da= ta >> frames (IEEE Std 802.11e), half-clocked operation (IEEE Std 802.11j), an= d >> use of 5.9 GHz frequency band. Nota: any implementation should comply wi= th >> standards and regulations >> set in the different countries for using that frequency band. >> > > NEW: > >> 802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB attribut= e >> dot11OCBActivited is true. >> > Alex > > > > Le 01/03/2018 =C3=A0 18:33, Dick Roy a =C3=A9crit : > >> Not quite right yet ... :^((((( OCB-mode does not "permit use of >> 5.9GHz=E2=80=9D, OCB mode is =E2=80=9Crequired=E2=80=9D in the 5.9GHz ba= nd in the US and >> Europe according to 802.11. Secondly, if you=E2=80=99re going to list t= he >> frames allowed, list them all. Otherwise don=E2=80=99t list any. >> >> RR >> >> -----Original Message----- From: its [mailto:its-bounces@ietf.org] On >> Behalf Of J=C3=A9r=C3=B4me H=C3=A4rri Sent: Thursday, March 1, 2018 9:09= AM To: >> 'Alexandre Petrescu'; its@ietf.org Subject: Re: [ipwave] 802.11 Data >> >> vs 802.11 QoS Data in IPv6-over-802.11-OCB - new text proposal >> >> Agreed..indeed, that was wrong :-) >> >> BR, >> >> J=C3=A9r=C3=B4me >> >> -----Original Message----- >> >> From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre >> Petrescu >> >> Sent: Thursday 01 March 2018 17:40 >> >> To: its@ietf.org >> >> Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in >> IPv6-over-802.11-OCB - new text proposal >> >> In the Terminology section, I propose this resolution. >> >> OLD: >> >> 802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB >>> >> >> attribute dot11OCBActivited is true. The OCB mode requires >>> >> >> transmission of QoS data frames (IEEE Std 802.11e), half-clocked >>> >> >> operation (IEEE Std 802.11j), and use of 5.9 GHz frequency band. >>> >> >> Nota: any implementation should comply with standards and >>> regulations >>> >> >> set in the different countries for using that frequency band. >>> >> >> NEW: >> >> 802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB >>> >> >> attribute dot11OCBActivited is true. The OCB mode permits the >>> >> >> transmission of 802.11 Data frames, of 802.11 QoS Data frames >>> (IEEE >>> >> >> Std 802.11e), half-clocked operation (IEEE Std 802.11j), and use >>> of >>> >> >> 5.9 GHz frequency band. Nota: any implementation should comply >>> with >>> >> >> standards and regulations set in the different countries for using >>> >> >> that frequency band. >>> >> >> I hope you dont disagree with this proposal. >> >> Alex >> >> Le 01/03/2018 =C3=A0 15:48, Alexandre Petrescu a =C3=A9crit : >> >> Hi, >>> >> >> >>> >> I propose this new resolution: say "802.11 headers" instead of >>> "Data >>> >> >> Headers" and of "QoS Data Headers". Which header to use is left >>> >> >> outside the scope of this document. >>> >> >> >>> >> OLD: >>> >> >> At reception, this layer takes as input the IEEE 802.11 Data >>>> Header >>>> >>> >> and the Logical-Link Layer Control Header and produces an >>>> Ethernet II >>>> >>> >> Header. >>>> >>> >> >>> >> NEW: >>> >> >> At reception, this layer takes as input the IEEE 802.11 header >>>> and >>>> >>> >> the Logical-Link Layer Control Header and produces an Ethernet >>>> II Header. >>>> >>> >> >>> >> OLD: >>> >> >> 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. >>>> >>> >> >>> >> NEW: >>> >> >> The Receiver and Transmitter Address fields in the 802.11 header >>>> MUST >>>> >>> >> contain the same values as the Destination and the Source >>>> Address >>>> >>> >> fields in the Ethernet II Header, respectively. >>>> >>> >> >>> >> 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. >>>> >>> >> [...] >>> >> >> [I-D.ietf-tsvwg-ieee-802-11], although it is not specific to >>>> OCB >>>> >>> >> mode. >>>> >>> >> >>> >> NEW: >>> >> >> The specification of the 802.11 header used to transmit IP >>>> packets is >>>> >>> >> outside the scope of this document. >>>> >>> >> >>> >> I hope you dont disagree. >>> >> >> >>> >> Alex >>> >> >> >>> >> >>> >> >>> >> Le 28/02/2018 =C3=A0 08:39, Alexandre Petrescu a =C3=A9crit : >>> >> >> 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=3D=3D1"). >>>> >>> >> >>>> >> 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 =C3=A0 03:29, John Kenney a =C3=A9crit : >>>> >>> >> 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 >>>>> >>>> >> >>>> > >>>>> >>>> >> 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 =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 >>>>> >>>> >> >>>>> >>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> -- John Kenney Director and Principal Researcher Toyota >>>>> >>>> >> InfoTechnology Center, USA 465 Bernardo Avenue Mountain View, >>>>> CA >>>>> >>>> >> 94043 Tel: 650-694-4160. Mobile: 650-224-6644 >>>>> >>>> >> >>>> >> _______________________________________________ its mailing >>>> list >>>> >>> >> its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>> >>> >> >>> >> _______________________________________________ >>> >> >> 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 > --=20 Michelle Wetterwald michelle.wetterwald@gmail.com --000000000000d328d605666aa3a8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alex,

May I make a=C2=A0s= uggestion for that?

OLD:
802.11-OCB: mod= e specified in IEEE Std 802.11-2016 when the MIB attribute dot11OCBActivite= d is true.=C2=A0 The OCB mode requires transmission of QoS data frames (IEE= E Std 802.11e), half-clocked operation (IEEE Std 802.11j), and use of 5.9 G= Hz frequency band. Nota: any implementation should comply with standards an= d regulations set in the different countries for using that frequency band.=

NEW:
802.11-OCB: mode specified in IEEE Std 802.11= -2016 when the MIB attribute dot11OCBActivited is true. Nota: any implement= ation should comply with standards and regulations set in the different cou= ntries=C2=A0when using the 5.9 GHz frequency band.

Best regards,
Michelle

=
2018-03-01 19:00 GMT+01:00 Alexandre Petrescu <alexandre.petrescu@gmail.com>:
Then how about this suggestion.

OLD:
802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB attribute d= ot11OCBActivited is true.=C2=A0 The OCB mode requires transmission of QoS d= ata frames (IEEE Std 802.11e), half-clocked operation (IEEE Std 802.11j), a= nd use of 5.9 GHz frequency band. Nota: any implementation should comply wi= th standards and regulations
set in the different countries for using that frequency band.

NEW:
802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB attribute d= ot11OCBActivited is true.
 Alex



Le 01/03/2018 =C3=A0 18:33, Dick Roy a =C3=A9crit :
Not quite right yet ... :^(((((=C2=A0 OCB-mode does not "permit use of= 5.9GHz=E2=80=9D, OCB mode is =E2=80=9Crequired=E2=80=9D in the 5.9GHz band= in the US and
Europe according to 802.11.=C2=A0 Secondly, if you=E2=80=99re going to list= the
frames allowed, list them all.=C2=A0 Otherwise don=E2=80=99t list any.

RR

-----Original Message----- From: its [mailto:its-bounces@ietf.org] On
 Behalf Of J=C3=A9r=C3=B4me H=C3=A4rri Sent: Thursday, March 1, 2018 9:09 AM= To:
'Alexandre Petrescu'; its@ietf.org Subject: Re: [ipwave] 802.11 Data

vs 802.11 QoS Data in IPv6-over-802.11-OCB - new text proposal

Agreed..indeed, that was wrong :-)

BR,

J=C3=A9r=C3=B4me

-----Original Message-----

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

Sent: Thursday 01 March 2018 17:40

To: its@ietf.org

Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OC= B - new text proposal

In the Terminology section, I propose this resolution.

OLD:

802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB

attribute dot11OCBActivited is true.=C2=A0 The OCB mode requires

transmission of QoS data frames (IEEE Std 802.11e), half-clocked

operation (IEEE Std 802.11j), and use of 5.9 GHz frequency band.

Nota: any implementation should comply with standards and
regulations

set in the different countries for using that frequency band.

NEW:

802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB

attribute dot11OCBActivited is true.=C2=A0 The OCB mode permits the

transmission of 802.11 Data frames, of 802.11 QoS Data frames
(IEEE

Std 802.11e), half-clocked operation (IEEE Std 802.11j), and use
of

5.9 GHz frequency band.=C2=A0 =C2=A0Nota: any implementation should comply<= br> with

standards and regulations set in the different countries for using

that frequency band.

I hope you dont disagree with this proposal.

Alex

Le 01/03/2018 =C3=A0 15:48, Alexandre Petrescu a =C3=A9crit :

Hi,



I propose this new resolution: say "802.11 headers"=C2=A0 instead= of
"Data

Headers" and of "QoS Data Headers".=C2=A0 Which header=C2=A0= to use is left

outside the scope of this document.



OLD:

At reception, this layer takes as input the IEEE 802.11 Data
Header

and the Logical-Link Layer Control Header and produces an
Ethernet II

Header.



NEW:

At reception, this layer takes as input the IEEE 802.11 header
and

the Logical-Link Layer Control Header and produces an Ethernet
II Header.



OLD:

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.



NEW:

The Receiver and Transmitter Address fields in the 802.11=C2=A0 header
MUST

contain the same values as the Destination and the Source
Address

fields in the Ethernet II Header, respectively.



OLD:

In OCB mode, IPv6 packets MAY be transmitted either as=C2=A0 "IEEE

802.11

Data" or alternatively as "IEEE 802.11 QoS=C2=A0 Data", as illustrated

in

Figure 2.

[...]

[I-D.ietf-tsvwg-ieee-802-11], although it is not specific=C2=A0 to
OCB

mode.



NEW:

The specification of the 802.11 header used to transmit IP
packets is

outside the scope of this document.



I hope you dont disagree.



Alex







Le 28/02/2018 =C3=A0 08:39, Alexandre Petrescu a =C3=A9crit :

John,



Thank you for the message.



Obviously, we disagree.



If I had access to code that implements what you suggest then=C2=A0 I
would

not hesitate to write that text as you suggest ("MUST QoS=C2=A0 Data,<= br> Qos

Control Field and TID 0001 and UP=3D=3D1").



Until then, I ponder over removal altogher of the section
Ethernet

Adaptation Layer from this draft, and move these QoS aspects=C2=A0 in

another document. Maybe Carlos questioning of this EAL was=C2=A0 right
in

the end.



Alex



Le 28/02/2018 =C3=A0 03:29, John Kenney a =C3=A9crit :

Yes, I disagree.



I suggest: NEW:

In OCB mode, an IPv6 packet MUST be transmitted as an=C2=A0 "IEEE

802.11 QoS Data" frame. In the QoS Control Field,=C2=A0 the TID
subfield

(Bits

0-3) MUST be set equal to binary 0001, corresponding to UP=C2=A0 =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

<alexa= ndre.petrescu@gmail.com
<mailto:alexandre.petrescu@gmail.com>>

wrote:



I propose the following modifications towards resolution=C2=A0 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=C2=A0 Data", as

illustrated in

Figure 2.



NEW:

In OCB mode, it is RECOMMENDED to transmit IPv6=C2=A0 packets as
"IEEE

802.11 Data" (the value of the field Subtype in=C2=A0 the Frame
Control

Field is 0).



Remove this entire OLD text:



In OCB mode, IPv6 packets MAY be transmitted either as=C2=A0 "IEEE
802.11

Data" or alternatively as "IEEE 802.11 QoS=C2=A0 Data", as illustrated in

Figure 2.



+--------------------+-------------+-------------+---------+-----= ------+










| 802.11 Data Header | LLC Header=C2=A0 | IPv6 Header | Payload |.11

Trailer|

+--------------------+-------------+-------------+---------+-----= ------+








or



+--------------------+-------------+-------------+---------+-----= ------+










| 802.11 QoS Data Hdr| LLC Header=C2=A0 | 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=C2=A0 value
of the

field "Type/Subtype".=C2=A0 The value of the field=C2=A0 "Ty= pe/Subtype"
in the

802.11 Data header is 0x0020.=C2=A0 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=C2=A0 fields in the = "802.11 QoS
Data

Header" (e.g.=C2=A0 "QoS Control") are not=C2=A0 specified i= n this
document.

Guidance for a potential mapping is provided in

[I-D.ietf-tsvwg-ieee-802-11], although it is not specific=C2=A0 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=C2=A0 "IEEE
802.11

Data" or alternatively as "IEEE 802.11 QoS=C2=A0 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=C2=A0 Frame
Control

Field is 0).





Alex





_______________________________________________ its=C2=A0 mailing
list

its@ietf.org <mail= to:its@ietf.org>

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

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









-- John Kenney Director and Principal Researcher Toyota

InfoTechnology Center, USA 465 Bernardo Avenue Mountain View,
CA

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



_______________________________________________ its mailing
list

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



_______________________________________________

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



--
Michelle Wetterwald
michelle.w= etterwald@gmail.com
--000000000000d328d605666aa3a8-- From nobody Fri Mar 2 01:32: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 5EA5F1270AE for ; Fri, 2 Mar 2018 01:32: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 xGew2eyHESio for ; Fri, 2 Mar 2018 01:32:02 -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 F2C0C1267BB for ; Fri, 2 Mar 2018 01:32:01 -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 w229VvRc031461; Fri, 2 Mar 2018 10:31:57 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id CED2B20366D; Fri, 2 Mar 2018 10:31:57 +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 C0C4B203604; Fri, 2 Mar 2018 10:31:57 +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 w229VvY2004134; Fri, 2 Mar 2018 10:31:57 +0100 To: dickroy@alum.mit.edu References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <9ada5591-2af3-272d-3bc3-031bf35454c3@gmail.com> <1eca0280-0931-fa39-5706-cadc22cca17c@gmail.com> <36063FD97F6C469AA6B00ADDE6C63DE1@SRA6> Cc: its@ietf.org From: Alexandre Petrescu Message-ID: Date: Fri, 2 Mar 2018 10:31:57 +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: <36063FD97F6C469AA6B00ADDE6C63DE1@SRA6> Content-Type: text/plain; charset=windows-1252; 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 - new text proposal X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 09:32:04 -0000 Le 01/03/2018 19:24, Dick Roy a crit: [...] > NEW: > >> The specification of the 802.11 header used to transmit IP packets is >> outside the scope of this document. > > */[RR] Nice! And the right idea! However it is in direct conflict with > the change you suggest above. Leave this statement in, and REMOVE all > the rest!/* I will say "The specification of _which_ type or subtype of 802.11 headers are used to transmit IP packets is left outside the scope of this document". In this way, it does not conflict with previous text. Alex > > *//* > > */Cheers,/* > > */ > RR/* > > I hope you dont disagree. > > Alex > > Le 28/02/2018 08:39, Alexandre Petrescu a crit : > >> 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 > >> > >> _______________________________________________ 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 Fri Mar 2 01:33: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 32AB0127601 for ; Fri, 2 Mar 2018 01:32:56 -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 EZU0498fm0cI for ; Fri, 2 Mar 2018 01:32:53 -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 3DED91267BB for ; Fri, 2 Mar 2018 01:32:53 -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 w229Wlro031741; Fri, 2 Mar 2018 10:32:47 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E9515203647; Fri, 2 Mar 2018 10:32: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 D65A020340F; Fri, 2 Mar 2018 10:32:46 +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 w229WkAR004904; Fri, 2 Mar 2018 10:32:46 +0100 To: Michelle Wetterwald Cc: Richard Roy , =?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> <1eca0280-0931-fa39-5706-cadc22cca17c@gmail.com> <526c8e1d-652b-56e7-c113-1ae52ef720e6@gmail.com> <007f01d3b17f$efd51b00$cf7f5100$@eurecom.fr> <78E78E385EDA4F78AEDC5BB5EC248A2A@SRA6> <84364d10-c4a1-9eaa-0cef-e8858e3d06e9@gmail.com> From: Alexandre Petrescu Message-ID: <9b9f04f0-34e2-292e-cc93-8644b95f62a7@gmail.com> Date: Fri, 2 Mar 2018 10:32: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 - new text proposal X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 09:32:56 -0000 Le 02/03/2018 à 10:31, Michelle Wetterwald a écrit : > Hi Alex, > > May I make a suggestion for that? > > OLD: > 802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB > attribute dot11OCBActivited is true.  The OCB mode requires transmission > of QoS data frames (IEEE Std 802.11e), half-clocked operation (IEEE Std > 802.11j), and use of 5.9 GHz frequency band. Nota: any implementation > should comply with standards and regulations set in the different > countries for using that frequency band. > > NEW: > 802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB > attribute dot11OCBActivited is true. Nota: any implementation should > comply with standards and regulations set in the different > countries when using the 5.9 GHz frequency band. I have been asked whether 'Nota' is in language Italian? Alex > > Best regards, > Michelle > > 2018-03-01 19:00 GMT+01:00 Alexandre Petrescu > >: > > Then how about this suggestion. > > OLD: > > 802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB > attribute dot11OCBActivited is true.  The OCB mode requires > transmission of QoS data frames (IEEE Std 802.11e), half-clocked > operation (IEEE Std 802.11j), and use of 5.9 GHz frequency band. > Nota: any implementation should comply with standards and > regulations > set in the different countries for using that frequency band. > > > NEW: > > 802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB > attribute dot11OCBActivited is true. > > Alex > > > > Le 01/03/2018 à 18:33, Dick Roy a écrit : > > Not quite right yet ... :^(((((  OCB-mode does not "permit use > of 5.9GHz”, OCB mode is “required” in the 5.9GHz band in the US and > Europe according to 802.11.  Secondly, if you’re going to list the > frames allowed, list them all.  Otherwise don’t list any. > > RR > > -----Original Message----- From: its > [mailto:its-bounces@ietf.org ] On > Behalf Of Jérôme Härri Sent: Thursday, March 1, 2018 9:09 AM To: > 'Alexandre Petrescu'; its@ietf.org > Subject: Re: [ipwave] 802.11 Data > > vs 802.11 QoS Data in IPv6-over-802.11-OCB - new text proposal > > Agreed..indeed, that was wrong :-) > > BR, > > Jérôme > > -----Original Message----- > > From: its [mailto:its-bounces@ietf.org > ] On Behalf Of Alexandre > Petrescu > > Sent: Thursday 01 March 2018 17:40 > > To: its@ietf.org > > Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in > IPv6-over-802.11-OCB - new text proposal > > In the Terminology section, I propose this resolution. > > OLD: > > 802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB > > > attribute dot11OCBActivited is true.  The OCB mode requires > > > transmission of QoS data frames (IEEE Std 802.11e), half-clocked > > > operation (IEEE Std 802.11j), and use of 5.9 GHz frequency band. > > > Nota: any implementation should comply with standards and > regulations > > > set in the different countries for using that frequency band. > > > NEW: > > 802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB > > > attribute dot11OCBActivited is true.  The OCB mode permits the > > > transmission of 802.11 Data frames, of 802.11 QoS Data frames > (IEEE > > > Std 802.11e), half-clocked operation (IEEE Std 802.11j), and use > of > > > 5.9 GHz frequency band.   Nota: any implementation should comply > with > > > standards and regulations set in the different countries for > using > > > that frequency band. > > > I hope you dont disagree with this proposal. > > Alex > > Le 01/03/2018 à 15:48, Alexandre Petrescu a écrit : > > Hi, > > > > > I propose this new resolution: say "802.11 headers"  instead of > "Data > > > Headers" and of "QoS Data Headers".  Which header  to use is > left > > > outside the scope of this document. > > > > > OLD: > > > At reception, this layer takes as input the IEEE 802.11 Data > Header > > > and the Logical-Link Layer Control Header and produces an > Ethernet II > > > Header. > > > > > NEW: > > > At reception, this layer takes as input the IEEE 802.11 > header > and > > > the Logical-Link Layer Control Header and produces an > Ethernet > II Header. > > > > > OLD: > > > 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. > > > > > NEW: > > > The Receiver and Transmitter Address fields in the > 802.11  header > MUST > > > contain the same values as the Destination and the Source > Address > > > fields in the Ethernet II Header, respectively. > > > > > 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. > > > [...] > > > [I-D.ietf-tsvwg-ieee-802-11], although it is not > specific  to > OCB > > > mode. > > > > > NEW: > > > The specification of the 802.11 header used to transmit IP > packets is > > > outside the scope of this document. > > > > > I hope you dont disagree. > > > > > Alex > > > > > > > > > Le 28/02/2018 à 08:39, Alexandre Petrescu a écrit : > > > 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 > > > > > _______________________________________________ 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 > > > > > > -- > Michelle Wetterwald > michelle.wetterwald@gmail.com From nobody Fri Mar 2 01:44: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 A571F1272E1 for ; Fri, 2 Mar 2018 01:44: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 TJrfPEjroBkT for ; Fri, 2 Mar 2018 01:44: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 9911D1270AE for ; Fri, 2 Mar 2018 01:44:14 -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 w229iC7P141007 for ; Fri, 2 Mar 2018 10:44:12 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A37C02036D4 for ; Fri, 2 Mar 2018 10:44:12 +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 9910C203338 for ; Fri, 2 Mar 2018 10:44:12 +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 w229iCjN015207 for ; Fri, 2 Mar 2018 10:44:12 +0100 To: 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> <1eca0280-0931-fa39-5706-cadc22cca17c@gmail.com> <526c8e1d-652b-56e7-c113-1ae52ef720e6@gmail.com> <007f01d3b17f$efd51b00$cf7f5100$@eurecom.fr> <78E78E385EDA4F78AEDC5BB5EC248A2A@SRA6> <84364d10-c4a1-9eaa-0cef-e8858e3d06e9@gmail.com> <9b9f04f0-34e2-292e-cc93-8644b95f62a7@gmail.com> From: Alexandre Petrescu Message-ID: <21cfa231-e69b-b66e-e14c-9aca61630b0a@gmail.com> Date: Fri, 2 Mar 2018 10:44: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: <9b9f04f0-34e2-292e-cc93-8644b95f62a7@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 - new text proposal X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 09:44:18 -0000 I propose this: OLD: > 802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB > attribute dot11OCBActivited is true. The OCB mode requires > transmission of QoS data frames (IEEE Std 802.11e), half-clocked > operation (IEEE Std 802.11j), and use of 5.9 GHz frequency band. > Nota: any implementation should comply with standards and > regulations set in the different countries for using that frequency > band. NEW: > 802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB > attribute dot11OCBActivited is true. Note: compliance with > standards and regulations set in different countries when using the > 5.9GHz frequency band is required. Alex Le 02/03/2018 à 10:32, Alexandre Petrescu a écrit : > > > Le 02/03/2018 à 10:31, Michelle Wetterwald a écrit : >> Hi Alex, >> >> May I make a suggestion for that? >> >> OLD: 802.11-OCB: mode specified in IEEE Std 802.11-2016 when the >> MIB attribute dot11OCBActivited is true. The OCB mode requires >> transmission of QoS data frames (IEEE Std 802.11e), half-clocked >> operation (IEEE Std 802.11j), and use of 5.9 GHz frequency band. >> Nota: any implementation should comply with standards and >> regulations set in the different countries for using that frequency >> band. >> >> NEW: 802.11-OCB: mode specified in IEEE Std 802.11-2016 when the >> MIB attribute dot11OCBActivited is true. Nota: any implementation >> should comply with standards and regulations set in the different >> countries when using the 5.9 GHz frequency band. > > I have been asked whether 'Nota' is in language Italian? > > Alex > >> >> Best regards, Michelle >> >> 2018-03-01 19:00 GMT+01:00 Alexandre Petrescu >> > >: >> >> Then how about this suggestion. >> >> OLD: >> >> 802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB >> attribute dot11OCBActivited is true. The OCB mode requires >> transmission of QoS data frames (IEEE Std 802.11e), half-clocked >> operation (IEEE Std 802.11j), and use of 5.9 GHz frequency band. >> Nota: any implementation should comply with standards and >> regulations set in the different countries for using that frequency >> band. >> >> >> NEW: >> >> 802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB >> attribute dot11OCBActivited is true. >> >> Alex >> >> >> >> Le 01/03/2018 à 18:33, Dick Roy a écrit : >> >> Not quite right yet ... :^((((( OCB-mode does not "permit use of >> 5.9GHz”, OCB mode is “required” in the 5.9GHz band in the US and >> Europe according to 802.11. Secondly, if you’re going to list the >> frames allowed, list them all. Otherwise don’t list any. >> >> RR >> >> -----Original Message----- From: its [mailto:its-bounces@ietf.org >> ] On Behalf Of Jérôme Härri Sent: >> Thursday, March 1, 2018 9:09 AM To: 'Alexandre Petrescu'; >> its@ietf.org Subject: Re: [ipwave] 802.11 >> Data >> >> vs 802.11 QoS Data in IPv6-over-802.11-OCB - new text proposal >> >> Agreed..indeed, that was wrong :-) >> >> BR, >> >> Jérôme >> >> -----Original Message----- >> >> From: its [mailto:its-bounces@ietf.org >> ] On Behalf Of Alexandre Petrescu >> >> Sent: Thursday 01 March 2018 17:40 >> >> To: its@ietf.org >> >> Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in >> IPv6-over-802.11-OCB - new text proposal >> >> In the Terminology section, I propose this resolution. >> >> OLD: >> >> 802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB >> >> >> attribute dot11OCBActivited is true. The OCB mode requires >> >> >> transmission of QoS data frames (IEEE Std 802.11e), half-clocked >> >> >> operation (IEEE Std 802.11j), and use of 5.9 GHz frequency band. >> >> >> Nota: any implementation should comply with standards and >> regulations >> >> >> set in the different countries for using that frequency band. >> >> >> NEW: >> >> 802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB >> >> >> attribute dot11OCBActivited is true. The OCB mode permits the >> >> >> transmission of 802.11 Data frames, of 802.11 QoS Data frames >> (IEEE >> >> >> Std 802.11e), half-clocked operation (IEEE Std 802.11j), and use >> of >> >> >> 5.9 GHz frequency band. Nota: any implementation should comply >> with >> >> >> standards and regulations set in the different countries for using >> >> >> that frequency band. >> >> >> I hope you dont disagree with this proposal. >> >> Alex >> >> Le 01/03/2018 à 15:48, Alexandre Petrescu a écrit : >> >> Hi, >> >> >> >> >> I propose this new resolution: say "802.11 headers" instead of >> "Data >> >> >> Headers" and of "QoS Data Headers". Which header to use is left >> >> >> outside the scope of this document. >> >> >> >> >> OLD: >> >> >> At reception, this layer takes as input the IEEE 802.11 Data >> Header >> >> >> and the Logical-Link Layer Control Header and produces an Ethernet >> II >> >> >> Header. >> >> >> >> >> NEW: >> >> >> At reception, this layer takes as input the IEEE 802.11 header and >> >> >> the Logical-Link Layer Control Header and produces an Ethernet II >> Header. >> >> >> >> >> OLD: >> >> >> 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. >> >> >> >> >> NEW: >> >> >> The Receiver and Transmitter Address fields in the 802.11 header >> MUST >> >> >> contain the same values as the Destination and the Source Address >> >> >> fields in the Ethernet II Header, respectively. >> >> >> >> >> 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. >> >> >> [...] >> >> >> [I-D.ietf-tsvwg-ieee-802-11], although it is not specific to OCB >> >> >> mode. >> >> >> >> >> NEW: >> >> >> The specification of the 802.11 header used to transmit IP packets >> is >> >> >> outside the scope of this document. >> >> >> >> >> I hope you dont disagree. >> >> >> >> >> Alex >> >> >> >> >> >> >> >> >> Le 28/02/2018 à 08:39, Alexandre Petrescu a écrit : >> >> >> 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 >> >> >> >> >> >> _______________________________________________ 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 >> >> >> >> >> >> -- Michelle Wetterwald michelle.wetterwald@gmail.com >> > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its From nobody Fri Mar 2 02:02:05 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 CDBC212702E; Fri, 2 Mar 2018 02:02:03 -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.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151998492381.15775.11095673670373191625@ietfa.amsl.com> Date: Fri, 02 Mar 2018 02:02:03 -0800 Archived-At: Subject: [ipwave] I-D Action: draft-ietf-ipwave-ipv6-over-80211ocb-20.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: Fri, 02 Mar 2018 10:02:04 -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-20.txt Pages : 39 Date : 2018-03-02 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-20 https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Mar 2 02:05: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 6EDAB12D87F for ; Fri, 2 Mar 2018 02:05:10 -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 VsHLVEwsOTUy for ; Fri, 2 Mar 2018 02:05: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 B02D712702E for ; Fri, 2 Mar 2018 02:05:07 -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 w22A56Z0045782 for ; Fri, 2 Mar 2018 11:05:06 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 123E2206441 for ; Fri, 2 Mar 2018 11:05: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 0374E20645B for ; Fri, 2 Mar 2018 11:05: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 w22A55ws004095 for ; Fri, 2 Mar 2018 11:05:05 +0100 References: <151998492399.15775.15971432877926900473.idtracker@ietfa.amsl.com> To: "its@ietf.org" From: Alexandre PETRESCU Organization: CEA X-Forwarded-Message-Id: <151998492399.15775.15971432877926900473.idtracker@ietfa.amsl.com> Message-ID: <26bf844a-99a7-818d-22d7-b21f0540d3be@cea.fr> Date: Fri, 2 Mar 2018 11:05: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: <151998492399.15775.15971432877926900473.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090706030009030303060604" Archived-At: Subject: [ipwave] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-20.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, 02 Mar 2018 10:05:14 -0000 This is a cryptographically signed message in MIME format. --------------ms090706030009030303060604 Content-Type: multipart/alternative; boundary="------------FC43BD9AFDFE77A8D5804DB2" Content-Language: fr This is a multi-part message in MIME format. --------------FC43BD9AFDFE77A8D5804DB2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi IPWAVErs, I submitted a new version of the IP-over-OCB draft. If furrther objections please comment on this version. This is the ChangeLog: =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Reduced the definition of term "80= 2.11-OCB". =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Left out of this specification whi= ch 802.11 header to use =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 to transmit IP packets in OCB mode= (QoS Data header, Data =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 header, or any other). =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Added 'MUST' use an Ethernet Adapt= ation Layer, instead of =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 'is using' an Ethernet Adaptation = Layer. Alex -------- Message transf=C3=A9r=C3=A9 -------- Sujet=C2=A0: New Version Notification for=20 draft-ietf-ipwave-ipv6-over-80211ocb-20.txt Date=C2=A0: Fri, 2 Mar 2018 02:02:03 -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-20.txt has been successfully submitted by Alexandre Petrescu and posted to the IETF repository. Name: draft-ietf-ipwave-ipv6-over-80211ocb Revision: 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) Document date: 2018-03-02 Group: ipwave Pages: 39 URL: https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ip= v6-over-80211ocb-20.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-20 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-i= pv6-over-80211ocb-20 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipwave-ipv= 6-over-80211ocb-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 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 --------------FC43BD9AFDFE77A8D5804DB2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi IPWAVErs,

I submitted a new version of the IP-over-OCB draft.

If furrther objection= s please comment on this version.

This is the ChangeLog= :

=C2=A0=C2=A0=C2=A0 =C2= =A0=C2=A0=C2=A0 Reduced the definition of term "802.11-OCB".

=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Left out of this specific= ation which 802.11 header to use
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 to transmit IP packets in= OCB mode (QoS Data header, Data
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 header, or any other).

=C2=A0=C2=A0=C2=A0 =C2= =A0=C2=A0=C2=A0 Added 'MUST' use an Ethernet Adaptation Layer, instead of
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 'is using' an Ethernet Ad= aptation Layer.

Alex



-------- Message transf=C3=A9r=C3=A9 --------
Suj= et=C2=A0: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-20.txt
Dat= e=C2=A0: Fri, 2 Mar 2018 02:02:03 -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-20.=
txt
has been successfully submitted by Alexandre Petrescu and posted to the
IETF repository.

Name:		draft-ietf-ipwave-ipv6-over-80211ocb
Revision:	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)
Document date:	2018-03-02
Group:		ipwave
Pages:		39
URL:            https=
://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-20.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-20
Htmlized:       https://=
datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-20=

Diff:           https://ww=
w.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipwave-ipv6-over-80211ocb-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


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
--------------FC43BD9AFDFE77A8D5804DB2-- --------------ms090706030009030303060604 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 CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODAzMDIxMDA1MDVaMC8GCSqGSIb3 DQEJBDEiBCCGMP1rEYOgCVw5eEhuT4hiN42tQklhRGw0Dwqr3jczlTBSBgkrBgEEAYI3EAQx RTBDMD0xCzAJBgNVBAYTAkZSMQwwCgYDVQQKDANDRUExIDAeBgNVBAMMF0NFQSBBQyBVdGls aXNhdGV1ciAyMDMxAgIYEjBUBgsqhkiG9w0BCRACCzFFoEMwPTELMAkGA1UEBhMCRlIxDDAK BgNVBAoMA0NFQTEgMB4GA1UEAwwXQ0VBIEFDIFV0aWxpc2F0ZXVyIDIwMzECAhgSMGwGCSqG SIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJ KoZIhvcNAQEBBQAEggEAi8TiPzshFkmUuj/LZGaSw5e4qils0Dr/4izPJJZdrWGYGOa0uaA1 WBJ81EE6Krfld5ReBO4/qltCuney+6vv9R2sNYkCkho8sHJKAGXWjkHJaQ4k4rd6rECyT+nn kAxNvu0mJxAtoVp/8F5lYpx8QRZ9P01FNlA3GZU4aiS4idhWa1hoKOHOx3FzuQRfGcyNkIFA EmzEDA2OXnofF+PTL9r6Cwoe8VLPF02dLGFMhQMw9oaXaH6TX5KQJqNZtRR4jpoSJzCNVIjB k9qBmVQhwdMczDrJ429d5z2tV758Sh+nVXEH7/sU9xyYkSLTV+zDkb8GMosb08R4aiLd0mGc eQAAAAAAAA== --------------ms090706030009030303060604-- From nobody Fri Mar 2 08:16: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 5B31E12D77C for ; Fri, 2 Mar 2018 08:16: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, 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 wKytIloyg7Be for ; Fri, 2 Mar 2018 08:16:32 -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 E841812D7EA for ; Fri, 2 Mar 2018 08:16:27 -0800 (PST) Received: by mail-pl0-x236.google.com with SMTP id f23-v6so5941428plr.10 for ; Fri, 02 Mar 2018 08:16:27 -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=TNx4k9EH+ndCMInN2i2PGb3Bs2kPfkJx+QDF+HTXPbM=; b=ZIcPQJK7Qxah90xAbaNIo+OfWyiZNF0/vjP6A2y7N/greYT+a9HMBH5Thqih8p+BWp 5z8XTvqGnpu4UhQmrK2ak0ms70HrHeMspzytwHM/pZmiyWf5G90wn6E8puqcA7N1wP36 EtTrH0WVNQDv9UrhMDTBe2b1uJx1XI1Lmscxs= 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=TNx4k9EH+ndCMInN2i2PGb3Bs2kPfkJx+QDF+HTXPbM=; b=WADbrqiTMecbXfNJ5iGdNhx15853JRdcDp9HrSjtV87Yx2+/r1M56GYalwFEWvtbXJ PkrPRXyIFLdfrYuLOgTa+dZ2u/Er3owwKdUcSMWXxkSOAfpY9F5xGZNBJfbQ/osUJFMm 905/t1VL+sxBgF9bRPcrzSZBK8qifRAglMHx1nJHvXZjDQJFdLDSBcq3FijPlgoR8Aq2 4Lsh472pHVDqyZc4Di1SDCs34IhmoVQ9rEtoqG6QBDCjlUicRRQLdxfZcTfYXhcv8E57 xgAwVMj0dWzduYQlMQs/3Nlm6ioDZ8MbjSel2GvQnsEv7tsTq7ITt2d/r3jwzoYDWMcQ npHw== X-Gm-Message-State: APf1xPC4Ifk2pUliTYrXYrKywqWIH4goPVacsb3M2SOdRj1NzhNRIhX3 7UCTZ15mra3HzRpJGc4K5AkbCjWjsYctLoVJG+cKTISD X-Google-Smtp-Source: AG47ELtFM64Laq+k0F38NQKVYeCvMMvnEN9mm9b3eKglOgFAw5YzNCdP3pzucX7MMyS7MQaP7bsoYizV1GFekvVFyvw= X-Received: by 2002:a17:902:27:: with SMTP id 36-v6mr5709441pla.128.1520007385978; Fri, 02 Mar 2018 08:16:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.186.163 with HTTP; Fri, 2 Mar 2018 08:16:04 -0800 (PST) In-Reply-To: <86a2077a-ea46-c99b-c048-60ab78f69ec3@gmail.com> References: <007901d3aee3$a9985ba0$fcc912e0$@eurecom.fr> <00f801d3af1d$f20ce4c0$d626ae40$@gmail.com> <002b01d3af21$6e779a70$4b66cf50$@eurecom.fr> <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> <5ccad588-bcd8-d179-165b-7936a34220fb@gmail.com> <5a98213d.d138c80a.ababc.519f@mx.google.com> <5a982375.042bed0a.1271f.4afc@mx.google.com> <86a2077a-ea46-c99b-c048-60ab78f69ec3@gmail.com> From: William Whyte Date: Fri, 2 Mar 2018 11:16:04 -0500 Message-ID: To: Alexandre Petrescu Cc: "its@ietf.org" Content-Type: multipart/alternative; boundary="0000000000004c32890566704cd5" 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: Fri, 02 Mar 2018 16:16:34 -0000 --0000000000004c32890566704cd5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I've confirmed that the US implementations use QoSData, just to close that loop. Cheers, William On Thu, Mar 1, 2018 at 11:05 AM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > William, > > Le 01/03/2018 =C3=A0 16:59, William Whyte a =C3=A9crit : > >> > I propose we rename 'OCB' into 'IP-OCB' in the draft. >> >> > 'IP-OCB' is an OCB mode that can be transport IP packets with .11 Dat= a >> >> > headers or with .11 QoS Data headers. >> >> If it=E2=80=99s over OCB, then it needs to use QoSData. If you=E2=80=99r= e doing Data, >> you=E2=80=99re not conformant to OCB. There can=E2=80=99t be an OCB mode= that transports >> packets with .11 Data, because OCB by definition uses QoSData. If the dr= aft >> implies that you can do non-conformant OCB, that=E2=80=99s a serious def= ect in the >> draft. >> >> Some implementations may not yet have implemented this, but that=E2=80= =99s on >> those developers. >> > > For one second, allow me the benefit of the doubt about specifications > that may not be implemented. > > I would like to know whether there is an implementation of IP over OCB > with QoSData headers? Packet dump is sufficient, or any other kind of > statement. > > I agree with you that many times it is good to write specification first > and implementation after. > > Alex > > >> Cheers, >> >> William >> >> Sent from Mail for >> Windows 10 >> >> *From: *Alexandre Petrescu >> *Sent: *Thursday, March 1, 2018 10:54 AM >> *To: *William Whyte ; its@ietf.org >> >> *Subject: *Re: [ipwave] 802.11 Data vs 802.11 QoS Data in >> IPv6-over-802.11-OCB-implementations >> >> >> Le 01/03/2018 =C3=A0 16:50, William Whyte a =C3=A9crit : >> >> > >> (there are some packet dumps with IP packets transported with .11 >> Data >> >> > >> >> > headers in OCB mode at 5.9GHz, e.g. attached). >> >> > >> >> > My understanding is OCB mode requires QoSData, so those packets aren= =E2=80=99t >> >> > conformant to the standard. >> >> I propose we rename 'OCB' into 'IP-OCB' in the draft. >> >> 'IP-OCB' is an OCB mode that can be transport IP packets with .11 Data >> >> headers or with .11 QoS Data headers. >> >> Alex >> >> > >> >> > Cheers, >> >> > >> >> > William >> >> > >> >> > Sent from Mail for >> >> > Windows 10 >> >> > >> >> > *From: *Alexandre Petrescu >> >> > *Sent: *Thursday, March 1, 2018 10:48 AM >> >> > *To: *its@ietf.org >> >> > *Subject: *Re: [ipwave] 802.11 Data vs 802.11 QoS Data in >> >> > IPv6-over-802.11-OCB -implementations >> >> > >> >> > In a private discussion, this question came up: >> >> > >> >> > Is there a packet dump showing an IP packet transported with .11 >> QoSData >> >> > >> >> > headers in OCB mode at 5.9GHz. >> >> > >> >> > (there are some packet dumps with IP packets transported with .11 Dat= a >> >> > >> >> > headers in OCB mode at 5.9GHz, e.g. attached). >> >> > >> >> > Alex >> >> > >> >> > Le 01/03/2018 =C3=A0 15:32, Alexandre Petrescu a =C3=A9crit : >> >> > >> >> > > I received some feedback from programmer. >> >> > >> >> > > >> >> > >> >> > > Le 28/02/2018 =C3=A0 23:48, Abdussalam Baryun a =C3=A9crit : >> >> > >> >> > > [...] >> >> > >> >> > >> 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, >> >> > >> >> > > >> >> > >> >> > > Here is the QoS problem for IP over 802.11 OCB in implementations. >> >> > >> >> > > >> >> > >> >> > > In short, in open source on linux, we dont know how to send IP >> packets >> >> > >> >> > > transported as 802.11 QoSData, all IP packets are transported as >> 802.11 >> >> > >> >> > > Data instead. >> >> > >> >> > > >> >> > >> >> > > - if you ping -Q at 5.9GHz in OCB mode, the DSCP fields do get >> >> > >> >> > > set properly in IP headers of Echorequest, but there is no .11 >> QoSData >> >> > >> >> > > headers in packets. Normally, one expects the QoSData headers >> to be >> >> > >> >> > > present there when the DSCP (an IP field) is set. >> >> > >> >> > > >> >> > >> >> > > - if you want to modify kernel, and force always to use QoSData >> headers >> >> > >> >> > > on WiFi, including OCB at 5.9GHz, there is a net/mac80211/tx.c >> file >> >> > >> >> > > with a flag called wme_sta that you could set to true. But tak= e >> care >> >> > >> >> > > that the C comments there say that it's not normal to use QoSDa= ta >> >> > >> >> > > headers in OCB mode, because a terminal sending QoSData has no >> >> > >> >> > > guarantee that receivers also use QoSData (the negotiation of Q= oS >> >> > >> >> > > capabilities are absent in OCB). >> >> > >> >> > > >> >> > >> >> > > As you can see, this can be long to try and fix. >> >> > >> >> > > >> >> > >> >> > > Until then I will propose to set QoS aside from IP-over-OCB at thi= s >> time. >> >> > >> >> > > >> >> > >> >> > > Alex >> >> > >> >> > > >> >> > >> >> > > _______________________________________________ >> >> > >> >> > > its mailing list >> >> > >> >> > > its@ietf.org >> >> > >> >> > > https://www.ietf.org/mailman/listinfo/its >> >> > >> >> --=20 PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS: wwhyte@onboardsecurity.com --0000000000004c32890566704cd5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've confirmed that the US implementations use QoSData= , just to close that loop.

Cheers,

<= div>William

On Thu, Mar 1, 2018 at 11:05 AM, Alexandre Petrescu <alex= andre.petrescu@gmail.com> wrote:
William,

Le 01/03/2018 =C3=A0 16:59, William Whyte a =C3=A9crit=C2=A0:
=C2=A0> I propose we rename 'OCB' into 'IP-OCB' in the d= raft.

=C2=A0> 'IP-OCB' is an OCB mode that can be transport IP packets= with .11 Data

=C2=A0> headers or with .11 QoS Data headers.

If it=E2=80=99s over OCB, then it needs to use QoSData. If you=E2=80=99re d= oing Data, you=E2=80=99re not conformant to OCB. There can=E2=80=99t be an = OCB mode that transports packets with .11 Data, because OCB by definition u= ses QoSData. If the draft implies that you can do non-conformant OCB, that= =E2=80=99s a serious defect in the draft.

Some implementations may not yet have implemented this, but that=E2=80=99s = on those developers.

 For one second, allow me the benefit of the doubt about specifications that= may not be implemented.

I would like to know whether there is an implementation of IP over OCB with= QoSData headers?=C2=A0 Packet dump is sufficient, or any other kind of sta= tement.

I agree with you that many times it is good to write specification first an= d implementation after.

Alex


Cheers,

William

Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=3D550986> for Windows 10

*From: *Alexandre Petrescu <mailto:alexandre.petrescu@gmail.com>
<= /span> *Sent: *Thursday, March 1, 2018 10:54 AM
*To: *William Whyte <mailto:wwhyte@onboardsecurity.com>; its@ietf.org <mailto:its@ietf.org>
*Subject: *Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-= OCB-implementations


Le 01/03/2018 =C3=A0 16:50, William Whyte a =C3=A9crit=C2=A0:

=C2=A0>=C2=A0 >> (there are some packet dumps with IP packets tran= sported with .11 Data

=C2=A0>

=C2=A0> headers in OCB mode at 5.9GHz, e.g. attached).

=C2=A0>

=C2=A0> My understanding is OCB mode requires QoSData, so those packets = aren=E2=80=99t

=C2=A0> conformant to the standard.

I propose we rename 'OCB' into 'IP-OCB' in the draft.

'IP-OCB' is an OCB mode that can be transport IP packets with .11 D= ata

headers or with .11 QoS Data headers.

Alex

=C2=A0>

=C2=A0> Cheers,

=C2=A0>

=C2=A0> William

=C2=A0>

=C2=A0> Sent from Mail <https://go.microsoft.c= om/fwlink/?LinkId=3D550986> for

=C2=A0> Windows 10

=C2=A0>

=C2=A0> *From: *Alexandre Petrescu <mailto:alexandre.petrescu@gmail.com>

=C2=A0> *Sent: *Thursday, March 1, 2018 10:48 AM

=C2=A0> *To: *its@ietf= .org <mailto:its@i= etf.org>

=C2=A0> *Subject: *Re: [ipwave] 802.11 Data vs 802.11 QoS Data in

=C2=A0> IPv6-over-802.11-OCB -implementations

=C2=A0>

=C2=A0> In a private discussion, this question came up:

=C2=A0>

=C2=A0> Is there a packet dump showing an IP packet transported with .11= QoSData

=C2=A0>

=C2=A0> headers in OCB mode at 5.9GHz.

=C2=A0>

=C2=A0> (there are some packet dumps with IP packets transported with .1= 1 Data

=C2=A0>

=C2=A0> headers in OCB mode at 5.9GHz, e.g. attached).

=C2=A0>

=C2=A0> Alex

=C2=A0>

=C2=A0> Le 01/03/2018 =C3=A0 15:32, Alexandre Petrescu a =C3=A9crit=C2= =A0:

=C2=A0>

=C2=A0>=C2=A0 > I received some feedback from programmer.

=C2=A0>

=C2=A0>=C2=A0 >

=C2=A0>

=C2=A0>=C2=A0 > Le 28/02/2018 =C3=A0 23:48, Abdussalam Baryun a =C3= =A9crit=C2=A0:

=C2=A0>

=C2=A0>=C2=A0 > [...]

=C2=A0>

=C2=A0>=C2=A0 >> ieee802.11ocb protocol is already implemented/tes= ted and it is

=C2=A0>

=C2=A0>=C2=A0 >> interoperable, but what is the problem, sorry may= be I did not follow

=C2=A0>

=C2=A0>=C2=A0 >> the discussion well,

=C2=A0>

=C2=A0>=C2=A0 >

=C2=A0>

=C2=A0>=C2=A0 > Here is the QoS problem for IP over 802.11 OCB in imp= lementations.

=C2=A0>

=C2=A0>=C2=A0 >

=C2=A0>

=C2=A0>=C2=A0 > In short, in open source on linux, we dont know how t= o send IP packets

=C2=A0>

=C2=A0>=C2=A0 > transported as 802.11 QoSData, all IP packets are tra= nsported as 802.11

=C2=A0>

=C2=A0>=C2=A0 > Data instead.

=C2=A0>

=C2=A0>=C2=A0 >

=C2=A0>

=C2=A0>=C2=A0 > - if you ping -Q at 5.9GHz in OCB mode, the DSCP fiel= ds do get

=C2=A0>

=C2=A0>=C2=A0 >=C2=A0 =C2=A0 set properly in IP headers of Echoreques= t, but there is no .11 QoSData

=C2=A0>

=C2=A0>=C2=A0 >=C2=A0 =C2=A0 headers in packets.=C2=A0 Normally, one = expects the QoSData headers to be

=C2=A0>

=C2=A0>=C2=A0 >=C2=A0 =C2=A0 present there when the DSCP (an IP field= ) is set.

=C2=A0>

=C2=A0>=C2=A0 >

=C2=A0>

=C2=A0>=C2=A0 > - if you want to modify kernel, and force always to u= se QoSData headers

=C2=A0>

=C2=A0>=C2=A0 >=C2=A0 =C2=A0 on WiFi, including OCB at 5.9GHz, there = is a net/mac80211/tx.c file

=C2=A0>

=C2=A0>=C2=A0 >=C2=A0 =C2=A0 with a flag called wme_sta that you coul= d set to true.=C2=A0 But take care

=C2=A0>

=C2=A0>=C2=A0 >=C2=A0 =C2=A0 that the C comments there say that it= 9;s not normal to use QoSData

=C2=A0>

=C2=A0>=C2=A0 >=C2=A0 =C2=A0 headers in OCB mode, because a terminal = sending QoSData has no

=C2=A0>

=C2=A0>=C2=A0 >=C2=A0 =C2=A0 guarantee that receivers also use QoSDat= a (the negotiation of QoS

=C2=A0>

=C2=A0>=C2=A0 >=C2=A0 =C2=A0 capabilities are absent in OCB).

=C2=A0>

=C2=A0>=C2=A0 >

=C2=A0>

=C2=A0>=C2=A0 > As you can see, this can be long to try and fix.

=C2=A0>

=C2=A0>=C2=A0 >

=C2=A0>

=C2=A0>=C2=A0 > Until then I will propose to set QoS aside from IP-ov= er-OCB at this time.

=C2=A0>

=C2=A0>=C2=A0 >

=C2=A0>

=C2=A0>=C2=A0 > Alex

=C2=A0>

=C2=A0>=C2=A0 >

=C2=A0>

=C2=A0>=C2=A0 > _______________________________________________<= br>
=C2=A0>

=C2=A0>=C2=A0 > its mailing list

=C2=A0>

=C2=A0>=C2=A0 > its= @ietf.org

=C2=A0>

=C2=A0>=C2=A0 > https://www.ietf.org/mailman/lis= tinfo/its

=C2=A0>




--


PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW AD= DRESS: wwhy= te@onboardsecurity.com
--0000000000004c32890566704cd5-- From nobody Fri Mar 2 08:18: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 1E53512D7E8 for ; Fri, 2 Mar 2018 08:18:00 -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 XWcHsozSxOln for ; Fri, 2 Mar 2018 08:17:58 -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 7DB6412D77C for ; Fri, 2 Mar 2018 08:17:58 -0800 (PST) Received: from resomta-po-08v.sys.comcast.net ([96.114.154.232]) by resqmta-po-12v.sys.comcast.net with ESMTP id rnN3eQ3a1pFrNrnNeeHx2d; Fri, 02 Mar 2018 16:17:58 +0000 Received: from [172.22.228.216] ([162.210.130.3]) by resomta-po-08v.sys.comcast.net with SMTP id rnLUeSubs723ornLXememu; Fri, 02 Mar 2018 16:15:55 +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: <0b34a046-3868-1332-a33d-094b7180df84@gmail.com> Date: Fri, 2 Mar 2018 08:15:43 -0800 Cc: Richard Roy , its@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <7bf2fcd7-4328-28e5-baeb-4e0b34a89755@gmail.com> <9fa4ef44-7278-1423-5b39-5f951fce0740@gmail.com> <9ada5591-2af3-272d-3bc3-031bf35454c3@gmail.com> <1eca0280-0931-fa39-5706-cadc22cca17c@gmail.com> <36063FD97F6C469AA6B00ADDE6C63DE1@SRA6> <0b34a046-3868-1332-a33d-094b7180df84@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3445.5.20) X-CMAE-Envelope: MS4wfInMVIla6S7xGveVMAUF30PWPPl7iL+ddgTl//6lBwcm/rvoDt30Wlmmk6SfANiIpr3DLQyrUsXb4u7MGt71yBhVU8IcsxAqHquGycC9ZHiszExnwYox sWovU8RfxqHO8/5uym2FmbEx3WweUSwVqcdBgJwXWExPTi/cOgrMYvP2Y6c6WEnEYdZMHqw44AViRhniXqQIGycYpI1cRNTqAOod9BShBzsurKsG3oeCeMNz Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB - new text proposal X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 16:18:00 -0000 > I am trying to remove all text about this WiFi-to-Ethernet Adaptation = Layer. And what I am left with is IPv6-over-Ethernet: >=20 >> IP packets are transmitted over 802.11-OCB as standard Ethernet >> packets. >=20 > Do you think I can just leave it at that? No, since that would be wildly inaccurate. =20 We need to specify the appropriate headers to use. That is a fundamental = requirement of this document. This part must be normative. Based on the = discussion so far, we MUST use QoS Data and we must be specific about = that. While I appreciate the efforts to evade difficulty by deferring to other = documents, that=E2=80=99s not going to work in this case. Explaining how the adaptation layer simplifies kernel programming may be = part of the document, but since it doesn=E2=80=99t actually appear on = the wire, this part should be informational. Tony From nobody Fri Mar 2 08:25: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 42DB112D7E8 for ; Fri, 2 Mar 2018 08:25:17 -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 ct4hZ1JxXaC6 for ; Fri, 2 Mar 2018 08:25:16 -0800 (PST) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::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 E330C12D77C for ; Fri, 2 Mar 2018 08:25:15 -0800 (PST) Received: by mail-wr0-x22a.google.com with SMTP id o76so10665818wrb.7 for ; Fri, 02 Mar 2018 08:25:15 -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=U0q0NyeYSEFvmz27J2sMZGGwKWtMNJftWCbPD+mrN18=; b=BFrysm+zSJRbP0a9cBJltyj4aK+SA/BCsEXrIM0qPnK0gKCmDyzjTCQKij6CpHq6LF RS5lgGjK+bolS+C/iO4u+lv5pRlUxjEatRMbcbsTLThL4PJIHGWFyzQGc2V/WGLSrZqh 4B83n4WcsdC9ZW8C7N7toyI5sHPA9/UIzqMcqJimksoUXjP+HVScrOuKHtmAHJ9GCcom +ZyPARCM85dgxhWTeYv2YSjous/Kyq32cD7Vo3L1qGDijfCQib6JA0J6CRftp7a2VqQG 5+LNxn+1JXkm7ZVCWmgTQkxh7yozdWYt8d6fg7VbwmFrP3RTL8sChhaiJE6vSwuwTvAK wV7Q== 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=U0q0NyeYSEFvmz27J2sMZGGwKWtMNJftWCbPD+mrN18=; b=QG/MzRj1944mqJEOmgczN+AbcSacKgN5+hY0UR6kCVxlSYusTvxeHtdV7bVd5sdZU0 fWQEk8DzXVmkaKKTZLcLpvGd8itaVG8gXOxkgJzNTq2Lh57yksJgHUZShsWEmKbf4eB7 1YDKuB9VsKGYW+ss963/cguWXDce9P3e98JdawH6W0dpDFoC9c4hSU4scn1R3eayhs1O MBIcepwhCXWDM83ozlxOuCti5Whq9bsPKPqVoL1zQnd2UY/CwpxFLUxuIF0yg8aOEf1K X3yIbKkUrgOgvMRuGIZ48/h/L1xOUefFmiguJTyjEZJq3bcHuS44n20Zy9dRoMqlZAqv 2jhg== X-Gm-Message-State: APf1xPAIHFsoXXQpmG9zMknmtAnRzu6EvNOnDS6+StaXsxnaT5pEaNQQ RvaKdpu+BNRACCQpDoJ/DMe4JB3h X-Google-Smtp-Source: AG47ELvoJoPpY6GBRunLw8+4kVnwMXig9YQMFuNMBCxZLz0GuHZ06RZvNxHtyljwaiLlM4LYmwLuww== X-Received: by 10.223.199.137 with SMTP id l9mr5894749wrg.6.1520007914176; Fri, 02 Mar 2018 08:25:14 -0800 (PST) Received: from acorde ([2001:720:410:1010:d681:d7ff:fe28:350b]) by smtp.gmail.com with ESMTPSA id h197sm1911250wmd.17.2018.03.02.08.25.13 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 02 Mar 2018 08:25:13 -0800 (PST) Message-ID: <1520007912.3735.43.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: Fri, 02 Mar 2018 17:25:12 +0100 In-Reply-To: <1519233010.3516.75.camel@it.uc3m.es> References: <1519233010.3516.75.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] 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: Fri, 02 Mar 2018 16:25:17 -0000 Hi, We have not received any slot request to related to rechartering. If we don't receive any request. Does this mean that there is no interest on rechartering? Please send your agenda requests by this Sunday EOD. Thanks! Carlos On Wed, 2018-02-21 at 18:10 +0100, Carlos Jesús Bernardos Cano wrote: > 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 Fri Mar 2 08:28: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 73F6012D7E6 for ; Fri, 2 Mar 2018 08:28: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 1-4LXvjMgozN for ; Fri, 2 Mar 2018 08:28:05 -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 80CA912D77C for ; Fri, 2 Mar 2018 08:28: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 w22GS398071475; Fri, 2 Mar 2018 17:28:03 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7508A206822; Fri, 2 Mar 2018 17:28: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 669592027A1; Fri, 2 Mar 2018 17:28: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 w22GS3oc002273; Fri, 2 Mar 2018 17:28:03 +0100 To: William Whyte Cc: "its@ietf.org" References: <00f801d3af1d$f20ce4c0$d626ae40$@gmail.com> <002b01d3af21$6e779a70$4b66cf50$@eurecom.fr> <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> <5ccad588-bcd8-d179-165b-7936a34220fb@gmail.com> <5a98213d.d138c80a.ababc.519f@mx.google.com> <5a982375.042bed0a.1271f.4afc@mx.google.com> <86a2077a-ea46-c99b-c048-60ab78f69ec3@gmail.com> From: Alexandre Petrescu Message-ID: Date: Fri, 2 Mar 2018 17:28: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: 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: Fri, 02 Mar 2018 16:28:08 -0000 Le 02/03/2018 à 17:16, William Whyte a écrit : > I've confirmed that the US implementations use QoSData, just to close > that loop. Thanks. It's QoSData with IP, right? Alex > > Cheers, > > William > > On Thu, Mar 1, 2018 at 11:05 AM, Alexandre Petrescu > > wrote: > > William, > > Le 01/03/2018 à 16:59, William Whyte a écrit : > >  > I propose we rename 'OCB' into 'IP-OCB' in the draft. > >  > 'IP-OCB' is an OCB mode that can be transport IP packets > with .11 Data > >  > headers or with .11 QoS Data headers. > > If it’s over OCB, then it needs to use QoSData. If you’re doing > Data, you’re not conformant to OCB. There can’t be an OCB mode > that transports packets with .11 Data, because OCB by definition > uses QoSData. If the draft implies that you can do > non-conformant OCB, that’s a serious defect in the draft. > > Some implementations may not yet have implemented this, but > that’s on those developers. > > > For one second, allow me the benefit of the doubt about > specifications that may not be implemented. > > I would like to know whether there is an implementation of IP over > OCB with QoSData headers?  Packet dump is sufficient, or any other > kind of statement. > > I agree with you that many times it is good to write specification > first and implementation after. > > Alex > > > Cheers, > > William > > Sent from Mail > for Windows 10 > > *From: *Alexandre Petrescu > > *Sent: *Thursday, March 1, 2018 10:54 AM > *To: *William Whyte >; its@ietf.org > > > *Subject: *Re: [ipwave] 802.11 Data vs 802.11 QoS Data in > IPv6-over-802.11-OCB-implementations > > > Le 01/03/2018 à 16:50, William Whyte a écrit : > >  >  >> (there are some packet dumps with IP packets transported > with .11 Data > >  > > >  > headers in OCB mode at 5.9GHz, e.g. attached). > >  > > >  > My understanding is OCB mode requires QoSData, so those > packets aren’t > >  > conformant to the standard. > > I propose we rename 'OCB' into 'IP-OCB' in the draft. > > 'IP-OCB' is an OCB mode that can be transport IP packets with > .11 Data > > headers or with .11 QoS Data headers. > > Alex > >  > > >  > Cheers, > >  > > >  > William > >  > > >  > Sent from Mail > > for > >  > Windows 10 > >  > > >  > *From: *Alexandre Petrescu > > > >  > *Sent: *Thursday, March 1, 2018 10:48 AM > >  > *To: *its@ietf.org > > > >  > *Subject: *Re: [ipwave] 802.11 Data vs 802.11 QoS Data in > >  > IPv6-over-802.11-OCB -implementations > >  > > >  > In a private discussion, this question came up: > >  > > >  > Is there a packet dump showing an IP packet transported with > .11 QoSData > >  > > >  > headers in OCB mode at 5.9GHz. > >  > > >  > (there are some packet dumps with IP packets transported > with .11 Data > >  > > >  > headers in OCB mode at 5.9GHz, e.g. attached). > >  > > >  > Alex > >  > > >  > Le 01/03/2018 à 15:32, Alexandre Petrescu a écrit : > >  > > >  >  > I received some feedback from programmer. > >  > > >  >  > > >  > > >  >  > Le 28/02/2018 à 23:48, Abdussalam Baryun a écrit : > >  > > >  >  > [...] > >  > > >  >  >> 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, > >  > > >  >  > > >  > > >  >  > Here is the QoS problem for IP over 802.11 OCB in > implementations. > >  > > >  >  > > >  > > >  >  > In short, in open source on linux, we dont know how to > send IP packets > >  > > >  >  > transported as 802.11 QoSData, all IP packets are > transported as 802.11 > >  > > >  >  > Data instead. > >  > > >  >  > > >  > > >  >  > - if you ping -Q at 5.9GHz in OCB mode, the DSCP fields > do get > >  > > >  >  >    set properly in IP headers of Echorequest, but there > is no .11 QoSData > >  > > >  >  >    headers in packets.  Normally, one expects the QoSData > headers to be > >  > > >  >  >    present there when the DSCP (an IP field) is set. > >  > > >  >  > > >  > > >  >  > - if you want to modify kernel, and force always to use > QoSData headers > >  > > >  >  >    on WiFi, including OCB at 5.9GHz, there is a > net/mac80211/tx.c file > >  > > >  >  >    with a flag called wme_sta that you could set to > true.  But take care > >  > > >  >  >    that the C comments there say that it's not normal to > use QoSData > >  > > >  >  >    headers in OCB mode, because a terminal sending > QoSData has no > >  > > >  >  >    guarantee that receivers also use QoSData (the > negotiation of QoS > >  > > >  >  >    capabilities are absent in OCB). > >  > > >  >  > > >  > > >  >  > As you can see, this can be long to try and fix. > >  > > >  >  > > >  > > >  >  > Until then I will propose to set QoS aside from > IP-over-OCB at this time. > >  > > >  >  > > >  > > >  >  > Alex > >  > > >  >  > > >  > > >  >  > _______________________________________________ > >  > > >  >  > 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 Fri Mar 2 08:34: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 7EF2212D77C for ; Fri, 2 Mar 2018 08:34:14 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_HK_NAME_FM_MR_MRS=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvnWOHivgTPr for ; Fri, 2 Mar 2018 08:34:12 -0800 (PST) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A52B126E01 for ; Fri, 2 Mar 2018 08:34:12 -0800 (PST) Received: by mail-io0-x236.google.com with SMTP id u84so11179774iod.9 for ; Fri, 02 Mar 2018 08:34:12 -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=/N7N2AIhWa7cxjWQbRheCVNBxyN9PC9nhDecCHGJwy8=; b=QUIKBPQ5Eu2vmFIA/CNG5Ug4aA1quWkbSFNwbJgGFr36ryEcsEPQvK99ARfPE4vNRV bu4uK1fPwdoR8J+oeiuQPbn746SQ6S6IydObpGi79cHhFgyizaD0A4yRdaOG7MltAH6r CkLhP1AAA8sdpgSYlYPw/If0dQeLoN3zdpKBL9mHsGdwppFDD2Ztpt9g3v9L3hVqiMWp 1GZUXBezhyokvtdyVJgguraO86OMYqLrrqeIHnvcWnDIT2YYB6vtHP30pOZ88Ml6A3B5 9rGOhf2LgP2qUTGUL5ZjOz6o8zMANvd+4pZwnXQERpnWI/Ulx1JyJY7c7aRRADJPwPW1 Wdeg== 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=/N7N2AIhWa7cxjWQbRheCVNBxyN9PC9nhDecCHGJwy8=; b=nqshsipt8FwVzry+upQ6U8g9XUs2rVR2jJzOH3JeCAEs6UbVTMzIBID7rVBHiJF1P0 TaWoxCuTyi/SPj+TOG65PycRnyGdSshhWBPzOvXCeCFjBv8WjTRq2qRzjF6bLbQWkl0n 6huDkf8DfwXQ0LraivLOSGO6CgOiV+zBuvZez6gr7+nWi84YmrH1/xbNC1RaVEWd7gaN CEwbCcdMZYZJMA+rkzBWomgxNqahZHgg7qztbPOLwqfMeH1OaDCIG5cgijweFRuyCPhc 4qDOFVeaJ2yfHqPYN1Ptl+qxLFthDhbrXmN5umAAUpP4qkc8Lu/bRYvSrNHcmID74xHG Mwcg== X-Gm-Message-State: APf1xPDaImnhhThj43TDDVN0daXMLMIFEiTQGJUR+P/pdU6Npw4ptwG3 ZX2GItN7itld0CoEcVXfgKrAqL3pF0YbPvGUd2k= X-Google-Smtp-Source: AG47ELtM9BrqRCbZtuBr/2YOW01E3Jj8UX6I1Pals1wTgMGlCvqMrWTHpSiTjEmgOUY4UOtS2bW7FcnDL+ytvCXnLqs= X-Received: by 10.107.132.227 with SMTP id o96mr7578352ioi.58.1520008451462; Fri, 02 Mar 2018 08:34:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.147.194 with HTTP; Fri, 2 Mar 2018 08:33:40 -0800 (PST) In-Reply-To: <1520007912.3735.43.camel@it.uc3m.es> References: <1519233010.3516.75.camel@it.uc3m.es> <1520007912.3735.43.camel@it.uc3m.es> From: "Mr. Jaehoon Paul Jeong" Date: Sat, 3 Mar 2018 01:33:40 +0900 Message-ID: To: CARLOS JESUS BERNARDOS CANO Cc: its@ietf.org, Russ Housley , Chris Shen , "Mr. Jaehoon Paul Jeong" Content-Type: multipart/alternative; boundary="001a113eba72ce1f540566708ba2" Archived-At: Subject: Re: [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: Fri, 02 Mar 2018 16:34:15 -0000 --001a113eba72ce1f540566708ba2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Carlos and Russ, I would like to present our WG document: - IP-based Vehicular Networking: Use Cases, Survey and Problem Statement . draft-ietf-ipwave-vehicular-networking-02 (to be submitted before the submission due) . 20 min Also, I would like to request a 30-min slot to present rechartering and work items and discuss them. I will merge the last IPWAVE mailing list discussion and add some suggested items for rechartering. Thanks. Best Regards, Paul On Sat, Mar 3, 2018 at 1:25 AM, Carlos Jes=C3=BAs Bernardos Cano wrote: > Hi, > > We have not received any slot request to related to rechartering. If we > don't receive any request. Does this mean that there is no interest on > rechartering? > > Please send your agenda requests by this Sunday EOD. > > Thanks! > > Carlos > > On Wed, 2018-02-21 at 18:10 +0100, Carlos Jes=C3=BAs Bernardos Cano wrote= : > > 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 > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php --001a113eba72ce1f540566708ba2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Carlos and Russ,
I would like to present our WG doc= ument:
- IP-based Vehicular Networking: Use Cases, Survey an= d Problem Statement
=C2=A0 . draft-ietf-ipwave-vehicular-networki= ng-02 (to be submitted before the submission due)
=C2=A0 . = 20 min

Also, I would like to request a 30-min slot= to present rechartering and work items and discuss them.
I will = merge the last IPWAVE mailing list discussion and add some suggested items = for rechartering.

Thanks.

Best Regards,
Paul



On Sat, Mar 3, 2018 a= t 1:25 AM, Carlos Jes=C3=BAs Bernardos Cano <cjbc@it.uc3m.es> wrote:
Hi,

We have not received any slot request to related to rechartering. If we
don't receive any request. Does this mean that there is no interest on<= br> rechartering?

Please send your agenda requests by this Sunday EOD.

Thanks!

Carlos

On Wed, 2018-02-21 at 18:10 +0100, Carlos Jes=C3=BAs Bernardos Cano wrote:<= br> > 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<= br> > to best organize this discussion.
>
> Thanks,
>
> Carlos & Russ

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



--
=
=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon= (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software
Su= ngkyunkwan University
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com,=C2= =A0pauljeong@skku.edu
Personal Homepage: http= ://iotlab.skku.edu/people-jaehoon-jeong.php
=
--001a113eba72ce1f540566708ba2-- From nobody Fri Mar 2 08:34: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 81C5612D77C for ; Fri, 2 Mar 2018 08:34:50 -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 OMyLhGUp0ua6 for ; Fri, 2 Mar 2018 08:34:49 -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 6A8DA126E01 for ; Fri, 2 Mar 2018 08:34:49 -0800 (PST) Received: from resomta-po-04v.sys.comcast.net ([96.114.154.228]) by resqmta-po-03v.sys.comcast.net with ESMTP id rndDegDkNJ6DCrndxegcFL; Fri, 02 Mar 2018 16:34:49 +0000 Received: from [172.22.228.216] ([162.210.130.3]) by resomta-po-04v.sys.comcast.net with SMTP id rnbneaIzBWg49rnbpeNjIW; Fri, 02 Mar 2018 16:32:47 +0000 From: Tony Li Message-Id: <97A166DE-DBCD-4C08-9F4F-4C88FABC3E7A@tony.li> Content-Type: multipart/alternative; boundary="Apple-Mail=_5039BB7D-AC1F-4B42-B12F-C00948879659" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Fri, 2 Mar 2018 08:32:34 -0800 In-Reply-To: <1520007912.3735.43.camel@it.uc3m.es> Cc: its , Russ Housley To: cjbc@it.uc3m.es References: <1519233010.3516.75.camel@it.uc3m.es> <1520007912.3735.43.camel@it.uc3m.es> X-Mailer: Apple Mail (2.3445.5.20) X-CMAE-Envelope: MS4wfH1qKQGrQurySiGl/J+DbMCkuHPwqtKPJhgOC8y3L3PdA8kn+57b8hxVaQSpWRLaWl1VtjwtcYuhaWua0Pigt6fX8FSPtZm7S5YxQ64OxKEZ2RBZ83FD 3SRSWoR8VRcXs9D0PD0WSi0Dp4eUfANJ0gsmrxjsH7HMo/bkM5GyVWsWirGNViwP906VLgDKdGf/4YD7/VgmiQoUy6ZRxntmQic= Archived-At: Subject: Re: [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: Fri, 02 Mar 2018 16:34:50 -0000 --Apple-Mail=_5039BB7D-AC1F-4B42-B12F-C00948879659 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Does this mean that there is no interest on > rechartering? I have no interest in rechartering. Let=E2=80=99s make this a = one-and-done. Tony --Apple-Mail=_5039BB7D-AC1F-4B42-B12F-C00948879659 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Does this mean that there is no interest on
rechartering?


I have = no interest in rechartering.  Let=E2=80=99s make this a = one-and-done.

Tony

= --Apple-Mail=_5039BB7D-AC1F-4B42-B12F-C00948879659-- From nobody Fri Mar 2 08:37: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 07099128C0A for ; Fri, 2 Mar 2018 08:37:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4Kdfha2WVJL for ; Fri, 2 Mar 2018 08:37:08 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B500312D779 for ; Fri, 2 Mar 2018 08:37:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8725; q=dns/txt; s=iport; t=1520008628; x=1521218228; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2JxEjMsSqjebArcczr3f7xX8DgIxVdoGDBe+XAt9r54=; b=ipt8u2cW3kIxuElnCoxfJ93PXKTIWT2acXAA+v5xwKFiVSgFotP2aG7o Ygpa3HZi+tnAJIIw9Wb+gQZaT4ThKpVog6n038UVt/teoDigPQ/8XS2lo roTm5ikL/iR/0vRrZVnuYn4NGpnFl8nuvb8VZf1H3Drx6AHhIxyqmDZM4 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D4AABUfZla/4gNJK1DGhkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGCWnZmcCgKjW2NeYICgRaHIYdshSAUggEKGAEKgVyBW4F?= =?us-ascii?q?WAoJhITQYAQIBAQEBAQECayeFIwEBAQQBARZWCw4CAgEIEQMBAgEnBxYLBgs?= =?us-ascii?q?UCQgCBAENBYQ3TAMVEDKrUYclDYEwgisFhSeCKYFXhROBR4EjRAEBAYE9AQ8?= =?us-ascii?q?DAT+FTQSNdzyDNoFYhmwxCQKGUIZvgzyBZ06DZ4hciUoyOYZzAhEZAYEtAQ4?= =?us-ascii?q?QOCY7cXAVOoJDCYFvRYILdwGKDIEigRgBAQE?= X-IronPort-AV: E=Sophos;i="5.47,413,1515456000"; d="scan'208,217";a="360972873" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Mar 2018 16:36:59 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w22GaxNC018094 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 2 Mar 2018 16:36:59 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 2 Mar 2018 10:36:58 -0600 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1320.000; Fri, 2 Mar 2018 10:36:58 -0600 From: "Sri Gundavelli (sgundave)" To: "Mr. Jaehoon Paul Jeong" , "CARLOS JESUS BERNARDOS CANO" CC: Chris Shen , Russ Housley , "its@ietf.org" Thread-Topic: [ipwave] IETF 101: IPWAVE agenda requests Thread-Index: AQHTskSueDpXiGzxeEWHsWbe6ocFHw== Date: Fri, 2 Mar 2018 16:36:58 +0000 Message-ID: References: <1519233010.3516.75.camel@it.uc3m.es> <1520007912.3735.43.camel@it.uc3m.es> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.188.60] Content-Type: multipart/alternative; boundary="_000_D6BEBD442AB2C2sgundaveciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [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: Fri, 02 Mar 2018 16:37:11 -0000 --_000_D6BEBD442AB2C2sgundaveciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Carlos & Russ, I need a slot to present a new proposal around RSU manageability. Name: IP Interfaces for RSU Manageability Time: 10 to 15 mins. Sri From: its > on behalf of = "Mr. Jaehoon Paul Jeong" > Date: Friday, March 2, 2018 at 8:33 AM To: CARLOS JESUS BERNARDOS CANO > Cc: Chris Shen >, Russ Ho= usley >, "Mr. Jaehoon Pau= l Jeong" >, "its@ietf= .org" > Subject: Re: [ipwave] IETF 101: IPWAVE agenda requests Hi Carlos and Russ, I would like to present our WG document: - IP-based Vehicular Networking: Use Cases, Survey and Problem Statement . draft-ietf-ipwave-vehicular-networking-02 (to be submitted before the s= ubmission due) . 20 min Also, I would like to request a 30-min slot to present rechartering and wor= k items and discuss them. I will merge the last IPWAVE mailing list discussion and add some suggested= items for rechartering. Thanks. Best Regards, Paul On Sat, Mar 3, 2018 at 1:25 AM, Carlos Jes=FAs Bernardos Cano > wrote: Hi, We have not received any slot request to related to rechartering. If we don't receive any request. Does this mean that there is no interest on rechartering? Please send your agenda requests by this Sunday EOD. Thanks! Carlos On Wed, 2018-02-21 at 18:10 +0100, Carlos Jes=FAs Bernardos Cano wrote: > 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 _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, pauljeong@skk= u.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php --_000_D6BEBD442AB2C2sgundaveciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Carlos & Russ,

I need a slot to present a new proposal around RSU manageability. = ;

Name: IP Interfaces for RSU Manageability
Time: 10 to 15 mins.

Sri


From: its <its-bounces@ietf.org> on behalf of "Mr. Jaeh= oon Paul Jeong" <jaehoon.= paul@gmail.com>
Date: Friday, March 2, 2018 at 8:33= AM
To: CARLOS JESUS BERNARDOS CANO <= ;cjbc@it.uc3m.es>
Cc: Chris Shen <shenyiwen7@gmail.com>, Russ Housley <housley@vigilsec.com>, "Mr.= Jaehoon Paul Jeong" <jae= hoon.paul@gmail.com>, "its@ietf.org" <its@ietf.org>
Subject: Re: [ipwave] IETF 101: IPW= AVE agenda requests

Hi Carlos and Russ,
I would like to present our WG document:
- IP-based Vehicular Networking: Use Cases, Survey and Problem Stateme= nt
  . draft-ietf-ipwave-vehicular-networking-02 (to be submitted be= fore the submission due)
  . 20 min

Also, I would like to request a 30-min slot to present rechartering an= d work items and discuss them.
I will merge the last IPWAVE mailing list discussion and add some sugg= ested items for rechartering.

Thanks.

Best Regards,
Paul



On Sat, Mar 3, 2018 at 1:25 AM, Carlos Jes=FAs B= ernardos Cano <= cjbc@it.uc3m.es> wrote:
Hi,

We have not received any slot request to related to rechartering. If we
don't receive any request. Does this mean that there is no interest on
rechartering?

Please send your agenda requests by this Sunday EOD.

Thanks!

Carlos

On Wed, 2018-02-21 at 18:10 +0100, Carlos Jes=FAs Bernardos Cano wrote:=
> 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<= br> > to best organize this discussion.
>
> Thanks,
>
> Carlos & Russ

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



--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: jaehoon.= paul@gmail.com, pauljeong@skku.edu
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
 --_000_D6BEBD442AB2C2sgundaveciscocom_-- From nobody Fri Mar 2 09:02: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 4B2EB12D875 for ; Fri, 2 Mar 2018 09:02:50 -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 piIei4InAuP4 for ; Fri, 2 Mar 2018 09:02:46 -0800 (PST) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4783A12D810 for ; Fri, 2 Mar 2018 09:02:46 -0800 (PST) Received: by mail-pf0-x22c.google.com with SMTP id d26so4246812pfn.5 for ; Fri, 02 Mar 2018 09:02:46 -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=EsyWLsU434f0oucq+TxUWEILqWeyIxXzeqge+NWapOM=; b=OB14PHaKAcTSUNETuOgpmFkc9SvSo8I0Kw+Zm0MduQk9fiCnmiC90n9Kp7APnYWRa9 pSIKWq6uhmg5c02vAtm6fl254NeK/P9Q9J3xZfcFbBzraYWrndnVgLmBEd4uoKd5zean i6Kcl6m1FfQMOvXu7GWwl7VJcSdDtKPt1dfXo= 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=EsyWLsU434f0oucq+TxUWEILqWeyIxXzeqge+NWapOM=; b=T09qyQ3QXWWCtZuRzQD4ezLX6GdgQzmaXVxuWXv0lDazu30QWWu3LkuFRmwuwN0dk/ Y/cGHQjkpzBwIWAOs55XiapG+VzPAoTyuiC9ZrPId87LOIvV4P70oCb/oQreBPdCC7tD 4pQqhrxvp7BrqCHbPiRUXZKWZoR3IgwAm3MRLHW4/Q2THXKb2YogwoKXp+PFkMx2u2sD ZCeEulEH4yeSceCaDdfdYPG7izzKPg7EPHPLUHCiYNBM9r6T9IdmyUp4gQaCMQBCNr3O nHH8/xinIzt4OJztlrdmgERQVuNuu9EjWIjvUpPUanloDIM+wJhuUHCiLTwHPokDZFGS v2bA== X-Gm-Message-State: APf1xPCsW5ZQN1ahRMFIGVZM5IGHar6iuzI/v2hXgRAOHHkQADWoz6YW 4sqa0RuVf3JWZkdjRxcibyPFXKxSgCksiYA17QLwRw== X-Google-Smtp-Source: AG47ELsqwDK9vOFRiNL6kB95NsPuvlgRvD9VPNUZR23FJKx2F2pPGKwawlbvUxAbi1x4WSWOVCvBF7BWX5aFnp8yXwY= X-Received: by 10.99.185.84 with SMTP id v20mr5135753pgo.112.1520010165403; Fri, 02 Mar 2018 09:02:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.186.163 with HTTP; Fri, 2 Mar 2018 09:02:24 -0800 (PST) In-Reply-To: References: <00f801d3af1d$f20ce4c0$d626ae40$@gmail.com> <002b01d3af21$6e779a70$4b66cf50$@eurecom.fr> <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> <5ccad588-bcd8-d179-165b-7936a34220fb@gmail.com> <5a98213d.d138c80a.ababc.519f@mx.google.com> <5a982375.042bed0a.1271f.4afc@mx.google.com> <86a2077a-ea46-c99b-c048-60ab78f69ec3@gmail.com> From: William Whyte Date: Fri, 2 Mar 2018 12:02:24 -0500 Message-ID: To: Alexandre Petrescu Cc: "its@ietf.org" Content-Type: multipart/related; boundary="94eb2c1bb29cf795c1056670f1f8" 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: Fri, 02 Mar 2018 17:02:50 -0000 --94eb2c1bb29cf795c1056670f1f8 Content-Type: multipart/alternative; boundary="94eb2c1bb29cf795bf056670f1f7" --94eb2c1bb29cf795bf056670f1f7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable US implementations use QoSData with everything -- although it's not required by 802.11-OCB, as we discussed earlier, it *is* required for a "WAVE device", which all US devices are. Here's a Wireshark image from a contact showing the QoSData field: [image: Inline image 1] Cheers, William On Fri, Mar 2, 2018 at 11:28 AM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > > > Le 02/03/2018 =C3=A0 17:16, William Whyte a =C3=A9crit : > >> I've confirmed that the US implementations use QoSData, just to close >> that loop. >> > > Thanks. It's QoSData with IP, right? > > Alex > > >> Cheers, >> >> William >> >> >> On Thu, Mar 1, 2018 at 11:05 AM, Alexandre Petrescu < >> alexandre.petrescu@gmail.com > >> wrote: >> >> William, >> >> Le 01/03/2018 =C3=A0 16:59, William Whyte a =C3=A9crit : >> >> > I propose we rename 'OCB' into 'IP-OCB' in the draft. >> >> > 'IP-OCB' is an OCB mode that can be transport IP packets >> with .11 Data >> >> > headers or with .11 QoS Data headers. >> >> If it=E2=80=99s over OCB, then it needs to use QoSData. If you= =E2=80=99re doing >> Data, you=E2=80=99re not conformant to OCB. There can=E2=80=99t = be an OCB mode >> that transports packets with .11 Data, because OCB by definition >> uses QoSData. If the draft implies that you can do >> non-conformant OCB, that=E2=80=99s a serious defect in the draft= . >> >> Some implementations may not yet have implemented this, but >> that=E2=80=99s on those developers. >> >> >> For one second, allow me the benefit of the doubt about >> specifications that may not be implemented. >> >> I would like to know whether there is an implementation of IP over >> OCB with QoSData headers? Packet dump is sufficient, or any other >> kind of statement. >> >> I agree with you that many times it is good to write specification >> first and implementation after. >> >> Alex >> >> >> Cheers, >> >> William >> >> Sent from Mail > > for Windows = 10 >> >> *From: *Alexandre Petrescu > > >> *Sent: *Thursday, March 1, 2018 10:54 AM >> *To: *William Whyte > >; its@ietf.org >> = > >> *Subject: *Re: [ipwave] 802.11 Data vs 802.11 QoS Data in >> IPv6-over-802.11-OCB-implementations >> >> >> Le 01/03/2018 =C3=A0 16:50, William Whyte a =C3=A9crit : >> >> > >> (there are some packet dumps with IP packets transported >> with .11 Data >> >> > >> >> > headers in OCB mode at 5.9GHz, e.g. attached). >> >> > >> >> > My understanding is OCB mode requires QoSData, so those >> packets aren=E2=80=99t >> >> > conformant to the standard. >> >> I propose we rename 'OCB' into 'IP-OCB' in the draft. >> >> 'IP-OCB' is an OCB mode that can be transport IP packets with >> .11 Data >> >> headers or with .11 QoS Data headers. >> >> Alex >> >> > >> >> > Cheers, >> >> > >> >> > William >> >> > >> >> > Sent from Mail >> > > for >> >> > Windows 10 >> >> > >> >> > *From: *Alexandre Petrescu >> > > >> >> > *Sent: *Thursday, March 1, 2018 10:48 AM >> >> > *To: *its@ietf.org >> > >> >> > *Subject: *Re: [ipwave] 802.11 Data vs 802.11 QoS Data in >> >> > IPv6-over-802.11-OCB -implementations >> >> > >> >> > In a private discussion, this question came up: >> >> > >> >> > Is there a packet dump showing an IP packet transported with >> .11 QoSData >> >> > >> >> > headers in OCB mode at 5.9GHz. >> >> > >> >> > (there are some packet dumps with IP packets transported >> with .11 Data >> >> > >> >> > headers in OCB mode at 5.9GHz, e.g. attached). >> >> > >> >> > Alex >> >> > >> >> > Le 01/03/2018 =C3=A0 15:32, Alexandre Petrescu a =C3=A9crit = : >> >> > >> >> > > I received some feedback from programmer. >> >> > >> >> > > >> >> > >> >> > > Le 28/02/2018 =C3=A0 23:48, Abdussalam Baryun a =C3=A9cri= t : >> >> > >> >> > > [...] >> >> > >> >> > >> 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, >> >> > >> >> > > >> >> > >> >> > > Here is the QoS problem for IP over 802.11 OCB in >> implementations. >> >> > >> >> > > >> >> > >> >> > > In short, in open source on linux, we dont know how to >> send IP packets >> >> > >> >> > > transported as 802.11 QoSData, all IP packets are >> transported as 802.11 >> >> > >> >> > > Data instead. >> >> > >> >> > > >> >> > >> >> > > - if you ping -Q at 5.9GHz in OCB mode, the DSCP fields >> do get >> >> > >> >> > > set properly in IP headers of Echorequest, but there >> is no .11 QoSData >> >> > >> >> > > headers in packets. Normally, one expects the QoSData >> headers to be >> >> > >> >> > > present there when the DSCP (an IP field) is set. >> >> > >> >> > > >> >> > >> >> > > - if you want to modify kernel, and force always to use >> QoSData headers >> >> > >> >> > > on WiFi, including OCB at 5.9GHz, there is a >> net/mac80211/tx.c file >> >> > >> >> > > with a flag called wme_sta that you could set to >> true. But take care >> >> > >> >> > > that the C comments there say that it's not normal to >> use QoSData >> >> > >> >> > > headers in OCB mode, because a terminal sending >> QoSData has no >> >> > >> >> > > guarantee that receivers also use QoSData (the >> negotiation of QoS >> >> > >> >> > > capabilities are absent in OCB). >> >> > >> >> > > >> >> > >> >> > > As you can see, this can be long to try and fix. >> >> > >> >> > > >> >> > >> >> > > Until then I will propose to set QoS aside from >> IP-over-OCB at this time. >> >> > >> >> > > >> >> > >> >> > > Alex >> >> > >> >> > > >> >> > >> >> > > _______________________________________________ >> >> > >> >> > > its mailing list >> >> > >> >> > > its@ietf.org >> >> > >> >> > > https://www.ietf.org/mailman/listinfo/its >> >> >> > >> >> >> >> >> -- >> >> >> PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS: >> wwhyte@onboardsecurity.com >> > --=20 PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS: wwhyte@onboardsecurity.com --94eb2c1bb29cf795bf056670f1f7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
US implementations use QoSData with everything -- although= it's not required by 802.11-OCB, as we discussed earlier, it *is* requ= ired for a "WAVE device", which all US devices are.=C2=A0
Here's a Wireshark image from a contact showing the QoSData= field:

3D"Inli=

Chee= rs,

William

On Fri, Mar 2, 2018 at 11:28 AM, Alexa= ndre Petrescu <alexandre.petrescu@gmail.com> wrot= e:


Le 02/03/2018 =C3=A0 17:16, William Whyte a =C3=A9crit=C2=A0:
I've confirmed that the US implementations use QoSData, just to close t= hat loop.

 Thanks.=C2=A0 It's QoSData with IP, right?

Alex


Cheers,

William


On Thu, Mar 1, 2018 at 11:05 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com= <mailto:alexandre.petrescu@gmail.com>> wrote:

=C2=A0 =C2=A0 William,

=C2=A0 =C2=A0 Le 01/03/2018 =C3=A0 16:59, William Whyte a =C3=A9crit=C2=A0:=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0> I propose we rename 'OCB&#= 39; into 'IP-OCB' in the draft.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0> 'IP-OCB' is an OCB mod= e that can be transport IP packets
=C2=A0 =C2=A0 =C2=A0 =C2=A0 with .11 Data

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0> headers or with .11 QoS Data h= eaders.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 If it=E2=80=99s over OCB, then it needs to use = QoSData. If you=E2=80=99re doing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Data, you=E2=80=99re not conformant to OCB. The= re can=E2=80=99t be an OCB mode
=C2=A0 =C2=A0 =C2=A0 =C2=A0 that transports packets with .11 Data, because = OCB by definition
=C2=A0 =C2=A0 =C2=A0 =C2=A0 uses QoSData. If the draft implies that you can= do
=C2=A0 =C2=A0 =C2=A0 =C2=A0 non-conformant OCB, that=E2=80=99s a serious de= fect in the draft.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Some implementations may not yet have implement= ed this, but
=C2=A0 =C2=A0 =C2=A0 =C2=A0 that=E2=80=99s on those developers.


=C2=A0 =C2=A0 For one second, allow me the benefit of the doubt about
=C2=A0 =C2=A0 specifications that may not be implemented.

=C2=A0 =C2=A0 I would like to know whether there is an implementation of IP= over
=C2=A0 =C2=A0 OCB with QoSData headers?=C2=A0 Packet dump is sufficient, or= any other
=C2=A0 =C2=A0 kind of statement.

=C2=A0 =C2=A0 I agree with you that many times it is good to write specific= ation
=C2=A0 =C2=A0 first and implementation after.

=C2=A0 =C2=A0 Alex


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Cheers,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 William

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Sent from Mail <https= ://go.microsoft.com/fwlink/?LinkId=3D550986
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://go.microsoft= .com/fwlink/?LinkId=3D550986>> for Windows 10

=C2=A0 =C2=A0 =C2=A0 =C2=A0 *From: *Alexandre Petrescu <mailto:alexandre.petres= cu@gmail.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:alexandre.petrescu@gmail.com>>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *Sent: *Thursday, March 1, 2018 10:54 AM
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *To: *William Whyte <mailto:wwhyte@onboardsecurity= .com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:wwhyte@onboardsecurity.com>>; its@ietf.org
<= /div> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:its@ietf.org> <mailto:its@ietf.org <mailto:its@ietf.org>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *Subject: *Re: [ipwave] 802.11 Data vs 802.11 Q= oS Data in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6-over-802.11-OCB-implementations


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Le 01/03/2018 =C3=A0 16:50, William Whyte a =C3= =A9crit=C2=A0:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>=C2=A0 >> (there are some= packet dumps with IP packets transported
=C2=A0 =C2=A0 =C2=A0 =C2=A0 with .11 Data

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0> headers in OCB mode at 5.9GHz,= e.g. attached).

=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 understanding is OCB mode r= equires QoSData, so those
=C2=A0 =C2=A0 =C2=A0 =C2=A0 packets aren=E2=80=99t

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0> conformant to the standard.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 I propose we rename 'OCB' into 'IP-= OCB' in the draft.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 'IP-OCB' is an OCB mode that can be tra= nsport IP packets with
=C2=A0 =C2=A0 =C2=A0 =C2=A0 .11 Data

=C2=A0 =C2=A0 =C2=A0 =C2=A0 headers or with .11 QoS Data headers.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Alex

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0> Cheers,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0> William

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0> Sent from Mail
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://go.microsoft= .com/fwlink/?LinkId=3D550986
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://go.microsoft= .com/fwlink/?LinkId=3D550986>> for

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0> Windows 10

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0> *From: *Alexandre Petrescu
=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 =C2=A0=C2=A0> *Sent: *Thursday, March 1, 201= 8 10:48 AM

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0> *To: *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 =C2=A0=C2=A0> *Subject: *Re: [ipwave] 802.11= Data vs 802.11 QoS Data in

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0> IPv6-over-802.11-OCB -implemen= tations

=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 a private discussion, this = question came up:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0> Is there a packet dump showing= an IP packet transported with
=C2=A0 =C2=A0 =C2=A0 =C2=A0 .11 QoSData

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0> headers in OCB mode at 5.9GHz.=

=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 are some packet dumps w= ith IP packets transported
=C2=A0 =C2=A0 =C2=A0 =C2=A0 with .11 Data

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0> headers in OCB mode at 5.9GHz,= e.g. attached).

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0> Alex

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0> Le 01/03/2018 =C3=A0 15:32, Al= exandre Petrescu a =C3=A9crit=C2=A0:

=C2=A0 =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 received some fee= dback from programmer.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>=C2=A0 >

=C2=A0 =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 23:48, Abdussalam Baryun a =C3=A9crit=C2=A0:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>=C2=A0 > [...]

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>=C2=A0 >> ieee802.11ocb p= rotocol is already implemented/tested and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 it 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 >> interoperable, = but what is the problem, sorry maybe I
=C2=A0 =C2=A0 =C2=A0 =C2=A0 did not follow

=C2=A0 =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 discussion = well,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>=C2=A0 >

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>=C2=A0 > Here is the QoS pro= blem for IP over 802.11 OCB in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 implementations.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>=C2=A0 >

=C2=A0 =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 short, in open s= ource on linux, we dont know how to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 send IP packets

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>=C2=A0 > transported as 802.= 11 QoSData, all IP packets are
=C2=A0 =C2=A0 =C2=A0 =C2=A0 transported as 802.11

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>=C2=A0 > Data instead.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>=C2=A0 >

=C2=A0 =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 you ping -Q at= 5.9GHz in OCB mode, the DSCP fields
=C2=A0 =C2=A0 =C2=A0 =C2=A0 do get

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>=C2=A0 >=C2=A0 =C2=A0 set pr= operly in IP headers of Echorequest, but there
=C2=A0 =C2=A0 =C2=A0 =C2=A0 is no .11 QoSData

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>=C2=A0 >=C2=A0 =C2=A0 header= s in packets.=C2=A0 Normally, one expects the QoSData
=C2=A0 =C2=A0 =C2=A0 =C2=A0 headers to be

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>=C2=A0 >=C2=A0 =C2=A0 presen= t there when the DSCP (an IP field) is set.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>=C2=A0 >

=C2=A0 =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 you want to mo= dify kernel, and force always to use
=C2=A0 =C2=A0 =C2=A0 =C2=A0 QoSData headers

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>=C2=A0 >=C2=A0 =C2=A0 on WiF= i, including OCB at 5.9GHz, there is a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 net/mac80211/tx.c file

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>=C2=A0 >=C2=A0 =C2=A0 with a= flag called wme_sta that you could set to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 true.=C2=A0 But take care

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>=C2=A0 >=C2=A0 =C2=A0 that t= he C comments there say that it's not normal to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 use QoSData

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>=C2=A0 >=C2=A0 =C2=A0 header= s in OCB mode, because a terminal sending
=C2=A0 =C2=A0 =C2=A0 =C2=A0 QoSData has no

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>=C2=A0 >=C2=A0 =C2=A0 guaran= tee that receivers also use QoSData (the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 negotiation of QoS

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>=C2=A0 >=C2=A0 =C2=A0 capabi= lities are absent in OCB).

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>=C2=A0 >

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>=C2=A0 > As you can see, thi= s can be long to try and fix.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>=C2=A0 >

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>=C2=A0 > Until then I will p= ropose to set QoS aside from
=C2=A0 =C2=A0 =C2=A0 =C2=A0 IP-over-OCB at this time.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>=C2=A0 >

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>=C2=A0 > Alex

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>=C2=A0 >

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0>=C2=A0 > ___________________= ____________________________

=C2=A0 =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
=C2=A0 =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@ietf.org <mailto: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 > htt= ps://www.ietf.org/mailman/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 =C2=A0=C2=A0>




--


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



--


PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW AD= DRESS: wwhy= te@onboardsecurity.com
--94eb2c1bb29cf795bf056670f1f7-- --94eb2c1bb29cf795c1056670f1f8 Content-Type: image/png; name="image.png" Content-Disposition: inline; filename="image.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ii_161e7a6fc3f29cae iVBORw0KGgoAAAANSUhEUgAAAbMAAADsCAYAAAD+QkgRAAAgAElEQVR4Aey9d5Bn13Xn933v9345 dA4zPTkBg5wDCRKBARCz6FWVtNJqy3L5D8vSSqqSqmyXq1Z2laTdlbdcrvXKkpYuUVqKopiUSDCI IECQRBxgMIMwOfZ093TuX86/5/qc97uDniFIpPWSEPt2vX7v996N5957zj3nnnOu16hXw2QqJcLq yoqymbwSyaTKpZKy2az8wLNvCnuSF0bP6kl2+ZJikrhvhHckBFyXvtXK94fHW02+kW4DAhsQeAdD IHwbuN+T6u2O4vFAoJFGs6VUMqFmqy0/lJLJuCqVmnK5jBRK3jpc02i0lEolLgOc1+u2wzAMxRUL Ain01Wm3FcTjRtAy2YjQRal68hWq5/WsMH7JqvE2GnRZdTZ+/NeGAIPmrYbeusH1VvPYSLcBgQ0I vEMhYITsreP+0JO8AIoiVas1tVotDQ8NGjCuzLXZaCkWiykej6nZbBuhuxJqXhh2w2qlomwup7DX k+cFqpTLxpW1220lEgnJgxMz4ihPPVklQtkd4rfBmV0J1nfO70vM9tuoMuNhI2xAYAMCP40Q8CLC 8BaaDt6wS1Kn072UQ61WUyGbU7VaVS6X09LSkibGR1WvNwVN4hoZGVKvJ/nrqV6rWQ8haGury+HQ YCEM/FiYTqasjJjnu7IgnqE8I6I/5O7332/cIzi9A+Bgw9B4s9AzXpux9eZ+i/g2LjbuG3AAP2yM g5+acWC4Igilt3F5fqhEArFgGE9nQvHb88PBoZEwk83beMoXBsMLF2bDUqmCFNFCq9Vxj5fuwdpq SWPj4xoYGNbaWknxRELNdsuoVjKdMmp4iWTaCtyPJIu8dCty49x4z4uN+zsGDpdExCyR+v32Zu8b /b0x7jfm/U8p3uuL6y4RgkuU4o09IBaKxRQEgTrdlt3DZFKdZlOVSuXSdlez2dTg4KDq9bqJIlMp 6FJdo6PDl5Xjhb0w7HW7FgmFj8LggNbW1lQoFFSp1sU3eY6X6xOr9Vlcphiy/sPG8zsCAm9jz+yt juF3BFw2KrkBgQ0IvD4EkN29nWAETVI32sqCEfBiMYXtjulw9Ho9JZNJPfP000qn0xoaGjJatWnT hK5UAgmajYbQZkyl0woVmpxyZGREnW6o0PcUC1ImX4yUPVi9+/3NMloQylenr9n4dlq0kfbHBYGN PbMfF+Q3yt2AwD8FCDhG5620pader6tEMlCr0ZS6XSWgRamUSiurfYWPuDzP08WLF5XP542wsWdG aDQal2k0BlC9Rr1ukTx5trlWLJfUaXf1f/6H/6gbbrhRpsPooXUSqeH3FFhmfsiXZp+gvZXGbKT5 cUPg7RKzt7sw+3G3f6P8DQhsQODtQODtETPf94yYqRea6BCt+pdffln/5vd+Xxfn5ow763Y6xo0t LCwYnUJqWCyWFY/HL6t40On0jCsjAaqPvW5HXUSLsZhuvPFGvfueu23/rNGTAl/q9O/tUGo1pMF0 pMvY4gWSY99TAM1bFxrNruVNvkEQsy2lmC81Wz0FgS+eUWZBPXOgkDGOEy0VGFjixGK+2u2O0qlA S8tFjY4M0HYLtVpTuWxyXWk/+EgeyYSvSjWKS31SyVcr6b6T0inVdLtRGt4tLq1pbDRSGXV17nZD JeKe2h0JiwbqWqu3lUlHAHZlVGstZTMJAZ9YLGLJq9W6crm0/D6HTtxkMqZKpWGdRb40r7UOPtSD sn3fVzxaS4h0iURM7XZUV2DSakVaQbSv3ohg5tLG476VuVasqlDI2nOvG2kE9btcYd+eg20Qpy00 P7+iiYlIPl0uN5TPp1Qs1pTJZKzz6W/Kpj3Ajzyoo4MrEoR2O4I5z+RtFxWjne3QBqvrR9dP/c8q lesq5NMClgxg4EMgL8bORtiAwAYEXhsCbheBGcM8g8uBo0mnU6YJ6HDQa6d+dV67uUx+5MW904nm +Q9Ly3vKdPOV38zlbDZtZZPerMH61sqdbs9MxNhDW15eNiSBmNGPxbS4uGiajeW+pj3v0bSH+Llw GSqwVbbTtASZeVKt2VO7FyGOeieSMs4uSidONbS43LZGFUs1q3Cn0zFCBtKhCBAcFwgX5AaCBYk5 QgaBgSiAlEGIEDKQId8BmAMg3yBk5AUhI386odFoXyJkEJXVtYpA1NSHPElPoMF8d+ypI2QgTRdA jKSBiAIfbB5cHhAy4hKHOlM/8uQ37QLpUydbBGB8vla5RCwhZPwmkI4LxFyvt+xdudIwAtVuh8rn UgZHiBAd7cqiHRBKflMebQFOEECIOcSeurpA+6gbMDPiQtkx3+KSdnAgImTUORZjEdG0QVUu1639 jUbHYACRJEDIqE+93jFCVqu1NTCQEQujHqsbScVixYgn+RlMMHpM+FZX4MkihrLpb/qO9jJGeMcC CAkB/UtbGczUn/oRMpm03YFl4Iz4mVQRTbNvG/82ILABgR+EgJsizCcW08xN8Ax4rtlki+hHB0fs WESDl1x4I4SMuBCyaq1p+Ivf4L5ms/WGCKEri/t6ouXeX/nOf9VoFrq2jraZDQAsoG/bZKCsRCA9 9t1T+rf/x3/Uv/7f/0DPHzxsyDKXzejQoZeUSsa1uloyzVRyarc6ghnhWlhYRiSqJrJRSUEMQiYl 43ByfkS8mh3FY9Lzzx/SkSPHDelVqw37xr3b6Wlm5qKqlbKljQcxIyQgy26nreHBnIYGshosZNRs 1K0edGY6GbO6892IZLNj6RLxwLiaVMI3rjOZiKnVbFvcQi5lBCkR961N+WxS1UrV2gnxWl1ZVr1W V6lUVdgLRV2ymZTlD19FOcCCulEu7eRduVxTpxMql2FVEcHh9KmT1ul8n52dNyIErI8fPyXaTf3I k7KeeupZnTp5Qux1AuNsJmkwO3vmtFaWV62tKytFaw/5Ac+lxRW748WFhQGElIEMF97rSIVcMsoL 7dVqU9l0oHazo0Tg23fKIR/eN+ttpZNxi39xfsnGBuXQxkwqsPf8XlpcvgwWpKc8B4dOu2VxmSzU ifaiS0Rb6S+kAMCoUqmb8f48ZTGoWVg5ug0X2V8pbtw3YLExBn5wDIBrgAuLaOYUC1TwFziZ+fp6 MANfgaeYn88+87Q+91ef1xe+8GV9+Utf1PnzM6+bnvxzmaSy6bjW1oo6cOCg0qmEwHkzM7OOLv3Q OwTrSqJF5Nd61xdYRXldYtioQRhZZpdrHXUUCI9XswvS5774Nzpx6rxSyZzuuutWQ0RPP/Gkjrx0 RIcOHVQ2ldXNt92sidEJNdoNLS80tbiyqG88/A194KEPaHhgWMNjw2pUG/rGt76hvbv2ave+3Qo7 oTphR6dPnDYPWb023ElLMUHZ6/raVx5WfjCv6bPTuu7G69Ss1ZUbyCkRS2h+aV6tektbtm9Rea2s YqWolcUVxRIxbdm0xdKVVkvaun1Ky4urOjt9VlfvvVrZfFprKyVVvJ74PjA8oOWFZW3buU0XZy4q k89ofGRYp0+f1PDNt2h6+pwOHnhOYdjV3IU5FYYKqpaq2r5ruzaNb1KQDFQpVsxDyvS5kr77xHe1 b/c+7blqj9VratuUGtWavv71h3XjdTfqqv17NXdhRo8++ojGhkcMXl/7ytf0yZ/7pM6dPqenDzyt 66+5Xvuv22/wrTaq6jQ7tuk5c35aTz7zpH7lX/6y/u4rX9WxV45ZOe+///3GxtcqDWVyKXGnvFtv ulWnzp7SbTffZvCJKaa1tRWNjIyZqHd4cESdXlultbKmtm5WcXVN45OjKhermpuf1ejwmIZHB/Xv /s2/1Xvve4+2bdmuLdumtLK0rEQ6obXlNdVbdfmhr3379ymdiES/tHetvKZeu6eTZ05qcmxS6Vxa 7UZbu/buUnGlqK66Nm64p+Iplaolgz/9PTs9q3gqbvEnJkZt17bnsXvrGSGF0LLQ2rhvwGFjHPzg PEgGuLmQukhC/FDdVluJbNI8EyKJe715k4gFQuKWigeqVErat3uPtu7YqkPPH9L582e1c9vUj5x/ 7Wbb8CL4GHy5eHFOn/70QQ0VhnTvA/f/UCL2wz78MOJG/OAybmx9Dn0xYy4TiIUwErtPffov9NIr x9TtQdwSyuThiKTx0WE9dnFWd9x1u5YXV3TwuWe1eXJK5y+ckw/SLK2a55DzZ0/rbw98SZObJwTy nJuZViGT1dzFaQ3kB7W0sqhOq6tP/rOfVSqR1h/++39nHEI2nzGZ53h3TDffdIMWlua1dHFeBw89 r72792n24owyqay8mAzp1hpVZdM5lSpF/dV//oxuu+NWq8fHf/ZjWl1Z0ouHDmplYdHS3ffe+/XU M09q+twFjY6PKBlP6bnnn7Z2uN+VWlkxRKbq6qYbr9fq8qIuzs3ozNkT2rNrr44ffUUvvXBI84sX dfrkGYNDzAtUr5b1+HceVam8ohfhXG2FktOxE0eV8GMqDGS0beuUbrnpBg0O5BWLD9jvkaEBTXuh 3v/AfVaPxfk5tVsNddtNjY2O6ezpk1bPwy88r4WHfkZTmyb05He/p6GBm/V//4f/S+1uy+AyPDqk d999j7ZvndLQYEGltRV97eGvCPgA53q9qjvvvFvHjx/VOIuPVl1jI+PW/kqpqvxAToEft/pumtis f/Evf8m475XlRR175YhGxoYVi8VVrpZULdcUJGLWb7RrdXlN5584pxPHTor+gxiePX9GS+ObFE8G mpmeVeq7SU2Ob1Kz3bD+Bc7pJPtwoSh/bGLU+tGPZczmhF1OJiCLnF4sYcQ3GU9c4gaZmKzDNu4b cNgYB9E8QFozPDKkWNzT3Py8nnnqWRXLayrkBrRtx1bdctPNP3K+2H5/p20Kgb56hkc2jY/p/GBB 3bDTn289efLF9yvvSOtC9TQ+NmL4Bfz5v/yvn9Wv/4//yiQ8xjetpzuv8ewI2JXc2JW/L+PMXs0H dEDwhT4BhOx7Tx7RE089o27PVzyR1vnpGa0sS8l8T+1mSzfeeL3effe79Pjjj5s9wPe+97jGx8fN Ldbq8opuueUW27zHaeSObdtNc+XqfVeZk8nTp89ryx1TOnr0Fe3cuVNf+ft/0G233aZEENeuHTst D4zmVldXjYguLy7Z5h/Ct+HhQe3evdNMCtjYfOGFFyyPXq+jbDqjrVunNDYyqvn5eb3w/EGdPAl7 O2N1GMgXjDtp1OrK57M6efyErrnmGoVdX3v37jYIrKys6ML5ad1+6222eYoBHwiUdlAG5eNuJTuU UaGQsxXP6PCIvRsZGtZdd9ypw4cPa2lpQbt379b+/VcZZwdXNLVpsz796U/bnhlahcAonU7q3Jmz mpub0anvndIDDzygyfEJzc3MWjuOHTtqLHaY7em2W241Loy073733dZenHPu30UZ0YYlCjbddkeP P/6YMqm0cpmsbpi6TseOHdPaGuLXmHZu32EKOl45VLlcNMWOqldRaa1oxorvvec9YuO1Vqnqlltu spXazp3brQ8wbizk8lY3XM+w1xjzfDUaNR0/ekxbt2412xDqQ3/VahXtGN9hdWETlz4DnuxnhrYB 3NXY8Jg2T26y/PlOfsj7GfidbhSvE/b3KOMJe09n8X3jvgGHjXHw6jwAP2ErzH7+xNi4Pv7xj0Yf 1/3/UfAyPQg/ZviEeXrw4HN65ZWXhMupG264zuQiEe/HuIMHvPwOfsCpBw7sq5WSHnnkH/Unf/xH +vKX/tYWw9t3gmddDdZVyj2Cx67YHAeXXEnIrNxuoxf6Cc/2o5KZtNBqNOGqH9PXH3tcd959hxX1 7e8f15FjZ7VWaqvTjen8+Vn9T7/1K7phh+S1GkZMBoeGrAoXpqc1OjpqxOuzn/2s2Q184hOfMO8i MxcuGIIslUoaHh62OHNzcwZstONId+7cOVMImNy0SefOnrV3ZAxgQIAAGOKG3QEG3pS7trpqef3D P/yD7rnnHkPIwyMjmj5/XtjNQYTo0KNHj1p6NDXZ1CRP3oOIDx48qB07dmhyctJ8VSIsfuqpp/TI I4/oV37lVwyhT09P6/bbbzejcgfkUrFo9UVxodh/jjSG0tZ23lE+9hMORqid0n6QP9bs1GVkdFRz s7PatHmzwfHM6dPasmWLwe25Awd0/fXX68KFC9q1e7eZUwBD4IW2D3Wlg4El8Nm2fbtq1aoy2ayW l5aMmEOoXZ3xxwm8l+YXNDY5qV67bflY+Vu2KOx0jHiTpxcEKq+tWfwYWh/9wbWwMG8LF9pFPNqP P7V8oWD1n52ZsT6in+g36sudfmGCARNgQ1+iAEKg7qZV2+tZnbEv4Td9dPPNN1t6nGBvhA0IbEDg 9SHgCBn4hWDO5PvJzBdv//0Py4n0pGX+saAFrzGHwVkwK/lCDnlJnyD94L3b6SoWxLS0uKTh4SH5 MfinKN5acU25gRHj55C6OG1GcO4H3/f+SGGvT8z+3099ynDJ2NiY4Wfu4OwEm3n94HUbndBPxCwj DKeNmFGg7+ubj31Ht9x2h/A1jCJLsSSlMlHKTEpq1KRBtBSDjjXYedt3nve9MDQOBbsAAOIHgSFm Q7KZjCEuRFsgMlSunXlAdKyM1EWjsNFQto8cncNjagDSJE+swp2jZN6jGMEqfj3Cg9gUBgaM08SJ MiqdkQNltFwiIgAypixUV9OZjDldpgPhBiF4EDnP900ZwSFrVieZTM7cf8E9EJ984WBw3NzttqxD gCuBwdNsdQzpg/hB5nG8RsO1+L61KZfPm0gNIj06Nmbp+Ecb6DwIV71WszpiH0g+IHsC9eMd5dkg NFOLbkTsLuWkiMhlMla3IJawgQlsIXwIU+u1qoIgbn1FX9YrFaXTWTPXaFSrSmWj9tgqBzkzphO0 K540+MFlUScIE+2DYIedtlKWv2dwMk3QOAaR0U4tcWkLfcAzbaWP8UoDfJhIjCO+WVv7BNW1fV3z froezdH3uib3nYKve9PfVbz8zau/nBTm1TcbT/80IeDws7u/EWLmIGG4OQgiZ/QQtw46DR0lrziG xcV3d+Ixf5mn4FZwJMSQ334sLgSVCCdfj5h96j/9JyNmEFCYDYgZuAFJlAsBm4I0ysRRIJR43DwY +0FcXq8rv9MRRtKFhFQYjhjCxaWacqmMMO9CbJRORBSOtCHer9iMC6JCJiY3q1ltKpnq24Khwefh id9TkIgrm4ipVq8YMbMVQKurmKm+gTsTyqYT6lU78jNQYOzNGmq127b/BFDC0FM2V+gDqWP7Zp0e Kiu+ur3ITVdhIGfiqXq9oVyuIM+LEC3q4iiIe34kwkokvT4SjtTlQM6jYxMaGh6V56P52Fa+MGgI F24kncmpVG8plY7O1XGrnngyOjYn5scVSyVMzEdHQsyxdmffhxI89nv8yFA95gdWBm2kLMqFiFIO SD6Zyljn03GUy8oIQk7fdVt9DVEWBagH9rqqFNdUGBqy/FEBNE4rCIwwZXK5SC0whAhJ8URW8QQ2 ITU7YiGVCVQql1RIDNopCulcQbVqU4mEbwTJJkEMbdWG4jFfKOvEEym12j3rO5+FCWYLiYR6nZaS yUTE7QNtOK84ZxZ1Ve9b8Me8mCqtlo21TCqjVqOmDiJutChpsOcpUxjUWq0SLULQrI3FzXtA2OlZ vwALFyB8TBY4T4ij4xzddyYhiyf680rDSxfnnXK3pUBfq9PqzOC6RNAisQ8rYV67EC0fol/sdJhf Tvfxinj8jNbRLsLG/Z0KAfAZwd1Z/L7REAsiHOfS8Dt658bYa+fk0rmvcGnR0ptxFWmxrxtyFg3i x2VqlC7hG7j7NvDd4HcOg/sJUdvPZwJlE1KtXDNNmFg31NRoRgF7F+2aUGFvdtuGNDCM9TzUubvq YJTGLMBeKpO0u2XbkxKZuH0rl6u2amQfhGAUG6xKaPWnnC/5iUBhC00cjGZTtk9EYx2lx3aJEBnU JgyR8TuGATdWeYYPPeVzeRN18Rv1VPceDgsuAE6JfEFy5E2Aq3B5kD/GfCBH3hMgZJRe7tuNFYvV iCC2oepRHhA5EwWaC5aI8JCm0WpqZS0Sj5IXKw0XqA/cCWVTL7PD6vWMwBEH5A28IXgg7qAvpjOC 6nlGyHDYSaiWSiYqbMLRQcgInmfExouxHxV1Fe0LjcyGSqQC1RtVtZoNi04ZwNOS9icBzWs3I04K Ihz6MTVaEaHue5yxBUkPYhvzVCutWT2AXSIRtzZAyLphV7lMztqxuLwoCFqlVlE+m7dtZRAuiw7i JAJszQL7zSqP9gIL9i0J9A9izfWEjPduvNCvEDP6mOsdH/rTZD2x+lFt6ke/tLtxWdx1WMXFW393 z5el2fjxUw4BCOJbvf7Lgu51STMW3IRCPqNkIm4iPH47rsH3fMVjrJ/9SFzFUxyOJ+JuQgiVGclG d+y4CJGtUE+VarR3wwoahF8qldWqNyW8YGDojHwTDxvs65n81JIbJxbzI4/LiBXh6kCSrXbL6hZZ V2BknNRaMdqrWV5Z1oCJGzHkflXWCqEAWUNMqAfIkd/kxzfeueAIDuJEI4jO1omz4CRTJKE+pC2u rBgn0m40TDwJQoUzcwEFl6HBoUsElvekc3Vx8XhHAPnCkUHcCLQZggeHh556rVZXrdFUA1s+z5cf T9i77MCgeVBRLBCeTZaXV+w7LsvYfkJyhw0f9WetxJ0+pY2UwYLHvJz0l1SdTlOtZt24eAhqIpVR tVxRom8w3Wpj0M0YadqqgQVOt9bsizFZdCSt/6uVurqtjhLCsWhX2XhSmzAVYPXY89Wo1FRZK0W/ Q8/uuKDx8TyA3lTPM7EysGDvkH5ifxQixwLF9R3w4xvvCfQvhBuC904PJllBuuK5q2eLK2YtK9/o YrXSv4zXxU6QORsdxnslDH4U0YryjRY/PyrelXlu/N6AwP/fEHhdYoYFN14ZTp85r8MvvmT1QYzD 6tcFVs6slkEehNWlFZ05c0ates04nFq5ZMStUirKC/Cc0VWrE2kQ5rM5sTqH20EZwA9iSsDJGQGT YiB/sCvSM4W2qm61ML5NqNvt6MCB57WyXLJyEgk8aKSUy+VNRbSLSwl5GhgYNCLZxZat77Gi0waJ R+wZhNlxXxAKLrhEQ+T9VT2ECKTouDI4AfB8u4U1e0f5bMrWJ8iIm/WGMtm0BoaHjROJp1JGGCAT 7K1hPNxsNtRuN9ULe9ZuygPZwjmAeMlzdnb20r4RsAEBIyumrhA2iF7Y86wOiIrY88pk8pbHyy++ Yu1Ip7K2p9hstM2hdKVcM0WThYuLlr5WDc2gkn5rQ4UsePJCDMkjYthqNlWtlSPxlRfZ/83Ozuji zIwy+QG1a81IYcZxvF0Ms3vK5ZK29+ohcqYv/LgtVKg7htKFXFpJjkzvSr1mW41ynU5WrVhVLpOx K88mrb2r2D2AqMGGmOGnb/0Bgad/HBEDLhAsYEl/QZQhXPSnI2g00y0K+o1+h94Yw+wjdhR60cG5 jkuL7m7VzEoEgmbeEF699+cW88sRqncoIDaq/VMOgdclZrhDAgEcOHBAR44c0ZEjx/Stb33LtOpQ jqjVG/0zz/yImHnS0WOv6MCBZ7S6uqzp2Wk98cT3NDt7QajrN1t1Ey1GkircNNX0j//4j6YujxYL 4rVSpaplvGfAFMQVPZuuRmhcF0Sl0+3ohYOHTXsPVftSqdIXNUXcGDxGz4iZr4PPH9Jjjz6uU6fO WBwnlkTt/oUXDuvJJ5804sVY4IgB3jtiQVkgRu4gRep3+vRpM0Eorq1pfm5GaXMw1tPiwoKpwKNx ODs9rbXlZU2fPavS6qqJv1DKgIDBuWWSCeXSGX32M3+pl156Sd/97ncNvmj8QcQwcYi4v4jYoVH5 yiuvmIYfyiEQP8wN4GYRvRLYr4Tbmpud1+c//0UdPvSSKpWa2q2uHnnkUXXbEJiCeh0UTgIdP37S 3psCa8xXpVgyrcXSatGMvOmAVCqjRCKtwgCLFzibrqq1kp59+ml97rOfU7tSV73SVLVY0+pyWaVi Td/+9qPWT6vLpcjvFi7KMlmp2TbO7+knn9HM9JyWF9f04sGXdPjgYXF2XqvRVqvasnqeOnrKRMux WKCZszM6dPCwluYQJWLpGW06evRvKIPLV77yFSPO3CFSwOjLX/6ywZL+gOBB3CB06xcO7+z5DyHr 2SKPhR5P0V9Eq8xBeN8PjiNU6Nu4y8aMcXARIXsjsIhKtLXEG4m+EWcDAv/VIPCqzOuHFMkKOkjH jdhcc83VplWG9+Kvf/3rOnf+gn7+5/+5du/ZYwokJgVkHyPmqdmsW9znnntOJ04dV6lS1gsvvqCr rrtaO/I7FY8FpgWI7dOeXbv1ne98RxMTm/Tod76to8dPKpvNa+euXfJNA6at++67T8ODkVYkGnAg btTur7r6Os1cmNOx40eMo7n33ns1OTluXAwiRrwrz83N6777HjAV8KeeekZ/9Ed/rO3bdqrVblga bMaeeOIJW7mfPXvWkB4EBQL2O7/zOwYZECGB1T3q/adOnTKRJV5PhoYHtHfvXv3Nl/5W73rXu3Rw dVk3XX+T2bQBKzi/1WJRH/vYx7Rj13ZD6JGIpmdq/pgivPjii6al8+1vf9vK4B2LCOpBQEUdFXZM A+DQEJd+85vf1L/6td8wUSNxINJBPKYdO3fq6quv1i233Kbf/u3f1r59+8wM4I//+E9N/EY+BN+L 6+y5i2rWm+p2yqrXV5TNpoxg+15S27bvFlzV7XfepnQGItBWL+xoZGRU+6++RpNjW3T29LQe+853 tWf/1Zqem9UANn2LC3r4KzMq5HL62Y/8DEJEtEGkREqdas3G0qmz543gtCo148C+//j3bF8NhY78 YEHtRkv0xcLcvGrNunF058+f17VXX6Prb7rBmAwMv2OJQNdee60wyYALI84f/uEfmuYjoseHH37Y CBjmFNddh11MJK6lH1ksvPMDIwkSc/m6NDqyyTP/qrTxVbd1r7YYoob/1fXh8lzWf4me+U5pBO5u M7//auO2AYEfGwReb+xecpJ71VVXGcIGkVb4S9gAACAASURBVCJiRNTFCheEjzcQQrRX4xkiAfkj mkL1fuu2LaYlt337dhMHsZlv08/EPqG2bt2uc+emtWlqs+LJpHmSwHuFn/B18vQJI4RdNPI8fEUm DQmhKTc4MGzcDJxZo6+A4fZDIoj6RhQHB4f1xBNP6cSJUzr0wotC9AZXCUGAE0N0h33W8ePHTTyK oS/2Xbt27TIESTtpN1wTK3vuqIheuHDePILs2rFDLx46pC2bJoWbqUI2p6efftoIJXtswMJxBiBR novFFZOeUjaECkQMTMmbfTCMxomLLRrpN2/eLAgjxI32IoacmprSWqmoVqct4IOIFtFqo9lSJpfV 2fPnNLV1i8EVZRMWFMC43e1o+84d9vv973vI1O7Zb8tlCxoZHNGm8c0aH96s8lpdiXhWqO9HHFGk HANsY7GkJie2GOdHvakb9WUhMzRUUC6X1eLSvGKInhMpNdZKpjVXrzc1NjZh7bn2muuVzQ9o5+7d andDTW7erKuvuU7jk5PatWefao2GzpybVqfX06aprfZ7ebWodn/vK7J5k3G2d911l6KFzKQRbEwp 4K7hshFB0g/c2UsDdvTpP40Q+Vyw/rlsnyw6ecFxZFcSLaNhfULGbHQXnF1EpthDvfxy7/H04J7/ acBwoxX/FCDwupzZ0GDOZOnsk504cUL79+7TBz7wAY2NjejoK8c0NjFpGpQwLux/sJEEAjl77rR2 79upW2+7Rdt37jTuJJXJmC1UvRV5208nUrayO/Ds84aY4TpASO+9715DREEyoZ/54IPqdttKgRAb dWVSKbNp4jA39paeeeYZ3XnnnXrPPfeqWIoIVLMZ7SdhbkCAAHFGDkTgoZ/5oBGHo0eO21HdDz30 QeN24FYQR8Fhgej2799vdSA9SJp32DnBMUFsIDLl0poeeOB+rSwt6Kq9u40zmhifNFEsdlk333qr +Vh893veo4WFJe3cvcu4LQguF+Hv/u7vTPT5kY98xIi0I2IgX3fsAQSOhQCis4mJCeM+QMwoO0AM sbUAN0eiW09hGBiHCKH++Mc/bvW2+pbLlgdiXX7/1m/9mpp1FiHYDF6tWNhSIh5TYXSTOtVQX/vG t3T1/usUT/iqt2vmJDidSqkMl42T6VZPn/joR82u7arrrtFquaRyo6JNU5PmNcVHDEjFQikFN9h1 ngBquvGWWzU8Nqprr7nGFgo33nqbjRsWEPQXgTF16513GaeIbQnjij6Ipzn2RoqnfDVbbVP+wKMJ sKRdv/7rv25iXTixv/iLv7C+xLMMgcWX40yBoeO47eM78F9EjyBoBMgMSh9XsFv9dkHQjEvmt4kG IGKR34YrV7WvlYN7R9Ir4/eL2LhtQODHBgEvZAMFERXnlMUDxeMZtTttEy994xvfMA6BIwMWF1fM 0eTenTussrgmyWYLRsg4iqVRr2poOBJflddWonPKAl+cHApWQunDFDJigaq1hlrdjgbzBSW9mC7O zgkVcTbpzWg4xLNzz3w64tvRqagHnm/aa6y4EVPCDYyOT5hbKXwEwj25s88Q0fGbuOTFXheIC2SI o2A4BJA/oiZHWGgY+y2kc+m5s5onHxAlBBSiQppataxNm8fUrleFTRmafclsTufPTCsWT2pkbFTx WMJ8OuJVv93tmWgTl1UQKDiaerVhHCJlUk8Ip6sz3BpcBPXmTkBkCREjUBficHy4+076DBbtnK9W a9gzbSUPx0EvLa1EXN/QoGo1PNVLfkzq1ssRJ9WSTh6b0ze+/R3tu/4a3XzntQrSLWUSMRVLK8oE ObUqMbUbPQ0NZBSkAnW9njy0WNFc7TWFi7BBbPo6oaprFfO5yBjrxTib3FOjg81edK5RVNdQSbPz Q3kkMtMADoVCUihv9oeRUOzEE3icM804ZiYuO0WBPoJQ0Z8QfAK/WYS5o9aBFf2LohLiyE2bNhnM gTuBuPQrkgfgCaz5DdFzY4k8XFziweEzbp2kgrxcXzJ2XN+5vuW3Wxxxp47kw3cux5lTBnm68UC9 qQuEHrjwmzoCBvLIDRTMPhEbxWanq0azaRrI2PNxGkS5XDK3Qvk0Y4rjhJI2zyuYTfiBkkFcMd9X 2Onaqb+I93EyC1yZf8yfwtCgmq2WzVXqYWPuSpbPoLPxbwMCrw+BSBcpZnKBwI/GNanQYXjwfe9/ NQPP0xsymn41xWs/gRw4ywsiMDCQF4gQTiCfz6lcLNnha7ZajifNs0THEEqs7+0h8r3nxF9deQp8 T/FUWt1mW2ulmvKJlIJEJDoEO5nmXLWsWDxQKogb4mHtyDHaIAmbwPG4pRkZY2+MM73qfYKGXVnC JjcTnAlIANlQR0QjiMEgOuhsgJhA+ExMkAPIBwIBcnEIw9xFRSzPJQQC1wRiGRjIqlZeM81FTgHo 9EKtzsxpYtMmO1MtkURhJCIkmCu0EQG2IiRJ2dlMVokgaUgMRAryAtE6RAXi46JOIDXSUFcQKHfe wa2QJh7nSJmuOPgTThYFD3xHzs+XzY8kmp6RyA2CnjNj82K5plQ6o1IVjqwmtapKh3iBCTQ1tVkP PvgzSg/n1fUh6CuaX13T9omt5kl/sLBFQd5TrV7VytKi8sMFW+Uvl1bM/GA0P6xieUWD+WE7RaDT jYw1WHSwV9PuNLVaasiLBYrFffNAU612NFRIqRtgI+ibyLlY53A+qVaBi+iqzmGs+Yx6YWB6IOzB QWwcAWN8QBDoSy76D46bBQDtB4b07bZt24xTh7OFaJGHQ9rAnP7gN3fGD3mB2LmAPX0C8eEbz/QB +ZI/YmNHBF1a4jB+HYEiLXWlXMapS+v6GFE074lH3bkjYmZskgfxcR7drdWUjWdNN4d2s5hiHqFl W2/EbYycOXdOk+NjqtaKUqelTDah5eWLGmJR1OLcu7Q5GSiVi0p4MeUQyXa6diLCQC6vGIsQCGS1 pmanHXnXicdtPxsR8EbYgMBbgQDEzLYKMCDBQ1Qfz3LHOBvnDG8mvC5nhp9DpIecYAwhiHsIGOAg uEUnLbNKbtrBbR1BzLKFyH6n0wJZxdRi0iKY8FGzj5s8jIZwlhYHPiP6wBNGyL4P+aNi3O5gKnXJ LVO13jBO0ElQONeqF6Jq31C317YVOWrq2DCBCEAmqN5Hq+pIgw3ARPBaDyQa4hsBAUmAqFwgLYiN ADLjmbwh8NzhWM0dE8bmIZ4wevLjadu+gN3FXI6TUKpVjlfuKWteTKLdDbjfFoQzm7N8QVauMykP gubKspV334CaOvEe5Eld2S+D64sEP3B+HXFOG37O6Cf2uxC/IvaE8OM4BqIAN5dMpU3aVG9WlUs2 5aGtiD1SM5CCyL9iK4gUv6uahZ9STiC+tGLhoNrVnuLJnlq9qh3fA4cWtY6dFw6Zk5J+St02hwKm 7Df6kMVqRzXMEhjMaIjWq0rEk1peWVIhP6B6o2bnykH10qmMaVI2Gy1TbmnUsVdLi9+dZk07No2r XY9sFek/YAWMgA8BLpqFDLCFAECMIBj0oetb0vDbBfoa2EJsyJP86A/yWB/PxedOGuJzd33Ds03M /hhy8daPMVc2dSM9RI/F0vpyII4QNIjhZXWJB+oVV+XnmG++eo1WZHMYxG3hFPpob/pqtBpK4ngg 7CjBXna9bNxaC/+YHV+JdFpJD9uzyCeDzT1c2jGIuTBVYW5ySCqnFjSbJlnJZOFg18+l9RDZeN6A wI+GADQAmgCuiJn0qWvj2/lmxO2Whf9SnBmrVvbNmJQQHLSi4WwgOq1WW7EgaUa3ION0JhUd6Nhu q9vrCPsqRn8AosfyK55QC2kZSIzD4hKokmNE69mhi9hn4ReRvRX7kEjKJyIHyZkrlohoRISibRyi 7ReFETHiBNNsBqlmRIDw3M7q2gWOPIGoxOMR0SIef+125OzX7aWA8EAyIDLa7cQ7IBvSgFSIw8LB aJ/5G+O8IE58btgJyYPDBSNkpSrKB766BgMJbiidSCieCJTN5U3U41hsEBhwJG+eqTt1YHXvAuW7 3yBAPFJDtDBV4JBTni8tNsx5J4g6MAKHQg6cK8bv7Cc2WhV5CV8dv6SummJYyYOQpbGiVqXpKSjE 7Futuyo/xgniVXXrcXmVmiZGcYjcUZI06mq5NK/hwpCq3aoSsaSSsbQ66iroe3Vh8NI1rOYRfxVr JXW6XZWqFeM4QORwt4gFm218UeatH5ZWVo0bBTZGiKoJI1Cs6jg8FeIKnAiOCJAXRJ9AHxKI44zm gZ3jgN130pKG/iZQHoGxwDP9DoFyHD9Ekr6CeBGHukFsuBgr5MU70pGeckjPd35TB35TLnGoH3dH 7Jh7PK8ndJSDuNvGeK8tP5tUe35asURGLdy7xRLyU2klGVtduL/Q9pvpH8xo4pmssvjZFH1QFRw7 9aFfInN5CFhk8uAIGYPcD5L4O7MFZ5BKym/jCq2heN+VnQFq498GBN4EBCLMRYJo5Ll5yJ3rzXJn b0gBBKPpxYV5rawsaWF2zrxcXHftflvlpzPRCjeND8VuVydPnNDFi7PmgHLf3qs0NDZuTEMYcoyA jMujETihuDBzXksL07rr9ps0XMgqzWq61dHcec7BOmLUmkmfKxS0ecs2TezYbsa3IceBwI34sgMt Txx/xU5T3rJlmwb2DBgHwmTFzg3kAMGDg6pUS1pcXDBxHP4a0WocKIwqmUwbcgGxYJz8/PPP90Vy oWktotmIAgZIByQCckE9nzPNHvzAfXY/+MJL+vBHPyHPj2twOGUWWUePz+ib33rEkPPCwkVNTIxr oJDTRz70PrMhLlYqRrTZ/3N5U/6hQ4fsN4gXhRTaQOeC3BxxBlkuLs7b2WUDgwXlc3BSIEl8aXpm Y8eColqpqVwpGYeTSMYNuRIPUWQYa6ututYq57XWWtJAJq5cvKBEakoKcsokUyqppv/n0/9eo9uA d1UXTl1QolfQf/dzv61ieVmxoKNMJqFO2NDREy/pxNnjyg8U9OD7HzJvLAPxEfPB2Gt31aiHGhrL yIvFVW+UdOLkaS2trhhRoV20l/6+4QaIBOLeAVOmcWJDEDtiQxA65gY+7as1VVlbNgIE4YCwEB/b PcSxTtyHYhEwJpCeZxSOgDXp6NeHHnroUhwIFhwSSk8ol5AGkSRmABATlw8LC8w6cBJAH5EX5aNw cuutt9o72oSIkLpDsLj4zXFEtJtnlH3oa04GoM4QSfb1PvOZz4gTJ9C0xfYQreJPfvKTRuTiQU/h ypx+/3/7nzW3uKKrrr1eI5NTGt20Ve978EMKIFpmnwlz1dLzzx3W/qv2amR4QEdeeVlbt21TPp20 8YJLsYtzF7VpdDzyAdps6fTRYzp1/IRpnsZTSR1+6UUVBgf1vg+8X7FsRi0cUsciQ20DyMa/DQi8 CQgYZ+ZF/hlJZgu0/p1nLmjFGw2vS8xq9bYy6bghUiYTxMz2XHod3XPPvZfK6XVl53Y9f+AZO4sL UdC56Qt6773v08DgsEIvEKomuE9qtqQnnn5O3/n2P+r663ardeM1Uhh5ZSfDWqmoZ7//pJYXF20V vHnLlD76s/+NJrZvM5aOhXYC5F6v6/iRQzp65EVT6OC8sIgnY0UdKZSAtHshyL1nXjeKxVUTS7Iq ZV/pyJHjuv66m40zAHggJ5CWW3U7jUL2WAggVBANiBIkVi2vmDZiqVLTLbe/S1u2bxduGcu1nh55 9DHt3nuVqckjal0rlw3R4dELey2URpZXl7Vr5/ZLcMSzCEQVhEcZEE4Cq2d3h+vAlIBFQ8/r6OJ8 THtZOAwMKGXitZ44jZmTYFH+mJmZNoJ900032F5Us11Xu9NRJhnouy89qaWl4wpbS5oaH9JIZkxj w6zY2+rEcqrF2nrv++/SiQtP6uz5U9q6Z4u2j+xTvVPUGMfP2DnRbfW8luLZmHIDKS0XF1SqrmlT dsq+wobjmgylDxQcGQeIGCu1hrZNbbMTqtFAGhsf1/LCohEElH3oD5QQ6BP2bny8hfQi84ChwoAp 3mQzSbVqkb9GCBkEBcLDHc1IYAiHBGGgDyFifKNf2Wj+4Ac/aAsXDNAxXIdYAXsICmMGYka+e/bs sb03zsuD4KyPQzyIH8cKQSAZh05JiLIIxCEf2kRg/w4i+eEPf9hsDDGIZ9xBQF0gDfaCpGGRg7kB 45L+p/y45+nEsYM6+Ox3lMoOaue2BzQyuUlr7ME1q4qbwgiHmIY6d27GNGozyYzZXhaLde3hIFQW PmFHYatj58mZD1HrpK48XJ8xHjuc2zes0vKqtYHzC2OZTLQwipFD1EZX7437BgTeCAQcZ8adWbEe x/Hsfr+RvIjzusQMQsbY/v73v2+T/8MPPqSJiTFbKW6Z2qbt23eauA2EgSExSAEOAmTFxnu01xCY N3vzH9GVDhw4pW98/RG9cOh5feCD99gZX+12qF4TkQ17Mp469abalZrSsUCtal0p/D82W+r6gbox z1g8vIpAnLBpYoU7Nt7X8mvi7QGlAjzaDxgygECA5FqcaixEPOyh1NRsRvsrcD8ExyGBhEAm2JyB TCEqAJeVN5vwN910k86cPmkICST1gQ88pPHJCVtJrJXqGhxK64abbtHmqa3GfQwMDas0Xdb42LAS VlRgDpQpwwUQLAoHqKGDEEF4wNVxY5Tv2sFqnhOi07mkEY5EOqV4apcyScSqPTU7TR0/dVznz1/Q 0NCA/FrVfu/a1TNFnnQ2rdOzR3R2+qj8YFWZeFXdMFCrE1cyHSqXDdRWoEq7pKktoyqGg/JSk/Ja Xd143dUKeinj6ur1ssKgp7PTJ7W8elG5wbROnjuuF48cUubmnHKxmJKJAYXxuCp1zuqWWt2eee4G brTf63nqtPH+3zXvJCjToMXaxgVXHG4rrU6rbQecPvfsAY2Oj2n/nqsV+LYzZ4sL+suJgUH8jEN+ Q8TMHm9tzQiS48q4w91BrCBcwBjTDZA2cIaAsLCAcPCbcQHHBRFx2pHEob9Y4MBVkpY+xKwDjo86 QeQYPy5P+pr5QVkQMy48ylBXiKQL1Iky4eZwKEDZP//zP2/5MacicWlVe3dt0T/7xIPqeHEND6TU qC5rdaWqZr2m3EjkrxMln0q5qkw6r/n5JeEObmx0ykSEIBH2blG2ytmeGPsILVs0jo+O6pbrb7Aq jU1OmPu4wvCQUsQjTl+06+q8cd+AwJuFAIQsWqa/KtYHJzBf3qwCyOsSMyrHPhlInYnMJIWYcRw2 Ew0lDbZqcvnIeSsT2HETcD6c98XRIRBE1m8LS6GeeuJJHXr+oIn+QDrET6bi8gL88Hnq4jSXvae+ mjyGUAnO0EqimszpJaGa7a4hKsRXQ0PDZuOFEka1VlU2E+2TMekt70SkLMHzyvKa7ZuNj0fixVJx zZAhRAqkRP1J57gjkJl7x53Ad5APxBpPFXOzC3by9vU33m7fh4bSmluoGaJ6+pkDxhHcdfcd2rF9 SoHbz2v2lEv6JkIkP4gpK3MQJJ4vWBiATEG6d999txFQ6kQng8hAvjxTP0RyqFaj/EINsTXKJtLR wgCiziZ9FzX9nBl08zuIR5uuLz3/gjZtSSqX6mrt4rJS/oJy2e1KZVvqqaGReE7fPPCYusmGwnqg uel5vTJ4THfv2yXUSdLplCmO7Ni1VdVuSbPzs9o0OWknjyPapT4dddRu9YwDG/Sy6+DclhdWDJ60 G8KN5iv9lM5mDCYouAAXuGG/VNTxkyeM02VQ0l8gY4gFhJHg4AgHQ54YUyOiYwHiiB35A0MkDYgC 4YYQLUNAnCgXIoXShSvbiXoZJwTydn1BvbF1pMwPfehDlocTRbrFEWW6wDuIHOMHDo5AHehLJ95k rLn9OLhCJ8Z045HyYXHZf3zXvfeqF8a1WmkYBzw8nLR5iYlMfnBM7U5PV++/yrjUF15+2YjmsVOn 1FZH+6/abeJ9vycjmIP5AYkjezo9La4u69wsi6EhZZp1nTx7RmP1qq697RYjZJ1W0zQacYKwETYg 8GYhYEqAZhsZaTMynwjc3fObyRNZju3KkxivGqj0ooHoJms7Mm+yPQD2HThiA8r5wAMPKBZEIhMK 5NDGd911h7bu2KrJqc0qFAZt0mBcTR1BasS+ODujg88+o1wag+muVhbmbCMZbSkQFB7Z47mc4kMD mrxqj5LjI5q6aq8q7bYqlaIpWKBVOTszraWFRS0trqq4VldxrabZ2fk+IaM035wO49KKZ8Sg5uUi N6AtUzuVTg0oHmQ0OjJu7XGEilU9CAukAvKDgPANZAMSIvAOH4AnT53Re+59nzZt3aWHv/otnTh1 NlKG6e/LVEprCnsdvXz4eX3hrz6jL/31X6u2tqaAo3WS0ek72POAiCkDuLJAuOGGG4xr4GRpRF+f +tSnrC7UBwQOYiTO/fe/T3fcepf+h//+17Rr+z7FPQhL3M4ea7dCvf/eB/Uv/vl/q9tuulO333K3 dm7do2SQVcJPK+zEtG18p37ho7+gzfmdWp3x1KwMa8/Od2l0dJep7rcaZdHi+2+9T8nSkKpnEhqN 7dH1O+9RTHG11DJCVgmL+tYj39RLh1/UzNkL5ij4H77893aKdVdd9YiX6KnWxNZJ4vi3xflFxf1A a5WqgkxKYTym+dVlxdJJJXIZdXxpqbSmZtjVkVMnVGrU7JrYOqWBsRH1MIgP0OaMTrgGJoxhYARx QzzHOzgzYPYnf/InJpqFKHGxGMD4H1tFfI5C7HAPhlsxAoSNfnZEivfsnf7lX/6lvvrVr1oe5Ivv SzzMHDr0onmYefrpZ3X69Fnj2CA8xIkWK2hHtmyvEoUcXK6hoERdIRb0P/t8zC8XqBNG+hBVOHX2 2MiT+kPocNwcy0+q7hVUCZPKjbBftkPD45OqsKhjARh21O019cQTj+vloy/qrvfepWOnT6jNIawc 78Mqs9VRtVw2N2u2qQ1z1qjpxPQ5PfbMk1qqlXXkzCkdPvqKViolgzsaWxw75BZ+4AtgD8xpM8/0 B+8RifOONnJ3F+10z9zX/2YurP/GM/3Be/K8Mj7v+M59fTm84yI+deM7wcXhGwtG11euHPed3y4t d4JroxtvLq7j0t08pa7Ah/guLt8IfOP9+nZSN965drjyXPnkwTOXS8+zK5/0/HblU46L/xN596Nj pQI/2jejjijnAQM0GbE5fjPBC8PoMDBW67hAajcxfuWgyJi+9rWv6d5732OcF0Pgwsys8OrAPtSO HdvMgBkxEPsduK2CCLAyZ3BgTzS1ZYvW1irK5QdtjkBQOMLsyJFTJmaq1csaHPS1ZeuEhgcig2ts kHDgW++fLwYRQcQyMDRkRsh0NHL9heUl2zjvNKJyeY8RrLPJATCI6dBQZPITQFyOWLlBxUGduKYC qRAgYsRjxcwg4WIVz34LZZAvASRJvB07dglP9Gulkq6/8RrhmLnJkSo96aVXjhh3dOzIK6ZNODY8 pNtvu8k8pXAaNUoo7HuxooeguXqyzwPhpO0omlAWIijjhPuTkTowAYG5Q3DUzeDD4PA8gxt5kx+/ nbamNcD+cZTMisrlBRVLkeZcYXBI2RScLQuCSC2/2W7p9KmzWlvj1IO4EdJMIgu/pUZYVrNTN+6n 1WpY39tghBu46lrt3HS1PLGgSGphpaiR4VE16tLSQsVslrpBT7VG1YgnGpZw8yyALlyYNfEoJgTk i8Nj7Oj4PThYMDdl5ZUF7d82oWqxaP0CvJjwIBD6zXFr9DlicmCB70z6DVEuHBXSBu7A7uDBgwbL d7/73UbMGMf0A/mRF+2iPxAlImbmWy5LHy6Z6y7yIg6EBjMI9tB4R6CfGWfUi7HHgbSID5cW1ywO nBxiT5RAqA/toG/pT/qPfLiou+0NQzyaFQVxxNRtdUtlzV28qGKlagelbtu1RymUglC88nzBibXa Xe3ed5WOHjtm8Ny9fZsSIZrJ0aGpjH2UrZh76Xxe8zMzwrcq3CmwoE7ME9pFvRI4j/Z8c/INbAm2 xdD3lmPtrNUM7kgZaA9jHFg7uLj+4huBtjJOGa/MX8fh2sd1/0hH/sCT/FxfUQ7zhD7gPf0G4ueK 8FLM+o1+Iq2rh8MH/ObZvadI5hfB1RE4kS8wcGPMVc1x9qRhfFDGlYG6c1EnyuGZvNaX6dKQD2UA D1cv3pEv+btAe4At36gn7Xc4zcX5SbvDh7HtQMApPOOetuLU/oF774tOA+HjG1TNj4gZB1J2esrm cz9AzJj8ADKJqBBC1kRl3TcCB3AT+O0zBN/f+/F6fe7ONxunVqtniJwFYLUKi+YpHTkFMUUQvOgX 8ASBXRaEKeDYkZpR5R4DLs6xIXUTp0Bs+cZOCX4a6bywDeGMOEk3cBgc1DmCQ7RSsx99ropvdD53 9g/odJeWeAys9YOLb/xmoBgs1nFSOPdlNQERw4yOpQEKIOAwO58TAlnj3ORQg3lO4TI5oNrNjlLp y6W8TDbKYlBTHu0iMMFpK9wEiJU6cNH5IJH1A3f9sxvg6/N17SO9wpb8WA0+sk+8EBhRU/4iMZrn RbZNGD1bWk4KB7F6HEoKzwVB7KodRmrbTFAO9WQPLJ8vKBFkTHXeU0LNTmji0FpdWpgv2Vioh6jj o2SUs/1MjKIHBvO6MD2rzVOT5nMTETSe/zFDyOcGbC+0uFZWrNfRjfu2q9uMJjzjEfgBNzeprdKM rT7BAgG4b45IrYc1xAJk6MYDiAsiud5ejWf6wpBPX8LWxqjYDO5fVeCgbGBPmZiFwO0Ron6JmTmF z6nrNl/72lt9JM0Ydshqff0sslvIBJ7CdlkexyTBqSVSxmlRFxwT0JcY6acyWVU4p88WKVK9g8ee lobyWYWthnykIqzi+8ixhqF4Pn/pdHJEK00QTSYjDng1BO4WVdij9Rc+9D1wA9a0lbbTjisRvpuf 6/uENrp2unHPWCYtv1nQMtZdf7i41NulZY4QqAdjgfcExrqDvSMIvCd/6kL/EvhGWby3+cESrF8+ 3x2hJR5lMX5oAwECvL5O5EvgHeOEwoGiEwAAIABJREFUuMADbtvBh+9uPhOPOpI3ZbuxSVsYL+Ao NwYdHiI+z8SN9lCtSPvnyiD9jzM4OFIHB5NLd4SCfuRgDbyIjSzfWEDhxrCKtjfhDRKzy7FplDQq tL96cAMCZJLPpdXsdGxVV69V7PysajE6CyyZSpj3jp4Xef3Ag4fCpsUtlSumUcgqsdOOVhTFIisJ 385goti5i3M2edMD0SrEJlQmo0qxaAPKAYXOQ9Ya9NXkGTJ0tutYh8AZFAxSBr8jEHQs7QFgvANZ kI53DAi+u4lEHN4Tj4sVF4OSerjVl8urVKobwHuer2wuI3xDMsZx0UU9BgvRYZQcdFqrVpQMUIpI mCiK+lIudWWwUx8C7eQbqywmiqsfZVJH6k4daR/PlEMaAhOf30x+7sTjTn480wZ7xz5akoVMx4gP 7Yxh2+eDaJlE0WnhxM/lB8waBLX/Yrlo+50+YmY7mDVQOl5QSw3hLsJLpJTMJdRlNdzsqhXWFfba JtpF4YaDQGN+TwGaML1AuULEPa+udjUwhjJPVtlk0uo4bFwr3BMcWsvOQUNRZDCf0aaxIRPzpeMR J0ob3TiBGwMe/AZewA+uHYQEQnHIkX0r4EQ84Aj3BNLgeT0iIy/6hr5iHABL8mzUOxYPjUDKZ3GD GJx+gjCChCgf5Oe4FspaXatauez/UhbxQUBceDMhL0SOEE2+cbnxQH5wh1ObxxWGvmKhr9VyTUOj OQnj6F5d9QZ7npEtaDKVVS6VU72FyKureDJhiwoOakV7KzpfrylQOuXQVs7GQ2wGrCjXELJxnJGI kzq3e12FvZjlxzgkLTBmHAF/2sz4Zf+XPXfikA9jj/fEp0/Ji7JIR3lwZHyj7cSlr4iPuJL+4U48 F4AVyBzYEY/6u/lEesqI+iaa55TDd/qGuHx3baR+wNfGWr+u1Jt3bpxA7PhN/ciL8UKgv6gHY4RA 2VzkSTzaxMW44R3t4jvjzOEeR4TcOAaG1JHvXNSL+ORBXjyThmfgQh0pi8u12yrzE/KP9l6CDf58 01nVGnXTpHVwYJ7QX282XMYDu4LWZ5LNRCtHgLO8Eok7GGwAtlat2uAhXaPVVLkWEQ4GJxfahOwT cIYX3NzAYEr5XJz5huMqO1akUMiq2YpWLewdYChHoANpEIOTjuU3nU89XKMZgK6DXWfznQHAbzqY 3zzT4cTn3ZWAcgOddhCXOxeDgUnGO9rDBKJs4vPu1QEXUzaXjhA8x23BUHkdc92VToLU2SNaMNMA RGWXDJ37Ks/kTV5u4IJwaSvvCdSZCcXFOyYT75hQbqA7eFE/hzCoJ+0ABq5tDsFwxzQgSBQUjxUk P62ekgq7iejqJaQwKd9L2xX2KBdtQw7T5H1KrRqnkybVqQfqdhJqlNl389WuoYuYVtiOye/FFfcT 8kP2CENVSiV5va4mxwe1ZTKrLZNDGsnFFeC2KZ/X5uGsYt2eJgbTKqA5mgzULNfk4acxlVI6FlM+ mdQgLqaaHVsY0K+0j3bTZodIWQQ4mNJ39CUICERA/4F8QGogAAgV75lI5AfMuDsNU7g18ndImGfg D/KiDOKTD+MMcwj6B7E3CNMhFerGRV3or1QyEgdRL367scr8oo8pi3rS74wPRG60kz5G9AdhWlnj 0NKYEumCeekprZbFGsRTdKo4XJONEdxxVSqqV8tq1KqKB744BZ56MqZogxsjRij6hIX2UGfy4Jk6 cgFj6gccUOLiGUJG3akvgToTF7Eo4j/6g7yJ62BMW8gXONE3tJvyyIu60R9uztF+8qQvgAtlcydf 3pMHWqK8py/Jl7Q8Q3BoA33k+sPVkXLIh7oSqB/peEc7yZs4pOdirFAGgboyhqgn+IvAd36Thni0 lboQqAtpgDXluDS8pzzawLjiN3iAO4E86CdgS/3Jmzyon2svcHFE1pVliX9C/lFfgrvzTL+A67jT LgJtBUZvNliPkPn6AlwmvFtYXNX42JCtjEeGh+yYewYaOnMWWBmCdHE0awg54l5QJsGZKQ6G4/G8 Yv3O93D9hP+3DBvxURZUfPu27VpcWtSpYydssO7dt8+USlKIAHo963Q2rBkogASvEfiUw00lA48O ZVBRBwLxGJy8I6wfrJc/R5vBTGY3QC3BOqCTp8uXeAw48magobGXTCIbj0V6OaGUS9GwuEHIrRYG BweUyyTN7yHlmDAvjPYJ+A2sKcOt9qgD71AAwL6IQU+9iQtC4BsDmsnp6s5AdoE6ugFBXYnLnbgE 4qLy3m515MfwExlxHaYi3+mZ8XcqmTFvIcQ37x1KGGeUz+VMslwPONmbeiaEPoaXLtgd7j2hQAHe /Lsdk7+2u20lAk+5VFLJdMKcFJ8+dVGFQbQMo5Uxq+5mva2TR48adwLnQegmIs7GRN0mqY7awNzo tkITRTMBgA8whMBwBxkAN2BhbUCcjuZsMnlpXDCBQDS4jMLQmT6lDwjEhaNgosFdAGvg5rg34sFZ BXDaKYhWJNrifDzyBdFQF/JkMec4bIgXdYv6LvJmYgX2tRpBhEZQ+mJKCJcLIEDSgtRQSBmb2Kwu /hYLg7YQTGTdiJOi0WUDySQjo8MoY4Wm+JFGcqJAjW7HTkMHJoj0UeognDh61NqAIo0TP+LGio5n TqaQIPiBefGhHgS3AHPzkPEHt8DYIw5wACbAkLYzliF+xAdRs3CgrW7OAl9HkPgGoSPwnb4hkA+2 fZRBWsww6HsuyqEfQPKUTT/SH4wJvpM3Y4b8uFMXTCUwTAf+jBvg4uYMebh0cN3kz/jgO3Ujf+pA vuTpxh39TT5c1JP4XLSZwDN50bcuuDEIjLioH/mB14hLAL6MKfJ0bSUPxg958n19ni7vH8edceeC ewantDo9gxmOyakrcwkYg6sCHIP3pU0u7Y+6x373d//17yITZz/s937/98ytlNNw/KVf+iU73BCk d/jwIQ0ND+n82bPmyaLbiVavzUYTbGZupwA69l3UG9dXBCqOfzh+cbgj6aiwH0M1PPItaBWPxWxz /bFvP2oDcqhQsMlRLhZVR7yRSOj89HlrsGlddiO5NUSBxlMOneoARefzHJX/qiYTcflGmUyIIIgQ I3UnsPJyRICJwKAgPs8EBg3vSE+IJ6NnvG3Qdog3yjT4S2yBYLGpQixoyENq2OoW+MTU6bH5HokM yZOL+hGYvCjggLiYWAxQV28mAath6hq1IYjMFHAp1ucwyItv5OcGP3XmGTjRRvLxQr5TLn0SKIaK P5x1PLB6IzGh6Sjv4HTGDnnGq9i6E4sxzQAaVB2iZlsw9DureC+6SMs4SCXgaKS5mYv62sMP6/y5 07qIB4z5ea0sLempJ54w7u3C+fMaHR5VIZ+VL1/x/hhqIT7rsA8bs7qEvUjU4vqMfnRw5KBTYAZM MHcAqSFWBKmAfFjFP/vss4bAUOwAMYLsgBH5AT/6nTggZQIq/Chp8B7k1W53TTEmm8saQeQ9p2Of OnXSTsAGuVE+84G+AJnje67daRm38tyBg4ZcqTdImQntOEYIKO9JT7nsJYC8MNZHKYi6FgYGdf7C nHFlxWKlTyzgBnC4XNby4rL5ubwwPa1MOmNbAdauBgeydpVK95UL+qIx6kj5X/nqw1rGaL/PtWAa gMNiYEPZ45ObtMJJ6hdmbHyiEUodIfQsDCAYIHGUaj73uc/pmmuusfGMdq4Tx9EPwB3kT39gOI6h O4Hfbk4w9iEOX/ziF41jQ3GGb9gIEv/RRx+1+QLsEdHSx8x7yueiXzHPAJ60nXHAd/rYERzGCfVG oxV4c/GNshk7pGPeMBcxTzp8+LDNQQgfeTE+MPUAPt/73vesH928hUiSH9/W2zKyIGFOcpEHcAUW EE3eReOrbXfeUxc394Ed7QTO3ImLxi115FR6zj/kG/nQpz/uy7XzyjvnV3LCw4njJwzGQ4ODOnP2 rP7yP3/G2grcQSwcbEybGQcQeu7AAlriQoTB3a/XuJOIFRfngeEeajCXN22ybVunVDGxzYCJCdv1 SJZLZZmAiBjpoLgRC6hyhNyUQNsskkHjpaIXdpWMpy0PtKQW5+aNUn/hC18wZE3HMgiGR0d16MXD uv/++3Xv/fdZJ6HOj/206yhXfepAwwkGjHWbwuRFfAJ3Op+B7ALfqT/fuFM+eblB7+JxpxzSc5EO n4ftEOS2plRyTCkQrnzVWjVThsF3Yi6Lx/eoPDjXVjMSH7hygBkBRIV2GxMQ7R4mLuIa6kG9eMfE 5RnODcSNxuUv//IvWxzyod7UjbYw+V0AJq4c7LoIEGDgEMSQ77uYtJFn9hLhwKP3cd9cN9rxK0gD +usWUwoiRhDz1LNjhBKGMNk/jZwhY2sLJxgIG6XVlSVt2bxfI2PDdnJ4q82J0jV9/GMf0ouHXpLC tqk7wZHBjqOWkk0jtu2agXWQiBYClEk7gQ132kabQVZMaFbbf/7nf27ePSAmcGDEBak6jx4gC06l /oVf+AVDdvSnQxwguZ/7uZ8zZPflL3/ZxhQcAEh0z+6rDQnfdPMNhjghRiAv5gp9COGj33AzBoIG xiCxB953n82rL3z+b6wu9BXICCREfTHLAPGBeKknzxAKFLKoK4j7kUce1fSFSHuYuUM9eb//6n3W USDw5cUlbd06ZQiZOAQIrIPTvfe9x8YuCxgXaANxcDIO8cFTiisT8xzME/7gD/7ATAko/7HHHrP6 0QbmBEidM+VoL8QXWGF2wG/GOcgXIkdbgQdEGjgxLrmAPcifuASQF3OKfiMPuDyIFN+JD3fE4o7r 85//vL0HDvQ1cwRJEu1gPlEXAn1AvowRLuYR9ny4reM9EhH6gfEBDoQwQUQ/+tGPWnnYfgJfCCwE DWJP+eBJ+pExwIKUxShcHGOJ/oHo/eqv/qq11xE46kN51J1AnwMD5jhas8CUNgAD7hBStJsZEwTK ZX7TNmACUaRs2v6TEByuoS6XPZurNc8OMv67v/lb05L9xV/8RWsLrhHZxnozwdgoClhfCJQQZMBF R9HRdCaDlcFEx9FBABAP7NjNMAGI7/Ky/RiIQaupWl9ejDPcmJ1bgzy7ar4XcVdEoPPoLPIgMNmw pWKAcWAlgYlhFDkebc6z6nf1ZlIwKOl4AoOZgc6di/oxoCiH38TlmYv3BMrkIh2BPGkzv3kmHYEy eefSmziVzWw0K+WZDR2ulUvFFXXaTWXgdFAGabfMsTB5GAfX5y5pM/WhDOrPRVm8Z6+BFTvIBcTM 6ozBDCJgVUq7qDP3SPxrVbS05OcQAsiIMgi0l4lEG0AKUWBfMLB6oXlabzT7nvfRXoSjY2EQEVqc 1zqhgUk8PKmLRwiIYrOuXreuWoVNcVwkgZB6atYq6nISAgbvjabCbkfX7L9aH/vIh5TLpnXsyMt2 2On46LD++nOfVSGX0fjYiGrYNfVF2i1OEgX+PfJtG4GjDa4v6RdgB9zgWiFYnMkHzHBTBaK6/fbb baVOu0kLEiUedwgIcGKME4Ar456V/Ze+9CXrBw5RBdmAMFxZ+HSkPAy0+UZfQMDoL55dfiBJxgzj mINEsRtD+sF7+ph+YU5xoCr1AJE5ToX6MRdBkhh6g7gQAXJxQG4ynTHHwhyndHF+UafPnDPFnrGJ cfuOP0fmMQE4LC/OGwyBFfvU5qEchaJKxRA9MIVLYYHEGGL/D2IAMsbDiRtzEBgIA3kCY9JBbLjT H4xB2gF8GLPUl3ayQAbR0ybgRL7Ak76iPNIy97jcfAUmcEkE8A/vuagbyBt48kx6CBl9DQEHXwFj 8ic/AvV3gT4iDUSBOK6d1IEAzuE95hz0JYtH7rSBdBBKcBdzivpQLpwonCYLEBYjzF9gRL/RfuIx FoATF+HBBx+0Mcg4pE6kAWaMP+rr2s830jBWGMfEo0/YU2R8AHPqQqAc1w76gMB34r1WIA5piMP8 cPF579JTNn1OoE4uf3e3D+sYCRtj6xgI9507sAEOv/Ebv2Fjg3byO2Dx3U+zPv6PerYjYKzifdV8 cAQbI87O7IEH3msiwrm5BTPCbNtRLLj/ifYhIodCsjOqXqsg8obgseLn7CsQY8K8qPfMXtPzklop lswLAXtgxZXIzuTcmTPavmuXuo4osQndahpyQTwHb0Ojs8mEDSQjcn0NPybJa9mnOGADXDqEyQ1T RqfRKSAZBiiDh0FKYPDTiQwg0jN4+E4ZTEKGe4kzzfr7Mgx6uMXIE0m0X8cz6REtIpCDFNjKMFsw 2PJM/akDg5CJyQDlTn4QKVazTFRWd3Q4E4LJhXiHgczKjnfEoT2ko53cqT932kw9GaxMRtrbDdnk XtXw4Igp6uBFBOIBXEhDoN3AA1hwpy2tBgQe8wI0Eju2l4LaNvZVPkiTgRh66hrRj5vo0TNk6qvX QqMLItSys8lQEAIZQDgIwJi6MVkZP1w8Q1HrlYq1i30bjgziMEoCbaa93N1EdvtcwMv1OcgERAei wfiZVTJwcXZncFOUR3zgxB1Y8Y72Uw/gwTfgOlAYMQ83aOwCfy5gdPr0SUNor46dqA7UBcTdaNYM UQWxaFzRfupB+cCB/qbfXVvgAhgTjDk3XtaKZfN6XyxHe2wgVb7dd/+9Wlte0e7d27W4sGT5ToyN GmxAYtTvyNGXbZEI8TV/jH3EbcD0PJ0+dcrK3rR5s6bPR+J9NwcgJHuwh6vVlM5E+1q0E7hQX+pq e239rQPGJHBhjANP2urgB4Knn4AL443fxAHezE/eEZfvLOyY85Th5ivj2YlnGTPU7c/+7M90xx13 mN9N2kM60rjxS578ZpwBa2Di8AX50pa///u/t4XGZz/7WVuksJiA46JOzDeCm3tOhM3YowzGF7Bg jEHUWHxC6IE1baeetAOY0Oe0FyLu6gec3XxjrFBHiDEwoe7UD9zwp3/6p/rN3/xNqwtxuMiP9jqu zLWNMgjAkbKvDG5MUW/iko+DO/lSJm3n4pk6uj4jPm3mG31McLhsfTnkTbh0p0qer4twkWNjmpmJ nHEj8fjYhz9ibcUvKLjkjRzOeYmYYUeEnVmnhSFRRMy+/vWv64H732MViEBheh6XRE98wNsehAVx WhSiO8bPBBrOycqsqjms0o6iMIM+BmTDfCeWa3VlUpxmvaiJkTEDZIIV1Dr7FhpVrlZsIJA17q7Q BkMBxAUA6pCRmwx8Y5Dxm86hY1yHRp2CKn2EqF1cgM2g4eKZznfEizxAaHQgeUKqIfxwXewzASeQ XyadjBA6qox2NItvk4dz2SCGmBbE/cgdk6s/eZMnA8UFBiaT4Mo68t0QvIt4xZ3BSD0YYEx4R6S5 O6Rr7YNwqadyqWyLFcSN5XJR46MT1nY3CcwzzDovC4kgbooHGL7nB3PGaQHXLrZkmYwiW6UBGxmN CoeAZvsyS2SUXbMbi6ew+aorlYlWy1c0wfYXTdEALTCMR/HMwv7JumN9ot26V1PSZtpHu10/8xX4 8Q2kQJ+CVCAW9K31V5/Ik9YFxg0wcpPfTWK+u4ku/Fm2WhoYzJqolsUac9YI7brVKN4+CI4gcAYf CzzmKnW9Mri6OyTjvq9/D0xZb7TdEGN29RAZt5VOxPvGzDnzmpNOvjqmgMX/x96dB2t2l/Wif95p v3seeu4EQhJIFMTjOSoCMkipcK9iOIcr16nKkir1P8u/rLLK0lt49B61qHIe4DAIwXMRjwrnQMEV MqASQhIMORCmBEjIQNLpac97v/Otz2/tp/tN0927k+4O9w9+u9Ze71rr93t+z/B9nt/4rtcvLhhB jUbVDAz64xgj07gusn5nPGTghjNJfkkwSz90z0HnEv2RFaboNOtAL1PqGi90nxhXj3LuKadMNmrK aAgkfOnt65zwHff5vOSaLzgy8Tc0M+gbnWkIXCvrmXokPKSt4Cc7tTkjkjzix8id36or9YEGvtVJ rqTn7F7qmwxkzIaBLlJnGgl84cM0qJFzyoO2557BGVzjPfXrPhugxQfUqx7lE5eewZxrz/GpjDx4 lJQl03gHIHWkfmXRSfuWQuONWDZqftMy6rGythrtVrVLW/w2bf2fbnhdqf+pNGa676XirNAZIw7J Nt/Vta0yilpbr17xVJSws5X0dLnTjcrpe9WuwsceO1Icq9/rx9cffLj0QtaWV8OPad716bsKYCiK EvQSza/f98UvlsbAvPCjDz1UQMqoFGmkozf38CMPFwekfIYDRL0hAAQIikWXLIzCqHh36JVV64DV m8AFecmCtIaLAdN47utNSUZA5vvl/9qDD8TDjz5WvuznRzA3NvXqutWX/YajGHa9C/J4mQ7z9nE/ aXLwwMFYPrkaDz/8aGx1e+VnNYy2JD2/dGb1q4NDSICIZ0ke8pJRIr/k2uYCLyEmAz0WffnJ+50t yRwAEOlIp8Dvr0kL8wsluKKhrNH0w498PT5zz7/FY48/Wn5/rdPZKj/t4wXHX/zCvdHtdeJLX/pC eUUZnZriouuVEyfixInquzcPPfBAeZFut9MpX7gtlVm3LL/DNioNWcrhnD/I56wh+/y995aNBWzB tgJVJvnTpnkvg5rr1KUy7rOh9R/6NsKxsUNPnp6t25iOSsdXnu7QULee8/gzOkfHzwvB5a23/nOZ dfjyl++P++//StEvXaAhpT/lZ/dNu6OdeTxzzc5ZbwYJ99kleSb7Fz7/ueq3BesRd3/mntjudOMb 33g0VleX48EHHyq/bmGaX6cPFzqDku+ZGS2RB91MaOIl/cz9vCcfzCmDN/ZOv5JH4HV4LiBJRmiC PprwnPrLOgVvz9DLI/O4hlG8SJlPnXxBcHWPXR3oS8rzdZtk5FUHzPPbbFzkEyskdUgCM7/QkIkb yuJBcg1D7mnk1AtLzmRN/8MXXUju41FAT948QwN/UsrqPj7lY2OJLl3niC3lVwdZNJZGv6kf+eTX cchGURnT42KoclI2Ws7yauh9ZpOUQzm06NV9Z4mu8hBPPFO/e1kWXmGDLlPOUvgc/1In8qvXtQON 0pCdo9zZbj9pN+N/+b3/Uu1as3OsVi/D7Oc99zllh1vZpTaKmCq/DebHNAc772as1k/KGyPKfreq EbR7zf63J44cL077nhv/W1xz9bWxsboW/3zrx+P6678zPnrTTeW7a9/xnc8vUxZLi0sx7PcL0D59 111x5PHHS6NlqL2xuRm33HprmQP/8Ec+HO//wAfKmtrhgweL8TRuAAxsFPuOd7yjTA+k8SjcLiMb JYDAeoBG6Qd+4MWnjKUhcwiajGRx1yI4o1njMP9Nye9///vLGsuHPvTh8hqo7/quF8THb/3nks8P ff71O98R3/vvvyc+fuut5XjR939/+YFKOye9pulv//bv4uTySvjS6sf+6aMlAOk1mvNXP4fiCI5M wCXw4t/UhR1V3rZu/t5nDmdqyoK1KQ1O88EPfvDUPL+8gMtZ7JJU7qabbyqj46W9e+Lf7r4n7OT4 2lcfiD/+4z+OF3znC+LOO+6KRx55tOjojk/dEWums6Zn4y1/+ZYg8969e+Kz936h2PA5V18bX/7y fdFqTcWtH/+Xsm5z3333x1e++rU4fnI5nnP11eXlwTW7RWq+qN2L5s4OT6/LslFIR0YAEXgFAfPm QP6xm28qU2zLqyvx/n98fzzv+uvC1wPYVFshKKSzVveqtRp2c42m53RMfq+2Uoa+BQYjFHoXgAQ1 +TmUPM7wxHkzSNC1QG097qUveWk88MCDccedn4rFxaWSx3s75+ertTa02MKuq/zMpkZPaPtNPc8z +Qxj6vLZQQeChE1ANleY5sKvmRO/fnDfl78Un/1f94Svztz2iX+NO++4veTx2i87aUtvyjfP0PTd ntXVsrPRjAIZ6UnyWb2CSp7xzBYCE77oEU+pC/fkT/3L61oApQf+Z3oUlpVJe6S8cK0OZzSK3Xem F+XFk+f8MYNj2hUf7qee5HOY4TFNyF/5sk4du9Objh5e+ALaeCVD0vT7cfCRm0zEFfa/4447SueX 75FDnNFxFCNgiM+aHoMTG2R0TF/4whcWuXSgTJ9qFPDK7vgkLx7cc61evuk53vMVbLCGD1PkNiDx 5Ve96lUlL1nJJJ7hk1xGNhrrD3zgA4Vna3Hy6Ai5b+oU1sngLK78wR/8QbGTPGRHT4ePj5hOtXab G32MBk1pszFcKsO3JDohk87SuM3S3k86l+WYrWg0G+UrLmjRhU7l3//3/17olPwXuJuxdEsSDM6Z 8l5eOydgGR7DmK0SZxCCdnp5vkDgchRx8ODe8jLf2dn5eNaznx3Pfe51ZRv4wsJSfM/3/IcyQmEs DZkEwHoMXvDKOIxGSApOw+uF6GXpKWrAOA3DWIy2s0ljReHKUbLGx7y2hWggYcA777yzLPRSfvbc gUQ9nMacOz44gZ47EJtOSAByAm9IXz65EkePnYxnP/uqOLj/UOzbsz8OHzgcs/NL8b/9734u52DU a81o++0o7508uRrPve76+MGXvizu/dznSw8MeNWRb1xXhm7HRwMc0Nw7xwAwgY1c+KMzsnMefHnO fj/2Yz9W7ttEI6DQB5DZkYaWPM//ru+Oqbbv2UTs23sojjx+NPzIqZHVD/7gy8vU2f33fzWuveZ5 Recz84tlR9fdd98Tw0EtDh26Ml71Q6+OdnsuHvvGsdi3/1DMze6Jez5zbzz6yJFYWd6Ixx97oqwT jeOLLSXroH4uCFw6g154S35BUy1iq9eJ2fnqd8wmJttx9XOvje//gRfFocNXlO9KWTsVBNAld+KS PgSorEMQgSX2pKP8FYLUFT7Y1tSUQJV02Jre9ZLRYyd2oUedAWW4jDx+QJPD40fQgT/1qmM8JW35 BHpJHrQdEv4lgd09eHW2IQo+BQ9lBaHN9bX4+MdvisXF2fjwh/9nfN/3/YfSiTON6PVwds7S58DL x3Y+K+uew25WvOAr7ePzeEo/x1fy6qxR9yzlUM5ndAR4Ojd6zQbONTnYxaE8HaW8yuElkzo8l3ec J3Tc85wt2MlzDYsOqoaDjTWO28RSAAAgAElEQVT4Ong/8iM/UngRfPmWhA91OdiczxsRixd2BGsI xBZ0BVc2IKs8Rps6PWLOL/zCLxS/EMPsPtTo4UmHEl2dD7sgNQjkxXfaFR/ZkKpHw0RveMCrGGVk Jc6hw9dt/iGvun0VwgYXeINtusKjGSc04NmGJfff/OY3lzgJy2yUa8QaYLso1WENGR1rjmjAmfVI 9RrdipMwJ75oXMnlUFZ8FY98LUDDiQ962C2xPZ1kojP8juMgn+12rrzmjFwJarftbMtka7mkIhUC QLVqlDlOn7Vn0tZWP448diSOPP5EfO6zX4i7/+2e+Oxn740jjz1eXqljuE7xkikv4KNcxrL9VO+T sihXr4JzZE/PtYbre7/3e0uPhELd0ygZzQn8QKhhBD5AM4pBWy9Nj1dwxwMw2YGmkaBgRsELeq7T KYFZ/gS/cl5hhBa6QA38d995Z/zbpz4dn/yXT8bjjz0WN3/0o/Ev/1xtD2bov/u7vy88cDyOxTH1 xDTS6tTDAix1cwIOBOjZqAEAHjg2hyibCmxIWFgooAM+z4FDw8WZ2PVP/uRPCn8a9vu+/JVii5U1 O1S/XjoZExOTpfOxsbldGjS/ftDZ8p2q1Tj6xPE48YQpu6nyO2PHj63EaKiOqXj8sRPR7daisz2K 51x9XUzPLMZ3vfDfx9XXXFd203W6/fC9uyoNY9ob3cMrrSZiUmPqZz6t9/gOW9TDK5harclYXl0v X7I/dmI53vHOd8XS3v1lwbjkq1WjOHgkGz3Qo8/05j7d6vVzYs74O7/zO+XajjF2yFGszgB9S2xK dw4pg13qkz3gkU7vvfdLxQbuqfdd73pXCZiuM4jjK4Ovs2sJj+pSzpGJb5HDc3XCv4RfSRmdnxe/ +EWxsbkW3/PvvjsWF+bL+fZPfiLu+/IXy0uapyat21Y+63VbG1vr0Rsa9bXLSveRY08UeuoRINVL X+pRv3qc3ZfwQqfukU1SVpKXb0j0LWDqWKZsyiibNHxGN8u7ljxHS8oznWWD6T7fkB9tdXqOlnih sadfIyR5xAdB2nNBX15lUq+u+ZYEIzohOseCPYzQsw6wJL6k/2edArgk6OOHP+auU/dgBK7IQmd4 Uo/6YQRf7tG5zpGOp2txKOMA3ZFHeWf0NDBkVYc60ROjNKjOnpMlZxrssPQCbXW4J4+G3fQ6fn/0 R3+07KIlq9goj/J0LT6zqYQHsQ5vGivP+ZX6debynjiV9isFz/GPLshLD3SqDAzaXPRU01lfNFyf aJ3azfiqV728TE0kYTOvKqwwXG0eqPp+toBwSO+qqhzTJhC4XD6xEvVG7g5z0/d/FsomjtWNzbji ymeV7SMmLGuDUQHNrF98PnQoHn/00Th0ZfWdto2takHTRpUnjh0rhqn7ztEOmCnZZwbP3pSGTzAQ kPQqKB0YKJtBDh48fApklGoumhGBGCA0XBoIeRkaeJTV6Dzy6GPlZzgOH95XfU9q23RZPTbWVsr3 qDiqg8HWfcN9erb8WoBpnvbUVMzMTMQjDz0S+/ftKTT1djSoZ0uAD/D4JwtwcR6Oi37WpUcH5AAh r+fkMGUgjwbXPSC0eWVlrdrFyWF8TcJvz331qw8UHfhxPL3FZ115RWxvdcpPliwuLYV1sKuuuqZi s+FN6d6a0Y6TJ73SZzZWVqr1vH37FmJ9fbu8QNivkwuY5buKSzvz7aavJr1k+ps3QCBuJEHv7HJg /4F45NFHii2vv676HpWvNwilcEc2tneml/xMLnhVN3xwfDaVzzV8CGYwk0FYGbqTPKMrNJMOh3bf 2YyDZEpPslal7JVXVtMs6aT8BQ2JbSQ8+JWApO2+/JkHneSfDgRSQcjOOsmP0x4+dCBM3X7jscfi CiPW7a3SM77m2upnfIouSveganRoi97KxqXiiv0Y3xxCRv6SDXvqBPboEB94cj973nwlg636Und6 6LDGn8ZlIqd86ME1PLOXs6Qun/GSeVMv+QwP6sUnOuzBT9E1owG3OihS5efVbEfSSZ5LhrEGWJ06 wej4ShCMqCPxpd6U2z2Njg6pz4K+2EAXZNdwsBmdZQOGLlndc3aNZtpXfvXJj8fUibzoSnSvPrrR iTVLgE/3+Dka5KAPGE0aGmMNuvpMv2qwLEUYXaozbe25WORrAfTNZ3wmH7oaevpmOzy9973vLfz/ /M//fLnPHjof4x0QfKP7pHOt2pSjIyueeg2cpYabbrop/o/Xv768qs5LJrxl6e3/9W3FD33V5NCh K6oBjVFm+/T3Z2u97vbI2oRdbH5BtmzNNwKr1csa1Ste/pLCQPYbT08C5FQEt6jS6Z9PT8epFO8p pRKccpAv3yPg2INhdPscql2tuCHme28MvfP9F841v7R0asG8vAHES071Gv0S9djbuTlPAt7nBB4e EsBAwOEYBgAYRoBjNCBy32cGBrYEBCdhIMaSgGZ6pnoRayq18DIYlp13ZUFnrMe9vFLVo+zmlmE4 mauEV/UCXoLdk/xMBxxFSr7JQw4yJo8VteqnOPCfKXuBrsmcyVSdsui0GtXLT8edJnXI2YykNja2 SoNd84tmgo/vmJ16uS6nrCQ6ftwvgFf12yTBVunIfkKInOzQLF8FSG6qc7UKW3229mrETmZvsBCI fVdRWltfi/nZ0y+crUo8+X/qJW3vKVr0SuZ0YPcFBEkQSIy4pgMp7Z62Up5MmcadVZ4zn2e+iznj 3YEX5zSluh3kYt8qWFZBMv3zbPWe5v5sT5/6PX6DB5jEo8/O9IknvCUW0u+eei2nS6BP1+pgC/Sz 86YeuE+/USpxkHZPfCTFM23tfjZo+PdcnRpFcSbtDM/qInfKxz4+Kycv/pKG8pX9Kl/02fOMO+pV hjxwlDK6L4/6Up9JR12ZT7wQy8Qsn3XE8e2zzpl8DjTQz/qSr+Q3GyS03VMXfeos6AjSo5kwyzBn ptRD3nct5dln/PUG/ag3J8sAyivSPvHJ2+KGV7+mTI77PT7R9u1ve0v5JZV9Bw/FwUNXxL79h2Nq diamJuwgr+g2/q/f+s03aQ29zup3/++d11mVRfpa/MIb3xjPuap671qC/nQYTBcRbqq/ZLpaAfGc gw3j2LGj8YUvfD4OHPBdgkfisztvOnjokYfj5ptviT1798bi/EKsb6xHv9MtC6levyOoWGRnBEa9 69OfLr3Sr3z1K/Hhj3yk9PhmpqYLCCjV4qmRiZ6DaULrIxLjK68X5dBjs1ZmlCVwa8gkeSyOogWY NlPokTAoJwAC03cWeE2h6Oncdecd5cu/yif43n3jjQXUj37jG/GR//cjpbFgeMGdIc1T33ffl+Pg gQNlIRVNIMKzIbuerHyAw0klgNPbw7epCK8IAn55yaGXZVSJtvvK2SyiHPnJ6L63XBiduZZnq/wy 93Q06hbTt+PBBx8oG1LYzSuZVldX4tChg2VtCB9ra6tFL5+47RPlnZS33fbJeP7zv7M4hm32eLZ4 /D/+xwfimmuuLjRy0wK9Ch7T0zPR6egxVo05bI0fsJnXpkhvufmW+Hff/d1l3eC2T9wWz9lZD/Vl 9d0SZ4Wf7NSQ35w/u3rLDJ1wetNFdOK+wCuxAUwo75DXtYSu60zkyoBKTp/lHc+TeZ/qOXv87P+e 97ynjLyN0EzBHzhwMB566OG4665Px7XXPjduv/1T8fnP+7LuwSKz+lOXZzs/VV7OzA/zZJUESr5C 1+7bJMBvBFK6GNeR/Bkoz6T5VK7RHde1etnGkoKZGH5lMwgf4L/joxX8SOONAZ+GDyOFlAufpvgt UZhKk18d/K5sTtvpBCc+1Ou+utCQz4gp+cwGJ7GBN3zi3bQk/OFVo0yX8sOi8jaW8HOjMTFKQ6th sz6oTqPBjHdigXhm/T87Exoi8rlGD300NEhioUZK3WwpdogV6safe+rkL66VcxZ78E6f4pfyrtHf LfW6OqqjqDWaMao1y1vaH3rkkXjvjX9TOs81CxC1iP/0E68tX+2atWt2bj4mZ+eK3PmaO/XsXttu 3OzyPA1nR1G+TofBLGTamWMa8pWvelVpyPzQoalJAfqeu+8urTYFy29azoKkxVxAFdQ1VpNN36dZ LaMkRjWlwDAMltMLlM6hgNCiKuMyNKPklA0+NSYaOute5t/V85rXvKbwYXHZWxSAQX0M/LGPfawY H0/4Md2AB8FH8DMXrfepbuAX5DgLkDK0BVxOo167Ji1am69/xSteUQAMTMCDJt7TQQUy4NWrwT9H AySNrwVZTmSqRB6yAiiHEqjpknMCJnoHDuyLn/7pny6dBtMqeNT4/Oqv/mqhgU+Og5ZkrU0yHWq9 0Y5Oa4sAbcHcc0GMLjiw9Qp1kyn1wJE4wYUkdNlR/fjjsHTJBjmCPB8demErZST2Y18BARZgAF7c 00mQ6F1iw7zOe+XGTkMnGHFasqhDyjO9CSroX0xifxiBI3ojj2DJfnbnsin9eqbjJ7jDu2kk6yRn 8n0xvJyt7Lgd6VaiA50Qu9+sZzvGExkcyl4K/mCWj/B5NoRD/vra1762jBjYgJ10VtJe+FE/veHB LAu/gF35dHrglW7JxefytVnWmsQL/ibYw6H6NZp8XmfO2bQbO4g1fAw99qEfB/zQA/qwhme+9/rX v77gRmeLf+Mf7l/5yleWM1/gf3zLWVnxxy+nk+nd73538U2xRln86fgoh4ad3mKZTj/8iM2+gE1f MCsOiQ3ehEI+DZ5YK7aIjzYiqU/D5fVqpipNX+JF3CGnt+KMY2Pc/pfr8+mB1mWqgSKAg/NROsNx UPcBgDItWjKy6aTVlZUCSgqV5BeIBLUMSM4UJkgDlEVMAd3IJ3tD1o0EFCDQowIq9QGscj4DigYS kPFH+cAFAPgRrIEW2AGFHAleIzzP1QMAhtnADiAaJruqjBIBVm+J05AbXQ6lDB58BjZ8CkZeqKmM vBI9kVfwtekAgAT3XMwmCx06BDF1O2voNGRADGRGhhoYGx40PvShUSUrvQGo567xij+BQcOMPzTI gWe0dUY0sHTmYCdBF690gQ+fycEm9MseDjqV3NstsUc2voIUXvGAJ3zsluR10EnaGL+u2QovApYe txGyIAMPkmeuz0xs6JDQyrO8yuBXYruLTWjxG9jTOfjhH/7h0vnJjgw5BHMYFbzwRd9sqNzlTuyj /vG6YCeDtEZY4wsrqTNnNrkUDRn5+Aua/EPDkf5IR3zfNfxK7IUXKRsyn40m2J8/Cfg6OOjBOdzo iLsmi0Q+9uU3cK5jwTfZ4w1veENpzNAX9HUgYYyv4xUPiSt6oDs8oYcPPCjDR/HE9jpb5LETWcyh c3V5hRpf47tiIPk1Tp6JEd4pCs86FmirX0NGRs8NKMQWG0DEILQ0ymjBsriCB3ySEx/04Tl9aLh1 msimEdXJFGsuxDeLIi/hv0swzXh+bhid4KZIOKYAqpdD+c++6qp47LHH4yUvfWnsXdpTRmfe3yeo 79+3L3741a+OW26+uTQ63v5w3/33lSDm7SCuNR4vffFLSiDSMNn0wViMr4FTn3pyWz3lC84AKjAA jO3rAiNwCdZ6lHbzAJiGkhGNTPTY1MeQZAIitNAxkmRwANMYGHFpSBjfbipnPS7lNCYMLq9Rn/t2 TWmsTSHgV514kjQGygEiYAnAHEhDyYHVA7zqICca7ulV6Yn95E/+ZAEWR9OjpCONlEYTAA8ePFBA bSelDgKZHHQoEMhDJo0459SY0LGGnD5NaeFdfnUbmQlgRrYclB7RxZtremYXehTM8H2+BDt40DPU 8eAoer3okn+38nSX+dTNcfGKjuQzOwheeKRnhzqTtvKSOumAHO7Rg0Q3Gmn3BABpPFCWG0/znzqS rgAF17aOC4hGImxNv/gViPBCvzDunLw/zep3LUYX9ES3sOqsYwMzcKyDw0foB88pT+p21wp2yaBO 9fAnfgvb6kucswO7sbd8DrrCJ914hhcBn3/D8o033lg+8x2bEWxv17DwTXGGLHQLS3zEbml02F6n iMxGKGzAHvwWbTyoiw4SO8RTli9ozNSvPFzSoZGQhsEz9HRk8S5miAFiadrYWUcm60KLLVxnB0e8 02gpqzEzu5SjNCMzfJGRXnXgxQJ1izv0hg7+NGrikNkSnUwx7Y1vfGPBvfLynynn2UzZ89WcnWlG Pw1mn8RDDz8c773xPU+aZvyPN/xEiPszM7NlmnFq5punGS/BBpCzsfjke4ACyIwN/AznwLgvW+sn +Vl2C/xry9UXRG0uWFteLsb3E+7eCGE3I0MuLC7G+pZXRk1HbeftDII/4ACAusanoRiBoYEQ6D13 zWD4EFiz8QAONAQ0IHNwALwrr1HQ6LnGi/Loowl0gr0AijbDqw/w9Q7RlXz2HCgkdSgDNAky9zUK QC2pS53qS17SUT1Xh2ty6TAkj+4BNBnxX/Q+9t5B70fM++ik3vBDbuU5ILpsJ6AKFpmqzR+Nwn/q Ai/4BWayok8/Enryjes2aeVZ2Uz4UKdA4DNe0OOQGtTdUuo/63WNhpSy4Y1+4FSDn/WPBxz5ye9Q fyZ52R1e2AUW0s6Z52LPAkpiRR3ZMUkcoE9H8AYz+IPDZzLRC/uwa8pPv+6n7fHjWp7EQNriYnhF L+mkndFLDLrH7vyArTKw40GiR7YWP8QB+XW+BWR5+KWUdoAVGOcTUvq9z2kT9SmLB/Zw7aweOnB2 rS5JXnTJkh1Gz1zzwyyfPpl6TRnTvz33DE9kyecaQXJ4jnejP1g1mjcNTDfjSX3oyGs0Kp7gMWX1 DG060dHnn0aNrjWidIOncbryS3n2eWN9NXp+P7E1GaN6q6yd2QDyuh+1AaQXtVG/vOv2nW/9q5iZ n4v9Bw7G/sPPij0HDhecjW8AuezTjBhOBRMMsB2Evf8r95dRRRF6arqMzIASqOwEnNvZpLC+slIU C4SCu9cAAdvKarUdNZ2F8RhfQEZHg8EoEkNkcFI3o1AqQCknGEiAlD1zwERHXkFZUgZ/ykmMh7ZA qCxZ1J+NIRC5x8HxI7/PghOwogVUgIaG3pJgpUEiq7ISOUxVSMkLnoHN4bM8ghkwKYd/oJXonh0E HPfoiT6ck3/56AINefEuP/4yUGVDhkeJfjI/3eBFXp0C5VIfwC+lQyiX98qDc/wjg3x4VQ850dSQ qWe3hB+JDcmKFjr4ICPs0AdbsEvWlVhRh2cOKe3umn7kc08nhH3ZhuyXKsESrKTN6SMbKhihY/VK eE3fYgvyXu6EH/WrS90OOlS/Z4kTfLjme3QvyXOxiR3gXv3ooc3HjBzYBm+m1enMczFEki99i/3Q EZDxJ6+ZDT7poFd6TjvAVPJOVnKp073EJH5gPPGiDBryq8tZ/cmHz3xU3EjseaZc6gxe4R9e3UMn 89J71u0ZP4YPI0T5ddLcRw+WNE4OIzx8SikTuvKpX5ls1NFP7IlV5BajzGxoyCQ6UoZNxhuy8vAy /7vs04yMquGxmGmYbirK4qopHcPJT33qjjh46FAsLFTTao1avSw03nrzzTE/N1fKUczW9nb8/T/8 Q5nG8hqmT91xR3GcZ195ZQEMI1vYNF0EQDZVaBgEdtfAY/rSwqZhsLlew2ND8AStaQOLsBoNwc+X t21c8Fmw4gimvbzaiqFNEZpmMM2ofmDVOJk7VodpIDssTRUoqwwDW0i10cNcM1p4BjCfTY+YOsIT mvIDmQBMb4KD+ny3w3dBTFtyXCAyFWIOHJjIjR4nQwP48GDqER1AfN/73hePPPJw0ZM1QA7gvsVg dOW1y099nIYOgNcXg9nE3P2dd95V6HIIulCvqTBymxq0ZmAqg6wSR8EPx+CAuyW0OCR9cEoyWU+F K3ZNZz4XnWxgBAkY8GYHGGT3P//zPy/Bg4PaHUpvAho7Chz0rg6y+awuBzyggS9TW9ZH4U1Dj0ef BQp1onkxiY5gQ0MLn3/2Z39W8MRebK0edrcZQGAin+lxU+N4d1zORC90RUd0TT/q5EN4oiu8uC9g p83lhTVlLyblTAIadJ0dK2tEfFV9Rg78gE/CraT+bKjG9WQqm17l5TMZT/g6P4P5LGd6325Bwb7y hTvLlC+MGvGYcsSDWQR2gnllxQH6Ij+d8EvXlif4CjlglR3xRsfq5nv8wWHKEQbEC42WuEZ2mDP9 zz+sl/M/+kdD7GAP+qAHedGkQ74A++Q3jY8ePJM/+YdzeTV06iWPuIMf9fEja4diALy6txv+L+U0 4+VF+k7PXSMGGIKlIElRApp1lbW1jbj2mmvLW+e9ENVuRutRn//c54px7ewRHJ53/fWlDKdgCA5O ecDCcSjZD3cyMCWqKwMBI+jJC4IaKOWBQ2Ond63X4p71Mo2X/HgWnIGNcQAL74DLUORhVL0+QUYS 9BkXsDUE1svUi0fBU9JAoQs4gCI/fQCVZxaqBXyAJx8QAjT+AJED/NVf/VUBCR4B2UiAk1gD/OVf /uXy1QGf6RiYgJK8ymrAs9GiM19exwP5OBDwk0397CAPHtRNbrrBJ0fgFF6wS8+/9Vu/daqHzl4c wvSERkyjlragM0kQUw8650t6yAITfujT2qREJ7s5inzqoRv6U7c1Fbahc/cFHXStewgo7kl4txZF Z+ryjB40dOyig2LjEqzBledk5uDKsKdylyLRO/7Ja42C3iTYZX+dIxtDNMjWLNlRQGO/y53ILamT rsnMZ9hJZ8s9GMrGnQ7hGx6UudiUMwVoWfdVP7n5neAtkDuzsZT4S9vgQ8KXTrcOyi/+4i/G7//+ 75dNHxoamJdPWWd54ZGMXrdnV6z7Nl/wdR1aMYDsOjc6t7/xG79R7qkLr2zpuUPDqjxc+joNv+WT GlA8yaOh0nFSN52zu06p374ji44mvMrL/6zT0bNGjy7e/va3FwzZyKLBoiM+Lz8fcE8d1sF0csUo cQ2W8SoG8ncxUCOtMRNTDErYNzsvbI7nn/mZnyly8ZXzJXr00vFhvRHb3mpv/cxaNFyVLz2fr/ST n11ct/HJtM55peco4BqpABalCbYCCsVIjGQ347GjR8sCrCBH8QwmcWDg0QBQLmMCjUaN4YCWcTwT kBhHz0miUPeBQ36BIe8lLUB1D3A5o0DByHhVl8bHZ70UzwQuAUsw0xgCmEAG/K6zjLoAAsAABNgB gy40XOQBQo0FAAOCMglaQM3giK5yAhqAqo8j+Kxeju1dbvShweE06AIMZxGI5SMHMKrfPTQkZ/LR NXv94R/+YcnLRurCfwFfrVYCOX7VI5BmeYFXHWzDGdhZGfJ4BqhoSbs1ZPIIBpxbz/ov/uIvSoeB A7IRPe2WMtiSn9Oho3406B1vnNQOLnLSGT0IvmzrkPANK+jRqU4MGVMv8EEXggaHZmO6vRQJXfik b3R1ONiJfwgitkcLqBpY13r4gmkG7EvBw7lo0BfbZoCWj67xiQef6cgBx/RI93R5qfhjDzywJx3B Bf2wHX/zDCYzuU6/hAlJXnn4mFkTjV/qHE51gozGBXB2JQ//Nyrx3EYRcYHv6FA4q0dHA2Y0Npno SnJfgyNe4QMdszJ4Qw/G+RAsiltsq/GAWZ/p0mfPxCNxFu/0rDOmc63DKy7gGR2dNn6Prh2NRoL8 8pd+6ZfK667wTnfspvFEV6wQM3TaYEvcduCPHmCf/sgi9qjX590aMjpQjp7IQh8wARtPJz0jG0Ao 3kFQDAvYpkRs6Ni390BsbG/FzGTVI97e2CxG8WNtHEJeIwmvOvjsvZ8rPYf21GT4Yh2jTE9UGy8o gAEZDaAFY4phDOAATKM2oy+7d+RlIIZg7AQYwBqxARdDqRvYGNjUg+DqswYFsAFBfuDAL8MIZkAh 2Gl8gAK4GYzD0AE6nB1PgjVHxFvyA9h4AAjlHHjDK/kADF8acQ6lDnQ04kZD6saf0a8OhIAoLxoc li3kPXz4YKlTHnTpiTNwEp0D8nAgDkOfHJiugND17bffUWwioAA3GhyBY+Nd42F0hab8kvIp09lA q85M9KMcvZCHngRDMlxoggll1KtxpTdywBbH02mBETZVd/JJZomNlXV4Rnb6YltBjp2cJZ0WdoU7 9wt2y5On9y/1Bot0rPeu8cKvzoWetDz0TfdsQF4dHLa83EnDz94ZgOiPfuCNjlzzG2f6gyufHfhm l4tJ9DLeMNKLe2zDBmzI3nyOf9AhHtQrH94lvMKruJEjMXrmZ3xLx5hd+R/soqFD44BNB9rsoFOk Mysfe8CM+szO4JXcgr37rvGGFz4LM2h5hif80TG5+KGyYqmOC57Q8VljqRwZ3adzdZIdLZ1mtGBE rFIPvzRN6vtw9ATn6cOwxUfQhycjMjMR4hf5xKp8ni8c+Lmf+7kSu+WlSzyPY5DNpTz7vHzyeHnZ WqM9Hb1hLRqtibjz03fFj9kA0t+K2rB3wRtALntjBtgUkkIBefaSvCG91WzHth+23FnX6m93Y2p6 Onp2A1k0Nc9uN54fjJueKsankrXNjaKU2ckKqBwFILIewMgeiXsUCFyZAI/h0wnzPl4lRsUnIAGE +wDM6A5BVULXgQ7wZS8KANSPDpCoTx680Ala+HVOvjR4AAh0yS86rrOnl8FRWXk9RwN/8qkHkLK8 +smZiV6yQa3uVb1EMqGHloY+G2aOhm908EkXkmuy+MVoNjX9KqmXzjhL3htvCEqmnXx4VueZCY1M ynJgDokXtH3GZ9om857tnDqmJ/xqwDTkkg4F5079CwjsV8lV6XUcH2c6Jxro40c+dpXwmcGh3LjI f/gUqCS6kNRFN+zB5jBGn/jAT+qsZL6M//BAfw48qZdNXeMHbhNLnuPtUqb0D3hTN304Ev/qghN4 UTd74Q3fyaey6VdosDMfwrtOpaQc/tGWH0aUd4+9pfHYpk51sIcyruU7E+/KO/L+OA0dQfhMGfOs rsS+e+TBs/r4dsqX2NVp1/BIGQ+cdbrxJpY501HGMDzRIZ2pg15gLOstxHbeeqSTaSSrvEQ/8qof L5nSr/Ps/te+en9pzIJwtxQAACAASURBVOxm7I/qMTE5FZ/5X/fEG378J/7/t5sxA5BevsTx9C6d GeuDH/pgAX0KTAF+B0xg2d7YKFMqR3Z+bFLPQPraA18rw1xKpnRnxjEEtgDpWh2MC3QMRIF6E4bi GfhNzTA0GsAqv+E94zCM3gn+PXMwJCPpvQG6aU+jIp/RFAh9NvpxjZ7PyuFDo4I3z/T4AJhM5vrR d08QlJSR8CYBFYczmlKefpTDJ5055DX8J6+eoR6az1LqiGzkov9M8iZQPce3+gRRvTgJ73RBZptn 8K2cnimH40x4Bl68mXfXS8WD/Gjim5zyyofn3ZLGxzoCByEb3snM3njcLbF7OjeHTL3RB96MyvBk Ots5HRK/qdOsI5+5TvtkECIb/SgnII13ILL80zmjxzYSfzHFaLQKK/Cux00PdOPsvmnTC9HN0+Hn zDJ0RK9wSwc6VPTND9gKRjLRj5SYzvsXc1YfHQnGGk1nU4swBzswaLSMT5hhL5/xhU+JX+FfJ47e xATJZ7JJ5IF1SX500KBvz6TspPM5dbEbflw7o+e+uvgA2nSBls98Ut2JLX4lwbBDPqMyfCoPww73 0/fIlJiHExuG4FE96obLPFvLNqOAT9gW15TlB4llfLlHz5Kz5xk/XJuZSt9I7Cuf+i0Fz/GPX9Mj HTl8TtrnKHLO25d9NyNmgdxagqlFDmme1pD57s98Jj72sZviuuuvj31+wr5ezZky1lfuv780SBoB uxDteLz5lpvLguY/ffSjceddd5XhtS9bM6ZeBuNRBHAL9GkoQAJgzzWqpmYYWT0MypieWzQX3ChV vXYDmS4EAJ9zusG8tCkIZ46DnkZQ0higYSrSdAXgakRN90mMZZFZQ2o4jm8NhClAw3U9cHU76A3v wAQcNm9oRPSk8EOX9GiDBBkEMQFEGY02J8anBokjGinSi89AKP8DD3yt9Ko4v+ecSWAnt/cAAiew qpesuQEhHfQf//H9xSboWQDH/+/+7u8WfuRlaw26qc+0A/twbA6WAa4o5yz/BGsNuGkT+tB5MK2i PB3tluSTMoDhGz2Bh5x63nRlWgrvRm3444h447g+Kz/OLyfnwIKKc8rhjE/6kEe5i0kZFAUttmVr ax1G2HaVwo11GTYVVAUk9la3oIuPy5noSl3q4YeSa5jGF93Alef06KBTeRxpn6fLo/r5MXuiRy9i ACzCLfzwR/blg+pnn+yc0Sse8M6HbK7iA7luRAY25h/KGrEp67PdmvwpGwtr8uKd+zDPNnhT1hSl cqkj+oCNxA2d6LSJKZL7ZIA5fqfjZaaDP/ksbomLbE0G04VGX+qw0xkfnos3N9xwQ8GN+OaajOhr GHUAxKdf+7VfK1PuBgH04YvjOud411Cq+4/+6I+KLTWyeBNP1SePRp1s7vNzZVO357Otd782mq1o tSej3myVWbkTJ0/E3//t+yKatagN++XdjBfypendu7bn4+QCnnEoyfqWdQ4BiCLdBxpCZ4NHiZ2N avTjM8AIXBRlvtk6AEXlUJrjnjx6rIBJfoudwKwOQV4gEKiskxgGC66ugR54zP0yiACmgRAsgER+ dQB3rl0J7kBr2y36gkquBaBp4ZZjaZzUAyB6hj/7sz9bjM058M/ggimQou/g8IBGD55p5OjIfQm/ dMWxOIBGTI9T4wowGm2BWH3qUBcZ7GTSe7dDkwPQJzn17tFD54orDpVAw/EdkjrI6G0B+AJYHRH8 aZyV9XYAMnBuMuFXeXqjC/piEzrxXJmc6ki5lM/PpeKz/ENTHqNEfMEQm6DJyeDhQhL+8IqWM73p JAgGGgF2MGqDG7STL3rIRBblPMeLRKeSAAlT6HiO9qVI6KXuvOGDzgRNus3Giq1hgf3pB65h5kJ1 czF8soHATL+Sazw68MBuMANDiels2C6FjthBoIVN7wgUJzT28EovYgJ7a1zZSkzABxuxJx7xg0e8 SjqAvkrEZ2x6cIZnHTqbbtSpPjS8JUTHVKMlfqAp1vAzttPYiQ8aUj4qsR09JX7RgzN84c99DXJ2 PNldI8PGeNNxxit7/8qv/Erxd/LiAU9oaMDFIbKzRb50XKMK4+KcfOIZTOMPrnxfTCfPPTSsO+KD HtWv4eKT4qZYKw6J4WR45zvfWfxGffKQf7eko+P3C+sTU2WasTnRLriu64QNO6d+kWU3Op5fXLfx AmpgXCMUQYMRGFywFTgmJ9pFEc16PbwBvVlvlJ8DoJTDV14Z3/eiFxXFvuCFLyy9CL0djQUD2SDi N89sMfWiX6AD2ASrXolrgd6vAGt49Jj0YAVx+fHBEBwAoL0c0zSlgMCQwGIkIGjoEQGh3/5x7V1m en16NwzuMwBqiNTD+BoDwLDbD6CNyARO23nl0zi65tR6cQAJZJncFyAFVsAgpw0LgCefHiP9Gg3i 1c+jo8mZgJKOORVgCoichaNY+PWVB8DmpPimF50DjZe8nAXv9I2mswMfgqQgwMHokDOj61qiU42q 4KFxw7M6yCIl33S+WyIDPehw6H2izQ4XGqw1MspnfjjMdRA20Mtkdw6YnaVxnugXvxL9qZtcbJKB EObSRpkvG7lxWk/3s0AneOKFvulCgwUzkoV3ujVDIB+dwYAAc7kTPNCJBAP0zT/pEp8aGjrOTgE9 k0OS91IljaWGRUMGr+rgp3wK9uCdHeVjK8/pB//uOxul4Petb31riQn8VgPBTyTYM7KnY7TJxNfJ Ry54hjV45+saSIeALZGXL8rDh3JaVDk8Onsbh3waC3Qd6sSr5yX2HTxY4pr685cfNGL0j1++jFcp GzcNEXzADPyboSKXEWvGlN/8zd8svGowycd+aStYJ6MOqQbMfeXYmYzi+o//+I8XHumNPpXZLTUb 9ghU65zTM776UHXgh52tGOZLEU71C3Ucz43pS7AB5NzECUIgji0QABmDMEI2OgwHYJQjD6AIgIbD QLC9uRWDUbX2JQ/HcWZ8+YCDwZzdRys/c3BGycCiDCBJlC0BiboYST40GA3g8YLXLO+elEHZ5wSL eskiT549V58D0LJO1xwIoOUltzroJINl8uBafs8yPx26Vic6eCRz5nVGlyzyajABeJwvvSrOxD7y 003ypyHTCHKidAqAxYe8DvKodzwwkFcd8tFL1pe2VBd9e07mrFu58yV05Fen+tSPDvmcd0t0pIx6 fU68oeUe3cMmPEnsi26WSfuzCT48x1M6rHxS2qRcnOU67z/Vc+oRHtVF7/hOfdA1HlOW5HNcpqda 54XmH/dvZfCKx9QZG0lpJzilw7Rf6u5C6ztfPhgW7NUJr+ycGFOnxHb0NZ4Sl3iiOx1UuhX4+ZzP yqGBfsYx+RNP6CmLFp8jl894UZ987mdKrKSe5FWeDdl3PLG7eukWD2iTlXw6nvw46cmb9eMZ/+hK +E3fVp+Oq1Gnzhzso5sY0iiij7+MC6mDxFry6yexNGo6+ORFmwyp85QFbSnPPm+sbUdPGzHRjFGj HjUvbb7ttnjdq19t33PUhhF+T/6db31r9Tqrg4di/+FDsefAwcLXVLtVvpuM1u6RoFT/9P+l4imf wgiYQKP0cVBTkjwUmb1nP1qdziv4MBYlyscx0FDOmfIlnz2Tx7NMQIUuA6sXAARsjaZ8AJfOhkcN YfKrbvkBCh1HgoRxGJoRM/CgJXnGGfAkoasuPCQ9MrmnrqStvkxGkgClDnSc6RVw6Ia+8j5wS8o7 1E1mZdSRIx0O4Bk6nJOz4Bm/GjJJQ5bAw688aQs0k0e6pEc29pkMqUt03JPwmwe69HUhiU7RwD/a PuM56Z6PhoacbsiJX3rEg8/0jyZeYIVtfFZHJnklvCa/ntMDrOCBbuVL/LkvoX0pUuIMHvGgLmc8 kA1+sj7P6Iv+yXS5E72SEz/0kHzQI9zScdoJb+6nvlxfbEJL3dmQwTT52cJ9/LErfSRvqS/XbCUP /Ep8UCNmJJN6hH26xK8DhugehhzkQ4MtPCOzOt1LLMlPT2g6y5dJXnSVH8dT6ofdyek5+fg7X0zc Jh35M2aRQ36zU2aNXMufvi2vUau36vNzvOrgpi3lU8c4n2TJ5+jRr7NfCfDCCrpwrQz66QfJ3zef s/kZ9xM/ZugYx4Z8eSQVz8fzRFyCDSDjjGRFp8+MR0kWBinIYqZ1HFNd5l/NQzOA4CqZLrM2ZMoL QOUBDtNDhsamxczhem2PIbhyFKzHoZzhruRM+YIugAgIypkKM61oTUvdpus8E/QA3rQBHtSpbtOF 6rBuh3/51G0IbkOGA/gZDx2NyV//9V8X8JPba504BkMLwGTNKUdz6DZhAJv7piY0NqY6EthkARAH QNODcurBo3zuA7nkS9NASAZ8yMux8YZHujd/jic0HOQiHxAqZ/FXGbLZJUfneqvusedv//Zvl7VM Iy6bTEw/mvbCi3q8ZQUdumcTU2PqUJ4tgJxj4YdezpdM8zrY0nQm51QXWmTerTwnVSfb4omOYUM5 i+0CLruY1mHn5IkcdO5aeQdaElpsCB/WH9CECfnZ0rqnniqbXmzCB9nZmg1M1bMTnFi3TT2qH27o 27SzunON8mJ52K08HQlseMmAZ6or14bZno866DDP9HWxiX7YMm0En/hhE/jw3JKDujRKnsEl3Gtg 3McPnYo3sMwnYZnvWG6Qx1JJNpwaNvKaohNH2EWDQO9ikjLsY90ITb6lw4zH1EPKjT/3yKA8bNIR LMISnLO9qT15jKRg1lII/4NpeMQfv8KztUINpDUw64iWNcgA5+qCW7yRR13ywo24yA/QcIYfMQxf YgpZ6JT+8EAH+EdDB4F87rtHf7Bw/lSLXpe9/DhnPez0qNVr1Vvz33NjKapdq0ct/uMNN1RvzZ/1 45yzMbWzNt2Cp51Ksmk8f50X8ZQBKAdIGJQRGJdSczjPQBQgCQLmXhlQ4LbgyqgUnb0nDZ2DMhlU eY0kBVI6wKKtPslaG0N4xskomfPr4TjwKK+NEda/0ARuxgZS14IokAKNuvHmOUcFXM/RNnS3XsWZ gITTAAN51QFQnqGJtgZVsFcf+YATKCSOSUZOpxHlONYT5cerd8ihr8FBHwDpjUNpYG3S0FjjVz3y WDsEZCDV8AGfJDgri1f0gJ8u6Ipu8aEzgBfrkBoWdWjUrc+grWFTjiz0o7Fgd/ziHw22IR9bcdTd EqfGOxvZlaUxJrOEl90SfuhaXrSslQq69GCBPOf96ZM98J48op2NRdbjGi0HTDkLFnBg44v1TPoW YNj6YhM6UnYE2EjQghWNGQxaS8SHICVgCzZ4gJ/LnVI/9JwNGTvzP77CZwRA9zLRr5Sy5f2nc86A KX7AMLnpKDc8iDcaeb5IN/L7LFDjiQ0z4QuG+Qcf1RjwZ+voGmbYE7glGBaX2IKexRFlvVJMB1ZH kG34iQ4y38xyGev4DB74gs/oK6vTjrYdy+QwEMAPbMKyxgqNv/mbvynXOvIaVj5NNnECDX7LR9Xh vbV/+qd/WmRKWfAmFuPv3e9+dznIC0c2hngrDn7USW6xhy4kmLP7Gi3TjPYU4NGORzzLn3KWAs/A v8vemJFB8AEaDujsmuL1+CneQiRAEF4L/5a3vKWMiBgPOCmG01C8IOkz4zOiHgsgKceQAISWIM2Y Do2M+tTNgTiegC+QAYaEpnoE8wQ8murTCAG4gAI06lRX8iCQoCeIALdyPttgoKy8HA1tfLnWaLmn gQVmPHEQdaeDAiGeJGcAJQdAATsgyatxQcPuRXVyJI2I8vjhuBoDhwaJHOhwbroHViM1PAjA7ML5 BHe6pU960wBIphTcJwM67pNXfnVoNLIzoSODdwFGUCMjfUl0vluiYzhQP4f0W174ds3WuyWysYG6 5BcANDhsCBcaYjyzCznlo4fU+2706Vfv12Yf9G17NnKEl0sxzUd2/kJegYmu2VbnwDSRTpQgrD5n 9oBRvJDjmUjqObMuNoY7vsDv2J9+pbT7mWWeLq/osQPMsSud8Ht6oCudTbup+Qoe6BTO2RiWpLS9 PHQnVqGVeDUC1ylTl5jknNd8gU+qi0w2UIgtaLqHr8QXG6X86oVvfuEe/+FH8ooV4h0fN4uloSPX y172ssI3mcRLnVU+Tw71aJiUgRk881XY0EgZKOSmJ8/EDRtIYMtvmbGXTpk44x5+YFmDplNCh/Sq c4lHsZF87pPbrJc4pJzydPdMpss+zUgoggusBGY4AZzAlMdQek4CDsAL9EBgmoTiKZZB3Acyxsxg b9QmGFMmgwlclMlQwC1ooyEAoK8BQEPD45rB0ZMPyPACMMqnI+Z0jakuO43UxeB6+ADPYIKj4KJu 4JLXqIg88njOoR0CkF1F6Gs06AQQNQBo0AWZJLQdHI8D4h2PRkN6nKZA0aFfTqF+DpwNE/1I+FCW 3oDR1x0EWs7MEQV0PNMVemwE3ByGbozQ0JeX7UzDeI4mp2WbtA8e2Bpvfhoig4eRNVrjjQQbjV8X Zs/4xwlhheNxVjoiH3upa7dEtzo99Awf+KEH9icrGQQnwdc9NOV1H2+CjOtM9ADTyrCt4CNIKM9W nqGv4aHHxGqWf6pn9ZMBL2ynA0F+ONJwwaHdY4Kfr2Cwqw6E+xJ+L2dC34FPumUXnQO25jv4gRF6 oEc6kt95XK9Pl0c6FtTpn87hjg8ZddOTDiOb4off4w2PdAqzyjnTrwO/RuliBv8hF99EA174nmt5 4QUexQT5PSMr/1UH3Er4wQt9pH7c5yepD/TwxL80IGjhWcOYPPABOkNXHCCLWSll5MGHuKB+Pi4m qlMd7vFBdMUv2PFZI2kXNDzpDKuDv8O1OsjnO6JkpSf3HK7xCfumRvEqltInGurQGcDbudOlnWaM Xnd7NBoNRr1eb9RoNUcRzVE0JkbRnBzd8q+3j3qjUTn6o9HIcToNSrnT1+f+1Ol0RsPhsGTweTBQ djRaWVk5dX99fb18xof7m5ubJY/78q+uro6U3djYGK2trZXPMqDb7XZL3izj4vHHHy/3/Mv68oY6 pK2trSK3z+igK21vb4/6/X55fmY+1+h5nnTcwwN6nuEZv1LK7TP+T548Wcq6zvqz3pTDM3SSvnPS QSPL5r1yY+efe3QkHTlypJzH6/Q8aRw/frzwjX7eG9chGSXnpHnixIlyL3lFL2VNGjKM86EeST1p v3LjAv9l3UePHj1VIvk4deM8H9gz04MPPpgfC87IRhb8judjQ/ymDnwef+5+XjvnZzpYXl4+Vcel +AAfaReYSZ5SB+rEHxk8y/uXou4LoZH14mMcA/SA3/GET3myzPizp/MZHUfqZ5yH1NOxY8eKP8k3 zp/60lbpg+6lX8JAJjFJyvJ0DDd57dl43Er/wEPyIQ/5M+FnPDYpk74iT+ru61//ehb5JlrJF/zJ j6aE1jhtfKb/uE8nX/rSl0Z33333qTJZCX8706fxnTJlHZn/Qx/60OiTn/xkXp7zrFzKjAfNwOry xuj4sdXRidWN0fGNrdGJ7c7of95yyygade8IHNWiPmpGY3TjW98++of3vm/0L7fcOvriF784OnL8 2Gh9e2s0GFU00b3s40C9Dy266QZJ715Lruer9beepWdl5KF3oRdhdKEHotelB2xkoReil6D3opek h+o++no1kntGE+pDD13JCCAPvXPPXaOtpyQfOnoR5n3VhQ89enn1NtSBHzyqw3Nnw29llXFIRhDu kdHQ29m13qnenV6R6U09VKNDsuJDPjIawfmszjyji4aev0QO9WSSDw2jT3nwin/6pgv8Snr3ekyS Hiaeya+uHLXgCT02MypET8+LLujINCYa+HFmRzyTL+U25+6z+h3Kqged7K2lfQoz5/hnxEFO9kpa suoZXkiiE/pVnk7wSS6yGlm5Tzf0YoRLdonOlE290Y9Dohs6gUNJHp/Zjg707iXyX2xK3cOKevkG vn3GrzO+2J0spr7YzH3XlzulvfFH9vQB+nXQCbzjBU/u4Vd+drnYxEZoiQsS/8QDfdCTM3vn7AUe 4SDzpq1gUjyR8EWuxAAbGOGkfeWB+ZS1FNr5dQ5l0fcMDdcONMiOP4dn+E580Y8yfFKSV9zhI0Z7 meDXWqREj8rQAfylLtBHT1nrX2a3yG1kKnludGcEZtaI3HSER3zxUfKhl7xmXSkHOokvszRmAlzn Pf7+TKfGf/7Pv/0mv+o8GI7i937/92I4GEW91Yx6o1m+jHnN1VeVb2HnZMWw7ycyNiNGw2gU584n Z2edsQQj62CmQwDCYiFhTenluo8hL7BTliDslSyUqnGxfiPIWJA09LfuI1gaOhtWUzonNz2gcWQ0 P7LpmcZDnYyjXjubDIftuDO1ZjqCoRnRkF1dwKKM+mzmYGyL7YbVGi/rLob/aAgegJRBRD0WgoGD 3Oo07WOqQQJGGyPIZcOAOW6BFLi8YovTqId+EsycAUgsSJubN6VhbcY9U4P0QX82buBZXWQAYlML AGlt0tniLBnphSwCDQdiB4A17WAa0ZQNRzAnbopEXjrh4GjrOHBGOybz7SfqQPfXf/3Xi71MX1rE xhenoWd1ZEpHzuuzndXpS6ymj+DBa9HYTMBADw/nS57LS5f0ZZ3MjkD32J/dyEaH9Er/6MIhu47T T37ZQ55MriX5x1PmH7/3VD8n7wITnPjhVJhkL7bWqFvIz/Uajb8DTzAxzv9TrftC8qM/HpizPtN7 XrdFT/n6MZ/Zn17IA49PRUcCPLn4uzp9Vj47Uvh1X2P+l3/5l8We/IqPsU3qQ71oKM9PkycNgxcF 8HU4kMf6kIYufwfR5+QBfvgyfzLFx+81jtahlOOb/NhGK0sUeCWDesblhnH4tNFDbKEbfitWwbyG WGwzbWjXobgiRrC7Z+QXL/ErDzpiKZ7FNMs06sCvvHyIzD7jR7x929veVupiN/GADsQydekQaFD5 jQ6l2MCnrenRkzU1nVp2xrNk+pEc43K6ho+8V6+bZuybC4/ZhelYXd+I+dmZ+OqDD8Z73/v/FDq1 ofeDXNhuxtORpRT95n9+L02nPtfymk1z3b5Mt/vifVJjGIFCMBEMrRVRAmPYuUgx5mwBDlAY1hfw OK/nRnKCoWvlAIQhABdoGANAKN9cLcCpRwCkZAbSoGTDJEBo/IBN4ydYK8M45nsBxLwwIzI6I3AE DSqDAphgIljr/WVgQwPv5MCT0ZMGV2B0qFdZPPmML3nw7blGUzkJLXn0OD0jc45iAUxDDRQ6BD4D qyAGzEacubHGIq25cEEPIOnHyEqjSAbO55v/QIZX+QBWPvrBIx7oAfCd6UZecqLpOV7wST69tOxo 0B2dpBOTjdPJT175z5fwxY6cQ6ODNt1caBK4YMpZOY4Kf+SmR/iBFXrTWfCGFwEOzrKhv9C6Lkc+ 2IB1vAvMdnSyG93TDYzofOhQwAJds5vOBiyT7XImtswAlY0Em8OCpLMAu/jlr/JkMGf/3fhLrDhn Up8jE93QkUDvMz/X6eUPfBtmBGB14yvrxw8748NnDYAY4CeidIbpXjmNAzzzKY0SWST69qopPqux 0QCkreQhmwaO3yorDooVfJXPpAzy0hk+PEPPzI31YjFH59QskIQP92CUb+Zr5chBdjFSPNXY6dRb n+ezb3rTm0oM82OeEp8iK59yiENim/waO3VI9IUn8QBt9fMLMknkxTv/fvOb31z4UkaMSJulvfAh 0XPVIahGoF/44pdiYmYyVjc34uUve2nBrgau6bu8/QpHpeAu/846zcjomXzOhsy9waDq1RjNlSMz nuMs2FO8xkOv36GHwOkoSDABmASIBsT2Vs/1dgAUaEzXUTo6gKcMJwFWw2XGozSKZ3iH0Y+8aVhB nJMrp/EEHgZPeTUK6KMBSEYgQCrw4QG/aAnEAAZ0DMY4ggp6GkK8ey6oaMDpgMwaCSMDdDwHAKDG D1oafAELz4ztmaQOtDkDByMnfaGNf6BWRuOaAPJaH2UASP0OIHQNyIK6BtpoGb8ACKwckuPRH1to GJUDdnLSTSbBgkMYAeKFPGydtPGEVw0W56Aj+ZzxmbwmvbOdlaMHMgoqAhHnkfJ8tnJ5j1wCCJtp 2G0nplvY8kwwypEl/ZFVYJAudCoz67pcZ0ExdUfHbEGnsAI7On70Su/0Y5Sp80f3lzvRJSzSr/qq eFH9MjF9Gql7DncO/Enywt1uCebgaDdbw4j6jA6UoTN1JDbxhwZ+HZ7hRzCmSzbHq2SkIYkR8vFX csmfMzCew4cYw1fEFXWyj4AvbzZKyqqH78rj7HnyAp94Sz7YWhyCRaNM+cQOdscjfdCjfOyPRzqG bzFOOXiAD/XAhUbYtVim4yYOmV2S3/XrXve68ro8uKFH8Qmv8tMnHshLfg0tfvi+++zons1v6qM3 cSJ9FX90kP6Of+XoamlP9Y5e2/vF+LXNrRLPZ+fmor/TISrGuIB/NZs/Rt4a0B+WL6P1u6OotZpR qzeKUV/5yldEsxHli2mauNrA/2GMhhXAJtrnf9ErIxmJMAqlEVKA0qMHIAZgfGBjAEYBDJ/l0XsW fDPY+kwJlEPJeiMZ9BmIMhlCY8Tw6kwQ564bDRLFahwZC1jlQRMAjeLQwpPGAmgYlgHw5bOgjQ/l NIJkUjdgMriRhM8ahOxNoaUMWZzVzeAAiWYGf7x5DiTphADhs8YSHXrBjwYJeAEWbxowOpEX4HLU Jq/7bEEvdCevetRNDnSzJ61XT4f408uiF7bhiJxKfeplT/c5Cn1qkN1Pp0vHSn3AJPnwJ9H5+ZLp M3WyEbDTAww4089u5cmJP2cy6pSQE/8wiS+BxlQRZ0wHJBf7fKtT6hqP7If/7PzxHR0c+MEvndMr nZNL2k0/l0o+9oAlGGYX+hbk4Y4P8g2JDRz4Ypfd+EusoH+uxBc1BFkHu/ITHRY+gScYl5JH9+BK /WjTGUzgzdS4svxXPvina9iAc/fJR+d0zwfVrU701AW3ORslr1hHXglP8uHFPWXZzTX/hHV1iDvp x3TqwHPGB/XLdJCmVAAAIABJREFUL57BScpDhvGOmPrkpSd5JR1RPJiN8DJ0tPGhTvFU3GI3cuOF jOIy3yGfxtY9dOlLnp/6qZ8q5cRPefCOF88keqBD8U8d6+ubsbm+FZNT0/Hgow/FgSsOa1niX2/7 RPzMG34y2q2J6K5tRCNqY6+zOrDzOquqjikzFDshZNfG7Id+6BXVNGNhx3uyMg1joIVtnl47yCfj Z8JSMkFSqAQQIBDOfY0BZ5QEWeAEJIJz4uyVpEIoCh2G5TDyukZPHteA4hlwM1aCSR3j/HiegQug gJthk0/5GQUo8JWBRR3yqgPPWR9AqO9MB1ReHjJ5nrLKRwfoqMdZyvrJDpzqw1eeyZ6N13j+pItX aVzWtAceUh/JJ77Rp8PUSQaTrLMQHPuHRzpL25KRXdkcHUlZKZ0FzQwu5cEF/KMXdSUe0tFThvOR gC26wCMaeKT/DGDK4jFpj9vgfHS/Fc/YL3GW/NMFH5F8FijY4Knq+OnIQ1d8EYbokG0TC2fS8zwD HDucK9+Z5c53rb7EhrNEP+qR3HPAYuJ8HANs7v44juhOmRyhF0Jjccl16h6tTHwxdZ4xLJ+lbvg2 ntM31JOxzBk2PUtd8Rn3MuFTnWi4nz6OTsYNn8mgLPk00pL8WV7DlrRhJ+VwDx0+7YyncV9LGuih QUemNXV+NfRSxnI88DO8Ji3PUzcbG1vR6/RjYXEutgfD2Ox2YnZmKj70T/8UP/tT/2f01jd23s14 YY2ZiH1KkMJJ9uZ2jKRD1OkMohYaikbYDbK1tRGd7c3CZLP15EXvpJFngDUcNcoyjUVZWny9eIrN qT29ET0b+eXRI2AEjimYy0s5jOM5pwYchnCfYuWlNMpCz2fPGFw5RnEwAAV7xogMprypOD1d9alD ObTUwbjKKM+geQ106kUnaSmjAXGtjLN86CnrkAd/gAe8+BvPRw8pK9kl/KInKZs0jcDk1xmgN/LR jV6bOtH32T1lyHem3uSTkjfyadCSJzQ9w6+8ph/pCG06kXQI8IcPDb463UNLwMhgQt/uSfKdL5GT LulYeXrDlzrUTZbzJWXkVR/MGdXhka3pTFDicHRLNxxxvCEm87cysRO/ID/+yEPv9OAevtnVKNqI jWz0w170T8bLmeCDjRw+wwfcsjFe8Jt50kfpmz3wSZbdkrzoONAk07hcPqvXs/E6Ycsz9cGQuhLP 7Ex/6dt4wI/y9IleJhjhg3QOD2jCVNI8U45xH1JuHMP0InapJ2VPWciXNnZ2eEZv4hmeXcvnXvoW XsmKJ3Urp05+6hmM0KHnMIEHoyd5yaosXhyesZ+kDvzTkZkZmEo9yMdP0H7xi19c8qNHJ+lv+Ew6 bKAuefBEl+b72GN5eT1Orq+EKcBWu9oRi37Ahg0iF5hqo2Hf3v9T04wDMabZGJtmfGURatD38s7J iP4gjh8/Gmury0Wp/TLteO7aKJ8i1UEZzg4BMIM4BTGAa3k0ehSlrHwUptWnZAoCQkojcIKT4dCQ Bx0pwSwPemihLwAmwDNI4CkNqTzFJ2AY0shIAMQrEAGFIXcCGq8JGvUoD1DyJ/gAMgO8xgBNzxyM rP4MCj4ry5GykcAXngBRgCODBITuS/SAHh6ck4cMcK5Tj+6NOwldcBj1AKTP6TB0m2ClQ2CkU/eV 84wOOWrykY7H/j4r4wzMDnYh5/kSRyKbfOkQ7EoG/OPzfEndySvdVM6zXOyDHr7lGZeFvemJbVPH 56vjcj6jp8QQXuiCTnIKL3ECi+SgGymxzj6XM2VAThzDgDrHbYsvPOONDZRxLzF/Pv7kZ2typm+g BYPqhFU6YitYVbf8ks6wOuWhDzx5rrxEr9kQJb7cN4XPL5TBJzr8TSccPff5oHjAJvCVeoBvdeCN LtxPvDuTJ/0g88pPNvmVk89Z3VLqDi31iTNkpb+UJ3WpDFnIyhfx6TOa+E5+4AhmPMNHlpeHXvCS 9/GAPzoXt5Th83ikd/w5o5G6JaOkDB2zAV75lgFDJWMj6tGI1kQ7NrpbMTs/E7oQn7j99njNK14e UW9ErTe44GnGZviqWXlR8TBq5WtnwG+ay/DZulQnNjdWIwbDmGrJO4hBZzuG3U4YlWHS5kmpaodP 7zoq93aCdSqy36+29Hcx2ZyIbr9X5kknmq1oTrRK8J6enSkKPXbieCzOL5TWmvKveNaVsbm+EWsb 6zE9WfVU5+YWylyu89aWzQV6G1WPQYAykBkMqrUtBqFQhmJ0vDPAxGQ7+lvbhRcgWV1fq4BUr4zV aFVvqHdmnKPHjxWjKYsG5xmNKvBNTlbTWRMTNlUYoalPwJ8p63Ceq392tnJG/M7N+UHHyTLibTRs 26X36g38KYvnq6vHY3FxT3Ei5eQlB4BOTwv6y2WDTq9XzUkDNZABVpFrdbXIzyHYA5g7HZ2Uao0t A6UXfn7j8cfK8xPLJ4uM8s/PzhVQq5sdHaur69EfDmLYH8XEpPdwHoxjJ+zIrJffpothLTo9emrH dtc0x1TUm9YuTK9UwaiA5xz/8MRxyEDfHJSTcSjBhXxVgkHYe/K5Xq9G2HAgCLATufHOsXSS4ELD TY8cj405m3o47LcyCSwwS3a80AUe8S1Q8QVy8BUykA0m681GOVq78J/rDU9XRljGXwZgPLrn3GhU U1brq2vltwv5uG3WayuncdhqtsIvY+DjbOfudqf4V6NWL/FBeanQajZKPFjauyfkK3z0qh2Kq8vV uplysIL+pJHsWtUYDXr92GptxczUdMHviWPHY3HPUnS2tsua+9ROfBFnyDPVnizrRFdfVa3ZHz3y ROzZtzfQ4U/9bi/4zfbmVokn+Nzc3iy/0Wi0MTs9EydXlmM0qH7pwm83wvKexaU4un6s0s9ku6wT La+ulPrYutep/Fe+ja3NGParXww5efxE0Qf+xQByqYdeal6KXW/Ehhmn5ZWYmpku8sO5dajtUafI 7Vo5esOX9ar9+/bHkSeOlHrpFT1+S49wp/zs/FzQ18LSYolBx44uR2uiEYcOHojlkyeL34gV7MnP 7KuAj6898PV45NGHygyCPqzY4ydf1jc3YmHPXDxx9ETs2b8njh+t3hdr4JSTuMNahY9sXc7WBa55 vUfu7qi3GmU7pGAYrWb5TtILnv8dsba8UsBy1RWHw6TAQw88GINuL0Yah4mp2OoOoj/oRbNWj6nJ apqws7VZBBBQCdKeqt5yHrVGTExNxrZg3PS6poipqXZ0bV/XEzaS03PXKzGU9XLNlZXYs7gYA9N2 GiNTAidPRr1mw8VkTEzY2lr1bgQkgReAZ2en4+TJldizZ7Fc61UJDoKUwMaI7clWqaeth2dq1bQg R7ThwjDXKFKDp4fl51w2Nsp9PwwK5DoDQLG9bVpRL9qUoy9hG4HqGNQLH4K3YGs3aKfjzdN2CRlp 2g00EceOnSiN2uamaVRvaDc9ZKSjFzZX6MhPXvTRK0GrXi9yCHaVLg3lt6Lb6ZSgLKgI+INetWaZ PclevxN7lvbFxkY1jdY33TkhANZizbRE//RIkQ0b9VaxTasxEcsnVwv9PXv3xsraaswtzkVvuxfD 2jBG/VF0B92YnZqN9a31qA1rMTU7FYPuIDr9TsxMzsSoPirXpq3xxh74zwaEXjkoXn1mJzw4JPcc bO2ZfDoHJ08eL3qfn/dL0mYDjPatn2jI9Dh1FHwR3XqhKbpqFJnTIhpMtNBVP9o+41HHSKfFfXp3 T97Gjv7xBlPZY4Uz9PRUBQF5lYGV7Nl67ruaZJfQ1pAqm1PunqlPj14d8jjoynV30C/BRQOBV2Wr jmOlq9ZOB25iourVo1d0V29Ex7qp4JcRo3DxzP4T8ASqOtc7y3m6PRn9EVwNYt33WwfDOHjF4Tiw d19s97ol5pyt3Lnoffv+2fX8tPQSzegPDXzqUR/1ox6Wo07PBAx0QNrTsbqxHgcP7ouHH3ks3v2u d8YPveKl8ZIXfV+srKzGzNzeWNvYjsmpane2XYx2sL/uhtfGyPfCDJJqtXj7f31r8cH9B6ud4Dpy Bj1+4DnTqQlroMoRVtQ4Qj16w1Hs3XMgOtvmt9dieW09Du7ZF/MLe0Jv6+SqN6HXY3p+IWI4iF6n +k5Cabxa1fx0NhyjWrVI3DSS2epEbzCM9tRkjIaVc/Z3pqhGO7sTTwXqnfeoadAEBA7MGafLd8nm ot8ZRHtiKja31sv0oaCztGR6wZsHqvUPDUuv1ymBRnlBhIIEnkEMorfztgt1CgaCjYAhnxGN4LC9 s1XeTw8ou7G1VRrKQ/sPRadTTW12OtUbL9AQfARM04r41mvWmz569PGy00xQ0WAZeVQN72w0m6Y3 T2+xWVurNsLkKE0gxD/baBQFx36/+h5XFeCr0Yf6p6aqUZk8eDGA0QNSroy6R9UbTlqtaoQ7v7Bg VB+dnV1/elM6GRppNtTz1YjNjk2fmq6dX1woNDc71dQOWeemq9+RG23Wyg7ZEnxH3oc3UzoOW5tV R6fWrNbpyE829eTnSp5qvZFNYYoskjrkZx+jSnzQkZHA3Fw7er1q9O0Z/WdDUHqCtZyGMo2rx1j9 RBF67A8TbFLRrqZs6TwbVDzmtBdesmGBCYd8En591vuWJxNansmb+bIBVKdDp4us7Gi6Wl406ASf nuHVEa1qm/nkdDWCcE+9jcbp6eusr983KrFpYDK2d9ZkGiZxvtWNWSrnLOeVbvUmCToYDWtRN3NR a8ao1ihnPfv0mG+fKwU+U3qoRzOarYmqQx/9aIx6URv7icxBrRlbvX60Jqbi5Op2HDt5suymvPbq a2JqerIMYGZmpmNYb0bTT8BouPyz/2CnISuXbu2MzEqmnX9n4rZpZnF4CsyN6JexlxvN6PQiVrb7 MTm3N567dKhsABELj3cjuqNW9JpTMdGuFnP1/Bfn52Jmuvq5Et/kbjWqBT4BYHJ6pjh2y4J0vRGt qOaG/Z6NkYbesSkgjQfn49AR1Vv0bW0XwNHxjMOORt2y9Xxpfk9sb22U4fDczGzoiY4Ei1HEvj17 oz8Q8LtlJNFWvt8tm1cEieGoX9YKTf2ZshNUBAsNjek9wU7PWu9egNAoCn7qF5gd3a1uadhtZDHk Ny2BjuAj6B0+eCj6vX55ZorUtKmpA9MSWxubsW/v3tILV2+vUb2SiozqNbXgs7rL9IFR1nbVsxYU q6mXRjVqbFY/tWPaSeMr8OFB4J/Ep5GhAFrzPYtaTM1Uc+967L4Ab4RqNGCKwqixN+iXzgC900MZ EfarRgc/S0tVIy+w6hnnaIbuJPzRg+caKM+dlU09k80o2NR1vTaKyXb1g5k6PLDt6x+lgehV300T 3KXNjZ0vnRql9QfVlEy7ksf0Drol3/pG0SFe0KEXOMNjNpqj8HtI1fqARrF8bjWiPkPmao0Sv81G LVZ2RvbtiWoEpAFdKPSqjs/UdLXYr+5q5D+MhcU90Z6ssFD8IH/U0xSxtRU/pFpmKBqxMA9r1dQx 2+Ebn84bG9tFrvbEjPepBh5qXl/XH4RZkAq32zFsVK834kvKwXZpfJsW1htlPb1VRqUbMTUzW7rp ZwaForxn6l9tfIf0N1dKD2Rz1JvVjz866wzn8c2lvn3nmdDAyAqX1/lamBoZlQ1Pj8xGzRjWBlFr tKIFe+16XPe874jrrnpOTDaGsXlyOSYb/GstOgOvYjy9wQduxQCpP9YRLDfO869Z4tupxmwQMdRC msCO6G73YqrdjPV+LbqDWmx2+jE924z5g8+q1ms6WzHZbsZo0I+tjbXyKhKBZGZ2PuZmq3f5ceAZ 04yT09GenqtGCf1BNFrVt94F0+WVE7FnYbEMR00rbHU7MTU9F7ML89Hd2o729FQsdXvlNVvrK6a1 FqJVb5RAaa3GlFsVpKqfNy/Bc3Iz9u5dKgEdD4KqoawzBzGdU3r05tiXFmPY65fpz54RyNpqLMzO RaffK9Ma83v2xUSjGb3hoPBj2mOyVe2oModcLQTbgNKNqbmFMm1oenB2cTH27t1fpr+MEkxvLSx4 vZYNDVUjUtZ0yiuUTG/ZBmtaSd9KALZw63swdpLSV69Ml+l1a2BMownwjL9mHWX//phYXi0NkcaQ HtijBNHZameSadGN7a3SaagB4KAX3c5WTHs3ZqMZ+/cdiPZUuwRuDdqwN4rJqYmiB41n25Tokcdj z9JSdC3i77z+bLo9Hdu97TJ9WGvWollrRnu6HVvrW2XasVVvlenFfqcfnrumj2mj851dn0ZQuUam 0dMge0ZGnRvPJaMX8mmUBv1qfUbHwrTh/LxOkcbMa458/8hOVOtN1iisNdnFZUeqHXKjqDdq4S2P Fvl9x07jrz4YUfehZ51+e4hdo57hzfMFHbOamYlWTO8sfms0NdwaTnnJI59r/HumccH/1NxckT8b WvX5PDG2042Mys3ubIKA2+n5owXvpQNUph3NOpC/2rnb4Ss7U7LN9sSpaU510l2rWW0sInNn81u7 W1NHaLdEZ/RC7xIbDc3QRLVevFv5bz+/PBowWrJOKNVMM55asdKs1SNqpiEjup1B1Hu6jaM4MD8T aydWYrjdjekZMbQV9YlGjIanv1qAHmzzh6eSmjHaKkxYWGhGP+qD/s50Yy2Gm+th5UbDITx0h4MY dSKGLZs1Itp+ubUbsTDfirmlqeh2Ijqb2zG/j5PWYntQi7nF+Vjf7OKuNBAa3M7qMOoT9ZicKJsj Y3phf0zONqJTM82kpzoVUzP1aE/XYm5uOr5xdD3mpn17vhZbnYj1ziiatWEsLHjlkzW3iMakXno7 mlPtmJ+rx2x30fphdHsaAtNS7Rg1a1GvtaLZHHCD6FkHmpuPaNm904+RNYfZViy0Z0P8ji7Zq/0w 5pSbtYg5O6bM7+/MHHUGw1jYf7j0LASR9kSrvOeyNWjEgf3Tsbo2jJmlfbG91Y3ZpcU4sbIdU9Pz Zaq13Z6Ijc3t2Ht4f9Gd92P2tgaxZ+98bKwPY31jLeZm52MUwxhCTqMVC1PzIabT08bmMEzPLsw1 o2nqzazT9HzhszGhYRxEmdKuNaIxuzfaM96FJv5OxmiyUdbB6oN2Gdt3a/WYXdofE7PtOLbSjY31 QTzrykqHGxvD2O5vxuzUZLQmG7F48FC02q3Y9oXGiWYBbmdYj3p7liqjb5pgMIqN7jDa07PRMVKs NWJqdiJqMxFbpgTrzVhcEFz7ZWTWG/Ri1B1Gd9SI2sAIslUaPQ1aa3o6puoTYV1PmprfE63JZmz1 67GwNBkrK1sV1vbui/aE6dRG1ci1Z2LUbEfbwvpERHN6pprHGNVibsYUyY4ejXrqtSI/+l3f2WlP xNxsq8xanDixHqNmIxb3H46pNvrVjMG+Q0txYs3uuGZM0GvNLsJBjLrWDU1bTkRrdk/MztVjojtf dhobuA4HjRg0WzFrA84mzDRjac6LtjXU1bS7tTQN0sxiM9qtiJmhGYsyS1vkb8/qPEU0+Eyd4Sdj YqZZtjM3atUXcemr3m7E9MJE1Bv16Hst3eRclOzz+6M23YhaA9C/damaXDp3/Zala1UnPXI5Zmuk x24qtxUzk7tRODftbz+5SA1Y79whUYuJ/4+9O4+y7Crrxv/cW1W35qqu6u7qeU7SSTrzwEwYAoig iCLIIIqCLlzLV9QlP//RHw7//Fyvy2HhKygoBhVFEQVRUByAhHnMRJJOeu70UPM83LrDb332rZ20 vEgI3UnUnL3WrXPuOXt49nNufb/7efaz90nesDz3hoZ84HI7slqNmJupR0+HV930RXulPc6Mno3o rkXTJh3x8BKPHM/gf//RpPa0Kq2pUOtHATT9wJvN9jBo+9Idx2NhFSh2xSp/fbRFs9wei8vVEN3X 09EZszNTKcqFm6VuPUfbQppYXqkuxcrh6fSKay4ZYfzgiAlpvsgokYtD4EG7NqMe1ZVWUEYp2tI8 2Gq1HpXO9ujpppx61FYtI1hJftrOTlE2rfdLsWq4g1giRs1GcsCFJVaptNZwcctkN07L9WLKsDUC T1GdpUbLD18WE8Mdx2xuS3NJ5Kg3Vh+Sk/++vaMcLLn29tZ6MRYQGfKcx+BEy9VHFnNmwMnouK2t NRoeHT2eLKT+qUhzO+aGjEbqp1o70su7eqb1zrQE6mtzemT3MfJnVSnDwqNXbU3OzKS2Nmy0M8ls IsKOrs5EXqJH5Wn4VBdjoNOcIYu2Fu0dXVFu74q2dvOG5bhrdDblpe9SsxHltoVo1Jajo70UrLqV 1Xr09K5LrgSWh76TxY8xWzD0n+e85KEjH89Jn1i89GjUbU6ndW8+3fOsjMpXTrT2q1SnlF2Zvs8c nHjoueuXesiQ21hZGUvflcuWiXOWvOckbwoCila4f5ZX2+5rK7m+T7Tep6dNz9Fv7J7puZicMond l3YyWK1Xo793ILp6OqNWbURldiWWF1eSZ3dpYTlFOaRQ5M72qFVFZbZHbXU5VpZai8xT59ZCxpeW 5pJs2tInI1U6I4+5167Z1lsNOoxx0jzabFTS+i3LHprR7S0HdkH3RoRKpynt5GngLqZ3v18DWHNP T1RKI/tHaDz/ZmTzrPweyE//dOM5FemJ0kAjas1qci0+7Ko2P1CORqkjDXKrq400j9Vj6mB1OXpO zkRpeS52b1oXXR39sTy/kP4PKh2t8A3TP555tswejW3W3ix1R7XcSCPlWglYtEeUuw3hYrLRH+98 /z/FxEI15mqlKPcOxnwjomdwOGYXl6Nv3frorPTE1++9J4VtD/T1pEk9oJ9CVNfce1wjQrg7rZGw O0aPdR7lWFpZjmuvvibGxs7G4cNHk1tQ1BkPCfcQtx232w03XBcPPHBnchtdfvkVcebMqdi0aUts 3Lg+7rnr7uTm8zhtR5RA5t67/8PT7elpkRw3EWBCulyDovm6u/qSW9Gc2eLifHJHmSAnB7Ax98Ct l6MRuXO4+wRGcFM95YbrUsi9urmDTPgjGutUkLX2HAGRB2XfM4t3bSszMTEXMzMnE7DmdWcW9ebN fYGWPc/8EwNqWxQBZFvlIIwDl10WZ8+cSu1Z5mDOa2RkU6yI8qp0xZVXd8axEw/GseMnUwSmeoAX N83c/GK0xUpccdHmOP3g0ajXSrFr9744dXo8tu3YE5tGtsVXb7+9VXdbW2zZvCE6O0px6IF7ot6o xsz0eKwbWh+9feujEW1JB2QjZw4d96OkE/1ADHSD2ICR7yzTlcXW2j/l9MlWZJ5NBjE/aq66NMe5 NlIDYvL6XfX19adwdC5CZdRtNwJ9pA9RT54HmejWljwAcOPGWhw+3HpjszlZbSIKH9sQkce+ftq1 d6NzROb3pT4uujNnzsa2XXtjwJsZpufi6ImjUTEoKzdTVGdrPGTg0IhysxxLVV6QcgwOD8bywnJs 3jIS6wf74uDB+9I/rz6R2/wr2ZEY8OYO9ztC0Nq2SJUcx44ejvEzp5OMY6MTSXeTM7NJB4PrhmJm dj46urpT0ESz3Jbm97i577v/YHI1NgR6ldrSTMd/+Id5nL98K1LLv4P8P0A//pfoxnOkhyI9URow 6LfrfT1Foz68OKsc9VJryZbpkWa1Fs3qYgz3lKOrthiN+bF42Qtvih95+f7YsLIxesv16GhvS5jg /83z9T/eOGfh+rfTw/Y0addcjbYU+CHUnIsHS7ZHtV6OxVo5nvrc74qLr74oxpcjbvnrj8c9D45H z9BwXP/0m+Lr95yILZcPp7UD42NnY2liLLZv2Zx+bMLlL9u/M06emk4LEfdffiCOn3gw7r3v/iT4 9u37YttVF8f47f0xc3Q29u9/SprzOX7yeEwvNaPc3h0j20di46X74kuHpmLdrj1xyVMvik/+0fGY aCzFjTs2xsGpRixXu1MwxP51O2LzSE/Uhnam4Ir77r83rr7ymti4aV3y23719q/EyIZNsXP3jjh7 +kxaV3L0yKkYnz0S7Y32aHb3x64du2L33t0xPjqejNX1Q+vj9NnTcej+Q1GtVaNvw44YHhqMWrUW 9UYtyiO7o7TSGZvWXxTbdmyNg/feHx3LC3Hp1dfFyVMn4oGDh6KjsydWlqpx0ZU3xun5pfj66HKU N7TFRQeui4m7DsfQxXtjtPZAfPXooejdMRi1dTtj52UXp0cxf2gyJqcn0hrATcO7Y/NFm2K00Rf1 yZnYctVVcf9ENa649orYsqUn/vUTX4uBTZuio9KVCOy2e0/HjU+5Lu44bdnDagK1SkclFsqdMVUv x8bhTXHps66Po//Amu6OS55xY9zz4S/F+Mm5uGqoJyZKw7FYm4/6ympsGNgRey8Zitrg1lhZnona saOxfc+euOyKPTE1HbHwua/F+o3DMbxufcwvzsWG4Y3x4OmT8eCJUzE6OhfLi/XYs+/y2LZjdxw+ eiia7Stx7dOfmvaIG9mEKLtienYqLt63LY6dGIuZqdno6GxPFs/2a9fH+qENcfudX0t6uPLqK2Jq YjpGx8biGTddGseOL8ehr5+O9kpfrBsYSvo7MTEdBx+ci+fuuyFK/bVolqejPLIjzhydiUa1HuUN 6+JMrTde+oqbY2Ep4s6PfTKWq82o19pj58DW2LdnJEoje+P40RPRuX1nnPniwXjeTc+NWrUeX7vj q7H1yuuid9dsfPLTn49rrt0RA1u3R222EfPcGeVm7Ny7K3bs2p76sW54MIYGy3HoyHjcd8/BGG+W ot7RF/v3XRszM9NRGlmNSy89kCy4Sntn9PZHrNx+OOnxqiuujiPHDsdg/7pU7+iZsVh38c44dmQh Ds8eiUsPPCvS4vtjx2Ln3n3RPTYWgrSGN4xE9+RUHD5yNBaWVlIA1vY918WGkUp88utnolwvp4jg xWp9zVXEM5M9NI/vsVn6z9trdvSHUbvgK/J1lXqiFtVYbdajq1yJask82n9evuVxKu4/FnpoeWv8 LPmCH6Ybg6RGCAApJZd7X29XzC2ejpnZlRjgMau2x4OLpVgQfLjCVb4cpa7WNn8GjAb/BiuPNpWj NhuV0lIfJbf5AAAgAElEQVSUVqajgtRKyxFVbqpa9LTVo6MJyHrj6OGx6GpvRR4J4R4cHEjy16or MbJxfQwOlOPOO74Wi3OzsWvnSFy6f2vs3rUjLLXaumVdvOqVV8ZAb2sd2tC6gejp7kxWxV13jqby QjOPHH4gRs+eSdFqfKj26brxhsvSPM9VV14RV15xUXR1RqwfXhf7L7k4vvzFL0d7uZQCT8zniIg7 fP/ZWDfYHz1dlbj5+c+NtlIzVpar8fU774jlxcW46Zk70xxOb1roWI1rrtqbIhztcFJbXYl9e/ek Ee++vRvj4os2xqkHT8buXdvi7OlTUeloi77ennjOTZvjBTcDqskYHxtN5bZs2hhHjxyKyfHReMHN 10dvdyn1iwspRepV2mOgvzeOHz2coi+7RMRVIn2fnZmJ7Vs3x+ZNG2Ps7OmYnBgTcR2LC8tx5YHL 0pxS08LvWjUsjdq5Y1sszM3E7FQ1WcRHjxyOB0/OxsTo2fD+ny2bhlKZybGx6OuNmJ+djv7enhSU IxJwfnYmero647tedH1yP+2/5KK48Ybr0rMSWbdzx/a4687bY2VxIUUUKrNaXYnJiXrS62B/f3zf y54fS4vzcfzoXBw/djLJfM3VO2PTSG9yO7t36f5d0agL122kSMWrrjyQdMWa3LhhOLZtjbju2kvS WsJmbbUViVqLuPvOO1Pb27dujauvuDS0tzQ/F9OTk/Gsp18dw+va0vzdZZdeEnfdfipmpidj3UBf 6t/UxFiKqB0fPZOi/nRKVOTR9Nsai107toXfn+ckKtB+AAtzK3Hx3j2tdXQmtBuNGD+7GOuH+pNO pyaWYmT9cEyOj0d1aTHmZ2djanwstddpa7XZmejt5m6fTvpRxeaRDTE9NRl7dg3F9m3leODgmdi2 dUOK8F1cmE/HmamJ2LB+KAb6+mJ6YjxWbQe0tBhnTk3H4fsPxk3Pujp6OkXlDsdllwzHfffcE6dP nojqcsRdt38tBvv6YtfO7XHxRUNhPajnOj56Ni7auycu2tsX64fWpbmIRs3vpDd276zE5pFI/1ee c826N5Godg56Aj5whBdG5Co5vtnR/7ffUNlMfqkZ1eWl9F1+zw+gtgbkxfHx1gOyEehl3rYtHZ23 t66JwbCkZG42lhbmY+uWDdHbw5JeiKF11oeJA4hYrbVeu2MTcdMUAkJ4c74TMms5KtdeOG380kp+ Oq0JPJF+Y/YxW78lZucj+r3SYXohFhYWY3R0Io7cf19MnDkVldIV0dteipGh/liamYt6pRJjZ05H V8WIeyYePNIdnd290dFYjbMnjybXyMjIcFy6byRGR2di42B3bNs6kqIK/QNbJLkwPx23f/Grseei fTF55kwcO7wQCxN7IlaXYnl2PKrz02H+13qomanpWJmdik3D6+PQPXfF8tJSPO3Gp8S7//kLsWvP zrh0365kEdz1VSP4thg7dSoGrUcrlaK/qz2WFxZiaGhdzE2cjuH+7pg4PRHWTs2On4rDtYXYsXk4 FpfmorY4HZ/5ZCNFX3aW6tFWW4nl2clY6uuN+tJctDWqcfCuwzHQN5iiNIf6umJuejxt2zI7fiYu 2rUthgY6o7s94vgDJ8L95spCzNo9utyIucnR1K+zJ89E/2BfHD1xJHraIy0QbG9Uo75sf8bV6Gpr prwLU2PpR9DX0Zb62NNRionTo1Ep1eOGqy+P44dGY+eWjXHxJZemEc+hxtqrWmam4guf+lrs37Mx Hjz2QEx0nYkNI1tF8ERUF6OzLLikGovzszEyNBBDvZ3p3szkmehoa8b8RFc0lhZi8syJ6O0fjO0b h2N6dDEWZheirV5Nz3lhaja6So1YbazGQN9AHD14T2zdtDV2bRmJXZs3xsTp1eQa3LFtIMZHmzE1 /mCcPl6Li3dtjd7uvlhdmI4qslmaj7OnR2Nxeizu//r9yQKcHp9KOy1s3bgh7FJSrq/E3OxsVMod UVucjV1bR2JdfyU6BDVFLdYP9ES5tpzmsOisvtpIep8aPRud3ZXkBtGeaMvmynyUuioxPToX7c3V mJs4E/Xl+XRdpOnm4f4Y6O5Iz2v3to0xMjwQsboQvfQy1doPcXluIro6OuLkkQeT63Bq9GT0dDSj VFtM+RorczE3MRrlldnoNOGwuhRHDx6Pvp7+2L5zW5L3ntvvi62bt8WZ44eiNr8x6aNZrcfxB47H yvx0rNu0MQZ6KnH25Ez6/Y/wGKysizPHD8fc9GC0NSLa6isx2FNJ9X/99mPJfd8Z1egWQFNdbgWQ pFH1E2SZ2aEjW2bFsRW78N9ED342JXNiSeqHZ7dMx4pXkEY2DcXc9FgsTDdjoKMRHf2VKNUXYnV5 xsqrNDjhUsxzZo1GKxCEhca1bPOHbzeVGvUV4QNRq7fCvdN8WXRE9AzH//fOP4nP33kwDp+ejGql LxYabdHo6Elrzxrek7NuKFYX5qKro7VjAitocX4ujX75+c2J9FjnUl1JcxWDQ+ujWqtHtdYKuTbn wedtXoRF0dPfF0vzCzE2ORHdlc4UMv/g8ROxY/euGD87mkL39+zc1Qot7+tP8wo6nCbFh4djw8j6 OCN4orEaVx64IpEWN9fYxGisHxpObj8kw+0zNTkZPb39KZR7Ymompmxns344hP47LszOhbBmOyR4 8/bi3HwaOlo60FbpiOmJyRQQYm7FxsvcQNxidoFuRD0FApwZPZ1AeWJqPLk3tdvT1Ruj42eTu2xl dTnld31+diHtTSZQoN6spfU/SJfbSWCBaHNHIO+ff3qytbOJvpsn4ms2v0iX9bSFVz24de+86660 o8q2Ha3X6Fj8nuYubVq8uhiD3aVYXZmLUqkjPJ/Rsek0p9lsAJlIlp/5rVpdsE0zOtqbsXXzSPT2 dsa99x6M1UZb9A2ui/mZ+ah0V9KckIXook9n5mfS3JFQfD9cRzuEtFU8b7/21iLgXbu4fUdjbmE2 6aOnrzu586yFm7DFzYahWJhbTP028kPyczPzaTsf6+5sR4ac6J1+leO2nJ23c42dZIzoV1M5Szlm 5qbT/da2E80UsCFQg165EQVwtJc7wvOxxZvvY2fH0+9GvWfHzqTBSr3ZiPZKT/T1tzZY9ps3x2OE 6R/U/JZ5LokOzR0KBPKP6nvaLadsB/W26O7sSe5k7Q6s60/PV7uunz57quU+bbBQ2qK3vydOHDsZ A4N9MdDbFwtzc2m9nv8nu2QIVrI7wmrd5tethcYiJc2l+r3a2cYcsbWH5tJaMOR5OHv8jo0UNfD4 tfd49+9/fnvlaK56fgLCsAhia6R1p7DDv3j/wLo4e+Zkmp9f19UWldpsDLbX44XPuTHe8uqnCWaM 0sJCigb3fyF5Q/aPvf6H03n6YweQd7V2ABGLYF7dXDjMy2Xka2+GKMKW1zkFf5gUTr9uGzbW46Uv vjkWG23RObAhJueWYqXRFpPzC9HdP5DWl5VXl6K/2w4RSzE9MxW7tm6PQ4fvj+XF3tSoAIZdu/bE wPOuS7tLtMIyKzFh0Zytg8qltK0VV+CZs6djZOP+6Ki0x+KC99x0RnvbjWnjturKalQ6O6ImshKy i7rkk6010+T44SMPJCbfeO3eVK/5OsBx+Ybdsbq6LW0pVa9fkgIogE6lcklrd4ZGM4au3ple393T 2x2nT52JDRvXR6PeDN9npmejf6AvpqdmUvtCysmxtNjaggW5UWp+lxrwEgxC2R0dNyRrCOF4AIIU pK4DWxMBm+twzyS/AAVH0XSCCwRLICngKPLOQ+NLZoIDSSTuPteCNpeWWxsvl8ttqZ45+uvqiqfs fVaKPFW3JGpRXfbBrK0uRbm6EL09nbGwuBQdnbYZq6UBhwW1yhhsAGb+SGvMlubsYWh7q1I8dd/m sHpkxR5q57wZwASuZ0NOunHPh5z6qX82UHZvfmY6BXIsbO1Lz0YZ/QL29KPPdOk7uQVG0IEPuURr 5ihQ8mo7B4zQpTyu0UXSV6mU6iKL+gTzuC74gp6d0z1CMjBwzD585/q1unpZOooatE2b3W3SYnbh xdbidXelhfECnCx2RyKO1uRY1C36kSeBWjva7Egzn3SRfs/NZpKfvNojT71+IP0u9EUfyd1oXJvu eXuFctYdzq+9ukS+SndP0tWmzVtS8JI8tr5K0ZregLBUDbuGiDBOgSDp1/HE/GmR6RPTdtHq+WjA ILUVTdqW5s3s72s7wIf3UWztQ78nOitt0VVajebyTPSUq3HJzk3hJdLwrb1mzr61Y5HfvY/I7Eez YFov2stp/0B8YaG0RTBrk6XNcvTWJ+MHnvPssK7j1Ol6dOwdjPVDBtl9Mb8c8a8fvyMqUYvvf+51 cf+htujv3xS9neWY33sgbvvUJ+Lq/f0xstgRT33qjhjZvD7GJ+ejp7svbv3MZ+Opl++PS/YPx+EH JlPo+66dm+P0meEUGr9uqCuND5eWGzE+NplC8Tes3xp9/R1x9Mjp2LJ1WwotBjK7d3gR3lx0nJqO G2+8MbZs8cJLr2sXHu5tqTYHjpiYbO3nB6A6O7fFoUMn4vbbD8aGrSNx3XW7YqC/Peyg0lbeGW3t rXUs9953JHbdcFms3xAxO7MjRYdt2dwXX/3aA7Fr5770INIi7v5mnC21Xktz/fXXxsc+dm/s2zgU u3Zti+Fho2AbbkZ8+tMPJl/wtdceSC/FWzh7LF73Ay9J9yuVHSEwy7q5/NYOx4kJLxa0B6WQdOHl ETam912dPiPDEZbyAUebVeu/uqp1O4Ondb0t4OxgIdidwr6VpTRH0dkWaV7m1Nlq2mGhp6e1ls86 QnWsDZZidSUibRixsi3VvzgfacNguhLz4D2WCwtpOeFDR+v/yDk6Wkt6sLH/pg3b0zq91dUtyRUx O223EwRs3VDr50d+O1f5SXJXuKdu71dcWdmdrvX3e6eUNY6tfKOjXj1RST/fvB6L/PLRqbV56iAP HXkmPqxY9cqjLTqkU9foyosJZmdbzyBxeqNVR2qj1MpjqVZfdwQjkBFKH9Yp8t4LfPfd/Zn51v3u voil+Q2pffpdWVuj5l+PztJz7o2YnGrJQ/a1TciT7v3j9vZEzMy2fg/uKbfUWs4ZNo1X72r1otSG vtGpZ+rcc5yatDsJADkfMDu/ssk4P78qitJPpAb8fwqIbbZ+54551Z+lokjNmty0y1Qr6DG6yzui 22+xthKL42fi1NmzaTAmmlESyWvAZvD1aJM4/FaZtdXbzLKmQJDmSlSaS7E0s5QsnEN33B0bNmyM vt170+aO1dHReODWDyX30951tXjwxMm4/atfjmc87akxOTURM6NjsTDcETNH7ojuq/bEP/35h2Jw aCjGJibj6/cejHWN58feoafE2MHPx623fiqFlLOmenp64+abnx8HLtsfo0vTccufvT26ujpjXdra ySsExtP9ycmp+OIXvxg3P+eFcd9996dR6MH6ZLzn059Or05Po9yox0033RRde3ZF79ro+58//vEU es16umbntrjttn+LG/auj47ScNSXl2LATiRTM7EwvxC3fujP4+n/zy/GxPHx+KN3vTvt97hv30Vx +vSpOHDgiqQXb0EdG5tI1oZ3iT390i3xwBf/JVbO3BcPfLESr33ta5N1cOLIkXSdFbHnedfFfZWl WFhdirbZsTRa7h4cjB7vDmqvx/zsfCpja6ktXR2xujwfjcVGNJeWorrQGQ2vd+nujq61tUcx1x9N L+NjcS0uRtlbpdfWaM2Mz6RRjhE+ROu27sgrWeYryXpIG7709UXX/GRra6nlSrLVO6od0d5sxMLE QurbOrttTyzG1Nh4soQqpVIKSZ+dXog2W1bVeqMxPx9tHR3RtfZ6l/p8OWpe62ND54XeqMzPxMxi a20Qi1QAwEB7R9Qn6tFmm6e1PTPLXV3Rs7a+Kllq7e0xQPZqd3Q3WludNVa6ojY+HnPTrY2BO5aW YnBga9KlkG0jPnVUx6rRrFajOtdi+Ip1fnZFKVeiudp6LUZ9sRzda3szKju3MBeNpXJ0cIGvVKKL 67DclyxN+3jSo/qThbvmIegcXBe1pcW0ndnS1GQ0O2yYXYseHozqSlRqXdExO5PW3NTmO6KtVk+7 nNfn6tGGtSXrvxYr0WCdLvdFx9r76+TvXHuBZHu0rPglVqg9Qxe6U0BTu3fVedefka2X1K62ysRq RKVhB4ayJZVRslNJe38063PRvdgd7SuPPmqsJeyF+QvwivTfVwOlciUZHm1NezO2trTSGy9usdFw tHWmaSX/x7Y3rJS9Ib4tejrK0WhW08jR4go7gPAC8RzwpKT/s0eplnbbjvhBJSY1V0YAhJZcofXY MNgdRw7eFSszp6PZ2YztfRdFZ3sjJqZOxsLJg7HvwJWxOD0Zxx+4L6qL83Hs8P0pimqwpzOuOXBJ fPlzt0azvhQLs5PR39cdPZX2ePYzboxyYyUWZybiji99LtobK9HfafsSI85KRHUhZicnorE8H+t6 KjEysj65x8Ynx6OUgj8m4sEjh+LsiSPx+ds+kYilj0U4NZYCUPbu2JKI5sanXB/79+9PSqrVmtGz ri9N3C9Mj6eJ/eNH7ovOdvvbLcW9d3wltm3bEo3O9ugq16OtuyPW93fF177wmbRrvWCT3Vs3x+6t I7Fvx6Ykz5GzD8ZTb3xa1JcX48pLL0qT8gIODlyyN61p4lbsrbQ2NjZhvyRQZHYy7vzKF+LMiSNx 4MCBNNFv5D87cfYht5Kd2Hu7e5Pcc4bnay++7OxtLdjtauuKWm01yo162nFlemkx7dMn+MNkP+Ja Xp6PpWo1htZejrm0NB+1ailF7HW1l6K+Op/eTFBvlKKZNgfuSq+AWK4upUXE9iLkTizXIxamR6Pe 4W0Ildi2eWOaRxs7MxYnjxxJyxHsHFOqLUdvh82bLdxuvdPJj3NlaS5tfVWvV2PzcOt9SP19G6K9 UUqutfa2tpj0XGuRAnH8mAWviEC0V2N7k9Vm1NZIQRjZ/Wr1yNaN3LStReC9ld4UxLE8Nxd164/W XlXPcrQHnHpLFsHXlqNkh4/0GprV2DTshYWn06soqtVSMrtqS63F25uGh5NblF4FxDTLjejqbr0Z nYw2STUY5CHwm/KKjnJvXwru6eooheq01960zqaRfgvpVRtNyyRKUWlnKS1H2TyWtwK0l6PUXI3a 0lwsNaopipM7lNu0XCrH8lzrvVlNgRvlrhhZP5De6NA50B293V0xxW3caG1QvLqymLYbQ7j6axlJ cvfap7S0Eh2NepSqq9GeQt4fJWpcoOwovCCzC6TMJ6ga/GGqI03qr0WWEsV+Uta01hrt0WVHpV4R jJVYWV5IQVitaQ7jt0ZyP7DGnPOc+XCTpHWEj8J10O7HxNxPJv85oyQmYzYbu9rb4uorDqR3mK0u zUWpXIpL9u2M//XmNwmzi6VaPW684dq0yHnn9h1x4tiRmKvYwbw3XvKSl0R/T2+8/GXfE1/52h1x 9VOvD685OXzkSFqfcO3VV6XXZt97z8E4dPhIPPc5z48d27emQBIj9+uvvSYuu3x/2hlkcmo8Zqbn wrokKlR2eN3GuO+++2LH9i3J4rLgmKm6tLQhdm7fFtOTEwko7DJiNw8hzIDtpuc8J/7mA38V+y++ JG3w+qG//bu4+QXPS1aniXVzHMKeTxw7Gnuf++x4+cu+N0bHzsT2rVtS4MeWzdtiaHAgPnPbZ5PS 9+7eFQtzszExNhpXHrg8Ldw92NMdk+OtFz1ed83VsW3L5gRMRh6ud1U6Un4LYtOclO8TE605oHot 5mam07yR/N2dlUTQRjh8yq61VWy5ZEf81mbKlgoARXMt7W3NaLQ1Y3F2Kv1IvMJG1KcAiuWVxfQD HFrXF4tLqyEsvm7/Qpu5RjMGerrTu5iWF2vRpw/Lk1Hp6E6gK8BnZcEOHRFbRjam5+R9ZtoFnHYk IaMfJzmEW3uRq/tzs6tpjZ7vaf5sWr3eXt4iL7vPuNfft7VFEPOt15r4Z0k6ELrrNUXtnTE/N5Pq sIO69izYXlpYic4Ob8xti+pyPcmmnYpXtizX1zah9u6megoF97akqcnRFPJtOYe5VIEvA/29SadT k62Fy/6pzE15ZQrdI1rLJOq11vPSz25vKugZTDElTeHkgi3CJsAroR1zB/YY9Q4322V5XZIFp0Lk yegZ0p15REtd9EnouXZcN39o6Qh92v7KeXW5HCvLS60w5tpqdHa0gMDuLN5gYU9NywREpXplU7Ik 6WLtJY3eddamwicwFa7GJ1D5F6Bp//sp+KPUZIslzlCtDSUsr0q767Q1Y2FpLgVKry4vRXelI9r7 WgPBNIhra3lrhOOv1uqxtCyC8WEy8v+fPw+LnBZrPPxViUajacC2Nl/QESXbigiXbTTilve+N177 mlfG/PxSDPZ1p+rTP3F1Jf1j26dwds6OHtYHVB4KWhgcGIwFWwFVl9IWSsBAEmHFWrGThX9Wk/oi sKrV5Th69HjaH3H37r3pvVPppY818yDDiSRxPXK0ga+XUG7btiNN2mNxStAJAOrjO/AzivcPrA0B B1xD5ER2gkPs7GGFOsvAzh69vV6H4oWTrZdcbtmyKe0EwkKxDRA5tW8D4/n51sT7v/zLv6QF4yxA CSiRiVUCmHKb+qttyT2g6EjO80lGM/qY69KGOn1P56utrZDky9txATn6IhMyyOnhUfLDizTyvdax BXwGOTk9XCZfeXIe6YQuHu3xsdXW2vx3ijL7v1t6GC7+73uP15VzfkqPV5NFO4+BBlq/JTvdtCrP QUWltKF6Wwr+S7uB2GiiXE7ueO8fPHbieNrkQVQtItu0ZVvc+unPxBte+5rWBrjN1ntc3v2ud0Rf /0Bs2LQ5Nm3eGhvsk9rXG93eHrEWj8vhtBaSy7Sz8zHzsLl2uyVYuc0+jV7HIXatHJWe/lhcqcY9 9x1MG+UihyNHjiSSAKCf/vSnUwSa7aVEiXktiSPw3LlzZ9x5551p1K4cktE51yVAbAIcIQ0ODiWr 4uTJU4kUhGWal7IllHLaEkWIGMxFiXRzX70I01t3kcmXv/zlOHz4cLzgBS9IVpQ384pcQ7LKDA+3 Xjk/OjqertvncOvWzWmkbkSsjrvvvjvJ/7SnPS1tR8WaMi/3gz/4g8mKILs+PkQi9Xq6rj/y6Y9j PpfPtfNNdCflur/x6K2wmTCbzdYbpsfGJxPhIttk5mchHkKW/wzmWhkeyqbcf/iSK3ryHZMaENqa Tr7d42OrKc+RJN/8eSYZH1sBitqfJBpo/ZZsjbaW1n5c9uqFSWkOrNnajxVmMSTSUpE1q4td15ry ak175ViO9Mtde2kr0kq7jZh0+CY/6YeH5VmIbziK9uL6mpqcSBbThnVD6c3N/Pi33nprnDk7lgIu TOgfPHgw9u3bl0hAgIXX2gNs1ooQ/fvvvz/e9KY3pTeJsl6e97znpeACpOK+DwLasWNHIh9Egqi+ +tWvJvcc60eeSy65JAV/AOKrr7461UFGVp+3lL74xS9Orkff7buHXMlgzz5yA3cfMiI+9SivLQR8 ++23p3Jf+MIXknX3xje+Me2HiNSQJlfm1q1bE5kiSVYOgnVNX9SXiQqBa9v3fC2375j8w9+g80fz VdvZKsvtOqpbe+6RwXdWa+uH1HJHyUe2IhUaKDRQaOCx0EDGHLjzjQNt3y9kekQy41I3l2Beysa+ 6wdbFg1BWEWrtUYCSAtCkYfrrCyT4iwnnWAFWWfF7ceikZdVsHv37mQZcQOy1lhVV111VeofIlEO eQBieZHj5z73ubApr7YRwVe+8pV49rOfncogQcAtsRRbm8GeSWRzww03JNmQj/YQL6C3aeu///u/ xx133JFIFBl95jOfScEZ5mFYeAjxE5/4RJKPHPpFH/JdfvnlicBsTosMkQNiRzLyIYxMII6SNpx7 0Of7QDNBqicTo/PclvM0l2VOZu0NxeZ4JLpyr0iFBgoNFBp4LDQABx+v9IhkRhAg6AMgM0gCYkA/ O9d6fQUiA6ZIxgcpIRTk8/rXvz6RB3fflVdemQjss5/9bFxzzTVp8SvARTDPfOYzk2X0qU99Ks1p ISMJOQBebbKAkASS4y5kSUm5DnUCePLaJR3x2aEeEeZRAqIF4qw6JIRE1Y9knCuLwPWBe9FHu66r 49ixY8mCVP5Zz3pWsuqUZfXlhIBZchJ56M01cvq45ni+D1t5hJnTN57rF5JFYPLqgzyZUDMZ5vLF sdBAoYFCAxdKAzAHzjEcJNjjOxzN1y5UW6Vmo7YWAeK9XXyZXZGisRrNFADyspe9LIUnLy0upF00 eipG8o202SfXnK2+EUvewYKA5qGQB3ID4qwwpOIeYkqRZ0tLyULTKZ0TkMGtyGpDFuafuByBLZLI c2DIBjgjCuXUJalXPm1lostzZoiLVah+R4CuDoCufmUl8vmuTsTjaANM1pi69JG1eOLEidQ3D0pb 6tQPCWmoG2GSTz0+7meiyQ/S0b3zSYhdHfSsPfI7ZvLURr6mv2TO/VWWLopUaKDQQKGBx0ID8Ace wRn4AwNhE5xkMNh03Fs+GraPqzVj81YBILfFj73mdWlLfW+wtqn0H//BO6J3oD82jmyKjVu2x/DI loT1/yEA5JE6YMFyX+/IQ1PI9sAU1WcndYSFzAjJjZjBmuvtXIAXrCEv4EdSCAd55c4BWK481p28 rCV1sby4LOVluZ09ezYRDHJClMgHICtvyyNzYMpRnLk7R98RZFZqJj9WH9LMciME0ZXqRXra9P36 669P9VO8tpBUnntDWkha35wjcQ9OHdrTFsuInGRGKpJ+54dL9vNJuS7t+ZGo1zHrh1xkoAdbQMmH zFzT56yP85GhKFtooNBAoYFvpoE80HYP9sAh+AS3fC5kekQ3o/Wq1iLNz83GyspS7N6+PQH34UP3 J/caNyPCMRflCLBZLiwppMDliIiQFcsGeJprEgzyjGc8I81VAeBrr702BW+Y9zIHhkgA/Uc+8pFE BPlqRK4AACAASURBVNyJXJPm3LgNgTRSVFaACKLkwkSWPiw4bbOktEs2ZElOyXfkhLSQpHrkJZ+X Zxo5IEjAzwr0IBAZkvCiRkl05V/8xV/Ec5/73LQ4G0GQidzIT1nn2eJzlLTrnqP6zifpq7r8MPxI nDuSV58efPDBpDPPQD+0h1jdl+QvUqGBQgOFBh4LDcAiGJhJDZnl765dyPSIZFZdbSZAbFjEOzcT fV3daT0Wa0fwxdnR1tt8BWywchABcnnLW94SH/jAB5LgohZZLAgISZkTY4EBVeSBTFg1gjH+6Z/+ KZ7znOekvNmK+9d//de076KyCEowh0QZ//iP/5iIA5HIj7C4G9WLuL7ne74nWXosKPcFe3AbIhsy CQQRhfj5z38+RC0C+/e9730pGOSVr3xlkp9Fw4pjgcn/93//9/GKV7wi1WMXD3Ko25ozJMkq1V5e eoDghPAjYwTz0pe+NB0RCT2SV9+U9SZkciFKAwPX9Q2JIz9t5R8DHcjrB4LM6ZTFSa8f//jHUwQm gqcLMmhPeaSmjjxSupA/qKKuQgOFBgoNZA3AmzxwhlOwLFtnMOhCpkdc/g8AgTOyIRgLALizXAAk a4bFAeRdI6h8DzzwQAJsVpH7QBYYA2jgCnDNuakX6OukEHpAj9xEN6obWCMR+eXL7j5kAcBZYFyB CAkRsgYRBlcga/BLX/pSaodlIq+2WX+iEREUC1H98u/ZsycRANm1gxz0i9LdQ8ZcmQiTRZctLHmR DnJHWHTG1apvAkeQhzKuCRqR3zV1kol+DQQMAshJHoEzyiA7RJmfAXlZiAjQOZncN7dHB64h/Gyd XXbZZYkYySqda5l5VkUqNFBooNDAY6WBTFhwPGMSLPJ53N2M3d0td543Dff0tAIv7IhhPgsxERa4 slAQDIGBKjYG1ggD8CM0JOPI6vARbeg+gEVmAB4RAnjfkQJLD7mx5hALAgXWyqjLmjKEdejQoXj1 q1+dwNycG/JTx9Of/vRk1SAbrkxryHye//znB2uSSxPRUiwS075ryEV/uDkRoA/iIPPb3va2RIju 6wfCsPZMW4gI2bPeuEPJyKpCUsiKfliq3H/ICmEiIP0g70c/+tEUIYmg9NNDt2yA7AYL2kRw8uqz NXeehfzk4+KlN3OGBhL66nnkgYEfleeWiUx/i1RooNBAoYHHQgPwJXuPHPEF7JYuNPY8YjTja17z ypid9cK/lbSdVHO1FpX0vrG5ZGHYTw+4AkukBWQRGWIC3Nn9BczdExWoEwgwdwjJKQ+4ATwyAMiI ANFQgnsAGzGwjuThkkOYrBbkYI5LPdpFBICeFcSKUVe+h5iAufrIqS4ykx8hKO8D9FmPyApJkF29 2iGzD3KVDxkiG3UiNsTolTRchx4gMtWHTCTq0p7v+uSoLvLQE71JrusDHSMtsspnEKAOMpAH6dOx fiiPzJXVb9fJRzZ613c/KB8yFanQQKGBQgOPhQZgPYxxhKmOcAfO8lw9rtGMPFF9fT1RLvlElDos hBbEMBTrhobS/shAEvkgC0BKUNYUtyDhAasPUAawgBUoA38JGSkDiJVxLqkLMVx33XWpHBciYgPs 6tOeBKBZLkAaGagfkbmujI8E+OWhXAQjL0uK7LlNwJ8Ty4Z1JamDvKw+SXl9I7OkX74jX2vPEJQ6 fVhTiMe59vXBNaTEshNQkt2PdMkNitS1p4+IC2GxCnNCsFL+cegvfalb23Sg/75LfkjqUk++5jq5 i1RooNBAoYHHQgMZ/2GvBG+QGdx0vJDpEQNA8qbavFF2sSdcqdTarZsgXpYNlCUCc4n98z//c7Jm BB8AWcTGlQbQBV+wSFhSrCrE4r1kgNbiZMEdOix6EZmYh0I6QF+QhjoAP2JAMCwS1hNLSFlzR8jO fJl5NwufM2kiittuuy314bu/+7vTyIDlgmS5HLWJFCX9lJcbEHFYjE1O7X/sYx+LF73oRakdC8GR LVk8IGSlv64LPpHX/By3ZiYjlqJgEbrRf25SoxTf/+RP/iS5S/VbuR/+4R9OliirTP9YlZJ2yEh+ xJ5/GIgKkdEdUnNfcu3cpDyyy/Wde684LzRQaKDQwIXQQB7sw7k8kM/X4NeFTI9IZuc2Jvakwys7 IqLLjhKsjHJrUS5gJORTnvKUREoCKszXcAVKANs8lL0VRRkCW3Nc3HBA17wOK0x+pIPAEB6iQXJA mbWSAZo1Qzl5Gypg7tyuI0jjh37oh5IFgsiURZDIiVJde/vb357cgEhHftYZV6DkXH0IEgkhYvN4 yPG7vuu7EoG6j4CRzG/91m/FL/3SL6X+a0e/9QuxsODIYjmCeT/9QuisN/2966674ud//ufj3e9+ d5qrM59mUGCAoG7kKWkb8dANIte+HwMLF+EiU9fpVR/pSUJiZJAclVeWDgoiS2op/hQaKDTwGGkA 9sIgWAWvYVDGxQtNZo8czVhttPbdLgF5+w6uJqEaaztb0AFwZB0AVoSA1FhHrBcWiOtAWWe4FAEp dxwyEMTAegKsOs0aQSaiAtWFFLjdWF/moIC0uhCbeSykgEi1l12E7qvPdeCuXm2qiwWE8LJ7UR7y awMZmo+jZH0gK0uPHIg1z3GxKJEWa84HeWgjEzqr0H39I+e//du/JQIju2ssMFamPPr0wQ9+MFl/ 73//+xNRIjttc3Gy0PJSAvnpWULy2pTo0o/Ex1ybH5BPNu0dlfUjohe6kBBrkQoNFBooNPBYaQAm SbDHVEe2ynzP5xeq7XaNJfD2HjPuNXMo5VKU2lsj+s6K11tzazUTeHrtdU7nTugBT0ALLLnwAK1g CVYPd6Owe6HpXqGiEywdlgTi4XZDRkA7RwSy4BAOUEck6gS+LBmkCKBvuummRHLIRng+ULe/ozJI LJMa2RAWdyFitbM+C0i7duJnBbEWf+RHfiTJhpzoxTozBMaNiAAzWaonux/tO6k/ZMtBGyIJzXMh R3WIwmSxslaRClLTd/Kq0/yZReZ0ol/k9boaRIhk/+Ef/iHJm/WO7LNrN1/zLKT8o8nX6SqT3rk/ LPczqeW8xbHQQKGBQgMXUgOwNCcYnK0z12DVhUylRn212SKzzvQG6Wi2P0Rm73nPe+J1r31Vag/B EqRStgegS/ZnrEet3tod/lyh1OeDzJAH96JzwR2AVT0AGZgiHiQA5Fk2EoDP13O97gN6xAGUEZx5 NMpSH3LQpnNtZAJzlEd78kjq8T2Tj/qy+0796vCRTxlEka2YTAC+y5uJQr3KkME1lhPS0icE/40p B8q4Lg89aY+8iEo98jhHashOct2PQqITMnyrRKac8o8nH/P14lhooNBAoYHHUgNwCI46ZvzhWTt9 6uQF25vxEd2MuYMMMqDPQpNYcDnkHXC7B1yRgrkmYG8eDOG4xvWGQCQdAsLyZwtDfiTmIz+LiEsw J/UjFsQEzPN6rnMBXb2IhKXG/fcbv/EbyVqkPGW1L2BE3ciSnBYnqwPhIBJuzz/4gz9ILkwEw71p rguxZCKTz7mjhdqsTucelvZZWqwy1iEiMl+GsKwzM//HqlPGPNi5JKtvmZz1N7eXiUxefcyJ3EUq NFBooNBAoYGIbz2sRzzNSCH5KAzAlm1hHJEIQ7BGpbM7gTgSAq4CPXy4AH3nFuTSQ2zmjpCXeSl1 caEBZwEWb3jDGxIhqBvQIwGuOXNoiI5LjitQfuVE/b3uda9L9SIUEY7mssxF2XWDuxF5IC5EpRx5 bVUlatGWWX/zN3+Tgi7I81d/9VcpYtE+i8hSe9yRgka4IpGV76IaWVyIxbweohTIgSwRH9cmcv+7 v/u7ZJEiVcEqyNB1/UdiAjbMhwmVZ7nmpD6k6CMph/iRL6JEsGRxrs0iFRooNFBooNBAfjf1t9BE 3j6LQQBos5uT9cRyQlwIQ3IfYCMxoI1YEA/3ogg/xADYuRx9ENXf/u3fJmIE8Nltp047YpibYj2x TOTLC5fNLdmk2F6O3I1AXUi9PRyVsV8jq5GVwyIiFwJAuOayWHUCMXyyBZiDP/SD/PKb6xKgQS7z gazLTNrImAUomAOxaON3f/d3U50sMuTNCkNCyFU/cpvOXXMvW1ralLILMX0RNbq2/s53lhqSkzeX y/mKY6GBQgOFBp7MGnhEywx5sc6QWrYWALmELFg9riM3QM+KYW0I9mAJiTZEDEiEtcNy8WFhIByg zkrJ67vUK+CCdcZFKYAE8alHkAhy5Aq0lksedSIwc0msMwSkTuQjEIMsCAK5IgGh9aIn9SEvtEZG rEAERFYLo1lESJjc8iEodSPCTDDI1Lxi3hj5R3/0R1M4PX3QC/nJLHgE+SJpcnlHnKAO7aiLXIhR GcSJgMksb07yZaKjd4msZC9SoYFCA4UGnuwa+LYDQHLcidADxLEwP5sIrKe3PxEDqwH4IgFgjGQQ HOAFuAAbUHPPAWHAnZN8yAbBsHAcWX15ITLiQpTaUI/76kSGgibUBewllhYLSFKvfKwY91mN5NEW GVwnE5LIMiinTuXI6qi/mUDc0z9tOCeLfpOFHJnw83d1kFtbymmPLJm8tKdP5NEGWc4N8sg60Zb7 mcBc5341KPhW6VwLjm6lfPxW5Yp7hQYKDRQauFAagEOw0THjzxMWAJI7xd1IIJGAW7ZuTWCOaAA6 gCYwIgO+SAMZZLAG7PIBfaQHtDNRuCefpLPqAPwAm4UEyFlH8qvTPJd2WT7IIYO2uuVRTvuO7iMr 5Oga2bLl4z5iQDgSMtSWa7ne/D3Llsky90dfyKLvdKBOJOO7esntnGz6j5DcJ6ekLX0io35kC0w+ uqCXfE09UtZV+lL8KTRQaKDQwJNcA21ve9v/+yvAtNzWHr/6q7+a9lo0MVYqt8XLX/7yuOrKA0lF D1lmpda8Tp47q1RarjCgC/SBMTAH9KL63vWudyW3ItfgJz7xiWTRmDcTnIGIBFMAagTzR3/0R4lM gP4tt9yS6kIUgjYseDav9eEPfzit10JMygm6ELzB6lKHoA5lyCAvt6Q5KltsqZeLUzn3BZEgGv3X BvJkPb33ve9N5ewOYjsq7kJkpW/6mQkl99fRVleiHvUJ0asHGZKFqzJHdWoPaZkjVCc96StXqe/m AB2RKsIms3bVIzknp3lDO/Prh7pdQ370oH5ESV/aoTt1kYls1vCpV2IBy0t32kT22iAnIiZPDj5x pCs6YC1rTx8Fxui/duRB2HSUBw2poeJPoYFCA09aDWTcyEeK4L3y0ue2tvZoltqibh/g/oE4fuJ4 fOhvPhjRrEcpGikA8fu+93ui0tkZvb190ds/EN29/YlvOtrKkbnpEefMHkn7gM1HYi2wMCSgKGjj JS95SZor0gkLm//sz/4sHQVTAFsWGEBEQqIeRTEiGUQq+hHx/MAP/EAiRXsTet+ZAI/XvOY1qR2k 6PUz5ueQ1/d///encHlgaisqb4LWlnky5JQjE/PeiEzdW2+9NX75l385kQpy+N7v/d545zvfmd4g TQ6BJa997WtT38inrKAUc2X6a9spO4VoR//Mq+n3X//1X6frXiljSYCoR0Evgka8PPNnf/Znk4XG mkMOQvjpAvFqRxtIji6RhAhNCdHoi7lFsjkiKj8OgwfJ/CECVJ/ryNpekeYZzUGKynTPgMMRASK8 H//xH09ba5H1x37sx1J+C92Rp7yetfJI2EABiZLdc/Rc3L/55psTqXvmRSo0UGig0MDjoYFve53Z fyYM8MouL8QDaIWjG7WzupCF+6wXVoNdMAAzSw0QGsUDPa47offyA2/WDOvBfUQAOJUTFSkoxHUA zophaagb+CMLdbFWBF5w52kHUHNXAmEE5L5zASK2jfIGasl14Iz01CkikxVIRoSpTdYMS8R6MYks yEDfWSfysJpYPEBeRCSLTd9YOpYQ6IP+uS/whH70kw6Rj2t2Q0GU2qc3SRvKkZPFSXYWVB5EKO+e cH+EJb8P3eRF4kjYh9VGFjqlG/kEuVhOkQN4tE33ZNJPefTVjiyecY7MpBNkbnChTxILr0iFBgoN FBp4PDTwqN2MD7NfHnWXkqsLGCM2BAHggGQmFxaBraoAHYsFWSEHEYosKGVYV8AecLKuWG0sGhGJ 3FgsMfVxhRn5K48sWEGIjyUiYhAwu68eofF2nUd43JHuIzZtqgt5IAbyiTR81atelUiDpWbdmzaU YzGSGRkgDRYi2ZVFXK6rkzWV20aEtvGiBzIiGWSMNMiqjDzkRPbIh+WK5EVJssgMBrhF6VW/tYFc HPVJXn0iE6JBLupHxMogNaTpiIy0h3AQpTqc04EIT30lI5k9C4TlukQ+cuqvsuRD2p659pC/pRSI TiSpvuQBDDmKVGig0MCTWwPwBRbkI23ApAvpZvyOohlbj6U16jb4BlzAEVFIQBXAIhspA1oGONd0 BCBL5lYAo5Q7e260n+vK5vp9z20gk0eK6APMrBduN3mVVVeWiwWBUIF5liMJc85WU/JkwM/3vvGo H7lu5CK5lvtEJ86zHtxDAKxDiXzk8iEzWekB8bHQcr5zdZcKrkWY6oN29QP5sVC5TfVdeeSY+6d+ BM1iRXZ53sxzVEd2USJgbsgsE0LLunJNQvjyqM+5dpSXt0iFBgoNFBqAn7DFMeMu4+UJ2c7qP3sc ABl4OgLpDIqsAMK7B+DdB6SOOgT8nHPd6VR22QF75+5L8krAF3FJ2kAM2gPUwJVrE3BL5pMk95GF lMmWXK7nvNpTXj1IgnUl5fsIRdtS7qN7QD6nnNdD4vIkm3bIrs/IwdF9ckhIyjUElcu7ThfmpNxn kZIvvyom69YgQBlzkqwzBGLHEWXyDwWRsZDNzUnch/lcfxGP58KqlU8dAnToxjOhf/no5EMf+lCq l6UrICYTJtnkZQ3rKzexXU3ohmV9br+SEMWfQgOFBgoNPEYauCABIJkoHLnrgBv3IJeVII5XvOIV CSwFOLjGGgCEXFT2RgTqXIoAlxtLArzmbZACgnjhC1+YRvzKAXXzOtxb3Hrcgr6bqzEPlOsHvt4l Zp4K0HIPiqRkiSARAQtccmQSSOE+t162WgSBIAjzQ+SQuP8QpDa42wRrcCUiD+fycWHSAZcbkJfX AmlBIkjTx6JpLkLuSt9ZUohfRCQ5brnllqQXffq93/u91Jb8+qktJERHrCPkYQ6P+1Id9KJOe1Oa G0OKCIm82vEcnCtvKzBvC6ArgwUuRoRITyysn/mZn4k3v/nNicQEt/zcz/1cIry8bZh9LJGbZy+4 hBXpuSJ0gTKCaYpUaKDQQKGBx1oD501m2eJwzCN1lhEwNbI3UmdpAUhzTwIhfvu3fzuB6k/91E8l EAR8gjVYRcgAISEfJMQ9BsSRAmLhunIuso6VIPBAndpjWZivkQeQivJTJ5Jh7bAUyAT8WSbqANjI TB0sL+4xhCCfMvpFFiSNlMmmTRabvRkRB4IxN2UeCdEiDsEbgjOQgl1CfuInfiLlQ3yus4DIR2d0 g6CQgTrclw+pIUTfvRKGXIjYvBlLSh5kqH92KckDAWSMpJWjO3XbSkxUqDpEUzrqg2ei/3RtXlMd yJquETsyNKiQyGueDYG6p15l6Nuelp61ukSOeuYIskiFBgoNFBp4PDTwcDzHd9gagsjuPwCNFABa Jh2WhUg8oMf1BIR9t9mvwAhgDXxF3nGZGeUrj0RyOYDKteaehExYPohLPq45brFs4SAH99SDHJAl S4xVxWoiB1nJhKgQkECIPN+FLLWlD9pldSAWBIG0lEWIrBzlnNODuiR5WGGI7qMf/WgKnkAQyIX1 SUdkssEyWbUvac99RIM0kI22EJgADCSCIORBZD4sIf3QP+Uk+lAv3WsLcZMpu3iRuPP8bOhN/YhM Xw0g9Is8rCz1y+N55WeAwMm9eWRTXHH5gWjWG3HlgSvikosuDm9zHT1zdm0ftIjlxaV0Lb3ltRlR XV556DvSM3A4NyH4IhUaKDRQaODRaOC8A0DyXsUACYACIsAOZJEDQAfKSME5cAWYABexKAOkkRIQ BbCAnlUEQH2UzxaMzqk3gyCwBc7qUm8GYe0DcXIBYEQJjLksAbt2WE2AmnWGUOXTtuS7+SIkhBBZ bMogbnWSSX7krG/kYwUiFfdYpwhbPepwPfdPe8q5rn1yZznzTvysIfVqD1Hrb9aDdhEuMqEfddFr njNDgIiNTn3k0xZ9KJtdmurV32yROlefvtKx/Mpqy3f5PSvXtKlPSwuL0WOhdb42MhLjY2PJavXm BGWH6E1AS29vzM7MxMDgYOtdeGsvgiVrJmK6V8bvwqdIhQYKDfz314D/aTiX/7f1CAdcyACQ83Yz skoQB5AEckDJuQSgkQ0QBPbcUgBSYm0od26SVwLGLJOczDlxa1EEguFmkzeDtrokbeT1WLkseYC3 OTyAjCQAssQaVIcEyF33HZiTGUH6SIgkH+VDALnPQFc5JKkNydyT+z7q8mH9ZCtWH3yURf5IROKe VAd56NN1efTfd3m1rx4ykQORSSwp+tGWdvUDiSFPelev6whOWQSpHfUjTgTlPp2pQ3n90hYdOyJM ebPO5ZucmEjPduPISCwtLsaGjRuTbgfX9sh0zQ9ZIvvUWoCPuvsHWxGtnq3nJ5HHuWvnkly6Wfwp NFBooNDAN9HAeZNZJqRMAACRVQWoWTQsE6TmAwQBqshDYC8JJABw5mPMlynne56Xcg7cgKGoPtft hKE+9zLgZyBUJ/IC0oCefNplKcmrHW2qz84WkvqBuPvqVJejlIkGkLuvvpzfNdF8viObbBkBYW0D elYjlyfSRyDmlQSDsBKzNZiJTH3047tyyF8d6kVU7tMtF5+5MIEhdEFnf/mXfxmvfOUrk2tV+5Id SLTrvW/uk9G8X5ZPG7YCE6TBajRv9n3f932J7JRHJOqgS65ewSmu2RWFnD5333lXcq966wDXr8CU N77xjWmwMTM9nfT3kY98JFlx3LQCbeSVyPac5z036Y8Ofc59jr4XqdBAoYFCA9+OBs6bzAAS0EEG CEagAUvK/IvdOCyUFqTACuCGs0AZuJlTshAaQSEO4G8+iJUh0k5wB+tMPqAJZIEvNyKLShSk9oCf rZYQFnIS3IAEAP8HPvCBNE/FugLE8pBXEAei/d//+3+nurQDtFlFAF90pAXUSE89wB7xcJOap0Is +iwaULCHKEJWFzkEaiSQv/vu5EJU37vf/e405+Y+MvKhD6CO2EQJkh3JmHcTTPErv/IrqS9vfetb k24zMQtsseWUSEwEhPjMyyFZ1ip3qlB7xGFXE9tw0bF6Wa0Iy/OhI5Gm6iWjqEZyk8FzkgdJioQU 7YiotCmaEaE5f9GLXhTvf//7U3m7nAiSYfkaAHiWrEHWF30qZ0BBZs+BLH/6p3+anoc++P1I9GrQ 4JituW/nh1zkKTRQaODJrYHzJrNsmVEjwAeAwIqlBvC4o1gvgh8ALfJBVnluSZAG1xhCYwFwgQkd R1pA064YgBX4ISXzXAIgMggDW2Tkk12YCAuJmh8DzqwFEXYsQvKwznJovHMgSy6WofbVo4z2kIe2 3HcP8AJa31mJ5EIiiNv7zICy/RFZSfaYzCCPKBAeixQpmitDysgasSECVhZdkf9Nb3pTaiNbZWSg UySkLnnpjfxInjx0r38IhOWHFC15oAP1W8YgyY+UkSlyQexcpFyxynsW+kFGRG3uy7NDXmSW5JeH xcbyvOjii9MzkGdk06YkK70gNoOEa669Nlmm+rP/0ktTHee6PtOF4k+hgUIDhQa+Qw2cdzQjgDUv IwEnAIdsWC9vectbEugBPu4yH6Dse7Z0EF+2KgAv4APMohxZaUAZaCMnIA+QEQKiAcQZbH03opeQ DotKHYBa2DrrhHVHVkRp+yXgrQ1EC7iRDbn1AbFKLCftIwB1AmNykF+Eo74Ac6SF3PTHll0sQRYN YuESZLHoO5LUnjqQq4SEkJQ61eU7GUQ76gsdOyJROkZ46kLQkn6Qk8xIxzIH53SiHuXkkfSFDBJS 1G8yKm9AoH/q1xd59U/SvnOy0IV83Ll0Rt7a6mpycbKmnNMVy5ZrVd2S50pnY6OjcdeddybLy+DA oCUneXLefJ7vFcdCA4UGCg38Zxq4INGMQAeR+ABRIAlEHYEbsMpE4xx4Ss4BrQQkkR1AB4CucyOq Jx9TxrU/eS4rXwOeADfPdQF7srBKtOO+eiVyuUeOnB9wIyKJrMp8Y1515jrISzbXHHNduaw2sl70 C3nl+nMb7utnbst18mb3mrpzHvWqR37r0VhkiCC3J19uUx3uOSIcREmHviNDutBv+sq6zc/EdXWx FnNgCeLSx6wzMtA/4q+v1qLN/OLaNl3pma4FeyT9ZavWxtBrEaPy33nHHckVPbxhfWpPmz7fmPLz +cbrxfdCA4UG/vtoIOOaI/yQLnQ043lbZoQiHNABeIR1JCjwkzLgAjrgKQFP5TKIAmr3gDBQy9YP gFYfYM8JkKpTArQSkiGDOpQB1GTJROE+a0NSt/LnAmUmGu1kZSuvLkledeaUicUclDkqZeTNRJRl IJ97SCQn9eqDOh0RR05cqoJo5NEeHTrSiXpYo1x9mazkQ8TK6bu+uSchXFYTmcibnwcyy+fu5WfA /WkwQXaWrCQv0qIXbdEnWTKpu4bI8n3fF1htU1MpslHduX55EFl1ZSWuvOqqRLL6RE46yPpQfz5H xuYYpdRWOmv98Qzdl8jpO1cxi7ZIhQYKDTy5NHDeu+avrrbACtAAJi7GP//zP0/AAqiBLyAFOhYr m6sBNtx9riM99wCoIAX1ACW7ZgBt2zQpZy5HwABgVAfgBeDccgIMADlLAghKQNqaLfcFNNjHEOgr zwUI9NVBDsBODqThu2hBc3rqJxNCALiISb3yk1M973jHO5I7z/wQ9xzg1wZXH4vI3Jx6uPlycAY5 yaI+LjsvJUV2glrMbWmP3PRkbRv56Uj9gk6Qnbk6euGGNecn2IOb0B6NyF85OtUf7QrUcK7Pj8Mg awAAIABJREFUAj/Ux0VI1/IL2DAfSQ59QgpcuAhIeQE93JP5u11HuDnpW4QiebWnfmQqgEdf9DXv IXnDjTfGbbfeGnv27k3P6LOf+UwMDA4k2Q0I1E1/5ESWv/Zrv5bmI80rkk9b6vNM6E7/uTLldzS/ aY7Vu/E8J8/EsUiFBgoNPLEayIPxfCRNwsD/Si/nBIZAJpOIOSpAb7cNEXBA6mUve1la6wTcWDII DxgL9GAJyIssgCILyStg1IFcALpOixIElEjIKPztb397AjZrqICZaEAEhAgk4IfklMmAhhQAJrLR NtA1Twcsgb1gFHIhNkDPnSc/ItIu4hEtqZw69Vl/yeaeOuQ1Z8YKdA+hIR/9RDjAVnltmoPSv5/+ 6Z9O7z9j9Xj5KNn0Q7+Rzu///u+ntgTOqB+J0pl6DBi0gZDoAakjJfpDDEjJoEEUqe2+EMBP/uRP puAU85Pu0SfLyByb+S316JNnIspRII35T8/OfKW5SME9dPD7v/d/Eolq38BFxCaZzIOKqLR12S/+ 4i+mgcWxo0fT9XqtFr/+67+eyp889WB6buZE9R8pksczokdtGDzQhUhZ/TdQEABDNjr54Ac/GK9/ /etTOaQm+tRAxjxmkQoNFBp4cmjgggxbsS3wycko3jXkISoPQCEqFoRRNRAFRoAU4HFpATJgipwE SzhHAKwz50hFiD+Qdi6/UTrQtwmxqDrgLQFTJAp8AR/LyEgf8ToHvECSnKwLQEl+lo32ka3y2s7g jLiUy2SJJIz81UEm5MlyUg4hy+sjH3JAaI76woLJpIqQvMjTEYEiHPXqmzwSUmGN0pl69MN9BKou MiBG97StL0iQHgwI9A9Bsta0geT1E+EgCvVJ8qnDziWIwPNDfuqhL3UjLMSnDQRP5wYAXmlON2SX PDsk6G3flkL4PbCu9YlsdKtdgwMykk2gDhlc93zpXJCM/ORUVn8l+pLUjWBZZQYLSN7zONetmzIW fwoNFBr4H62B83YzmrMHbIAH4EmAFnCxQgAQywE4sXyEgyMNwMhFBpyM9BEYsFZWfb6rMxOjegEf MAWeABcgqxMY5jYAoXLuKSuSMLvT1M/yAIRcaCLrgCSyRaraVg9iUFZ/WFfKA0igSm7uVDLKg5xc QwxAVf3qQ2LuiZzUX/VrFzGRD/DTiX6SmYWY56EQc7ZOtJ91gdCQBKvJ2jDETAakQo+iJA0Q6JNu taEtMpFfXepmNXrxJuKQ3wf4s2Id6Re5ICBkz+L1PetVe8rozzOf8YxE5J1rc5TqpD99QWx0Tk4y Cdmfm51Nz0ao/rrBwbjq6quTPuXVP89SX+iTvpEh3dE5WTwTgwT1yy9ZguDZ+U4vBk7edECvnm+R Cg0UGnhiNQBL/A/nI2lgxX+pl3PmvRmzqgARAGGFIJRvlgA6MMx5cwfz9VwGcAM39QFQAMdKAFJ5 bkUbiAUxSJnMXAN8mWBz3UCdUn0QhvqBdB71Ky+Rz72c3FeXvDnlNsiJBIAvGdVBzmzF5fyOSM71 XIY86pU/Wxv6qj7XyZhJTnnf9RWgK0t32vPJ5RE+8pGP3LkfuW315Ova0idteR7O9Z27UhvqzbrV tnvICWGnZFPhs2cTUflu1w/yduSXra4F0bDcuBfVkfrW1pb2Z1xaWU7fc/8d8++B3LmPyhlo5JTz y0tuz9PvJJdF2IitSIUGCg088RrIOOfof1UynXMh92Y8bzcjsMuAkgVGZEARULqX3VI6gABckzJI uqZsBl1A5QP0XAdWyAsAIwzuQ8AMcM05ObpHSfLmunM77gFhSdmcgC45jRAETpjHAuosLbIA0Fyf oBAuOLLqn6Oy5ERgyMnDcVQfMM1ReOrJMmaCU5+F1tojEyJixZk7Ur9AD22TkftS0o/sqvXdVlSC MsiqvHL0JQ89cdHJI/meSRGx01XWhedAV8iLnpznHxz3qTZYbfkckem/votkZHHNW6j+la8kotPf nErlcnJrWlfGvUk+vxlh+pJnTF7uWYlbk+701TOhH/1DZHRLtnOfJzndJ4/fhO/0kH9bqdLiT6GB QgP/4zXwsJnxHXY1gwZgByQAWtSheSwuMPNP3FTABiEBMqANqE3Um+eQuCTtWwhoBYAALAmBCHjw 3i0gZ9upvEDZNk4CP0z2c6FZe2XOCbkAXMDI3QTUAa+AAu3agspOFRnc5XPtbW97W5KT/NyX3Ia2 3tIXc05kVLf2JHN4glq4PO1EwiJCaHRhblB55/qlbQEL9IA0kIP8dCRQJrsk5fmFX/iFJDMSI78y AhsQDdBnGYny1Ee64VIE+qxUQSvya9fejcrTKXm0x70owpIOzbnZpUSAhkGBAAv56V4ZuiK7PpPZ d4SmXdGK8nre2vR8zJEZwNCT3wIZuFg9E1uXkcH8qPky7mZzhU9/5jNStCSyVzdy8zy4Dg0q6J0e WZpIy3MkC1LMvz3kSTfZMs2u4PSQij+FBgoNPCk0cEEsM5pCUkbELA9EYZQMmO0wASSBnhBvE/aA UxSaAAOAbbsk10WlyQOcgFW2coSsf/jDH04gh1iy5aEdoA44BZXIoy2gCriVV7/7AjkQI/m0jci0 ITlHXiLlWCGCRpATK8A8DRIGqEBePQgLGbieAxjILBJRefdFDwJvc4cIi26EjLPIADPgRWiz0zOx /+JL0ju+brz+hvD55L9/IrZv3ZY+n7nt0zHYPxAb12+I+dm5dF+Z0w+eiuuvvS4RFwLJLjbWVg5k QfTm1/QDKSFmyVyhOSokTDakI9Qe0RkUkBkxsuYEVOij8sibLrVnHg6B/N7v/5944PChEJW4feeO OHXmdEzPzkRvf1+MbN4U6zduiO9+6Uvia3fcHtXaauzYtTPuue/eqDXqce3116U2tO9ZImZtm19j 3RqceGaZpORDYD7I228uPz/fcyJjkQoNFBp4cmngYQT4DvsNWIzYAU2eI0MgANToG4kBJfm43YAo YjC6R3RG5Kwz14CrUT1yAZRG6awqwMnN5DpQRVysE8QgoAHgAjOBEghGe+rP7irlkBvyQjDKOSc3 KwaAIlQgzVrRF20jL0SKiFhE51op3IHuOyIysnPpCSwhj82FWZ7IWb0sCvf0kxUGoFkz2kbkEnes tgQ8kA/ZC6CgQ3UgQUSOdIE/qwrwZ72zpuiGnEiNhUJv5KMvROXZqMNggwWEfFlLgkdYWHSmLELX JwMD7SNqgxPWkQEBPeqTDZnJo0/u6bsBgDbp3PO1JgxpCizRJ78Bz9dz13+6FurvzePK+JCHbgWT 0BV9IC+/IwlhFaSVVFH8KTRQaAAmNOqrTSDR3tEZpXIpotkeUS5Fqb0jLVx+3WtflRSVx7oP76LX smoEgCAEIANckBgAB7A+AA5AmowH/qwl4OW6dl0DfKLRgCPQYmW4nwFMnQhGXiN1bjXn8gBL+aU8 OgeeiIF7DPA6zwSpffVqE6h+YyID8FQv+ZRzjvjIoU71I03kQQb9Vs45OXNCHPrlmvLu05W85NdO X29fnD1zJjatBVSI9uu3UfPSUgL85DK0RZjtudaCKrwfrHtta665+VZgTG6TTMhR35CXpC0ERW9k 0PdM8OTKAwUWs4GDa5k8WUj6p9+IHvnQg+ctDz14vu67np8luREmF/O5+ndNGc9MeeUctUM+dSF0 5GeOjXWJlMnkuXEx5qS9gtCyNopjoYH/uhrwvwufHfP/LA/WhQwAeRh5v0M9ZEABmICGoEbgOQE1 RIYQ3AemwMtRkh/g62Qeget0Jr1MUPIiAYDnnvK5TaSjvCOQRJYAk2yAkUUDZMningREJSDqPCs4 j/zJqh2ykst9QCyvNsz7sSy1m2X3cNzTHlkBv3vq9CEveciGTOTxokpEZnNeRAT49QMBsmIQjXNE trK2qTNZkNkJr75ZN5j6Rl5tsXjIpRw3oTbJJGxd/ZLvdCOPc+UkVpD8dItA9N2RzMiEtSuRm060 RacIi8z66Lr8BjKeO73Th+evTYMLekVarDmJTn24XZGwcuo1b5Z/J/l3lgp8wx6W+VpxLDRQaODJ q4HzdjMCVkCWSYf7iTuKi4hry9ZJ3FjAi1uJ1Qa4AB6AMsFvrkx5wSJenwLQgZhjToBY0IFACITk O3IBrEAUaAJm9ZMJQJNBfvVwXSEFMrEwgKUjsHZf3UBWWXVKZLAVE6vmD//wD9Ock/79zu/8TnKL yadf2ucOFXChLgEi3keG8ORxlH7zN38zRehxt9oZQyDG0PBwIqX2jo4UwWgrMCQkuOWWW25J5cks alCf3/ve96Z5wa/ffXfaNkz/9IuM9OklnH/8x3+c+uk9ab6zJF1jKSIMenLNUVt0T1/6m8kDqXlO CA0xITPPWVJOW44+8tCBOuVBcgYJdIy0JWSrDsk1pOW+pC561B7SI4s+ZVny70sbOX+WJV0o/hQa KDTwpNfAeZMZ4MmgRpvmawQTAHeWhQg1wGTOieWSSQ+gIY5MKIhMVB+CAo5ILoMXQgCQ6hKuLWwd oQgYUA5om+8RnCFww3yVPIDe3A95yAW4yfHOd74zzRXZJoorS0g+okUI+sK6AMZkMA/nu3bMDSEU +S3GBs7yqNPcEgsEACNzc3/K6QsCoQtEyI0HxBGaupGU+mZnZh4K5QfuXIVIW78RtT4gIyTD8qUL JGkOjh5tYUU2OmRB0Zm5Lvct+vbqHOSORBAB65BsCEQ/PBdyqR+h0IPkPqLxvORTr+eZCHbt30ce iayemfsGCeSS1Cf5nglMe/n5uq4ObbimDWXImWVSZ67PNb+7IhUaKDRQaCBr4LzdjJmcVAhkgA7A BOxAmXtLwAH3oPuCL4AtoHff0agd0QFvcyXuIzkWgYSEgBywBLLAVZCEF2Cy/LjLgLBoPQAIpNUF xJEIK9C7zFheQulZbwIfBI8gBVF8gkYAMJA8FzQRBDcaF5y+OIrqQxJkEcThKNw8k5VgEq5T5TJJ kF3QBtcZghU96ROlUuozErSdE1DnZhMAIb9+A/m8E4d+KaduhOtIPwIv5BO9SH8iGkVcpjbWrB8E QQfqkDIJISYuvyyr55F1IJ/+IVT1S849Y3oldybtXB8yQpZ06ZmrT8oE5vm4pmwmUt89V7K57reR yS5bYec+m3N/d6ny4k+hgUIDT2oNnLdlRnuIJI/YWQ0sDsEH5keATg4FB3Ai+jL4ATpAxQWIWICt MoCNywoRAc4MtKwddSESQC25liPlrHtCYLaGQnYAUQCBqEJh+4ASadkvUp3AWMQlYCYnMJUAOWLT DvJlASGJPKckghDAA2JLA9SjXW3RBSJBfEAZSSMv/XJdUo+6tel1KFyTXd3daY5NvQJA6EkZiWVH NsRKDgRIL7Z6MnhAaNrIAwn6QJ5C6g0qBM2IFiQfHZBbUp8PXZzrIsyWlDyeq0EFIvOsEEomNc/T syQLItN3dbsunUtIdOR5S2Qga3Z10re8SFx9dEB36pWcS7l9estEl24UfwoNFBp40mvgvKMZV1Za 7xujSWAFaHwAUQa9c60BgASI8jXgKL+je4AUGAI33wGd/OfWB4Cz5YD4WCjIR1nfpVz/uU/43Pv5 urLkBK6AW3nyAGXfyQF0WZYSK4glqC73kAYQPxdwta0eoKwuSV4y57xZ5mhGilTUx9xujlpsmIts a4uJ8fFYv2FDNFmN56ynShWXHt6aSt10hhAkMmaiMGAQkJLlzHKQS19d9/zk9yzoO1vG6pJHf6Rc Nn0p/hQaKDRQaOARNHAuzmfsNtC/kNGM522ZAW0AKhGYoMDcNeCYXX7AMOdBDkbnwFY+5ATIgaXr krLKAHnnCEc+5wjkXGJCZPJmJalTPdqRfAfA8pwrhzkl8pPbvBcSUMb8E1mQqrKIDLFpW1uIKBMZ OTJBmHPTD3nI4ly76vTdOQtFmUz05KMvpKWN3AcvuCQrAkNk9jVMxFOtpvk15WwhpUxu39FcXO5j JlRHMtGlRAb9kuhUOWVYwvLoO0sr55GPjiQyuC5/bifdKP4UGig0UGjgCdTAec+ZATTgl0frvp9L SBkU5ZGAYQbyDJDICSgDf8CbrTBl5AGeyrGefDKpqM995ZAAUsjATh5ykEd96sruL+XMmwlSsXCY e0vwCBJjjXDLmVMD7AI7zGUl997aW6oRQ07kkQSQcBdatKwMebgjHbkABY8I4CAvWfQByV2876JU zrlrCJY7klvQPBhXYk9vb+o/ssyEw33IvWiwYB4QwXJ1ioLkOuXuZUXStfYEmahXX9XjvvYQOEIT YIIIuT+Vd53usrznEpt7nkcm3qyL4lhooNBAoYEnSgPnTWYEB3iZRBBLXi8EDLNl5RwAAkIgyjpx LiEe5zkwQF7khtgywckHdJEH0kI66pHkcZ37L7dJHvWqR17tyS8fl5sAE3NI5sPsEfjWt741EQjC ed3rXpeWCAD8N7/5zWkbKkES3HTKve9970sE9OpXvzrNDQJ6UY3Igi6Qi2hHJI0U7QxiHlF5xGqp AvIS5PGVL305ESsSFMEokEQbAkh86M+8GkJCwKIqEZkoTMQzOj6W6kSY8pNFn3zUQ+fZLWr9GTKT 13WJvuiGbu3mQVbzlxKyymStfUn9ZJKfjp0XqdBAoYFCA0+0Bs7bzQjkkIuEPICbdVasFO4s67cA p22hgDXwFD4P0FkOvgNFRMM6kBCCyEQkJa8XLyIThGGXCpaRPDm94x3vSKcAXB3KkQGpsExccw6Y kRtAB+xC+5V5wxvekN4SzdKxhdN73vOetH+jvlhflolII4hEeYEoyCuTp2AL5IQ4WGTuC+CwRED/ ESqZEbYIQ/tDCtNnuQrAYFUhMttGOScL2cicSRsZKovEWJ0sSO3rr4ARbdCNMvrneZCVXAJftCcv Qsqk5PkhXfXYYPnFL35x0hGyVT7rmS6cK58tMudFKjRQaKDQwH8FDZx3AAhOAWoANx+5q8wzAUQf 0XuAF3ACW5Yb0Gd5SawVKVskysiX3Vki+QA+9xjAzhaB9gCu+oSjA1ztAHB1IEtRlfIgXKBNBuSC 1IAzsmOpueecu07KhImUyYp0clLWR36yAHdtIQjWEVcgMlK/6+pyzxq5/5+9946W477uPL9Vnbtf vxzxHjIIgiQAgpkUo0TLlGRLooIli9JaY3vHSZ61veuw59jetWfmnPHxH7vj9Tme0dqULFsOskRJ tEVJlCyKmWBEIDJAhIf0Al7ofp1T7fnc6gIfSQQSACV6p35Av+qq+tUv3Kq+37r3dwOS2i/8wi/Y eBlrKuH7kQWgTj/Qg/FzPZaJGIQQIYRikhJpTubnre2BoUEbB9dDd+jASwRAylx5CQCAkb6CthkD gAn9oQVzYJ7BPYR+lADwbOd1RiDUtbEEJ8NtSIGQAiEFzkKB4EWYbfAyfKkNQC5azRioC9kGa1SY pcMIASOYKmASqMBggpjCByrFABSgARIEBSYMUHCONvgOGAEq7AfMmroAGAwfIvE9kIAAED4U+qeN ADwZA98ZI4AI8HJ9MDaugcmzD9MHZAMwC+YLI2ecFMbGPFG9URgP13PTAmClPhH/qQMwUww0PN/0 PAAsIoEwLiKDvN56MXhZYD5d3d0GwIlU0kCN9UDoDkAylmCu0Iu5AdaMieOsxQXzBcgo3DtAlGsp wf0JQJa+AXruI9cyBuYHzcMSUiCkQEiBHzcFLlpPFKioYIZIE+xjvIB/FmCEkQUMk+gTGEbACFE5 4uwM84TZwrxh8uQqQ/0II0U9B+NlnQgEpw1UjFgdBgwXsAEkAokHCY4QUTgvA0D0Q+E62gCIYOgw aNoG4GDIAajRB+dol+OAFWNE2oGRw8C5jjYCIKM+c6dt+kQqC66nHsweoKEOakKAk2v4BAU6sS7G OCxTc9uiMzDDJzoIIBe0h0EIkUMAGK6hbdqAhvi9MUYK+4Eky3iZU9AvW+bLnBg7Kk2AkPki6RIx hUIUFb5zHomOfriH0C4EMiNR+CekQEiBdwAF3pRkhqkA6sTIIuhDaoBpx+K+6o65sM/6FowTAIFZ wgwxtECVx5oZKkcYI6CHEcM9P3mPIm5E3374IXV2ZLV39x6TWJ556mndcdvtOjU1beD4B3/wB9qz a7cBw1ryf7WBafPTz8jxZOcAQRjs888+Z1IKSSFvvulmHT0ybkC7ZvUaWVR6VIa+/YMxeECBAoMH HBgbBUYP02ZebIOCOg/gxMoxYOjEl8Ri8HOf+5wBCuCNEQhWkoGqkjU26gPg5F1D2mOfEF5Ia5wH OIggwjEsJIlyYpKcI21+7ll7SeAa1Jg4jNM+IMp1pIshrBdRTe677z5bE+QFg7oYjrAmh1UmdMG4 BckQqRJpC6MQ1Li/+Iu/qD/8wz800GX9kOgtSHyoKjGUYW0umDPAt5guAX3CbUiBkAIhBX7UFFgE T2fvmgh7r1/r5y0fqYg3dUqgBoTxI4kALEhQ1IGZYyABU2YfkENlyLX4SlFQ5wEqSBOowYI1K75z DoCE2cOc8bmKJxImgdAPkhPSAmbtMFukKCQgmDRrTQColbZbAHUpe/fsOS2pAET0wQcJhAJgAcIU xs0Hg5TPf/7zZgLPNcwXACT0FCGnMFIhNiPggFQKIAImtIPUhrUkAE8MRa4FjBgz5wHEe++914Dm T//0T40eSKYBuEIv5gQtmSsvDoAm0ipGJ9TFBQDjkvvvv9/qQB8+HA+iptAG9KddvjNGaMg+a2yo gVH5Mr+Pf/zjBqwcQ7KkLejLnEMgs0cj/BNSIKTAO4AC55XMWp5Ib6Ygn5lv0e2vBwFoSBkUVF1I E/goEWkeyzkYNQYQqK9g1khkMEOYIG/1MF2Ab35uzqQEmDH7AEEATsG1SBwwWoCRtoZZd3IcY9Co EwEGzOuJDo/lHv0iacGQARCkKdoN1HwwYwBl1ZrVpoJEDQnoAQxIOtRDmoHpB/NkjkhbgAnAy1gB ZgptA7RYGyLF0A5SEGo/+gYcUN8xb9bOABAsDgFqwI5j0AeAQuL7vd/7PfOBIw5kUAAU6M3YAkAB jAAZaIKkxT2A7p/5zGcM6KA1cwhUjrx0AKrBuh3nAWnGSBsAGhIf4+QeQiP6Q8XJHNnHdJ/xQ/NA pRmMMdyGFAgpEFLgx0GB81oz4nsUi74KZmoCZKzX+MNtNj0Dq+CtHdVZIK3A6AAlGB+qKdZmAACA BFCDyQbqPlpjvQjDBsrszMxpK0CYbYTknNWqSXPUKRWLviQVj1tEDJg8AEM9CgDZ3dNjoaIYA2PK dHRYG9QzQwuSijK5tmTJeOkrAFzGTQkAG4ZOW4GajflwDUDBFvAMJFbqcZ5rAFbABymTNq3/RUk8 MWiBLtQFRAKplH36YjyBAYoNqP2HuvTJuhiF+vQPoAWGMNThWoA2aANQBQSZa3AN42Vc7PMCQQEc uR5pFfoxdtqlT+ZDG2EJKRBSIKTA+SgQ8Be28CjKpbZmPK+aEeb2+sIx1HcACswWIIPBwSx58w/e 2KkHg2TwMEQkGwrXMCmYI8YNFFSHgAZtUmDuXIvEEIzBmGkb7AAPLABJbkldvgNkZGgG9AAywJHj iWTSgIxszQApQEZhDLSNRMLYYO7Mw8CzHaWfMQVGD0iFjJ02qMcYKEgzzBspjePUpx5SD+0i2eAi AChRB4AAXPgEEhP16RcaBjceYxj65BhzBxxpg/YptA+4MH7W4JDsKIAhdWmPMUJ/2gBUKUh4tEcJ 2oIOjIe6gBgfzgX+gNCBvgA6xgeQBaBnDYV/QgqEFAgp8GOkwHnBbPHYUDnC7PjA6GBmrC8REgqw glmyloNhB6GhULVhmAADpqC2w8gAdRVMnAITPXH8uAER62AwdUAH9SAMF6tGHKBPTU8bUGDAAVjR zv59+8xiEQtGQI3jgAUgCEjC3Mulkk6eOKFXDhww5s64t23daucBOpg+aj7GhBUk+6gl+c48g7Ut AJr5cT1vFKg8KUgoFPoiISeGL5wDsJgjn8B5GytPImwgiWGBSSR/AAfHbKQlgIt5Qdff//3ft+Sb jAG1J7SkXRybf/CDHxh4Qh9oC5izVgdwMj4MQCiAHOOjPUApqM94GB8AzHgpzI/1N8aGqhbVLSCN ypL7GdwvQCx4uQglMyNd+CekQEiBdwAFzrtmBjOl+BaNLcXMpNE1pgmznD41awYLqLYw+OAYTJG0 K4AcjJj1IkAB03vWs2CgMFi+Y70Io8QKkDd/0p987+GHDVCQKgAXDDEwqgA4YchE1wBYSPOClISV ZBCBg4C9FCKIwJixxHvwwQfNOIL+mA/XMh4kFBYE6Z+1LdSAAAbzAJyJEIJEhQRExmb6wiACJs84 mBuGE6xBsab3m7/5mxb6CmMLsk7/1m/9lgEfUVAYY+DAjQSEhSfzA3gAMdrAnQGgIecZxi6sqQE6 gDVjhz70CfAQs5ExAt4AFdaJSMh//ud/bt+RznixYJyAbxCmC/cIPp/85CcNsJg3YIXKF/84aAad MRaBTtCVa5kzwImER//Qif7CElIgpEBIgXcCBc4rmYFlABlB1oM3cgaOOg2mDBMGDAAJU+G1VVsw eZgha26ch2mjnoJhwzgx/oApAlYADgUgw+QfpokRBR8YJtZ+AArtIMlwPQCAEQNMGwCFycPc8b+i YDgBw8WoBKkHYEDqo2ByTluMnfMAMWNHQqNPjDxoiz6QPugHQED1xnfOAUTMkcJx6j3wwAO2BQwB YK4HUAAI5oSUxBaA4ThgihqV44wB+kILDC+YN8YkSJlIUIAboEKfXI8EBs0BO8ZM4Tv0AUyhPR9o BX1IIspLBWP5yEc+YsDFnKA/9yJQm6ISxSiFcSLxAaD0RZ8AGd+ZewhkRvLwT0iBkALvEAq8ZQMQ 4ADGNjszbdJVpVo3SQawABAADhgob/IADIwPRg+YcR5JAgYJIFBnfnbOmO7Gq69+lSSeZybwtAPz hnHCXGHeqBwD5osEiAUiAAOjR4qgHsCH2g+wQgKiYCaPnxXHkaI4DvPv6uk2Jg/IwqypNjdnAAAg AElEQVQBA9oDiGgHyQWTe44jsQA0AA8gA9NnTnwAR1SVAAv0YY6Ml3EB2rTNPvQAJDgWGJZwPS8G 7FMfUKU/6MMYAsDF/B51I7RDikKtCD0ZF2pL4jpSHykQwKYeYMWWFwn6XbzlOPOGvtACeiGdQkPG AbAS1xJwJD4l9wPAZa68GNA37YUlpEBIgZACZ6IAfJIC34D/BVuO8SJ//Ni4+Sq33JiqDU/DS0b1 xFNP6uc/9WmpVZXjNRRxpC98/r8p05nVwOCQBkbG1Ds4YvwvFY/KaVsRnhfMPn3fJ2wwKBuReQK9 pNdq2Fu6HN8JGKYGk4PBwqhhxmwDwwjOc459JggjNEnJ840/+A7jhakSysnWv9oGFqyT0R7XsYUo lEClaFaQWPS1jwfXIuVRYM4GJq5rRiH0jSTS2dWluXlfPRqMmXHSPltACUDhHMcYOyAV1LXGF/1B EkJS5Dx9UAAq9gExvtMO86D94EZTj74AF9SvtMH3YJ7QlfMcR7KiLca1+MEA0JAQA+mT89CSPjnG FrBkLJwL+ofm0JQ6tM38aJe5An6smdFvAM5cz1gYO2MM+ltEhvBrSIGQAiEFjAIBjwr4TbDPyUsN ZudVMwb3pNlCtdiwSCAcI9QSDBtJAKYLU4RJwgSRathSYIIwPuoFUgJMFSbIxDDUQM0GEGB1aNJD s+kDJYYJ9bpdmyK2YjJphiKAGIYSWEAeHR+3CCGo7bCEDAAsGCNjox/Wv8jcTN+0xdhfevFFGyNg h3EKkiSMmggZjB81HFIcDJ3jjI0C8w8Kc6LQR0ALmHwAYswT8KEEYwmAEkANruUaCm3QVlAAMujH uCmMIagbgBzHkVB5WWBsAdCxBcRpMzgXXEsffBhbMAfuVQC4dh9aLVvnQyILxh6MhbZDIAvuUrgN KRBS4M1QYDFvW/z9zVx7vjqvcuVz1IS1wl9hZEiNMGPUjKzFEM6KtSnWmShEt8DAAOMM1FNYNbJW wzoSqr577rnHmCDXwHi/8cDXbT0IZ+vnn3vOQAwVGkYNSBYADf19+MMftraRHu6++24DG6Jx3H77 7SaRADyoxVAL0m+kVDoNPhiAwLQxX6ct1GqsadH2S1u3WD0AmDHiEMxxnJdZq8NQhLkACEglQQnW o2DyFNoFINlCJ7ac4xpuGseCm8dx5h5cy/XBd/oBOIN9QCMAGLYASCAZBQDHOhb1uIZ+OE+/tBUU zgX90w7j4wO4cZwPdQBYvjM+6tEeheOc53hYQgqEFAgp8GYoEPCVgMdwDd/fjnJeyYxug2WRaDs4 I4NBmmJdhTUX1svYh+Eh1ZAfDHAARFhrAeCQbgA/tjBk1qUwTcdKD0BiLQzwYu3oz/7sz2ytDEaL RIHxA1usI4mUQV+slyE9AZAwWa7FtB9GjoRh61+xmAETjJ0cYNQBJP/iL/7CrqFd1sAwQwcsmRd1 mQfRO5BIsOpjDYsCcw9uRAAkgToxuDlcTwEEAsYfSDBsORacY5/6gAoluDYAGvqjUI9rGBeFNpgz hbrBWDjPPnUXAxljDurTVgBKtMM1AVDTH/Pher4H4+f6YAzWaftPQIvFx8LvIQVCCoQUCCgQ8IjF W74Hn6Depdie9zUblmkv54vAFMYGuMDsZ+dypqIjOC5ggeSFPxVqPyzoMIoADGCSAbNmXYjriWf4 D3/396ZiRFrCeATGzHVISUhISFSAGOeQlNjnWgxDUAsi0cGQMYwoFgoGcAAp60eoKJFYMFsnYG5g vg+TBkwJ5JvuyFgYLOIiYtCBfxtSHhIgOl1CSwUgQt/MEebPd24IwADjB0TpK1DZBecCQABkAkCB DhznuuA7N5Pv0Jbj9Ml32mNLfb6zZZ/2qceHsVA/AKmAzkhs0DPoN9gCVkHhOl4a2NJ2IF2yz3wo XMcn6JNjjCE4FrQVbkMKhBQIKbCYAvCMoPD99fvBuUuxPa8ByKc+9YnTsRkZVoB+lXLRwKZc8dOi mM9We0QAAoCC6hFQgOECTlgBBmbkTIo1H7V8FRzrYYAPBWCwNCft9qbaFpLsIn1RcIaGKXMd62SA DOGqLCp+O48Z0UCoAygCvEQIwbkaAxOMRgCBSq1q5+gTBg5gMEakP0AzAI4ACBgzTJ996gJsbCm0 Rztcw2dxYb5BGwGABeAVHIdOXMdxxs2H74wLUKJt6gaqwaA+5zkWtBP0FbQPkAbtMvbgOurxnWPM gfG/vtA27fKhHQrfuYZCH2EJKRBSIKTA2SgAr4CPwM8CzRF1ERomJ05cMmvGAJv8cXjtN3bP5DFk MsGr4r5tgprNlmr1qlx5ZkmIX1gqjZqLIMM5Y7gwN0zIKcRt7OjoNNCqVusGEidOTGjJkmE7x/lC Pqd0JqmI46nlSLVyTR1dXapgzEEg43ZUkAjrQTHGhx9aXpViSQMjwyrk/bQvAFm1bSzBAh8Axvgw Eunr77cwVxwDyDAEQQ0JIwewYOoUvsPUcepm3Y3zgBfHuRZgRuLjpgCeSC5sg+9INTB6rqMOBVDk OO0G518PTrTDMcAqABvGRL/sI8nyEAA2tEM9zgNwjIvvtE09jtEe46ZNvnNPALsAsDjHPuNkvFzP MdpHdQvwBWNmDtThQ6Eun2AMtBOWkAIhBf5HpkDgnvOqxsenhv9CHnwHTyjwj9cWrm/JcnlZhaAd n+e0Le9fe8kZ9qJO69W1ETpz3Ig8Jyav6SriJhSNSRPTOZWLCxro75HjNpWIRnRi8phOHj+pZUvJ EVY2hh6J+CbwB/bvUF9fvzFIrAiJ2DE8vEQv7N9m1nHbtu4xxtnb06m//sJfKRp19Uv//t+rwZpU E5+wzVo2tlTDS0Z08Oi4nt78jN518y1yo46FuiqVy3r6qSd136c/o9lcXr19Azq6f58xWKwSYeis dc0dHTfH5G1btpv0hXT2zQe/aepE1JQw+fnZnK3JAQoUAOFLX/qSPvShD1kbqOqOHjlmRiKO42ri hK8KBQgKbtGYP9JZvVqQ47m2LhgAGuMAkLiGdbwTUyetD0AjN+evMRK0GctB+kciBJwBQkDi5Lwf t5KL8Md7fcnNzZ9ez8zP++MvFfy4jUHdnPxwW8H+ubZBG+eqE54LKRBSIKSAT4GWPAcQaoNZIAwZ aLmSx9q7b2QGr/UltJoc1+d58FCpKTls0WS1wcsaB9D4IG9xnnN8AqB74z2Inj4ZgCUDWtRmtSZb 05qZnlShmNPQYK/cbMbUiFu3bdP1192sl1/eaYYVWPjBkJFUTp6YNCOKgwdf0Z133qHvfOchY9Dx eNRAjvBU9374QxaW6dixcaVTHdq5e5d6urpN/OxIZwzM9u71s0vfeP0N+so//KMGBwY0dWpKrYaf wmXdlRsNCPr6BvTww9/R7Oy8PvrRe/XUU89ocvKkikUyI6MKI+Cxp1279uhTn/qkxsePmXXjhz/4 IXNKLperqlRK+vCHP2KS5bJlK2ydbmBgSJkM60lxA914HPeBtEmiSGpDQyNqNAhg7Jm7gH8+I8eJ WHuFQsmknEjEdxL3PFR0uDUkVSj4qky2nEeKq1Rq6ukhMr2/FtZotN9a7CbynZsZbDEGCW7W4uPB +XD7WnqF9AjpEf5OXuUfF/978JzGmcHMA4TQUnnG913XBzNfy4O2L7loWYNxUAIQCna5V74RHMB4 vuLaw33GinSAZZyvKsMK8eArh9VqSslYUuViWXv37Nbk1DEtFKY0M3tCyZSjfftfVrYzrliioZ6+ pLJdUc3MHdPs/HF19ya07srlennnc9qy7WnVmyU5kZimZ3I6cPCQXtyyTcdPTmhi6pTmcnlVag3d eNMt8pyIGi1P2e4eXXnVBi0US8rlF3Tg0GG50ZipOaenZvT88y/qrjvfY9LKy9t3amxsmWZnfOll w/qrBeDddOMtBkzdXb3iQ/vVWkNDwyMaP3pchWJJOILPzs1reGRUkWhMkWhc1VpdrA/O5/IqliqK J5IaHVumUrmiQrGsVDqjzq4e9fUPoIS1duqNlpKptOKJ1Ol2aa/BDY4T9T8pIqjIjSiRTCvb1W1S ZiQWV8tzVKpUrS5z55o3bJue1aMuQaDDbUiH8DkIfwc/Sj7Ay7nXan/47kXktXwDtWBJ4o1b39WL ay9lifzRH/7RHwUWHn/8x/9JjmXiJBunp49+9GPauHGdiqWqHDnKpNJasWyZrcOUiyUVigXt2bNL l61dLddx1dXVqeXLl2lyckLz83O65ppNymY7tHr1KqXTSR09esTWXvL5eYs7mOlIWxQOVJtYJY6M LjFfsWK5pFOnZnR4/Ig2XbNJxXJBff29tk63dNmYloz5KVUIbcL6Tm9vn+KJmF373e9+x9SMV111 pUlKV155hYXT2nTN1baGRJ9YQfb392nJ6Iiy2U5F4zFNnDxpkuA1mzbp1OyM1hK2KjevOLm8Wk1b Z0umU7YuV65WzICk3mzYXWl6LTtfa/hpcZyIH7U/lUmbUzj1WLvLZDvkOo4WigW7rtHClL5pxi75 fM7UrLxAzM7NKRaLmMGKva3YmhUvOqxdLd7K6M4zweFwG9IhfA7C38GPig/46kWkqUCisqfP/xE6 pFjxzDgvEsF4DDsCfwsPszX5Gn7E84pEXXlOlFSZ6sh2aXz8qB584OuS15KDQCVPH/7gBxVPxpXJ dCiTzSqVyVobBL6nV4rTrHue2SrAEN2YRfbwHF/V+Ldf/nv9zM98xIIMR10JI450MubnHGs1VW9U lcpgBFFUX2+fJiYnTC9KmhMcjYmFiK4UIwRUaKwbEUUklcIRuGXqSzOxn5xWd2eXSpWycGXD6rBe q5rZPKAJWKSTKbXUVLVcEfEU2fqquqIZR9A+a0+0x/oTa05YVKL2xPABfS1rWKhCWZMKjB2Qqnr6 ++RgVRmLqlauKJ3tUCGXVyQeU71StePNWl2JdEpeoykGyfGG11LMjSiZSWt+ZlZONGLXr1i5SseO jiuaiKtVbyiWTCgeiZqBS6NaU1Oe7ac6MqJdUxc3W9Ye46hD20pV/UODKuYX7DoXycuRXr9FCj/T 8dfXC/dDOoXPyRt/P+Hv4sJ/FwYgtuQBmAWQ4gNL8LfZ9I3P/DUz3wXIUcQMAxFqjhzZbzknW05S 1aY0PLJMTzz5tH7+vk8T51CO6oqoqS98/vPKdGU0MDisgZElZ4zNGDVQff1YQFUrLdXrRINwhKV5 CrPGltSAAaulTDqrUrGkarWlY8emhYHE8NCIfu1Xf0NHjx5XX++w+ZmlU13KdvSaOEr9dAorw6o6 s72aPjVv6j/AqNGoK5JMGvAUSwVlMAGPx5SOx239CYJgSt/RbJrUhpi6ds1a8wcDyDDwIIUKgYGJ 8IE7AOtaQQR7DFGCkE1Y+uGbdvWma3VyatKctTHkwGkbIK426vLqNctrRgQT2sfiD2Ck0Fc2Hjdw NOvFmJ9Ys5nJ6NTsKQOkznaoL9YQI6mYFubnbW4ALFFS0B/39/faOLAABWTxbSMCypFjR5UrLJj1 JPfItMpn2DbRK72qWQ40zOHWqHJa4x7SI6RH+Du5xHzCNckJsr4eQIJjLTVbdbkttg05Td8VCNiD Z/oGIO0H8xJsXmuabw3CNtt6K1v98TR7KqfpiWmlUgmNLsEgIqX9e3ebEcXKVVdqZmZOW7dsV29f t7a8tE0f+Kn3aSFf1JOPPWcWhkhJRKmHiXdm+vXlL/2TGVe867Zb9ejjPzQnaawIZ2dndPPNN2r7 y1u1sJCzCO4rViwzKQsfNcJXoVZ8//vfr83PvGhqw3rF04Pf+KbFJsTXjTBZzzz5nEX0yM8V5Xmu crMFPfv0CyrkygZGgAgO1CdPTOvxx/+bmeETmZ5oIIzxj/7gP+pP/uS/6J/+6asGLhEv5qdjaUU1 efyYhcwiEwARRPCpA+gIxovfBI7XRDwBnLBkxMSfOJI4fEcVV1RRVQo1Pf34ZgPEa669Ws8+/byO j5+0MRGlntQvuA48tf0ZfeADHzjnbUZfHZaQAiEFQgr8qCnQdDyzpkcV+KqBRtvAxiwcm2q2mlbH DNkiTTXqqA49NaoIReQXO79hx5udl4FZoGPl/Z/vvsjod4K0gOoNiaGrM63hwR4Ds5lTJ/Xcs0/q sUef0qarb1AiFtFgX79qlZK++o9fMYZcKvn5zghp1dvVqXq1aCrH9VeuU39vt3q7u1SvNtTXPaji QknTk9MaHhzR909+zyz+xpaMmvUiQLZs6VJdvXGjjaOwsKDtW7eZteSX/+Zv9bu//duWqmTH9u0G agf27VNnR4dJPvhNrVqxQj/4/vfleJ62vPiiWVAuGxtr+0s1bP3rwx/6kGWBBiiHBgdVLBT11JNP mpRGf3zMtLRW0+5duwzIqIdD99KxMVOpHti/39baCH58+dq1Br5XXnGFn9WaMFaOY+rWgMLvf9/7 zMBmeHDIrDOx2Nz58g6lEkm95653a9uWreZUfq6bGY2c4X3kXBeE50IKhBQIKXBJKOAYUPmrVm1Q Mmt4QMQXiFw1FItQz1OUXC7NiBzFFHNTijm4EV26l/GoCYhnkRLpJhGVXnnlkAoLOVVKOTnrL5Oc qFatHNHXHzim3FxN/XffrqGhjB555FvKZh3ddtt71NnVYeGirrv+ct1+OxaDp8wIpF4v6fDhl82f a3CwQ3PTU3rpxeeVzWY0NTmhrVueVywq5XIz2r3rZXV1peQ6LVUrRW156XkdHT+utWvWaMP6K01K uvXm6/Stf/m6STI333St5fK6ZtNVeubpxyziCJINwYKzHQkdPrRP1127QXfecYvV+6//9c/00Y/9 jAYHxvTNb3xVgwM9yudmdHT8oF45sEc33XitSXqV8oKiEU+pZFTlUl5Lx4b1wQ++3wxLDh/ar+3b XrRzhw7u09Tk1ZqeOqFnNz+p4aE+NRsVFRbm1GpWzZikM+s7OnP8yOEDBtqVsr+e+Cf/5T/a+t8H f/oebd/2ghJxRy6mr2ctWBH5asazVglPhBQIKRBS4G2gQKBm9AI1o0lZgWRWlxxSZ2Ek1/Rzjnl1 OV7MjAlN799y5F5Cycxp1DzPxV8NI30n0vZdA8ZcffnLf697f/pjmpk+pVazrqhLWKqEGvWcarW8 5nOnzAyTCCBEzUDVRnLHRCJm60DJpJ+IM57wc5vlcn6+L4IEI+UsX7Fa4+NE1RjS9PSEqrWyliwZ RAg1y8expcNmoYjjMuXgwYPK5wvWx7GjJ8yaZenoiKYnp9pWjb0W/Ji1MtSRBDZGnUh8SNpYtmyZ qT1R/2EccvQ461Nj6u3vN/+zVatWKJdbMP+0yy67XM1mXZOT0xoc7Nfg4LDK5aL173lNrVixSgcP HmhHPiEB6YCOHz+qri6yTE+Ze8DKlcvNz61aLWvNmrWan58V63zQ5bnnXrD2UDMyryDRJ2pS1vVw hcBwBiOac5bTD0P7IXqNHxoq4/C4v+IY0iGkQ/h7uJT8wLWV/JZJZ367vqO0WTk6NcnBWruuWDyC LYcibkr1akyOl1ZHekC5hbwOnzioSALjuIs3AHktmGGWbyEF+RPVl//273TfJz9mgy0W6kommook kBRyKuZOKNMV18zUMfUNjshrlE2td+LkcVt3IvwSzsGsfXlqGmPGPBOTTEIhcb67Z1S1SkPxRLot bdZVr5MHrSE3wmJh3a7FWINPKkmsRD8MU+Cj0KhVVatXrH0sFDG2YJtIECLKTyKJUQfrZPTNefwe MPagPYxKGA86XaTDWo2ULU2z3AR06KdWI6cY0e4Juhw1s3mcAWdnkTZZL+swkOvs6tbc7Iy1Mz+f V/9An+Zm583JGidonKu56ZiqJpNpAzNAF/pgacmCKHRhrIDt0NBy5fNTZ8ey00BGlZBZh8w6ZNbh 7+BHzAdOR//wnaRtDcyigiCZAWY1A7NGXYpGMqpXEnK8DnWkh5TL1fXK+IQi8cwlATNyTp+52OJZ VAyCD3rPfG5WqVRVcuY1N39Ux46d1Pz8CUWjqwwkRkZHNDBQ18LCPgMLQKRvoF/VCqbyJU1PT6nR iGk+N6vJiWmtXr1GrpNWhcjwrtTRSQLKmtyoJ7fZ0tTMSSViMbnRiBzPUbkWUybVIfzQErGkASWo H41F5UTiyhf8RJZzOcz2/UzWrJlhTAHAYbKfSCYMLBwyKxeqSibSmsudUk9nl3ILDSVjcTPFL8+d kuek1ZFKK1+bF5peTOkb9YZKlYbyc/MaHBmW15hQqRJRo15SpdqhWLSmYtlTtiOuXP6wqUgbraTK pYK5AGCqPzE9pcFov2JJTxPHT6irt0flmboq9ZqNA1P+WDSniakD1v9ZTaoB15YbmuafwWUhNLm+ cJPrsz5vIZ3f4BrzP/Rz5vLy1H6BIuKHGV/g1kWIKiSzphy3KrnwZ9bQOiSHLB6dPtDZihkv+Jkz Y9BbPHoW6wHQ3RcZCY7+yoFjcj0iXRzXlVcOKtkRl+YKeuzxB0WA+tExz9bHUIth1v7ss89obGyJ YvGoJcJEHUdIqYVCzuI0so8F5NKlcf3f/9f/o7vuulMjw/0aW75E40cOaGRs0MBhaGTQQKDp4ZuW 0UKhpKiTlet4qtekRrOgjmSntV2ttVSpls2U3XHLJuUQNSMSbajZSqjlJeVGyorGUmauj5rT9zUj nxdJKSeEU/SpySkDl2aTqPr9KpdJ7eKYH1qpVJeaLXX39apemVazuaAKZve4D6STIiRW1HE1fWpa K5YuU6O8oEQUSZJo0UXNzx8x/7J0uqFyeVL5YkGDA71qOQXF3JYyWVwf5rSQr5jlqMwNgIekfVfP uOVehSWkQEiBkAI/Ygp44JcfKtBiKFpEh0AyxH2roZZXVcuLquW5cp2sPGXUanUZz241EwZul2rU PpiZdAbCLi6uXM+3ViEobn9fUoQBrFYX5EZKisfq6htIaSF3VD/84UPas3OXevp7VFqYUCYT00/+ xC36m7/7G81MHVK5Vla9Wta7br9VwwMZNZuDmjxxUKPDnbrqimW6fPWwiqW8vnT/n2touEdLR++2 UFj18rQ6O4hhWDZQqEcrSsSiSsYjqtc8JXpiqlRm5EQdRS0ZZlURp6hotKZEzBHSl1quGq2qvCbR 5gtyheqwqkQsrXjUUwxhsOlnXW5WSurKOlJ9Xr3dUUW9gppeVXGcyXmzaFXV9JomLmczniJOSV4M ww5PrUZFMbzVHVe9WZeAVnY9/aDG7EiTXJNgxBF1Z+jUU1d3p+qVgq3nAa6quxa4GHVjKjuoVr0s r0lwLL+ceUtf5zrvK16oEdYL6RQ+B+Hv4FLxAX9trKmW48ptRdRS1DCj5XhynZpaSGitirxITOKF HjWgheCLyWmS/gve9ca0U/6v9K3/jXqEHAncyhZdj/gc3HbWcHA+lkfA3bTiKVe1Uwvq7UnrwN6T +qn3v1dx17FcYxs3bNDm557R9x/+njZt2Kjnn3tOg8MDirpdWrNyleUsGx0Z0uBAn6rlqqoLdc1N l3T5unVqVL6jDVdcq850v4V+yp06qVrRk9OMqpSvSq2YGpXAgo+8XHVFI0nzQ4sS7b8VUzFfM8dq 9mMJR/VqTZFY1Mzd0wlXEcdVsrNTXrOl6YkZjQ6PqljI2xpbbiF3Ol1M3I1b/Ml4LKVaqWZ9ZJPd vuP0fFlOK6qIE1OCfpyYFkp+KppoPK5eIp1UqnIaUVULDQu22dmZUSoZU7NaVWGuaGuA+KfVaqwn diiezfKmoHg27fvPlT3NTbedphfdlzd89X0p3nA4PBBSIKRASIG3kwJYMTbdhoAkzO1dsWrFHkYh EbkOsY5c4adL1I+Il5G8rH3cVqfcFumjAmi9+JFGzeFtcYMYFTj+Ogz60HJVWrvuMqVSUqFwVLE4 ETBITtmjDRvfo+uuuUOJuKvevnW2NlWrVXX77UvV19ejUrmgq9bfbYYOGDgcO3ZUq1atVWV2Wrfc +nEtFCP6lc/9Z+3cuVszp2JaufrdWrniLj/48LF5ZTrXSa2Guns6LKyTF40YgDRcT6l4StOzOHIT 9Lhu/ljERIxHYyYFEXmXlDKJmGtrbGrEDdRKxTJmmxYeq6druebnKopH+1WteerpXa2TJyc1PLzc nLq7upbIcRGRyyJ7gOMmzVjDdSO2xkcwYhzCs9GskqmmrRs6blxepZ0VOhY1q02MOnJ5P7+Y66YV iw0qkXRVKrNAinc8Mct8g5Agmj4GIsPDKy16/mm9dKCfPr29+Afg334Ll+7H8G+fFuEMQgr86Cjg wYfaCXs9UrUQZJjuTf2IVIYxXU1q+YZ0AJnHmhlbt8/CArY8wNCsDtsDD1LKtLfB0oq1e+7fepSG GvWmWeiZJUqLCzzW7FT3aqaGi6WiBne9qTE5AsyqGh0bsa1UsvqDCdaj4paXps+cCKLKdFM3pni6 bpmhV619j+TV1N3XUCSCqq1lgSjXX3eT+SKs3vAZNetFRWIpJdIFVes1nZqa1tSBaV294V2KJTq0 kDuldEdWbiSloVFUo+hsIaShjQWnlBNXs1ZUJZ9XLJnU4HCPKsV5JTPdisfyiqc62m8ETaU7mwa2 6RSLkFENr6haIOLh5XeaoQjHYtkzPyCDne07J6THuqkoXTduFjxegrU2KjC+iCL1kmIxMlFXzJoy kcj6ak9TjybleXUlu6G9q0wf+uakmq2iUm5Gnspy2uI49fw8mTwgfpJO1yXWpe++gJO740RVKOTU 0dFt7aEaTiRSpqfmvBS3+twDrEex7ozH01YXFSyFFDZYXyKJS3ULNcb3Vqti65GxWMaupb1IJGHj J5yZ3QubM0+h7+JRr/vJQOkHlStzp5TLOQvhhUUnoA6Q48aAmjWdZuwtVatFGztSOP3wbPrtXZpF YxtI+CekQEiBS0ABfv9BCZatglxl7AeSGDgRVTU3o0YjbzzbizTlxjDmcxSJtqSYp5gbV6OEdbvP F1+7pb12Qs824NmamYVitAMYffg6RzYkXgu0WP7QoopgteJgXgmv8hf5SOVSq6pIbEcAACAASURB VDcUjaUt4vvU9IS6OnvUke3Wrp17tPbyNUIK2r13p4aHlli4KsTOO26/XdV6VadmpjS2ZLn2v7LH zOUHh/p04kRdPb2DUqRLjzz6nJaveI8ObN2nW266TYfHXzGVJ/5rwwNLtfPl7ert7TcjDDJer1w5 ZA7T//zPj+lnf/Y+lQueSiWyNLuan6+rWi1oZGTUoo6WqmX1DSw14jbU0OTUpB559JCWLWtaCKrO DkOs4A69YRusWDWdmlBNUprQJdpUS3ETumnXsYTMUbnxhoW0ol48LpVqvAzELexLwpg18OfXaQpL n4j9axFm2WuaSpPv9WZd8UjcoorQVsut2znrS47SHctYfjXXg0h8WPbm5OIE4PktRqRqk7XD1+qs 0XOTIQF1QSTqqe7xduUpFo3Z9whOiQ5ziwhVOKqGQqWsjiQvCDxeRLkmzjXvbS21CMYci6lYLSqV SCmR8B/4uldXKgXdX1sSCX/+POzU4R4Diswvopia8l+8aJtnB6tWv9AuT2m4DekQPgfvlN+BZwpG x4Ko4/lFjAfySsL/GyopEqvJjSTUIqI+FeAZ5J9s1QWXebW0Ae017kivnuXbWawZX1vp7HuuSD7Z 0ZFRLE1nnra8tEPjR48ok+5QqVw0pjg4uESP/XCzorGIXt62T/v279X6qzbo2PFJbdu6XXl80VrP ot3U1Rs3aevWR5WIJ7VQyOujH/m4ursGNTkxq6nJeT355GbVGzXt2rnbgld2W8qAI7r33o9oPlfU M89s1q21lpYuXab5XFnzuZL27durRqOpw4cPyVSEEVeXX17S2Nio5hfy6usfsagmraan7q4Bs5R0 nYS6OwaMIZ99/rKbFHEilhomno6p3qrL86JKRtPG0OuthqpV37+uGXFVrbQUTcZUbVRNKknHu6z5 RquictMHDtYoI3E//BWMvGFpxnEOiKhuET+wDEqIvJ1INIlowoCMhqoV34cvm84KET4ZTRkA1BoN q0edQrlgfm1Rk44jarQBy4DK9N+uPUgEVsbFgUcMnXi5VFE2k1KriftB2dTKQC1Bo/23Lpnjeyqe EBaoaCDwCwSQGW+w2Fuqlmzc0RQ6dke1Zs2AOQBCgBRde61aUyzpvyBgWOM7QfrbSrWkWBTpLFBR MMpAGgy3vlQc0iGkw4/5d2GPIEIS5vr82v07wl80SPjtwu8ovDSjlcH3l1QtJGD2z9jp8/65ODDz XCUTSC6u6rWmGk3yeTUEk4xG0pqaPKZPfuJTppLc/PQWjY4NqlaZ1dKxVRoaXKpyqaF8rqJly1fr icef0ror1qoz26/jx56xJJp79hxQpdxUxE3qinVXK58v6a/+8gv63d/7bX31K/+s666/Rqlkp268 4Vat33iDDr+yXzOnFvTKgXGNLlmlTLrbGN6B/Ue0bt2VKhXrGhkZ1IYNV1lU/0rN00D/EkUdX2XV anhq1FqqV12Viy3lF6rGsM9FxWj7RsD+pYSadc+ij8DcuRERp6UOU2v6rbCmxzkAiFJv1E3qScYS Jp1xzAcVXlJQx0ZVqpBpAHWf7DsuBdSp1qr2ADSciIIYjcm4f0ubLSnqJlQq+9cSwrFSrdiDksn0 GoggNTUBSo81QOQpgMKXtkAiM6JxX5XcYpEOOUoq6sbUnX1VYu1I950GFfwCeR6iTsJwhjFG4gnF sdZUxHLgJRIdiiVip+fOc65IQhUba+I0PGWSvtRVLBXtgU+nXj3XrGOxmrCXJRt0KJGFkmkomb/j NBP2Hm4g5rs02769dAJwvmEIYAYb9T98fysQ5v/6+XtxYMYKWhX1YodiMVexeErNhqvCQlU33XCH 7rrrbvV099nb+k++96c0fvSwNm28SbxVHz40rmVLVyvqZnTs+Lj+99/7Q/3rD76nmVN5/fIv/bqe efpZfeJnPq1kIqu77nyvioWaVq28XL/+ud/SunUb9bu/8/uam58xoBgdHZEaAGtWd9x+twYG+tTZ Pai73/M+S0Nz36c+a1moP/TBj2lgYMjWZdZdea0FDM43q0om8etC4jC9ma5Yt8mi3ndmBwwsXiXX G7+1PM9f9zHzz4Ql6SQbN+uPSDb43rkxP2qJRftoOSqXUZXF7DqkrVrNF6dbmKqyBoX+kZvTVjvi UO55cbvJ9r0VMUdEW2htkRg0opbjG52k2qCHwzpZDlJJ1p7aD4fnKYIeuh6xseFMDtgRLYVQZrwZ 8VaEtBeJxJWwdTRf+iMCi+uw7hYzJ/oI+kDJ1LmED6M/pLh4PGVtmHQZQZqk77j/ZiZA1wdPAL3Z QH2ZMCBuGs1oM2FvZ9AqKNGI/9ZG3/6an5RK4p7RMF/BUK0WqtXeKWq1cBy8EL/6PPq/fxO7fMWJ qRn5ZcPUgB//BToANH739tuHd6CNqbKU9ebKRYKZlMl0qllvqVDIW8qTa6+9Xp53nZavWKbcfN4G SwSRvv5+C+Fk2aXVpUoZRpTW0qXLDWCA5VvfdWd71BFdc811SqZ8hrl69dr2cVfXXjdq/XV2dmvF ypU+gVinqjU00D+iwYEl5qsFo1+z5gqjVbqjS7fcfKviyYRI9tnTPaBaqaqVKy9TtA008VhE8Vhc jZh0zaYblM2mzJctFjv3W0K5jEM3QJq0+GOBBIWKLZOG+ZqoYyCPSpg+yuRKa0XF8pMb8WU66gUv JNCL5KWsL8HkE3GfDuZb1/6OxJpMJlSpNMXYKalkyuhRLBLZBClKKhVrymQCcCRXnEnwahJay9Np ia9WRR+AIYgt7lm/7UTaFpYsGAPjaTVdk5iTyYhJxrTTkfHXzPgecaMG0IANIcE4BuB6LRmdGCtO 79AMaTmdBuzbY/E45wVaS5tX0Dc7vCgQGiyRiFo/dneIKWol3IZ0gALhc/BOeQ58SYzRePYyHvA4 jmBkhkEYVuhN1tMihA6s2QeGQFjBc3Nff5bBXx8Wg70L2NaqdUt7nc122npUf/+gsll/HejIkaMW aLcjmzFGD5CVilXl5guKRtsMNhax6B4wqVQ6aZ9atWlABjPN57BmkYqFijq7smqgxou6ymSyqpSJ /4V7VkNESyZgpRuPKNPZqVyuoPn8ghoNT+Pjx3Vqbt6ALZVNq+FJNQOLmDF31tMItoGqlgKQUTh+ vpJKxU6D0Ozs/OnqtRoSm787P18UoDg+fsKYNtcE5+oGXNxo5oH1nmxMvJVwDgGFyCMwe9oolRhr SwCJRSRpv9ksLGAsQt2m9u3bb228/PIufe97/2rHT5yY0Z49e+08QNvdnREPWrnsS4XxOLEr/QFz fn6+YFFa9uzZb4BJI8VizZK1MrZt2162dhlHPu9bUgb9MxeAOJkkwLS0bdsuLSwUVS5XTveHNhIg PnFiwtbW6I9Sq/HBctGfO1IrLww7dx6w87TXamcKOP3D8HHYQBPgDD8hDcJn4J3xDBgYIY3BqN/w 23Tb2py4aaqQyC5UxQhzuGjJjGDCFKQMDAQOHTqo5557TitWrLBo8D/4wfd13XXXac2aNdqxY4dF vCcRJoksP/OZz1gYLIL/vutd79KLL75obd1+++3tt6uW/uEf/s7UTvfdd58mJ/J69NFH9clPfkLP PbfZ0sjcc8892rlzp2VnJmo/maCJOv/ii89r165d+tVf/VVt3fqSDh8+rFtuuUU33HC9YnFfJUpn MO5EIm7Mn30YJ+tUhUJF2WxgKWfDOuMfmGvwNvH8889bnjPUdDiZk7yTxJwTExMiW3WQePOOO+6w TNOo9Egoyg0kGzbzRy35nve8RytWjBnAnTgxbfQkG8Hg4KCeeuop27IPnaEr8Sc3b94s6EaS0+3b t1u7999/v2699Vbt33/Y6HzNNdeYpdCDD37L8r6RMPSJJx7T+vXrtWTJgM1vYmLGsgygNoSeDz74 oLVLslEi+ZOUlKwDjz76iC67bLXR+/HHH7fkq2QLP3nypG666SZTB7K2x7195JFHLPccdCFjArRY vny5vv71r2tkZMTcFbhu5cqVNhfUnZzPZtMGirt27ddDDz2k5cs/p44OpFQc5n2ws0G/lde3M97F 8GBIgZACbxsF+H2+7mMvok7L+Al+v3WvpbpaxnMIJoGpN4sULRyd32Q5r2T22jH4XIP1E0CjVqvK jTpqmDVbU6lMXP/4lS/rE5/8qN599x1qtqq64cZrtP3ll/Qv3/qGsp0p/eCRh7Vi5ZiOjL+iXH5G e/bu0E/99D22ffh7D+npZx5XtVaUHyqloSWjgxpZMqDu3qwOvLJHW7e9oL/8q/+u2bkpq7d3304N DvUqkYzYp6+/S9G4o+uuv1q9fZ2q1UsqlnL66Q++T/sP7Fa9UbG2q9WSbTHAwOqvaTajMj+HmdlZ ZTuTqtbqqpi3tFQqV17zPbg5jWZVmY64vvvwQ0okoxodG9bzL2xWtjOtrz3wFW3b/pJWrlqmg4f2 2/nrrt+k/Qf26Atf/Eu98OKzNp7f+d3/VZmOpJaMDmnt5auFa8LuPXv0j1/5J1WqRc3Nn9L2l7do 1+6XVSjmdPjIK0aDbz30oB7+3rf1rz94WOuuuEzLlo9a/xOTxzU8MmDtXXPtRq25bIUBeK1e1pat L1ifV29ar3jC0ciSQQ0M9tpLE3OCPszl1ttuFnMbWzoijEf++kv325x+8Mj31N2TtXql8oL1f9X6 dTZm5sRYTs1MKp1JWPvQhLmRBWHrthe1avVy7d23S9/45td08y032PEv/c0XtPnZp2yuD337n/X1 b3zV+uIFCSOVNZet1NBwv5KpmMoVYr1xHOuoYDkQ6TL8hDQIn4F32jPg4N6FupDQVrjtuGQFaVn0 poGBHrHe3tvba1te1rEl4EUaKYNoSW+lRP7P/+OP/og3YdZu/viP/5PPHbAuiUR07733asOGK609 H8Zkfk2OS9bQiKLRiOr1qgUUXljIq1GvmpSBVDQ7O2P+BKOjo5YShUZwiB0eHlJ/f68hcE9Pl/bu 3avx8cP2Vn7o0Cu67bZbtXTpqCWyxN+gWq2YZNXb06MtW15UobCgTZs2WooU6iMxFIsL1m93d6fN g/BUW7du1VNPPWGSS61W0YsvvqBbbrlJzz33rK0XjYwM64EHvqbL112uOGbwLhJW1fKo+YGRmzp2 bFyvvLLfXA8efvg7wtCk0ajr29/+lpYuHbP65G4rlYp2/fT0pG25eZVKyZyOh4YGbD7MhQ9rSB0d aRsz7fX2dpvDOlvqvvDCc1q7do21g9UlAYxplzVJMncznuHhQV155TrNzExr48b1FtT58OGDGhkZ sizgU1MTRiPq3n33u61f6kJ3jEKOHDlk7XZ3d1lQaPKukZbGJSRZPKqTJ49bRgIcldesWWXX4UDN WNguW0aW7qauv/5a0S/j4hzPApFfOE8/sZifLofj7HP/yQ0HDTg2MXHC5s8+9477TltI+7QRibjK 5+ft+di2bYvVJd0ONGe83AvXDG98Van/Q+ZJC/d9JhDSIaTDO+D3YClhePdEz+iPx7xQW001Gy05 rutbVUd8A7hdu3fpXx580AANf2aCZX34gx+ycIlohTLZDqUyGVNRxsio0m7VaTU8D9t+fMAcl8V/ 30bSicX1xS9+UZ/85MdN3YXxAs5uvoFle3GpPbhms6ZSsaJspx9ZY8+enVoyMmZrXAyWNS4W/yen TmpwYNisGb2WI9bQTk3PqN6o2vGTE8eVTnUo04FzLaboLbEm12jWlIinLDwWW6whn35qs/bs3aVf /pVfM4aHQUgqiQoKYbOlQpGUM5NmYBKNuBo/ekzLlo5pYnLKGG9ntlv7D+w3dSi+ZwA65u2FYsFS xaD+Q1VI3jMMEE5OnNTIMFFPpGPHj5l6DPUg/k+1es0MOw4eOmjqvUw6o9m5WSEuI8FmO7JqNBvW HhaOo0tGrT2sCWmDOtTFOGTvvr2mnrQXDNc1Aw3ape6RI0dM1XfXXXeZOhJVLS8LBCkmwSeqOfqe IsXMwKDyC3mrx3n6oGAkMn503N6EGNfE5ISGh4bNTJ4Epp3ZTuXyOVN7ovbjLQl1Ic+Izdd1jR5z 83Pq6e6xeR07RpLTJVYHdSlzgW5msUloNFwAmk2LOYmBDPuoHycnJ22uqFvJ30YbqCLps7u7u20J KZsHqmkSmPb39ds8/D+v/jiC+x5u/ec/pENIB/+l7sdPB0I18Dz6YOaPB01Yvd5QrdyUE4mqhtFE LKJINKqvPvA1/dLP/wJqIlPQAVdf+PxfKtOZ1cDgoAaWDKt3cMCWO1IJkn363OC8YPapT/lgBm7x Nh5zCJfkG0Y0Gxh/RFWvkYAtblua5XuzQZqTsjqyWS3k88p2dqpWrRq6UqdRr9tak5mus9qPNYLj 2HW02Wo2bd0FJswHROZ4pVw2hsc6FccTqaQx2a7OLvPTAoBgpjBwgAYQwZyb7zB3mDXHWFsaGhyy 74wHJgqY2HfPj37P92bLd+ID0GZmZ2wcWOEtFBaMYQM6AaOnDc6huoRBm3UhRg1tsKO9+Xa2bcZP 3TOVwPcMs3kAhHZog/ZZJKW/4Fp8x4LvtEXkDRZbAWUsDIM5c44x44IQ+KS9vm6wv3hM0Cqov/g4 3/Ehgy6M11wK3Mhp37GgLn1y76ATvnH0wX1bPGbqMg9KcLxc8ZO9AqSnzXvbjS6+p+1D4SakQEiB dygF+M1TFv+O4auXGsyAyXMWk8jA1bYsB1OiVCsVzc/PKzfPW/yMDTVmZuOOqpWqpqdPqSPbKa+N wEwFK7XZmVkdO3pMlUrV92+KRJXP5S248ckTJ22C5VJZu3fvsWMJGDnWbdGY1YtGY0pnOvTd7z4s fKq6u3qUTuP07Jipdk9Pr+KxhO83Zb5avrSZywNkWFk6ikZiGhoctu9YxrHPNZwjUWixWDLyN1st 6zsWi6tWr6uvt1/JBMBSV7aj0/rjWqKVYOHHOdrgE2/Tgu8YlATHGS8+XUHdKuZ7clQqE8y4JvzW YtG4bYkXmUoSSQSTfowpynaOa+fJYmB+fq9ezz7RM2grk+kQ44deQfscY77Msd5otK01HbsXwbWc 4zr2gz4YE/UZX35hwQI4c57P7NycjYmxcW1wPGgDOkEbzPU5x/iCubNfrgBijh2DzvTDfPlOPZ4T 6gQ/B5tTJGbPCXWD/sKtfz9COoR0+DfzDJwjNNU5QeksJ9+yNaNJIi0/Qvzs7JzS6Q7LGp1Jd6mz q0v79u4xizssGLdv22WqNRb5du/ebdIS1ndf+9rXtGnTJn32s5/V/ff/v6aOYvEPVdnAwICpnzAy oU2u3fzMC3rf+96nzs4+k9xwtsNP7cknNusDP/1TJhEW2067Fh0jQpDcRpuRc2vJr4PUFTUARoVF Ya0NSYXikbvN8SzzdDIBM4cBIxUBlC1Vyr4qkeNYD0ayMVN3xmNJU4OyRT2HGtR8q9rqznqdbKuw YlcTkycsNmWtXlE0AuMmw3bMpBXUq4vVAqhtE8mYORWT2YB2ent6zfqyWFpQd1evaIcYmKhdF1/P nHDGZs3LHLhpuckLiSvGGfSD4Qvj8lV3rsqVos2X9iKJmEm4qINZT3UtggcZiYJoIwQYBpT9yCQd GUDLnyftVyv4jxFAWCoUF5Tt6BLjph7noTfzJ3IMiUszaQIvl+065g0dUUcG9Kc++gTmgeO40c1e rHgfO+87md3j8E9IgZACPwYKtAUgW68KuregvwG/CA5e3Pa8XKBW99+Jg25Qe6HuYu1nYWFBhw4e sWjnANlCvqCpKdZMOrVq1RodO3ZCN954s5599nnlcgt63/s+oEajpZtuukX33vtRi+tI+hcYFTEe 3/Wu2yzs1IYNV2vt2nUWDLiru1urV19mfkpE90fKwRkbPzOAlML6DADFFgZLHzC4Ws3PJcaYWXMi CDFjo+D3RBvEBqNupUIEesc+7DebqMPwPnftGH3RHvtENSHmIIyYSPgwXPZh7ER+p07w4TzAxb7P yF3bp1/XIUVMXLn5hdM0YAwAAOPkPGMggzXtcI5x+oCEB73fT63qj6tUqphfH4DDd+r583WNVsVi 2e4Dc2M8ROCgbdplv1H36cY8AE+L0EGYrXZ9xsL3oD7z8mMv+vQK5syW8VofTU+sT+IgyfxN6GvT lP5Y6wS4qMt4u7t7jZ52X4L51Rp2PXUC+kC3oA+7oeGfkAIhBd6hFAik5cXDC3jk4mMX9/38YAYg wOOs4FnvJ2KDKcHcABAs0woLC2YAcuON15vlGtZn99zzXu3Zs0uf+MTH9d733q3+/n4NDw+bTxL+ UqyXfeITP2tgtWnTtRocHDYAu/76G40pHzhwUDhQ79ixy5gyRir1up8qZH4+r/HxY5qfK/gqKCJH 4PNVJVI7qkTXxo1iC9adz5VMcuS4wbPX3rZ9C5HoeHNgPafe9Nf74PEAN8cBRNYCKY22uBOJxa1+ rdE0oIsnUrZ2NDuPClAqY9Zv9QEAKdMG0ga51rDiMfWjlExnrH3OQ1PPguriuxczhp1MZZTPFzSX y/vrdO3zsTipYzxbj+TFgvVD1qeKxDjkvuB1buOo2LiIgIIPnttOuQIQ2ZpUO4IGwAfgARiAlg8W OI/7DwAAh9THlmPU4foaEU0IhdWCDjU125HyW+31MegNXdkiMVOfNbZEO/RWpO1Ab86KRAdpEu2/ JehECehE8GFCZpUwzzeJr2yOmP799H0y6eRHtW8d0dlFfn5U4w378e9VSId3Ah1woj4v/Njv/83+ cbyW52HAQYZkt23N6KBSciO6/6++qPvu+7jPUNotElqPAtZKTTW8qpmmA0zGGH1WYmf506qTL6ys DI5wTkTlQsnMKvneqtdNGogTtsqTZqZn1TfYS7O+PQhCE9E6KnU/zJIrNWq+5aUJPw6A0VA86edb 8+UKItlLUTJ0M04iyzuW7eXMWxKlOC25HglJ3+pWclvRM7eLL9S5+n2T55lHMK8zbR2Lb++nXQmi zr/ZLffHI87jRRTHJVHDhfXPfBzSrV8COqHJvZB2mP2FXGeaY+jGJC6i2AvTj3H+F0q38LoLf24u 9Hn7t3gdvy+zZQQ3XPtvPxncRImwVFjImetWpVFXvlxUX/+g/vbvvqxf+ey/M94P/zZrxv9+v2/N ODSogZFh9Q5hzZjSYmvG162Z8ct8LXML4r364CUFYGaY5ZAKO6Kurs529HI/fxVrOUFoEhbpM50d 5hPE2g/hpCYnMPRomll21HNVLvj1AbJ6BZWSo2gCC0epXKxYiKsTx09qydIRO96qEyrK0exMTj39 XVooAagl9ff3aC5fVFdnRmjMWFsJCAj62nvA67cCCJG+OE+AxLe4bd+gs7b/+v7e4n7AK8+2JTtZ IH2iXuSZebNbm+lFvxxdeP8Yg5z3/rxFer3V++DT63QavyCd35vaQrq2kHzBcGYaXq5+m+cZtm+P WkjnH/FzZrJP8KK56N3PF8pwovYjKLnRiK3Rw03Q8hCSCSvqZsm3cj7rD8x+QNbLecJZOS0F4QkD W35by3NaZttP8s5601M0EbWEk81WXRMTU+Zwi4+ReXZ3d5vscOLkpMbHj+rGG2/UqdkZPfbYY/q1 X/117T2wz3yMCM+0d+teW/u64sp1eubpzSL8EvnBHn34UVNPfff70zbRn/u5n9PWl142v6rdu/da iCRCKA319+jE0XEtZLPm1ExuL9RS5y8XzdHP38UF1jA15zmu9aPIX/j4/cfgHB2c49Sr1154/+do /h1/iheM4CXvQgcbrI1f6PXhdSEF3skUgH+d5mGWlZ51b6mJVo4ciyxT1LBXkNyEH+ScpZJ4Mqna QuEt/b5eJ5m9kSmRfoMS/Gj9XerxUyYbcdISRlYxcY/GNDtf0JEj4yaZrbsirq5uP9fVsy9uscgS 6zds0Gw+Z+s2Jycn9PyLz1neLOIakroFQ4GHHvoXWyN66aUXzHCBSCEEpCVKBAYlf/3XX9DGjZv0 O7/zv+k//MZvmvP0u++6yxyVv/3QQ0qk4vqN//C/KBLFXN8EPBs/zJd5vGbLGotvKHdh29e3d4n3 sUD0yMyKccrrt77geWHjDpAouLGvIcpbm8Q7mX5vuN9vbWpvfF4WXX+pmMhFkP6c4wvbPcPvfdH9 C+nz9tMH/mUrGWYVjQ7J57cxlrK8pvbu3q8du3aKIB0brt2ksaVLzY8WoHtTBSmLG9nmhf6mfeDV BgCrQLn16lH/GB2hCWW1BFULRhaYWnsqV2oqFKvKL5DluWjqvpn5eQ2PjGpuPq8Tk1O6av1G9fQP qFIHkZuKxYnA0dTY0iW6/fZb1dPbZWGNLl93mYmhhWLewihhOr5589NKpRPavn2rkqm4YhFXQwP9 qpSKOnhgv2amp1RcyKtSKiuKcxxGBChoz7hF/m1P82K2Z23/bP2++eMeqRDIQH2mLYYoFzXu9twZ P69Gb3VrQRLf2fQ7831/8/Q/1/U8s6hELnZ79ufz0owzbD+k47me47fz+WiRHxEDsWZDrWbdBx6P LNIcI/tH0rJzEDkIiQxJjYDlrUpF7mKtmoXEajM7vp8Bm9oGICTYJL+W72DrG4A4uv/+v9JnPvMp QzLfJrDRXpXB3whbNSwC8ZPy5TXw8PjxCfMtY80MiQq/MTBl3/59KlcrunLdFarWKyoVi2ZZ98zj T+qZp5+2CPpYOuLDRe6zbVu3WqgpRFTCJRFdnS1WekGoKc6hZiMiBmpNCEOEeiz26DfZ9iFbDMWv +R5Y07wByF9T6+w7gVRjxD17tbftzKUa/xkejDc35rYk/2+Vfm9ukmGtkAIhBS41BbB+rrcsn+Rx gmV4LS0ZGzUR6W///sv65V/8n/0wVaQYe5PhrNpqxjeqFwPZzY/kAHghjfH2jrFEwzd4R/UlfL9I f+23MbakXwN9XeYgbQ62DtmIc1q5bKViiZjVItRUvVxTKpYy0Pm5z37WACieSJwGoKs3bfKzGBNR uRdn4Zb6BwYsDBW+Z5iXW2gmc+aV5ufm1N3TY3WQMvCDIyTWOYstWDDuUfsSOQAAFxNJREFUAJXO WfsMJ+Hi0IM3hben+GtiZ2nbQmkxhjPdv7Nc85rDLUVsMfRCx++paQuwF96/OVq/jfR7zXTPsGOL zWc4/qYPOah/33Tt11SE9Bd46WvaCXdCCrxTKQD/CtbMjJe1kxByDCEEV6DhoRFVW00t4Ae7kDdf 3XQmo9J87o2/j9NS2Ruls9etmb2OJE7L8nFJgBdMu6kIYKYgA2hLiagfsh8nVgL24nA7M7fQTqDo CodeHI6r9ZqJkPhDIV0xsQP79lsUdYAHiQxfJIAOU36cnFkYPHHihDlnI5lRByKQ+womhHFHpC2Z EZyWaCFcOzU1ZcYhRBHhc84SSDfnrHSOk28zI4Ye5yo4bl9M8cHswlvwwezCr/ejo1z49Rd75cWA Ga8RWN5eKJgx9tMm/hc7kfD6kALvQArAvxaDGRo7fnPw5SBIQyKZVrlRUyyVNH0flunwcTcWk9f0 fXX9qZ37pTtaWCAYsB/SiVD8FoewVrO4ikQxX750qXbs2q5yqaCe3k4N9vZYFmAW8A4e2KXZ6RPa uP4qi3T+/DNbdNVVG+W1XKWTnYpGElKKUP1JHT2WU5poGdGkIi1XnV3dqldrJrVlsxkDIkAKC0gQ G90poMQWAgBkqBIhTAB6HE/E4zZxggtzDlUjCSRJLMk1HIc4gSoSIOV6AhL7bfupuiEu10BE2gVM AVLGc+5yoVLJuVsNzjJuCuPjBQDAZpzolRkfvhbMlwVTIs8zv7m5OaMDtIBmQfT/IAgzEm3QbrPm 05oHjPOocHlJOHTokEnLvCRAQ9pHp017BGmmPsdn5mdMumY8MPbAehQ6Uod9XkqI0MIceJmBpujI CWFGBBLqQG/6Z+zUJe4nc+Uecj8YM8dQRVMPWnCMtmkTh3zapy7jgyaonGmX+8yzwZjoi61pB9r1 qcP86It2aJ+2ecmChtRnXNCG47RPBP/xo0dtjPnCgrUL7bmWa3jGoBVjok++M076ZYz0xZiILxqW kAL/f6UAPIHCb4jfBb8veAq8iuUgx4mp0WypQmD2VFq1Rs1+Zxbur1xcJJktBrK2Nux1gkQUIMOO gESUMB8i21P4MRJf74WXyNJ8UIm4qz17dmvT+qu0fMWo5uem9b3vPqzZqcOamTisVCqriYljGhsd 1cjwmMZWrdHRA4fNEXr9+o3q6xuwYMGtBsF7a0pmk5ZAkujJtRq+BK4xqn37DlhMQfbJgEyUCXwR sHIk0gjHYzE/5h+5tWZm5jTc3a1YJK6m19CpqRktX7FCUTemiclJzZ6aszW622+9Q0ePj1tMw0ar rhUrVqtaK5vTXl8/FpeyCPqtRtN/0255Gh0btYj/Z7fWc+S0I4nY1lwWsD7EdeHSbFOJNP7lqlcb No9ELKloPGIxG1kTJE3Ls88/q3QypbXrLrftipUrLBD09MwppRJJDY0MqVquaGR0xCxHoyTAM8Ya E9FF9u3dq0Q0oWgirkceeVSrLlulzkyn+ocGlUymNbRkSFMnp7T/4H6NDo8q292lkcERFcoFjS4f s0SZZOuOxKKKR2Oay82LMQTZAoiuT9yYI0fHRR451kTj8ZiOHj+uTKrDEpF2pLMqVYp63z0f0Ozc KZPwT06eUDKe0ujYmB5/9AndcuvNev7ZF3Tnu+8wR/qXtr6oy1avVbU2Y9EEUIkTQ3PZ8uXm0XrF lb12H+Zys8rN5bXuiiu0kCuYOER/9aYfGuzwkYP2lnjFlVfa80qmh76efqvXrLeUyaatfWJW4mGN upv2ALVlK1aqp69XPLf8fgiTBsinUhlLQURUFfK4cZxcbjyvy5ePiAg2S5YMq5Avmqr6Uj0vYTuX 5ncX0vHS0LGzo0u1RlWVUlWxBD69ERVLUxaqz08b5Rj29Lj96ujyg6ofHj+iepHfxZnKYlB77XnT YdVqfuw/e4tuh2Ai0jlvvzte3qWh4QGlkwl7e92+fYcxUCQ64uqdmmjp5IljGl2yXDddf4OuveY6 TU7Pqjw3pwceeEBDw6MW4DeRylgE+r6BfnsrPXVqWk15WrVmpfbs263RJUs1ONSvl3fs0tZtL+ny tVdo49XrLY5hkM8MJgfwdveQTqZh1owH9h/UuivWatnYcotH+OTTz6inr1swIZjYimUrdeToMV01 n9ND3/mubr3lNjtfrTb1w8ceUToV09iyMQFi0XhM2UyHRkaXGKOy9DIsE57NdB93ZS+66Pyr/ndm MbrIH+9C96v5BQMvflyEefK8uiJeU4RLJJzW0ePH9O3vfkcb12/QwMiQJTtdtWa1Jk6c1K49uw1c 7rjrTu3asVMzc7OampjU1ddsssXVtWsvV6tUMZoDmiOjw9q9d79yxYLi0YRudG7QqhWrLSzYdx7+ vsrVkvbuecXu2fFjk0bHQ0cOanJ6UtOTU1p92RoD03RHxlLdHD95QrVKVb39fSaFP/bE41q1YqVW rFppxx/54Q/1P33638lzDumHjz2ugaF+Pfy97+s9P/Fu/cuD31Jnd1Ynjp3UwfHDmp2b1/1f/Gt1 d/Zoy7btKhXK2ndgn7ZseVmF0oJGhpZo/carzDAr2ZG27UC638BtYmpaL72wRasvv8yu7RvoFT+y ExPHtWbVZXrl0GHrJ9OV1Te//qCuvf4aTU3NGrjSX0tNpZMZnZqdVm93n9HphZe2aO/+PTp6bELD o8MWh3Ry8qS9tG3fsUO33XaHdu7eq9nZeXs542Xu0ccfN5V7uqNDAwNDFgKtTqiwS/CcXOjzFV7H 7/vS/25Duvp0LZTKxjeI4pR2UkrGo4onU4pGPUXjCTk1T6VmzTLIe1FXyXTSz6oRixnvqhcLixBr MZAt/u5XibZM8vFVZYHqKUFcvwZBeluWSoQAsKgfO7O9yp2al+e5FtH+1tvu0jUb1qheLahcaiiV 6ZKiCRWLdQ30d5iPWSSe0pHjJ02t9fLOnQaQqH2Is0hw4hOTE3riicd0zTXX6c47b1d//6AG+odM /fToDx9XV1ePxXdEMkNCGx5eoq6urF555ZBJagQnnp3Pa3Cgrpm5nHbs3K2G11B3ttskClwC4umU RpYM69TsvB5/4il193Wb5HHg0GGlEhFtfuF58zToG+xTX3ef7v3YvRocWmKSR0SEWzpbmKvF4awu JBzW2dp99bjnenKijpwWPnOOIg6hxlisaciJxFSuFCyGYTyR1tObn9Vjjzymm951k7o6upRbKGjH th0qVCp6+omnlcwklU6klUadWiirVK7plptvV1d3r4F/b9+AfuK99yhfyGnny7tMatu2fYeBF+fG lo0a0z90eFyTJ6eMqRdLOaPn1NSM9bPlhS1ad9U6Cw82ODKo7z70XW26bpNibkw7du9QKtmhKzZs 0LKlKzW6bKdq9aZ40fnwvR/V9x/5vvbtf0WrL1+r+dyC3v3en1A+90O7r8uWrdDOvXtsvMS8TKU7 tGzFKqXiKcWSMe3bvc/ub2mhpGK1ovVXrLfnYnZ6Vl09fcp2dqtUqRlwR+IRu27P/j1asXSF8rh+ VBuKJVI6eOiI+oeHdPTwURUrRZNYoX+9UtfUzJTWrFyju3/ybnV29ejGm99lcUOJZdnT02cqRkCL LOOsExPIulxG49E0kCNzRGennwEhmUSNPm11MCK6sHBq4XUh3d4evnOp6FosVtTZ061kX9T8kSvF igXaQEM3O5eTWq6pH1PZDvvdEuLKcKhOvst6W80IcC0Cr9PqxeC4j19RN+IoHokpl1+w9CrkJEOX T2eoSrLZLhE0uCOd0UIhr6uvulKFhYoB2kK+olPTea1ZvUKtVlSuy/qIo2ozYp+egf+vvWvtcdu4 ooeSSJGi3quVdr27tjePNutHEzQOHCdFCgT9AwH6c4r2d+RLvzZ/oYbT9IEEBZrEtZMGTpy1vbG9 u9rVW3xIoh7FudKkzNZujNpeI8EMIAxJkRzykJw7994z967htYuXpAMR4kcuj1zexanNTZhWSj7+ fqeLra2z2Nx8DidOrOP69X9hff0kisUS+MFfu3Yda2sbeP75FySDAG+QmiT/z+WyEsz3zs5dLJWr MrXg4qU30PN6cB2m13ZFg8m4OTTbHjZOnoaTdlCpVuD1PFx8/Q3cv3cPdrYg5ijHtRfmJKaMoTrG xJMzzBhoWMyGR2rhQc5Tzxmz6WJS8xOuYWASca6Z5A9HImVIjjgGN+aoPl+s4tULb+DV1y7h6rVP Zd1I2HBzS8iXl9Fs+Mi4JZw593PUVqtyH9QwJpGBQqmGnh/AyeYwDAZotDuorqxgckBXpwskU1jb 2EA/CDGMIvz1w4/wyvmXEURMlprHvb37ODw8hGHaSDsFpMw0Tj/3ErbOvIKbX36Nk6dexJlzB6it rKPd7ODFn5yTNolrtz+EbReQYLDm0RhrGydFQL156U0RFJVqDc0Wr2cVXuDhxlc3cf5nr+DaZ5/L c81msrjx1Q289Yu3JPvs3u6BCEKGJCstV0Rr3N0/kNEfz3975xt8+NHfZVRYLBcxCAYiMCfrAB3Q JzdqKJWKeO3i65IENl8s4adrZ+QbclwH2ze3ZVC0dfYcTp7axGedz3DlyhVsvXRGTOCddhflcgXt FudU1vDxPz5Bs0VzqQPPH6DVbOPs2fPwvUDYv43DjphwmYl9Phle1xoHBkf4cb0HtIK0u33sdnqw bAtLpSX5vm9v38YXN75EYmrgxOo6VjZWgVQSpp2ahzPMZDCmlTCKE0CogcWEWkxn46LMM+PCgKNd x0HadsXf4hZLEnKKPpmrV6/CTLKRGc5vbaFYykrn9M3dW8jYBspLRYRBhGAQYXVlA/WDNk6fOiUd luOm0e76qNVckHjXbLWQK+TgWJyfBnBmW6vRFR8Q81jd2r4j56ssLcEjgYMUzTBExnEkKaTNmI0G 4HtjtHtt7O7XMZqMZCTOEbqdMuAxMHHSRLvXgWu7yLjzKQHBaIL6bh2NdgONegNv/+pt7DHm4/qq +GCiyQRJw0A2l0bjsAsznUY2Q4bNXBl6aM14Zyr+2FOoo+kEs/EMCTMB20zIXIygP0TP87BaW8Ld +3Wc3qjBCycIfR9px5FJ1rzeQs4WM+j+bgO8v2qlgmAwQDQcClmkkLcRhBFcx4QfRuJrpC/J7weo 1ooYDmZI2/OZ+zt391BbXoEfeijmcxLk+fLlyzj/8st4YXM+R6TfDdFst3F3Zwdv/fIS6vstJE0T rUYDy7UaDBJH8i6m4xl8MpaIrZlA3rURMGg0U6hPxrizfQcbpzfkvqlJjcKRhA1lXa2VZMQWMgUP s1tPJ3CsJG7e2oFt2igvl4Vly0n51Gj5/O/draNQLogGRk2rkHUxHE9AzZsaVylfkuvgiLQf9OW9 sZ0kfG8EN2sh8CN0vS5SRgq5Yg4ZK4kGY4OWCmLSZModfh+M9l8uu2g2PckewWkrzeahpLahr5dp hJQPmL5QOsh/iAFkn+b7rvF4uv3JceLL75WWLceywTzBg3CCeqMulrBCLi+EQJKvDCuBZNoCM3K9 /8EH+PU77yDy+zLriRFnf//uu4tAwxUsn1hBuVoRqyEtM1Q0WFKMmM/UJkwoyZpamSqX/3gFFy5c EEbWYDpEPp/Fxx9fRTabQbvZwmAYIpGaodP5XIQRTV13drpi3vpyex9uriBMLmoCSE5gOSaicSh2 0RkiiYBvhNQCZ6J9tVoNye+1fee2pIPp9TqyrpI+BgHtp8zNZUsKkOl0jLSblU76039eR6fXBh37 g1Eovg36eNhTsPNlwGJqJvR99Dwfw2iCT65el0673QvRajQldYltpYXIwAgiJDSMSYx5mM+MJkAZ ST05wsdRxzMJH/TZxHs83h/vZzAaiq+o7/n4+uaOpGAhAYNBO+kDNNMWGjRl5bIoFYogIeSL6U3Q p8X9gtCXyCrsZMuFspjb+PJRuJAQ8sVXYwyDobyM7MQpVLa/3hGzHs1uScsEEhZu3b6Hw4MOvMAX Db5+eADi95e/fSrtEEcSUAYRMyNQqDKiyRR5+j4HfIcMIWZkso48t2a7IY7i3YO6EEDo06Bv609/ fh+bp54TcyM1verKsrzI9cN9LC9VxXdGvHBrW4gVHBVSKFNo0AfoHNhSk2hCIggd09VKTd4Pvhf3 9+5h/cSG+CiH4Uh8avSZcT8SjIrlgjyH5rWGEFf4XhIvJhllrrZevyO57iS5acJEvpBF47AlyVuZ A6/TbaG6vIKDw30slZdlnabiJ0kYOvr+6PUnQ2TQOP5/OPJ7ZJAMukdIXCORre/3ZD3vZmEnUsIa HkwiWJk0jCSJhjeEgRyFPnNwKXH0vXWKlOHZlLm1EpKx2ZBklYDfaeN3v/0NIklrz9GzKdqHmWJG 4hAuadGLYJHUsCoVagYDDPwQCSsNyVBsMnmjAbIHp4MACdfC1GDs/yHpeTIHO5F0ZWQ7YyyuRELY dhw5zDhqtkxMaDdNJWXEbnEeQjSGR6cgCRD8PxohSap5GMrxbqEAv9eDadtyP2T80QYbLf6XYTGn HpTLwugTSbWYdEzTWtid5yJzSQtvtwFzHvzywUgS6EcH+8Hn+J6tap6cZcnAgIw5jmRYyxyn8RSZ HMN/BWJ7HvR6ggPvkxoa/ZO9RgOO0GANibzCKRgsM7JIjRlISAi8uaPVWKRJ4PlJNSd2Q99HbW0N 9b09SRXE9kkOmo5oAkjALS0J5vS1kqnK9ylNenq/L+0YzBXH9jhJfTSClc3KAInYzYYh0rmcsGcl pBbvlyZe7sua8+w4PWE6leNGnifPm/R2LnMfe3E8Q36xMEgpr4+MXDIL+80mTNf9liGVWtyX0PN5 D8QySZ9sQt6jb589A6Om07KN98D9WajVUmtnTbpx0kjI/SctS/bhcxks2FhONivPrdtqQea08AS8 Tj6DhAE+C34/umgEfrQISKg8MunYaSfB4BjyrXEecBAin8uDTOThdAxyBGT6TKcD23Uw8NiHzK0X VCqmKtcjV44UYzwez9g5sXOgYGPnJMkbFx2DdCjqIF7M/yzzTnK+S6wxUnukqI5f1ezh4scsdjvW 6nHbj93LsV63auxZX/+zbl/hoGuNgEbgR4UAiR6LKDnv/eE9sRou16pYXa3JHLWVE6tzQtziplMc vXIETvMia47wLdMCzOS3GoACSMkyGWEvNqpJcfPVR+3YYx1gTOapdo63ftRrPt6revTWnvX1P+v2 Hx0pvadGQCPwQ0KAVouZKFp93xP5RI2OfmhGnGJc9HgSsxQFGAujJTAyA2dq01SkfGc8mEUJMFXL xth2ta5rjYBGQCOgEdAIPAkE6CZh5CFGDGHkI1oPaYakJZGKF7epYjQajRlD/7Ds7OyIQOOBDGdE AUdKfbwoYabq72pm8T31skZAI6AR0AhoBB4PASpYTN5M/zT91gwrx6woFGrcpkqKgoyCSUk5amKM ScdtjJGnhJUSXqpWJzi6rrbrWiOgEdAIaAQ0Ao+DADUzyiPGPCUZjcKLMueoIGMbKf5BgUX1jeoc pSBNjwwCy//mpJD/mBl5UFyAxZcf56L1sRoBjYBGQCOgEYgjQPlCpYpyiG4wCjMylMn1oJDjf6oI m5H2R0o91pSA3JFRvek7Uz4zHqAEl6rj29QJda0R0AhoBDQCGoEngQC5G5RBrKmlMbAHlS3WFHBx +WTMZrMZhRZ/1Mx4EIUa1xUZRF3Ug4RYfJvaT9caAY2ARkAjoBF4XAQ4bUwJLcolCjEKMP7oP1Nu MLYjwkw1qASTqrmd+Zh00QhoBDQCGgGNwHEjoAIVsF0luFQd38blB6Yx5s5KoMXVuOO+Ed2eRkAj oBHQCGgE4gLsYWh8RzPjTkqIHV1+2An0do2ARkAjoBHQCDwNBCiP4oIsvsz24uv/Jcy4Q1ygxXd+ Gherz6kR0AhoBDQCGoEHIaCCd/C/uCyKL6vj/g0P0KrLRBuSfwAAAABJRU5ErkJggg== --94eb2c1bb29cf795c1056670f1f8-- From nobody Fri Mar 2 09:05: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 DD27712D947 for ; Fri, 2 Mar 2018 09:05: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 2QanSvlv2V7j for ; Fri, 2 Mar 2018 09:05:40 -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 82EA412D86E for ; Fri, 2 Mar 2018 09:05:40 -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 w22H5crA030392; Fri, 2 Mar 2018 18:05:38 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id CD97020687C; Fri, 2 Mar 2018 18:05:38 +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 BF3E5206868; Fri, 2 Mar 2018 18:05:38 +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 w22H5cFm025596; Fri, 2 Mar 2018 18:05:38 +0100 To: William Whyte Cc: "its@ietf.org" References: <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> <5ccad588-bcd8-d179-165b-7936a34220fb@gmail.com> <5a98213d.d138c80a.ababc.519f@mx.google.com> <5a982375.042bed0a.1271f.4afc@mx.google.com> <86a2077a-ea46-c99b-c048-60ab78f69ec3@gmail.com> From: Alexandre Petrescu Message-ID: <41260b12-78c9-910f-cb9c-05cae023304d@gmail.com> Date: Fri, 2 Mar 2018 18:05: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: 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: Fri, 02 Mar 2018 17:05:44 -0000 thank you very much for this. In this figure we see a WSMP message transported with QoSData. This is very good, because security is very important. I will not push for this, and consider this close. Just if in any case later there may be some opportunity to tell the operator of the wireshark to also ping, it would be wonderful. For later. Alex Le 02/03/2018 à 18:02, William Whyte a écrit : > US implementations use QoSData with everything -- although it's not > required by 802.11-OCB, as we discussed earlier, it *is* required for a > "WAVE device", which all US devices are. > > Here's a Wireshark image from a contact showing the QoSData field: > > Inline image 1 > > Cheers, > > William > > On Fri, Mar 2, 2018 at 11:28 AM, Alexandre Petrescu > > wrote: > > > > Le 02/03/2018 à 17:16, William Whyte a écrit : > > I've confirmed that the US implementations use QoSData, just to > close that loop. > > > Thanks.  It's QoSData with IP, right? > > Alex > > > Cheers, > > William > > > On Thu, Mar 1, 2018 at 11:05 AM, Alexandre Petrescu > > >> wrote: > >     William, > >     Le 01/03/2018 à 16:59, William Whyte a écrit : > >           > I propose we rename 'OCB' into 'IP-OCB' in the draft. > >           > 'IP-OCB' is an OCB mode that can be transport IP > packets >         with .11 Data > >           > headers or with .11 QoS Data headers. > >         If it’s over OCB, then it needs to use QoSData. If > you’re doing >         Data, you’re not conformant to OCB. There can’t be an > OCB mode >         that transports packets with .11 Data, because OCB by > definition >         uses QoSData. If the draft implies that you can do >         non-conformant OCB, that’s a serious defect in the draft. > >         Some implementations may not yet have implemented this, but >         that’s on those developers. > > >     For one second, allow me the benefit of the doubt about >     specifications that may not be implemented. > >     I would like to know whether there is an implementation of > IP over >     OCB with QoSData headers?  Packet dump is sufficient, or > any other >     kind of statement. > >     I agree with you that many times it is good to write > specification >     first and implementation after. > >     Alex > > >         Cheers, > >         William > >         Sent from Mail > >         >> for Windows 10 > >         *From: *Alexandre Petrescu > >         >> >         *Sent: *Thursday, March 1, 2018 10:54 AM >         *To: *William Whyte >         >>; its@ietf.org > >         > > >> >         *Subject: *Re: [ipwave] 802.11 Data vs 802.11 QoS Data in >         IPv6-over-802.11-OCB-implementations > > >         Le 01/03/2018 à 16:50, William Whyte a écrit : > >           >  >> (there are some packet dumps with IP packets > transported >         with .11 Data > >           > > >           > headers in OCB mode at 5.9GHz, e.g. attached). > >           > > >           > My understanding is OCB mode requires QoSData, so those >         packets aren’t > >           > conformant to the standard. > >         I propose we rename 'OCB' into 'IP-OCB' in the draft. > >         'IP-OCB' is an OCB mode that can be transport IP > packets with >         .11 Data > >         headers or with .11 QoS Data headers. > >         Alex > >           > > >           > Cheers, > >           > > >           > William > >           > > >           > Sent from Mail >         >         >> for > >           > Windows 10 > >           > > >           > *From: *Alexandre Petrescu >         >         >> > >           > *Sent: *Thursday, March 1, 2018 10:48 AM > >           > *To: *its@ietf.org > > >         > >> > >           > *Subject: *Re: [ipwave] 802.11 Data vs 802.11 QoS > Data in > >           > IPv6-over-802.11-OCB -implementations > >           > > >           > In a private discussion, this question came up: > >           > > >           > Is there a packet dump showing an IP packet > transported with >         .11 QoSData > >           > > >           > headers in OCB mode at 5.9GHz. > >           > > >           > (there are some packet dumps with IP packets > transported >         with .11 Data > >           > > >           > headers in OCB mode at 5.9GHz, e.g. attached). > >           > > >           > Alex > >           > > >           > Le 01/03/2018 à 15:32, Alexandre Petrescu a écrit : > >           > > >           >  > I received some feedback from programmer. > >           > > >           >  > > >           > > >           >  > Le 28/02/2018 à 23:48, Abdussalam Baryun a écrit : > >           > > >           >  > [...] > >           > > >           >  >> 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, > >           > > >           >  > > >           > > >           >  > Here is the QoS problem for IP over 802.11 OCB in >         implementations. > >           > > >           >  > > >           > > >           >  > In short, in open source on linux, we dont know > how to >         send IP packets > >           > > >           >  > transported as 802.11 QoSData, all IP packets are >         transported as 802.11 > >           > > >           >  > Data instead. > >           > > >           >  > > >           > > >           >  > - if you ping -Q at 5.9GHz in OCB mode, the DSCP > fields >         do get > >           > > >           >  >    set properly in IP headers of Echorequest, > but there >         is no .11 QoSData > >           > > >           >  >    headers in packets.  Normally, one expects > the QoSData >         headers to be > >           > > >           >  >    present there when the DSCP (an IP field) is set. > >           > > >           >  > > >           > > >           >  > - if you want to modify kernel, and force always > to use >         QoSData headers > >           > > >           >  >    on WiFi, including OCB at 5.9GHz, there is a >         net/mac80211/tx.c file > >           > > >           >  >    with a flag called wme_sta that you could set to >         true.  But take care > >           > > >           >  >    that the C comments there say that it's not > normal to >         use QoSData > >           > > >           >  >    headers in OCB mode, because a terminal sending >         QoSData has no > >           > > >           >  >    guarantee that receivers also use QoSData (the >         negotiation of QoS > >           > > >           >  >    capabilities are absent in OCB). > >           > > >           >  > > >           > > >           >  > As you can see, this can be long to try and fix. > >           > > >           >  > > >           > > >           >  > Until then I will propose to set QoS aside from >         IP-over-OCB at this time. > >           > > >           >  > > >           > > >           >  > Alex > >           > > >           >  > > >           > > >           >  > _______________________________________________ > >           > > >           >  > 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 > > > > > > > -- > > > PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS: > wwhyte@onboardsecurity.com From nobody Fri Mar 2 09:06: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 B75E112D885 for ; Fri, 2 Mar 2018 09:06:12 -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 RJK2R-3Azgky for ; Fri, 2 Mar 2018 09:06:10 -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 9D50712D875 for ; Fri, 2 Mar 2018 09:06:09 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id s198so12768790qke.5 for ; Fri, 02 Mar 2018 09:06:09 -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=319tNNxrySKFnDoopKMRxqpTophR54boYoqjPcgKWLQ=; b=hSbqWiceHIwB06Sg7GVSQ36SA37hzxfxksvs5U0zsIErCgHwdymgh6qM7393WO8Xd0 9kBjoWhrQ1CMIJHcJ+orXg/RGX80FZCaMddKMfAvEwbNOePy2Xj0FH6U1EZVcm+cpgUo y5ILQdQ8HiMJFV/hUld4A5TC/Qygcq6sb7MXkl+saBdzvqomt/oGqFa5pxKw9za3NTj3 xnj9nY35z39XxsxIlWTgGQLvWCb2wimMiC5+qj4n/xfzWMM7poLK3dByTlNUwv5TmxyK OdiPD5G9UjRSM0fAHgdhw4gfXVfPt5/iHn7BJzL7qWQ4HX5XmPDKrjOaPNLBQuohqIY3 kJbA== 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=319tNNxrySKFnDoopKMRxqpTophR54boYoqjPcgKWLQ=; b=b7QY8pUOF67JjLp1RKyD5fWQs34rSlmxhx1CpFNDs6shdi1WNCmCyoxGN8WIF5K4SG Y1mF+mhnVmXoFo6CWL/lEOBc8LzoX3TSgZ4lPwxhcKc1YZQEOLuP3kqLmsBJiGSck//y nfRAxlk0CanE0GdurxTpfxqwkbESUMueBh/HYs4rQOi1POPY68SNNhCGtiS3aGWWIK/F ebyfY9YUmkGsXcOfwPDJbXvvq8UFvF/3xPaHXhvB0hod1zFbCvfEKIBr0Ploli2Kyztu LAoAA+AD9fCBMBxREkOKf1J8FuxSyvIDpWiLd+CIHPh90EwlcLH+oxM3dnQ6GHeDwNlh x3vQ== X-Gm-Message-State: AElRT7HqBvFln8yF78ctnlFSgenKJDG2BSQgee4Fx+T32b70g7tt0ZdL dbbQ7ikA/RRKswL9cR9CnNg= X-Google-Smtp-Source: AG47ELuii7VYMz+UTus0EanCWOkVipJ/mAHB9EvDGpOUWRwYXcksRU6sUXwQSz7uGx7ftnc+s8uArg== X-Received: by 10.55.97.70 with SMTP id v67mr9485954qkb.159.1520010368669; Fri, 02 Mar 2018 09:06: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 i37sm5089146qte.48.2018.03.02.09.06.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Mar 2018 09:06:07 -0800 (PST) From: =?UTF-8?Q?Fran=C3=A7ois_Simon?= To: =?UTF-8?B?J0rDqXLDtG1lIEjDpHJyaSc=?= , "'William Whyte'" , "'Dick Roy'" Cc: "'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> <00f801d3af1d$f20ce4c0$d626ae40$@gmail.com> <002b01d3af21$6e779a70$4b66cf50$@eurecom.fr> <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> <5ccad588-bcd8-d179-165b-7936a34220fb@gmail.com> <5a98213d.d138c80a.ababc.519f@mx.googl e.com> <006c01d3b17f$88506750$98f135f0$@eurecom.fr> In-Reply-To: <006c01d3b17f$88506750$98f135f0$@eurecom.fr> Date: Fri, 2 Mar 2018 12:06:08 -0500 Message-ID: <01eb01d3b248$c24c0df0$46e429d0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01EC_01D3B21E.D97D31E0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHelLAw/aN7IRfcwiTBG/gKcgHVEwGONDnFAivYBTcBDgW0eQFK9evKAbex+qQCF4nJkAMphqaUAo/H9voB/QVRSwGgjFsGAtvA4TEBm9hPkAKafOT2Adw4FVkBhOPELQGWvTywAi3roigCMY3M2QINk5QMAzxauy8Bvqj5jAJNyEkgoj+gn1A= Content-Language: en-us 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: Fri, 02 Mar 2018 17:06:13 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01EC_01D3B21E.D97D31E0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Aggree. =20 From: its On Behalf Of J=C3=A9r=C3=B4me = H=C3=A4rri Sent: Thursday, March 01, 2018 12:06 PM To: 'William Whyte' ; 'Dick Roy' = Cc: 'Alexandre Petrescu' ; its@ietf.org Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in = IPv6-over-802.11-OCB -implementations =20 Dear All, =20 With the risk of repeating information already sent in the thread, the = issue has never been if Data or QoSData is allowed for OCB. It is clear = it is.=20 =20 BUT considering that SAE 2945/1 (BSM) and ETSI geonet-media dependent = functionalities, both specify to use QoSData to differentiate = event-based BSM (very urgent) from periodic BMS (normal) / DENM (very = urgent) from CAM (normal) using QoSData with AC_VI (DENM/event-based = BSM) and AC_BE (CAM/periodic BSM), we have a =E2=80=98coexistence = issue=E2=80=99 . =20 Indeed, 802.11 data frame use DCF, which use a DIFS equal to 2 slot + = SIFS. Now, AC_VI (the urgent DENM/BSM) use EDCA AC_VI, also with 2 slot = + SIFS. And CAM/periodic BSM use *6* slot + SIFS. =20 In short, any IP-over-OCB will access the channel before CAM/BSM at best = and generate collisions with ITS-G5 and DSRC. This can be seem as = =E2=80=98harmful=E2=80=99 interferences with an existing system, which = must be avoided.=20 =20 That is the reason I am suggesting to use QoSData for IP-over-OCB, so = that depending on your traffic (e.g. if you transmit CAM-over-IP, or = video feeds) you can tweak the right AC_ and not interfere with = DSRC/ITS-G5..much. That would avoid a lot of issues=E2=80=A6and it does = not cost much (ok some extra bits, but come on=E2=80=A6we are not doing = ROLL here, so is it that dramatic?=20 =20 Even though not the task of IETF, it is important to make sure that any = specification will not interfere with an existing system. So, = Alex=E2=80=99s suggestion to remove any explicit mention to QoSData or = Data is probably a good trade-off, and leave it open to profiling as = function of in which channel IP-over-OCB would be used (i.e if = interference is expected or not)=E2=80=A6 =20 BR, =20 J=C3=A9r=C3=B4me =20 =20 From: its [mailto:its-bounces@ietf.org] On Behalf Of William Whyte Sent: Thursday 01 March 2018 17:29 To: Dick Roy Cc: Alexandre Petrescu; its@ietf.org =20 Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in = IPv6-over-802.11-OCB -implementations =20 If that's the case, I don't have an issue with the draft allowing Data = and QoSData, though I'd note that the definition of OCB in the = Terminology section of the draft states that QoSData is required and = should be changed if it's wrong. =20 On the question of implementations: I don't have pcaps to hand, but the = USDOT RSU spec, available from = https://transportationops.org/publications/dedicated-short-range-communic= ations-roadside-unit-specifications, requires QoSData, and OmniAir has = been testing conformance to that spec, so it's safe to assume that it's = been implemented. =20 Cheers, =20 William =20 On Thu, Mar 1, 2018 at 11:22 AM, Dick Roy > wrote: Actually I believe the QoSData restriction is in J2945/1 having only to = do with operation in the US in 5.9GHz. Data and QoSData are permitted = according to 802.11 (and 1609.x). This is not to say I believe this = discussion is relevant to the task of the ITS group, but =E2=80=A6 :^))) =20 Cheers, =20 RR _____ =20 From: its [mailto:its-bounces@ietf.org ] = On Behalf Of William Whyte Sent: Thursday, March 1, 2018 7:50 AM To: Alexandre Petrescu; its@ietf.org =20 Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in = IPv6-over-802.11-OCB -implementations =20 >> (there are some packet dumps with IP packets transported with .11 = Data=20 headers in OCB mode at 5.9GHz, e.g. attached). =20 My understanding is OCB mode requires QoSData, so those packets = aren=E2=80=99t conformant to the standard. =20 Cheers, =20 William =20 Sent from Mail for = Windows 10 =20 From: Alexandre Petrescu =20 Sent: Thursday, March 1, 2018 10:48 AM To: its@ietf.org =20 Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in = IPv6-over-802.11-OCB -implementations =20 In a private discussion, this question came up: =20 Is there a packet dump showing an IP packet transported with .11 QoSData = headers in OCB mode at 5.9GHz. =20 (there are some packet dumps with IP packets transported with .11 Data=20 headers in OCB mode at 5.9GHz, e.g. attached). =20 Alex =20 Le 01/03/2018 =C3=A0 15:32, Alexandre Petrescu a =C3=A9crit : > I received some feedback from programmer. >=20 > Le 28/02/2018 =C3=A0 23:48, Abdussalam Baryun a =C3=A9crit : > [...] >> ieee802.11ocb protocol is already implemented/tested and it is=20 >> interoperable, but what is the problem, sorry maybe I did not follow=20 >> the discussion well, >=20 > Here is the QoS problem for IP over 802.11 OCB in implementations. >=20 > In short, in open source on linux, we dont know how to send IP packets = > transported as 802.11 QoSData, all IP packets are transported as = 802.11=20 > Data instead. >=20 > - if you ping -Q at 5.9GHz in OCB mode, the DSCP fields do get > set properly in IP headers of Echorequest, but there is no .11 = QoSData > headers in packets. Normally, one expects the QoSData headers to = be > present there when the DSCP (an IP field) is set. >=20 > - if you want to modify kernel, and force always to use QoSData = headers > on WiFi, including OCB at 5.9GHz, there is a net/mac80211/tx.c file > with a flag called wme_sta that you could set to true. But take = care > that the C comments there say that it's not normal to use QoSData > headers in OCB mode, because a terminal sending QoSData has no > guarantee that receivers also use QoSData (the negotiation of QoS > capabilities are absent in OCB). >=20 > As you can see, this can be long to try and fix. >=20 > Until then I will propose to set QoS aside from IP-over-OCB at this = time. >=20 > Alex >=20 > _______________________________________________ > its mailing list > its@ietf.org =20 > https://www.ietf.org/mailman/listinfo/its =20 =20 --=20 =20 =20 PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS: = wwhyte@onboardsecurity.com =20 ------=_NextPart_000_01EC_01D3B21E.D97D31E0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Aggree.<= /o:p>

 

From:<= /b> = its <its-bounces@ietf.org> On Behalf Of J=C3=A9r=C3=B4me = H=C3=A4rri
Sent: Thursday, March 01, 2018 12:06 = PM
To: 'William Whyte' <wwhyte@onboardsecurity.com>; = 'Dick Roy' <dickroy@alum.mit.edu>
Cc: '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 = -implementations

 

Dear All,

 

With the risk of repeating information already sent in the thread, the = issue has never been if Data or QoSData is allowed for OCB. It is clear = it is.

 

BUT considering that SAE 2945/1 (BSM) and ETSI geonet-media dependent = functionalities, both specify to use QoSData to differentiate = event-based BSM (very urgent) from periodic BMS (normal) / DENM (very = urgent) from CAM (normal) using QoSData with AC_VI (DENM/event-based = BSM) and AC_BE (CAM/periodic BSM), we have a =E2=80=98coexistence = issue=E2=80=99 .

 

Indeed, 802.11 data frame use DCF, which use a DIFS equal to 2 slot + = SIFS. Now, AC_VI (the urgent DENM/BSM) use EDCA AC_VI, also with 2 slot = + SIFS. And CAM/periodic BSM use *6* slot + = SIFS.

 

In short, any IP-over-OCB will access the channel before CAM/BSM at = best and generate collisions with ITS-G5 and DSRC. This can be seem as = =E2=80=98harmful=E2=80=99 interferences with an existing system, which = must be avoided.

 

That is the reason I am suggesting to use QoSData for IP-over-OCB, so = that depending on your traffic (e.g. if you transmit CAM-over-IP, or = video feeds) you can tweak the right AC_ and not interfere with = DSRC/ITS-G5..much. That would avoid a lot of issues=E2=80=A6and it does = not cost much (ok some extra bits, but come on=E2=80=A6we are not doing = ROLL here, so is it that dramatic?

 

Even though not the task of IETF, it is important to make sure that any = specification will not interfere with an existing system. So, = Alex=E2=80=99s suggestion to remove any explicit mention to QoSData or = Data is probably a good trade-off, and leave it open to profiling as = function of in which channel IP-over-OCB would be used (i.e if = interference is expected or not)=E2=80=A6

 

BR,

 

J=C3=A9r=C3=B4me

 

 

From: its = [mailto:its-bounces@ietf.org] = On Behalf Of William Whyte
Sent: Thursday 01 March 2018 = 17:29
To: Dick Roy
Cc: Alexandre Petrescu; its@ietf.org
Subject: Re: = [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB = -implementations

 

If = that's the case, I don't have an issue with the draft allowing Data and = QoSData, though I'd note that the definition of OCB in the Terminology = section of the draft states that QoSData is required and should be = changed if it's wrong.

 

On the question of implementations: I don't have pcaps = to hand, but the USDOT RSU spec, available from https://transportationops.or= g/publications/dedicated-short-range-communications-roadside-unit-specifi= cations, requires QoSData, and OmniAir has been testing conformance = to that spec, so it's safe to assume that it's been = implemented.

 

Cheers,

 

William

 

On Thu, = Mar 1, 2018 at 11:22 AM, Dick Roy <dickroy@alum.mit.edu> = wrote:

Actu= ally I believe the QoSData restriction is in J2945/1 having only to do = with operation in the US in 5.9GHz.  Data and QoSData are permitted = according to 802.11 (and 1609.x).  This is not to say I believe = this discussion is relevant to the task of the ITS group, but =E2=80=A6 = :^)))

&nbs= p;

Chee= rs,

&nbs= p;

RR

From: its = [mailto:its-bounces@ietf.org] On Behalf Of William = Whyte
Sent: Thursday, March 1, 2018 7:50 AM
To: = Alexandre Petrescu; its@ietf.org


Subject= : Re: [ipwave] 802.11 Data vs 802.11 QoS Data in = IPv6-over-802.11-OCB = -implementations

 =

>> = (there are some packet dumps with IP packets transported with .11 Data =

headers in = OCB mode at 5.9GHz, e.g. attached).

 =

My = understanding is OCB mode requires QoSData, so those packets = aren=E2=80=99t conformant to the standard.

 =

Cheers,

 =

William

 =

Sent from Mail for Windows 10

 =

From: = Alexandre Petrescu
Sent: Thursday, March = 1, 2018 10:48 AM
To: its@ietf.org
Subject: Re: [ipwave] = 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB = -implementations

 =

In a private = discussion, this question came up:

 =

Is there a = packet dump showing an IP packet transported with .11 QoSData =

headers in = OCB mode at 5.9GHz.

 =

(there are = some packet dumps with IP packets transported with .11 Data =

headers in = OCB mode at 5.9GHz, e.g. attached).

 =

Alex

 =

Le = 01/03/2018 =C3=A0 15:32, Alexandre Petrescu a = =C3=A9crit :

> I = received some feedback from programmer.

> =

> Le = 28/02/2018 =C3=A0 23:48, Abdussalam Baryun a = =C3=A9crit :

> = [...]

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

> =

> Here is = the QoS problem for IP over 802.11 OCB in = implementations.

> =

> In = short, in open source on linux, we dont know how to send IP packets =

> = transported as 802.11 QoSData, all IP packets are transported as 802.11 =

> Data = instead.

> =

> - if = you ping -Q at 5.9GHz in OCB mode, the DSCP fields do = get

>  =   set properly in IP headers of Echorequest, but there is no .11 = QoSData

>  =   headers in packets.  Normally, one expects the QoSData = headers to be

>  =   present there when the DSCP (an IP field) is = set.

> =

> - if = you want to modify kernel, and force always to use QoSData = headers

>  =   on WiFi, including OCB at 5.9GHz, there is a net/mac80211/tx.c = file

>  =   with a flag called wme_sta that you could set to true.  But = take care

>  =   that the C comments there say that it's not normal to use = QoSData

>  =   headers in OCB mode, because a terminal sending QoSData has = no

>  =   guarantee that receivers also use QoSData (the negotiation of = QoS

>  =   capabilities are absent in OCB).

> =

> As you = can see, this can be long to try and fix.

> =

> Until = then I will propose to set QoS aside from IP-over-OCB at this = time.

> =

> = Alex

> =

> = _______________________________________________

> 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

------=_NextPart_000_01EC_01D3B21E.D97D31E0-- From nobody Fri Mar 2 09:10: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 8298312D885 for ; Fri, 2 Mar 2018 09:10:40 -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 HY0QBrJFXps0 for ; Fri, 2 Mar 2018 09:10:38 -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 1A4D412D86E for ; Fri, 2 Mar 2018 09:10:37 -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 w22HAWA0034464; Fri, 2 Mar 2018 18:10:32 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5EA3E206850; Fri, 2 Mar 2018 18:10: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 4A4F0201965; Fri, 2 Mar 2018 18:10: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 w22HAVDu028323; Fri, 2 Mar 2018 18:10:32 +0100 To: =?UTF-8?Q?Fran=c3=a7ois_Simon?= , =?UTF-8?B?J0rDqXLDtG1lIEjDpHJyaSc=?= , "'William Whyte'" , "'Dick Roy'" Cc: its@ietf.org References: <00f801d3af1d$f20ce4c0$d626ae40$@gmail.com> <002b01d3af21$6e779a70$4b66cf50$@eurecom.fr> <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> <5ccad588-bcd8-d179-165b-7936a34220fb@gmail.com> <5a98213d.d138c80a.ababc.519f@mx.googl e.com> <006c01d3b17f$88506750$98f135f0$@eurecom.fr> <01eb01d3b248$c24c0df0$46e429d0$@gmail.com> From: Alexandre Petrescu Message-ID: <4d3a05bf-169f-c531-c8b4-ba2310ae3e22@gmail.com> Date: Fri, 2 Mar 2018 18: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: <01eb01d3b248$c24c0df0$46e429d0$@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 -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: Fri, 02 Mar 2018 17:10:40 -0000 Is there a discussion slot to discuss this in London? I would be interested to contribute to the discussion on QoS, but provided we agree it is about QoS with IP, not QoS without IP. Alex Le 02/03/2018 à 18:06, François Simon a écrit : > Aggree. > > *From:*its *On Behalf Of *Jérôme Härri > *Sent:* Thursday, March 01, 2018 12:06 PM > *To:* 'William Whyte' ; 'Dick Roy' > > *Cc:* 'Alexandre Petrescu' ; its@ietf.org > *Subject:* Re: [ipwave] 802.11 Data vs 802.11 QoS Data in > IPv6-over-802.11-OCB -implementations > > Dear All, > > With the risk of repeating information already sent in the thread, the > issue has never been if Data or QoSData is allowed for OCB. It is clear > it is. > > BUT considering that SAE 2945/1 (BSM) and ETSI geonet-media dependent > functionalities, both specify to use QoSData to differentiate > event-based BSM (very urgent) from periodic BMS (normal) / DENM (very > urgent) from CAM (normal) using QoSData with AC_VI (DENM/event-based > BSM) and AC_BE (CAM/periodic BSM), we have a ‘coexistence issue’ . > > Indeed, 802.11 data frame use DCF, which use a DIFS equal to 2 slot + > SIFS. Now, AC_VI (the urgent DENM/BSM) use EDCA AC_VI, also with 2 slot > + SIFS. And CAM/periodic BSM use **6** slot + SIFS. > > In short, any IP-over-OCB will access the channel before CAM/BSM at best > and generate collisions with ITS-G5 and DSRC. This can be seem as > ‘harmful’ interferences with an existing system, which must be avoided. > > That is the reason I am suggesting to use QoSData for IP-over-OCB, so > that depending on your traffic (e.g. if you transmit CAM-over-IP, or > video feeds) you can tweak the right AC_ and not interfere with > DSRC/ITS-G5..much. That would avoid a lot of issues…and it does not cost > much (ok some extra bits, but come on…we are not doing ROLL here, so is > it that dramatic? > > Even though not the task of IETF, it is important to make sure that any > specification will not interfere with an existing system. So, Alex’s > suggestion to remove any explicit mention to QoSData or Data is probably > a good trade-off, and leave it open to profiling as function of in which > channel IP-over-OCB would be used (i.e if interference is expected or not)… > > BR, > > Jérôme > > *From:*its [mailto:its-bounces@ietf.org] *On Behalf Of *William Whyte > *Sent:* Thursday 01 March 2018 17:29 > *To:* Dick Roy > *Cc:* Alexandre Petrescu; its@ietf.org > *Subject:* Re: [ipwave] 802.11 Data vs 802.11 QoS Data in > IPv6-over-802.11-OCB -implementations > > If that's the case, I don't have an issue with the draft allowing Data > and QoSData, though I'd note that the definition of OCB in the > Terminology section of the draft states that QoSData is required and > should be changed if it's wrong. > > On the question of implementations: I don't have pcaps to hand, but the > USDOT RSU spec, available from > https://transportationops.org/publications/dedicated-short-range-communications-roadside-unit-specifications, > requires QoSData, and OmniAir has been testing conformance to that spec, > so it's safe to assume that it's been implemented. > > Cheers, > > William > > On Thu, Mar 1, 2018 at 11:22 AM, Dick Roy > wrote: > > Actually I believe the QoSData restriction is in J2945/1 having only to > do with operation in the US in 5.9GHz.  Data and QoSData are permitted > according to 802.11 (and 1609.x).  This is not to say I believe this > discussion is relevant to the task of the ITS group, but … :^))) > > Cheers, > > RR > > ------------------------------------------------------------------------ > > *From:*its [mailto:its-bounces@ietf.org ] > *On Behalf Of *William Whyte > *Sent:* Thursday, March 1, 2018 7:50 AM > *To:* Alexandre Petrescu; its@ietf.org > > > *Subject:* Re: [ipwave] 802.11 Data vs 802.11 QoS Data in > IPv6-over-802.11-OCB -implementations > >>> (there are some packet dumps with IP packets transported with .11 Data > > headers in OCB mode at 5.9GHz, e.g. attached). > > My understanding is OCB mode requires QoSData, so those packets aren’t > conformant to the standard. > > Cheers, > > William > > Sent from Mail for > Windows 10 > > *From: *Alexandre Petrescu > *Sent: *Thursday, March 1, 2018 10:48 AM > *To: *its@ietf.org > *Subject: *Re: [ipwave] 802.11 Data vs 802.11 QoS Data in > IPv6-over-802.11-OCB -implementations > > In a private discussion, this question came up: > > Is there a packet dump showing an IP packet transported with .11 QoSData > > headers in OCB mode at 5.9GHz. > > (there are some packet dumps with IP packets transported with .11 Data > > headers in OCB mode at 5.9GHz, e.g. attached). > > Alex > > Le 01/03/2018 à 15:32, Alexandre Petrescu a écrit : > >> I received some feedback from programmer. > >> > >> Le 28/02/2018 à 23:48, Abdussalam Baryun a écrit : > >> [...] > >>> 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, > >> > >> Here is the QoS problem for IP over 802.11 OCB in implementations. > >> > >> In short, in open source on linux, we dont know how to send IP packets > >> transported as 802.11 QoSData, all IP packets are transported as 802.11 > >> Data instead. > >> > >> - if you ping -Q at 5.9GHz in OCB mode, the DSCP fields do get > >>    set properly in IP headers of Echorequest, but there is no .11 QoSData > >>    headers in packets.  Normally, one expects the QoSData headers to be > >>    present there when the DSCP (an IP field) is set. > >> > >> - if you want to modify kernel, and force always to use QoSData headers > >>    on WiFi, including OCB at 5.9GHz, there is a net/mac80211/tx.c file > >>    with a flag called wme_sta that you could set to true.  But take care > >>    that the C comments there say that it's not normal to use QoSData > >>    headers in OCB mode, because a terminal sending QoSData has no > >>    guarantee that receivers also use QoSData (the negotiation of QoS > >>    capabilities are absent in OCB). > >> > >> As you can see, this can be long to try and fix. > >> > >> Until then I will propose to set QoS aside from IP-over-OCB at this time. > >> > >> Alex > >> > >> _______________________________________________ > >> 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 Fri Mar 2 11:54: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 6C611124217 for ; Fri, 2 Mar 2018 11:54:44 -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 zEl295eA_cSI for ; Fri, 2 Mar 2018 11:54:41 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c: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 06C5B1200FC for ; Fri, 2 Mar 2018 11:54:41 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id z9so5067255wmb.3 for ; Fri, 02 Mar 2018 11:54: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=Oy4Ez8miAtwEbySI+wmXhIyNOvhvfED2wocR9SCEF2s=; b=n8eSosM4D1EAPB0XROYrzJ7EBnRTcsFFjRcaHBHrjfo+BfLGUWObRvlNoM1fLGF+dx H2kYNark3EkIrj3cooLIcwoQZWU7h9bdZBY2IctnFsMmva1EMEoKKMPGfykUeuJifVVA hZrFRbfNsABbzdw4ui0aTayK+eKyt0KikciYR1kjXVcYyZvNoT06kssfyOFwA78zOCKc 2GVzyEsPxsTvJlc2a8B8GhyhS41aTkjKC1LjjwNbKBozniHinGBW9h/rbQgzPqa+bGSp 2fqCY65SEhJCcS+shm2dK2HPzzXvh2c9vxO7/ZlaY3k1ev2mjdS2b4vasZkfscwnAi1Q pkyQ== 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=Oy4Ez8miAtwEbySI+wmXhIyNOvhvfED2wocR9SCEF2s=; b=oLRnJemypJIjLUa5Zjq3sLAb5BXNrlpnJYa/RHcSl1wVJiRXL53VhDl9Q0EXQ7oP8k cY0ETq2CEG0ABg7KSqCVpbrOmhunMrODsfxFlPvh6R/rf6U/EMfFhiEPBFNycnSweT2F j2K5D5SquAvyhZpBBzamxUfKfT9Ncs8rwXRg6xBikg5X6LqbfiEn4+SoHCaAh3KR6ZFd R1dfACqWXGUgRGNfzC9FtovEPwUoaSCMAe/JJYxdjnBF3D+Lv5xWsvVBn22x3JbIw6cB moMKJBhUGX/EHzJNPiBnXKzu6cZ68sk9QKMh3NKyTMyhhBN2bA/znjPI2UK1HKQ2/OYe R31Q== X-Gm-Message-State: AElRT7FK0+Ns3CWuwCRVT2v783tKJ6J+VfGptWKW4gfV3WT96PFxOrGx IBiOxUekviFmOgP5lpjdSEyedw== X-Google-Smtp-Source: AG47ELu5iqpo7eSB+IH9OXiT0phLbgjwbHswg1dm5C/EPJ8dHSFn3mM29l0MDPbuZRdvuzb5aAC15Q== X-Received: by 10.28.177.86 with SMTP id a83mr2389968wmf.143.1520020479311; Fri, 02 Mar 2018 11:54:39 -0800 (PST) Received: from acorde.lan (2.154.161.159.dyn.user.ono.com. [2.154.161.159]) by smtp.gmail.com with ESMTPSA id i44sm5803620wri.23.2018.03.02.11.54.37 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 02 Mar 2018 11:54:38 -0800 (PST) Message-ID: <1520020476.3381.4.camel@it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano Reply-To: cjbc@it.uc3m.es To: Alexandre Petrescu , =?ISO-8859-1?Q?Fran=E7ois?= Simon , =?ISO-8859-1?Q?=27J=E9r=F4me_H=E4rri=27?= , 'William Whyte' , 'Dick Roy' Cc: its@ietf.org Date: Fri, 02 Mar 2018 20:54:36 +0100 In-Reply-To: <4d3a05bf-169f-c531-c8b4-ba2310ae3e22@gmail.com> References: <00f801d3af1d$f20ce4c0$d626ae40$@gmail.com> <002b01d3af21$6e779a70$4b66cf50$@eurecom.fr> <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> <5ccad588-bcd8-d179-165b-7936a34220fb@gmail.com> <5a98213d.d138c80a.ababc.519f@mx.googl e.com> <006c01d3b17f$88506750$98f135f0$@eurecom.fr> <01eb01d3b248$c24c0df0$46e429d0$@gmail.com> <4d3a05bf-169f-c531-c8b4-ba2310ae3e22@gmail.com> 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] 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: Fri, 02 Mar 2018 19:54:44 -0000 Hi Alex, On Fri, 2018-03-02 at 18:10 +0100, Alexandre Petrescu wrote: > Is there a discussion slot to discuss this in London? You mean to discuss about QoS with IPv6 over 802.11-OCB? Are you requesting it to present some material to foster the discussion? We sure can allocate some time for that (I'd say that under the "rechartering" discussion slot, as I understood that this issue is closed for the WG doc, right?). Do you think -20 is ready so I can review it and request our AD to send the draft to 6man for review? Thanks, Carlos > > I would be interested to contribute to the discussion on QoS, but > provided we agree it is about QoS with IP, not QoS without IP. > > Alex > > Le 02/03/2018 à 18:06, François Simon a écrit : > > Aggree. > > > > *From:*its *On Behalf Of *Jérôme Härri > > *Sent:* Thursday, March 01, 2018 12:06 PM > > *To:* 'William Whyte' ; 'Dick Roy' > > > > *Cc:* 'Alexandre Petrescu' ; its@ietf > > .org > > *Subject:* Re: [ipwave] 802.11 Data vs 802.11 QoS Data in > > IPv6-over-802.11-OCB -implementations > > > > Dear All, > > > > With the risk of repeating information already sent in the thread, > > the > > issue has never been if Data or QoSData is allowed for OCB. It is > > clear > > it is. > > > > BUT considering that SAE 2945/1 (BSM) and ETSI geonet-media > > dependent > > functionalities, both specify to use QoSData to differentiate > > event-based BSM (very urgent) from periodic BMS (normal) / DENM > > (very > > urgent) from CAM (normal) using QoSData with AC_VI (DENM/event- > > based > > BSM) and AC_BE (CAM/periodic BSM), we have a ‘coexistence issue’ . > > > > Indeed, 802.11 data frame use DCF, which use a DIFS equal to 2 slot > > + > > SIFS. Now, AC_VI (the urgent DENM/BSM) use EDCA AC_VI, also with 2 > > slot > > + SIFS. And CAM/periodic BSM use **6** slot + SIFS. > > > > In short, any IP-over-OCB will access the channel before CAM/BSM at > > best > > and generate collisions with ITS-G5 and DSRC. This can be seem as > > ‘harmful’ interferences with an existing system, which must be > > avoided. > > > > That is the reason I am suggesting to use QoSData for IP-over-OCB, > > so > > that depending on your traffic (e.g. if you transmit CAM-over-IP, > > or > > video feeds) you can tweak the right AC_ and not interfere with > > DSRC/ITS-G5..much. That would avoid a lot of issues…and it does not > > cost > > much (ok some extra bits, but come on…we are not doing ROLL here, > > so is > > it that dramatic? > > > > Even though not the task of IETF, it is important to make sure that > > any > > specification will not interfere with an existing system. So, > > Alex’s > > suggestion to remove any explicit mention to QoSData or Data is > > probably > > a good trade-off, and leave it open to profiling as function of in > > which > > channel IP-over-OCB would be used (i.e if interference is expected > > or not)… > > > > BR, > > > > Jérôme > > > > *From:*its [mailto:its-bounces@ietf.org] *On Behalf Of *William > > Whyte > > *Sent:* Thursday 01 March 2018 17:29 > > *To:* Dick Roy > > *Cc:* Alexandre Petrescu; its@ietf.org > > *Subject:* Re: [ipwave] 802.11 Data vs 802.11 QoS Data in > > IPv6-over-802.11-OCB -implementations > > > > If that's the case, I don't have an issue with the draft allowing > > Data > > and QoSData, though I'd note that the definition of OCB in the > > Terminology section of the draft states that QoSData is required > > and > > should be changed if it's wrong. > > > > On the question of implementations: I don't have pcaps to hand, but > > the > > USDOT RSU spec, available from > > https://transportationops.org/publications/dedicated-short-range-co > > mmunications-roadside-unit-specifications, > > requires QoSData, and OmniAir has been testing conformance to that > > spec, > > so it's safe to assume that it's been implemented. > > > > Cheers, > > > > William > > > > On Thu, Mar 1, 2018 at 11:22 AM, Dick Roy > > wrote: > > > > Actually I believe the QoSData restriction is in J2945/1 having > > only to > > do with operation in the US in 5.9GHz. Data and QoSData are > > permitted > > according to 802.11 (and 1609.x). This is not to say I believe > > this > > discussion is relevant to the task of the ITS group, but … :^))) > > > > Cheers, > > > > RR > > > > ----------------------------------------------------------------- > > ------- > > > > *From:*its [mailto:its-bounces@ietf.org > g>] > > *On Behalf Of *William Whyte > > *Sent:* Thursday, March 1, 2018 7:50 AM > > *To:* Alexandre Petrescu; its@ietf.org > > > > > > *Subject:* Re: [ipwave] 802.11 Data vs 802.11 QoS Data in > > IPv6-over-802.11-OCB -implementations > > > > > > (there are some packet dumps with IP packets transported with > > > > .11 Data > > > > headers in OCB mode at 5.9GHz, e.g. attached). > > > > My understanding is OCB mode requires QoSData, so those packets > > aren’t > > conformant to the standard. > > > > Cheers, > > > > William > > > > Sent from Mail > > for > > Windows 10 > > > > *From: *Alexandre Petrescu > > *Sent: *Thursday, March 1, 2018 10:48 AM > > *To: *its@ietf.org > > *Subject: *Re: [ipwave] 802.11 Data vs 802.11 QoS Data in > > IPv6-over-802.11-OCB -implementations > > > > In a private discussion, this question came up: > > > > Is there a packet dump showing an IP packet transported with .11 > > QoSData > > > > headers in OCB mode at 5.9GHz. > > > > (there are some packet dumps with IP packets transported with .11 > > Data > > > > headers in OCB mode at 5.9GHz, e.g. attached). > > > > Alex > > > > Le 01/03/2018 à 15:32, Alexandre Petrescu a écrit : > > > > > I received some feedback from programmer. > > > > > > Le 28/02/2018 à 23:48, Abdussalam Baryun a écrit : > > > [...] > > > > 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, > > > > > > Here is the QoS problem for IP over 802.11 OCB in > > > implementations. > > > > > > In short, in open source on linux, we dont know how to send IP > > > packets > > > transported as 802.11 QoSData, all IP packets are transported as > > > 802.11 > > > Data instead. > > > > > > - if you ping -Q at 5.9GHz in OCB mode, the DSCP fields do get > > > set properly in IP headers of Echorequest, but there is no > > > .11 QoSData > > > headers in packets. Normally, one expects the QoSData > > > headers to be > > > present there when the DSCP (an IP field) is set. > > > > > > - if you want to modify kernel, and force always to use QoSData > > > headers > > > on WiFi, including OCB at 5.9GHz, there is a > > > net/mac80211/tx.c file > > > with a flag called wme_sta that you could set to true. But > > > take care > > > that the C comments there say that it's not normal to use > > > QoSData > > > headers in OCB mode, because a terminal sending QoSData has > > > no > > > guarantee that receivers also use QoSData (the negotiation of > > > QoS > > > capabilities are absent in OCB). > > > > > > As you can see, this can be long to try and fix. > > > > > > Until then I will propose to set QoS aside from IP-over-OCB at > > > this time. > > > > > > Alex > > > > > > _______________________________________________ > > > its mailing list > > > its@ietf.org > > > https://www.ietf.org/mailman/listinfo/its > > > > > > > > -- > > > > PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS: > > wwhyte@onboardsecurity.com > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Fri Mar 2 11:57: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 12FB0126C22 for ; Fri, 2 Mar 2018 11:57:50 -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 k5ZAJJelWuKd for ; Fri, 2 Mar 2018 11:57:48 -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 4655D124217 for ; Fri, 2 Mar 2018 11:57:48 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id 139so5117997wmn.2 for ; Fri, 02 Mar 2018 11:57:48 -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=mnqAZh9YebLMwGk7MV67HRoTvPXFqYGi6TD+t1m//ak=; b=0nqYg87EWabcE/i8xUiK36zAtpEPqU7x0iGunv6XpyIJwJj7K2QclqVTKKoN7myibc hpIpNq7uWIFzdP2IelMiDzy4GCULN6i/Qo9zlL7AxQg87j3CvNyX7VCF0WDRF0/QJxSb 2VzTOApc8jcICM2ijUBYh71yEObcxcP2geRIF7s8yoREn3XJbxE34TxNUyTC0TjgKxuP DVp3aRXjCM5WWo51piFHtNqOIG6+0882Fj7+ayxD20RcDzTre3tCvx1hqdy+sSNMfypQ xgaFNWyIbQq3FObkLMYZUceumS1jXjx22EukHmKinFOxWHIiuAj1vkh+3gjjhg/KRrmN fUig== 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=mnqAZh9YebLMwGk7MV67HRoTvPXFqYGi6TD+t1m//ak=; b=Fy1RpVqZYk65AWoiXJNBUxsJlz4EydEH4R6OYpXx4PBbsExRnUB3myDbRIRhOekmym yEVcwtnTF4jMhorbVN0XXI3nmLNk6pbaJLkUXnsMs6ayE7gJxgg9PRkKlH4swRaaqvID KD/rLDTtLu7eMCK1CcROeP9AVSlvyrEq+icYylcudyQ+Q7+SMmUXuxeL/RRSVmeC3kvB Ew8VoRXsBvksYtJmB+/Jg1fcJ26xGx6D8TvPGMypVezKCsoZZQZnYUhswO0FJFAxguwj a6LGTxp9pJspHt+GnnXwzeiT2KE3cLRMzPUOFzonp9SHfXZ4rdPoSvG+Mln9uzrMEjW+ T+eg== X-Gm-Message-State: AElRT7H7Wy2nc7QgK5A3vnx4traLoO+1KPgldng6BeRzeGaUS5rzyDNe XUCdk5+RLWAls8BY+DAPz2mplA== X-Google-Smtp-Source: AG47ELt7CO89uOmWImy1BiA4ogzWJFJD44gmXc283sRCSPmNeezp8vVChYJZ/GqxcJQUNwXig0X2oA== X-Received: by 10.28.195.87 with SMTP id t84mr2188149wmf.118.1520020666628; Fri, 02 Mar 2018 11:57:46 -0800 (PST) Received: from acorde.lan (2.154.161.159.dyn.user.ono.com. [2.154.161.159]) by smtp.gmail.com with ESMTPSA id l11sm6090563wrg.71.2018.03.02.11.57.45 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 02 Mar 2018 11:57:45 -0800 (PST) Message-ID: <1520020664.3381.7.camel@it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano Reply-To: cjbc@it.uc3m.es To: "Mr. Jaehoon Paul Jeong" Cc: its@ietf.org, Russ Housley , Chris Shen Date: Fri, 02 Mar 2018 20:57:44 +0100 In-Reply-To: References: <1519233010.3516.75.camel@it.uc3m.es> <1520007912.3735.43.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] 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: Fri, 02 Mar 2018 19:57:50 -0000 OK, thanks! Carlos On Sat, 2018-03-03 at 01:33 +0900, Mr. Jaehoon Paul Jeong wrote: > Hi Carlos and Russ, > I would like to present our WG document: > - IP-based Vehicular Networking: Use Cases, Survey and Problem > Statement > . draft-ietf-ipwave-vehicular-networking-02 (to be submitted before > the submission due) > . 20 min > > Also, I would like to request a 30-min slot to present rechartering > and work items and discuss them. > I will merge the last IPWAVE mailing list discussion and add some > suggested items for rechartering. > > Thanks. > > Best Regards, > Paul > > > > On Sat, Mar 3, 2018 at 1:25 AM, Carlos Jesús Bernardos Cano uc3m.es> wrote: > > Hi, > > > > We have not received any slot request to related to rechartering. > > If we > > don't receive any request. Does this mean that there is no interest > > on > > rechartering? > > > > Please send your agenda requests by this Sunday EOD. > > > > Thanks! > > > > Carlos > > > > On Wed, 2018-02-21 at 18:10 +0100, Carlos Jesús Bernardos Cano > > wrote: > > > 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 > > > > _______________________________________________ > > its mailing list > > its@ietf.org > > https://www.ietf.org/mailman/listinfo/its > > > From nobody Fri Mar 2 11:58: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 CBE34126C25 for ; Fri, 2 Mar 2018 11:58:04 -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 YfFRZuQhN-Ar for ; Fri, 2 Mar 2018 11:58:01 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 D56B1126C22 for ; Fri, 2 Mar 2018 11:58:00 -0800 (PST) Received: by mail-wm0-x22d.google.com with SMTP id i3so5075160wmi.4 for ; Fri, 02 Mar 2018 11:58:00 -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=NNKKlVojQYVSKpL+D8yZI9rzp3LhfRAjSs9Ae9wQiSk=; b=G36oZiPMfromRASXg91rZs6Vh18M+luZh0svAh+Yt5rrsKBsv0+/SK9nOhhL+Tndr6 MCbx7a19JhxBLn2u61TmM0xEo8rbt3tGkM9RmcwbN+nsWfFTCpMGctahw2JqFSfjxzsw HFuZzV3GtiW6y+1DLug6hKbqCkU+QEcMFl9woosd/6rZ/AIaJ4xyPSfqwetPkbuC4ZT2 Z1IX8CW3HpYCQx7Bcz1mUhNtxbxOr7pl2suJfIMeTQSv6e86VCcXHAjaqdwGdVbfv1Oo 6nI4bw3tuqLPowbsBG4DMsV9efEaEf+kUI533PQh4gWS2Wh2RkpHZEp1K/oTtOCGnUsa 5flw== 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=NNKKlVojQYVSKpL+D8yZI9rzp3LhfRAjSs9Ae9wQiSk=; b=Q07PpPqAEL9pkdRtr1DBpFjHWTkRBFySqv4blsHFcTFwEy5SknR85E2WpFXj+tf8pO a/BG6a4WgPdfsss3POow8C1WrhrZ7jVLsiNLmTrSE/oBdNDOd3vkNm7wsAXwhnUVP4Tj uGFV6avDv+NvyeQUgJ/b9jcMQwjzwgvb4dLGpK/BuTGZq2VrI7sijLt9knE7i0fbNetZ gkw4UTxtQwxv5/JdHrOWCNN+q59kHVIMyQtG+T1+AgeRko88YQub/Z8tV0QAXunSbbjR NXewNzgPV6LuoNRiXyQLhXFpuTutXAXGZFzD6B7LeUK+gqsSVy5rRb63Yhd3U2Jan0eE wqbw== X-Gm-Message-State: AElRT7HHiOp+MMiFeBqi4Gz6s76/Fd3bmJgYqBRGcCn2FJtiQf9TXPBU hTNx8sU7h8T+tnYawd0ELPGReA== X-Google-Smtp-Source: AG47ELtQXIC0CiH2YGeJwIEofcsofdojo2UybIMG1EUoWAmlsl0edd6DSpAJbGYVFKsRBy7EFcpbpg== X-Received: by 10.28.9.19 with SMTP id 19mr2723969wmj.114.1520020679290; Fri, 02 Mar 2018 11:57:59 -0800 (PST) Received: from acorde.lan (2.154.161.159.dyn.user.ono.com. [2.154.161.159]) by smtp.gmail.com with ESMTPSA id 69sm1872575wmp.36.2018.03.02.11.57.58 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 02 Mar 2018 11:57:58 -0800 (PST) Message-ID: <1520020677.3381.8.camel@it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano Reply-To: cjbc@it.uc3m.es To: "Sri Gundavelli (sgundave)" , "Mr. Jaehoon Paul Jeong" Cc: Chris Shen , Russ Housley , "its@ietf.org" Date: Fri, 02 Mar 2018 20:57:57 +0100 In-Reply-To: References: <1519233010.3516.75.camel@it.uc3m.es> <1520007912.3735.43.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] 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: Fri, 02 Mar 2018 19:58:05 -0000 Thanks. Carlos On Fri, 2018-03-02 at 16:36 +0000, Sri Gundavelli (sgundave) wrote: > Hi Carlos & Russ, > > I need a slot to present a new proposal around RSU manageability. > > Name: IP Interfaces for RSU Manageability > Time: 10 to 15 mins. > > Sri > > > From: its on behalf of "Mr. Jaehoon Paul > Jeong" > Date: Friday, March 2, 2018 at 8:33 AM > To: CARLOS JESUS BERNARDOS CANO > Cc: Chris Shen , Russ Housley .com>, "Mr. Jaehoon Paul Jeong" , "its@ietf.o > rg" > Subject: Re: [ipwave] IETF 101: IPWAVE agenda requests > > Hi Carlos and Russ, > I would like to present our WG document: > - IP-based Vehicular Networking: Use Cases, Survey and Problem > Statement > . draft-ietf-ipwave-vehicular-networking-02 (to be submitted before > the submission due) > . 20 min > > Also, I would like to request a 30-min slot to present rechartering > and work items and discuss them. > I will merge the last IPWAVE mailing list discussion and add some > suggested items for rechartering. > > Thanks. > > Best Regards, > Paul > > > > On Sat, Mar 3, 2018 at 1:25 AM, Carlos Jesús Bernardos Cano uc3m.es> wrote: > > Hi, > > > > We have not received any slot request to related to rechartering. > > If we > > don't receive any request. Does this mean that there is no interest > > on > > rechartering? > > > > Please send your agenda requests by this Sunday EOD. > > > > Thanks! > > > > Carlos > > > > On Wed, 2018-02-21 at 18:10 +0100, Carlos Jesús Bernardos Cano > > wrote: > > > 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 > > > > _______________________________________________ > > its mailing list > > its@ietf.org > > https://www.ietf.org/mailman/listinfo/its > > > > > From nobody Fri Mar 2 12: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 C1A4C12DA51 for ; Fri, 2 Mar 2018 12:03:36 -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 8ddPu3ZkqZOm for ; Fri, 2 Mar 2018 12:03:35 -0800 (PST) Received: from mail-pg0-x243.google.com (mail-pg0-x243.google.com [IPv6:2607:f8b0:400e:c05::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 1593B126C22 for ; Fri, 2 Mar 2018 12:03:35 -0800 (PST) Received: by mail-pg0-x243.google.com with SMTP id e9so4190723pgs.10 for ; Fri, 02 Mar 2018 12:03:35 -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=m4GcCNhK4JbHiJwPlI2K0E1eu4z1GqGnS42e4ZTjUY8=; b=riM3d+qKAqq9HLz7aYCQtMbDzDt7O2HQ9Gysqj3vHqZ7OQxdX/q7DiHjNw08L/MgD3 jdZ1qhAcyxudlL09AOcVM5odwuP+2H8jH4TJkMOG8nie1jrfRQmDU5RLG5b7gtAfLztl 22UflY/s8w9WxjK/xNFRwpG5Zneah5bq+8u6VUYC9L1YVatRdYJ/WTIuVA75fVqmAyxT n62hPVppK8i3P9Z5DGo9JYYAPDB9UgxV3A4jou0eW6gxNU8YMS0fOS4vCZCmHM3pCPv+ vrn2v0gyCbFbB1/UkY/jStQAercCW5TArmBfulCYFy34WrzUIrk4j+JSwTj1zti3V8h7 vG8g== 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=m4GcCNhK4JbHiJwPlI2K0E1eu4z1GqGnS42e4ZTjUY8=; b=KxR8AfuFb6eYj6hO5ohEMu9eHqvoSErlgJqWuIjj4EfInv7YDNiEdkAt3KWwq4B39L rl/pj6z8CyCCbL61DTu0URFCbwa3uFrPJZnvsNP5HH6g1phnOlndLIsSqY4089XL3pu0 0vv4xQQzwzndTdE6bf3MZbFOyrdQ871Yovdq8l6I5pEG8ISZn/Ngt4lbv8/uDbrDeiAO oOmV/XZlmHPgOgtaeZmSDfcfG2TCbTP/9uP3zMzD9hnPbioyoWSWBciuco1YTB0+rqOy HYNz1FCZ7PbI3qvpBOuVUgMJgubRQH0HuldUNUTmMkb4CpKYkX8bbVjiC7uGXssCgK9r h3JQ== X-Gm-Message-State: APf1xPC7Yc1T6IAC0EPzSmu4P0UA4UDJ8hPBW33g1UhVZv9H1BZ8Gjyv xCp4JpLXrtkMxGhys4Mskg4sKC501TM= X-Google-Smtp-Source: AG47ELuIJhI+swlxFKkXBBbqATbfJrsDVre8AlD2lrzidj3vS7ZghQJ25W06sDBWD6CtzhvX4FaWVA== X-Received: by 10.101.92.6 with SMTP id u6mr5437299pgr.440.1520021014020; Fri, 02 Mar 2018 12:03:34 -0800 (PST) Received: from [172.22.228.216] ([162.210.130.3]) by smtp.gmail.com with ESMTPSA id a65sm5281439pfg.90.2018.03.02.12.03.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Mar 2018 12:03:33 -0800 (PST) From: Tony Li Message-Id: <64DE64AB-CB38-4925-9B50-1576C7DA1C0A@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_014E40CD-C70C-4FF2-A848-6ACED242494C" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Fri, 2 Mar 2018 12:03:31 -0800 In-Reply-To: <1520020476.3381.4.camel@it.uc3m.es> Cc: Alexandre Petrescu , =?utf-8?Q?Fran=C3=A7ois_Simon?= , =?utf-8?B?SsOpcsO0bWUgSMOkcnJp?= , William Whyte , Dick Roy , its@ietf.org To: =?utf-8?Q?Carlos_Jes=C3=BAs_Bernardos_Cano?= References: <00f801d3af1d$f20ce4c0$d626ae40$@gmail.com> <002b01d3af21$6e779a70$4b66cf50$@eurecom.fr> <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> <5ccad588-bcd8-d179-165b-7936a34220fb@gmail.com> <5a98213d.d138c80a.ababc.519f@mx.googl e.com> <006c01d3b17f$88506750$98f135f0$@eurecom.fr> <01eb01d3b248$c24c0df0$46e429d0$@gmail.com> <4d3a05bf-169f-c531-c8b4-ba2310ae3e22@gmail.com> <1520020476.3381.4.camel@it.uc3m.es> 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 -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: Fri, 02 Mar 2018 20:03:38 -0000 --Apple-Mail=_014E40CD-C70C-4FF2-A848-6ACED242494C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 2, 2018, at 11:54 AM, Carlos Jes=C3=BAs Bernardos Cano = wrote: >=20 > You mean to discuss about QoS with IPv6 over 802.11-OCB? Are you > requesting it to present some material to foster the discussion? >=20 > We sure can allocate some time for that (I'd say that under the > "rechartering" discussion slot, as I understood that this issue is > closed for the WG doc, right?). I=E2=80=99m not at all convinced that we have rough consensus on QoS = yet. If we don=E2=80=99t converge by London, I would propose a hum. Tony --Apple-Mail=_014E40CD-C70C-4FF2-A848-6ACED242494C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Mar 2, 2018, at 11:54 AM, Carlos Jes=C3=BAs Bernardos Cano = <cjbc@it.uc3m.es> = wrote:

You mean to discuss about QoS = with IPv6 over 802.11-OCB? Are you
requesting it to present some = material to foster the discussion?

We sure can allocate some time for that (I'd say = that under the
"rechartering" discussion slot, as I = understood that this issue is
closed for the WG doc, = right?).

I=E2=80=99m not at all convinced that = we have rough consensus on QoS yet.

If we don=E2=80=99t converge by London, = I would propose a hum.

Tony

= --Apple-Mail=_014E40CD-C70C-4FF2-A848-6ACED242494C-- From nobody Fri Mar 2 12:18: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 B4D83126C25 for ; Fri, 2 Mar 2018 12:18:22 -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 6ZrW0mEUVt2F for ; Fri, 2 Mar 2018 12:18:20 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c: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 7B94F124217 for ; Fri, 2 Mar 2018 12:18:20 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id a20so4463219wmd.1 for ; Fri, 02 Mar 2018 12:18:20 -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=D7M0knWLZiQDt7CwR6KXtDbDKuFG+ic6qMaJdGLakF4=; b=AMI4uaazvx4vNc/Kv+zL3I38ZRs7kLyBYKsaCJJE1cAf171A9vdDVAmWTzC9bTO41b A6/qrMzCom3Qby7HBWmHqVtzsN0eMqhim1edNFPWWSh+srgyWRTlO2W7neFKBSCBDKRC uOV3bCprIsd8e5Z95QvwsplUhGjn4SqUcJYWcxLwmpjim5whaTc/jOsDqRMyEsaqWaRL dsg5w/ncfrq8c8N/CW63qsZF3GF4Gs0fx4szFANxzsIFvq79/wH1xOKoM6G7jvc0MfsR 8UicJOmIMcN3Y1InLA0OPRVIbaskY5gOkiS94dQcLUwdnorCuQE+m9MoqV3vGtwo1QQc wnkg== 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=D7M0knWLZiQDt7CwR6KXtDbDKuFG+ic6qMaJdGLakF4=; b=VQtKdkEXfFmxR/+7i+/LIxTBX9waoh3lhbecO01uHjkbFswPqGIUnkKOnqdtdCxU+K 2bgYjSJ4rnw0JzN8YGP4PnGJejAWK7ZYH3HujZ5u7vXLZWgwLPvQHeT1AhkJwe04OTrt 4BA/rTqfR9vTOviPZM6v0MrZvtVUIw0YUks78vA2aOyZxvFiGP3+1rPUPjgPVY4eelCk C1hzq2ST/mYoSmHjo/Kf2FqUfI+4xtGsFfukjkf47Qegj52x3hWnL+H2s8827d4Btqfr AijC7qi+uxDuK0Sp850l8uHvNLni1/AJdvfDwjO35MpC6iwHiqerCZd6QH7Lup/nzndJ LRNQ== X-Gm-Message-State: AElRT7F1Ot7UTRDPx5XboRsJ7h6eGkDeDZlgJRQBHQImRMvAo613W7n1 VLiAt0gRqpNoT7zYvpZfA8C7pA== X-Google-Smtp-Source: AG47ELuOKwJ+31EOj0bfncekwv6t1t3Is2OnlQXylJdwGK22sIou3ZHbTsXrt5oLoPvWWKrAA1zcvA== X-Received: by 10.28.128.79 with SMTP id b76mr2628507wmd.10.1520021898950; Fri, 02 Mar 2018 12:18:18 -0800 (PST) Received: from acorde.lan (2.154.161.159.dyn.user.ono.com. [2.154.161.159]) by smtp.gmail.com with ESMTPSA id x17sm8083303wrg.32.2018.03.02.12.18.17 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 02 Mar 2018 12:18:18 -0800 (PST) Message-ID: <1520021896.3381.10.camel@it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano Reply-To: cjbc@it.uc3m.es To: Tony Li Cc: Alexandre Petrescu , =?ISO-8859-1?Q?Fran=E7ois?= Simon , =?ISO-8859-1?Q?J=E9r=F4me_H=E4rri?= , William Whyte , Dick Roy , its@ietf.org Date: Fri, 02 Mar 2018 21:18:16 +0100 In-Reply-To: <64DE64AB-CB38-4925-9B50-1576C7DA1C0A@gmail.com> References: <00f801d3af1d$f20ce4c0$d626ae40$@gmail.com> <002b01d3af21$6e779a70$4b66cf50$@eurecom.fr> <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> <5ccad588-bcd8-d179-165b-7936a34220fb@gmail.com> <5a98213d.d138c80a.ababc.519f@mx.googl e.com> <006c01d3b17f$88506750$98f135f0$@eurecom.fr> <01eb01d3b248$c24c0df0$46e429d0$@gmail.com> <4d3a05bf-169f-c531-c8b4-ba2310ae3e22@gmail.com> <1520020476.3381.4.camel@it.uc3m.es> <64DE64AB-CB38-4925-9B50-1576C7DA1C0A@gmail.com> 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] 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: Fri, 02 Mar 2018 20:18:23 -0000 Hi Tony, OK, thanks. Alex: can you summarize the different views in one single e-mail, so we can take it from there? Thanks, Carlos On Fri, 2018-03-02 at 12:03 -0800, Tony Li wrote: > > > > On Mar 2, 2018, at 11:54 AM, Carlos Jesús Bernardos Cano > c3m.es> wrote: > > > > You mean to discuss about QoS with IPv6 over 802.11-OCB? Are you > > requesting it to present some material to foster the discussion? > > > > We sure can allocate some time for that (I'd say that under the > > "rechartering" discussion slot, as I understood that this issue is > > closed for the WG doc, right?). > > > I’m not at all convinced that we have rough consensus on QoS yet. > > If we don’t converge by London, I would propose a hum. > > Tony > From nobody Sat Mar 3 05: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 0E23712778D for ; Sat, 3 Mar 2018 05:27:45 -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 t55PjytogoaD for ; Sat, 3 Mar 2018 05:27: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 09391120721 for ; Sat, 3 Mar 2018 05:27: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 w23DRdvP017557; Sat, 3 Mar 2018 14:27:39 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 70CF220165E; Sat, 3 Mar 2018 14:27:39 +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 62CE9200800; Sat, 3 Mar 2018 14:27:39 +0100 (CET) Received: from [132.166.84.104] ([132.166.84.104]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w23DRcte014857; Sat, 3 Mar 2018 14:27:39 +0100 To: dickroy@alum.mit.edu 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> <1eca0280-0931-fa39-5706-cadc22cca17c@gmail.com> <36063FD97F6C469AA6B00ADDE6C63DE1@SRA6> <21c76a7b-614c-1d10-a809-8722d52efff7@gmail.com> <4CEE01F22380408B9481D8A84E283D27@SRA6> From: Alexandre Petrescu Message-ID: <07f679c4-1c0d-09dc-0b62-0136f491acb8@gmail.com> Date: Sat, 3 Mar 2018 14:27: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: <4CEE01F22380408B9481D8A84E283D27@SRA6> 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 - new text proposal X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 13:27:45 -0000 Le 03/03/2018 à 01:33, Dick Roy a écrit : > No, you do not have it right. IEEE 802.11 links never have Ethernet II > 802.3 headers; they have 802.11 headers. There is no tunneling of 802.3 > beneath/inside 802.11 to put it another way. I agree. > With the publication of .11ak, there is now a way to incorporate 802.11 > links in 802.1Q bridged LANs. Prior to this, the means for getting 802.11 > streams onto 802.3 LANs was through the DS in the AP. In the DS, magically > the headers got changed ... the DS was intentionally left to "vendor > implementation". I did not know that. > I don't know where you got the idea 802.3 was tunneled inside 802.11, > however you should abandon it. I am not meaning any tunnel. I think we dont understand each other. The IP stacks dont fill 802.11 headers. They fill Ethernet II (aka DIX) headers, accordidng to RFC2464 IPv6-over-Ethernet. Then there is an adaptation layer that removes the EthernetII header and puts an 802.11 header in there. The Ethernet headers are not sent on 802.11, there is no tunneling. (tunnelling == header in another header, or routing headers). Alex > > Hope this helps! > > RR > > PS. The DIX specification is only a part of 802.3; there's a bit more but > it's a real kludge. > > -----Original Message----- > From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] > Sent: Friday, March 2, 2018 1:00 AM > To: dickroy@alum.mit.edu > Cc: its@ietf.org > Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB > - new text proposal > > Dick, > > My understanding is in explanation further below. I hope I have it > right, but I never know. > > Essentially, I would like to ask you: do you agree that IPv6 currently > runs on top of EthernetII (aka DIX) and not directly on top of 802.11? > (even when IPv6 packets are sent on 802.11 interfaces). > > Alex > > Le 01/03/2018 à 19:24, Dick Roy a écrit : > [...] >> NEW: >> >>> At reception, this layer takes as input the IEEE 802.11 header and >>> the Logical-Link Layer Control Header and produces an Ethernet II >>> Header. >> >> */[RR] What "layer"? This makes little to no sense. > > The 'layer' is the 802.11-to-Ethernet Adaptation Layer, in the title of > the section. > > As far as I can tell IPv6 does not run directly over 802.11 layer, but > over the Ethernet layer. So it needs an adaptation layer. > >> Why would any "layer" take as input DLL headers (MAC and LLC sublayer >> headers) and "produce" another MAC (and LLC) header??? > > An adaptation layer helps the IP stack adapt to various link layers, > like 802.11 or 802.15.4. The IP stack stays the same: always constructs > EthernetII headers. And an adaptation layer converts that to 802.11 or > 802.15.4 or oher. > > In linux, the copy operations of this layer are in net/mac80211/tx.c > ether_addr_copy(amsdu_hdr->h_source, h_80211_src). The 'amsdu' is DIX. > > This adaptation layer, one day maybe, may set that AC_BK field for > IP-over-OCB-with-QoSData by copying it from the IP header. > > The 802.11-to-Ethernet Adaptation Layer outputs a MAC header, but not an > LLC header, even though in input there is an LLC header in 802.11. > >> That's the function of a bridge! > > In principle yes, but it depends what you call a bridge. > > In software, a bridge tool like brctl can do the function of a bridge. > The adaptation layer is not brctl. > >> Why are you even mentioning Ethernet II headers in a draft concerned >> with IEEE 802.11 MACs & PHYs!/* > > Because there is no draft concerned with IP over 802.11 per se, and in > this draft we are concerned only with the OCB part of 802.11. > > If you want, maybe someone can develop an IP stack that is specific to > 802.11, and eliminate this adaptation layer that seems superfluos. That > could be put in an IP-over-802.11 document. > > But I am afraid there is too much software to write. > >> >> OLD: >> >>> 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. >> >> NEW: >> >>> The Receiver and Transmitter Address fields in the 802.11 header >>> MUST >> >>> contain the same values as the Destination and the Source Address >> >>> fields in the Ethernet II Header, respectively. >> >> */[RR] This seems wrong. Where in the heck did the Ethernet II >> header come from in the first place?? > > One can see the EthernetII headers in wireshark packet dumps in normal > mode (not in monitor mode). > >> Where is 802.3 in a document dealing with IPv6 and 802.11??? > > I agree with this questioning. > > My answer is this: we need to write IPv6 over the OCB part of 802.11. > But there is no IPv6 over 802.11 in first place. What there is is > IPv6-over-Ethernet. > >> More importantly, I would also not make any specification of this >> sort in the document. > > I can try another rephrasing. > >> The four address format of 802.11 may prove very useful in the >> future, > > I agree. > > For that you would need an IPv6-over-802.11 document, and the software. > >> especially when the group does its job of simply defining new >> IPv6 functionality for rapidly varying wireless networks. Then all >> mention of OCB mode simply dies away, as well it should! Immediately! >> And then all the good work performed can be used with any and all >> Wi-Fi (802.11) LANs and others! Which is a real good thing, because >> the probability that 5.9GHz OCB operations are actually going to be >> deployed in the forseeable future is declining to zero at a rate that >> will make your heads spin. /* > > Noted. > > [...] > >> NEW: >> >>> The specification of the 802.11 header used to transmit IP packets >>> is >>> outside the scope of this document. >> >> */[RR] Nice! And the right idea! However it is in direct conflict >> with the change you suggest above. Leave this statement in, and >> REMOVE all the rest!/* > > I keep that paragraph. > > But the EthernetII header is always there, even when IP appears to run > on 802.11. I dont know how you want me to not talk about EthernetII, > aka DIX. > > Alex > > [...] > > From nobody Sat Mar 3 09:36:11 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 C2AFA126CD6; Sat, 3 Mar 2018 09:36:09 -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.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152009856974.8410.16409861324923705911@ietfa.amsl.com> Date: Sat, 03 Mar 2018 09:36:09 -0800 Archived-At: Subject: [ipwave] I-D Action: draft-ietf-ipwave-ipv6-over-80211ocb-21.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: Sat, 03 Mar 2018 17:36:10 -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-21.txt Pages : 39 Date : 2018-03-03 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-21 https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-21 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-21 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 Sat Mar 3 09:38:27 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 26C16126D3F for ; Sat, 3 Mar 2018 09:38:26 -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 9Bq768u42SNI for ; Sat, 3 Mar 2018 09:38:23 -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 52C62126BFD for ; Sat, 3 Mar 2018 09:38: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 w23HcLpY004220 for ; Sat, 3 Mar 2018 18:38:21 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id AA623200DDB for ; Sat, 3 Mar 2018 18:38:21 +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 9E348200DB1 for ; Sat, 3 Mar 2018 18:38:21 +0100 (CET) Received: from [132.166.84.104] ([132.166.84.104]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w23HcKOg015949 for ; Sat, 3 Mar 2018 18:38:20 +0100 References: <152009857000.8410.8266485378671362859.idtracker@ietfa.amsl.com> To: "its@ietf.org" From: Alexandre Petrescu X-Forwarded-Message-Id: <152009857000.8410.8266485378671362859.idtracker@ietfa.amsl.com> Message-ID: <06620206-0177-b6bd-bb4b-c4a247a8e449@gmail.com> Date: Sat, 3 Mar 2018 18:38: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: <152009857000.8410.8266485378671362859.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------2F9C724B8C016F7F23B7557D" Content-Language: fr Archived-At: Subject: [ipwave] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-21.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: Sat, 03 Mar 2018 17:38:26 -0000 This is a multi-part message in MIME format. --------------2F9C724B8C016F7F23B7557D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi IPWAVErs, I have submitted the version -21 of the IPv6-over-OCB draft. This is the changelog:    o  Corrected a few nits and added names in Acknowledgments section.    o  Removed unused reference to old Internet Draft tsvwg about QoS. This addresses all comments during WGLC and Shepherd review. Alex -------- Message transféré -------- Sujet : New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-21.txt Date : Sat, 3 Mar 2018 09:36:10 -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-21.txt has been successfully submitted by Alexandre Petrescu and posted to the IETF repository. Name: draft-ietf-ipwave-ipv6-over-80211ocb Revision: 21 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-03-03 Group: ipwave Pages: 39 URL: https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-21.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-21 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-21 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-21 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 --------------2F9C724B8C016F7F23B7557D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi IPWAVErs,

I have submitted the version -21 of the IPv6-over-OCB draft.

This is the changelog:

   o  Corrected a few nits and added names in Acknowledgments section.

   o  Removed unused reference to old Internet Draft tsvwg about QoS.

This addresses all comments during WGLC and Shepherd review.

Alex



-------- Message transféré --------
Sujet : New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-21.txt
Date : Sat, 3 Mar 2018 09:36:10 -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-21.txt
has been successfully submitted by Alexandre Petrescu and posted to the
IETF repository.

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

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
--------------2F9C724B8C016F7F23B7557D-- From nobody Sat Mar 3 09:52: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 830BF126CB6 for ; Sat, 3 Mar 2018 09:52:03 -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 hXvtvCUoEPtc for ; Sat, 3 Mar 2018 09:52: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 1036E1204DA for ; Sat, 3 Mar 2018 09:52:00 -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 w23Hpr7a091301; Sat, 3 Mar 2018 18:51:53 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 709FE201E75; Sat, 3 Mar 2018 18:51: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 576DA200E32; Sat, 3 Mar 2018 18:51:53 +0100 (CET) Received: from [132.166.84.104] ([132.166.84.104]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w23Hpqqr020982; Sat, 3 Mar 2018 18:51:52 +0100 To: cjbc@it.uc3m.es, Tony Li Cc: =?UTF-8?Q?Fran=c3=a7ois_Simon?= , =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , William Whyte , Dick Roy , its@ietf.org References: <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> <5ccad588-bcd8-d179-165b-7936a34220fb@gmail.com> <5a98213d.d138c80a.ababc.519f@mx.googl e.com> <006c01d3b17f$88506750$98f135f0$@eurecom.fr> <01eb01d3b248$c24c0df0$46e429d0$@gmail.com> <4d3a05bf-169f-c531-c8b4-ba2310ae3e22@gmail.com> <1520020476.3381.4.camel@it.uc3m.es> <64DE64AB-CB38-4925-9B50-1576C7DA1C0A@gmail.com> <1520021896.3381.10.camel@it.uc3m.es> From: Alexandre Petrescu Message-ID: <9b5daf2c-8c75-61f3-dded-31b86506c4e1@gmail.com> Date: Sat, 3 Mar 2018 18:51:51 +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: <1520021896.3381.10.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] 802.11 Data vs 802.11 QoS Data - summary X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 17:52:03 -0000 Hi Carlos, The last version, -21, is neutral with respect to which 802.11 headers to use. It says "802.11 headers" and does not say anything about which Subtype. It does not say "MAY use QOSData", nor does it say "MAY use Data". The different views on this topic are the following: - some suggest the 802.11 Data headers is the best choice to transmit IP datagrams on 802.11 in OCB mode at 5.9 GHz. The reasons invoked relate to: it is widely implemented this way, and there is some high-level doubting QoS in general across Internet. - some suggest, on the contrary, that the best choice to transmit IP datagrams on 802.11 in OCB mode at 5.9 GHz is the 802.11 QoS Data headers instead. The reasons invoked are: the OCB mode at 5.9GHz is already used to transmit very important non-IP packets (WSMP, CAM, etc), each using QoS Data headers; there may be a risk of loss of QoS guarantee if somebody else (IP) uses Data headers instead. - the IEEE OCB standard permits the use of both QoSData headers _and_ Data headers. But further standards beyond that, require the use of QoSData headers although they dont say they require it for IP. - a partial solution was suggested publicly, and agreed by some private and public emails, to use a certain QoS AC value (Access Category) to transport IP. - many coexistence was required and necessary. It is because of this difference of views that we removed the QoSData-vs-Data altogether from the IP-over-OCB draft. Alex Le 02/03/2018 à 21:18, Carlos Jesús Bernardos Cano a écrit : > Hi Tony, > > OK, thanks. > > Alex: can you summarize the different views in one single e-mail, so we > can take it from there? > > Thanks, > > Carlos > > On Fri, 2018-03-02 at 12:03 -0800, Tony Li wrote: >> >> >>> On Mar 2, 2018, at 11:54 AM, Carlos Jesús Bernardos Cano >> c3m.es> wrote: >>> >>> You mean to discuss about QoS with IPv6 over 802.11-OCB? Are you >>> requesting it to present some material to foster the discussion? >>> >>> We sure can allocate some time for that (I'd say that under the >>> "rechartering" discussion slot, as I understood that this issue is >>> closed for the WG doc, right?). >> >> >> I’m not at all convinced that we have rough consensus on QoS yet. >> >> If we don’t converge by London, I would propose a hum. >> >> Tony >> > From nobody Sat Mar 3 10:00: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 B25BE126CB6 for ; Sat, 3 Mar 2018 10:00:34 -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 2lPJ_mXInFYk for ; Sat, 3 Mar 2018 10:00: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 D4F571204DA for ; Sat, 3 Mar 2018 10:00:25 -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 w23I0N1N092096 for ; Sat, 3 Mar 2018 19:00:24 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E1F6D200D23 for ; Sat, 3 Mar 2018 19:00: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 D26D7200800 for ; Sat, 3 Mar 2018 19:00:23 +0100 (CET) Received: from [132.166.84.104] ([132.166.84.104]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w23I0LrW024340 for ; Sat, 3 Mar 2018 19:00:22 +0100 To: "its@ietf.org" From: Alexandre Petrescu Message-ID: <9077d652-3e44-d078-12f0-1376a9bff2d3@gmail.com> Date: Sat, 3 Mar 2018 19:00: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 Content-Type: multipart/alternative; boundary="------------A29038F9C1F1B6C89649F1CA" Content-Language: fr Archived-At: Subject: [ipwave] IPv6-over-OCB - implementations and packet dumps X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 18:00:35 -0000 This is a multi-part message in MIME format. --------------A29038F9C1F1B6C89649F1CA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi IPWAVErs, The IPv6-over-OCB draft is implemented in many places. An OCB patch existed for the linux kernel since 6 years, maintained privately and publicly by a few people on the Internet.  It has been integrated in the mainline in the recent years.  Still, a few simple operations are necessary, see the patch posted below. In addition, there are few packet dumps of IP packets on OCB and together with CAM, that are available upon request.  They are generated by us and YoGoKo.  A few other companies have such traces. With this patch applied, one can do one's own packet traces of IP packets on OCB, with Wireshark. Alex ------------------------------------------------------------------------------------------------------------------- - download the linux kernel linux-4.9.61. - copy the patch file inside the linux folder - cd into the linux folder - make menuconfig and check:         > Networking support > Wireless ->  cfg80211 - wireless configuration API         > Networking support > Wireless ->  use statically compiled regulatory rules database         > Networking support > Wireless -> support CRDA         > Networking support > Wireless -> Generic IEEE 802.11 Networking Stack (mac80211)         > Device Drivers > Network device support -> Wireless LAN -> Atheros 802.11n wireless cards support         > Device Drivers > Network device support -> Wireless LAN -> Atheros ath9k PCI/PCIe bus support - Patch the kernel using the command "patch -p1 < patch.file" - and make the kernel - install iw 4.9 - iw dev wlan0 set type ocb - ifconfig wlan0 up - iw dev wlan0 ocb join 5900 10MHz When we boot the board our country code is US. If for you it is different you can change the country with the "iw reg set" command. This is important in order to define which channels are available. This patch file was created with inspiration from somebody else from the Internet who used python to achieve the same, but which is hard to do on small platforms. Date: 27 February 2018 Based on:https://drive.google.com/file/d/0BxK6WTQZ97QVWF9tRURjOGhBU2c/view; and other online resources diff -ur linux-4.9.61/drivers/net/wireless/ath/ath9k/common-init.c linux-4.9.61-pat/drivers/net/wireless/ath/ath9k/common-init.c --- linux-4.9.61/drivers/net/wireless/ath/ath9k/common-init.c 2017-11-08 03:08:37.000000000 -0600 +++ linux-4.9.61-pat/drivers/net/wireless/ath/ath9k/common-init.c 2017-11-17 04:33:50.168704602 -0600 @@ -86,6 +86,27 @@ CHAN5G(5785, 35), /* Channel 157 */ CHAN5G(5805, 36), /* Channel 161 */ CHAN5G(5825, 37), /* Channel 165 */ + + CHAN5G(5850, 38), /* Channel 170 */ + /* ITA-G5B */ + CHAN5G(5855, 39), /* Channel 171 */ + CHAN5G(5860, 40), /* Channel 172 */ + CHAN5G(5865, 41), /* Channel 173 */ + CHAN5G(5870, 42), /* Channel 174 */ + /* ITS-G5A */ + CHAN5G(5875, 43), /* Channel 175 */ + CHAN5G(5880, 44), /* Channel 176 */ + CHAN5G(5885, 45), /* Channel 177 */ + CHAN5G(5890, 46), /* Channel 178 */ + CHAN5G(5895, 47), /* Channel 179 */ + CHAN5G(5900, 48), /* Channel 180 */ + CHAN5G(5905, 49), /* Channel 181 */ + /* ITS-G5D */ + CHAN5G(5910, 50), /* Channel 182 */ + CHAN5G(5915, 51), /* Channel 183 */ + CHAN5G(5920, 52), /* Channel 184 */ + CHAN5G(5925, 53), /* Channel 185 */ + }; /* Atheros hardware rate code addition for short premble */ diff -ur linux-4.9.61/drivers/net/wireless/ath/ath9k/hw.h linux-4.9.61-pat/drivers/net/wireless/ath/ath9k/hw.h --- linux-4.9.61/drivers/net/wireless/ath/ath9k/hw.h 2017-11-08 03:08:37.000000000 -0600 +++ linux-4.9.61-pat/drivers/net/wireless/ath/ath9k/hw.h 2017-11-17 04:34:18.781260652 -0600 @@ -73,7 +73,7 @@ #define ATH9K_RSSI_BAD -128 -#define ATH9K_NUM_CHANNELS 38 +#define ATH9K_NUM_CHANNELS 54 /* Register read/write primitives */ #define REG_WRITE(_ah, _reg, _val) \ diff -ur linux-4.9.61/drivers/net/wireless/ath/regd.c linux-4.9.61-pat/drivers/net/wireless/ath/regd.c --- linux-4.9.61/drivers/net/wireless/ath/regd.c 2017-11-08 03:08:37.000000000 -0600 +++ linux-4.9.61-pat/drivers/net/wireless/ath/regd.c 2017-11-17 04:37:11.684613511 -0600 @@ -45,9 +45,9 @@ /* We allow IBSS on these on a case by case basis by regulatory domain */ #define ATH9K_5GHZ_5150_5350 REG_RULE(5150-10, 5350+10, 80, 0, 30,\ NL80211_RRF_NO_IR) -#define ATH9K_5GHZ_5470_5850 REG_RULE(5470-10, 5850+10, 80, 0, 30,\ +#define ATH9K_5GHZ_5470_5925 REG_RULE(5470-10, 5925+10, 80, 0, 30,\ NL80211_RRF_NO_IR) -#define ATH9K_5GHZ_5725_5850 REG_RULE(5725-10, 5850+10, 80, 0, 30,\ +#define ATH9K_5GHZ_5725_5925 REG_RULE(5725-10, 5925+10, 80, 0, 30,\ NL80211_RRF_NO_IR) #define ATH9K_2GHZ_ALL ATH9K_2GHZ_CH01_11, \ @@ -55,11 +55,11 @@ ATH9K_2GHZ_CH14 #define ATH9K_5GHZ_ALL ATH9K_5GHZ_5150_5350, \ - ATH9K_5GHZ_5470_5850 + ATH9K_5GHZ_5470_5925 /* This one skips what we call "mid band" */ #define ATH9K_5GHZ_NO_MIDBAND ATH9K_5GHZ_5150_5350, \ - ATH9K_5GHZ_5725_5850 + ATH9K_5GHZ_5725_5925 /* Can be used for: * 0x60, 0x61, 0x62 */ Only in linux-4.9.61-pat/include: config Only in linux-4.9.61-pat/include: generated diff -ur linux-4.9.61/net/wireless/db.txt linux-4.9.61-pat/net/wireless/db.txt --- linux-4.9.61/net/wireless/db.txt 2017-11-08 03:08:37.000000000 -0600 +++ linux-4.9.61-pat/net/wireless/db.txt 2017-11-17 04:38:44.958417939 -0600 @@ -1,17 +1,1220 @@ +# This is the world regulatory domain +country 00: + (2402 - 2472 @ 40), (20) + # Channel 12 - 13. + (2457 - 2482 @ 40), (20), NO-IR + # Channel 14. Only JP enables this and for 802.11b only + (2474 - 2494 @ 20), (20), NO-IR, NO-OFDM + # Channel 36 - 48 + (5170 - 5250 @ 80), (20), NO-IR, AUTO-BW + # Channel 52 - 64 + (5250 - 5330 @ 80), (20), NO-IR, DFS, AUTO-BW + # Channel 100 - 144 + (5490 - 5730 @ 160), (20), NO-IR, DFS + # Channel 149 - 165 + (5735 - 5835 @ 80), (20), NO-IR + # IEEE 802.11ad (60GHz), channels 1..3 + (57240 - 63720 @ 2160), (0) + + #channel 172 184 + (5860 - 5920 @ 80), (10), NO-IR + +country AD: + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20) + (5250 - 5330 @ 80), (20), DFS + (5490 - 5710 @ 80), (27), DFS + # 60 gHz band channels 1-4, ref: Etsi En 302 567 + (57000 - 66000 @ 2160), (40) + +country AE: DFS-FCC + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (17), AUTO-BW + (5250 - 5330 @ 80), (24), DFS, AUTO-BW + (5490 - 5730 @ 160), (24), DFS + (5735 - 5835 @ 80), (30) + +country AF: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + +# Source: +#http://pucanguilla.org/Downloads/January2005-Anguilla%20Table%20of%20Allocations.pdf +country AI: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + +country AL: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20.00), AUTO-BW + (5250 - 5330 @ 80), (20.00), DFS, AUTO-BW + (5490 - 5710 @ 160), (27.00), DFS + +country AM: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (18) + (5250 - 5330 @ 80), (18), DFS + +country AN: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + +country AR: DFS-FCC + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (17), AUTO-BW + (5250 - 5330 @ 80), (24), DFS, AUTO-BW + (5490 - 5730 @ 160), (24), DFS + (5735 - 5835 @ 80), (30) + +country AS: DFS-FCC + (2402 - 2472 @ 40), (30) + (5170 - 5250 @ 80), (24), AUTO-BW + (5250 - 5330 @ 80), (24), DFS, AUTO-BW + (5490 - 5730 @ 160), (24), DFS + (5735 - 5835 @ 80), (30) + +country AT: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + # 60 gHz band channels 1-4, ref: Etsi En 302 567 + (57000 - 66000 @ 2160), (40) + +country AU: + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (17), AUTO-BW + (5250 - 5330 @ 80), (24), DFS, AUTO-BW + (5490 - 5710 @ 160), (24), DFS + (5735 - 5835 @ 80), (30) + +country AW: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + +country AZ: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (18), AUTO-BW + (5250 - 5330 @ 80), (18), DFS, AUTO-BW + +country BA: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + # 60 gHz band channels 1-4, ref: Etsi En 302 567 + (57000 - 66000 @ 2160), (40) + +country BB: DFS-FCC + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (23), AUTO-BW + (5250 - 5330 @ 80), (23), DFS, AUTO-BW + (5735 - 5835 @ 80), (30) + +country BD: DFS-JP + (2402 - 2482 @ 40), (20) + (5735 - 5835 @ 80), (30) + +country BE: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + # 60 gHz band channels 1-4, ref: Etsi En 302 567 + (57000 - 66000 @ 2160), (40) + +country BF: DFS-FCC + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (17), AUTO-BW + (5250 - 5330 @ 80), (24), DFS, AUTO-BW + (5490 - 5730 @ 160), (24), DFS + (5735 - 5835 @ 80), (30) + +country BG: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + # 60 gHz band channels 1-4, ref: Etsi En 302 567 + (57000 - 66000 @ 2160), (40) + +country BH: DFS-JP + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20) + (5250 - 5330 @ 80), (20), DFS + (5735 - 5835 @ 80), (20) + +country BL: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + +country BM: DFS-FCC + (2402 - 2472 @ 40), (30) + (5170 - 5250 @ 80), (24), AUTO-BW + (5250 - 5330 @ 80), (24), DFS, AUTO-BW + (5490 - 5730 @ 160), (24), DFS + (5735 - 5835 @ 80), (30) + +country BN: DFS-JP + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5735 - 5835 @ 80), (20) + +country BO: DFS-JP + (2402 - 2482 @ 40), (20) + (5250 - 5330 @ 80), (30), DFS + (5735 - 5835 @ 80), (30) + +country BR: DFS-FCC + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (17), AUTO-BW + (5250 - 5330 @ 80), (24), DFS, AUTO-BW + (5490 - 5730 @ 160), (24), DFS + (5735 - 5835 @ 80), (30) + +country BS: DFS-FCC + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (24), AUTO-BW + (5250 - 5330 @ 80), (24), DFS, AUTO-BW + (5490 - 5730 @ 160), (24), DFS + (5735 - 5835 @ 80), (30) + +# Source: +#http://www.bicma.gov.bt/paper/publication/nrrpart4.pdf +country BT: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + +country BY: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + +country BZ: DFS-JP + (2402 - 2482 @ 40), (30) + (5735 - 5835 @ 80), (30) + +country CA: DFS-FCC + (2402 - 2472 @ 40), (30) + (5170 - 5250 @ 80), (17), AUTO-BW + (5250 - 5330 @ 80), (24), DFS, AUTO-BW + (5490 - 5730 @ 160), (24), DFS + (5735 - 5835 @ 80), (30) + +# Source: +#http://www.art-rca.org +country CF: DFS-FCC + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 40), (17) + (5250 - 5330 @ 40), (24), DFS + (5490 - 5730 @ 40), (24), DFS + (5735 - 5835 @ 40), (30) + +country CH: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + # 60 gHz band channels 1-4, ref: Etsi En 302 567 + (57000 - 66000 @ 2160), (40) + +country CI: DFS-FCC + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (17), AUTO-BW + (5250 - 5330 @ 80), (24), DFS, AUTO-BW + (5490 - 5730 @ 160), (24), DFS + (5735 - 5835 @ 80), (30) + +country CL: DFS-JP + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5735 - 5835 @ 80), (20) + +country CN: DFS-FCC + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (23), AUTO-BW + (5250 - 5330 @ 80), (23), DFS, AUTO-BW + (5735 - 5835 @ 80), (30) + # 60 gHz band channels 1,4: 28dBm, channels 2,3: 44dBm + # ref:http://www.miit.gov.cn/n11293472/n11505629/n11506593/n11960250/n11960606/n11960700/n12330791.files/n12330790.pdf + (57240 - 59400 @ 2160), (28) + (59400 - 63720 @ 2160), (44) + (63720 - 65880 @ 2160), (28) + +country CO: DFS-FCC + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (17), AUTO-BW + (5250 - 5330 @ 80), (24), DFS, AUTO-BW + (5490 - 5730 @ 160), (24), DFS + (5735 - 5835 @ 80), (30) + +country CR: DFS-FCC + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (17) + (5250 - 5330 @ 80), (24), DFS + (5490 - 5730 @ 80), (24), DFS + (5735 - 5835 @ 80), (30) + +country CX: DFS-FCC + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (24), AUTO-BW + (5250 - 5330 @ 80), (24), DFS, AUTO-BW + (5490 - 5730 @ 160), (24), DFS + (5735 - 5835 @ 80), (30) + +country CY: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + # 60 gHz band channels 1-4, ref: Etsi En 302 567 + (57000 - 66000 @ 2160), (40) + +# Data fromhttp://www.ctu.eu/164/download/VOR/VOR-12-08-2005-34.pdf +# andhttp://www.ctu.eu/164/download/VOR/VOR-12-05-2007-6-AN.pdf +# Power at 5250 - 5350 MHz and 5470 - 5725 MHz can be doubled if TPC is +# implemented. +country CZ: DFS-ETSI + (2400 - 2483.5 @ 40), (100 mW) + (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW + (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW + (5470 - 5725 @ 160), (500 mW), DFS + # 60 gHz band channels 1-4, ref: Etsi En 302 567 + (57000 - 66000 @ 2160), (40) + +# Data from "Frequenznutzungsplan" (as published in April 2008), downloaded from +#http://www.bundesnetzagentur.de/cae/servlet/contentblob/38448/publicationFile/2659/Frequenznutzungsplan2008_Id17448pdf.pdf +# For the 5GHz range also see +#http://www.bundesnetzagentur.de/cae/servlet/contentblob/38216/publicationFile/6579/WLAN5GHzVfg7_2010_28042010pdf.pdf +# The values have been reduced by a factor of 2 (3db) for non TPC devices +# (in other words: devices with TPC can use twice the tx power of this table). +# Note that the docs do not require TPC for 5150--5250; the reduction to +# 100mW thus is not strictly required -- however the conservative 100mW +# limit is used here as the non-interference with radar and satellite +# apps relies on the attenuation by the building walls only in the +# absence of DFS; the neighbour countries have 100mW limit here as well. + +country DE: DFS-ETSI + # entries 279004 and 280006 + (2400 - 2483.5 @ 40), (100 mW) + # entry 303005 + (5150 - 5250 @ 80), (100 mW), NO-OUTDOOR, AUTO-BW + # entries 304002 and 305002 + (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW + # entries 308002, 309001 and 310003 + (5470 - 5725 @ 160), (500 mW), DFS + # 60 gHz band channels 1-4, ref: Etsi En 302 567 + (57000 - 66000 @ 2160), (40) + +country DK: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + # 60 gHz band channels 1-4, ref: Etsi En 302 567 + (57000 - 66000 @ 2160), (40) + +# Source: +#http://www.ntrcdom.org/index.php?option=com_content&view=category&layout=blog&id=10&Itemid=55 +country DM: DFS-FCC + (2402 - 2472 @ 40), (30) + (5170 - 5250 @ 80), (17), AUTO-BW + (5250 - 5330 @ 80), (23), DFS, AUTO-BW + (5735 - 5835 @ 80), (30) + +country DO: DFS-FCC + (2402 - 2472 @ 40), (30) + (5170 - 5250 @ 80), (17), AUTO-BW + (5250 - 5330 @ 80), (23), DFS, AUTO-BW + (5735 - 5835 @ 80), (30) + +country DZ: DFS-JP + (2402 - 2482 @ 40), (20) + (5170.000 - 5250.000 @ 80.000), (23.00), AUTO-BW + (5250.000 - 5330.000 @ 80.000), (23.00), DFS, AUTO-BW + (5490.000 - 5670.000 @ 160.000), (23.00), DFS + +country EC: DFS-FCC + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (17) + (5250 - 5330 @ 80), (24), DFS + (5490 - 5730 @ 80), (24), DFS + (5735 - 5835 @ 80), (30) + +country EE: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + # 60 gHz band channels 1-4, ref: Etsi En 302 567 + (57000 - 66000 @ 2160), (40) + +country EG: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20) + (5250 - 5330 @ 80), (20), DFS + +# Orden IET/787/2013, de 25 de abril, por la que se aprueba +# el cuadro nacional de atribución de frecuencias. +#http://www.boe.es/diario_boe/txt.php?id=BOE-A-2013-4845 # -# This file is a placeholder to prevent accidental build breakage if someone -# enables CONFIG_CFG80211_INTERNAL_REGDB. Almost no one actually needs to -# enable that build option. -# -# You should be using CRDA instead. It is even better if you use the CRDA -# package provided by your distribution, since they will probably keep it -# up-to-date on your behalf. -# -# If you_really_ intend to use CONFIG_CFG80211_INTERNAL_REGDB then you will -# need to replace this file with one containing appropriately formatted -# regulatory rules that cover the regulatory domains you will be using. Your -# best option is to extract the db.txt file from the wireless-regdb git -# repository: -# -# git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-regdb.git -# +# more info at "Cuadro nacional de atribución de frecuencias (CNAF)": +#http://www.minetur.gob.es/telecomunicaciones/espectro/paginas/cnaf.aspx + +country ES: DFS-ETSI + (2400 - 2483.5 @ 40), (100 mW) + (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW + (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW + (5470 - 5725 @ 160), (500 mW), DFS + # 60 gHz band channels 1-4, ref: Etsi En 302 567 + (57000 - 66000 @ 2160), (40) + +country ET: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + +country FI: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + # 60 gHz band channels 1-4, ref: Etsi En 302 567 + (57000 - 66000 @ 2160), (40) + +country FM: DFS-FCC + (2402 - 2472 @ 40), (30) + (5170 - 5250 @ 80), (24), AUTO-BW + (5250 - 5330 @ 80), (24), DFS, AUTO-BW + (5490 - 5730 @ 160), (24), DFS + (5735 - 5835 @ 80), (30) + +country FR: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + # 60 gHz band channels 1-4, ref: Etsi En 302 567 + (57000 - 66000 @ 2160), (40) + +country GB: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + # 60 gHz band channels 1-4, ref: Etsi En 302 567 + (57000 - 66000 @ 2160), (40) + +country GD: DFS-FCC + (2402 - 2472 @ 40), (30) + (5170 - 5250 @ 80), (17), AUTO-BW + (5250 - 5330 @ 80), (24), DFS, AUTO-BW + (5490 - 5730 @ 160), (24), DFS + (5735 - 5835 @ 80), (30) + +country GE: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (18), AUTO-BW + (5250 - 5330 @ 80), (18), DFS, AUTO-BW + # 60 gHz band channels 1-4, ref: Etsi En 302 567 + (57000 - 66000 @ 2160), (40) + +country GF: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + +country GH: DFS-FCC + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (17), AUTO-BW + (5250 - 5330 @ 80), (24), DFS, AUTO-BW + (5490 - 5730 @ 160), (24), DFS + (5735 - 5835 @ 80), (30) + +country GL: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20) + (5250 - 5330 @ 80), (20), DFS + (5490 - 5710 @ 80), (27), DFS + +country GP: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + +country GR: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + # 60 gHz band channels 1-4, ref: Etsi En 302 567 + (57000 - 66000 @ 2160), (40) + +country GT: DFS-FCC + (2402 - 2472 @ 40), (30) + (5170 - 5250 @ 80), (17), AUTO-BW + (5250 - 5330 @ 80), (23), DFS, AUTO-BW + (5735 - 5835 @ 80), (30) + +country GU: DFS-FCC + (2402 - 2472 @ 40), (30) + (5170 - 5250 @ 80), (17) + (5250 - 5330 @ 80), (24), DFS + (5490 - 5730 @ 80), (24), DFS + (5735 - 5835 @ 80), (30) + +country GY: + (2402 - 2482 @ 40), (30) + (5735 - 5835 @ 80), (30) + +country HK: + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (17), AUTO-BW + (5250 - 5330 @ 80), (24), DFS, AUTO-BW + (5490 - 5710 @ 160), (24), DFS + (5735 - 5835 @ 80), (30) + +country HN: DFS-FCC + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (17), AUTO-BW + (5250 - 5330 @ 80), (24), DFS, AUTO-BW + (5490 - 5730 @ 160), (24), DFS + (5735 - 5835 @ 80), (30) + +country HR: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + # 60 gHz band channels 1-4, ref: Etsi En 302 567 + (57000 - 66000 @ 2160), (40) + +country HT: DFS-FCC + (2402 - 2472 @ 40), (30) + (5170 - 5250 @ 80), (24), AUTO-BW + (5250 - 5330 @ 80), (24), DFS, AUTO-BW + (5490 - 5730 @ 160), (24), DFS + (5735 - 5835 @ 80), (30) + +country HU: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + # 60 gHz band channels 1-4, ref: Etsi En 302 567 + (57000 - 66000 @ 2160), (40) + +country ID: DFS-JP + # ref:http://www.postel.go.id/content/ID/regulasi/standardisasi/kepdir/bwa%205,8%20ghz.pdf + (2402 - 2482 @ 40), (20) + (5735 - 5815 @ 80), (23) + +country IE: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + # 60 gHz band channels 1-4, ref: Etsi En 302 567 + (57000 - 66000 @ 2160), (40) + +country IL: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW + (5250 - 5350 @ 80), (200 mW), NO-OUTDOOR, DFS, AUTO-BW + +country IN: DFS-JP + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5735 - 5835 @ 80), (20) + +country IR: DFS-JP + (2402 - 2482 @ 40), (20) + (5735 - 5835 @ 80), (30) + +country IS: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + # 60 gHz band channels 1-4, ref: Etsi En 302 567 + (57000 - 66000 @ 2160), (40) + +country IT: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + # 60 gHz band channels 1-4, ref: Etsi En 302 567 + (57000 - 66000 @ 2160), (40) + +country JM: DFS-FCC + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (17), AUTO-BW + (5250 - 5330 @ 80), (24), DFS, AUTO-BW + (5490 - 5730 @ 160), (24), DFS + (5735 - 5835 @ 80), (30) + +country JO: DFS-JP + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (23) + (5735 - 5835 @ 80), (23) + +country JP: DFS-JP + (2402 - 2482 @ 40), (20) + (2474 - 2494 @ 20), (20), NO-OFDM + (4910 - 4990 @ 40), (23) + (5030 - 5090 @ 40), (23) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (23), DFS + +country KE: DFS-JP + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (23) + (5490 - 5570 @ 80), (30), DFS + (5735 - 5775 @ 40), (23) + +country KH: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + +# Source +#http://ntrc.kn/?page_id=7 +country KN: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (30), DFS + (5735 - 5815 @ 80), (30) + +country KP: DFS-JP + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5630 @ 80), (30), DFS + (5735 - 5815 @ 80), (30) + +country KR: DFS-JP + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (30), DFS + (5735 - 5835 @ 80), (30) + +country KW: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + +country KY: DFS-FCC + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (24), AUTO-BW + (5250 - 5330 @ 80), (24), DFS, AUTO-BW + (5490 - 5730 @ 160), (24), DFS + (5735 - 5835 @ 80), (30) + +country KZ: + (2402 - 2482 @ 40), (20) + +country LB: DFS-FCC + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (17), AUTO-BW + (5250 - 5330 @ 80), (24), DFS, AUTO-BW + (5490 - 5730 @ 160), (24), DFS + (5735 - 5835 @ 80), (30) + +# Source: +#http://www.ntrc.org.lc/operational_structures.htm +country LC: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (30), DFS + (5735 - 5815 @ 80), (30) + +country LI: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + +country LK: DFS-FCC + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (17) + (5250 - 5330 @ 80), (24), DFS + (5490 - 5730 @ 80), (24), DFS + (5735 - 5835 @ 80), (30) + +# Source: +#http://lca.org.ls/images/documents/lesotho_national_frequency_allocation_plan.pdf +country LS: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + +country LT: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + # 60 gHz band channels 1-4, ref: Etsi En 302 567 + (57000 - 66000 @ 2160), (40) + +country LU: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + # 60 gHz band channels 1-4, ref: Etsi En 302 567 + (57000 - 66000 @ 2160), (40) + +country LV: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + # 60 gHz band channels 1-4, ref: Etsi En 302 567 + (57000 - 66000 @ 2160), (40) + +country MA: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + +country MC: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + +# Source: +#http://www.cnfr.md/index.php?pag=sec&id=117&l=en +country MD: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + +# Source: +#http://www.cept.org/files/1050/Tools%20and%20Services/EFIS%20-%20ECO%20Frequency%20Information%20System/National%20frequency%20tables/Montenegro%20NAFT%20-%202010.pdf +country ME: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + +country MF: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + +country MH: DFS-FCC + (2402 - 2472 @ 40), (30) + (5170 - 5250 @ 80), (24), AUTO-BW + (5250 - 5330 @ 80), (24), DFS, AUTO-BW + (5490 - 5730 @ 160), (24), DFS + (5735 - 5835 @ 80), (30) + +country MK: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + # 60 gHz band channels 1-4, ref: Etsi En 302 567 + (57000 - 66000 @ 2160), (40) + +country MN: DFS-FCC + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (24), AUTO-BW + (5250 - 5330 @ 80), (24), DFS, AUTO-BW + (5490 - 5730 @ 160), (24), DFS + (5735 - 5835 @ 80), (30) + +country MO: + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 40), (23) + (5250 - 5330 @ 40), (23), DFS + (5735 - 5835 @ 40), (30) + +country MP: DFS-FCC + (2402 - 2472 @ 40), (30) + (5170 - 5250 @ 80), (24), AUTO-BW + (5250 - 5330 @ 80), (24), DFS, AUTO-BW + (5490 - 5730 @ 160), (24), DFS + (5735 - 5835 @ 80), (30) + +country MQ: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + +# Source: +#http://www.are.mr/pdfs/telec_freq_TNAbf_2010.pdf +country MR: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + +country MT: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + # 60 gHz band channels 1-4, ref: Etsi En 302 567 + (57000 - 66000 @ 2160), (40) + +country MU: DFS-FCC + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (24), AUTO-BW + (5250 - 5330 @ 80), (24), DFS, AUTO-BW + (5490 - 5730 @ 160), (24), DFS + (5735 - 5835 @ 80), (30) + +country MW: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + +country MX: DFS-FCC + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (17), AUTO-BW + (5250 - 5330 @ 80), (24), DFS, AUTO-BW + (5490 - 5730 @ 160), (24), DFS + (5735 - 5835 @ 80), (30) + +country MY: DFS-FCC + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (17), AUTO-BW + (5250 - 5330 @ 80), (23), DFS, AUTO-BW + (5735 - 5835 @ 80), (30) + +country NI: DFS-FCC + (2402 - 2472 @ 40), (30) + (5170 - 5250 @ 80), (24), AUTO-BW + (5250 - 5330 @ 80), (24), DFS, AUTO-BW + (5490 - 5730 @ 160), (24), DFS + (5735 - 5835 @ 80), (30) + +country NL: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), NO-OUTDOOR, AUTO-BW + (5250 - 5330 @ 80), (20), NO-OUTDOOR, DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + # 60 gHz band channels 1-4, ref: Etsi En 302 567 + (57000 - 66000 @ 2160), (40) + +# Data fromhttp://www.lovdata.no/dokument/SF/forskrift/2012-01-19-77 +# Power at 5250 - 5350 MHz, 5470 - 5725 MHz and 5815 – 5850 MHz can +# be doubled if TPC is implemented. +# Up to 2W (or 4W with TPC) is allowed in the 5725 – 5795 MHz band +# which has been merged with 5470 - 5725 MHz to allow wide channels +country NO: DFS-ETSI + (2400 - 2483.5 @ 40), (100 mW) + (5150 - 5250 @ 80), (200 mW), AUTO-BW + (5250 - 5350 @ 80), (100 mW), DFS, AUTO-BW + (5470 - 5795 @ 160), (500 mW), DFS + (5815 - 5850 @ 35), (2000 mW), DFS + (17100 - 17300 @ 200), (100 mW) + # 60 gHz band channels 1-4, ref: Etsi En 302 567 + (57000 - 66000 @ 2160), (40) + +country NP: DFS-JP + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5735 - 5835 @ 80), (20) + +country NZ: DFS-FCC + (2402 - 2482 @ 40), (30) + (5170 - 5250 @ 80), (17), AUTO-BW + (5250 - 5330 @ 80), (24), DFS, AUTO-BW + (5490 - 5730 @ 160), (24), DFS + (5735 - 5835 @ 80), (30) + +country OM: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + +country PA: DFS-FCC + (2402 - 2472 @ 40), (30) + (5170 - 5250 @ 80), (17), AUTO-BW + (5250 - 5330 @ 80), (23), DFS, AUTO-BW + (5735 - 5835 @ 80), (30) + +country PE: DFS-FCC + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (17), AUTO-BW + (5250 - 5330 @ 80), (24), DFS, AUTO-BW + (5490 - 5730 @ 160), (24), DFS + (5735 - 5835 @ 80), (30) + +country PF: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + +country PG: DFS-FCC + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (17), AUTO-BW + (5250 - 5330 @ 80), (24), DFS, AUTO-BW + (5490 - 5730 @ 160), (24), DFS + (5735 - 5835 @ 80), (30) + +country PH: DFS-FCC + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (17), AUTO-BW + (5250 - 5330 @ 80), (24), DFS, AUTO-BW + (5490 - 5730 @ 160), (24), DFS + (5735 - 5835 @ 80), (30) + +country PK: DFS-JP + (2402 - 2482 @ 40), (20) + (5735 - 5835 @ 80), (30) + +country PL: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + # 60 gHz band channels 1-4, ref: Etsi En 302 567 + (57000 - 66000 @ 2160), (40) + +country PM: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + +country PR: DFS-FCC + (2402 - 2472 @ 40), (30) + (5170 - 5250 @ 80), (17), AUTO-BW + (5250 - 5330 @ 80), (24), DFS, AUTO-BW + (5490 - 5730 @ 160), (24), DFS + (5735 - 5835 @ 80), (30) + +country PT: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + # 60 gHz band channels 1-4, ref: Etsi En 302 567 + (57000 - 66000 @ 2160), (40) + +country PW: DFS-FCC + (2402 - 2472 @ 40), (30) + (5170 - 5250 @ 80), (24), AUTO-BW + (5250 - 5330 @ 80), (24), DFS, AUTO-BW + (5490 - 5730 @ 160), (24), DFS + (5735 - 5835 @ 80), (30) + +country PY: DFS-FCC + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (24), AUTO-BW + (5250 - 5330 @ 80), (24), DFS, AUTO-BW + (5490 - 5730 @ 160), (24), DFS + (5735 - 5835 @ 80), (30) + +country QA: DFS-JP + (2402 - 2482 @ 40), (20) + (5735 - 5835 @ 80), (30) + +country RE: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + +country RO: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + # 60 gHz band channels 1-4, ref: Etsi En 302 567 + (57000 - 66000 @ 2160), (40) + + +# Source: +#http://www.ratel.rs/upload/documents/Plan_namene/Plan_namene-sl_glasnik.pdf +country RS: DFS-ETSI + (2400 - 2483.5 @ 40), (100 mW) + (5150 - 5350 @ 40), (200 mW), NO-OUTDOOR + (5470 - 5725 @ 20), (1000 mW), DFS + # 60 gHz band channels 1-4, ref: Etsi En 302 567 + (57000 - 66000 @ 2160), (40) + +country RU: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20) + (5250 - 5330 @ 80), (20), DFS + (5650 - 5730 @ 80), (30), DFS + (5735 - 5835 @ 80), (30) + +country RW: DFS-FCC + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (17), AUTO-BW + (5250 - 5330 @ 80), (24), DFS, AUTO-BW + (5490 - 5730 @ 160), (24), DFS + (5735 - 5835 @ 80), (30) + +country SA: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + +country SE: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + # 60 gHz band channels 1-4, ref: Etsi En 302 567 + (57000 - 66000 @ 2160), (40) + +country SG: DFS-FCC + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (17), AUTO-BW + (5250 - 5330 @ 80), (24), DFS, AUTO-BW + (5490 - 5730 @ 160), (24), DFS + (5735 - 5835 @ 80), (30) + +country SI: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + # 60 gHz band channels 1-4, ref: Etsi En 302 567 + (57000 - 66000 @ 2160), (40) + +country SK: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + # 60 gHz band channels 1-4, ref: Etsi En 302 567 + (57000 - 66000 @ 2160), (40) + +# Source: +# Regulation N° 2004-005 ART/DG/DRC/D.Rég +country SN: DFS-FCC + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (17), AUTO-BW + (5250 - 5330 @ 80), (24), DFS, AUTO-BW + (5490 - 5730 @ 160), (24), DFS + (5735 - 5835 @ 80), (30) + +country SR: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + +country SV: DFS-FCC + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (17) + (5250 - 5330 @ 80), (23), DFS + (5735 - 5835 @ 80), (30) + +country SY: + (2402 - 2482 @ 40), (20) + +# Source: +#http://www.telecommission.tc/Spectrum-plan20110324-101210.html +country TC: DFS-FCC + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (24), AUTO-BW + (5250 - 5330 @ 80), (24), DFS, AUTO-BW + (5490 - 5730 @ 160), (24), DFS + (5735 - 5835 @ 80), (30) + +country TD: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + +country TG: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 40), (20) + (5250 - 5330 @ 40), (20), DFS + (5490 - 5710 @ 40), (27), DFS + +country TH: DFS-FCC + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (17), AUTO-BW + (5250 - 5330 @ 80), (24), DFS, AUTO-BW + (5490 - 5730 @ 160), (24), DFS + (5735 - 5835 @ 80), (30) + +country TN: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + +country TR: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + # 60 gHz band channels 1-4, ref: Etsi En 302 567 + (57000 - 66000 @ 2160), (40) + +country TT: DFS-FCC + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (17), AUTO-BW + (5250 - 5330 @ 80), (24), DFS, AUTO-BW + (5490 - 5730 @ 160), (24), DFS + (5735 - 5835 @ 80), (30) + +country TW: DFS-JP + (2402 - 2472 @ 40), (30) + (5270 - 5330 @ 40), (17), DFS + (5490 - 5590 @ 80), (30), DFS + (5650 - 5710 @ 40), (30), DFS + (5735 - 5835 @ 80), (30) + +# Source: +# #914 / 06 Sep 2007:http://www.ucrf.gov.ua/uk/doc/nkrz/1196068874 +# #1174 / 23 Oct 2008:http://www.nkrz.gov.ua/uk/activities/ruling/1225269361 +# (appendix 8) +# Listed 5GHz range is a lowest common denominator for all related +# rules in the referenced laws. Such a range is used because of +# disputable definitions there. +country UA: DFS-ETSI + (2400 - 2483.5 @ 40), (20), NO-OUTDOOR + (5150 - 5350 @ 40), (20), NO-OUTDOOR + (5490 - 5670 @ 80), (20), DFS + (5735 - 5835 @ 80), (20) + # 60 gHz band channels 1-4, ref: Etsi En 302 567 + (57000 - 66000 @ 2160), (40) + +country UG: DFS-FCC + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (24), AUTO-BW + (5250 - 5330 @ 80), (24), DFS, AUTO-BW + (5490 - 5730 @ 160), (24), DFS + (5735 - 5835 @ 80), (30) + +country US: DFS-FCC + (2402 - 2472 @ 40), (30) + (5170 - 5250 @ 80), (17), AUTO-BW + (5250 - 5330 @ 80), (23), DFS, AUTO-BW + (5490 - 5710 @ 20), (30) + (5735 - 5835 @ 80), (30) + (5850 - 5935 @ 10), (30) + # 60g band + # reference:http://cfr.regstoday.com/47cfr15.aspx#47_CFR_15p255 + # channels 1,2,3, EIRP=40dBm(43dBm peak) + (57240 - 63720 @ 2160), (40) + +country UY: DFS-FCC + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (17), AUTO-BW + (5250 - 5330 @ 80), (24), DFS, AUTO-BW + (5490 - 5730 @ 160), (24), DFS + (5735 - 5835 @ 80), (30) + +# Source: +#http://cemc.uz/article/1976/ +country UZ: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + +# Source: +#http://www.ntrc.vc/regulations/Jun_2006_Spectrum_Managment_Regulations.pdf +country VC: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + +# Source: +# Official Gazette (Gaceta Oficial) concerning Unlicensed transmitter use +# (10 June 2013) +#http://www.conatel.gob.ve/ +country VE: DFS-FCC + (2402 - 2482 @ 40), (30) + (5170 - 5250 @ 80), (23), AUTO-BW + (5250 - 5330 @ 80), (23), DFS, AUTO-BW + (5735 - 5835 @ 80), (30) + +country VI: DFS-FCC + (2402 - 2472 @ 40), (30) + (5170 - 5250 @ 80), (24), AUTO-BW + (5250 - 5330 @ 80), (24), DFS, AUTO-BW + (5490 - 5730 @ 160), (24), DFS + (5735 - 5835 @ 80), (30) + +country VN: DFS-FCC + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (17) + (5250 - 5330 @ 80), (24), DFS + (5490 - 5730 @ 80), (24), DFS + (5735 - 5835 @ 80), (30) + +# Source: +#http://www.trr.vu/attachments/category/130/GURL_for_Short-range_Radiocommunication_Devices2.pdf +country VU: DFS-FCC + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (17), AUTO-BW + (5250 - 5330 @ 80), (24), DFS, AUTO-BW + (5490 - 5730 @ 160), (24), DFS + (5735 - 5835 @ 80), (30) + +country WF: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + +country YE: + (2402 - 2482 @ 40), (20) + +country YT: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + +country ZA: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + +country ZW: DFS-ETSI + (2402 - 2482 @ 40), (20) + (5170 - 5250 @ 80), (20), AUTO-BW + (5250 - 5330 @ 80), (20), DFS, AUTO-BW + (5490 - 5710 @ 160), (27), DFS + + Only in linux-4.9.61-pat/scripts/basic: .fixdep.cmd Only in linux-4.9.61-pat/scripts/basic: fixdep Only in linux-4.9.61-pat/scripts/kconfig: .conf.cmd Only in linux-4.9.61-pat/scripts/kconfig: .conf.o.cmd Only in linux-4.9.61-pat/scripts/kconfig: .mconf.cmd Only in linux-4.9.61-pat/scripts/kconfig: .mconf.o.cmd Only in linux-4.9.61-pat/scripts/kconfig: .zconf.tab.o.cmd Only in linux-4.9.61-pat/scripts/kconfig: conf Only in linux-4.9.61-pat/scripts/kconfig: conf.o Only in linux-4.9.61-pat/scripts/kconfig/lxdialog: .checklist.o.cmd Only in linux-4.9.61-pat/scripts/kconfig/lxdialog: .inputbox.o.cmd Only in linux-4.9.61-pat/scripts/kconfig/lxdialog: .menubox.o.cmd Only in linux-4.9.61-pat/scripts/kconfig/lxdialog: .textbox.o.cmd Only in linux-4.9.61-pat/scripts/kconfig/lxdialog: .util.o.cmd Only in linux-4.9.61-pat/scripts/kconfig/lxdialog: .yesno.o.cmd Only in linux-4.9.61-pat/scripts/kconfig/lxdialog: checklist.o Only in linux-4.9.61-pat/scripts/kconfig/lxdialog: inputbox.o Only in linux-4.9.61-pat/scripts/kconfig/lxdialog: menubox.o Only in linux-4.9.61-pat/scripts/kconfig/lxdialog: textbox.o Only in linux-4.9.61-pat/scripts/kconfig/lxdialog: util.o Only in linux-4.9.61-pat/scripts/kconfig/lxdialog: yesno.o Only in linux-4.9.61-pat/scripts/kconfig: mconf Only in linux-4.9.61-pat/scripts/kconfig: mconf.o Only in linux-4.9.61-pat/scripts/kconfig: zconf.hash.c Only in linux-4.9.61-pat/scripts/kconfig: zconf.lex.c Only in linux-4.9.61-pat/scripts/kconfig: zconf.tab.c Only in linux-4.9.61-pat/scripts/kconfig: zconf.tab.o --------------A29038F9C1F1B6C89649F1CA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi IPWAVErs,

The IPv6-over-OCB draft is implemented in many places.

An OCB patch existed for the linux kernel since 6 years, maintained privately and publicly by a few people on the Internet.  It has been integrated in the mainline in the recent years.  Still, a few simple operations are necessary, see the patch posted below.

In addition, there are few packet dumps of IP packets on OCB and together with CAM, that are available upon request.  They are generated by us and YoGoKo.  A few other companies have such traces.

With this patch applied, one can do one's own packet traces of IP packets on OCB, with Wireshark.

Alex

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

- download the linux kernel linux-4.9.61.
- copy the patch file inside the linux folder
- cd into the linux folder
- make menuconfig and check:
        > Networking support > Wireless ->  cfg80211 - wireless configuration API
        > Networking support > Wireless ->  use statically compiled regulatory rules database
        > Networking support > Wireless -> support CRDA
        > Networking support > Wireless -> Generic IEEE 802.11 Networking Stack (mac80211)
        > Device Drivers > Network device support -> Wireless LAN -> Atheros 802.11n wireless cards support
        > Device Drivers > Network device support -> Wireless LAN -> Atheros ath9k PCI/PCIe bus support
- Patch the kernel using the command "patch -p1 < patch.file"
- and make the kernel

- install iw 4.9
- iw dev wlan0 set type ocb
- ifconfig wlan0 up
- iw dev wlan0 ocb join 5900 10MHz

When we boot the board our country code is US. If for you it is different you can change the country with the "iw reg set" command.
This is important in order to define which channels are available.

This patch file was created with inspiration from somebody else from the Internet who used python to achieve the same, but which is hard to do on small platforms.

Date: 27 February 2018
Based on: https://drive.google.com/file/d/0BxK6WTQZ97QVWF9tRURjOGhBU2c/view; and other online resources
diff -ur linux-4.9.61/drivers/net/wireless/ath/ath9k/common-init.c linux-4.9.61-pat/drivers/net/wireless/ath/ath9k/common-init.c
--- linux-4.9.61/drivers/net/wireless/ath/ath9k/common-init.c	2017-11-08 03:08:37.000000000 -0600
+++ linux-4.9.61-pat/drivers/net/wireless/ath/ath9k/common-init.c	2017-11-17 04:33:50.168704602 -0600
@@ -86,6 +86,27 @@
 	CHAN5G(5785, 35), /* Channel 157 */
 	CHAN5G(5805, 36), /* Channel 161 */
 	CHAN5G(5825, 37), /* Channel 165 */
+
+	CHAN5G(5850, 38), /* Channel 170 */
+        /* ITA-G5B */
+        CHAN5G(5855, 39), /* Channel 171 */
+        CHAN5G(5860, 40), /* Channel 172 */
+        CHAN5G(5865, 41), /* Channel 173 */
+        CHAN5G(5870, 42), /* Channel 174 */
+        /* ITS-G5A */
+        CHAN5G(5875, 43), /* Channel 175 */
+        CHAN5G(5880, 44), /* Channel 176 */
+        CHAN5G(5885, 45), /* Channel 177 */
+        CHAN5G(5890, 46), /* Channel 178 */
+        CHAN5G(5895, 47), /* Channel 179 */
+        CHAN5G(5900, 48), /* Channel 180 */
+        CHAN5G(5905, 49), /* Channel 181 */
+        /* ITS-G5D */
+        CHAN5G(5910, 50), /* Channel 182 */
+        CHAN5G(5915, 51), /* Channel 183 */
+        CHAN5G(5920, 52), /* Channel 184 */
+        CHAN5G(5925, 53), /* Channel 185 */
+
 };
 
 /* Atheros hardware rate code addition for short premble */
diff -ur linux-4.9.61/drivers/net/wireless/ath/ath9k/hw.h linux-4.9.61-pat/drivers/net/wireless/ath/ath9k/hw.h
--- linux-4.9.61/drivers/net/wireless/ath/ath9k/hw.h	2017-11-08 03:08:37.000000000 -0600
+++ linux-4.9.61-pat/drivers/net/wireless/ath/ath9k/hw.h	2017-11-17 04:34:18.781260652 -0600
@@ -73,7 +73,7 @@
 
 #define ATH9K_RSSI_BAD			-128
 
-#define ATH9K_NUM_CHANNELS	38
+#define ATH9K_NUM_CHANNELS	54
 
 /* Register read/write primitives */
 #define REG_WRITE(_ah, _reg, _val) \
diff -ur linux-4.9.61/drivers/net/wireless/ath/regd.c linux-4.9.61-pat/drivers/net/wireless/ath/regd.c
--- linux-4.9.61/drivers/net/wireless/ath/regd.c	2017-11-08 03:08:37.000000000 -0600
+++ linux-4.9.61-pat/drivers/net/wireless/ath/regd.c	2017-11-17 04:37:11.684613511 -0600
@@ -45,9 +45,9 @@
 /* We allow IBSS on these on a case by case basis by regulatory domain */
 #define ATH9K_5GHZ_5150_5350	REG_RULE(5150-10, 5350+10, 80, 0, 30,\
 					 NL80211_RRF_NO_IR)
-#define ATH9K_5GHZ_5470_5850	REG_RULE(5470-10, 5850+10, 80, 0, 30,\
+#define ATH9K_5GHZ_5470_5925	REG_RULE(5470-10, 5925+10, 80, 0, 30,\
 					 NL80211_RRF_NO_IR)
-#define ATH9K_5GHZ_5725_5850	REG_RULE(5725-10, 5850+10, 80, 0, 30,\
+#define ATH9K_5GHZ_5725_5925	REG_RULE(5725-10, 5925+10, 80, 0, 30,\
 					 NL80211_RRF_NO_IR)
 
 #define ATH9K_2GHZ_ALL		ATH9K_2GHZ_CH01_11, \
@@ -55,11 +55,11 @@
 				ATH9K_2GHZ_CH14
 
 #define ATH9K_5GHZ_ALL		ATH9K_5GHZ_5150_5350, \
-				ATH9K_5GHZ_5470_5850
+				ATH9K_5GHZ_5470_5925
 
 /* This one skips what we call "mid band" */
 #define ATH9K_5GHZ_NO_MIDBAND	ATH9K_5GHZ_5150_5350, \
-				ATH9K_5GHZ_5725_5850
+				ATH9K_5GHZ_5725_5925
 
 /* Can be used for:
  * 0x60, 0x61, 0x62 */
Only in linux-4.9.61-pat/include: config
Only in linux-4.9.61-pat/include: generated
diff -ur linux-4.9.61/net/wireless/db.txt linux-4.9.61-pat/net/wireless/db.txt
--- linux-4.9.61/net/wireless/db.txt	2017-11-08 03:08:37.000000000 -0600
+++ linux-4.9.61-pat/net/wireless/db.txt	2017-11-17 04:38:44.958417939 -0600
@@ -1,17 +1,1220 @@
+# This is the world regulatory domain
+country 00:
+	(2402 - 2472 @ 40), (20)
+	# Channel 12 - 13.
+	(2457 - 2482 @ 40), (20), NO-IR
+	# Channel 14. Only JP enables this and for 802.11b only
+	(2474 - 2494 @ 20), (20), NO-IR, NO-OFDM
+	# Channel 36 - 48
+	(5170 - 5250 @ 80), (20), NO-IR, AUTO-BW
+	# Channel 52 - 64
+	(5250 - 5330 @ 80), (20), NO-IR, DFS, AUTO-BW
+	# Channel 100 - 144
+	(5490 - 5730 @ 160), (20), NO-IR, DFS
+	# Channel 149 - 165
+	(5735 - 5835 @ 80), (20), NO-IR
+	# IEEE 802.11ad (60GHz), channels 1..3
+	(57240 - 63720 @ 2160), (0)
+	
+	#channel 172 184	
+	(5860 - 5920 @ 80), (10), NO-IR
+
+country AD:
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20)
+	(5250 - 5330 @ 80), (20), DFS
+	(5490 - 5710 @ 80), (27), DFS
+	# 60 gHz band channels 1-4, ref: Etsi En 302 567
+	(57000 - 66000 @ 2160), (40)
+
+country AE: DFS-FCC
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (17), AUTO-BW
+	(5250 - 5330 @ 80), (24), DFS, AUTO-BW
+	(5490 - 5730 @ 160), (24), DFS
+	(5735 - 5835 @ 80), (30)
+
+country AF: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+
+# Source:
+# http://pucanguilla.org/Downloads/January2005-Anguilla%20Table%20of%20Allocations.pdf
+country AI: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+
+country AL: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20.00), AUTO-BW
+	(5250 - 5330 @ 80), (20.00), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27.00), DFS
+
+country AM: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (18)
+	(5250 - 5330 @ 80), (18), DFS
+
+country AN: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+
+country AR: DFS-FCC
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (17), AUTO-BW
+	(5250 - 5330 @ 80), (24), DFS, AUTO-BW
+	(5490 - 5730 @ 160), (24), DFS
+	(5735 - 5835 @ 80), (30)
+
+country AS: DFS-FCC
+	(2402 - 2472 @ 40), (30)
+	(5170 - 5250 @ 80), (24), AUTO-BW
+	(5250 - 5330 @ 80), (24), DFS, AUTO-BW
+	(5490 - 5730 @ 160), (24), DFS
+	(5735 - 5835 @ 80), (30)
+
+country AT: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+	# 60 gHz band channels 1-4, ref: Etsi En 302 567
+	(57000 - 66000 @ 2160), (40)
+
+country AU:
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (17), AUTO-BW
+	(5250 - 5330 @ 80), (24), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (24), DFS
+	(5735 - 5835 @ 80), (30)
+
+country AW: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+
+country AZ: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (18), AUTO-BW
+	(5250 - 5330 @ 80), (18), DFS, AUTO-BW
+
+country BA: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+	# 60 gHz band channels 1-4, ref: Etsi En 302 567
+	(57000 - 66000 @ 2160), (40)
+
+country BB: DFS-FCC
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (23), AUTO-BW
+	(5250 - 5330 @ 80), (23), DFS, AUTO-BW
+	(5735 - 5835 @ 80), (30)
+
+country BD: DFS-JP
+	(2402 - 2482 @ 40), (20)
+	(5735 - 5835 @ 80), (30)
+
+country BE: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+	# 60 gHz band channels 1-4, ref: Etsi En 302 567
+	(57000 - 66000 @ 2160), (40)
+
+country BF: DFS-FCC
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (17), AUTO-BW
+	(5250 - 5330 @ 80), (24), DFS, AUTO-BW
+	(5490 - 5730 @ 160), (24), DFS
+	(5735 - 5835 @ 80), (30)
+
+country BG: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+	# 60 gHz band channels 1-4, ref: Etsi En 302 567
+	(57000 - 66000 @ 2160), (40)
+
+country BH: DFS-JP
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20)
+	(5250 - 5330 @ 80), (20), DFS
+	(5735 - 5835 @ 80), (20)
+
+country BL: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+
+country BM: DFS-FCC
+	(2402 - 2472 @ 40), (30)
+	(5170 - 5250 @ 80), (24), AUTO-BW
+	(5250 - 5330 @ 80), (24), DFS, AUTO-BW
+	(5490 - 5730 @ 160), (24), DFS
+	(5735 - 5835 @ 80), (30)
+
+country BN: DFS-JP
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5735 - 5835 @ 80), (20)
+
+country BO: DFS-JP
+	(2402 - 2482 @ 40), (20)
+	(5250 - 5330 @ 80), (30), DFS
+	(5735 - 5835 @ 80), (30)
+
+country BR: DFS-FCC
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (17), AUTO-BW
+	(5250 - 5330 @ 80), (24), DFS, AUTO-BW
+	(5490 - 5730 @ 160), (24), DFS
+	(5735 - 5835 @ 80), (30)
+
+country BS: DFS-FCC
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (24), AUTO-BW
+	(5250 - 5330 @ 80), (24), DFS, AUTO-BW
+	(5490 - 5730 @ 160), (24), DFS
+	(5735 - 5835 @ 80), (30)
+
+# Source:
+# http://www.bicma.gov.bt/paper/publication/nrrpart4.pdf
+country BT: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+
+country BY: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+
+country BZ: DFS-JP
+	(2402 - 2482 @ 40), (30)
+	(5735 - 5835 @ 80), (30)
+
+country CA: DFS-FCC
+	(2402 - 2472 @ 40), (30)
+	(5170 - 5250 @ 80), (17), AUTO-BW
+	(5250 - 5330 @ 80), (24), DFS, AUTO-BW
+	(5490 - 5730 @ 160), (24), DFS
+	(5735 - 5835 @ 80), (30)
+
+# Source:
+# http://www.art-rca.org
+country CF: DFS-FCC
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 40), (17)
+	(5250 - 5330 @ 40), (24), DFS
+	(5490 - 5730 @ 40), (24), DFS
+	(5735 - 5835 @ 40), (30)
+
+country CH: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+	# 60 gHz band channels 1-4, ref: Etsi En 302 567
+	(57000 - 66000 @ 2160), (40)
+
+country CI: DFS-FCC
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (17), AUTO-BW
+	(5250 - 5330 @ 80), (24), DFS, AUTO-BW
+	(5490 - 5730 @ 160), (24), DFS
+	(5735 - 5835 @ 80), (30)
+
+country CL: DFS-JP
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5735 - 5835 @ 80), (20)
+
+country CN: DFS-FCC
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (23), AUTO-BW
+	(5250 - 5330 @ 80), (23), DFS, AUTO-BW
+	(5735 - 5835 @ 80), (30)
+	# 60 gHz band channels 1,4: 28dBm, channels 2,3: 44dBm
+	# ref: http://www.miit.gov.cn/n11293472/n11505629/n11506593/n11960250/n11960606/n11960700/n12330791.files/n12330790.pdf
+	(57240 - 59400 @ 2160), (28)
+	(59400 - 63720 @ 2160), (44)
+	(63720 - 65880 @ 2160), (28)
+
+country CO: DFS-FCC
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (17), AUTO-BW
+	(5250 - 5330 @ 80), (24), DFS, AUTO-BW
+	(5490 - 5730 @ 160), (24), DFS
+	(5735 - 5835 @ 80), (30)
+
+country CR: DFS-FCC
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (17)
+	(5250 - 5330 @ 80), (24), DFS
+	(5490 - 5730 @ 80), (24), DFS
+	(5735 - 5835 @ 80), (30)
+
+country CX: DFS-FCC
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (24), AUTO-BW
+	(5250 - 5330 @ 80), (24), DFS, AUTO-BW
+	(5490 - 5730 @ 160), (24), DFS
+	(5735 - 5835 @ 80), (30)
+
+country CY: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+	# 60 gHz band channels 1-4, ref: Etsi En 302 567
+	(57000 - 66000 @ 2160), (40)
+
+# Data from http://www.ctu.eu/164/download/VOR/VOR-12-08-2005-34.pdf
+# and http://www.ctu.eu/164/download/VOR/VOR-12-05-2007-6-AN.pdf
+# Power at 5250 - 5350 MHz and 5470 - 5725 MHz can be doubled if TPC is
+# implemented.
+country CZ: DFS-ETSI
+	(2400 - 2483.5 @ 40), (100 mW)
+	(5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW
+	(5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW
+	(5470 - 5725 @ 160), (500 mW), DFS
+	# 60 gHz band channels 1-4, ref: Etsi En 302 567
+	(57000 - 66000 @ 2160), (40)
+
+# Data from "Frequenznutzungsplan" (as published in April 2008), downloaded from
+# http://www.bundesnetzagentur.de/cae/servlet/contentblob/38448/publicationFile/2659/Frequenznutzungsplan2008_Id17448pdf.pdf
+# For the 5GHz range also see
+# http://www.bundesnetzagentur.de/cae/servlet/contentblob/38216/publicationFile/6579/WLAN5GHzVfg7_2010_28042010pdf.pdf
+# The values have been reduced by a factor of 2 (3db) for non TPC devices
+# (in other words: devices with TPC can use twice the tx power of this table).
+# Note that the docs do not require TPC for 5150--5250; the reduction to
+# 100mW thus is not strictly required -- however the conservative 100mW
+# limit is used here as the non-interference with radar and satellite
+# apps relies on the attenuation by the building walls only in the
+# absence of DFS; the neighbour countries have 100mW limit here as well.
+
+country DE: DFS-ETSI
+	# entries 279004 and 280006
+	(2400 - 2483.5 @ 40), (100 mW)
+	# entry 303005
+	(5150 - 5250 @ 80), (100 mW), NO-OUTDOOR, AUTO-BW
+	# entries 304002 and 305002
+	(5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW
+	# entries 308002, 309001 and 310003
+	(5470 - 5725 @ 160), (500 mW), DFS
+	# 60 gHz band channels 1-4, ref: Etsi En 302 567
+	(57000 - 66000 @ 2160), (40)
+
+country DK: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+	# 60 gHz band channels 1-4, ref: Etsi En 302 567
+	(57000 - 66000 @ 2160), (40)
+
+# Source:
+# http://www.ntrcdom.org/index.php?option=com_content&view=category&layout=blog&id=10&Itemid=55
+country DM: DFS-FCC
+	(2402 - 2472 @ 40), (30)
+	(5170 - 5250 @ 80), (17), AUTO-BW
+	(5250 - 5330 @ 80), (23), DFS, AUTO-BW
+	(5735 - 5835 @ 80), (30)
+
+country DO: DFS-FCC
+	(2402 - 2472 @ 40), (30)
+	(5170 - 5250 @ 80), (17), AUTO-BW
+	(5250 - 5330 @ 80), (23), DFS, AUTO-BW
+	(5735 - 5835 @ 80), (30)
+
+country DZ: DFS-JP
+	(2402 - 2482 @ 40), (20)
+	(5170.000 - 5250.000 @ 80.000), (23.00), AUTO-BW
+	(5250.000 - 5330.000 @ 80.000), (23.00), DFS, AUTO-BW
+	(5490.000 - 5670.000 @ 160.000), (23.00), DFS
+
+country EC: DFS-FCC
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (17)
+	(5250 - 5330 @ 80), (24), DFS
+	(5490 - 5730 @ 80), (24), DFS
+	(5735 - 5835 @ 80), (30)
+
+country EE: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+	# 60 gHz band channels 1-4, ref: Etsi En 302 567
+	(57000 - 66000 @ 2160), (40)
+
+country EG: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20)
+	(5250 - 5330 @ 80), (20), DFS
+
+# Orden IET/787/2013, de 25 de abril, por la que se aprueba
+# el cuadro nacional de atribución de frecuencias.
+# http://www.boe.es/diario_boe/txt.php?id=BOE-A-2013-4845
 #
-# This file is a placeholder to prevent accidental build breakage if someone
-# enables CONFIG_CFG80211_INTERNAL_REGDB.  Almost no one actually needs to
-# enable that build option.
-#
-# You should be using CRDA instead.  It is even better if you use the CRDA
-# package provided by your distribution, since they will probably keep it
-# up-to-date on your behalf.
-#
-# If you _really_ intend to use CONFIG_CFG80211_INTERNAL_REGDB then you will
-# need to replace this file with one containing appropriately formatted
-# regulatory rules that cover the regulatory domains you will be using.  Your
-# best option is to extract the db.txt file from the wireless-regdb git
-# repository:
-#
-#   git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-regdb.git
-#
+# more info at "Cuadro nacional de atribución de frecuencias (CNAF)":
+# http://www.minetur.gob.es/telecomunicaciones/espectro/paginas/cnaf.aspx
+
+country ES: DFS-ETSI
+	(2400 - 2483.5 @ 40), (100 mW)
+	(5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW
+	(5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW
+	(5470 - 5725 @ 160), (500 mW), DFS
+	# 60 gHz band channels 1-4, ref: Etsi En 302 567
+	(57000 - 66000 @ 2160), (40)
+
+country ET: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+
+country FI: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+	# 60 gHz band channels 1-4, ref: Etsi En 302 567
+	(57000 - 66000 @ 2160), (40)
+
+country FM: DFS-FCC
+	(2402 - 2472 @ 40), (30)
+	(5170 - 5250 @ 80), (24), AUTO-BW
+	(5250 - 5330 @ 80), (24), DFS, AUTO-BW
+	(5490 - 5730 @ 160), (24), DFS
+	(5735 - 5835 @ 80), (30)
+
+country FR: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+	# 60 gHz band channels 1-4, ref: Etsi En 302 567
+	(57000 - 66000 @ 2160), (40)
+
+country GB: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+	# 60 gHz band channels 1-4, ref: Etsi En 302 567
+	(57000 - 66000 @ 2160), (40)
+
+country GD: DFS-FCC
+	(2402 - 2472 @ 40), (30)
+	(5170 - 5250 @ 80), (17), AUTO-BW
+	(5250 - 5330 @ 80), (24), DFS, AUTO-BW
+	(5490 - 5730 @ 160), (24), DFS
+	(5735 - 5835 @ 80), (30)
+
+country GE: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (18), AUTO-BW
+	(5250 - 5330 @ 80), (18), DFS, AUTO-BW
+	# 60 gHz band channels 1-4, ref: Etsi En 302 567
+	(57000 - 66000 @ 2160), (40)
+
+country GF: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+
+country GH: DFS-FCC
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (17), AUTO-BW
+	(5250 - 5330 @ 80), (24), DFS, AUTO-BW
+	(5490 - 5730 @ 160), (24), DFS
+	(5735 - 5835 @ 80), (30)
+
+country GL: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20)
+	(5250 - 5330 @ 80), (20), DFS
+	(5490 - 5710 @ 80), (27), DFS
+
+country GP: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+
+country GR: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+	# 60 gHz band channels 1-4, ref: Etsi En 302 567
+	(57000 - 66000 @ 2160), (40)
+
+country GT: DFS-FCC
+	(2402 - 2472 @ 40), (30)
+	(5170 - 5250 @ 80), (17), AUTO-BW
+	(5250 - 5330 @ 80), (23), DFS, AUTO-BW
+	(5735 - 5835 @ 80), (30)
+
+country GU: DFS-FCC
+	(2402 - 2472 @ 40), (30)
+	(5170 - 5250 @ 80), (17)
+	(5250 - 5330 @ 80), (24), DFS
+	(5490 - 5730 @ 80), (24), DFS
+	(5735 - 5835 @ 80), (30)
+
+country GY:
+	(2402 - 2482 @ 40), (30)
+	(5735 - 5835 @ 80), (30)
+
+country HK:
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (17), AUTO-BW
+	(5250 - 5330 @ 80), (24), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (24), DFS
+	(5735 - 5835 @ 80), (30)
+
+country HN: DFS-FCC
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (17), AUTO-BW
+	(5250 - 5330 @ 80), (24), DFS, AUTO-BW
+	(5490 - 5730 @ 160), (24), DFS
+	(5735 - 5835 @ 80), (30)
+
+country HR: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+	# 60 gHz band channels 1-4, ref: Etsi En 302 567
+	(57000 - 66000 @ 2160), (40)
+
+country HT: DFS-FCC
+	(2402 - 2472 @ 40), (30)
+	(5170 - 5250 @ 80), (24), AUTO-BW
+	(5250 - 5330 @ 80), (24), DFS, AUTO-BW
+	(5490 - 5730 @ 160), (24), DFS
+	(5735 - 5835 @ 80), (30)
+
+country HU: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+	# 60 gHz band channels 1-4, ref: Etsi En 302 567
+	(57000 - 66000 @ 2160), (40)
+
+country ID: DFS-JP
+	# ref: http://www.postel.go.id/content/ID/regulasi/standardisasi/kepdir/bwa%205,8%20ghz.pdf
+	(2402 - 2482 @ 40), (20)
+	(5735 - 5815 @ 80), (23)
+
+country IE: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+	# 60 gHz band channels 1-4, ref: Etsi En 302 567
+	(57000 - 66000 @ 2160), (40)
+
+country IL: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW
+	(5250 - 5350 @ 80), (200 mW), NO-OUTDOOR, DFS, AUTO-BW
+
+country IN: DFS-JP
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5735 - 5835 @ 80), (20)
+
+country IR: DFS-JP
+	(2402 - 2482 @ 40), (20)
+	(5735 - 5835 @ 80), (30)
+
+country IS: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+	# 60 gHz band channels 1-4, ref: Etsi En 302 567
+	(57000 - 66000 @ 2160), (40)
+
+country IT: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+	# 60 gHz band channels 1-4, ref: Etsi En 302 567
+	(57000 - 66000 @ 2160), (40)
+
+country JM: DFS-FCC
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (17), AUTO-BW
+	(5250 - 5330 @ 80), (24), DFS, AUTO-BW
+	(5490 - 5730 @ 160), (24), DFS
+	(5735 - 5835 @ 80), (30)
+
+country JO: DFS-JP
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (23)
+	(5735 - 5835 @ 80), (23)
+
+country JP: DFS-JP
+	(2402 - 2482 @ 40), (20)
+	(2474 - 2494 @ 20), (20), NO-OFDM
+	(4910 - 4990 @ 40), (23)
+	(5030 - 5090 @ 40), (23)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (23), DFS
+
+country KE: DFS-JP
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (23)
+	(5490 - 5570 @ 80), (30), DFS
+	(5735 - 5775 @ 40), (23)
+
+country KH: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+
+# Source
+# http://ntrc.kn/?page_id=7
+country KN: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (30), DFS
+	(5735 - 5815 @ 80), (30)
+
+country KP: DFS-JP
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5630 @ 80), (30), DFS
+	(5735 - 5815 @ 80), (30)
+
+country KR: DFS-JP
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (30), DFS
+	(5735 - 5835 @ 80), (30)
+
+country KW: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+
+country KY: DFS-FCC
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (24), AUTO-BW
+	(5250 - 5330 @ 80), (24), DFS, AUTO-BW
+	(5490 - 5730 @ 160), (24), DFS
+	(5735 - 5835 @ 80), (30)
+
+country KZ:
+	(2402 - 2482 @ 40), (20)
+
+country LB: DFS-FCC
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (17), AUTO-BW
+	(5250 - 5330 @ 80), (24), DFS, AUTO-BW
+	(5490 - 5730 @ 160), (24), DFS
+	(5735 - 5835 @ 80), (30)
+
+# Source:
+# http://www.ntrc.org.lc/operational_structures.htm
+country LC: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (30), DFS
+	(5735 - 5815 @ 80), (30)
+
+country LI: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+
+country LK: DFS-FCC
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (17)
+	(5250 - 5330 @ 80), (24), DFS
+	(5490 - 5730 @ 80), (24), DFS
+	(5735 - 5835 @ 80), (30)
+
+# Source:
+# http://lca.org.ls/images/documents/lesotho_national_frequency_allocation_plan.pdf
+country LS: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+
+country LT: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+	# 60 gHz band channels 1-4, ref: Etsi En 302 567
+	(57000 - 66000 @ 2160), (40)
+
+country LU: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+	# 60 gHz band channels 1-4, ref: Etsi En 302 567
+	(57000 - 66000 @ 2160), (40)
+
+country LV: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+	# 60 gHz band channels 1-4, ref: Etsi En 302 567
+	(57000 - 66000 @ 2160), (40)
+
+country MA: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+
+country MC: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+
+# Source:
+# http://www.cnfr.md/index.php?pag=sec&id=117&l=en
+country MD: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+
+# Source:
+# http://www.cept.org/files/1050/Tools%20and%20Services/EFIS%20-%20ECO%20Frequency%20Information%20System/National%20frequency%20tables/Montenegro%20NAFT%20-%202010.pdf
+country ME: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+
+country MF: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+
+country MH: DFS-FCC
+	(2402 - 2472 @ 40), (30)
+	(5170 - 5250 @ 80), (24), AUTO-BW
+	(5250 - 5330 @ 80), (24), DFS, AUTO-BW
+	(5490 - 5730 @ 160), (24), DFS
+	(5735 - 5835 @ 80), (30)
+
+country MK: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+	# 60 gHz band channels 1-4, ref: Etsi En 302 567
+	(57000 - 66000 @ 2160), (40)
+
+country MN: DFS-FCC
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (24), AUTO-BW
+	(5250 - 5330 @ 80), (24), DFS, AUTO-BW
+	(5490 - 5730 @ 160), (24), DFS
+	(5735 - 5835 @ 80), (30)
+
+country MO:
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 40), (23)
+	(5250 - 5330 @ 40), (23), DFS
+	(5735 - 5835 @ 40), (30)
+
+country MP: DFS-FCC
+	(2402 - 2472 @ 40), (30)
+	(5170 - 5250 @ 80), (24), AUTO-BW
+	(5250 - 5330 @ 80), (24), DFS, AUTO-BW
+	(5490 - 5730 @ 160), (24), DFS
+	(5735 - 5835 @ 80), (30)
+
+country MQ: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+
+# Source:
+# http://www.are.mr/pdfs/telec_freq_TNAbf_2010.pdf
+country MR: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+
+country MT: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+	# 60 gHz band channels 1-4, ref: Etsi En 302 567
+	(57000 - 66000 @ 2160), (40)
+
+country MU: DFS-FCC
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (24), AUTO-BW
+	(5250 - 5330 @ 80), (24), DFS, AUTO-BW
+	(5490 - 5730 @ 160), (24), DFS
+	(5735 - 5835 @ 80), (30)
+
+country MW: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+
+country MX: DFS-FCC
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (17), AUTO-BW
+	(5250 - 5330 @ 80), (24), DFS, AUTO-BW
+	(5490 - 5730 @ 160), (24), DFS
+	(5735 - 5835 @ 80), (30)
+
+country MY: DFS-FCC
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (17), AUTO-BW
+	(5250 - 5330 @ 80), (23), DFS, AUTO-BW
+	(5735 - 5835 @ 80), (30)
+
+country NI: DFS-FCC
+	(2402 - 2472 @ 40), (30)
+	(5170 - 5250 @ 80), (24), AUTO-BW
+	(5250 - 5330 @ 80), (24), DFS, AUTO-BW
+	(5490 - 5730 @ 160), (24), DFS
+	(5735 - 5835 @ 80), (30)
+
+country NL: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), NO-OUTDOOR, AUTO-BW
+	(5250 - 5330 @ 80), (20), NO-OUTDOOR, DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+	# 60 gHz band channels 1-4, ref: Etsi En 302 567
+	(57000 - 66000 @ 2160), (40)
+
+# Data from http://www.lovdata.no/dokument/SF/forskrift/2012-01-19-77
+# Power at 5250 - 5350 MHz, 5470 - 5725 MHz and 5815 – 5850 MHz can
+# be doubled if TPC is implemented.
+# Up to 2W (or 4W with TPC) is allowed in the 5725 – 5795 MHz band
+# which has been merged with 5470 - 5725 MHz to allow wide channels
+country NO: DFS-ETSI
+	(2400 - 2483.5 @ 40), (100 mW)
+	(5150 - 5250 @ 80), (200 mW), AUTO-BW
+	(5250 - 5350 @ 80), (100 mW), DFS, AUTO-BW
+	(5470 - 5795 @ 160), (500 mW), DFS
+	(5815 - 5850 @ 35), (2000 mW), DFS
+	(17100 - 17300 @ 200), (100 mW)
+	# 60 gHz band channels 1-4, ref: Etsi En 302 567
+	(57000 - 66000 @ 2160), (40)
+
+country NP: DFS-JP
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5735 - 5835 @ 80), (20)
+
+country NZ: DFS-FCC
+	(2402 - 2482 @ 40), (30)
+	(5170 - 5250 @ 80), (17), AUTO-BW
+	(5250 - 5330 @ 80), (24), DFS, AUTO-BW
+	(5490 - 5730 @ 160), (24), DFS
+	(5735 - 5835 @ 80), (30)
+
+country OM: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+
+country PA: DFS-FCC
+	(2402 - 2472 @ 40), (30)
+	(5170 - 5250 @ 80), (17), AUTO-BW
+	(5250 - 5330 @ 80), (23), DFS, AUTO-BW
+	(5735 - 5835 @ 80), (30)
+
+country PE: DFS-FCC
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (17), AUTO-BW
+	(5250 - 5330 @ 80), (24), DFS, AUTO-BW
+	(5490 - 5730 @ 160), (24), DFS
+	(5735 - 5835 @ 80), (30)
+
+country PF: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+
+country PG: DFS-FCC
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (17), AUTO-BW
+	(5250 - 5330 @ 80), (24), DFS, AUTO-BW
+	(5490 - 5730 @ 160), (24), DFS
+	(5735 - 5835 @ 80), (30)
+
+country PH: DFS-FCC
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (17), AUTO-BW
+	(5250 - 5330 @ 80), (24), DFS, AUTO-BW
+	(5490 - 5730 @ 160), (24), DFS
+	(5735 - 5835 @ 80), (30)
+
+country PK: DFS-JP
+	(2402 - 2482 @ 40), (20)
+	(5735 - 5835 @ 80), (30)
+
+country PL: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+	# 60 gHz band channels 1-4, ref: Etsi En 302 567
+	(57000 - 66000 @ 2160), (40)
+
+country PM: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+
+country PR: DFS-FCC
+	(2402 - 2472 @ 40), (30)
+	(5170 - 5250 @ 80), (17), AUTO-BW
+	(5250 - 5330 @ 80), (24), DFS, AUTO-BW
+	(5490 - 5730 @ 160), (24), DFS
+	(5735 - 5835 @ 80), (30)
+
+country PT: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+	# 60 gHz band channels 1-4, ref: Etsi En 302 567
+	(57000 - 66000 @ 2160), (40)
+
+country PW: DFS-FCC
+	(2402 - 2472 @ 40), (30)
+	(5170 - 5250 @ 80), (24), AUTO-BW
+	(5250 - 5330 @ 80), (24), DFS, AUTO-BW
+	(5490 - 5730 @ 160), (24), DFS
+	(5735 - 5835 @ 80), (30)
+
+country PY: DFS-FCC
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (24), AUTO-BW
+	(5250 - 5330 @ 80), (24), DFS, AUTO-BW
+	(5490 - 5730 @ 160), (24), DFS
+	(5735 - 5835 @ 80), (30)
+
+country QA: DFS-JP
+	(2402 - 2482 @ 40), (20)
+	(5735 - 5835 @ 80), (30)
+
+country RE: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+
+country RO: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+	# 60 gHz band channels 1-4, ref: Etsi En 302 567
+	(57000 - 66000 @ 2160), (40)
+
+
+# Source:
+# http://www.ratel.rs/upload/documents/Plan_namene/Plan_namene-sl_glasnik.pdf
+country RS: DFS-ETSI
+	(2400 - 2483.5 @ 40), (100 mW)
+	(5150 - 5350 @ 40), (200 mW), NO-OUTDOOR
+	(5470 - 5725 @ 20), (1000 mW), DFS
+	# 60 gHz band channels 1-4, ref: Etsi En 302 567
+	(57000 - 66000 @ 2160), (40)
+
+country RU: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20)
+	(5250 - 5330 @ 80), (20), DFS
+	(5650 - 5730 @ 80), (30), DFS
+	(5735 - 5835 @ 80), (30)
+
+country RW: DFS-FCC
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (17), AUTO-BW
+	(5250 - 5330 @ 80), (24), DFS, AUTO-BW
+	(5490 - 5730 @ 160), (24), DFS
+	(5735 - 5835 @ 80), (30)
+
+country SA: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+
+country SE: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+	# 60 gHz band channels 1-4, ref: Etsi En 302 567
+	(57000 - 66000 @ 2160), (40)
+
+country SG: DFS-FCC
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (17), AUTO-BW
+	(5250 - 5330 @ 80), (24), DFS, AUTO-BW
+	(5490 - 5730 @ 160), (24), DFS
+	(5735 - 5835 @ 80), (30)
+
+country SI: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+	# 60 gHz band channels 1-4, ref: Etsi En 302 567
+	(57000 - 66000 @ 2160), (40)
+
+country SK: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+	# 60 gHz band channels 1-4, ref: Etsi En 302 567
+	(57000 - 66000 @ 2160), (40)
+
+# Source:
+# Regulation N° 2004-005 ART/DG/DRC/D.Rég
+country SN: DFS-FCC
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (17), AUTO-BW
+	(5250 - 5330 @ 80), (24), DFS, AUTO-BW
+	(5490 - 5730 @ 160), (24), DFS
+	(5735 - 5835 @ 80), (30)
+
+country SR: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+
+country SV: DFS-FCC
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (17)
+	(5250 - 5330 @ 80), (23), DFS
+	(5735 - 5835 @ 80), (30)
+
+country SY:
+	(2402 - 2482 @ 40), (20)
+
+# Source:
+# http://www.telecommission.tc/Spectrum-plan20110324-101210.html
+country TC: DFS-FCC
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (24), AUTO-BW
+	(5250 - 5330 @ 80), (24), DFS, AUTO-BW
+	(5490 - 5730 @ 160), (24), DFS
+	(5735 - 5835 @ 80), (30)
+
+country TD: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+
+country TG: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 40), (20)
+	(5250 - 5330 @ 40), (20), DFS
+	(5490 - 5710 @ 40), (27), DFS
+
+country TH: DFS-FCC
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (17), AUTO-BW
+	(5250 - 5330 @ 80), (24), DFS, AUTO-BW
+	(5490 - 5730 @ 160), (24), DFS
+	(5735 - 5835 @ 80), (30)
+
+country TN: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+
+country TR: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+	# 60 gHz band channels 1-4, ref: Etsi En 302 567
+	(57000 - 66000 @ 2160), (40)
+
+country TT: DFS-FCC
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (17), AUTO-BW
+	(5250 - 5330 @ 80), (24), DFS, AUTO-BW
+	(5490 - 5730 @ 160), (24), DFS
+	(5735 - 5835 @ 80), (30)
+
+country TW: DFS-JP
+	(2402 - 2472 @ 40), (30)
+	(5270 - 5330 @ 40), (17), DFS
+	(5490 - 5590 @ 80), (30), DFS
+	(5650 - 5710 @ 40), (30), DFS
+	(5735 - 5835 @ 80), (30)
+ 
+# Source:
+# #914 / 06 Sep 2007: http://www.ucrf.gov.ua/uk/doc/nkrz/1196068874
+# #1174 / 23 Oct 2008: http://www.nkrz.gov.ua/uk/activities/ruling/1225269361
+# (appendix 8)
+# Listed 5GHz range is a lowest common denominator for all related
+# rules in the referenced laws. Such a range is used because of
+# disputable definitions there.
+country UA: DFS-ETSI
+	(2400 - 2483.5 @ 40), (20), NO-OUTDOOR
+	(5150 - 5350 @ 40), (20), NO-OUTDOOR
+	(5490 - 5670 @ 80), (20), DFS
+	(5735 - 5835 @ 80), (20)
+	# 60 gHz band channels 1-4, ref: Etsi En 302 567
+	(57000 - 66000 @ 2160), (40)
+
+country UG: DFS-FCC
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (24), AUTO-BW
+	(5250 - 5330 @ 80), (24), DFS, AUTO-BW
+	(5490 - 5730 @ 160), (24), DFS
+	(5735 - 5835 @ 80), (30)
+
+country US: DFS-FCC
+	(2402 - 2472 @ 40), (30)
+	(5170 - 5250 @ 80), (17), AUTO-BW
+	(5250 - 5330 @ 80), (23), DFS, AUTO-BW
+	(5490 - 5710 @ 20), (30)
+	(5735 - 5835 @ 80), (30)
+	(5850 - 5935 @ 10), (30)
+	# 60g band
+	# reference: http://cfr.regstoday.com/47cfr15.aspx#47_CFR_15p255
+	# channels 1,2,3, EIRP=40dBm(43dBm peak)
+	(57240 - 63720 @ 2160), (40)
+
+country UY: DFS-FCC
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (17), AUTO-BW
+	(5250 - 5330 @ 80), (24), DFS, AUTO-BW
+	(5490 - 5730 @ 160), (24), DFS
+	(5735 - 5835 @ 80), (30)
+
+# Source:
+# http://cemc.uz/article/1976/
+country UZ: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+
+# Source:
+# http://www.ntrc.vc/regulations/Jun_2006_Spectrum_Managment_Regulations.pdf
+country VC: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+
+# Source:
+# Official Gazette (Gaceta Oficial) concerning Unlicensed transmitter use
+# (10 June 2013)
+# http://www.conatel.gob.ve/
+country VE: DFS-FCC
+	(2402 - 2482 @ 40), (30)
+	(5170 - 5250 @ 80), (23), AUTO-BW
+	(5250 - 5330 @ 80), (23), DFS, AUTO-BW
+	(5735 - 5835 @ 80), (30)
+
+country VI: DFS-FCC
+	(2402 - 2472 @ 40), (30)
+	(5170 - 5250 @ 80), (24), AUTO-BW
+	(5250 - 5330 @ 80), (24), DFS, AUTO-BW
+	(5490 - 5730 @ 160), (24), DFS
+	(5735 - 5835 @ 80), (30)
+
+country VN: DFS-FCC
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (17)
+	(5250 - 5330 @ 80), (24), DFS
+	(5490 - 5730 @ 80), (24), DFS
+	(5735 - 5835 @ 80), (30)
+
+# Source:
+# http://www.trr.vu/attachments/category/130/GURL_for_Short-range_Radiocommunication_Devices2.pdf
+country VU: DFS-FCC
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (17), AUTO-BW
+	(5250 - 5330 @ 80), (24), DFS, AUTO-BW
+	(5490 - 5730 @ 160), (24), DFS
+	(5735 - 5835 @ 80), (30)
+
+country WF: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+
+country YE:
+	(2402 - 2482 @ 40), (20)
+
+country YT: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+
+country ZA: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+
+country ZW: DFS-ETSI
+	(2402 - 2482 @ 40), (20)
+	(5170 - 5250 @ 80), (20), AUTO-BW
+	(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+	(5490 - 5710 @ 160), (27), DFS
+
+
Only in linux-4.9.61-pat/scripts/basic: .fixdep.cmd
Only in linux-4.9.61-pat/scripts/basic: fixdep
Only in linux-4.9.61-pat/scripts/kconfig: .conf.cmd
Only in linux-4.9.61-pat/scripts/kconfig: .conf.o.cmd
Only in linux-4.9.61-pat/scripts/kconfig: .mconf.cmd
Only in linux-4.9.61-pat/scripts/kconfig: .mconf.o.cmd
Only in linux-4.9.61-pat/scripts/kconfig: .zconf.tab.o.cmd
Only in linux-4.9.61-pat/scripts/kconfig: conf
Only in linux-4.9.61-pat/scripts/kconfig: conf.o
Only in linux-4.9.61-pat/scripts/kconfig/lxdialog: .checklist.o.cmd
Only in linux-4.9.61-pat/scripts/kconfig/lxdialog: .inputbox.o.cmd
Only in linux-4.9.61-pat/scripts/kconfig/lxdialog: .menubox.o.cmd
Only in linux-4.9.61-pat/scripts/kconfig/lxdialog: .textbox.o.cmd
Only in linux-4.9.61-pat/scripts/kconfig/lxdialog: .util.o.cmd
Only in linux-4.9.61-pat/scripts/kconfig/lxdialog: .yesno.o.cmd
Only in linux-4.9.61-pat/scripts/kconfig/lxdialog: checklist.o
Only in linux-4.9.61-pat/scripts/kconfig/lxdialog: inputbox.o
Only in linux-4.9.61-pat/scripts/kconfig/lxdialog: menubox.o
Only in linux-4.9.61-pat/scripts/kconfig/lxdialog: textbox.o
Only in linux-4.9.61-pat/scripts/kconfig/lxdialog: util.o
Only in linux-4.9.61-pat/scripts/kconfig/lxdialog: yesno.o
Only in linux-4.9.61-pat/scripts/kconfig: mconf
Only in linux-4.9.61-pat/scripts/kconfig: mconf.o
Only in linux-4.9.61-pat/scripts/kconfig: zconf.hash.c
Only in linux-4.9.61-pat/scripts/kconfig: zconf.lex.c
Only in linux-4.9.61-pat/scripts/kconfig: zconf.tab.c
Only in linux-4.9.61-pat/scripts/kconfig: zconf.tab.o

--------------A29038F9C1F1B6C89649F1CA-- From nobody Sat Mar 3 10:03: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 D9D1F126CB6 for ; Sat, 3 Mar 2018 10:03: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, 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 OV0zD4tAb01O for ; Sat, 3 Mar 2018 10:03: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 C556C1204DA for ; Sat, 3 Mar 2018 10:03: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 w23I3a2k092430; Sat, 3 Mar 2018 19:03:36 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4DC3C200DDB; Sat, 3 Mar 2018 19:03: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 36F182007F0; Sat, 3 Mar 2018 19:03:36 +0100 (CET) Received: from [132.166.84.104] ([132.166.84.104]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w23I3VrM025531; Sat, 3 Mar 2018 19:03:32 +0100 To: cjbc@it.uc3m.es, =?UTF-8?Q?Fran=c3=a7ois_Simon?= , =?UTF-8?B?J0rDqXLDtG1lIEjDpHJyaSc=?= , "'William Whyte'" , "'Dick Roy'" Cc: its@ietf.org References: <002b01d3af21$6e779a70$4b66cf50$@eurecom.fr> <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> <5ccad588-bcd8-d179-165b-7936a34220fb@gmail.com> <5a98213d.d138c80a.ababc.519f@mx.googl e.com> <006c01d3b17f$88506750$98f135f0$@eurecom.fr> <01eb01d3b248$c24c0df0$46e429d0$@gmail.com> <4d3a05bf-169f-c531-c8b4-ba2310ae3e22@gmail.com> <1520020476.3381.4.camel@it.uc3m.es> From: Alexandre Petrescu Message-ID: Date: Sat, 3 Mar 2018 19:03: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: <1520020476.3381.4.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] 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: Sat, 03 Mar 2018 18:03:44 -0000 Le 02/03/2018 à 20:54, Carlos Jesús Bernardos Cano a écrit : > Hi Alex, > > On Fri, 2018-03-02 at 18:10 +0100, Alexandre Petrescu wrote: >> Is there a discussion slot to discuss this in London? > > You mean to discuss about QoS with IPv6 over 802.11-OCB? Yes. > Are you > requesting it to present some material to foster the discussion? I asked Jérôme too, we think about this. > We sure can allocate some time for that (I'd say that under the > "rechartering" discussion slot, as I understood that this issue is > closed for the WG doc, right?). yes closed. > Do you think -20 is ready so I can review it and request our AD to send > the draft to 6man for review? Yes, the -21 is ready. Alex > > Thanks, > > Carlos > >> >> I would be interested to contribute to the discussion on QoS, but >> provided we agree it is about QoS with IP, not QoS without IP. >> >> Alex >> >> Le 02/03/2018 à 18:06, François Simon a écrit : >>> Aggree. >>> >>> *From:*its *On Behalf Of *Jérôme Härri >>> *Sent:* Thursday, March 01, 2018 12:06 PM >>> *To:* 'William Whyte' ; 'Dick Roy' >>> >>> *Cc:* 'Alexandre Petrescu' ; its@ietf >>> .org >>> *Subject:* Re: [ipwave] 802.11 Data vs 802.11 QoS Data in >>> IPv6-over-802.11-OCB -implementations >>> >>> Dear All, >>> >>> With the risk of repeating information already sent in the thread, >>> the >>> issue has never been if Data or QoSData is allowed for OCB. It is >>> clear >>> it is. >>> >>> BUT considering that SAE 2945/1 (BSM) and ETSI geonet-media >>> dependent >>> functionalities, both specify to use QoSData to differentiate >>> event-based BSM (very urgent) from periodic BMS (normal) / DENM >>> (very >>> urgent) from CAM (normal) using QoSData with AC_VI (DENM/event- >>> based >>> BSM) and AC_BE (CAM/periodic BSM), we have a ‘coexistence issue’ . >>> >>> Indeed, 802.11 data frame use DCF, which use a DIFS equal to 2 slot >>> + >>> SIFS. Now, AC_VI (the urgent DENM/BSM) use EDCA AC_VI, also with 2 >>> slot >>> + SIFS. And CAM/periodic BSM use **6** slot + SIFS. >>> >>> In short, any IP-over-OCB will access the channel before CAM/BSM at >>> best >>> and generate collisions with ITS-G5 and DSRC. This can be seem as >>> ‘harmful’ interferences with an existing system, which must be >>> avoided. >>> >>> That is the reason I am suggesting to use QoSData for IP-over-OCB, >>> so >>> that depending on your traffic (e.g. if you transmit CAM-over-IP, >>> or >>> video feeds) you can tweak the right AC_ and not interfere with >>> DSRC/ITS-G5..much. That would avoid a lot of issues…and it does not >>> cost >>> much (ok some extra bits, but come on…we are not doing ROLL here, >>> so is >>> it that dramatic? >>> >>> Even though not the task of IETF, it is important to make sure that >>> any >>> specification will not interfere with an existing system. So, >>> Alex’s >>> suggestion to remove any explicit mention to QoSData or Data is >>> probably >>> a good trade-off, and leave it open to profiling as function of in >>> which >>> channel IP-over-OCB would be used (i.e if interference is expected >>> or not)… >>> >>> BR, >>> >>> Jérôme >>> >>> *From:*its [mailto:its-bounces@ietf.org] *On Behalf Of *William >>> Whyte >>> *Sent:* Thursday 01 March 2018 17:29 >>> *To:* Dick Roy >>> *Cc:* Alexandre Petrescu; its@ietf.org >>> *Subject:* Re: [ipwave] 802.11 Data vs 802.11 QoS Data in >>> IPv6-over-802.11-OCB -implementations >>> >>> If that's the case, I don't have an issue with the draft allowing >>> Data >>> and QoSData, though I'd note that the definition of OCB in the >>> Terminology section of the draft states that QoSData is required >>> and >>> should be changed if it's wrong. >>> >>> On the question of implementations: I don't have pcaps to hand, but >>> the >>> USDOT RSU spec, available from >>> https://transportationops.org/publications/dedicated-short-range-co >>> mmunications-roadside-unit-specifications, >>> requires QoSData, and OmniAir has been testing conformance to that >>> spec, >>> so it's safe to assume that it's been implemented. >>> >>> Cheers, >>> >>> William >>> >>> On Thu, Mar 1, 2018 at 11:22 AM, Dick Roy >> > wrote: >>> >>> Actually I believe the QoSData restriction is in J2945/1 having >>> only to >>> do with operation in the US in 5.9GHz. Data and QoSData are >>> permitted >>> according to 802.11 (and 1609.x). This is not to say I believe >>> this >>> discussion is relevant to the task of the ITS group, but … :^))) >>> >>> Cheers, >>> >>> RR >>> >>> ----------------------------------------------------------------- >>> ------- >>> >>> *From:*its [mailto:its-bounces@ietf.org >> g>] >>> *On Behalf Of *William Whyte >>> *Sent:* Thursday, March 1, 2018 7:50 AM >>> *To:* Alexandre Petrescu; its@ietf.org >>> >>> >>> *Subject:* Re: [ipwave] 802.11 Data vs 802.11 QoS Data in >>> IPv6-over-802.11-OCB -implementations >>> >>>>> (there are some packet dumps with IP packets transported with >>>>> .11 Data >>> >>> headers in OCB mode at 5.9GHz, e.g. attached). >>> >>> My understanding is OCB mode requires QoSData, so those packets >>> aren’t >>> conformant to the standard. >>> >>> Cheers, >>> >>> William >>> >>> Sent from Mail >>> for >>> Windows 10 >>> >>> *From: *Alexandre Petrescu >>> *Sent: *Thursday, March 1, 2018 10:48 AM >>> *To: *its@ietf.org >>> *Subject: *Re: [ipwave] 802.11 Data vs 802.11 QoS Data in >>> IPv6-over-802.11-OCB -implementations >>> >>> In a private discussion, this question came up: >>> >>> Is there a packet dump showing an IP packet transported with .11 >>> QoSData >>> >>> headers in OCB mode at 5.9GHz. >>> >>> (there are some packet dumps with IP packets transported with .11 >>> Data >>> >>> headers in OCB mode at 5.9GHz, e.g. attached). >>> >>> Alex >>> >>> Le 01/03/2018 à 15:32, Alexandre Petrescu a écrit : >>> >>>> I received some feedback from programmer. >>>> >>>> Le 28/02/2018 à 23:48, Abdussalam Baryun a écrit : >>>> [...] >>>>> 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, >>>> >>>> Here is the QoS problem for IP over 802.11 OCB in >>>> implementations. >>>> >>>> In short, in open source on linux, we dont know how to send IP >>>> packets >>>> transported as 802.11 QoSData, all IP packets are transported as >>>> 802.11 >>>> Data instead. >>>> >>>> - if you ping -Q at 5.9GHz in OCB mode, the DSCP fields do get >>>> set properly in IP headers of Echorequest, but there is no >>>> .11 QoSData >>>> headers in packets. Normally, one expects the QoSData >>>> headers to be >>>> present there when the DSCP (an IP field) is set. >>>> >>>> - if you want to modify kernel, and force always to use QoSData >>>> headers >>>> on WiFi, including OCB at 5.9GHz, there is a >>>> net/mac80211/tx.c file >>>> with a flag called wme_sta that you could set to true. But >>>> take care >>>> that the C comments there say that it's not normal to use >>>> QoSData >>>> headers in OCB mode, because a terminal sending QoSData has >>>> no >>>> guarantee that receivers also use QoSData (the negotiation of >>>> QoS >>>> capabilities are absent in OCB). >>>> >>>> As you can see, this can be long to try and fix. >>>> >>>> Until then I will propose to set QoS aside from IP-over-OCB at >>>> this time. >>>> >>>> Alex >>>> >>>> _______________________________________________ >>>> its mailing list >>>> its@ietf.org >>>> https://www.ietf.org/mailman/listinfo/its >>> >>> >>> >>> -- >>> >>> PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS: >>> wwhyte@onboardsecurity.com >>> >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its > From nobody Sun Mar 4 07:39: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 66D741270AC for ; Sun, 4 Mar 2018 07:39:43 -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 WBGhiFAZqO5J for ; Sun, 4 Mar 2018 07:39:41 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 BED34120721 for ; Sun, 4 Mar 2018 07:39:40 -0800 (PST) Received: by mail-wm0-x22d.google.com with SMTP id t74so11349375wme.3 for ; Sun, 04 Mar 2018 07:39: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=v4BGCqoaNG/GPOpFTxrp8PUW2LbBkrsc62T/fu1LNw4=; b=kxqVYZ/SPk89YLumAbMZ04fno0P8NM0Rpd60nUrBo7WcY8aavK8n4qtGqTJ7qDfm6A ehxxs4EUMwEUPPeDAHLMyt+NCksG5X1ASxUEcFLPcZtPYdd1rqpC7JTy6LAgeUIr3sL5 sXuTysUiB/uL4VGDEv6qcIffLMSL/f8pSdW1z9Rp2gcNjdv1f6nOlZ9eHCv4vrtxcTqG TMZTu5WtgpNvM4DAstC1oAJxslY2pqZXORBuipUk3RrXRLjKVqAgvPmw6SKj857SYnvr 0XlTwttcrH7jQ7s6zV9gtlEcOT0pKe/K6pdA93YLf3KekVhoWxyqHNb1rseyDYQRo0dT 0mAg== 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=v4BGCqoaNG/GPOpFTxrp8PUW2LbBkrsc62T/fu1LNw4=; b=lEQD0UTNQgt0TGZq6pQkHr4ovyNuwVUwBXv3ZNgim/QxGhJ6Y5fXPiPmtAOFHHtKRk v/RVoTu4zDCQgxi49MQerq1ugJR7++FMave3UEz7WJqjrlrUFGJVkPiuErk7xCaj71gb zh1PeYlMef/rOGn7aLyff4pL1RALRaak7sbxgwuzRKmh8zJTv2bP4WGumwiNah+BRuPX qCZYxOe4qrQN7uH/zVFfzk2RHb722kI3pr4YjkSn4epLAHGDV6BhQQ42zfEhXKGePXbG aYH3ioCYiCZzGTDPMBj3Jo1DFr6Wp3fmKzFwuhOP+bQbwhCfVZiQDJWQXhO//b6P/gwf s7DA== X-Gm-Message-State: AElRT7G2mWhsyBO9Xhh+cxtGPNnsMu6XXIuotOjlA1n/mUYKM046vxuA eFRuAjMlLwilyjrt+uyrXOLphw== X-Google-Smtp-Source: AG47ELsfeYuQQ3HGNMwPciPj4QnP3VviWKVZukv3UOxOIbjIq0P8zqHR2RvWvR4EbkB19OyugJXH3Q== X-Received: by 10.28.156.67 with SMTP id f64mr6487723wme.11.1520177979156; Sun, 04 Mar 2018 07:39:39 -0800 (PST) Received: from acorde ([31.4.242.246]) by smtp.gmail.com with ESMTPSA id j89sm5958314wrj.92.2018.03.04.07.39.37 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 04 Mar 2018 07:39:38 -0800 (PST) Message-ID: <1520177965.3381.36.camel@it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano Reply-To: cjbc@it.uc3m.es To: Alexandre Petrescu , Tony Li Cc: =?ISO-8859-1?Q?Fran=E7ois?= Simon , =?ISO-8859-1?Q?J=E9r=F4me_H=E4rri?= , William Whyte , Dick Roy , its@ietf.org Date: Sun, 04 Mar 2018 16:39:25 +0100 In-Reply-To: <9b5daf2c-8c75-61f3-dded-31b86506c4e1@gmail.com> References: <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> <5ccad588-bcd8-d179-165b-7936a34220fb@gmail.com> <5a98213d.d138c80a.ababc.519f@mx.googl e.com> <006c01d3b17f$88506750$98f135f0$@eurecom.fr> <01eb01d3b248$c24c0df0$46e429d0$@gmail.com> <4d3a05bf-169f-c531-c8b4-ba2310ae3e22@gmail.com> <1520020476.3381.4.camel@it.uc3m.es> <64DE64AB-CB38-4925-9B50-1576C7DA1C0A@gmail.com> <1520021896.3381.10.camel@it.uc3m.es> <9b5daf2c-8c75-61f3-dded-31b86506c4e1@gmail.com> 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] 802.11 Data vs 802.11 QoS Data - summary X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 15:39:43 -0000 Hi Alex, Thanks for the summary. Carlos On Sat, 2018-03-03 at 18:51 +0100, Alexandre Petrescu wrote: > Hi Carlos, > > The last version, -21, is neutral with respect to which 802.11 > headers > to use. It says "802.11 headers" and does not say anything about > which > Subtype. It does not say "MAY use QOSData", nor does it say "MAY use > Data". > > The different views on this topic are the following: > > - some suggest the 802.11 Data headers is the best choice to transmit > IP > datagrams on 802.11 in OCB mode at 5.9 GHz. The reasons invoked > relate to: it is widely implemented this way, and there is some > high-level doubting QoS in general across Internet. > - some suggest, on the contrary, that the best choice to transmit IP > datagrams on 802.11 in OCB mode at 5.9 GHz is the 802.11 QoS Data > headers instead. The reasons invoked are: the OCB mode at 5.9GHz > is > already used to transmit very important non-IP packets (WSMP, CAM, > etc), each using QoS Data headers; there may be a risk of loss of > QoS guarantee if somebody else (IP) uses Data headers instead. > - the IEEE OCB standard permits the use of both QoSData headers _and_ > Data headers. But further standards beyond that, require the use > of > QoSData headers although they dont say they require it for IP. > - a partial solution was suggested publicly, and agreed by some > private > and public emails, to use a certain QoS AC value (Access Category) > to > transport IP. > - many coexistence was required and necessary. > > It is because of this difference of views that we removed the > QoSData-vs-Data altogether from the IP-over-OCB draft. > > Alex > > Le 02/03/2018 à 21:18, Carlos Jesús Bernardos Cano a écrit : > > Hi Tony, > > > > OK, thanks. > > > > Alex: can you summarize the different views in one single e-mail, > > so we > > can take it from there? > > > > Thanks, > > > > Carlos > > > > On Fri, 2018-03-02 at 12:03 -0800, Tony Li wrote: > > > > > > > > > > On Mar 2, 2018, at 11:54 AM, Carlos Jesús Bernardos Cano > > > it.u > > > > c3m.es> wrote: > > > > > > > > You mean to discuss about QoS with IPv6 over 802.11-OCB? Are > > > > you > > > > requesting it to present some material to foster the > > > > discussion? > > > > > > > > We sure can allocate some time for that (I'd say that under the > > > > "rechartering" discussion slot, as I understood that this issue > > > > is > > > > closed for the WG doc, right?). > > > > > > > > > I’m not at all convinced that we have rough consensus on QoS yet. > > > > > > If we don’t converge by London, I would propose a hum. > > > > > > Tony > > > From nobody Sun Mar 4 15:20: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 75528126B6E for ; Sun, 4 Mar 2018 15:20:42 -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 Lmylyrc156rD for ; Sun, 4 Mar 2018 15:20:39 -0800 (PST) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::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 AF932124217 for ; Sun, 4 Mar 2018 15:20:39 -0800 (PST) Received: by mail-it0-x231.google.com with SMTP id e64so7836578ita.5 for ; Sun, 04 Mar 2018 15:20:39 -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=EvI0Boa223Tz4jBA/UdU4S5W4mT8FUzhHZwjkqMcsGg=; b=X2tt9gosDlnLCCElKiBt+n0eHL9LzObfWF34Zwrys7YonXiGSrrnLzHff3CjKqfzI2 l4jlCMJYZQSA80LljQs1nD+MdDW+MKDwVbI4WrB4o3LdDpLP/YpE5H5/r5w6q6rPfokz Auhaj7y/tWtD5Q9lVQ3e1UPeD2MRzrOWUvUBjmd0caAwj0KH9bNn5AkaKxV1nydlFyLH CmPmIf9ilX7jL2cbdIiauNTFG9xz0Gd+kQAgnMBstwilVlUrypYj791Ssv41wUOpu5Tn rcxGUkpavkE2k+0yxPoBS8whKGcTVoTHwVQ5/PBBvx/tSkpnIfccDFWYOGV3oytvB27s 6CsA== 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=EvI0Boa223Tz4jBA/UdU4S5W4mT8FUzhHZwjkqMcsGg=; b=OCDn+GehXxJ2pRi5aJ4HvSW3srXQTGnSPfu8zm6c9HhR4IMaySRGakzQaq4mJcW0yi vvItaTXFGPsdeiKX08+w4sU5o7SZY92ND2+iod8cUZQhJ1WenKKblgPOW6AQaHWJF4LU 1UmKVjn+TTlNRcO91RYzzMWt89AqCz8ulLXXFA21zxbE/BR4nv7+Xe/zicbx+A3UoGLS ybYf6v2dBQCJbi45nLPeNUd56iGOJupAr26fm9IYZxJK2UvzdPUJWoK7G3Q8078iGCdH 4EKY64ds1Ug5+wmYxA2z1BETOcs8Fu6SKciX9ySl24qH5YXj1ATKnSy4COVDe+QpcUYA F3oQ== X-Gm-Message-State: AElRT7HZ6l5nAlVPZVJDL4RbpJ7BnxLOos+x0Ll33ODEzGHZyDsRXZih l0b5GjX9Q0+OR5ORniG6MJpWA15jqog1eNcEnJHpNg== X-Google-Smtp-Source: AG47ELuh0cw2yR906i5RwYuFIYMMDUT+hPwfYkSB1kAhzbFLgSN4D4GgL+GIARIEGTlqNvSZZGqK6UfBIcW60wDLIOw= X-Received: by 10.36.2.75 with SMTP id 72mr11570378itu.83.1520205638748; Sun, 04 Mar 2018 15:20:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.24.135 with HTTP; Sun, 4 Mar 2018 15:20:38 -0800 (PST) In-Reply-To: <9b5daf2c-8c75-61f3-dded-31b86506c4e1@gmail.com> References: <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> <5ccad588-bcd8-d179-165b-7936a34220fb@gmail.com> <006c01d3b17f$88506750$98f135f0$@eurecom.fr> <01eb01d3b248$c24c0df0$46e429d0$@gmail.com> <4d3a05bf-169f-c531-c8b4-ba2310ae3e22@gmail.com> <1520020476.3381.4.camel@it.uc3m.es> <64DE64AB-CB38-4925-9B50-1576C7DA1C0A@gmail.com> <1520021896.3381.10.camel@it.uc3m.es> <9b5daf2c-8c75-61f3-dded-31b86506c4e1@gmail.com> From: John Kenney Date: Sun, 4 Mar 2018 15:20:38 -0800 Message-ID: To: Alexandre Petrescu Cc: cjbc@it.uc3m.es, Tony Li , =?UTF-8?Q?Fran=C3=A7ois_Simon?= , William Whyte , =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , Dick Roy , its Content-Type: multipart/alternative; boundary="001a1144a654155fbd05669e75fa" Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data - summary X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 23:20:42 -0000 --001a1144a654155fbd05669e75fa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alex, Thanks for this summary. I would like to add a couple of points, one with regard to standards and one with regard to regulations. * Standards: * I was part of the IEEE 802.11 TGp task group that wrote the 802.11p amendment. I speak here only for myself. While we were focused on making it work for DSRC in the 5.9 GHz band, we also recognized that this "BSS-less" feature could be useful for others in the 802.11 community (a kind of ad hoc Wi-Fi). So, we tried not to over-constrain the definition of the OCB type of communication, since we didn't know all of the use cases to which it might be applied. We always expected to require EDCA for vehicular communication in 5.9 GHz. We judged that that could be handled in the IEEE 1609 standards (or in equivalent ETSI standards for Europe). This is why 802.11 allows DCF data frames while IEEE 1609 and EN 302 663 do not. To be clear, a WAVE device must use EDCA for all transmissions, regardless of the L3 protocol. It was never intended that DCF frames would compete with EDCA frames for channel access in a band where safety-of-life was at stake [To restate from earlier in the thread, in such a mix DCF frames would have extremely high priority]. Perhaps we were too liberal originally. Now, 8 years later, I am not aware of any other uses of the OCB type of communication. Perhaps a future revision of 802.11 should omit the DCF type of data frame when using OCB, to avoid any further confusion. *Regulations:* FCC 5.9 GHz regulations require that DSRC services provide access priority to safety-of-life communication over all other DSRC communication. Furthermore, a second class called public-safety communication is required to have access priority over so-called non-priority communication. You can find this in CFR 47 =C2=A7 90.377 and =C2=A7 95.1511. These regulatory re= quirements are independent of the L3 protocol. EDCA is the only mechanism of which I am aware to satisfy this regulation. More to the point, I believe that non-safety-of-life packets using DCF would fail to meet the regulatory requirement vis a vis safety-of-life packets that use EDCA. I am not well versed in the spectrum use regulations of European countries. I believe individual countries are permitted to regulate spectrum use based on European Norms (ENs). Perhaps EN 302 663's requirement to use EDCA will be recognized in the regulations of some countries. *Summary:* Personally, I'm a bit surprised at the resistance to requiring EDCA in the ipwave RFC. I think the arguments are quite compelling. I think the IPWAVE WG should consider the applicability intended for its RFCs in this space. If you intend implementations of this RFC to operate in the US 5.9 GHz band, respect for the life-saving mission of DSRC (to say nothing of FCC regulations) argues that for the common good those implementations should follow the same priority system that all other devices use. One could argue that it is sufficient for the RFC to be silent on the QoS data type, as in the current draft. But, given the confusion that this thread has exposed, I continue to think it better to explicitly require EDCA. Thanks, John On Sat, Mar 3, 2018 at 9:51 AM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > Hi Carlos, > > The last version, -21, is neutral with respect to which 802.11 headers to > use. It says "802.11 headers" and does not say anything about which > Subtype. It does not say "MAY use QOSData", nor does it say "MAY use Dat= a". > > The different views on this topic are the following: > > - some suggest the 802.11 Data headers is the best choice to transmit IP > datagrams on 802.11 in OCB mode at 5.9 GHz. The reasons invoked > relate to: it is widely implemented this way, and there is some > high-level doubting QoS in general across Internet. > - some suggest, on the contrary, that the best choice to transmit IP > datagrams on 802.11 in OCB mode at 5.9 GHz is the 802.11 QoS Data > headers instead. The reasons invoked are: the OCB mode at 5.9GHz is > already used to transmit very important non-IP packets (WSMP, CAM, > etc), each using QoS Data headers; there may be a risk of loss of > QoS guarantee if somebody else (IP) uses Data headers instead. > - the IEEE OCB standard permits the use of both QoSData headers _and_ > Data headers. But further standards beyond that, require the use of > QoSData headers although they dont say they require it for IP. > - a partial solution was suggested publicly, and agreed by some private > and public emails, to use a certain QoS AC value (Access Category) to > transport IP. > - many coexistence was required and necessary. > > It is because of this difference of views that we removed the > QoSData-vs-Data altogether from the IP-over-OCB draft. > > Alex > > Le 02/03/2018 =C3=A0 21:18, Carlos Jes=C3=BAs Bernardos Cano a =C3=A9crit= : > >> Hi Tony, >> >> OK, thanks. >> >> Alex: can you summarize the different views in one single e-mail, so we >> can take it from there? >> >> Thanks, >> >> Carlos >> >> On Fri, 2018-03-02 at 12:03 -0800, Tony Li wrote: >> >>> >>> >>> On Mar 2, 2018, at 11:54 AM, Carlos Jes=C3=BAs Bernardos Cano >>> c3m.es> wrote: >>>> >>>> You mean to discuss about QoS with IPv6 over 802.11-OCB? Are you >>>> requesting it to present some material to foster the discussion? >>>> >>>> We sure can allocate some time for that (I'd say that under the >>>> "rechartering" discussion slot, as I understood that this issue is >>>> closed for the WG doc, right?). >>>> >>> >>> >>> I=E2=80=99m not at all convinced that we have rough consensus on QoS ye= t. >>> >>> If we don=E2=80=99t converge by London, I would propose a hum. >>> >>> Tony >>> >>> >> > _______________________________________________ > 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 --001a1144a654155fbd05669e75fa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alex,

Thanks for this summary.
=

I would like to add a couple of points, one with regard= to standards and one with regard to regulations.

= Standards:=C2=A0
I was part of the IEEE 802.1= 1 TGp task group that wrote the 802.11p amendment.=C2=A0 I speak here only = for myself. While we were focused on making it work for DSRC in the 5.9 GHz= band, we also recognized that this "BSS-less" feature could be u= seful for others in the 802.11 community (a kind of ad hoc Wi-Fi).=C2=A0 So= , we tried not to over-constrain the definition of the OCB type of communic= ation, since we didn't know all of the use cases to which it might be a= pplied. We always expected to require EDCA for vehicular communication in 5= .9 GHz. We judged that that could be handled in the IEEE 1609 standards (or= in equivalent ETSI standards for Europe).=C2=A0 This is why 802.11 allows = DCF data frames while IEEE 1609 and EN 302 663 do not.=C2=A0 To be clear, a= WAVE device must use EDCA for all transmissions, regardless of the L3 prot= ocol.=C2=A0 It was never intended that DCF frames would compete with EDCA f= rames for channel access in a band where safety-of-life was at stake [To re= state from earlier in the thread, in such a mix DCF frames would have extre= mely high priority].=C2=A0 Perhaps we were too liberal originally. Now, 8 y= ears later, I am not aware of any other uses of the OCB type of communicati= on. Perhaps a future revision of 802.11 should omit the DCF type of data fr= ame when using OCB, to avoid any further confusion.

Regulations:
FCC 5.9 GHz regulations require that= DSRC services provide access priority to safety-of-life communication over= all other DSRC communication. Furthermore, a second class called public-sa= fety communication is required to have access priority over so-called non-p= riority communication. You can find this in CFR 47 =C2=A7 90.377 and=C2=A0 =C2=A7 95.1511.=C2=A0 These regulatory requirements are independent of the L3 prot= ocol. EDCA is the only mechanism of which I am aware to satisfy this regula= tion. More to the point, I believe that non-safety-of-life packets using DC= F would fail to meet the regulatory requirement vis a vis safety-of-life pa= ckets that use EDCA.

I am not well versed in the s= pectrum use regulations of European countries. I believe individual countri= es are permitted to regulate spectrum use based on European Norms (ENs).=C2= =A0 Perhaps EN 302 663's requirement to use EDCA will be recognized in = the regulations of some countries.

Summary:=
Personally, I'm a bit surprised at the resistance to requiri= ng EDCA in the ipwave RFC. I think the arguments are quite compelling. I th= ink the IPWAVE WG should consider the applicability intended for its RFCs i= n this space. If you intend implementations of this RFC to operate in the U= S 5.9 GHz band, respect for the life-saving mission of DSRC (to say nothing= of FCC regulations) argues that for the common good those implementations = should follow the same priority system that all other devices use.=C2=A0=C2= =A0

One could argue that it is sufficient for the = RFC to be silent on the QoS data type, as in the current draft. But, given = the confusion that this thread has exposed, I continue to think it better t= o explicitly require EDCA.

Thanks,
John<= /div>





On Sat, Mar 3,= 2018 at 9:51 AM, Alexandre Petrescu <alexandre.petrescu@gmail.= com> wrote:
Hi Carlos,

The last version, -21, is neutral with respect to which 802.11 headers to u= se.=C2=A0 It says "802.11 headers" and does not say anything abou= t which Subtype.=C2=A0 It does not say "MAY use QOSData", nor doe= s it say "MAY use Data".

The different views on this topic are the following:

- some suggest the 802.11 Data headers is the best choice to transmit IP =C2=A0 datagrams on 802.11 in OCB mode at 5.9 GHz.=C2=A0 The reasons invoke= d
=C2=A0 relate to: it is widely implemented this way, and there is some
=C2=A0 high-level doubting QoS in general across Internet.
- some suggest, on the contrary, that the best choice to transmit IP
=C2=A0 datagrams on 802.11 in OCB mode at 5.9 GHz is the 802.11 QoS Data =C2=A0 headers instead.=C2=A0 The reasons invoked are: the OCB mode at 5.9G= Hz is
=C2=A0 already used to transmit very important non-IP packets (WSMP, CAM, =C2=A0 etc), each using QoS Data headers; there may be a risk of loss of =C2=A0 QoS guarantee if somebody else (IP) uses Data headers instead.
- the IEEE OCB standard permits the use of both QoSData headers _and_
=C2=A0 Data headers.=C2=A0 But further standards beyond that, require the u= se of
=C2=A0 QoSData headers although they dont say they require it for IP.
- a partial solution was suggested publicly, and agreed by some private
=C2=A0 and public emails, to use a certain QoS AC value (Access Category) t= o
=C2=A0 transport IP.
- many coexistence was required and necessary.

It is because of this difference of views that we removed the QoSData-vs-Da= ta altogether from the IP-over-OCB draft.

Alex

Le 02/03/2018 =C3=A0 21:18, Carlos Jes=C3=BAs Bernardos Cano a =C3=A9crit= =C2=A0:
Hi Tony,

OK, thanks.

Alex: can you summarize the different views in one single e-mail, so we
can take it from there?

Thanks,

Carlos

On Fri, 2018-03-02 at 12:03 -0800, Tony Li wrote:


On Mar 2, 2018, at 11:54 AM, Carlos Jes=C3=BAs Bernardos Cano <cjbc@it.u=
c3m.es&g= t; wrote:

You mean to discuss about QoS with IPv6 over 802.11-OCB? Are you
requesting it to present some material to foster the discussion?

We sure can allocate some time for that (I'd say that under the
"rechartering" discussion slot, as I understood that this issue i= s
closed for the WG doc, right?).


I=E2=80=99m not at all convinced that we have rough consensus on QoS yet.
If we don=E2=80=99t converge by London, I would propose a hum.

Tony



_______________________________________________
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
--001a1144a654155fbd05669e75fa-- From nobody Sun Mar 4 16:02: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 C2C34126BF7 for ; Sun, 4 Mar 2018 16:02:56 -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 wDxh5e9q5HAu for ; Sun, 4 Mar 2018 16:02:55 -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 7AC2F124217 for ; Sun, 4 Mar 2018 16:02:55 -0800 (PST) Received: from resomta-po-07v.sys.comcast.net ([96.114.154.231]) by resqmta-po-06v.sys.comcast.net with ESMTP id sdahemDlPL5iAsdaheRNKt; Mon, 05 Mar 2018 00:02:55 +0000 Received: from [10.95.87.246] ([162.210.129.5]) by resomta-po-07v.sys.comcast.net with SMTP id sdYLeZFmTFD3ksdYNeqD0p; Mon, 05 Mar 2018 00:00:52 +0000 From: Tony Li Message-Id: <475FA779-6523-4891-9472-BF6391CA62A9@tony.li> Content-Type: multipart/alternative; boundary="Apple-Mail=_A08D382B-9CC2-4971-85C6-11A4875CF6A7" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Sun, 4 Mar 2018 16:00:28 -0800 In-Reply-To: Cc: Alexandre Petrescu , =?utf-8?Q?Carlos_Jes=C3=BAs_Bernardos_Cano?= , =?utf-8?Q?Fran=C3=A7ois_Simon?= , William Whyte , =?utf-8?B?SsOpcsO0bWUgSMOkcnJp?= , Dick Roy , its To: John Kenney References: <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> <5ccad588-bcd8-d179-165b-7936a34220fb@gmail.com> <006c01d3b17f$88506750$98f135f0$@eurecom.fr> <01eb01d3b248$c24c0df0$46e429d0$@gmail.com> <4d3a05bf-169f-c531-c8b4-ba2310ae3e22@gmail.com> <1520020476.3381.4.camel@it.uc3m.es> <64DE64AB-CB38-4925-9B50-1576C7DA1C0A@gmail.com> <1520021896.3381.10.camel@it.uc3m.es> <9b5daf2c-8c75-61f3-dded-31b86506c4e1@gmail.com> X-Mailer: Apple Mail (2.3445.5.20) X-CMAE-Envelope: MS4wfOR/ga+SvEsiMk6CdKkqoYaWMZRZRSlgKkdAqYINsgLrin7pZ5sSAjJezbBGzd2gCgNtxSiEq/GLPvaxOID78aQrw/e2ErlTz/2ZPmLgtBzIIYoihZmt dVsXYGfD0Tc/rgsjmXrF/pWZDNW2Bh3YAmMZ3hBwR9HFdOVKdhS4VBmmtk4fFkLQFQwetltUq+Y8cuIbocyf+KzmWJCr6E7Fd+TsU1NpxkAzIA6nJK205pDC 5ii1G24rL1W6z93N0bqDFE8s2B7hV1sRWQPteUEYAtEjKDfXct9pdVtw40x9JQkKzVdHumErl/u7RDsMe80OrPGNXeyQk3GAEiLU3hT7XOmNrGeJ8EwIETyE rV2xka+80DlfXFMGZFMFHdMQqSOCNXxMGuVA+Ln3olgYiOaQ/wU= Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data - summary X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 00:02:57 -0000 --Apple-Mail=_A08D382B-9CC2-4971-85C6-11A4875CF6A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii John, Thank you for your comment. One note: > One could argue that it is sufficient for the RFC to be silent on the = QoS data type, as in the current draft. Being silent will lead to multiple implementations making different = interpretations of intent, resulting in non-interoperable = implementations.=20 Thus, silence is insufficient and we need to say something if we intend = to publish a coherent spec. Regards, Tony --Apple-Mail=_A08D382B-9CC2-4971-85C6-11A4875CF6A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

John,

Thank you for your comment. One = note:

One could argue that it is sufficient for = the RFC to be silent on the QoS data type, as in the current = draft.

Being silent will lead to multiple implementations making = different interpretations of intent, resulting in non-interoperable = implementations. 

Thus, silence is insufficient and we need to say something if = we intend to publish a coherent spec.

Regards,
Tony

= --Apple-Mail=_A08D382B-9CC2-4971-85C6-11A4875CF6A7-- From nobody Sun Mar 4 17:02: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 1838E126C89 for ; Sun, 4 Mar 2018 17:02:17 -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 Q9fOlfzmJwLj for ; Sun, 4 Mar 2018 17:02:16 -0800 (PST) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::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 102D71201FA for ; Sun, 4 Mar 2018 17:02:15 -0800 (PST) Received: by mail-it0-x22c.google.com with SMTP id v194so8008507itb.0 for ; Sun, 04 Mar 2018 17:02:15 -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=L/Me9L7x23suVcvHQ4qqYC5mrkmXrl5FkbchUnbf2rc=; b=gbDqEbhnifv4GXXPidTWxnN63hGj4YZV7zzPbHmuo7s4Yd0qBIAuSDP310tLUPPhk0 LfO12ui4xdLc4jSU/+THM1RzwgyTAYA752KWP6xzQU3I09fHoJ9XRWhH5wCng2Rt+MJ8 QaLqu8nRievJFQ7PnnbiSTKOwIKoJ/LNFUCeYwfNaddnNdgfmvRLwBJYJ8GLQ6d1LyO7 l0g9BtHdPvdebevSrN6Qcu9FRknORsYWrGRWgiEOOsr/7Kb66I0x1Jv4iIlD+Gt/Q0I1 tOF1ZScKhCDCbhSYpCCBmIGBnammD0FrUVCtGXXD34JfvDIu2aSd/6Fu+hyWz7sZBWDY 1Czw== 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=L/Me9L7x23suVcvHQ4qqYC5mrkmXrl5FkbchUnbf2rc=; b=E/j4y8y30KVpdQGB3O8m1CmeCdpH7W9X6hoJ2q5UEXyptv0N80iPrl5cVFGYluhxA0 2VP5GUF+OzNDilIKCayCFoByrotNPT9YzwAAiApOMhOO7xleLBzWWj9ojJo3dmqQezis FPQ45o7jOxGgRu4fTJaxLXDvjL6AFDDW2Zjk97N2DS6Y5nZ2CFfZGYB1aIzMPLNCEtb8 G42deWMyHEvGKKoOE0Tw2blfctp0U1wZDMWYuqFp12Ov3xGkjBkhwN2TEOHwTr3ZWUHD NU0tmrSB2B7AG5xHeVN1oOgKUuYzwMY1ufXlMndfuK8popxsfBISX/eXZg0y/6nSGc83 iscQ== X-Gm-Message-State: AElRT7G0F1mo/DUhb5JB+rSoIAoW9S7XbluBZZfRLY5bye+4x4C37t5O 8jvd7FfeJzzW5F8cazHx3zBq8maGnaXpJrV84ZBgPA== X-Google-Smtp-Source: AG47ELu7jFNL5ajsAwrMucYw9JE4t5i5BVXxNJKbiTjnw/gNJE+458I6tHeiAhFB6ycjy36paP3XOBeec68ND0Q/3sQ= X-Received: by 10.36.217.138 with SMTP id p132mr8209712itg.41.1520211735034; Sun, 04 Mar 2018 17:02:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.24.135 with HTTP; Sun, 4 Mar 2018 17:02:14 -0800 (PST) In-Reply-To: <475FA779-6523-4891-9472-BF6391CA62A9@tony.li> References: <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> <5ccad588-bcd8-d179-165b-7936a34220fb@gmail.com> <006c01d3b17f$88506750$98f135f0$@eurecom.fr> <01eb01d3b248$c24c0df0$46e429d0$@gmail.com> <4d3a05bf-169f-c531-c8b4-ba2310ae3e22@gmail.com> <1520020476.3381.4.camel@it.uc3m.es> <64DE64AB-CB38-4925-9B50-1576C7DA1C0A@gmail.com> <1520021896.3381.10.camel@it.uc3m.es> <9b5daf2c-8c75-61f3-dded-31b86506c4e1@gmail.com> <475FA779-6523-4891-9472-BF6391CA62A9@tony.li> From: John Kenney Date: Sun, 4 Mar 2018 17:02:14 -0800 Message-ID: To: Tony Li Cc: Alexandre Petrescu , =?UTF-8?Q?Carlos_Jes=C3=BAs_Bernardos_Cano?= , =?UTF-8?Q?Fran=C3=A7ois_Simon?= , William Whyte , =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , Dick Roy , its Content-Type: multipart/alternative; boundary="001a113736f47354c205669fe09a" Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data - summary X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 01:02:17 -0000 --001a113736f47354c205669fe09a Content-Type: text/plain; charset="UTF-8" I fully agree with Tony. John On Sun, Mar 4, 2018 at 4:00 PM, Tony Li wrote: > > John, > > Thank you for your comment. One note: > > One could argue that it is sufficient for the RFC to be silent on the QoS > data type, as in the current draft. > > > Being silent will lead to multiple implementations making different > interpretations of intent, resulting in non-interoperable implementations. > > Thus, silence is insufficient and we need to say something if we intend to > publish a coherent spec. > > Regards, > Tony > > -- 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 --001a113736f47354c205669fe09a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I fully agree with Tony.

John


= On Sun, Mar 4, 2018 at 4:00 PM, Tony Li <tony.li@tony.li> wrot= e:

John,

Thank yo= u for your comment. One note:

One could argue = that it is sufficient for the RFC to be silent on the QoS data type, as in = the current draft.

Bei= ng silent will lead to multiple implementations making different interpreta= tions of intent, resulting in non-interoperable implementations.=C2=A0

Thus, silence is insufficient and we need to say somet= hing if we intend to publish a coherent spec.

Rega= rds,
Tony




--
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
--001a113736f47354c205669fe09a-- From nobody Mon Mar 5 04:58: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 56D8512D7E2 for ; Mon, 5 Mar 2018 04:58:12 -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 TEU91pPJj1da for ; Mon, 5 Mar 2018 04:58:10 -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 4935512D778 for ; Mon, 5 Mar 2018 04:58:10 -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 w25Cw8UG094749 for ; Mon, 5 Mar 2018 13:58:08 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 07347203B73 for ; Mon, 5 Mar 2018 13:58:08 +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 F1866203AF9 for ; Mon, 5 Mar 2018 13:58:07 +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 w25Cw7Xi013985 for ; Mon, 5 Mar 2018 13:58:07 +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> <00f801d3af1d$f20ce4c0$d626ae40$@gmail.com> <002b01d3af21$6e779a70$4b66cf50$@eurecom.fr> <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> From: Alexandre Petrescu Message-ID: <5c3e6699-67c5-cc6e-efb5-1ee68a9e03c1@gmail.com> Date: Mon, 5 Mar 2018 13:58: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 - 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: Mon, 05 Mar 2018 12:58:12 -0000 just some implementations aspects worth considering when considering the QoSData question. Le 01/03/2018 à 15:32, Alexandre Petrescu a écrit : > I received some feedback from programmer. > > Le 28/02/2018 à 23:48, Abdussalam Baryun a écrit : > [...] >> 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, > > Here is the QoS problem for IP over 802.11 OCB in implementations. > > In short, in open source on linux, we dont know how to send IP packets > transported as 802.11 QoSData, all IP packets are transported as 802.11 > Data instead. > > - if you ping -Q at 5.9GHz in OCB mode, the DSCP fields do get >   set properly in IP headers of Echorequest, but there is no .11 QoSData >   headers in packets.  Normally, one expects the QoSData headers to be >   present there when the DSCP (an IP field) is set. > > - if you want to modify kernel, and force always to use QoSData headers >   on WiFi, including OCB at 5.9GHz, there is a net/mac80211/tx.c file >   with a flag called wme_sta that you could set to true.  But take care >   that the C comments there say that it's not normal to use QoSData >   headers in OCB mode, because a terminal sending QoSData has no >   guarantee that receivers also use QoSData (the negotiation of QoS >   capabilities are absent in OCB). In private, a partner pointed to an additional method to trigger the making of QoSData headers, although not sure whether it's for IP or non-IP. Use setsockopt to set a distinct priority per socket (BK, BE, VI, VO): > setsockopt(Sock_VI,SOL_SOCKET ,SO_PRIORITY, &PRIORITY_VI,sizeof(PRIORITY_VI)); > setsockopt(Sock_VO,SOL_SOCKET ,SO_PRIORITY, &PRIORITY_VO,sizeof(PRIORITY_VO)); > setsockopt(Sock_BE,SOL_SOCKET ,SO_PRIORITY, &PRIORITY_BE,sizeof(PRIORITY_BE)); > setsockopt(Sock_BK,SOL_SOCKET ,SO_PRIORITY, &PRIORITY_BK,sizeof(PRIORITY_BK)); My analysis of it is the following: this method to generate packets with QoSData headers seems valuable, but it seems dedicated to a particular application. If I have an app that sends CAM messages then I setsockopt like above in that app, and thus the CAM packets are preceded by QoSData. On another hand, one may want _all_ apps in the computer to use QoSData if at 5.9GHz in OCB mode, not just some application. I think setsockopt may not be fully appropriate for that goal. One may want some IP app to setsockopt one priority and another IP app to setsockopt another priority. Alex > > As you can see, this can be long to try and fix. > > Until then I will propose to set QoS aside from IP-over-OCB at this time. > > Alex > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Mon Mar 5 07:41: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 1A55B12D875 for ; Mon, 5 Mar 2018 07:41:16 -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 GOiTEnhSNAYg for ; Mon, 5 Mar 2018 07:41:14 -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 CADD612D86E for ; Mon, 5 Mar 2018 07:41:14 -0800 (PST) Received: from resomta-po-14v.sys.comcast.net ([96.114.154.238]) by resqmta-po-08v.sys.comcast.net with ESMTP id ssEDebDuVOyyWssEkedkA8; Mon, 05 Mar 2018 15:41:14 +0000 Received: from [192.168.1.6] ([24.130.209.5]) by resomta-po-14v.sys.comcast.net with SMTP id ssEieaio0Fcc8ssEjebA6v; Mon, 05 Mar 2018 15:41:14 +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: <5c3e6699-67c5-cc6e-efb5-1ee68a9e03c1@gmail.com> Date: Mon, 5 Mar 2018 07:41:12 -0800 Cc: its@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: 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> <5c3e6699-67c5-cc6e-efb5-1ee68a9e03c1@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3445.5.20) X-CMAE-Envelope: MS4wfMw6j1usBP8UkhZRKIlUDdY1Nedg7w3baJtP/jchM1Oz1nlnxLE3+OZIuw8pWWSwckvii8hozrUuj3vBPVqPdmc0jcFiPyqUVlgl4g3TZjUpJGd4CRjA ZVCjWuKkFpIRcyQJKrG602uO7wn2nvofS/5kNf0h5ShSJ52JceYSCGJSbs+6aoIf6L2utX+C0op9Ww== 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: Mon, 05 Mar 2018 15:41:16 -0000 > One may want some IP app to setsockopt one priority and another IP app = to setsockopt another priority. One may want many things. As previously noted, there is very little use = of QoS in the Internet. Almost no applications do this today. Please remember that most of the IP packets that will ever pass through = an OCB system will be sourced somewhere else in the Internet, off of = OCB. Expecting someone on another continent to change their programming = to suit our requirements is not reasonable. Tony From nobody Mon Mar 5 08:50: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 8E17012D94F for ; Mon, 5 Mar 2018 08:50:43 -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 swgGmbASU7B2 for ; Mon, 5 Mar 2018 08:50:41 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d: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 A6E9112D94A for ; Mon, 5 Mar 2018 08:50:41 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id s188so21370908qkb.2 for ; Mon, 05 Mar 2018 08:50:41 -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=D6CdoyDqDxKnxX/FnBgzdraDND7lEKDUnLUFd0RZfxY=; b=BXSL3j80zdN5YMlyekyZGdfuLHPp2Ydz5J6JsOzCCRSC9Ok9G+8tip229oKgit1o7l scen0E04Gfpv02h0ytdNA07tUfA+0e7mlKLGFpHLqD18kOPU34OA7aJQu8a9XJ4C4zYz r7rzFaj450kcN8ula4zF1M3hJPYfRNKHR0bM65IyX5lDyaYjMFdYVPbSi4RtYLdLZowO OhpshlhYaANV2c/RgMwSwnVDwzN60PfSrfzjoqo29QwSzTXgDcs/qoDuNiJfUsO4ecCq B0QaI/B/Lnsxzq9mE9VznZEFa86mYt9HgYBP/go6Eb9Fq51CKoc2pXw91cjnWAvFnIzc VDDg== 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=D6CdoyDqDxKnxX/FnBgzdraDND7lEKDUnLUFd0RZfxY=; b=TxxxdAMSEWJQLQ5LDCkOIa0Uhg0fHrjPJtNGQEmV0/VQs+JrWAvxAVRflnvm9LwnIL 41H+6EacoERrrxNEAUYEq8N6utZwohEDUl2CP2lYVA/RcG2M4Bk4Qiov2pGEr2oqh1wJ BHcryYql85QC3izDpoKMtIuy/re/dY2dHj+8cNJk0kT0GKER1h+AmGN7N0fnF7uUsF12 EeZBBZMciSiurHQpVyGIxxm1rZi2eSDIWvz5TGbQR9EAuNh++aFO2tIP643zj4mGplGu v/tuNEM8WIeV4i4WUGFdCI04MzQnslWPjKSS4Mo+huuBt6T+wsqJLmTKLmNezvEA86tW 3OoQ== X-Gm-Message-State: AElRT7H+WvVY6lSc0OyCOmeEh1MpdDwj+gbrPCqLnIwFVtkoH8B0DdI9 CNqSvgGUhxogGVwnMg5aHN8= X-Google-Smtp-Source: AG47ELv7NX5f31zHmNghPATXGxLac2Yub5u/ZrZ1/054uzBKSHaxAMnk8mae7daqAw+wI8pd0sKVxg== X-Received: by 10.55.191.1 with SMTP id p1mr23233833qkf.97.1520268640790; Mon, 05 Mar 2018 08:50:40 -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 s69sm8518121qke.55.2018.03.05.08.50.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Mar 2018 08:50:39 -0800 (PST) From: =?iso-8859-1?Q?Fran=E7ois_Simon?= To: "'Tony Li'" , "'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> <00f801d3af1d$f20ce4c0$d626ae40$@gmail.com> <002b01d3af21$6e779a70$4b66cf50$@eurecom.fr> <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> <5c3e6699-67c5-cc6e-efb5-1ee68a9e03c1@gmail.com> In-Reply-To: Date: Mon, 5 Mar 2018 11:50:39 -0500 Message-ID: <003001d3b4a2$18129910$4837cb30$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0031_01D3B478.2F3F5030" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHelLAw/aN7IRfcwiTBG/gKcgHVEwGONDnFAivYBTcBDgW0eQFK9evKAbex+qQCF4nJkAMphqaUAo/H9voB/QVRSwGgjFsGAtvA4TEBm9hPkAKafOT2Adw4FVkBhOPELQGWvTywAi3roigCOQ33tAHnh1geon+NlfA= Content-Language: en-us 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: Mon, 05 Mar 2018 16:50:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0031_01D3B478.2F3F5030 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable One may want many things. As previously noted, there is very little use = of QoS in the Internet. Almost no applications do this today. Please remember that most of the IP packets that will ever pass through = an OCB system will be sourced somewhere else in the Internet, off of OCB. Expecting someone on another continent to change their programming to = suit our requirements is not reasonable. Tony Sir, While your argument may be valid, the fact is the IP application is = using OCB as a segment of the communication link (choice of IPWAVE WG). In = the US IEEE 802.11 OCB also provide service to Safety applications which in = many instances remain local (i.e., V2V). =93Communications involving the = safety of life have access priority over all other DSRCS communications=94 [Ref: = CFR =A7 95.1511]. If the IP application is not a Safety application, it will be ranked as of lower priority. Thus, the requirement of QoSdata and EDCA. Fygs -----Original Message----- From: its On Behalf Of Tony Li Sent: Monday, March 05, 2018 10:41 AM To: Alexandre Petrescu Cc: its@ietf.org Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in = IPv6-over-802.11-OCB - implementations > One may want some IP app to setsockopt one priority and another IP app = to setsockopt another priority. One may want many things. As previously noted, there is very little use = of QoS in the Internet. Almost no applications do this today. Please remember that most of the IP packets that will ever pass through = an OCB system will be sourced somewhere else in the Internet, off of OCB. Expecting someone on another continent to change their programming to = suit our requirements is not reasonable. Tony _______________________________________________ its mailing list its@ietf.org =20 https://www.ietf.org/mailman/listinfo/its ------=_NextPart_000_0031_01D3B478.2F3F5030 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipwave] 802.11 Data vs 802.11 QoS Data in = IPv6-over-802.11-OCB - implementations

One may want = many things.  As previously noted, there is very little use of QoS = in the Internet. Almost no applications do this = today.

Please = remember that most of the IP packets that will ever pass through an OCB = system will be sourced somewhere else in the Internet, off of OCB. = Expecting someone on another continent to change their programming to = suit our requirements is not reasonable.

Tony

Sir,

While your = argument may be valid, the fact is the IP application is using OCB as a = segment of the communication link (choice of IPWAVE WG).  In the US IEEE 802.11 OCB = also provide service to Safety applications which in many instances = remain local (i.e., V2V).  “Communications involving the = safety of life have access priority over all other DSRCS = communications” [Ref: CFR =A7 95.1511]. If the IP application is = not a Safety application, it will be ranked as of lower priority. Thus, = the requirement of QoSdata and EDCA.

Fygs

-----Original = Message-----
From: its <its-bounces@ietf.org> On Behalf Of Tony Li
Sent: Monday, March 05, 2018 10:41 AM
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Cc: its@ietf.org
Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in = IPv6-over-802.11-OCB - implementations

> One may = want some IP app to setsockopt one priority and another IP app to = setsockopt another priority.


One may want = many things.  As previously noted, there is very little use of QoS = in the Internet. Almost no applications do this today.

Please remember = that most of the IP packets that will ever pass through an OCB system = will be sourced somewhere else in the Internet, off of OCB. Expecting = someone on another continent to change their programming to suit our = requirements is not reasonable.

Tony

_______________________________________________

its mailing = list

its@ietf.org

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

------=_NextPart_000_0031_01D3B478.2F3F5030-- From nobody Mon Mar 5 09:02: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 47C5612D86A for ; Mon, 5 Mar 2018 09:02: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 fkeAhco3dvJd for ; Mon, 5 Mar 2018 09:02:13 -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 68D0C12D94F for ; Mon, 5 Mar 2018 09:02:11 -0800 (PST) Received: from resomta-po-03v.sys.comcast.net ([96.114.154.227]) by resqmta-po-07v.sys.comcast.net with ESMTP id stQoeW2hq4kZfstV5ezGKY; Mon, 05 Mar 2018 17:02:11 +0000 Received: from [10.95.88.71] ([162.210.129.5]) by resomta-po-03v.sys.comcast.net with SMTP id stSveb5ic2kNUstSyevDps; Mon, 05 Mar 2018 17:00:09 +0000 From: tony.li@tony.li Message-Id: <10A97EA7-857B-4658-AEEC-3A23B096CF49@tony.li> Content-Type: multipart/alternative; boundary="Apple-Mail=_A2B16CE2-C5AC-4A84-8A37-68B6A6D0C489" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Mon, 5 Mar 2018 08:59:57 -0800 In-Reply-To: <003001d3b4a2$18129910$4837cb30$@gmail.com> Cc: Alexandre Petrescu , its@ietf.org To: =?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> <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> <5c3e6699-67c5-cc6e-efb5-1ee68a9e03c1@gmail.com> <003001d3b4a2$18129910$4837cb30$@gmail.com> X-Mailer: Apple Mail (2.3445.5.20) X-CMAE-Envelope: MS4wfB5GBaySdgwtAQerG9wiMuyxKvEAn5nbW8wWHppDK5g0ty8J+05xgCiqs2AHAJYUVnQ3D+Cn02kMyPUvyUIBrcHDoz0e61X52fmEZtISlPzn3gExl4ub y1CtIAk/48nGXvGznzoNk+8hojw2BugCfQ0d96EDytwU6wO7sbvl9AxlQn94vKHOLjKtbE0rew6z0PtXSOJONcG4CmBRQryxamOOtNw9IjzlSFDNXUMk0spm 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: Mon, 05 Mar 2018 17:02:15 -0000 --Apple-Mail=_A2B16CE2-C5AC-4A84-8A37-68B6A6D0C489 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > While your argument may be valid, the fact is the IP application is = using OCB as a segment of the communication link (choice of IPWAVE WG). = In the US IEEE 802.11 OCB also provide service to Safety applications = which in many instances remain local (i.e., V2V). =E2=80=9CCommunications= involving the safety of life have access priority over all other DSRCS = communications=E2=80=9D [Ref: CFR =C2=A7 95.1511]. If the IP application = is not a Safety application, it will be ranked as of lower priority. = Thus, the requirement of QoSdata and EDCA. Bonjour Fran=C3=A7ois, This point was (I think), already conceded and not the issue at hand. The point that I was trying to make is that expecting IP applications to = have correctly set QoS properties is overly optimistic. Much of the IP traffic will be coming through OCB attached routers = connected to the Internet, coming from servers run by people who have = never, ever heard of DSRC/802.11p/OCB. And application writers even more = removed. Tony --Apple-Mail=_A2B16CE2-C5AC-4A84-8A37-68B6A6D0C489 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

While your argument may be valid, the fact = is the IP application is using OCB as a segment of the = communication link (choice of IPWAVE = WG).  In the US IEEE 802.11 OCB also provide service to Safety = applications which in many instances remain local (i.e., V2V).  = =E2=80=9CCommunications involving the safety of life have access = priority over all other DSRCS communications=E2=80=9D [Ref: CFR =C2=A7 = 95.1511]. If the IP application is not a Safety application, it will be = ranked as of lower priority. Thus, the requirement of QoSdata and = EDCA.


Bonjour = Fran=C3=A7ois,

This point was (I think), already conceded and not the issue = at hand.

The = point that I was trying to make is that expecting IP applications to = have correctly set QoS properties is overly optimistic.

Much of the IP traffic = will be coming through OCB attached routers connected to the Internet, = coming from servers run by people who have never, ever heard of = DSRC/802.11p/OCB. And application writers even more removed.

Tony

= --Apple-Mail=_A2B16CE2-C5AC-4A84-8A37-68B6A6D0C489-- From nobody Mon Mar 5 10:20:17 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 4C8D812E87D; Mon, 5 Mar 2018 10:20:08 -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.74.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152027400826.14551.2766762404227800440@ietfa.amsl.com> Date: Mon, 05 Mar 2018 10:20:08 -0800 Archived-At: Subject: [ipwave] I-D Action: draft-ietf-ipwave-vehicular-networking-02.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, 05 Mar 2018 18:20:16 -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 : IP-based Vehicular Networking: Use Cases, Survey and Problem Statement Author : Jaehoon Paul Jeong Filename : draft-ietf-ipwave-vehicular-networking-02.txt Pages : 52 Date : 2018-03-05 Abstract: This document discusses use cases, survey, and problem statement on IP-based vehicular networks, which are considered a key component of Intelligent Transportation Systems (ITS). The main topics of vehicular networking are vehicle-to-vehicle (V2V), vehicle-to- infrastructure (V2I), and infrastructure-to-vehicle (I2V) networking. First, this document surveys use cases using V2V and V2I networking. Second, this document deals with some critical aspects in vehicular networking, such as vehicular network architectures, standardization activities, IP address autoconfiguration, routing, mobility management, DNS naming service, service discovery, and security and privacy. For each aspect, this document discusses problem statement to analyze the gap between the state-of-the-art techniques and requirements in IP-based vehicular networking. Finally, this document articulates discussions including the summary and analysis of vehicular networking aspects and raises deployment issues. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipwave-vehicular-networking/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-02 https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-vehicular-networking-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-vehicular-networking-02 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 Mar 5 11:32: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 69E3B12D93E for ; Mon, 5 Mar 2018 11:32:08 -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 tVyrdeBZOlvv for ; Mon, 5 Mar 2018 11:32:06 -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 4AE8812D7F6 for ; Mon, 5 Mar 2018 11:32:06 -0800 (PST) Received: by mail-ot0-x22e.google.com with SMTP id m22so16019016otf.10 for ; Mon, 05 Mar 2018 11:32:06 -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=jR+9I+YQXd01L+duUK1YIV7xltXGUBJ52goe4LINmxA=; b=ol8DRYBJUHkJLeJSQXzwS/PRy3L5t7BYSeiSF03dI2E7KczCQI08uVYWnIHEsBamwQ W3kw84qfa7EcdlVXmKwUjFPp8g8RvCWxSoyc2LHLLC27R8gJm7FxIyC3VEXD386mQi0I uPe70Y2wAjOzkSgMDg1SFdvyJgdAOjEkCxx6UNTeT7AlfdeF9YcKp25tKEZQiggmEUvJ w5Zjr71Be2P9PLIcinFYvB6QCU8OH2BK9kaMxp04HUYcYoaWwDIoPZ/gE9iVaR2nQC37 r5f8d+jVjbwKhTK1anfENiwKVu0RrCiZc4MRFGYFPcE49w5PdtL6PSKP8QC0l2NmU5m6 JyZw== 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=jR+9I+YQXd01L+duUK1YIV7xltXGUBJ52goe4LINmxA=; b=CnyGLOEJYHrjUK4ZUv+GMDoPK03vvXwCQiWYMwh5g9dG59tbLPUz4wNVU1Dpf4d04o GXHgRhx9IjR4Mxnbr58neGGzyCh0asMXA9IqG0Z/uyBFo8nXXZH3FNaAp1hOALLEMtYM tFfneItcCUQNg/bky1dBpy7ePN11Q9m3WVkJCXjtR1BYUwQnsrRfkIgmcbIlynshu8Ot sXt2BwBLZb4on2jdkdZljI+lFL43KvZ5FoYPxB03pfAqlIbIti0Mx4jeINTyl/QzJCFu LGJRGkHH1OhO0AlzwCKeQxdoBF9rk4XiLRZWCR8zWFH/tuStktQpsGo/EZMkXC2zFTAZ D+Aw== X-Gm-Message-State: AElRT7Efi/pI5Bjh1uSgSBxYUm18+5y1YV0eVRECFgKneRew27f/FjS4 DXSvFWZ8ghiPXE5O8+7N5SpdO+tw4Ff/gsqIZWQ= X-Google-Smtp-Source: AG47ELvCLUhUijXhqqyxIpGJnZGXM78CqTCROxyBG1PVpL6A+i81ANZQT0YhbIETYanRnaLZCh3n/zoaiUHRQaSrJl8= X-Received: by 10.157.65.237 with SMTP id v42mr11569125oti.156.1520278325598; Mon, 05 Mar 2018 11:32:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.36 with HTTP; Mon, 5 Mar 2018 11:32:05 -0800 (PST) In-Reply-To: References: <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> <5ccad588-bcd8-d179-165b-7936a34220fb@gmail.com> <006c01d3b17f$88506750$98f135f0$@eurecom.fr> <01eb01d3b248$c24c0df0$46e429d0$@gmail.com> <4d3a05bf-169f-c531-c8b4-ba2310ae3e22@gmail.com> <1520020476.3381.4.camel@it.uc3m.es> <64DE64AB-CB38-4925-9B50-1576C7DA1C0A@gmail.com> <1520021896.3381.10.camel@it.uc3m.es> <9b5daf2c-8c75-61f3-dded-31b86506c4e1@gmail.com> From: Abdussalam Baryun Date: Mon, 5 Mar 2018 21:32:05 +0200 Message-ID: To: John Kenney Cc: Alexandre Petrescu , Tony Li , its , =?UTF-8?Q?Fran=C3=A7ois_Simon?= , William Whyte , =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , =?UTF-8?Q?Carlos_Jes=C3=BAs_Bernardos_Cano?= , Dick Roy Content-Type: multipart/alternative; boundary="94eb2c1c1cec8e9fc50566af619f" Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data - summary X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 19:32:08 -0000 --94eb2c1c1cec8e9fc50566af619f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Mar 5, 2018 at 1:20 AM, John Kenney wrote: > Hi Alex, > > Thanks for this summary. > > I would like to add a couple of points, one with regard to standards and > one with regard to regulations. > > * Standards: * > I was part of the IEEE 802.11 TGp task group that wrote the 802.11p > amendment. I speak here only for myself. While we were focused on making > it work for DSRC in the 5.9 GHz band, we also recognized that this > "BSS-less" feature could be useful for others in the 802.11 community (a > kind of ad hoc Wi-Fi). So, we tried not to over-constrain the definition > of the OCB type of communication, since we didn't know all of the use cas= es > to which it might be applied. We always expected to require EDCA for > vehicular communication in 5.9 GHz. We judged that that could be handled = in > the IEEE 1609 standards (or in equivalent ETSI standards for Europe). Th= is > is why 802.11 allows DCF data frames while IEEE 1609 and EN 302 663 do > not. To be clear, a WAVE device must use EDCA for all transmissions, > regardless of the L3 protocol. It was never intended that DCF frames wou= ld > compete with EDCA frames for channel access in a band where safety-of-lif= e > was at stake [To restate from earlier in the thread, in such a mix DCF > frames would have extremely high priority]. Perhaps we were too liberal > originally. Now, 8 years later, I am not aware of any other uses of the O= CB > type of communication. Perhaps a future revision of 802.11 should omit th= e > DCF type of data frame when using OCB, to avoid any further confusion. > +1 > > *Regulations:* > FCC 5.9 GHz regulations require that DSRC services provide access priorit= y > to safety-of-life communication over all other DSRC communication. > Furthermore, a second class called public-safety communication is require= d > to have access priority over so-called non-priority communication. You ca= n > find this in CFR 47 =C2=A7 90.377 and =C2=A7 95.1511. These regulatory > requirements are independent of the L3 protocol. EDCA is the only mechani= sm > of which I am aware to satisfy this regulation. More to the point, I > believe that non-safety-of-life packets using DCF would fail to meet the > regulatory requirement vis a vis safety-of-life packets that use EDCA. > > I am not well versed in the spectrum use regulations of European > countries. I believe individual countries are permitted to regulate > spectrum use based on European Norms (ENs). Perhaps EN 302 663's > requirement to use EDCA will be recognized in the regulations of some > countries. > > *Summary:* > Personally, I'm a bit surprised at the resistance to requiring EDCA in th= e > ipwave RFC. > I agree > I think the arguments are quite compelling. I think the IPWAVE WG should > consider the applicability intended for its RFCs in this space. If you > intend implementations of this RFC to operate in the US 5.9 GHz band, > respect for the life-saving mission of DSRC (to say nothing of FCC > regulations) argues that for the common good those implementations should > follow the same priority system that all other devices use. > Accepting priority is important for this WG and within our use-cases. AB --94eb2c1c1cec8e9fc50566af619f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Mar 5, 2018 at 1:20 AM, John Kenney <jkenney@us.toyota= -itc.com> wrote:
Hi Al= ex,

Thanks for this summary.

I = would like to add a couple of points, one with regard to standards and one = with regard to regulations.

Stand= ards:=C2=A0
I was part of the IEEE 802.11 TGp task group = that wrote the 802.11p amendment.=C2=A0 I speak here only for myself. While= we were focused on making it work for DSRC in the 5.9 GHz band, we also re= cognized that this "BSS-less" feature could be useful for others = in the 802.11 community (a kind of ad hoc Wi-Fi).=C2=A0 So, we tried not to= over-constrain the definition of the OCB type of communication, since we d= idn't know all of the use cases to which it might be applied. We always= expected to require EDCA for vehicular communication in 5.9 GHz. We judged= that that could be handled in the IEEE 1609 standards (or in equivalent ET= SI standards for Europe).=C2=A0 This is why 802.11 allows DCF data frames w= hile IEEE 1609 and EN 302 663 do not.=C2=A0 To be clear, a WAVE device must= use EDCA for all transmissions, regardless of the L3 protocol.=C2=A0 It wa= s never intended that DCF frames would compete with EDCA frames for channel= access in a band where safety-of-life was at stake [To restate from earlie= r in the thread, in such a mix DCF frames would have extremely high priorit= y].=C2=A0 Perhaps we were too liberal originally. Now, 8 years later, I am = not aware of any other uses of the OCB type of communication. Perhaps a fut= ure revision of 802.11 should omit the DCF type of data frame when using OC= B, to avoid any further confusion.

<= div>+1=C2=A0

=C2= =A0

<= /u>
Regulations:
FCC 5.9 GHz regulations require= that DSRC services provide access priority to safety-of-life communication= over all other DSRC communication. Furthermore, a second class called publ= ic-safety communication is required to have access priority over so-called = non-priority communication. You can find this in CFR 47 =C2=A7 90.377 and= =C2=A0 =C2=A7 95.1511.=C2=A0 These regulatory requirements are independent of the L3 prot= ocol. EDCA is the only mechanism of which I am aware to satisfy this regula= tion. More to the point, I believe that non-safety-of-life packets using DC= F would fail to meet the regulatory requirement vis a vis safety-of-life pa= ckets that use EDCA.

I am not well versed in the s= pectrum use regulations of European countries. I believe individual countri= es are permitted to regulate spectrum use based on European Norms (ENs).=C2= =A0 Perhaps EN 302 663's requirement to use EDCA will be recognized in = the regulations of some countries.

Summary:=
Personally, I'm a bit surprised at the resistance to requiri= ng EDCA in the ipwave RFC.

I ag= ree
=C2=A0
I think t= he arguments are quite compelling. I think the IPWAVE WG should consider th= e applicability intended for its RFCs in this space. If you intend implemen= tations of this RFC to operate in the US 5.9 GHz band, respect for the life= -saving mission of DSRC (to say nothing of FCC regulations) argues that for= the common good those implementations should follow the same priority syst= em that all other devices use.=C2=A0=C2=A0
Accepting priority is important for this WG and within=C2=A0our= use-cases.

AB


--94eb2c1c1cec8e9fc50566af619f-- From nobody Mon Mar 5 12:03: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 E6AE012DB6D for ; Mon, 5 Mar 2018 12:03:03 -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 BPBJ7rguh9zX for ; Mon, 5 Mar 2018 12:02:54 -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 857E412E6D7 for ; Mon, 5 Mar 2018 12:02:49 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id l206so22167991qke.1 for ; Mon, 05 Mar 2018 12:02: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:thread-index:content-language; bh=9WBsZ9H3bA+8FuHkgIgrXj2oiIIzhkO3sFyP9y+Gd6I=; b=hi7rl7jqQLh0DlzvW5p9y6ezSG2n/ilnRHEuRGRjnewaff5ARaw9yTWKAf3Xf2syBn I8MSfo6LIhzJli3/XL1rRZHvTNya646lRPM/XHv8/SjDRlVYlPtbuoCFFBChf2RI+HXI 7NXTV5O+UKGyWnyzD9zr4GKsdz4gnFa5ygexvCqDSj2vlrutkp3nOmVR08l+3mJq2V1y ODEIOCLWKvcd/QGR10sqBAb2f+X8DoO/2zgTzMGfbXzpboFlvNMozYb1sqY8zbWXOD0P Ind5pmGbcTN/cUicDk6/LVBsInUa+ZzGLo9OPEBvhRf6+3D3HNOnugzqydq9MdURMJbh VhgQ== 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=9WBsZ9H3bA+8FuHkgIgrXj2oiIIzhkO3sFyP9y+Gd6I=; b=lVKYkrqujymkjvEDmRFH5X+7s82E0RbTTRA3J6Pw+Jf2EnaB3Q735C5m938Ie532II 6Gtiec6kOFbYpidW4h97KKyfwhXk8TRdWZdWB03KjcbfgYGa+XJjTBkJOStQ0qR1LaZx 80dH5VHs0EQC+D8a+WgLczFsPIiRyZv6Hfg0hm4hJdUyU6mQQApq5s+epQjDzLQT70Z9 DQfAUq1RbupZfNYK7HUg7iaKvtnaAq+u0qT4l9Gxm4UJyGdW+u2SbBKcNmTdphUDNKTp ZB10X3xWZvCC1arigpJcOhj4FT8Ws28PUVuC2xDiP5AAc6zRQqBQHPJrJoSxYaQC/SkP J2Rw== X-Gm-Message-State: AElRT7HphQpsnw6FNHR3dGpkHhGshi0HVS62GS1h6IIpomofx7A6lFTb oH0Gx4POo10YHVXSpmtYWI0= X-Google-Smtp-Source: AG47ELsUGFDA0Vmy8HiodoA14HMCFT+AaE9n7/8rtjKAraBrMXb4XY80ZcRv2PlPC3VrfP+a0k0f/w== X-Received: by 10.55.60.2 with SMTP id j2mr24283626qka.89.1520280168698; Mon, 05 Mar 2018 12:02: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 z9sm9566810qtb.49.2018.03.05.12.02.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Mar 2018 12:02:47 -0800 (PST) From: =?utf-8?Q?Fran=C3=A7ois_Simon?= To: "'Abdussalam Baryun'" , "'John Kenney'" Cc: "'Alexandre Petrescu'" , "'Tony Li'" , "'its'" , "'William Whyte'" , =?utf-8?B?J0rDqXLDtG1lIEjDpHJyaSc=?= , =?utf-8?Q?'Carlos_Jes=C3=BAs_Bernardos_Cano'?= , "'Dick Roy'" References: <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> <5ccad588-bcd8-d179-165b-7936a34220fb@gmail.com> <006c01d3b17f$88506750$98f135f0$@eurecom.fr> <01eb01d3b248$c24c0df0$46e429d0$@gmail.com> <4d3a05bf-169f-c531-c8b4-ba2310ae3e22@gmail.com> <1520020476.3381.4.camel@it.uc3m.es> <64DE64AB-CB38-4925-9B50-1576C7DA1C0A@gmail.com> <1520021896.3381.10.camel@it.uc3m.es> <9b5daf2c-8c75-61f3-dded-31b86506c4e1@gmail.com> In-Reply-To: Date: Mon, 5 Mar 2018 15:02:45 -0500 Message-ID: <006101d3b4bc$ef0ffc90$cd2ff5b0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0062_01D3B493.063D28E0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHelLAw/aN7IRfcwiTBG/gKcgHVEwGgjFsGAtvA4TEBm9hPkAKafOT2Adw4FVkBhOPELQGWvTywAi3roigCMY3M2QG+qPmMAk3ISSACcn5T7gIMtPdxAnIz6LEBWx12/QGdbG9TAqnDZbYB5vAm+gFGON3kon2WJ3A= Content-Language: en-us Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data - summary X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 20:03:06 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0062_01D3B493.063D28E0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable ABSOLUTELY ! =20 Fygs =20 From: Abdussalam Baryun =20 Sent: Monday, March 05, 2018 2:32 PM To: John Kenney Cc: Alexandre Petrescu ; Tony Li = ; its ; Fran=C3=A7ois Simon = ; William Whyte ; = J=C3=A9r=C3=B4me H=C3=A4rri ; Carlos = Jes=C3=BAs Bernardos Cano ; Dick Roy = Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data - summary =20 =20 =20 On Mon, Mar 5, 2018 at 1:20 AM, John Kenney > wrote: Hi Alex, =20 Thanks for this summary. =20 I would like to add a couple of points, one with regard to standards and = one with regard to regulations. =20 Standards:=20 I was part of the IEEE 802.11 TGp task group that wrote the 802.11p = amendment. I speak here only for myself. While we were focused on = making it work for DSRC in the 5.9 GHz band, we also recognized that = this "BSS-less" feature could be useful for others in the 802.11 = community (a kind of ad hoc Wi-Fi). So, we tried not to over-constrain = the definition of the OCB type of communication, since we didn't know = all of the use cases to which it might be applied. We always expected to = require EDCA for vehicular communication in 5.9 GHz. We judged that that = could be handled in the IEEE 1609 standards (or in equivalent ETSI = standards for Europe). This is why 802.11 allows DCF data frames while = IEEE 1609 and EN 302 663 do not. To be clear, a WAVE device must use = EDCA for all transmissions, regardless of the L3 protocol. It was never = intended that DCF frames would compete with EDCA frames for channel = access in a band where safety-of-life was at stake [To restate from = earlier in the thread, in such a mix DCF frames would have extremely = high priority]. Perhaps we were too liberal originally. Now, 8 years = later, I am not aware of any other uses of the OCB type of = communication. Perhaps a future revision of 802.11 should omit the DCF = type of data frame when using OCB, to avoid any further confusion. =20 +1=20 =20 =20 =20 Regulations: FCC 5.9 GHz regulations require that DSRC services provide access = priority to safety-of-life communication over all other DSRC = communication. Furthermore, a second class called public-safety = communication is required to have access priority over so-called = non-priority communication. You can find this in CFR 47 =C2=A7 90.377 = and =C2=A7 95.1511. These regulatory requirements are independent of = the L3 protocol. EDCA is the only mechanism of which I am aware to = satisfy this regulation. More to the point, I believe that = non-safety-of-life packets using DCF would fail to meet the regulatory = requirement vis a vis safety-of-life packets that use EDCA. =20 I am not well versed in the spectrum use regulations of European = countries. I believe individual countries are permitted to regulate = spectrum use based on European Norms (ENs). Perhaps EN 302 663's = requirement to use EDCA will be recognized in the regulations of some = countries. =20 Summary: Personally, I'm a bit surprised at the resistance to requiring EDCA in = the ipwave RFC. =20 I agree =20 I think the arguments are quite compelling. I think the IPWAVE WG should = consider the applicability intended for its RFCs in this space. If you = intend implementations of this RFC to operate in the US 5.9 GHz band, = respect for the life-saving mission of DSRC (to say nothing of FCC = regulations) argues that for the common good those implementations = should follow the same priority system that all other devices use. =20 =20 Accepting priority is important for this WG and within our use-cases. =20 AB =20 =20 ------=_NextPart_000_0062_01D3B493.063D28E0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

ABSOLUTELY = !

 

Fygs

 

From: = Abdussalam Baryun <abdussalambaryun@gmail.com>
Sent: = Monday, March 05, 2018 2:32 PM
To: John Kenney = <jkenney@us.toyota-itc.com>
Cc: Alexandre Petrescu = <alexandre.petrescu@gmail.com>; Tony Li = <tony1athome@gmail.com>; its <its@ietf.org>; Fran=C3=A7ois = Simon <fygsimon@gmail.com>; William Whyte = <wwhyte@onboardsecurity.com>; J=C3=A9r=C3=B4me H=C3=A4rri = <jerome.haerri@eurecom.fr>; Carlos Jes=C3=BAs Bernardos Cano = <cjbc@it.uc3m.es>; Dick Roy = <dickroy@alum.mit.edu>
Subject: Re: [ipwave] 802.11 Data = vs 802.11 QoS Data - summary

 

 

 

On Mon, = Mar 5, 2018 at 1:20 AM, John Kenney <jkenney@us.toyota-itc.com> = wrote:

Hi = Alex,

 

Thanks for this summary.

 

I = would like to add a couple of points, one with regard to standards and = one with regard to regulations.

 

Standards: 

I was part of the IEEE 802.11 TGp task group that = wrote the 802.11p amendment.  I speak here only for myself. While = we were focused on making it work for DSRC in the 5.9 GHz band, we also = recognized that this "BSS-less" feature could be useful for = others in the 802.11 community (a kind of ad hoc Wi-Fi).  So, we = tried not to over-constrain the definition of the OCB type of = communication, since we didn't know all of the use cases to which it = might be applied. We always expected to require EDCA for vehicular = communication in 5.9 GHz. We judged that that could be handled in the = IEEE 1609 standards (or in equivalent ETSI standards for Europe).  = This is why 802.11 allows DCF data frames while IEEE 1609 and EN 302 663 = do not.  To be clear, a WAVE device must use EDCA for all = transmissions, regardless of the L3 protocol.  It was never = intended that DCF frames would compete with EDCA frames for channel = access in a band where safety-of-life was at stake [To restate from = earlier in the thread, in such a mix DCF frames would have extremely = high priority].  Perhaps we were too liberal originally. Now, 8 = years later, I am not aware of any other uses of the OCB type of = communication. Perhaps a future revision of 802.11 should omit the DCF = type of data frame when using OCB, to avoid any further = confusion.

 

+1 

 

 

 

Regulations:

FCC 5.9 GHz regulations require that DSRC services = provide access priority to safety-of-life communication over all other = DSRC communication. Furthermore, a second class called public-safety = communication is required to have access priority over so-called = non-priority communication. You can find this in CFR 47 =C2=A7 90.377 = and  =C2=A7 95.1511.  These regulatory = requirements are independent of the L3 protocol. EDCA is the only = mechanism of which I am aware to satisfy this regulation. More to the = point, I believe that non-safety-of-life packets using DCF would fail to = meet the regulatory requirement vis a vis safety-of-life packets that = use EDCA.

 

I = am not well versed in the spectrum use regulations of European = countries. I believe individual countries are permitted to regulate = spectrum use based on European Norms (ENs).  Perhaps EN 302 663's = requirement to use EDCA will be recognized in the regulations of some = countries.

 

Summary:

Personally, I'm a bit surprised at the resistance to = requiring EDCA in the ipwave = RFC.

 

I = agree

 

I think the arguments are quite compelling. I think = the IPWAVE WG should consider the applicability intended for its RFCs in = this space. If you intend implementations of this RFC to operate in the = US 5.9 GHz band, respect for the life-saving mission of DSRC (to say = nothing of FCC regulations) argues that for the common good those = implementations should follow the same priority system that all other = devices use.  

 

Accepting priority is important for this WG and = within our use-cases.

 

AB

 

 

------=_NextPart_000_0062_01D3B493.063D28E0-- From nobody Mon Mar 5 13:28: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 7D151126CB6 for ; Mon, 5 Mar 2018 13:28:42 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=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 iJ1cpYo3D_Vd for ; Mon, 5 Mar 2018 13:28: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 C25C61242F5 for ; Mon, 5 Mar 2018 13:28:39 -0800 (PST) Received: by mail-wr0-x229.google.com with SMTP id m12so18788508wrm.13 for ; Mon, 05 Mar 2018 13:28:39 -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=NwnVlDONURdtQhOEi6gFNbBCYCAQ9CksZthA/u7h0UQ=; b=2GILRXjM1UiFujO0L70hSHeG75QK1xNPU/LpJEJRZSkUaWr1OX6q95jPw5q8PVxCvS 2CJOFfEtq0pxBuHlCsUlj8WicCaoTk7dDdVpzBdUe/JlVsajBZuSzTCUNid/O7Bi59nH d9+vvcS3Eo8qXyFgj/TsJN9kgzh3J3FNzDV7nzthpIKVxZGiScBzqeNlzi5erWV8aRFu l1n9psOww2VgMpCFkEQVP/7jCD94hpITx1Ffq77kd3c3OK/CwXtKVDUcuyhkdLpYzYIk 2sBrcLksLq00YJSxGoUKCCx3AUSuvYFvDvWSjdBNUP7Hg2i8UBjHBZnjup/CIwWZrDNV tlgA== 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=NwnVlDONURdtQhOEi6gFNbBCYCAQ9CksZthA/u7h0UQ=; b=RwkvyHlQIHOkkX21mNVancMyK4C+pdLFmkVG34L6Ped23yCo0/fUOxt9jtOUNGrY18 Egn/gNfahIJjkMMYj9Lxl4Y9ugXflGIL/HFgZ7BWvO3B+fuF81Zqk4otciVfJJuzqkyJ 3u+VDzz8393R6nOd5sFw5z9MkyxYHxuRPaKLLefkCTRXcOCMng+hJPLDzuKPWF0ikq9A tOum/YX8BjqCfODSAOo8Y7qWvGzyfCZDerJno955xGYN49Z90fpfI/E3cKzhnASLTmu4 ds8URU0l3b1ekvSKd05qhBGpceVjRfD9Sf+e+FlivIibZhYnJHxsETgcqqXSrni5ukCV ouHg== X-Gm-Message-State: APf1xPBp+L/vEBLMNzmnNxntY3HwPrfwJmeAT2IZvprnx8ZgyEp54xqD uuQnHpB3gfh8HaY8p9YjsveHIQ== X-Google-Smtp-Source: AG47ELt1YH55tyMa0lFUNFHLUpYQ4XYWTZ6CFCyffJTlqVDDBGhG0JRjqZh1qsv+p2a428dSgt/yZQ== X-Received: by 10.223.209.68 with SMTP id b4mr13832512wri.161.1520285318270; Mon, 05 Mar 2018 13:28:38 -0800 (PST) Received: from cjbc_dell.lan (2.154.161.159.dyn.user.ono.com. [2.154.161.159]) by smtp.gmail.com with ESMTPSA id f127sm6523523wmg.46.2018.03.05.13.28.37 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 05 Mar 2018 13:28:37 -0800 (PST) Message-ID: <1520285316.4122.15.camel@it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano Reply-To: cjbc@it.uc3m.es To: John Kenney , Tony Li Cc: Alexandre Petrescu , =?ISO-8859-1?Q?Fran=E7ois?= Simon , William Whyte , =?ISO-8859-1?Q?J=E9r=F4me_H=E4rri?= , Dick Roy , its Date: Mon, 05 Mar 2018 22:28:36 +0100 In-Reply-To: References: <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> <5ccad588-bcd8-d179-165b-7936a34220fb@gmail.com> <006c01d3b17f$88506750$98f135f0$@eurecom.fr> <01eb01d3b248$c24c0df0$46e429d0$@gmail.com> <4d3a05bf-169f-c531-c8b4-ba2310ae3e22@gmail.com> <1520020476.3381.4.camel@it.uc3m.es> <64DE64AB-CB38-4925-9B50-1576C7DA1C0A@gmail.com> <1520021896.3381.10.camel@it.uc3m.es> <9b5daf2c-8c75-61f3-dded-31b86506c4e1@gmail.com> <475FA779-6523-4891-9472-BF6391CA62A9@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: 7bit Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data - summary X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 21:28:42 -0000 Hi, OK, we will discuss this point in London and close it once for all. As an individual, I tend to think that we should say something to make a coherent spec. Thanks, Carlos On Sun, 2018-03-04 at 17:02 -0800, John Kenney wrote: > I fully agree with Tony. > > John > > > On Sun, Mar 4, 2018 at 4:00 PM, Tony Li wrote: > > John, > > > > Thank you for your comment. One note: > > > > > One could argue that it is sufficient for the RFC to be silent on > > > the QoS data type, as in the current draft. > > > > Being silent will lead to multiple implementations making different > > interpretations of intent, resulting in non-interoperable > > implementations. > > > > Thus, silence is insufficient and we need to say something if we > > intend to publish a coherent spec. > > > > Regards, > > Tony > > > > > From nobody Mon Mar 5 13:32: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 207C01242F5 for ; Mon, 5 Mar 2018 13:32:06 -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, 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=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 fQ5aJcB2egjJ for ; Mon, 5 Mar 2018 13:32:04 -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 87922126C0F for ; Mon, 5 Mar 2018 13:32:04 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id h21so18780977wmd.1 for ; Mon, 05 Mar 2018 13:32:04 -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=Zv3bEc9pnALqntZ9rmnySaCPyC+9oaGDymvrd35VOT8=; b=hloJeXh51Vr06Rdf9wTxHo4LJNj0CG+XyGOLwZyNN1RzczS2IhN8oHybzYhZg6+JOs quSE8bOdC9ghV50g14jJEHul/Ph9ojaK2HLdyPkjWBQrnwmz8+RaOZUXmRulyZxIcNd5 DybS5yDC26jf5WbcfaI+NCoGeF16WPXDVsyQlut9Oa8noQQ547ynK8HBQoDtWoYlBN/T 6ghHhDgNJ9eMfLIxt2lpXy7kQ8c5zo7bBFoYDuRaQ82V1kCcwS7RnM76W/HH8iDB8wpU y9CIK1TclACVL+yV5Qmu9vXGaGEe/SO4UJzVtnqgEhFGqfkqRBI2aGdgvx0wKehJYRPr qzng== 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=Zv3bEc9pnALqntZ9rmnySaCPyC+9oaGDymvrd35VOT8=; b=hOBkAHwGEkX7sfGr83h8GXTlUFT3De0svBC7WRGi4p+a7HZa/Adqj1C6oHshyJ9i0u fcvg3EbOct3ECz3AFB74theq88ZdC2jjFrwhaELUMfn5rR5GJBy8eMRuFyWNZZOO/Zl/ NYRyxyfiUzlb3j7qsSFddCmIGcK5wNhoq3QdBAtkdFE7gpXEUT9RwevqIO2MyCvdM2Lv 46cPWwLGTrtXCyVDG2sXLVeoMYOIMSPRTa6g5Fqxntw2hbOzGa5u1887zdMx4hMkzYoE W5NoefK5v1VtlzJvn9fwL9IL3WxhFocg+KBFfZj2fND8RqX6nl+dL9vben3xomOwV2Vo 6tNQ== X-Gm-Message-State: AElRT7Hgod4/gnJFK0CjAarFJZT2ttWJbkH33fOSNfCX6ob2mxYb4vEO AYsP8MVbcraoLRK8aXK5cU80fQ== X-Google-Smtp-Source: AG47ELv73WseltprjmEyylxy2dttblGmVfUjK/yILzj3Tif3GgTHTpzbDiNqcFgrq+mYRHS1RWqwPw== X-Received: by 10.28.61.65 with SMTP id k62mr9530644wma.140.1520285522942; Mon, 05 Mar 2018 13:32:02 -0800 (PST) Received: from cjbc_dell.lan (2.154.161.159.dyn.user.ono.com. [2.154.161.159]) by smtp.gmail.com with ESMTPSA id m187sm11804625wmg.0.2018.03.05.13.32.01 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 05 Mar 2018 13:32:02 -0800 (PST) Message-ID: <1520285521.4122.19.camel@it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano Reply-To: cjbc@it.uc3m.es To: Alexandre Petrescu , Tony Li Cc: =?ISO-8859-1?Q?Fran=E7ois?= Simon , =?ISO-8859-1?Q?J=E9r=F4me_H=E4rri?= , William Whyte , Dick Roy , its@ietf.org Date: Mon, 05 Mar 2018 22:32:01 +0100 In-Reply-To: <9b5daf2c-8c75-61f3-dded-31b86506c4e1@gmail.com> References: <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> <5ccad588-bcd8-d179-165b-7936a34220fb@gmail.com> <5a98213d.d138c80a.ababc.519f@mx.googl e.com> <006c01d3b17f$88506750$98f135f0$@eurecom.fr> <01eb01d3b248$c24c0df0$46e429d0$@gmail.com> <4d3a05bf-169f-c531-c8b4-ba2310ae3e22@gmail.com> <1520020476.3381.4.camel@it.uc3m.es> <64DE64AB-CB38-4925-9B50-1576C7DA1C0A@gmail.com> <1520021896.3381.10.camel@it.uc3m.es> <9b5daf2c-8c75-61f3-dded-31b86506c4e1@gmail.com> 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] 802.11 Data vs 802.11 QoS Data - summary X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 21:32:06 -0000 Hi Alex, Thanks a lot for the summary. As mentioned in a previous e-mail, we will discuss this topic during in London and take a decision. Thanks, Carlos On Sat, 2018-03-03 at 18:51 +0100, Alexandre Petrescu wrote: > Hi Carlos, > > The last version, -21, is neutral with respect to which 802.11 > headers > to use. It says "802.11 headers" and does not say anything about > which > Subtype. It does not say "MAY use QOSData", nor does it say "MAY use > Data". > > The different views on this topic are the following: > > - some suggest the 802.11 Data headers is the best choice to transmit > IP > datagrams on 802.11 in OCB mode at 5.9 GHz. The reasons invoked > relate to: it is widely implemented this way, and there is some > high-level doubting QoS in general across Internet. > - some suggest, on the contrary, that the best choice to transmit IP > datagrams on 802.11 in OCB mode at 5.9 GHz is the 802.11 QoS Data > headers instead. The reasons invoked are: the OCB mode at 5.9GHz > is > already used to transmit very important non-IP packets (WSMP, CAM, > etc), each using QoS Data headers; there may be a risk of loss of > QoS guarantee if somebody else (IP) uses Data headers instead. > - the IEEE OCB standard permits the use of both QoSData headers _and_ > Data headers. But further standards beyond that, require the use > of > QoSData headers although they dont say they require it for IP. > - a partial solution was suggested publicly, and agreed by some > private > and public emails, to use a certain QoS AC value (Access Category) > to > transport IP. > - many coexistence was required and necessary. > > It is because of this difference of views that we removed the > QoSData-vs-Data altogether from the IP-over-OCB draft. > > Alex > > Le 02/03/2018 à 21:18, Carlos Jesús Bernardos Cano a écrit : > > Hi Tony, > > > > OK, thanks. > > > > Alex: can you summarize the different views in one single e-mail, > > so we > > can take it from there? > > > > Thanks, > > > > Carlos > > > > On Fri, 2018-03-02 at 12:03 -0800, Tony Li wrote: > > > > > > > > > > On Mar 2, 2018, at 11:54 AM, Carlos Jesús Bernardos Cano > > > it.u > > > > c3m.es> wrote: > > > > > > > > You mean to discuss about QoS with IPv6 over 802.11-OCB? Are > > > > you > > > > requesting it to present some material to foster the > > > > discussion? > > > > > > > > We sure can allocate some time for that (I'd say that under the > > > > "rechartering" discussion slot, as I understood that this issue > > > > is > > > > closed for the WG doc, right?). > > > > > > > > > I’m not at all convinced that we have rough consensus on QoS yet. > > > > > > If we don’t converge by London, I would propose a hum. > > > > > > Tony > > > From nobody Mon Mar 5 13:33: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 F18F212E8C9 for ; Mon, 5 Mar 2018 13:33:10 -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, 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=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 N0Z1XfKo1_WY for ; Mon, 5 Mar 2018 13:33:08 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE65C126DCA for ; Mon, 5 Mar 2018 13:33:02 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id s206so15098172wme.0 for ; Mon, 05 Mar 2018 13:33: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=0HtvW9PoffqqsJeMjimiuCRqJloLqwK/P7k8EBZXz9k=; b=1h9V2hNOWc29ExbOYosyowo+6mroQz2V9VcTJP/UNHrgaCWeb8t5hsaRiyfS30wtM/ mF/xWqAhjqEGa996ZSTAVn5XRe5v2siPAgNG+uJZc/G5NPgSgIEnaoRP/oIaAz44ZIp8 TxJnzBEx2wpZCuU56suBqSJxfYkwJCxhAI8Yy0aidBo2svNwrx4/wW+RCu7XWUj2VlyO Pke3rYyFIRaYMPZ2ZWRFp21wg5ghd/iT1pBZ1xcXfM8DBNyHEBYDkbAB1f2ml3XOFwQe kjCBx7A65b8JreOQF0hpeU1n7bECn4Z4AaZfDI9O3hsHV64/8THMraHnBTRAVOthwHET 6rfg== 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=0HtvW9PoffqqsJeMjimiuCRqJloLqwK/P7k8EBZXz9k=; b=jTisf76EYnxbmZSYizoWQl1wcmmeqD96XS05zhIRiHmE06VQ/eOpC6dv7UPTE/bxgM wi7yeZYWuWvzR7xsI88Z0dSDbX29baSNoQFhlMnulp7xtwGpwSUHo7xnO3ZLu7eaV5GN Xd8a54W8D78nyJHYcC7nVi6XgJQoRmbzOBWKm67iLW8X+0+718PxDcMAERVD0xThwjYD f4BKcb6NZAV50jjbPZVz9CWC9PLiR/PIXHEVbDWRjrAFBijsIoT4s2+b5bVyv0EBX3Dk kxruTa2Lfgcv94OSqYzEDgvN8TFxkWgSd8OmwEtDNCprwqbuGQTg6s+cLEkfv6cyOL3R 9EEw== X-Gm-Message-State: AElRT7EgCXH4k1Qj6gRt5REPC7OrR+JlxxVXkz66YXIit8eqx9t993zT aHjs2HjJRGnQHGoHQjPVz/fMmQ== X-Google-Smtp-Source: AG47ELsV8gzJ6udRlXAAd/YdiNnuAzR1DKeoYseQ4bsEZVP4t/mK2JGHBGlbn0TLHW3a08GMBT5TfQ== X-Received: by 10.28.227.86 with SMTP id a83mr10007153wmh.3.1520285581248; Mon, 05 Mar 2018 13:33:01 -0800 (PST) Received: from cjbc_dell.lan (2.154.161.159.dyn.user.ono.com. [2.154.161.159]) by smtp.gmail.com with ESMTPSA id r128sm7539932wmf.37.2018.03.05.13.33.00 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 05 Mar 2018 13:33:00 -0800 (PST) Message-ID: <1520285579.4122.20.camel@it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano Reply-To: cjbc@it.uc3m.es To: Alexandre Petrescu , =?ISO-8859-1?Q?Fran=E7ois?= Simon , =?ISO-8859-1?Q?=27J=E9r=F4me_H=E4rri=27?= , 'William Whyte' , 'Dick Roy' Cc: its@ietf.org Date: Mon, 05 Mar 2018 22:32:59 +0100 In-Reply-To: References: <002b01d3af21$6e779a70$4b66cf50$@eurecom.fr> <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> <5ccad588-bcd8-d179-165b-7936a34220fb@gmail.com> <5a98213d.d138c80a.ababc.519f@mx.googl e.com> <006c01d3b17f$88506750$98f135f0$@eurecom.fr> <01eb01d3b248$c24c0df0$46e429d0$@gmail.com> <4d3a05bf-169f-c531-c8b4-ba2310ae3e22@gmail.com> <1520020476.3381.4.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] 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: Mon, 05 Mar 2018 21:33:13 -0000 Hi Alex, On Sat, 2018-03-03 at 19:03 +0100, Alexandre Petrescu wrote: > > Le 02/03/2018 à 20:54, Carlos Jesús Bernardos Cano a écrit : > > Hi Alex, > > > > On Fri, 2018-03-02 at 18:10 +0100, Alexandre Petrescu wrote: > > > Is there a discussion slot to discuss this in London? > > > > You mean to discuss about QoS with IPv6 over 802.11-OCB? > > Yes. > > > Are you > > requesting it to present some material to foster the discussion? > > I asked Jérôme too, we think about this. Please provide me with a topic title and requested time, so we can organize the rechartering discussion. Thanks, Carlos > > > We sure can allocate some time for that (I'd say that under the > > "rechartering" discussion slot, as I understood that this issue is > > closed for the WG doc, right?). > > yes closed. > > > Do you think -20 is ready so I can review it and request our AD to > > send > > the draft to 6man for review? > > Yes, the -21 is ready. > > Alex > > > > > Thanks, > > > > Carlos > > > > > > > > I would be interested to contribute to the discussion on QoS, but > > > provided we agree it is about QoS with IP, not QoS without IP. > > > > > > Alex > > > > > > Le 02/03/2018 à 18:06, François Simon a écrit : > > > > Aggree. > > > > > > > > *From:*its *On Behalf Of *Jérôme Härri > > > > *Sent:* Thursday, March 01, 2018 12:06 PM > > > > *To:* 'William Whyte' ; 'Dick Roy' > > > > > > > > *Cc:* 'Alexandre Petrescu' ; its@ > > > > ietf > > > > .org > > > > *Subject:* Re: [ipwave] 802.11 Data vs 802.11 QoS Data in > > > > IPv6-over-802.11-OCB -implementations > > > > > > > > Dear All, > > > > > > > > With the risk of repeating information already sent in the > > > > thread, > > > > the > > > > issue has never been if Data or QoSData is allowed for OCB. It > > > > is > > > > clear > > > > it is. > > > > > > > > BUT considering that SAE 2945/1 (BSM) and ETSI geonet-media > > > > dependent > > > > functionalities, both specify to use QoSData to differentiate > > > > event-based BSM (very urgent) from periodic BMS (normal) / DENM > > > > (very > > > > urgent) from CAM (normal) using QoSData with AC_VI (DENM/event- > > > > based > > > > BSM) and AC_BE (CAM/periodic BSM), we have a ‘coexistence > > > > issue’ . > > > > > > > > Indeed, 802.11 data frame use DCF, which use a DIFS equal to 2 > > > > slot > > > > + > > > > SIFS. Now, AC_VI (the urgent DENM/BSM) use EDCA AC_VI, also > > > > with 2 > > > > slot > > > > + SIFS. And CAM/periodic BSM use **6** slot + SIFS. > > > > > > > > In short, any IP-over-OCB will access the channel before > > > > CAM/BSM at > > > > best > > > > and generate collisions with ITS-G5 and DSRC. This can be seem > > > > as > > > > ‘harmful’ interferences with an existing system, which must be > > > > avoided. > > > > > > > > That is the reason I am suggesting to use QoSData for IP-over- > > > > OCB, > > > > so > > > > that depending on your traffic (e.g. if you transmit CAM-over- > > > > IP, > > > > or > > > > video feeds) you can tweak the right AC_ and not interfere with > > > > DSRC/ITS-G5..much. That would avoid a lot of issues…and it does > > > > not > > > > cost > > > > much (ok some extra bits, but come on…we are not doing ROLL > > > > here, > > > > so is > > > > it that dramatic? > > > > > > > > Even though not the task of IETF, it is important to make sure > > > > that > > > > any > > > > specification will not interfere with an existing system. So, > > > > Alex’s > > > > suggestion to remove any explicit mention to QoSData or Data is > > > > probably > > > > a good trade-off, and leave it open to profiling as function of > > > > in > > > > which > > > > channel IP-over-OCB would be used (i.e if interference is > > > > expected > > > > or not)… > > > > > > > > BR, > > > > > > > > Jérôme > > > > > > > > *From:*its [mailto:its-bounces@ietf.org] *On Behalf Of *William > > > > Whyte > > > > *Sent:* Thursday 01 March 2018 17:29 > > > > *To:* Dick Roy > > > > *Cc:* Alexandre Petrescu; its@ietf.org > > > > *Subject:* Re: [ipwave] 802.11 Data vs 802.11 QoS Data in > > > > IPv6-over-802.11-OCB -implementations > > > > > > > > If that's the case, I don't have an issue with the draft > > > > allowing > > > > Data > > > > and QoSData, though I'd note that the definition of OCB in the > > > > Terminology section of the draft states that QoSData is > > > > required > > > > and > > > > should be changed if it's wrong. > > > > > > > > On the question of implementations: I don't have pcaps to hand, > > > > but > > > > the > > > > USDOT RSU spec, available from > > > > https://transportationops.org/publications/dedicated-short-rang > > > > e-co > > > > mmunications-roadside-unit-specifications, > > > > requires QoSData, and OmniAir has been testing conformance to > > > > that > > > > spec, > > > > so it's safe to assume that it's been implemented. > > > > > > > > Cheers, > > > > > > > > William > > > > > > > > On Thu, Mar 1, 2018 at 11:22 AM, Dick Roy > > > > wrote: > > > > > > > > Actually I believe the QoSData restriction is in J2945/1 having > > > > only to > > > > do with operation in the US in 5.9GHz. Data and QoSData are > > > > permitted > > > > according to 802.11 (and 1609.x). This is not to say I believe > > > > this > > > > discussion is relevant to the task of the ITS group, but … > > > > :^))) > > > > > > > > Cheers, > > > > > > > > RR > > > > > > > > ------------------------------------------------------------- > > > > ---- > > > > ------- > > > > > > > > *From:*its [mailto:its-bounces@ietf.org > > > f.or > > > > g>] > > > > *On Behalf Of *William Whyte > > > > *Sent:* Thursday, March 1, 2018 7:50 AM > > > > *To:* Alexandre Petrescu; its@ietf.org > > > > > > > > > > > > *Subject:* Re: [ipwave] 802.11 Data vs 802.11 QoS Data in > > > > IPv6-over-802.11-OCB -implementations > > > > > > > > > > (there are some packet dumps with IP packets transported > > > > > > with > > > > > > .11 Data > > > > > > > > headers in OCB mode at 5.9GHz, e.g. attached). > > > > > > > > My understanding is OCB mode requires QoSData, so those packets > > > > aren’t > > > > conformant to the standard. > > > > > > > > Cheers, > > > > > > > > William > > > > > > > > Sent from Mail > > > > for > > > > Windows 10 > > > > > > > > *From: *Alexandre Petrescu > > > > > > > > *Sent: *Thursday, March 1, 2018 10:48 AM > > > > *To: *its@ietf.org > > > > *Subject: *Re: [ipwave] 802.11 Data vs 802.11 QoS Data in > > > > IPv6-over-802.11-OCB -implementations > > > > > > > > In a private discussion, this question came up: > > > > > > > > Is there a packet dump showing an IP packet transported with > > > > .11 > > > > QoSData > > > > > > > > headers in OCB mode at 5.9GHz. > > > > > > > > (there are some packet dumps with IP packets transported with > > > > .11 > > > > Data > > > > > > > > headers in OCB mode at 5.9GHz, e.g. attached). > > > > > > > > Alex > > > > > > > > Le 01/03/2018 à 15:32, Alexandre Petrescu a écrit : > > > > > > > > > I received some feedback from programmer. > > > > > > > > > > Le 28/02/2018 à 23:48, Abdussalam Baryun a écrit : > > > > > [...] > > > > > > 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, > > > > > > > > > > Here is the QoS problem for IP over 802.11 OCB in > > > > > implementations. > > > > > > > > > > In short, in open source on linux, we dont know how to send > > > > > IP > > > > > packets > > > > > transported as 802.11 QoSData, all IP packets are transported > > > > > as > > > > > 802.11 > > > > > Data instead. > > > > > > > > > > - if you ping -Q at 5.9GHz in OCB mode, the DSCP fields do > > > > > get > > > > > set properly in IP headers of Echorequest, but there is > > > > > no > > > > > .11 QoSData > > > > > headers in packets. Normally, one expects the QoSData > > > > > headers to be > > > > > present there when the DSCP (an IP field) is set. > > > > > > > > > > - if you want to modify kernel, and force always to use > > > > > QoSData > > > > > headers > > > > > on WiFi, including OCB at 5.9GHz, there is a > > > > > net/mac80211/tx.c file > > > > > with a flag called wme_sta that you could set to > > > > > true. But > > > > > take care > > > > > that the C comments there say that it's not normal to > > > > > use > > > > > QoSData > > > > > headers in OCB mode, because a terminal sending QoSData > > > > > has > > > > > no > > > > > guarantee that receivers also use QoSData (the > > > > > negotiation of > > > > > QoS > > > > > capabilities are absent in OCB). > > > > > > > > > > As you can see, this can be long to try and fix. > > > > > > > > > > Until then I will propose to set QoS aside from IP-over-OCB > > > > > at > > > > > this time. > > > > > > > > > > Alex > > > > > > > > > > _______________________________________________ > > > > > its mailing list > > > > > its@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/its > > > > > > > > > > > > > > > > -- > > > > > > > > PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS: > > > > wwhyte@onboardsecurity.com > > > > > > > > > > _______________________________________________ > > > its mailing list > > > its@ietf.org > > > https://www.ietf.org/mailman/listinfo/its From nobody Tue Mar 6 02:24: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 2004A127076 for ; Tue, 6 Mar 2018 02:24: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 eX24TPO0KM-l for ; Tue, 6 Mar 2018 02:24:33 -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 D4DDC126579 for ; Tue, 6 Mar 2018 02:24: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 w26AOVue042688 for ; Tue, 6 Mar 2018 11:24:31 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 334F22024CC for ; Tue, 6 Mar 2018 11:24: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 294AD201432 for ; Tue, 6 Mar 2018 11:24: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 w26AOUJJ020396 for ; Tue, 6 Mar 2018 11:24:31 +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> <00f801d3af1d$f20ce4c0$d626ae40$@gmail.com> <002b01d3af21$6e779a70$4b66cf50$@eurecom.fr> <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> <5c3e6699-67c5-cc6e-efb5-1ee68a9e03c1@gmail.com> From: Alexandre Petrescu Message-ID: <4aebbacd-ec95-5f1d-55b3-7c875d68d5bb@gmail.com> Date: Tue, 6 Mar 2018 11:24: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: <5c3e6699-67c5-cc6e-efb5-1ee68a9e03c1@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 - 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: Tue, 06 Mar 2018 10:24:35 -0000 Further implementation aspects tp be considered: - expensive large Unex boards with Autotalks "802.11p" modems with the ThreadX OS (not linux) - do generate QoSData headers, but dont generate IP. - cheap small Compex boards with Qualcomm Atheros "WiFi" modems in OCB mode with the linux OS - do not generate QoSData headers, but do generate IP (with Data headers). Our draft is about IP and QoSData-vs-Data. Alex Le 05/03/2018 à 13:58, Alexandre Petrescu a écrit : > just some implementations aspects worth considering when considering the > QoSData question. > > Le 01/03/2018 à 15:32, Alexandre Petrescu a écrit : >> I received some feedback from programmer. >> >> Le 28/02/2018 à 23:48, Abdussalam Baryun a écrit : >> [...] >>> 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, >> >> Here is the QoS problem for IP over 802.11 OCB in implementations. >> >> In short, in open source on linux, we dont know how to send IP packets >> transported as 802.11 QoSData, all IP packets are transported as >> 802.11 Data instead. >> >> - if you ping -Q at 5.9GHz in OCB mode, the DSCP fields do get >>    set properly in IP headers of Echorequest, but there is no .11 QoSData >>    headers in packets.  Normally, one expects the QoSData headers to be >>    present there when the DSCP (an IP field) is set. >> >> - if you want to modify kernel, and force always to use QoSData headers >>    on WiFi, including OCB at 5.9GHz, there is a net/mac80211/tx.c file >>    with a flag called wme_sta that you could set to true.  But take care >>    that the C comments there say that it's not normal to use QoSData >>    headers in OCB mode, because a terminal sending QoSData has no >>    guarantee that receivers also use QoSData (the negotiation of QoS >>    capabilities are absent in OCB). > > In private, a partner pointed to an additional method to trigger the > making of QoSData headers, although not sure whether it's for IP or > non-IP.  Use setsockopt to set a distinct priority per socket (BK, BE, > VI, VO): > >>     setsockopt(Sock_VI,SOL_SOCKET ,SO_PRIORITY, >> &PRIORITY_VI,sizeof(PRIORITY_VI)); >>     setsockopt(Sock_VO,SOL_SOCKET ,SO_PRIORITY, >> &PRIORITY_VO,sizeof(PRIORITY_VO)); >>     setsockopt(Sock_BE,SOL_SOCKET ,SO_PRIORITY, >> &PRIORITY_BE,sizeof(PRIORITY_BE)); >>     setsockopt(Sock_BK,SOL_SOCKET ,SO_PRIORITY, >> &PRIORITY_BK,sizeof(PRIORITY_BK)); > > My analysis of it is the following: this method to generate packets with > QoSData headers seems valuable, but it seems dedicated to a particular > application. If I have an app that sends CAM messages then I setsockopt > like above in that app, and thus the CAM packets are preceded by QoSData. > > On another hand, one may want _all_ apps in the computer to use QoSData > if at 5.9GHz in OCB mode, not just some application. I think setsockopt > may not be fully appropriate for that goal. > > One may want some IP app to setsockopt one priority and another IP app > to setsockopt another priority. > > Alex > > >> >> As you can see, this can be long to try and fix. >> >> Until then I will propose to set QoS aside from IP-over-OCB at this time. >> >> 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 Mar 6 03:32: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 0BFFB12708C for ; Tue, 6 Mar 2018 03:32:00 -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 EqWr4oPFoCB2 for ; Tue, 6 Mar 2018 03:31:57 -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 69D7A120047 for ; Tue, 6 Mar 2018 03:31:57 -0800 (PST) Received: by mail-qt0-x229.google.com with SMTP id z14so24136567qti.2 for ; Tue, 06 Mar 2018 03:31:57 -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=SesOFxVT+g0slARIGgflWRSg5x/tQzZrHxaQcgs/p9o=; b=cYEF6Z7YgRjyR++dnk6BDHagoBtKq5VAR5kt82KFDPAKkt+Vsb4cpQ0Ru/cJye0/R1 Ml4KyU5hzy3eJmakIvW/0AdUGZagUo6xtDbIc9nopV0aF0M6Qt1qHtH/D2F38SCCL1zZ Qxpva2Bp1BVC2852p6851bVw1ZGfAhoAFX+KrnX5EgvseFK64d6hc6PdM/Q219ScED7H eLOwAJ+NMidZ1rFpzrDEvxifS2LiP3pOrgVWJXEJUwhdk3tcHnryLmUAfZR/oYoDiRho WJWnZShRvTXbvgPIEdt036Pw5bNa2TwWtWoLwklQwhwXJt90jXu/4Nss7CWtyzeajxSL D+ZA== 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=SesOFxVT+g0slARIGgflWRSg5x/tQzZrHxaQcgs/p9o=; b=pUglLvbl/RESrwIQImkTyYyKTkA413EF1j/WOyuwAh0HTf0kgVUS8osB9npa+2oYzI dFwSHfWsikj1buJzcMOPHjliXMu47jGFt8iRasDRhZRJsZkmoiM2BMuZ7NvkJGIs4Kv5 t2lMR1bf1zi0lOlBuL7dmgHUi4YaFsF2ZQEwN8zeEUqxhLSo2YSp4dP9sqvXez4Dfhqk szsIFWTBxKFIrIcSySuRalfIAYunJBLmh7coaHoZ/NLreVTphToX2EP9NyPiTqOKbDRo S+giUuG0sCC+SZZtEbUX9aqjpyrMzMD7pVyMh+bqVDMmyhPx9CxMM8KYD8Plj4zviGyj pLnA== X-Gm-Message-State: AElRT7Gz1fqfknKLoCiLZ9M1pI/43qTlOKRCmm86sP9WivCoK4roOp3j 4caGB/qHtU6iRmwSRvsLhUI= X-Google-Smtp-Source: AG47ELvV6FsNsK9Fx5rxSj6nSOPoTWOTXdbtt23YzLK4PuInRJM6Li2LlnhegdviZphnol7s85D+ug== X-Received: by 10.200.7.134 with SMTP id l6mr26606838qth.219.1520335916571; Tue, 06 Mar 2018 03:31: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 r47sm10614527qtb.21.2018.03.06.03.31.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Mar 2018 03:31:55 -0800 (PST) From: =?UTF-8?Q?Fran=C3=A7ois_Simon?= 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> <00f801d3af1d$f20ce4c0$d626ae40$@gmail.com> <002b01d3af21$6e779a70$4b66cf50$@eurecom.fr> <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> <5c3e6699-67c5-cc6e-efb5-1ee68a9e03c1@gmail.com> <4aebbacd-ec95-5f1d-55b3-7c875d68d5bb@gmail.com> In-Reply-To: <4aebbacd-ec95-5f1d-55b3-7c875d68d5bb@gmail.com> Date: Tue, 6 Mar 2018 06:31:55 -0500 Message-ID: <002901d3b53e$bba8d480$32fa7d80$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002A_01D3B514.D2D7AE80" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQHelLAw/aN7IRfcwiTBG/gKcgHVEwGONDnFAivYBTcBDgW0eQFK9evKAbex+qQCF4nJkAMphqaUAo/H9voB/QVRSwGgjFsGAtvA4TEBm9hPkAKafOT2Adw4FVkBhOPELQGWvTywAi3roigCOQ33tACppbqeooq16HA= 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: Tue, 06 Mar 2018 11:32:00 -0000 This is a multipart message in MIME format. ------=_NextPart_000_002A_01D3B514.D2D7AE80 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Our draft is about IP and QoSData-vs-Data. The draft is about QoSData=E2=80=A6..no versus. Fygs -----Original Message----- From: its On Behalf Of Alexandre Petrescu Sent: Tuesday, March 06, 2018 5:25 AM To: its@ietf.org Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in = IPv6-over-802.11-OCB - implementations Further implementation aspects tp be considered: - expensive large Unex boards with Autotalks "802.11p" modems with the ThreadX OS (not linux) - do generate QoSData headers, but dont generate IP. - cheap small Compex boards with Qualcomm Atheros "WiFi" modems in OCB mode with the linux OS - do not generate QoSData headers, but do generate IP (with Data headers). Our draft is about IP and QoSData-vs-Data. Alex Le 05/03/2018 =C3=A0 13:58, Alexandre Petrescu a =C3=A9crit : > just some implementations aspects worth considering when considering=20 > the QoSData question. >=20 > Le 01/03/2018 =C3=A0 15:32, Alexandre Petrescu a =C3=A9crit : >> I received some feedback from programmer. >> >> Le 28/02/2018 =C3=A0 23:48, Abdussalam Baryun a =C3=A9crit : >> [...] >>> ieee802.11ocb protocol is already implemented/tested and it is=20 >>> interoperable, but what is the problem, sorry maybe I did not follow = >>> the discussion well, >> >> Here is the QoS problem for IP over 802.11 OCB in implementations. >> >> In short, in open source on linux, we dont know how to send IP=20 >> packets transported as 802.11 QoSData, all IP packets are transported = >> as >> 802.11 Data instead. >> >> - if you ping -Q at 5.9GHz in OCB mode, the DSCP fields do get >> set properly in IP headers of Echorequest, but there is no .11=20 >> QoSData >> headers in packets. Normally, one expects the QoSData headers to=20 >> be >> present there when the DSCP (an IP field) is set. >> >> - if you want to modify kernel, and force always to use QoSData=20 >> headers >> on WiFi, including OCB at 5.9GHz, there is a net/mac80211/tx.c=20 >> file >> with a flag called wme_sta that you could set to true. But take=20 >> care >> that the C comments there say that it's not normal to use QoSData >> headers in OCB mode, because a terminal sending QoSData has no >> guarantee that receivers also use QoSData (the negotiation of QoS >> capabilities are absent in OCB). >=20 > In private, a partner pointed to an additional method to trigger the=20 > making of QoSData headers, although not sure whether it's for IP or=20 > non-IP. Use setsockopt to set a distinct priority per socket (BK, BE, = > VI, VO): >=20 >> setsockopt(Sock_VI,SOL_SOCKET ,SO_PRIORITY,=20 >> &PRIORITY_VI,sizeof(PRIORITY_VI)); >> setsockopt(Sock_VO,SOL_SOCKET ,SO_PRIORITY,=20 >> &PRIORITY_VO,sizeof(PRIORITY_VO)); >> setsockopt(Sock_BE,SOL_SOCKET ,SO_PRIORITY,=20 >> &PRIORITY_BE,sizeof(PRIORITY_BE)); >> setsockopt(Sock_BK,SOL_SOCKET ,SO_PRIORITY,=20 >> &PRIORITY_BK,sizeof(PRIORITY_BK)); >=20 > My analysis of it is the following: this method to generate packets=20 > with QoSData headers seems valuable, but it seems dedicated to a=20 > particular application. If I have an app that sends CAM messages then=20 > I setsockopt like above in that app, and thus the CAM packets are = preceded by QoSData. >=20 > On another hand, one may want _all_ apps in the computer to use=20 > QoSData if at 5.9GHz in OCB mode, not just some application. I think=20 > setsockopt may not be fully appropriate for that goal. >=20 > One may want some IP app to setsockopt one priority and another IP app = > to setsockopt another priority. >=20 > Alex >=20 >=20 >> >> As you can see, this can be long to try and fix. >> >> Until then I will propose to set QoS aside from IP-over-OCB at this = time. >> >> 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 _______________________________________________ its mailing list its@ietf.org =20 https://www.ietf.org/mailman/listinfo/its ------=_NextPart_000_002A_01D3B514.D2D7AE80 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 - implementations

Our draft is = about IP and QoSData-vs-Data.

The draft is = about = QoSData=E2=80=A6..no versus.    Fygs

-----Original = Message-----
From: its <its-bounces@ietf.org> On Behalf Of Alexandre = Petrescu
Sent: Tuesday, March 06, 2018 5:25 AM
To: its@ietf.org
Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in = IPv6-over-802.11-OCB - implementations

Further = implementation aspects tp be considered:

- expensive = large Unex boards with Autotalks "802.11p" modems with = the

   = ThreadX OS (not linux) - do generate QoSData headers, = but

   = dont generate IP.

- cheap small = Compex boards with Qualcomm Atheros "WiFi" modems in = OCB

   = mode with the linux OS - do not generate QoSData headers, but = do

   = generate IP (with Data headers).

Our draft is = about IP and QoSData-vs-Data.

Alex

Le 05/03/2018 = =C3=A0 13:58, Alexandre Petrescu a =C3=A9crit=C2=A0:

> just some = implementations aspects worth considering when considering =

> the = QoSData question.

> =

> Le = 01/03/2018 =C3=A0 15:32, Alexandre Petrescu a = =C3=A9crit=C2=A0:

>> I = received some feedback from programmer.

>>

>> Le = 28/02/2018 =C3=A0 23:48, Abdussalam Baryun a = =C3=A9crit=C2=A0:

>> = [...]

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

>>

>> Here = is the QoS problem for IP over 802.11 OCB in = implementations.

>>

>> In = short, in open source on linux, we dont know how to send IP =

>> = packets transported as 802.11 QoSData, all IP packets are transported =

>> = as

>> 802.11 = Data instead.

>>

>> - if = you ping -Q at 5.9GHz in OCB mode, the DSCP fields do = get

>> = =C2=A0=C2=A0 set properly in IP headers of Echorequest, but there is no = .11

>> = QoSData

>> = =C2=A0=C2=A0 headers in packets.=C2=A0 Normally, one expects the QoSData = headers to

>> = be

>> = =C2=A0=C2=A0 present there when the DSCP (an IP field) is = set.

>>

>> - if = you want to modify kernel, and force always to use QoSData =

>> = headers

>> = =C2=A0=C2=A0 on WiFi, including OCB at 5.9GHz, there is a = net/mac80211/tx.c

>> = file

>> = =C2=A0=C2=A0 with a flag called wme_sta that you could set to = true.=C2=A0 But take

>> = care

>> = =C2=A0=C2=A0 that the C comments there say that it's not normal to use = QoSData

>> = =C2=A0=C2=A0 headers in OCB mode, because a terminal sending QoSData has = no

>> = =C2=A0=C2=A0 guarantee that receivers also use QoSData (the negotiation = of QoS

>> = =C2=A0=C2=A0 capabilities are absent in OCB).

> =

> In = private, a partner pointed to an additional method to trigger the =

> making of = QoSData headers, although not sure whether it's for IP or =

> = non-IP.=C2=A0 Use setsockopt to set a distinct priority per socket (BK, = BE,

> VI, = VO):

> =

>> = =C2=A0=C2=A0=C2=A0 setsockopt(Sock_VI,SOL_SOCKET ,SO_PRIORITY, =

>> = &PRIORITY_VI,sizeof(PRIORITY_VI));

>> = =C2=A0=C2=A0=C2=A0 setsockopt(Sock_VO,SOL_SOCKET ,SO_PRIORITY, =

>> = &PRIORITY_VO,sizeof(PRIORITY_VO));

>> = =C2=A0=C2=A0=C2=A0 setsockopt(Sock_BE,SOL_SOCKET ,SO_PRIORITY, =

>> = &PRIORITY_BE,sizeof(PRIORITY_BE));

>> = =C2=A0=C2=A0=C2=A0 setsockopt(Sock_BK,SOL_SOCKET ,SO_PRIORITY, =

>> = &PRIORITY_BK,sizeof(PRIORITY_BK));

> =

> My = analysis of it is the following: this method to generate packets =

> with = QoSData headers seems valuable, but it seems dedicated to a =

> particular = application. If I have an app that sends CAM messages then =

> I = setsockopt like above in that app, and thus the CAM packets are preceded = by QoSData.

> =

> On another = hand, one may want _all_ apps in the computer to use

> QoSData if = at 5.9GHz in OCB mode, not just some application. I think =

> setsockopt = may not be fully appropriate for that goal.

> =

> One may = want some IP app to setsockopt one priority and another IP app =

> to = setsockopt another priority.

> =

> = Alex

> =

> =

>>

>> As you = can see, this can be long to try and fix.

>>

>> Until = then I will propose to set QoS aside from IP-over-OCB at this = time.

>>

>> = Alex

>>

>> = _______________________________________________

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

_______________________________________________

its mailing = list

its@ietf.org

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

------=_NextPart_000_002A_01D3B514.D2D7AE80-- From nobody Tue Mar 6 03:55: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 95B1B120047 for ; Tue, 6 Mar 2018 03:55:05 -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 Okr3keNMB_lA for ; Tue, 6 Mar 2018 03:55: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 7CF5A127522 for ; Tue, 6 Mar 2018 03:54: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 w26BsuHW038026; Tue, 6 Mar 2018 12:54:56 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5A35B203E19; Tue, 6 Mar 2018 12:54: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 4C567203D33; Tue, 6 Mar 2018 12:54: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 w26Bstq5008788; Tue, 6 Mar 2018 12:54:56 +0100 To: =?UTF-8?Q?Fran=c3=a7ois_Simon?= References: <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> <5c3e6699-67c5-cc6e-efb5-1ee68a9e03c1@gmail.com> <4aebbacd-ec95-5f1d-55b3-7c875d68d5bb@gmail.com> <002901d3b53e$bba8d480$32fa7d80$@gmail.com> From: Alexandre Petrescu Cc: its@ietf.org Message-ID: Date: Tue, 6 Mar 2018 12:54: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: <002901d3b53e$bba8d480$32fa7d80$@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 - evolution from current 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: Tue, 06 Mar 2018 11:55:05 -0000 Le 06/03/2018 à 12:31, François Simon a écrit : > /Our draft is about IP and QoSData-vs-Data./// > > The draft is about QoSData…..no versus.    Fygs Currently the draft does not say QoSData anymore. It just says 'headers'. From this implementation status, what do you think the evolution could be: - the linux driver evolves into implementing QoSData for OCB? - the proprietary products evolve into implementing IP for OCB? Alex > > -----Original Message----- > From: its On Behalf Of Alexandre Petrescu > Sent: Tuesday, March 06, 2018 5:25 AM > To: its@ietf.org > Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in > IPv6-over-802.11-OCB - implementations > > Further implementation aspects tp be considered: > > - expensive large Unex boards with Autotalks "802.11p" modems with the > >    ThreadX OS (not linux) - do generate QoSData headers, but > >    dont generate IP. > > - cheap small Compex boards with Qualcomm Atheros "WiFi" modems in OCB > >    mode with the linux OS - do not generate QoSData headers, but do > >    generate IP (with Data headers). > > Our draft is about IP and QoSData-vs-Data. > > Alex > > Le 05/03/2018 à 13:58, Alexandre Petrescu a écrit : > >> just some implementations aspects worth considering when considering > >> the QoSData question. > >> > >> Le 01/03/2018 à 15:32, Alexandre Petrescu a écrit : > >>> I received some feedback from programmer. > >>> > >>> Le 28/02/2018 à 23:48, Abdussalam Baryun a écrit : > >>> [...] > >>>> 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, > >>> > >>> Here is the QoS problem for IP over 802.11 OCB in implementations. > >>> > >>> In short, in open source on linux, we dont know how to send IP > >>> packets transported as 802.11 QoSData, all IP packets are transported > >>> as > >>> 802.11 Data instead. > >>> > >>> - if you ping -Q at 5.9GHz in OCB mode, the DSCP fields do get > >>>    set properly in IP headers of Echorequest, but there is no .11 > >>> QoSData > >>>    headers in packets.  Normally, one expects the QoSData headers to > >>> be > >>>    present there when the DSCP (an IP field) is set. > >>> > >>> - if you want to modify kernel, and force always to use QoSData > >>> headers > >>>    on WiFi, including OCB at 5.9GHz, there is a net/mac80211/tx.c > >>> file > >>>    with a flag called wme_sta that you could set to true.  But take > >>> care > >>>    that the C comments there say that it's not normal to use QoSData > >>>    headers in OCB mode, because a terminal sending QoSData has no > >>>    guarantee that receivers also use QoSData (the negotiation of QoS > >>>    capabilities are absent in OCB). > >> > >> In private, a partner pointed to an additional method to trigger the > >> making of QoSData headers, although not sure whether it's for IP or > >> non-IP.  Use setsockopt to set a distinct priority per socket (BK, BE, > >> VI, VO): > >> > >>>     setsockopt(Sock_VI,SOL_SOCKET ,SO_PRIORITY, > >>> &PRIORITY_VI,sizeof(PRIORITY_VI)); > >>>     setsockopt(Sock_VO,SOL_SOCKET ,SO_PRIORITY, > >>> &PRIORITY_VO,sizeof(PRIORITY_VO)); > >>>     setsockopt(Sock_BE,SOL_SOCKET ,SO_PRIORITY, > >>> &PRIORITY_BE,sizeof(PRIORITY_BE)); > >>>     setsockopt(Sock_BK,SOL_SOCKET ,SO_PRIORITY, > >>> &PRIORITY_BK,sizeof(PRIORITY_BK)); > >> > >> My analysis of it is the following: this method to generate packets > >> with QoSData headers seems valuable, but it seems dedicated to a > >> particular application. If I have an app that sends CAM messages then > >> I setsockopt like above in that app, and thus the CAM packets are preceded by QoSData. > >> > >> On another hand, one may want _all_ apps in the computer to use > >> QoSData if at 5.9GHz in OCB mode, not just some application. I think > >> setsockopt may not be fully appropriate for that goal. > >> > >> One may want some IP app to setsockopt one priority and another IP app > >> to setsockopt another priority. > >> > >> Alex > >> > >> > >>> > >>> As you can see, this can be long to try and fix. > >>> > >>> Until then I will propose to set QoS aside from IP-over-OCB at this time. > >>> > >>> 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 Tue Mar 6 06: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 32E6E12741D for ; Tue, 6 Mar 2018 06:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_HK_NAME_FM_MR_MRS=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FG16CV_A_8c1 for ; Tue, 6 Mar 2018 06:18:22 -0800 (PST) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::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 8B59C127076 for ; Tue, 6 Mar 2018 06:18:22 -0800 (PST) Received: by mail-io0-x229.google.com with SMTP id m22so22176223iob.12 for ; Tue, 06 Mar 2018 06:18: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=jCi09YPo9byo6ac9+KJ6QAffTLmlSJlxMOKn48617VI=; b=M68HhQNUIFLQcxqN/ClvqCceb1o8AAJCQ7xhZLwnHX/c3ezedSNXSJQqzoOAVN7+hz 32tE9SC6vcdV9v90JMH8lZa9h8uxp+S0GjgHr8vo1d0RZaqo7or1WXHV4l4V2YLbJTjU 725v/yMnMEfl2xrp3YBe8UHRZsIkODGB3DT/wx7D70oPBJyaM7e7NMuxhmpakYk1G9SA R24mYddJBuVlIye4+IcKWcqs7YVWYonKn/okps/1K6nu9kt5dDICNkyvW2kXzLP+YA1P M0C6WM+MSrEmUwN19W4MnR5hwYVpcgHXT0J+BC8ixOOD2DIR3YSM0rvHmxJNDx+G1U6f 9nfQ== 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=jCi09YPo9byo6ac9+KJ6QAffTLmlSJlxMOKn48617VI=; b=B+K8CRghgDi0AGzxqwavKbUpa/IELeawSu2dhMfBZCkmrbGrnzMrEC1ABYzfNhNKGO URqUvp7ndGfegGSpTs3V+45UmjE6yYFaEGTScYWTjY9Xo+55xurlXx8qGFRMWpfViTtL MTatJrMJAPeSLMtkLdui2Li87N5Spfsz/5/vSfqQzjzdie3NLi1MWs/xWCDKoxXbNvJj MVuiwTnadTUHV8mR7rEdm/um05LyYcE7gNEssBw5bxUIl/S78cSYTQG541+LMDlelHc6 7JLmCOQvGKs2JCFESLkvpXV0GbfUhJXM0vcvErWQZeQv1WGJAPRM6TFycVZXXC0zl2ZX dBjg== X-Gm-Message-State: AElRT7EfFWfgqO8bfiqWXle2T35O+GhDg27IZvkJqafS701QEusY2vFZ vROIrU87egFpv0fQMpvxtB96ldyF37zMbRtNfNtKqA== X-Google-Smtp-Source: AG47ELvmrRYPcx4zfJGntwbcNzyvXUPnrYSZuPm27sTn9VJaV7VYeNkE2ojE4dviKSx93T85RVJF8diUqFWgHXEvUe4= X-Received: by 10.107.79.11 with SMTP id d11mr21667303iob.253.1520345901413; Tue, 06 Mar 2018 06:18:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.147.194 with HTTP; Tue, 6 Mar 2018 06:17:50 -0800 (PST) In-Reply-To: <152027400826.14551.2766762404227800440@ietfa.amsl.com> References: <152027400826.14551.2766762404227800440@ietfa.amsl.com> From: "Mr. Jaehoon Paul Jeong" Date: Tue, 6 Mar 2018 23:17:50 +0900 Message-ID: To: its@ietf.org Cc: skku_iotlab_seminar@googlegroups.com, "Mr. Jaehoon Paul Jeong" Content-Type: multipart/alternative; boundary="f4f5e80669bc63bb900566bf1d21" Archived-At: Subject: Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicular-networking-02.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, 06 Mar 2018 14:18:25 -0000 --f4f5e80669bc63bb900566bf1d21 Content-Type: text/plain; charset="UTF-8" Hi IPWAVE WG members, I have posted the 02-version of the IPWAVE Vehicular Networking WG document: https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-02 The major changes from the 01-version are based on the comments in the last IETF-100 IPWAVE WG meeting as follows: o In Section 1, the following sentence is added: The Federal Communications Commission (FCC) in the US allocated wireless channels for Dedicated Short-Range Communications (DSRC) [DSRC], service in the Intelligent Transportation Systems (ITS Radio Service in the 5.850 - 5.925 GHz band (5.9 GHz band). o In Section 2, the definition of Road-Side Unit (RSU) is modified as a node that has physical communication devices (e.g., DSRC, Visible Light Communication, 802.15.4, etc.) for wireless communication with vehicles and is also connected to the Internet as a router or switch for packet forwarding. o In Section 2, DMM is defined as the acronym for "Distributed Mobility Management" [DMM]. o In Section 3.1, the following sentence is clarified along with relevant references: The current RAN is mainly constructed by 4G- LTE for the communication between a vehicle and an infrastructure node (i.e., V2I) [FirstNet-Annual-Report-2017], but DSRC-based vehicular networks can be used for V2I in near future [DSRC]. o In Section 4.1.1, the following sentences are clarified along with relevant references: The standard WAVE [WAVE-1609.0][WAVE-1609.3] does not support Duplicate Address Detection (DAD) of IPv6 Stateless Address Autoconfiguration (SLAAC) [RFC4862] by having its own efficient IP address configuration mechanism based on a WAVE Service Advertisement (WSA) management frame [WAVE-1609.3]. It does not support both seamless communications for Internet services and multi-hop communications between a vehicle and an infrastructure node (e.g., RSU), either. Before this IETF-101 meeting, could you take a look at this revision and give our authors your comments on it? This document will be a good cornerstone for our WG's rechartering in this IETF meeting. Thanks. Best Regards, Paul On Tue, Mar 6, 2018 at 3:20 AM, 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 : IP-based Vehicular Networking: Use Cases, Survey > and Problem Statement > Author : Jaehoon Paul Jeong > Filename : draft-ietf-ipwave-vehicular-networking-02.txt > Pages : 52 > Date : 2018-03-05 > > Abstract: > This document discusses use cases, survey, and problem statement on > IP-based vehicular networks, which are considered a key component of > Intelligent Transportation Systems (ITS). The main topics of > vehicular networking are vehicle-to-vehicle (V2V), vehicle-to- > infrastructure (V2I), and infrastructure-to-vehicle (I2V) networking. > First, this document surveys use cases using V2V and V2I networking. > Second, this document deals with some critical aspects in vehicular > networking, such as vehicular network architectures, standardization > activities, IP address autoconfiguration, routing, mobility > management, DNS naming service, service discovery, and security and > privacy. For each aspect, this document discusses problem statement > to analyze the gap between the state-of-the-art techniques and > requirements in IP-based vehicular networking. Finally, this > document articulates discussions including the summary and analysis > of vehicular networking aspects and raises deployment issues. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipwave-vehicular-networking/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-02 > https://datatracker.ietf.org/doc/html/draft-ietf-ipwave- > vehicular-networking-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave- > vehicular-networking-02 > > > 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 > -- =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php --f4f5e80669bc63bb900566bf1d21 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi IPWAVE WG members,
I have posted the=20 02-version of the IPWAVE Vehi= cular Networking WG document:

= The major changes from the 01-version are based on the comments=C2=A0
=
in the last IETF-100 IPWAVE WG meeting as follows:

o=C2=A0 In Section 1, the following sentence is added: The Feder= al
=C2=A0 =C2=A0Communications Commission (FCC) in the US allocat= ed wireless
=C2=A0 =C2=A0channels for Dedicated Short-Range Commu= nications (DSRC) [DSRC],
=C2=A0 =C2=A0service in the Intelligent = Transportation Systems (ITS Radio
=C2=A0 =C2=A0Service in the 5.8= 50 - 5.925 GHz band (5.9 GHz band).

o=C2=A0 In Sec= tion 2, the definition of Road-Side Unit (RSU) is modified
=C2=A0= =C2=A0as a node that has physical communication devices (e.g., DSRC,
=
=C2=A0 =C2=A0Visible Light Communication, 802.15.4, etc.) for wireless=
=C2=A0 =C2=A0communication with vehicles and is also connected t= o the Internet
=C2=A0 =C2=A0as a router or switch for packet forw= arding.

o=C2=A0 In Section 2, DMM is defined as th= e acronym for "Distributed
=C2=A0 =C2=A0Mobility Management&= quot; [DMM].

o=C2=A0 In Section 3.1, the following= sentence is clarified along with
=C2=A0 =C2=A0relevant reference= s: The current RAN is mainly constructed by 4G-
=C2=A0 =C2=A0LTE = for the communication between a vehicle and an infrastructure
=C2= =A0 =C2=A0node (i.e., V2I) [FirstNet-Annual-Report-2017], but DSRC-based
=C2=A0 =C2=A0vehicular networks can be used for V2I in near future = [DSRC].

o=C2=A0 In Section 4.1.1, the following se= ntences are clarified along with
=C2=A0 =C2=A0relevant references= : The standard WAVE [WAVE-1609.0][WAVE-1609.3]
=C2=A0 =C2=A0does = not support Duplicate Address Detection (DAD) of IPv6
=C2=A0 =C2= =A0Stateless Address Autoconfiguration (SLAAC) [RFC4862] by having
=C2=A0 =C2=A0its own efficient IP address configuration mechanism based o= n a
=C2=A0 =C2=A0WAVE Service Advertisement (WSA) management fram= e [WAVE-1609.3].
=C2=A0 =C2=A0It does not support both seamless c= ommunications for Internet
=C2=A0 =C2=A0services and multi-hop co= mmunications between a vehicle and an
=C2=A0 =C2=A0infrastructure= node (e.g., RSU), either.

Before this IETF-= 101 meeting, could you take a look at this revision and=C2=A0
giv= e our authors your comments on it?

This document w= ill be a good cornerstone for our WG's rechartering in this IETF meetin= g.

Thanks.

Best Regards,<= /div>
Paul


On Tue, Mar 6, 2018 at 3:20 AM, = <internet-= drafts@ietf.org> wrote:
A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the IP Wireless Access in Vehicular Environmen= ts 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:= IP-based Vehicular Networking: Use Cases, Survey and Problem Statement
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Jaeh= oon Paul Jeong
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-ipwave-vehicular-networking-02.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 52
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2018-03-05

Abstract:
=C2=A0 =C2=A0This document discusses use cases, survey, and problem stateme= nt on
=C2=A0 =C2=A0IP-based vehicular networks, which are considered a key compon= ent of
=C2=A0 =C2=A0Intelligent Transportation Systems (ITS).=C2=A0 The main topic= s of
=C2=A0 =C2=A0vehicular networking are vehicle-to-vehicle (V2V), vehicle-to-=
=C2=A0 =C2=A0infrastructure (V2I), and infrastructure-to-vehicle (I2V) netw= orking.
=C2=A0 =C2=A0First, this document surveys use cases using V2V and V2I netwo= rking.
=C2=A0 =C2=A0Second, this document deals with some critical aspects in vehi= cular
=C2=A0 =C2=A0networking, such as vehicular network architectures, standardi= zation
=C2=A0 =C2=A0activities, IP address autoconfiguration, routing, mobility =C2=A0 =C2=A0management, DNS naming service, service discovery, and securit= y and
=C2=A0 =C2=A0privacy.=C2=A0 For each aspect, this document discusses proble= m statement
=C2=A0 =C2=A0to analyze the gap between the state-of-the-art techniques and=
=C2=A0 =C2=A0requirements in IP-based vehicular networking.=C2=A0 Finally, = this
=C2=A0 =C2=A0document articulates discussions including the summary and ana= lysis
=C2=A0 =C2=A0of vehicular networking aspects and raises deployment issues.<= br>

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org= /doc/draft-ietf-ipwave-vehicular-networking/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-02
https://datatracker.i= etf.org/doc/html/draft-ietf-ipwave-vehicular-networking-02
A diff from the previous version is available at:
https://www.ietf.org/rf= cdiff?url2=3Ddraft-ietf-ipwave-vehicular-networking-02


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

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

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



--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeon= g, Ph.D.
Assistant Professor
Department of Software
Sungkyunkwan U= niversity
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com,=C2=A0pauljeong@skku.edu
Personal Homepage: http://iotlab.s= kku.edu/people-jaehoon-jeong.php
--f4f5e80669bc63bb900566bf1d21-- From nobody Tue Mar 6 07:54: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 DC95912706D for ; Tue, 6 Mar 2018 07:54: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, 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 0-V1Ryuq3XK7 for ; Tue, 6 Mar 2018 07:54:17 -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 5BEDE124E15 for ; Tue, 6 Mar 2018 07:54:16 -0800 (PST) Received: from resomta-po-15v.sys.comcast.net ([96.114.154.239]) by resqmta-po-02v.sys.comcast.net with ESMTP id tEudeD1JYzpj8tEuueJJk3; Tue, 06 Mar 2018 15:54:16 +0000 Received: from [10.95.88.211] ([162.210.129.5]) by resomta-po-15v.sys.comcast.net with SMTP id tEskeQIE77PfztEsneuexU; Tue, 06 Mar 2018 15:52:14 +0000 From: Tony Li Message-Id: <503762D0-0C4D-47AB-915A-C72625D840BA@tony.li> Content-Type: multipart/alternative; boundary="Apple-Mail=_39F2C143-05DB-4A67-BFD3-5CB78B34CB6C" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Tue, 6 Mar 2018 07:52:01 -0800 In-Reply-To: Cc: =?utf-8?Q?Fran=C3=A7ois_Simon?= , its@ietf.org To: Alexandre Petrescu References: <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> <5c3e6699-67c5-cc6e-efb5-1ee68a9e03c1@gmail.com> <4aebbacd-ec95-5f1d-55b3-7c875d68d5bb@gmail.com> <002901d3b53e$bba8d480$32fa7d80$@gmail.com> X-Mailer: Apple Mail (2.3445.5.20) X-CMAE-Envelope: MS4wfD3cayKTm3NY+zBLikBS6GNa/g3LlqEU7g2m/WYpk1UJzDRcu4e33ANNPZjh//Pj+PffC4zrYUr+dQYdmKLJRGiRGSRjol8KZKsOodCA9Wi7xn5FxOVQ 22b8n/HtoUTejTltk4Q3EDS47D8hyje5htPogKy00SaTe9Ly2TBflroIBFYSrSyuJzu9/dBjPB/ORE/ZbW1Gxtyf78g89tW7UT82IEXbX3hxX3k9XuBd0GI4 Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB - evolution from current 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: Tue, 06 Mar 2018 15:54:19 -0000 --Apple-Mail=_39F2C143-05DB-4A67-BFD3-5CB78B34CB6C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Currently the draft does not say QoSData anymore. It just says = 'headers'. >=20 > =46rom this implementation status, what do you think the evolution = could be: >=20 > - the linux driver evolves into implementing QoSData for OCB? > - the proprietary products evolve into implementing IP for OCB? Standards are supposed to drive products. Not vice versa. While we have the utmost respect for running code, we do not create = broken standards just to accommodate existing products. Evolving the driver is easy. Probably a 1 hour hack. For the proprietary products, that is up to their developers and = management, and is not a concern of the WG. If they choose to implement = IP, they may find increased demand for their product. Regards, Tony --Apple-Mail=_39F2C143-05DB-4A67-BFD3-5CB78B34CB6C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Currently the draft does not say QoSData anymore. It just = says 'headers'.

=46rom this implementation = status, what do you think the evolution could be:
- the linux driver evolves into implementing = QoSData for OCB?
- the proprietary products evolve into = implementing IP for OCB?


Standards = are supposed to drive products. Not vice versa.

While we have the utmost respect for = running code, we do not create broken standards just to accommodate = existing products.

Evolving the driver is easy. Probably a 1 hour = hack.

For the = proprietary products, that is up to their developers and management, and = is not a concern of the WG.  If they choose to implement IP, they = may find increased demand for their product.

Regards,
Tony

= --Apple-Mail=_39F2C143-05DB-4A67-BFD3-5CB78B34CB6C-- From nobody Wed Mar 7 10:54: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 4F00F120721 for ; Wed, 7 Mar 2018 10:54:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.611 X-Spam-Level: X-Spam-Status: No, score=-1.611 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, URIBL_BLOCKED=0.001] 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 W-LHOG1k5m2k for ; Wed, 7 Mar 2018 10:54:47 -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 841DD129C5D for ; Wed, 7 Mar 2018 10:54: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 w27Isj7W124921 for ; Wed, 7 Mar 2018 19:54:45 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4588F2043DF for ; Wed, 7 Mar 2018 19:54:45 +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 3BC82204364 for ; Wed, 7 Mar 2018 19:54:45 +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 w27Isib6004785 for ; Wed, 7 Mar 2018 19:54:45 +0100 Cc: its@ietf.org References: <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> <5ccad588-bcd8-d179-165b-7936a34220fb@gmail.com> <5a98213d.d138c80a.ababc.519f@mx.googl e.com> <006c01d3b17f$88506750$98f135f0$@eurecom.fr> <01eb01d3b248$c24c0df0$46e429d0$@gmail.com> <4d3a05bf-169f-c531-c8b4-ba2310ae3e22@gmail.com> <1520020476.3381.4.camel@it.uc3m.es> <64DE64AB-CB38-4925-9B50-1576C7DA1C0A@gmail.com> <1520021896.3381.10.camel@it.uc3m.es> <9b5daf2c-8c75-61f3-dded-31b86506c4e1@gmail.com> <1520285521.4122.19.camel@it.uc3m.es> From: Alexandre Petrescu Message-ID: Date: Wed, 7 Mar 2018 19:54: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: <1520285521.4122.19.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] 802.11 Data vs 802.11 QoS Data - 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, 07 Mar 2018 18:54:49 -0000 Hi IPWAVErs, Instead of an ambiguous MAY, we can use a 'knob' with a default value. ---- By default, the IPv6 packet transmitted on 802.11-OCB MUST be preceded by an LLC header and a QoSData header; the value of the TID field is 0001 (aka UP==1, AC_BK). The value of the Traffic Class field of the IP header MUST be x. Each IP-OBU and IP-RSU system MUST provide a knob (SNMP, Yang, syscl, other); the default value of the knob MUST be 'false'. When the value is 'true', the IP packet MUST be preceded by an LLC header and a Data header, and the value of the Traffic Class field in the IPv6 header MUST NOT be restricted. The actioning of this knob MUST be performed in accordance with local regulation. Alex Le 05/03/2018 à 22:32, Carlos Jesús Bernardos Cano a écrit : > Hi Alex, > > Thanks a lot for the summary. As mentioned in a previous e-mail, we > will discuss this topic during in London and take a decision. > > Thanks, > > Carlos > > On Sat, 2018-03-03 at 18:51 +0100, Alexandre Petrescu wrote: >> Hi Carlos, >> >> The last version, -21, is neutral with respect to which 802.11 >> headers to use. It says "802.11 headers" and does not say >> anything about which Subtype. It does not say "MAY use QOSData", >> nor does it say "MAY use Data". >> >> The different views on this topic are the following: >> >> - some suggest the 802.11 Data headers is the best choice to >> transmit IP datagrams on 802.11 in OCB mode at 5.9 GHz. The >> reasons invoked relate to: it is widely implemented this way, and >> there is some high-level doubting QoS in general across Internet. >> - some suggest, on the contrary, that the best choice to transmit >> IP datagrams on 802.11 in OCB mode at 5.9 GHz is the 802.11 QoS >> Data headers instead. The reasons invoked are: the OCB mode at >> 5.9GHz is already used to transmit very important non-IP packets >> (WSMP, CAM, etc), each using QoS Data headers; there may be a risk >> of loss of QoS guarantee if somebody else (IP) uses Data headers >> instead. - the IEEE OCB standard permits the use of both QoSData >> headers _and_ Data headers. But further standards beyond that, >> require the use of QoSData headers although they dont say they >> require it for IP. - a partial solution was suggested publicly, and >> agreed by some private and public emails, to use a certain QoS AC >> value (Access Category) to transport IP. - many coexistence was >> required and necessary. >> >> It is because of this difference of views that we removed the >> QoSData-vs-Data altogether from the IP-over-OCB draft. >> >> Alex >> >> Le 02/03/2018 à 21:18, Carlos Jesús Bernardos Cano a écrit : >>> Hi Tony, >>> >>> OK, thanks. >>> >>> Alex: can you summarize the different views in one single e-mail, >>> so we can take it from there? >>> >>> Thanks, >>> >>> Carlos >>> >>> On Fri, 2018-03-02 at 12:03 -0800, Tony Li wrote: >>>> >>>> >>>>> On Mar 2, 2018, at 11:54 AM, Carlos Jesús Bernardos Cano >>>>> wrote: >>>>> >>>>> You mean to discuss about QoS with IPv6 over 802.11-OCB? Are >>>>> you requesting it to present some material to foster the >>>>> discussion? >>>>> >>>>> We sure can allocate some time for that (I'd say that under >>>>> the "rechartering" discussion slot, as I understood that >>>>> this issue is closed for the WG doc, right?). >>>> >>>> >>>> I’m not at all convinced that we have rough consensus on QoS >>>> yet. >>>> >>>> If we don’t converge by London, I would propose a hum. >>>> >>>> Tony >>>> > From nobody Wed Mar 7 11:08: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 49EFC1289B0 for ; Wed, 7 Mar 2018 11:08:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] 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 BLsJBfm2YX7Z for ; Wed, 7 Mar 2018 11:08:44 -0800 (PST) Received: from mail-io0-f179.google.com (mail-io0-f179.google.com [209.85.223.179]) (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 D26001250B8 for ; Wed, 7 Mar 2018 11:08:43 -0800 (PST) Received: by mail-io0-f179.google.com with SMTP id m22so4207484iob.12 for ; Wed, 07 Mar 2018 11:08:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4AXyFvJVTvutUBtGr6miYo3dBIfVpku7bVV0vA9o7bE=; b=S3BHydVK0H8kN0oBs7XMzf5LLLUbfWyIwNEYAXDnMe/t0604wtSFqBEx2wrABnrzQT Ov0vdT3d/D43Kzj4HOyhtoJq0Ou2vyKiub2oNwPKr5MhbI2TMaGI6egxvhsuZPYELEua dBSEH1kCrX+mbqKBYeWW7Ghh3VtUlGXv0vU2f+xlCkwCMsjdZor7EpkSusSP2KG5eqPA ZnTmwlwd1MqeG+LWTrcDtEgOws9a94ugwkbV+qlMFteoEUsPjaOBcQWNfiMoBaHFgpA1 qX3vns3JdyDC86cM84XeBZILmSoeKPoVmDyd+ALsFMT0N6ZltqbVtjSWb/gX0Mny6m6F KPlg== X-Gm-Message-State: APf1xPDKLeZG6eAy6WNEuOsKCkQE3+eOKSSUwgqumYw5X4qmf3MsMVHN 3VDVYHSAA2bj4zyWXb4Mzwp6fafIqort9r1PIZI= X-Google-Smtp-Source: AG47ELvBNK//EqgWnEOB+MBfbVPbW43rbFvnq/pTvWVEd+bC6oCcyD+ALv/0nnqZ73juUzbSwI0X28vMq/0CcpHwJdQ= X-Received: by 10.107.168.232 with SMTP id e101mr26434376ioj.180.1520449723104; Wed, 07 Mar 2018 11:08:43 -0800 (PST) MIME-Version: 1.0 References: <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> <5ccad588-bcd8-d179-165b-7936a34220fb@gmail.com> <006c01d3b17f$88506750$98f135f0$@eurecom.fr> <01eb01d3b248$c24c0df0$46e429d0$@gmail.com> <4d3a05bf-169f-c531-c8b4-ba2310ae3e22@gmail.com> <1520020476.3381.4.camel@it.uc3m.es> <64DE64AB-CB38-4925-9B50-1576C7DA1C0A@gmail.com> <1520021896.3381.10.camel@it.uc3m.es> <9b5daf2c-8c75-61f3-dded-31b86506c4e1@gmail.com> <1520285521.4122.19.camel@it.uc3m.es> In-Reply-To: From: Tony Li Date: Wed, 07 Mar 2018 19:08:32 +0000 Message-ID: To: Alexandre Petrescu Cc: its@ietf.org Content-Type: multipart/alternative; boundary="001a11427732a503550566d749b5" Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data - 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, 07 Mar 2018 19:08:45 -0000 --001a11427732a503550566d749b5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alex, By default, the IPv6 packet transmitted on 802.11-OCB MUST be preceded > by an LLC header and a QoSData header; the value of the TID field is > 0001 (aka UP=3D=3D1, AC_BK). This part is good. Thank you. The value of the Traffic Class field of the IP > header MUST be x. Are you proposing that we rewrite a packet in flight? And if so, why? This doesn=E2=80=99t seem like the right thing to do. I would just drop this se= ntence. Each IP-OBU and IP-RSU system MUST provide a knob (SNMP, Yang, syscl, > other); the default value of the knob MUST be 'false'. When the value is > 'true', the IP packet MUST be preceded by an LLC header and a Data > header, and the value of the Traffic Class field in the IPv6 header MUST > NOT be restricted. The actioning of this knob MUST be performed in > accordance with local regulation. I get that you=E2=80=99re trying to allow Data between consenting adults, b= ut you can do that by going outside of the spec anyway, so I=E2=80=99m not seeing = this as buying you much. Plus, implementations will probably not need this. I=E2=80= =99d suggest dropping this too. Tony > --001a11427732a503550566d749b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Alex,


By default, the IPv6 packet transmitted on 802.11-OCB MUST be preced= ed
by an LLC header and a QoSData header; the value of the TID field is
0001 (aka UP=3D=3D1, AC_BK).


This part is good.=C2=A0 Thank you= .


The value of the Traffic Class field of the IP
header MUST be x.


Are you proposing that we rewrite a packet in = flight? And if so, why?=C2=A0 This doesn=E2=80=99t seem like the right thin= g to do.=C2=A0 I would just drop this sentence.

=

Each IP-= OBU and IP-RSU system MUST provide a knob (SNMP, Yang, syscl,
other); the default value of the knob MUST be 'false'. When the val= ue is
'true', the IP packet MUST be preceded by an LLC header and a Data<= br> header, and the value of the Traffic Class field in the IPv6 header MUST NOT be restricted. The actioning of this knob MUST be performed in
accordance with local regulation.

<= div dir=3D"auto">
I get that you=E2=80=99re tryi= ng to allow Data between consenting adults, but you can do that by going ou= tside of the spec anyway, so I=E2=80=99m not seeing this as buying you much= . Plus, implementations will probably not need this. I=E2=80=99d suggest dr= opping this too.

Tony
=C2=A0
--001a11427732a503550566d749b5-- From nobody Thu Mar 8 02:30: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 8E0B1124C27 for ; Thu, 8 Mar 2018 02:30:40 -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 tB7Dz2K2w-rc for ; Thu, 8 Mar 2018 02:30:39 -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 B47701205F0 for ; Thu, 8 Mar 2018 02:30:38 -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 w28AUbCQ012859; Thu, 8 Mar 2018 11:30:37 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0F9F6204370; Thu, 8 Mar 2018 11:30: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 02B6C201C38; Thu, 8 Mar 2018 11:30: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 w28AUaqr026672; Thu, 8 Mar 2018 11:30:36 +0100 To: Tony Li Cc: its@ietf.org References: <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> <5ccad588-bcd8-d179-165b-7936a34220fb@gmail.com> <006c01d3b17f$88506750$98f135f0$@eurecom.fr> <01eb01d3b248$c24c0df0$46e429d0$@gmail.com> <4d3a05bf-169f-c531-c8b4-ba2310ae3e22@gmail.com> <1520020476.3381.4.camel@it.uc3m.es> <64DE64AB-CB38-4925-9B50-1576C7DA1C0A@gmail.com> <1520021896.3381.10.camel@it.uc3m.es> <9b5daf2c-8c75-61f3-dded-31b86506c4e1@gmail.com> <1520285521.4122.19.camel@it.uc3m.es> From: Alexandre Petrescu Message-ID: Date: Thu, 8 Mar 2018 11:30: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] 802.11 Data vs 802.11 QoS Data - 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: Thu, 08 Mar 2018 10:30:40 -0000 Tony, Le 07/03/2018 à 20:08, Tony Li a écrit : > > Hi Alex, > > > By default, the IPv6 packet transmitted on 802.11-OCB MUST be preceded > by an LLC header and a QoSData header; the value of the TID field is > 0001 (aka UP==1, AC_BK). > > > > This part is good.  Thank you. Noted, we can keep it. > The value of the Traffic Class field of the IP > header MUST be x. > > > > Are you proposing that we rewrite a packet in flight? And if so, why? I understand you assume rewriting, because a packet arriving from the Internet would not have that Traffic Class set for OCB. Certainly I dont propose rewriting, because communication from the Internet to a car should happen end-to-end, without rewriting, nor translation, nor proxying. In the other direction - from the car to the Internet, and only for 1-hop, the IP Traffic Class mapped to the 802.11 TID value and AC_BK, would make sense. Given that rewriting is not good, but mapping IP-to-.11 fields is good for one hop, I dont know how to proceed. > This doesn’t seem like the right thing to do.  I would just drop this > sentence. We can drop it. If we do, it would be very much about fields in headers below IP (not fields in the IP header). It would be this: > By default, the packet transmitted on 802.11-OCB with the value of the > EtherType field equal to 0x86dd (IPv6) MUST be preceded by an LLC > header and a QoSData header; the value of the TID field is 0001 (aka > UP==1, AC_BK). Should IETF write this before IEEE OCB does? > Each IP-OBU and IP-RSU system MUST provide a knob (SNMP, Yang, syscl, > other); the default value of the knob MUST be 'false'. When the value is > 'true', the IP packet MUST be preceded by an LLC header and a Data > header, and the value of the Traffic Class field in the IPv6 header MUST > NOT be restricted. The actioning of this knob MUST be performed in > accordance with local regulation. > > > > I get that you’re trying to allow Data between consenting adults, but > you can do that by going outside of the spec anyway, so I’m not seeing > this as buying you much. Plus, implementations will probably not need > this. I’d suggest dropping this too. There is this hackathon opportunity. They say they dont have expensive cards there. They ask which Internet Draft to test. What would you tell them? Alex > > Tony > From nobody Thu Mar 8 07:00: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 34B661241F8 for ; Thu, 8 Mar 2018 07:00:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_HK_NAME_FM_MR_MRS=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2P3h2mJaCuZO for ; Thu, 8 Mar 2018 07:00:33 -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 5358C12D960 for ; Thu, 8 Mar 2018 07:00:33 -0800 (PST) Received: by mail-io0-x230.google.com with SMTP id e30so7370403ioc.3 for ; Thu, 08 Mar 2018 07:00:33 -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=dr/RAyWx8oW1niezdqb9lFry0IrefA6TFr5UvggU6tQ=; b=ta5V7M60RpRacdJwQgeGYyx2ccNpvfBbH9azbboAE5shSVE2ARMbf17frvzz90rIRW yJgXhw0A7Eaye7D4KMsJUElAHPbN0EfY1SuTw4o3HtuUiGm8q4cQ2xTzSRLBzN3kfxMY HnJSA3mvDmVdC3BUG6Hy0QNJwGYddh1/2s1OSntKmm7YRLWne+rcLSauVLYJ82AIPefk LzqWgrz9hI/i99z+dXlwH7eFPpcR7ediSL9HIxog+RjezyuTdudXVaPvHd8xAKlD77QL bAzrzvCx5Ro6ueghcQyGuLwtjJdeAlaHH+jqpTXgJ+vxrPrJGKmnrTvrFBgddVohfxdR uD/A== 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=dr/RAyWx8oW1niezdqb9lFry0IrefA6TFr5UvggU6tQ=; b=CW+R4RKZ8GqlrLkYdNZLrG3aSV+ZkzBNNZkYy7o5uV/WqAUqh+AAO4vG8uzf0cZBUg wiM5uGAvF5nONEy73WxDU/KASooPP3oJOT0NpO5hOfV55nIrf89IuztYJC93W9WSKmrf 1uV7UmP8OvrgBrAh6wuLgyLQD5DaYzf+3BSHNJ/qN3twQSh9eBCUAR3pxKa0c5RW6Fin /k7+ok6YORfkDUcW51B1aJvr8biJjjokcTiNlDZHvUYSaVurUsy7SCNKaV4kWL3jkVe2 NQ6QNP9luvBSFmVOudMxb/03fBeW697HhlHee4aln0HiLLQp1YtVJDsfEqp14UV9T7QL LoDw== X-Gm-Message-State: AElRT7EE4ZoteSVAzihcHxoppIzc8yWY682B7cBADm9eBA0vsizBU9bb 8elgmZQWDfdEL7ZuguFG3WD+xaKHjmxID4ObXq8= X-Google-Smtp-Source: AG47ELsKNSCQ8dX0llzXPr69wKAVVVaEdJ/R8WolupEfrEMqhI5nskbAqgJ287I26d1T35ke5Fqf6hFy6AKCExyMmII= X-Received: by 10.107.79.11 with SMTP id d11mr31222844iob.253.1520521232381; Thu, 08 Mar 2018 07:00:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.245.6 with HTTP; Thu, 8 Mar 2018 07:00:00 -0800 (PST) In-Reply-To: <1B326624F8EE4A19B7C94AED23C7CE5C@SRA6> References: <152027400826.14551.2766762404227800440@ietfa.amsl.com> <1B326624F8EE4A19B7C94AED23C7CE5C@SRA6> From: "Mr. Jaehoon Paul Jeong" Date: Fri, 9 Mar 2018 00:00:00 +0900 Message-ID: To: Richard Roy Cc: its@ietf.org, Tony Li , skku_iotlab_seminar@googlegroups.com, "Mr. Jaehoon Paul Jeong" Content-Type: multipart/alternative; boundary="f4f5e80669bcedfb680566e7ef93" Archived-At: Subject: Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicular-networking-02.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, 08 Mar 2018 15:00:43 -0000 --f4f5e80669bcedfb680566e7ef93 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Richard, First of all, thanks for your constructive comments on our revision. I will revise our document according to your comments. I put my answer inline below. On Wed, Mar 7, 2018 at 7:55 AM, Dick Roy wrote: > Comments inline below =E2=80=A6 > > > ------------------------------ > > *From:* its [mailto:its-bounces@ietf.org] *On Behalf Of *Mr. Jaehoon Paul > Jeong > *Sent:* Tuesday, March 6, 2018 6:18 AM > *To:* its@ietf.org > *Cc:* skku_iotlab_seminar@googlegroups.com; Mr. Jaehoon Paul Jeong > *Subject:* Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicular-ne > tworking-02.txt > > > > Hi IPWAVE WG members, > > I have posted the 02-version of the IPWAVE Vehicular Networking WG > document: > > https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-02 > > > > The major changes from the 01-version are based on the comments > > in the last IETF-100 IPWAVE WG meeting as follows: > > > > o In Section 1, the following sentence is added: The Federal > > Communications Commission (FCC) in the US allocated frequency for > Dedicated Short-Range Communications (DSRC) [DSRC], > > service in the Intelligent Transportation Systems (ITS Radio > > Service in the 5.850 - 5.925 GHz band (5.9 GHz band). > =3D> I replace "allocated frequency for" with " allocated a frequency range for ". > > > o In Section 2, the definition of Road-Side Unit (RSU) is modified > > as a node that has physical communication devices (e.g., DSRC, > > Visible Light Communication, 802.15.4, etc.) for wireless > > communication with vehicles and is also connected to the Internet > > as a router or switch for packet forwarding. > > > > *[RR] RSUs should not be required to e connected to the =E2=80=9CInternet= =E2=80=9D nor to > =E2=80=9Cact as routers=E2=80=9D. There will be RSUs (already are) in pl= aces where there > is NO access to other networks!* > > =3D> Even though the current RSU has no Internet connectivity, the RSU may have Internet connectivity in near future. Thus, I revise the definition of RSU as below: In Section 2, the definition of Road-Side Unit (RSU) is modified as a node that has physical communication devices (e.g., DSRC, Visible Light Communication, 802.15.4, etc.) for wireless communication with vehicles and may have the connectivity to the Internet as a router or switch for packet forwarding in the Internet. > > o In Section 2, DMM is defined as the acronym for "Distributed > > Mobility Management" [DMM]. > > > > o In Section 3.1, the following sentence is clarified along with > > relevant references: The current RAN is mainly constructed by 4G- > > LTE for the communication between a vehicle and an infrastructure > > node (i.e., V2I) [FirstNet-Annual-Report-2017], but DSRC-based > > vehicular networks can be used for V2I in near future [DSRC]. > > *[RR] I have NO idea why you are discussing ANYTHING related to LTE in > this document! They have NO CLUE about OCB operations, and that is ALL > this document should be about! I=E2=80=99d remove any and all such refer= ences to > LTE of any flavor!* > =3D> Since this document deals with the survey of IP-based vehicular networking, we authors believe that LTE can be a tentative communication technology before the DSRC will be deployed popularly. > > > o In Section 4.1.1, the following sentences are clarified along with > > relevant references: The standard WAVE [WAVE-1609.0][WAVE-1609.3] > > does not support Duplicate Address Detection (DAD) of IPv6 > > Stateless Address Autoconfiguration (SLAAC) [RFC4862] by having > > its own efficient IP address configuration mechanism based on a > > WAVE Service Advertisement (WSA) management frame [WAVE-1609.3]. > > It does not support both seamless communications for Internet > > services and multi-hop communications between a vehicle and an > > infrastructure node (e.g., RSU), either. > > *[RR] This paragraph is wrong on many counts and should be completely > rewritten. The WAVE standards say NOTHING about IPv6 support other than > it=E2=80=99s optional, and if you implement it, you shall implement IPv6. > EVERYTHING IPv6 does is fair game! The WSA optionally can transmit a loca= l > IPv6 prefix, which can be used for SLAAC as I understand it. The WAVE > standards absolutely =E2=80=9Csupport=E2=80=9D seamless comms for Interne= t (IPv6) services, > exactly as ANY other Wi-Fi device does =E2=80=A6 very well if you are sta= tionary > and connected, and increasing poorly as you =E2=80=9Cmove faster=E2=80=9D= ! You can not > multi-hop between just two nodes! Assuming you meant the equivalent of > mesh networks in IEEE 802.11, it=E2=80=99s true mesh can be supported in = OCB > because the those writing the .11p standard required ToDS and FromDS to b= e > 0 which means the 4-address format can not be used. That said, FNTP, the > ISO equivalent of WAVE, DOES have n-hop forwarding as an extension of > null-networking! Use FNTP instead and you=E2=80=99ll have it! * > > > =3D> I suggest the following paragraphs to reflect your comments: ------------------------------------------------------------ ------------------------------------------------------------ ----------------------------------------------- The standard WAVE [WAVE-1609.0][WAVE-1609.3] defines a WAVE Service Advertisement (WSA) frame to support IPv6 [RFC4862]. WAVE devices send WSA frames via WAVE Short Message Protocol (WSMP) to announce IPv6 services. The WAVE Routing Advertisement (WRA) in a WSA frame announces several IP service-related information (e.g., Router Lifetime, IP Prefix, Prefix Length, and DNS Server Addresses). Each WAVE device supports link-local, global, and multicast IPv6 addresses [RFC4291]. WAVE devices can support dynamic IP addressing by calculating global IPv6 addresses via Stateless Address Autoconfiguration (SLAAC)[RFC4862] with their MAC address and the announced IP prefix. However, since the MAC address of a WAVE device may be altered for its pseudonym for privacy at any time, this MAC address change may let Duplicate Address Detection (DAD) fail or it brings a significant burden to WAVE devices. Another issue is that some IP services (e.g., Internet access and route management services) shall be provided across the entire WAVE networks. DAD guarantees the uniqueness of the IP address of a WAVE device in its current local link, but when the WAVE device moves to another local link or an area using a different SCH with the same WRA, the uniqueness of the IP address can be broken, so the seamless communication for those IP services can also be interrupted. Finally, the IP packet relay can enable multi-hop communications among WAVE devices instead of just one-hop connections, which may enhance the connectivity of WAVE devices into RSUs. Fast Networking & Transport Layer Protocol (FNTP)[FNTP:ISO29281-1] defining a multi-hop communication method for non-IP networking can be used as an alternative for multi-hop communications, but it is a non-IP service, so it may not be able provide IP-based seamless services to users. ------------------------------------------------------------ ------------------------------------------------------------ ----------------------------------------------- Thanks. Best Regards, Paul > Before this IETF-101 meeting, could you take a look at this revision and > > give our authors your comments on it? > > > > This document will be a good cornerstone for our WG's rechartering in thi= s > IETF meeting. > > > > Thanks. > > > > Best Regards, > > Paul > > > > > > On Tue, Mar 6, 2018 at 3:20 AM, 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 : IP-based Vehicular Networking: Use Cases, Surve= y > and Problem Statement > Author : Jaehoon Paul Jeong > Filename : draft-ietf-ipwave-vehicular-networking-02.txt > Pages : 52 > Date : 2018-03-05 > > Abstract: > This document discusses use cases, survey, and problem statement on > IP-based vehicular networks, which are considered a key component of > Intelligent Transportation Systems (ITS). The main topics of > vehicular networking are vehicle-to-vehicle (V2V), vehicle-to- > infrastructure (V2I), and infrastructure-to-vehicle (I2V) networking. > First, this document surveys use cases using V2V and V2I networking. > Second, this document deals with some critical aspects in vehicular > networking, such as vehicular network architectures, standardization > activities, IP address autoconfiguration, routing, mobility > management, DNS naming service, service discovery, and security and > privacy. For each aspect, this document discusses problem statement > to analyze the gap between the state-of-the-art techniques and > requirements in IP-based vehicular networking. Finally, this > document articulates discussions including the summary and analysis > of vehicular networking aspects and raises deployment issues. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipwave-vehicular-networking/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-02 > https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-vehi > cular-networking-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipwave-vehicula > r-networking-02 > > > 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 > > > > > > -- > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Mr. Jaehoon (Paul) Jeong, Ph.D. > Assistant Professor > Department of Software > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.paul@gmail.com, pauljeong@skku.edu > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php > > --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php --f4f5e80669bcedfb680566e7ef93 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Richard,
First of all, thanks for your constructive= comments on our revision.

I will revise our docum= ent according to your comments.
I put my answer inline below.

On Wed, Mar 7, = 2018 at 7:55 AM, Dick Roy <dickroy@alum.mit.edu> wrote:

Comments inline belo= w =E2=80=A6

=C2=A0=

From:<= font size=3D"2" face=3D"Tahoma"> its [mailto:its-bounc= es@ietf.org] On Behalf Of Mr. Jaehoon Paul Jeong
Sent: Tuesday, March 6, 2018= 6:18 AM
To: its@ietf.org
Cc: s= kku_iotlab_seminar@googlegroups.com; Mr. Jaehoon Paul Jeong
Subject: Re: [ipwave] I-D Ac= tion: draft-ietf-ipwave-vehicular-networking-02.txt<= /u>

=C2=A0

Hi IPWAVE WG members,

I have posted the 02-version of t= he IPWAVE Vehicular Networking WG document:

=C2=A0

The major changes from the 01-version are based on the= comments=C2=A0

in the last IETF-100 IPWAVE WG meeting as follows:<= /u>

=C2=A0

o=C2=A0 In Section 1, the following sentence is added:= The Federal

=C2=A0 =C2=A0Communications Commission (FCC) in the US allocated frequency for Dedicated Short-Range Communications (DSRC) [DSRC],

=C2=A0 =C2=A0service in the Intelligent Transportation= Systems (ITS Radio

=C2=A0 =C2=A0Service in the 5.850 - 5.925 GHz band (5.= 9 GHz band).


=C2=A0 =C2=A0 =C2=A0=3D> I replace "alloca= ted frequency for" with " allocated a frequency range for ".=C2=A0

=C2=A0

o=C2=A0 In Section 2, the definition of Road-Side Unit= (RSU) is modified

=C2=A0 =C2=A0as a node that has physical communication= devices (e.g., DSRC,

=C2=A0 =C2=A0Visible Light Communication, 802.15.4, et= c.) for wireless

=C2=A0 =C2=A0communication with vehicles and is also c= onnected to the Internet

=C2=A0 =C2=A0as a router or switch for packet forwardi= ng.

=C2=A0<= /font>

[RR] RSUs should not be required to e connected to the= =E2=80=9CInternet=E2=80=9D nor to =E2=80=9Cact as routers=E2=80=9D.=C2=A0 There will be RSUs (already = are) in places where there is NO access to other networks!


=C2=A0 = =C2=A0 =C2=A0=3D> Even though the current RSU has no Internet connectivi= ty, the RSU may have Internet connectivity in near future.=C2=A0
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thus,=C2=A0 I revise the definition of R= SU as below:

<= p class=3D"MsoNormal" style=3D"margin:0px">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= In Section 2, the definition of Road-Side Unit (RSU) is modified<= /u>

=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0as a node that has physical communication device= s (e.g., DSRC,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Visible Light Communi= cation, 802.15.4, etc.) for wireless

<= div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:sma= ll;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal= ;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;tex= t-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(2= 55,255,255);text-decoration-style:initial;text-decoration-color:initial">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0c= ommunication with vehicles and may have the connectivity to the Internet=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0as a router or switch for packet forward= ing in the Internet.


=C2=A0

o=C2=A0 In Section 2, DMM is defined as the acronym fo= r "Distributed

=C2=A0 =C2=A0Mobility Management" [DMM].

=C2=A0

o=C2=A0 In Section 3.1, the following sentence is clar= ified along with

=C2=A0 =C2=A0relevant references: The current RAN is m= ainly constructed by 4G-

=C2=A0 =C2=A0LTE for the communication between a vehic= le and an infrastructure

=C2=A0 =C2=A0node (i.e., V2I) [FirstNet-Annual-Report-= 2017], but DSRC-based

=C2=A0 =C2=A0vehicular networks can be used for V2I in= near future [DSRC].

[RR] I have NO idea why you are discussing ANYT= HING related to LTE in this document!=C2=A0 They have NO CLUE about OCB operations, and = that is ALL this document should be about!=C2=A0 I=E2=80=99d remove any and all suc= h references to LTE of any flavor!

<= /blockquote>

=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D> Since th= is document deals with the survey of IP-based vehicular networking,=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 we authors believe that = LTE can be a tentative communication technology
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 before the DSRC will be deployed popularly.=C2=A0= =C2=A0

=C2=A0

o=C2=A0 In Section 4.1.1, the following sentences are = clarified along with

=C2=A0 =C2=A0relevant references: The standard WAVE [WAVE-1609.0][WAVE-1609.3]

=C2=A0 =C2=A0does not support Duplicate Address Detect= ion (DAD) of IPv6

=C2=A0 =C2=A0Stateless Address Autoconfiguration (SLAA= C) [RFC4862] by having

=C2=A0 =C2=A0its own efficient IP address configuratio= n mechanism based on a

=C2=A0 =C2=A0WAVE Service Advertisement (WSA) manageme= nt frame [WAVE-1609.3].

=C2=A0 =C2=A0It does not support both seamless communi= cations for Internet

=C2=A0 =C2=A0services and multi-hop communications bet= ween a vehicle and an

=C2=A0 =C2=A0infrastructure node (e.g., RSU), either.<= u>

[RR] This paragraph is wrong on many counts and= should be completely rewritten.=C2=A0 The WAVE standards say NOTHING about IPv6 support other th= an it=E2=80=99s optional, and if you implement it, you shall implement IPv6.=C2=A0 EVERYTHI= NG IPv6 does is fair game! The WSA optionally can transmit a local IPv6 prefix, whi= ch can be used for SLAAC as I understand it.=C2=A0 The WAVE standards absolute= ly =E2=80=9Csupport=E2=80=9D seamless comms for Internet (IPv6) services, exactly as ANY other Wi-Fi dev= ice does =E2=80=A6 very well if you are stationary and connected, and increasin= g poorly as you =E2=80=9Cmove faster=E2=80=9D!=C2=A0 You can not multi-hop between just= two nodes!=C2=A0 Assuming you meant the equivalent of mesh networks in IEEE 802.11, it=E2=80=99s true mes= h can be supported in OCB because the those writing the .11p standard required ToDS = and FromDS to be 0 which means the 4-address format can not be used. That said, FNTP, the ISO equivalent of WAVE, DOES have n-hop forwarding as an extensio= n of null-networking!=C2=A0 Use FNTP instead and you=E2=80=99ll have it!=C2=A0 <= /span><= /font>

=C2=A0

=C2=A0 =C2=A0 =C2=A0=3D> I suggest the fo= llowing paragraphs to reflect your comments:
=C2=A0 -------------= -----------------------------------------------------------------= -----------------------------------------------------------------= ------------------------
The standard WAVE [WAVE-1609.0= ][WAVE-1609.3] defines a WAVE Service Advertisement (WSA) frame=C2=A0
=
to support IPv6 [RFC4862]. WAVE devices send WSA frames via WAVE Short= Message Protocol (WSMP)=C2=A0
to announce IPv6 services. The WAV= E Routing Advertisement (WRA) in a WSA frame announces several=C2=A0
<= div>IP service-related information (e.g., Router Lifetime, IP Prefix, Prefi= x Length, and DNS Server Addresses).=C2=A0

Each WA= VE device supports link-local, global, and multicast IPv6 addresses [RFC429= 1]. WAVE devices can=C2=A0
support dynamic IP addressing by calcu= lating global IPv6 addresses via Stateless Address Autoconfiguration=C2=A0<= /div>
(SLAAC)[RFC4862] with their MAC address and the announced IP pref= ix. However, since the MAC address=C2=A0
of a WAVE device may be = altered for its pseudonym for privacy at any time, this MAC address change = may let=C2=A0
Duplicate Address Detection (DAD) fail or it brings= a significant burden to WAVE devices.=C2=A0

Anoth= er issue is that some IP services (e.g., Internet access and route manageme= nt services) shall be provided=C2=A0
across the entire WAVE netwo= rks. DAD guarantees the uniqueness of the IP address of a WAVE device in=C2= =A0
its current local link, but when the WAVE device moves to ano= ther local link or an area using a different SCH=C2=A0
with the s= ame WRA, the uniqueness of the IP address can be broken, so the seamless co= mmunication for
those IP services can also be interrupted.=C2=A0
<= div>
Finally, the IP packet relay can enable multi-hop commun= ications among WAVE devices instead of just one-hop=C2=A0
connect= ions, which may enhance the connectivity of WAVE devices into RSUs. Fast Ne= tworking & Transport Layer=C2=A0
Protocol (FNTP)[FNTP:ISO2928= 1-1] defining a multi-hop communication method for non-IP networking can be= =C2=A0
used as an alternative for multi-hop communications, but i= t is a non-IP service, so it may not be able provide=C2=A0
IP-bas= ed seamless services to users.
= =C2=A0 ---------------------------------------------------------------------------------------------------------------------------= --------------------------------------------


Thanks.

Best Regards,
Pau= l
=C2=A0

Before this IETF-101 meeting, could you take a look at= this revision and=C2=A0

give our authors your comments on it?

=C2=A0

This document will be a good cornerstone for our WG= 9;s rechartering in this IETF meeting.

=C2=A0

Thanks.

=C2=A0

Best Regards,

Paul

=C2=A0

=C2=A0

On Tue, Mar 6, 2018 at 3:20 AM, <internet-drafts@ietf.org>= ; wrote:


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the IP Wireless Access in Vehicular Environmen= ts 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: IP-based Vehicular Networking: Use Cases, Survey and Problem Statement
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Jaeh= oon Paul Jeong
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-ietf-ipwave-vehicular-networking-02.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 52
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2018-03-05

Abstract:
=C2=A0 =C2=A0This document discusses use cases, survey, and problem stateme= nt on
=C2=A0 =C2=A0IP-based vehicular networks, which are considered a key compon= ent of
=C2=A0 =C2=A0Intelligent Transportation Systems (ITS).=C2=A0 The main topic= s of
=C2=A0 =C2=A0vehicular networking are vehicle-to-vehicle (V2V), vehicle-to-=
=C2=A0 =C2=A0infrastructure (V2I), and infrastructure-to-vehicle (I2V) networking.
=C2=A0 =C2=A0First, this document surveys use cases using V2V and V2I networking.
=C2=A0 =C2=A0Second, this document deals with some critical aspects in vehicular
=C2=A0 =C2=A0networking, such as vehicular network architectures, standardization
=C2=A0 =C2=A0activities, IP address autoconfiguration, routing, mobility =C2=A0 =C2=A0management, DNS naming service, service discovery, and securit= y and
=C2=A0 =C2=A0privacy.=C2=A0 For each aspect, this document discusses proble= m statement
=C2=A0 =C2=A0to analyze the gap between the state-of-the-art techniques and=
=C2=A0 =C2=A0requirements in IP-based vehicular networking.=C2=A0 Finally, = this
=C2=A0 =C2=A0document articulates discussions including the summary and analysis
=C2=A0 =C2=A0of vehicular networking aspects and raises deployment issues.<= br>

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-iet= f-ipwave-vehicular-networking/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ipwave= -vehicular-networking-02
https://datatracker.ietf.org/doc/ht= ml/draft-ietf-ipwave-vehicular-networking-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Dd= raft-ietf-ipwave-vehicular-networking-02


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

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

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



=C2=A0

--

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




--
--f4f5e80669bcedfb680566e7ef93-- From nobody Thu Mar 8 08:27: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 B36ED127241 for ; Thu, 8 Mar 2018 08:26:59 -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 QDrnyJOHXbSN for ; Thu, 8 Mar 2018 08:26:58 -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 6D8721241FC for ; Thu, 8 Mar 2018 08:26:58 -0800 (PST) Received: from resomta-po-06v.sys.comcast.net ([96.114.154.230]) by resqmta-po-04v.sys.comcast.net with ESMTP id tyMeedRv9M8WLtyNeeRQRn; Thu, 08 Mar 2018 16:26:58 +0000 Received: from [172.22.228.216] ([162.210.130.3]) by resomta-po-06v.sys.comcast.net with SMTP id tyLXe3SjO2O8MtyLaetgnk; Thu, 08 Mar 2018 16:24:56 +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: Date: Thu, 8 Mar 2018 08:24:47 -0800 Cc: its@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6637B0B0-494C-447B-9A12-021E885A8F50@tony.li> References: <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> <5ccad588-bcd8-d179-165b-7936a34220fb@gmail.com> <006c01d3b17f$88506750$98f135f0$@eurecom.fr> <01eb01d3b248$c24c0df0$46e429d0$@gmail.com> <4d3a05bf-169f-c531-c8b4-ba2310ae3e22@gmail.com> <1520020476.3381.4.camel@it.uc3m.es> <64DE64AB-CB38-4925-9B50-1576C7DA1C0A@gmail.com> <1520021896.3381.10.camel@it.uc3m.es> <9b5daf2c-8c75-61f3-dded-31b86506c4e1@gmail.com> <1520285521.4122.19.camel@it.uc3m.es> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3445.5.20) X-CMAE-Envelope: MS4wfHrCytJLHfdk/TaWCdgdZRZuYhSUVCW8vXMf5VPgRbIQYqBCVx0Bel/FMQLa7XXlMm234/AdsoopWqol9sPT8uyjgF9Ns0MDlgeiSOwnYkAn+668IxEj KEwVwJfLwwImpCurA5R1fO8H0ptxtSl3Brlm//whTNHO78+seWR1gxDyAC40xC2dKzOYOt0LzCU4IAWTjpFfeHT/P6/F9uQXjG8= Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data - 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: Thu, 08 Mar 2018 16:27:00 -0000 Alex, >> The value of the Traffic Class field of the IP >> header MUST be x. >> Are you proposing that we rewrite a packet in flight? And if so, why? >=20 > I understand you assume rewriting, because a packet arriving from the = Internet would not have that Traffic Class set for OCB. Certainly I = dont propose rewriting, because communication from the Internet to a car = should happen end-to-end, without rewriting, nor translation, nor = proxying. >=20 > In the other direction - from the car to the Internet, and only for = 1-hop, the IP Traffic Class mapped to the 802.11 TID value and AC_BK, = would make sense. >=20 > Given that rewriting is not good, but mapping IP-to-.11 fields is good = for one hop, I dont know how to proceed. Once again, mapping IP to .11 fields is not good. The IP field is, with = some exceptions, subject to fraud. It is not wise for us to mandate a = mapping. If this is a feature desired by some end-users, they can request it and = apply it in cases where they feel that the IP traffic class is = meaningful. >> This doesn=E2=80=99t seem like the right thing to do. I would just = drop this sentence. >=20 > We can drop it. If we do, it would be very much about fields in = headers below IP (not fields in the IP header). It would be this: >=20 >> By default, the packet transmitted on 802.11-OCB with the value of = the >> EtherType field equal to 0x86dd (IPv6) MUST be preceded by an LLC >> header and a QoSData header; the value of the TID field is 0001 (aka >> UP=3D=3D1, AC_BK). >=20 > Should IETF write this before IEEE OCB does? The IEEE will never write that as it contains the word =E2=80=98IPv6=E2=80= =99. ;-) If that=E2=80=99s the behavior that the group wants, then yes, that=E2=80=99= s a preferable approach. I=E2=80=99m fine with it. >> Each IP-OBU and IP-RSU system MUST provide a knob (SNMP, Yang, = syscl, >> other); the default value of the knob MUST be 'false'. When the = value is >> 'true', the IP packet MUST be preceded by an LLC header and a Data >> header, and the value of the Traffic Class field in the IPv6 = header MUST >> NOT be restricted. The actioning of this knob MUST be performed in >> accordance with local regulation. >> I get that you=E2=80=99re trying to allow Data between consenting = adults, but you can do that by going outside of the spec anyway, so = I=E2=80=99m not seeing this as buying you much. Plus, implementations = will probably not need this. I=E2=80=99d suggest dropping this too. >=20 > There is this hackathon opportunity. They say they dont have = expensive cards there. They ask which Internet Draft to test. What = would you tell them? I don=E2=80=99t understand your comment and the relevance to setting a = global standard for perpetuity. If people don=E2=80=99t have the right kit, hardware or software, they = should get it. This is clearly evolving technology. I=E2=80=99m sorry = that they experience inconvenience now, but we are not going to cause = inconvenience for every other implementation just to save them some = money. Tony From nobody Thu Mar 8 09:09: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 2DCA112751F for ; Thu, 8 Mar 2018 09:09:54 -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 f1uSUT490PSU for ; Thu, 8 Mar 2018 09:09:52 -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 659031270A7 for ; Thu, 8 Mar 2018 09:09:52 -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 w28H9oP3013297 for ; Thu, 8 Mar 2018 18:09:50 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A7138207159 for ; Thu, 8 Mar 2018 18:09: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 93CD020494B for ; Thu, 8 Mar 2018 18:09: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 w28H9oBr013375 for ; Thu, 8 Mar 2018 18:09:50 +0100 To: its@ietf.org References: <152027400826.14551.2766762404227800440@ietfa.amsl.com> <1B326624F8EE4A19B7C94AED23C7CE5C@SRA6> From: Alexandre Petrescu Message-ID: Date: Thu, 8 Mar 2018 18:09:50 +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-vehicular-networking-02.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, 08 Mar 2018 17:09:54 -0000 Le 08/03/2018 à 16:00, Mr. Jaehoon Paul Jeong a écrit : [...] > The WSA optionally can transmit a local IPv6 prefix, which can be > used for SLAAC as I understand it. Well I dont think any computer uses WSA, instead of an RA, to configure an address with the SLAAC protocol. It would be straight layer violation if the IP stack interpreted a non-IP message (the WSA). Or maybe we should not call it 'SLAAC' but something else. Alex From nobody Thu Mar 8 13:02: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 073341270A0 for ; Thu, 8 Mar 2018 13:02:36 -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 1xdzvLGziN3e for ; Thu, 8 Mar 2018 13:02:34 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::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 D2A00126B6D for ; Thu, 8 Mar 2018 13:02:33 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id 139so319267wmn.2 for ; Thu, 08 Mar 2018 13:02:33 -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=m+H0YPOmG6sP1U4m89bHwSGsG3o5b9CArb9deBPXklA=; b=R4qQvskdqH8fhmYfM40yB+oEYl18p9zmkjlrAXXBx8WxhzlBK4ZVs3yHGK++/A1rUe S2A6rimns9/nJd0PCUAq8+sCnFy/CJiofrL7zNMMlMZfOJ6uN+gyyQtmSFIBZVQvPbzh lV+HzyoG81G8+fE/ALsTvDJUsRtpItHfTu1USDmfPAp97KDvfOb18DuFw/J5r6s629aq 6M8PbTM6zmM9GHBtRd5zpZA7OTb7yKeJtv28/vD+61XGgO/WPg8AAKzUwWg6blkozi3/ qgvtBZOch6NRfhaj/evZo/DR51paW1KxrevCRfGV9KRYcDRmvNbscq9fS03uH6wYwqkw 961Q== 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=m+H0YPOmG6sP1U4m89bHwSGsG3o5b9CArb9deBPXklA=; b=WwCz5IW58tEjsp58ipOCppfukyVtIXov93XNmEbpBlE/7kvoFo1odchppmFMvxFpXl V6VW74j9SQ6pQJB9rC2c6u39kIVONmxe3bdLQoVduF+6UFPCWZ8wpu1K7HFhrrAGw2nP jKc37Z/W1/F+Wr1yEavop6Pun9VezRqb+b7PV8W8xW1c1xgEJZB+k0Fj3AJGcThKmZSp LxOcX1kW2zDYyKJ5M2X8DFOWuZzie39QXf6shTVtRXsN6RkflcL1gU8YBpwyypNfm2Ui 3mi58yvxzwA5IfQdlWQKvdEeqE/gp/1JlQBJr6TZbwRS//8i6P0PyryGlk2kHessPzvh Vexg== X-Gm-Message-State: AElRT7EqYoEq1/EAVQ/guEjkU/HZFHdS2qHvtqe2Yj5N3+0IAb0+QHEI 72z3VDvp1P5aJudQW7McNAa5Wvua X-Google-Smtp-Source: AG47ELtbdPCP6njPBEmvIvEGyPv49GpK1PuBKy4WJ21BlaYA6JToSamS6U9Jq92+UD/3dOeFSObsNA== X-Received: by 10.28.239.18 with SMTP id n18mr162298wmh.56.1520542952168; Thu, 08 Mar 2018 13:02:32 -0800 (PST) Received: from cjbc_dell.lan (2.154.161.159.dyn.user.ono.com. [2.154.161.159]) by smtp.gmail.com with ESMTPSA id v8sm8589428wmh.25.2018.03.08.13.02.31 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 08 Mar 2018 13:02:31 -0800 (PST) Message-ID: <1520542950.4138.16.camel@it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano Reply-To: cjbc@it.uc3m.es To: "its@ietf.org" Cc: ipwave-chairs@ietf.org Date: Thu, 08 Mar 2018 22:02:30 +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] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-21 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 08 Mar 2018 21:02:36 -0000 Hi, Since the document has changed quite a bit since the first WGLC (done over version -08), we are are issuing a short WGLC for draft-ietf- ipwave-ipv6-over-80211ocb-21. The WGLC will be open till the 15th of March. Please comment on the latest version. There is still one open issue about the use of the 802.11 headers. We plan to close this by the London meeting, so if yiu have specific comments on this, please do state them. If you have no comments and think the document is ready, please do send a note stating that to the WG ML. Additional information about the document is below: Name: draft-ietf-ipwave-ipv6-over-80211ocb Revision: 21 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-03-03 Group: ipwave Pages: 39 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-21 Thank you for your support. -- Russ and Carlos From nobody Thu Mar 8 14:35: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 E3BF112708C for ; Thu, 8 Mar 2018 14:35:32 -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=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 dWOY-iOb0Mc4 for ; Thu, 8 Mar 2018 14:35:30 -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 2588C1205D3 for ; Thu, 8 Mar 2018 14:35:29 -0800 (PST) Received: from resomta-po-02v.sys.comcast.net ([96.114.154.226]) by resqmta-po-02v.sys.comcast.net with ESMTP id u480e4aFQZynEu48HeDjGD; Thu, 08 Mar 2018 22:35:29 +0000 Received: from [172.22.228.216] ([162.210.130.3]) by resomta-po-02v.sys.comcast.net with SMTP id u468eQiGFPj7iu46AezUNd; Thu, 08 Mar 2018 22:33: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 In-Reply-To: <1520542950.4138.16.camel@it.uc3m.es> Date: Thu, 8 Mar 2018 14:33:15 -0800 Cc: "its@ietf.org" , ipwave-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <1520542950.4138.16.camel@it.uc3m.es> To: cjbc@it.uc3m.es X-Mailer: Apple Mail (2.3445.5.20) X-CMAE-Envelope: MS4wfNISEUey4/IK63XBUAzB1TophcfbrvCkihzYKy4bU5usyJSGbkJUmdH6kJ8SB3/CR06qWDzh6RS0x8l2wQLOZT+o63H4dl42/beeswhF0uorv/nrDZze ZxfzZ2jJ9A08Ff5kfT3Wb2tQGAlDPMQ8AafXmo/7dFsNjnmARdvcmwd5FiTQYVKOOR/h8KzSP4m3SqLM6JysRyQkv6sGPhWiQlgyq2quo73DQaNvXL98o+K2 Archived-At: Subject: Re: [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-21 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 08 Mar 2018 22:35:33 -0000 Hi Carlos, I feel that the document is NOT ready for publication in its current = form. I have no issues that haven=E2=80=99t been discussed, but until we close = on the QoSData wording, we should not proceed. I=E2=80=99m hopeful that we can close things by London, if not sooner. Tony > On Mar 8, 2018, at 1:02 PM, Carlos Jes=C3=BAs Bernardos Cano = wrote: >=20 > Hi, >=20 > Since the document has changed quite a bit since the first WGLC (done > over version -08), we are are issuing a short WGLC for draft-ietf- > ipwave-ipv6-over-80211ocb-21.=20 >=20 > The WGLC will be open till the 15th of March. Please comment on the > latest version. There is still one open issue about the use of the > 802.11 headers. We plan to close this by the London meeting, so if yiu > have specific comments on this, please do state them. >=20 > If you have no comments and think the document is ready, please do = send > a note stating that to the WG ML. >=20 > Additional information about the document is below: >=20 > Name: draft-ietf-ipwave-ipv6-over-80211ocb > Revision: 21 > 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-03-03 > Group: ipwave > Pages: 39 >=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 > 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-21 >=20 > Thank you for your support. >=20 > -- Russ and Carlos >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Fri Mar 9 05:30: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 48068126579 for ; Fri, 9 Mar 2018 05:30:58 -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 mLAB7E0rX-Ds for ; Fri, 9 Mar 2018 05:30:56 -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 ABA21126C3D for ; Fri, 9 Mar 2018 05:30:56 -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 w29DUs8C107015; Fri, 9 Mar 2018 14:30:54 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B091B202E61; Fri, 9 Mar 2018 14:30: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 99D26200F47; Fri, 9 Mar 2018 14:30: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 w29DUsfs027507; Fri, 9 Mar 2018 14:30:54 +0100 To: Tony Li Cc: its@ietf.org References: <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> <5ccad588-bcd8-d179-165b-7936a34220fb@gmail.com> <006c01d3b17f$88506750$98f135f0$@eurecom.fr> <01eb01d3b248$c24c0df0$46e429d0$@gmail.com> <4d3a05bf-169f-c531-c8b4-ba2310ae3e22@gmail.com> <1520020476.3381.4.camel@it.uc3m.es> <64DE64AB-CB38-4925-9B50-1576C7DA1C0A@gmail.com> <1520021896.3381.10.camel@it.uc3m.es> <9b5daf2c-8c75-61f3-dded-31b86506c4e1@gmail.com> <1520285521.4122.19.camel@it.uc3m.es> From: Alexandre Petrescu Message-ID: <06f0bd38-aad4-ed35-bd23-2ea4840b0cd5@gmail.com> Date: Fri, 9 Mar 2018 14:30: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: 7bit Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data - 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: Fri, 09 Mar 2018 13:30:58 -0000 > tony.li@tony.li Thu, 08 March 2018 16:26 UTCShow header [...] I propose this text: > The IPv6 packet transmitted on 802.11-OCB MUST be immediately preceded > by a Logical Link Control (LLC) header and an 802.11 header; the value > of the Subtype sub-field in the Frame Control field of the 802.11 > header MUST be set to 8 (i.e. 'QoS Data'); the value of the Traffic > Identifier (TID) sub-field of the QoS Control field of the 802.11 > header MUST be set to binary 001 (i.e. User Priority 'Background', QoS > Access Category 'AC_BK'). Do you agree with the values? Alex [...] From nobody Fri Mar 9 05:56: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 9D9F3126CF9 for ; Fri, 9 Mar 2018 05:56:12 -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 qcNe003xaHv7 for ; Fri, 9 Mar 2018 05:56:10 -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 79E35126C3D for ; Fri, 9 Mar 2018 05:56: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 w29Du8bH010796; Fri, 9 Mar 2018 14:56:08 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7D810203025; Fri, 9 Mar 2018 14:56:08 +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 6FD9C203173; Fri, 9 Mar 2018 14:56:08 +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 w29Du8GL023610; Fri, 9 Mar 2018 14:56:08 +0100 To: Tony Li Cc: its@ietf.org References: <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> <5ccad588-bcd8-d179-165b-7936a34220fb@gmail.com> <006c01d3b17f$88506750$98f135f0$@eurecom.fr> <01eb01d3b248$c24c0df0$46e429d0$@gmail.com> <4d3a05bf-169f-c531-c8b4-ba2310ae3e22@gmail.com> <1520020476.3381.4.camel@it.uc3m.es> <64DE64AB-CB38-4925-9B50-1576C7DA1C0A@gmail.com> <1520021896.3381.10.camel@it.uc3m.es> <9b5daf2c-8c75-61f3-dded-31b86506c4e1@gmail.com> <1520285521.4122.19.camel@it.uc3m.es> From: Alexandre Petrescu Message-ID: Date: Fri, 9 Mar 2018 14:56:08 +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 - ranting X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 09 Mar 2018 13:56:13 -0000 > Re: [ipwave] 802.11 Data vs 802.11 QoS Data - towards resolution > > tony.li@tony.li Thu, 08 March 2018 16:26 UTCShow header > > Alex, > > >>> The value of the Traffic Class field of the IP header MUST be x. >>> Are you proposing that we rewrite a packet in flight? And if so, >>> why? >> >> I understand you assume rewriting, because a packet arriving from >> the Internet would not have that Traffic Class set for OCB. >> Certainly I dont propose rewriting, because communication from the >> Internet to a car should happen end-to-end, without rewriting, nor >> translation, nor proxying. >> >> In the other direction - from the car to the Internet, and only for >> 1-hop, the IP Traffic Class mapped to the 802.11 TID value and >> AC_BK, would make sense. >> >> Given that rewriting is not good, but mapping IP-to-.11 fields is >> good for one hop, I dont know how to proceed. > > > Once again, mapping IP to .11 fields is not good. The IP field is, > with some exceptions, subject to fraud. It is not wise for us to > mandate a mapping. > > If this is a feature desired by some end-users, they can request it > and apply it in cases where they feel that the IP traffic class is > meaningful. Ok, maybe later we can think of another draft that overrides that. I am thinking that some traffic _inside_ the car, on future-Ethernet, must respect some stringent in-car QoS requirements. I would like the ADSystem in one car to talk to the ADSystem in the other car, over the OCB interfaces in series with the future-Ethernet interfaces. That would make for some need for mapping IP TC field into QoS fields of future-Ethernet and of OCB, I think. (it's useless to guarantee QoS _outside_ the car if it's not guaranteed inside too; just like it cant be pretended to guarantee QoS for BSM if IP-over-OCB does not use QoSData). >>> This doesn’t seem like the right thing to do. I would just drop >>> this sentence. >> >> We can drop it. If we do, it would be very much about fields in >> headers below IP (not fields in the IP header). It would be this: >> >>> By default, the packet transmitted on 802.11-OCB with the value >>> of the EtherType field equal to 0x86dd (IPv6) MUST be preceded by >>> an LLC header and a QoSData header; the value of the TID field is >>> 0001 (aka UP==1, AC_BK). >> >> Should IETF write this before IEEE OCB does? > > > The IEEE will never write that as it contains the word ‘IPv6’. ;-) > > If that’s the behavior that the group wants, then yes, that’s a > preferable approach. I’m fine with it. I understand that you think the group wants IETF to write it first. So be it. >>> Each IP-OBU and IP-RSU system MUST provide a knob (SNMP, Yang, >>> syscl, other); the default value of the knob MUST be 'false'. >>> When the value is 'true', the IP packet MUST be preceded by an >>> LLC header and a Data header, and the value of the Traffic Class >>> field in the IPv6 header MUST NOT be restricted. The actioning of >>> this knob MUST be performed in accordance with local regulation. >>> I get that you’re trying to allow Data between consenting adults, >>> but you can do that by going outside of the spec anyway, so I’m >>> not seeing this as buying you much. Plus, implementations will >>> probably not need this. I’d suggest dropping this too. >> >> There is this hackathon opportunity. They say they dont have >> expensive cards there. They ask which Internet Draft to test. >> What would you tell them? > > > I don’t understand your comment and the relevance to setting a global > standard for perpetuity. > > If people don’t have the right kit, hardware or software, they should > get it. This is clearly evolving technology. I’m sorry that they > experience inconvenience now, but we are not going to cause > inconvenience for every other implementation just to save them some > money. It is not complex to write software to make IP packets for the expensive 802.11-OCB QoSData-capable cards, but only the manufacturers of these cards have the necessary tools to do it. It is complex to write software to make QoSData headers for the cheap 802.11-OCB Data-capable cards that already support IP, but very many open-source developpers in the Internet have the necessary tools to do it. Maybe this Internet Draft is for both manufacturers and open-source developpers. Alex > > Tony > From nobody Fri Mar 9 06:42: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 6FC9412D779 for ; Fri, 9 Mar 2018 06:42: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 GqKFxUHGsMV8 for ; Fri, 9 Mar 2018 06:42:19 -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 EBF24126D85 for ; Fri, 9 Mar 2018 06:42:18 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id t6so4315180wmt.5 for ; Fri, 09 Mar 2018 06:42:18 -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=BhZZBSYQ8fPlM29Kf/pI2NDykLVEIyYO0k3aToNsObI=; b=LRL2z+BC+erJR82DVkoWHg3khZn31iindZbk/aTCW+qVhQ3inkBXa4ePerV+GZAp6M 35EaXME7344X/D/Ldo0RLsJ5YBlPEUhf3ivirxotPH+tylYcgwKmALxIxNvLmQh0Uht8 ProAHwkRfXOtRTWCfkoGdtdP3IhrLYEArJTFz9focnC+tgD6nyjbivszY5KFQ4xxkr/g qtv4lSvIfmeCx57Yl/ybq0KxsFgndcwELEcpLgtm/I02QK8kwxqfH6Szm3CtAy0auor1 WmJh45nlaKZGHrDKB+CYcOnsVPAGImvZ/4+8+i6RpqyP2fPCtnxpyKI6ZRWYoO0aPMeY TP7g== 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=BhZZBSYQ8fPlM29Kf/pI2NDykLVEIyYO0k3aToNsObI=; b=rxBjJQNPdxmd1gO/VRHtVvvN03ntL0E/KlKWfFf+Li38Kr14+WDhHViEw/oSeN/Nho efYVXZ56k5n4lX5T8WHmHpvPjxhfs/b483ZORpocJ8N48xaTgH24PT69eAc8krnG4GTO pu3r0DWTFPHjVSWc6Y/n/nBHkcjMQH9UjA1iVNcH8fporNTyjGHqZDLIn/zHVCQB7+Mx fmEcVvwLzQj5RguOEXR0bnmUG3udYbllU21/LOL1bG1HkySviwtGlgSuJMhQatOoEask LDJXBKedCRXZnZARO5je3DF/ld1E3pfdW8tSaI7MgQO2b0h+Vokr/qTDGJpO1Y1xMEak /BsA== X-Gm-Message-State: AElRT7FKTvo/P9PAQ+3c4W32WAXRVyOS0JTu3myB6Ubwvqhgt1/puXaj epMejanEf2vTTELvMvv/IBi0EXq9 X-Google-Smtp-Source: AG47ELvbLADX+2ORv7h8PwY4kQhLJNCK3SwfKGTwO0BEtvsFzd0Pytpvcpmo4ligKObsy6y7lI74Ig== X-Received: by 10.28.74.88 with SMTP id x85mr2251535wma.106.1520606537408; Fri, 09 Mar 2018 06:42:17 -0800 (PST) Received: from acorde ([2001:720:410:1010:d681:d7ff:fe28:350b]) by smtp.gmail.com with ESMTPSA id y65sm1318602wmg.25.2018.03.09.06.42.16 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 09 Mar 2018 06:42:16 -0800 (PST) Message-ID: <1520606535.5012.58.camel@it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano Reply-To: cjbc@it.uc3m.es To: Tony Li Cc: "its@ietf.org" , ipwave-chairs@ietf.org Date: Fri, 09 Mar 2018 15:42:15 +0100 In-Reply-To: References: <1520542950.4138.16.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] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-21 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 09 Mar 2018 14:42:22 -0000 Hi Tony, Understood. Our intention is to understand if the WG is happy with the rest of the document. We are fully aware we have to close the qosdata wording and will be done by London. Thanks, Carlos On Thu, 2018-03-08 at 14:33 -0800, Tony Li wrote: > Hi Carlos, > > I feel that the document is NOT ready for publication in its current > form. > > I have no issues that haven’t been discussed, but until we close on > the QoSData wording, we should not proceed. > I’m hopeful that we can close things by London, if not sooner. > > Tony > > > > On Mar 8, 2018, at 1:02 PM, Carlos Jesús Bernardos Cano > 3m.es> wrote: > > > > Hi, > > > > Since the document has changed quite a bit since the first WGLC > > (done > > over version -08), we are are issuing a short WGLC for draft-ietf- > > ipwave-ipv6-over-80211ocb-21. > > > > The WGLC will be open till the 15th of March. Please comment on the > > latest version. There is still one open issue about the use of the > > 802.11 headers. We plan to close this by the London meeting, so if > > yiu > > have specific comments on this, please do state them. > > > > If you have no comments and think the document is ready, please do > > send > > a note stating that to the WG ML. > > > > Additional information about the document is below: > > > > Name: draft-ietf-ipwave-ipv6-over-80211ocb > > Revision: 21 > > 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-03-03 > > Group: ipwave > > Pages: 39 > > > > 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-80211o > > cb/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-21 > > > > Thank you for your support. > > > > -- Russ and Carlos > > > > _______________________________________________ > > its mailing list > > its@ietf.org > > https://www.ietf.org/mailman/listinfo/its > > From nobody Fri Mar 9 06:43: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 3D9EC12D779 for ; Fri, 9 Mar 2018 06:43:22 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_HK_NAME_FM_MR_MRS=0.01, 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 Nc7DUCUWv9dN for ; Fri, 9 Mar 2018 06:43:20 -0800 (PST) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 3DE15128961 for ; Fri, 9 Mar 2018 06:43:20 -0800 (PST) Received: by mail-it0-x22a.google.com with SMTP id u5-v6so3101503itc.1 for ; Fri, 09 Mar 2018 06:43: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=E0MfwKsuPCQBScRhRcZ7DyAA1KB4lf3umFOzE6IlYzQ=; b=X4rdCSn7UmQ/k0HXGWzKjAmYhXJ3rqSPgPk0gTUDRc9mCkxwgodg/Ku04hBx13iu69 +efqrjpf7HapoMh+9WA6t8IyOGXzAx6ktvbI873Gc4+ByICHYXsHpaACg7C8IAsnmpaE liTrEw+e3WDU1qhlZQhlxh4r/PDv6YoBjcXhDIaQiWtEbEfrNQKTSkADVDpX42NntAbm zkQvEWxBtgD+X2En1ZxDMXFrsDt/370Mb/kT4+mjCq4Bf8eFdKAs9jMACxoq3GbHISvl sD60L1OsnfuspqlpeVI0Oi75jCjvCvuprOtUg9VPORjcJnitpnig3O1p+0I+45y1t6SH p1Jw== 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=E0MfwKsuPCQBScRhRcZ7DyAA1KB4lf3umFOzE6IlYzQ=; b=Kx5HdKUSR2cDvQzLwmI49poypdfq2MsIDh5gaG0RgsN23xmZNAkvqFB/lxNPaKsXFN RKXaaiC4vOce70IRyZCFTU6W8MoOXyNivu34ptGb9WRjLqkYVGuJTUNJGaFU8r9+S74A Pzjxaf/N2hL4Q9qtf2gRAU5RcyHP6XIRT4eyZF5qA/lLb+mnUBd6lgGOMMsBmz9c5NHA t6Yt15Jf1Z+Hy+o2NTIzfWFTci6jG6ANGxzIDchzLgpsZAtLsMq7iQudKIPWkiUnS0AR T9/yC0WOUh2aToI44+Xtmhb4LlSotyiN34yO6aUYXJBPUAEz2DCS6B/rbH1YXCFBjSRJ hr0Q== X-Gm-Message-State: AElRT7Hy/kaSBtC9/H3SD3e8k7bNA3+hx5M7qebX4j97Suj8HVCVN+dI FJOh4aKODJsQy2ee3ISbhixAJ3xB18QtZZz/fkg= X-Google-Smtp-Source: AG47ELvzNr/VgSrnR8CGK4Z1WMQLvDhmEGdLITFERwhSLO8/k1KN1yCdBTR/bp+3/eu8nn97zEbGoZqGQ6MdNXzOK34= X-Received: by 2002:a24:ac5d:: with SMTP id m29-v6mr3488633iti.133.1520606599428; Fri, 09 Mar 2018 06:43:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.147.194 with HTTP; Fri, 9 Mar 2018 06:42:48 -0800 (PST) In-Reply-To: References: <152027400826.14551.2766762404227800440@ietfa.amsl.com> <1B326624F8EE4A19B7C94AED23C7CE5C@SRA6> From: "Mr. Jaehoon Paul Jeong" Date: Fri, 9 Mar 2018 23:42:48 +0900 Message-ID: To: Alexandre Petrescu , Sandra Cespedes Cc: its@ietf.org Content-Type: multipart/alternative; boundary="00000000000033c0660566fbd082" Archived-At: Subject: Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicular-networking-02.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, 09 Mar 2018 14:43:22 -0000 --00000000000033c0660566fbd082 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alex, Thanks for your point. For the IPv6 address autoconfiguration based on WSA, we may call it WSA-based Stateless Address Autoconfiguration (WSLAAC). Sandra (as the 1st author of the VIP-WAVE paper for the above text) and others, Is there any other better name? https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-02#secti= on-4.1.1 Best Regards, Paul On Fri, Mar 9, 2018 at 2:09 AM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > > > Le 08/03/2018 =C3=A0 16:00, Mr. Jaehoon Paul Jeong a =C3=A9crit : > [...] > > The WSA optionally can transmit a local IPv6 prefix, which can be >> used for SLAAC as I understand it. >> > > Well I dont think any computer uses WSA, instead of an RA, to configure a= n > address with the SLAAC protocol. It would be straight layer violation if > the IP stack interpreted a non-IP message (the WSA). > > Or maybe we should not call it 'SLAAC' but something else. > > Alex > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php --00000000000033c0660566fbd082 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alex,
Thanks for your point.
For the IPv6= address autoconfiguration based on WSA, we may call it WSA-based Stateless= Address Autoconfiguration (WSLAAC).

Sandra (as th= e 1st author of the VIP-WAVE paper for the above text) and others,
Is there any other better name?

Best Regards,
Paul

On Fri, Mar 9, 2= 018 at 2:09 AM, Alexandre Petrescu <alexandre.petrescu@gmail.co= m> wrote:


Le 08/03/2018 =C3=A0 16:00, Mr. Jaehoon Paul Jeong a =C3=A9crit :
[...]

The WSA optionally can transmit a local IPv6 prefix, which can be
used for SLAAC as I understand it.

 Well I dont think any computer uses WSA, instead of an RA, to configure an = address with the SLAAC protocol.=C2=A0 It would be straight layer violation= if the IP stack interpreted a non-IP message (the WSA).

Or maybe we should not call it 'SLAAC' but something else.

Alex


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



--
=
=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon= (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software
Su= ngkyunkwan University
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com,=C2= =A0pauljeong@skku.edu
Personal Homepage: http= ://iotlab.skku.edu/people-jaehoon-jeong.php
=
--00000000000033c0660566fbd082-- From nobody Fri Mar 9 07:31: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 E2825126E64; Fri, 9 Mar 2018 07:31:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWxPuCXTEVVB; Fri, 9 Mar 2018 07:31:21 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B38A3126D85; Fri, 9 Mar 2018 07:31:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3550; q=dns/txt; s=iport; t=1520609481; x=1521819081; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=a1BSOBzAk/BPn7Vg01BwiphIoqUNuBBba6tpJ1msBJc=; b=XUyL1FcbtVge0cRSlRrBBKaMtMsFLpVatSrV45wG8D8pjSwSKbAtTUeU YawrvbjYI/lnF044AeiTvDz+O/h0XrABQl2zHXOvk3SgFj5rhIEkm1Q3u VfVoppBK4rR/5rxg9Pg9GQfRbfB3+hRN2FA88jl0ZDaPYbr34ttMPn9kp o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DqAAA2qKJa/4wNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNQZm8oCo1kjXeCBIEWlDSCFQoYC4UCAoMRITQYAQIBAQEBAQE?= =?us-ascii?q?CayeFJAEBBAEBbAsQAgEIGC4nCyUCBAENBYUZD68whHGDcoIahTeCLoFWgWaDL?= =?us-ascii?q?oMuAQECAQGBSoYOBI1yPIwnCQKGR4MQhxGBY4Q0iEqJeYcnAhETAYErAR44gVJ?= =?us-ascii?q?wFRkhgkMJhD93iXKBFwEBAQ?= X-IronPort-AV: E=Sophos;i="5.47,446,1515456000"; d="scan'208";a="81674893" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Mar 2018 15:31:20 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id w29FVK1g024899 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 9 Mar 2018 15:31:20 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 9 Mar 2018 09:31:15 -0600 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1320.000; Fri, 9 Mar 2018 09:31:15 -0600 From: "Sri Gundavelli (sgundave)" To: "cjbc@it.uc3m.es" , Tony Li CC: "its@ietf.org" , "ipwave-chairs@ietf.org" Thread-Topic: [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-21 Thread-Index: AQHTt7up9lXDtBz/wki/4fi6DQ4Bsw== Date: Fri, 9 Mar 2018 15:31:15 +0000 Message-ID: References: <1520542950.4138.16.camel@it.uc3m.es> <1520606535.5012.58.camel@it.uc3m.es> In-Reply-To: <1520606535.5012.58.camel@it.uc3m.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.188.60] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-21 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 09 Mar 2018 15:31:24 -0000 I have not followed all the discussions on the below thread, but I have reviewed the document and its is in good shape. I do suspect the below concern might be a valid issue and we need to resolve it and move the document forward. The rest of the document is in great shape. Sri On 3/9/18, 6:42 AM, "its on behalf of Carlos Jes=FAs Bernardos Cano" wrote: >Hi Tony, > >Understood. Our intention is to understand if the WG is happy with the >rest of the document. We are fully aware we have to close the qosdata >wording and will be done by London. > >Thanks, > >Carlos > >On Thu, 2018-03-08 at 14:33 -0800, Tony Li wrote: >> Hi Carlos, >>=20 >> I feel that the document is NOT ready for publication in its current >> form. >>=20 >> I have no issues that haven=B9t been discussed, but until we close on >> the QoSData wording, we should not proceed. >> I=B9m hopeful that we can close things by London, if not sooner. >>=20 >> Tony >>=20 >>=20 >> > On Mar 8, 2018, at 1:02 PM, Carlos Jes=FAs Bernardos Cano > > 3m.es> wrote: >> >=20 >> > Hi, >> >=20 >> > Since the document has changed quite a bit since the first WGLC >> > (done >> > over version -08), we are are issuing a short WGLC for draft-ietf- >> > ipwave-ipv6-over-80211ocb-21. >> >=20 >> > The WGLC will be open till the 15th of March. Please comment on the >> > latest version. There is still one open issue about the use of the >> > 802.11 headers. We plan to close this by the London meeting, so if >> > yiu >> > have specific comments on this, please do state them. >> >=20 >> > If you have no comments and think the document is ready, please do >> > send >> > a note stating that to the WG ML. >> >=20 >> > Additional information about the document is below: >> >=20 >> > Name: draft-ietf-ipwave-ipv6-over-80211ocb >> > Revision: 21 >> > 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-03-03 >> > Group: ipwave >> > Pages: 39 >> >=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 >> > The IETF datatracker status page for this draft is: >> > https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211o >> > cb/ >> >=20 >> > There are also htmlized versions available at: >> > https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-21 >> >=20 >> > Thank you for your support. >> >=20 >> > -- Russ and Carlos >> >=20 >> > _______________________________________________ >> > its mailing list >> > its@ietf.org >> > https://www.ietf.org/mailman/listinfo/its >>=20 >>=20 > >_______________________________________________ >its mailing list >its@ietf.org >https://www.ietf.org/mailman/listinfo/its From nobody Fri Mar 9 08:21: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 7A64F128961 for ; Fri, 9 Mar 2018 08:21:22 -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 xIi86fZDbggd for ; Fri, 9 Mar 2018 08:21: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 2F275127978 for ; Fri, 9 Mar 2018 08:21:21 -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 w29GLJAV161711 for ; Fri, 9 Mar 2018 17:21:19 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 352E02033C0 for ; Fri, 9 Mar 2018 17:21: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 20E5D201C23 for ; Fri, 9 Mar 2018 17:21: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 w29GLIAV019891 for ; Fri, 9 Mar 2018 17:21:19 +0100 To: "its@ietf.org" From: Alexandre Petrescu Message-ID: <1aef43a6-308a-ef9f-ff1d-3041443bb991@gmail.com> Date: Fri, 9 Mar 2018 17:21:18 +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="------------2FEE3D3214E200919B968576" Content-Language: fr Archived-At: Subject: [ipwave] =?utf-8?q?IPv6-over-OCB_during_Hackathon_in_S=C3=A9n?= =?utf-8?b?w6lnYWw=?= X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 09 Mar 2018 16:21:22 -0000 This is a multi-part message in MIME format. --------------2FEE3D3214E200919B968576 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit The IPv6-over-802.11-OCB draft too will be tested during a Hackathon in Sénégal https://hackathon.internetsummitafrica.org/doku.php?id=hackathon2018 Thanks Nabil, Alex --------------2FEE3D3214E200919B968576 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

The IPv6-over-802.11-OCB draft too will be tested during a Hackathon in Sénégal

https://hackathon.internetsummitafrica.org/doku.php?id=hackathon2018

Thanks Nabil,

Alex

--------------2FEE3D3214E200919B968576-- From nobody Fri Mar 9 08:37: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 BE287126FDC for ; Fri, 9 Mar 2018 08:37:10 -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 cZqGbHEntaNo for ; Fri, 9 Mar 2018 08:37:09 -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 7CEB212704A for ; Fri, 9 Mar 2018 08:37:09 -0800 (PST) Received: from resomta-po-16v.sys.comcast.net ([96.114.154.240]) by resqmta-po-06v.sys.comcast.net with ESMTP id uL0meQlmoJlnyuL13e4bbq; Fri, 09 Mar 2018 16:37:09 +0000 Received: from [172.22.228.216] ([162.210.130.3]) by resomta-po-16v.sys.comcast.net with SMTP id uKyweHkGpWSeCuKyyei1mg; Fri, 09 Mar 2018 16:35:07 +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: Date: Fri, 9 Mar 2018 08:34:57 -0800 Cc: its@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> <5ccad588-bcd8-d179-165b-7936a34220fb@gmail.com> <006c01d3b17f$88506750$98f135f0$@eurecom.fr> <01eb01d3b248$c24c0df0$46e429d0$@gmail.com> <4d3a05bf-169f-c531-c8b4-ba2310ae3e22@gmail.com> <1520020476.3381.4.camel@it.uc3m.es> <64DE64AB-CB38-4925-9B50-1576C7DA1C0A@gmail.com> <1520021896.3381.10.camel@it.uc3m.es> <9b5daf2c-8c75-61f3-dded-31b86506c4e1@gmail.com> <1520285521.4122.19.camel@it.uc3m.es> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3445.5.20) X-CMAE-Envelope: MS4wfCsstj8A92/GbVRzLsDjhwC5RSqZk4Ll7mCWJDeud+Nc3VR2vn26jLFC6UG0tEafOxlxMI+bH4UBAEytAbNgZrZezP+XgyCotngvJ5d4xvrta65VHyIz KBGUvYzoCuBZpNqf3fWVTPg2uXifBQ6dbI3Ws8JCR1fVwLDXIszH2t0AuqpWxfMDX7vCxD2YhJX8ERzSXF6Cm9+NqPsVlyeHZv8= Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data - ranting X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 09 Mar 2018 16:37:11 -0000 Alex, >> Once again, mapping IP to .11 fields is not good. The IP field is, >> with some exceptions, subject to fraud. It is not wise for us to >> mandate a mapping. >> If this is a feature desired by some end-users, they can request it >> and apply it in cases where they feel that the IP traffic class is >> meaningful. >=20 > Ok, maybe later we can think of another draft that overrides that. No draft is necessary. =20 What two consenting, adult implementations do within their own airspace = is their own business. > I am thinking that some traffic _inside_ the car, on future-Ethernet, > must respect some stringent in-car QoS requirements. Vehicle interior traffic will be Ethernet for chassis mounted systems = and will be Wi-Fi for passenger devices (mobile, tablet, laptop). This = much is very clear. The market has already decided. There is no QoS there today. It=E2=80=99s not magically going to happen. > (it's useless to guarantee QoS _outside_ the car if it's not = guaranteed > inside too; just like it cant be pretended to guarantee QoS for BSM if > IP-over-OCB does not use QoSData). Who is going to manage the QoS inside the car? While the vehicle based = systems might be well behaved, passenger devices are unregulated. > Maybe this Internet Draft is for both manufacturers and open-source = developpers. Always. Tony From nobody Fri Mar 9 08:38: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 7976712711E for ; Fri, 9 Mar 2018 08:38:39 -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 pYUASbXfgdXr for ; Fri, 9 Mar 2018 08:38:38 -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 71CCA12704A for ; Fri, 9 Mar 2018 08:38:38 -0800 (PST) Received: from resomta-po-16v.sys.comcast.net ([96.114.154.240]) by resqmta-po-04v.sys.comcast.net with ESMTP id uL1Gef2VGM8WLuL2UeU3x4; Fri, 09 Mar 2018 16:38:38 +0000 Received: from [172.22.228.216] ([162.210.130.3]) by resomta-po-16v.sys.comcast.net with SMTP id uKyweHkGpWSeCuL0Qei1zA; Fri, 09 Mar 2018 16:36:36 +0000 From: tony.li@tony.li Message-Id: <6B4E76BD-368D-49C1-A625-B7B770ECA023@tony.li> Content-Type: multipart/alternative; boundary="Apple-Mail=_0F4F3913-69D4-47FA-9475-7429B2C5E782" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Fri, 9 Mar 2018 08:36:29 -0800 In-Reply-To: <06f0bd38-aad4-ed35-bd23-2ea4840b0cd5@gmail.com> Cc: its@ietf.org To: Alexandre Petrescu References: <7fb5a2f4-80b4-c481-1358-0999e5124756@gmail.com> <5ccad588-bcd8-d179-165b-7936a34220fb@gmail.com> <006c01d3b17f$88506750$98f135f0$@eurecom.fr> <01eb01d3b248$c24c0df0$46e429d0$@gmail.com> <4d3a05bf-169f-c531-c8b4-ba2310ae3e22@gmail.com> <1520020476.3381.4.camel@it.uc3m.es> <64DE64AB-CB38-4925-9B50-1576C7DA1C0A@gmail.com> <1520021896.3381.10.camel@it.uc3m.es> <9b5daf2c-8c75-61f3-dded-31b86506c4e1@gmail.com> <1520285521.4122.19.camel@it.uc3m.es> <06f0bd38-aad4-ed35-bd23-2ea4840b0cd5@gmail.com> X-Mailer: Apple Mail (2.3445.5.20) X-CMAE-Envelope: MS4wfM+IVmzBIO4cmIeGSFqgxPXQ5q1rVn3DZ0wrXFpDSM+jx6393MAPqkWoBSk/ZxYY4kv6tqDYKdO0GExmfixaU2zmNJnWtHFsc5kyZGZr1Nqk6BXhjqX4 Sm1l488xcTKGd8sB1WHC8WOTjVYp4dSWHJ6E4Tyox7cvxhr7kfpLLSixANWAMOrSJ7HdsreGTnWGHME8QB/ZFlE2IWqj8g/Ocs0= Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data - 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: Fri, 09 Mar 2018 16:38:39 -0000 --Apple-Mail=_0F4F3913-69D4-47FA-9475-7429B2C5E782 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Alex, >> The IPv6 packet transmitted on 802.11-OCB MUST be immediately = preceded >> by a Logical Link Control (LLC) header and an 802.11 header; the = value >> of the Subtype sub-field in the Frame Control field of the 802.11 >> header MUST be set to 8 (i.e. 'QoS Data'); the value of the Traffic >> Identifier (TID) sub-field of the QoS Control field of the 802.11 >> header MUST be set to binary 001 (i.e. User Priority 'Background', = QoS >> Access Category 'AC_BK'). >=20 > Do you agree with the values? I=E2=80=99m fine with this, thank you. Others? We need rough consensus=E2=80=A6. Tony --Apple-Mail=_0F4F3913-69D4-47FA-9475-7429B2C5E782 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Alex,


The IPv6 packet transmitted on 802.11-OCB MUST be immediately = preceded
by a Logical Link Control (LLC) header and an = 802.11 header; the value
of the Subtype sub-field in the = Frame Control field of the 802.11
header MUST be set to 8 = (i.e. 'QoS Data'); the value of the Traffic
Identifier = (TID) sub-field of the QoS Control field of the 802.11
header MUST be set to binary 001 (i.e. User Priority = 'Background', QoS
Access Category 'AC_BK').

Do you agree with the = values?



I=E2=80=99m fine with this, thank you.
Others?  We need rough = consensus=E2=80=A6.

Tony

= --Apple-Mail=_0F4F3913-69D4-47FA-9475-7429B2C5E782-- From nobody Fri Mar 9 11:59: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 477E612D885; Fri, 9 Mar 2018 11:59:51 -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 zGsonXg9wppW; Fri, 9 Mar 2018 11:59:48 -0800 (PST) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86B2D1201F8; Fri, 9 Mar 2018 11:59:48 -0800 (PST) Received: by mail-vk0-x235.google.com with SMTP id q7so2852938vkh.3; Fri, 09 Mar 2018 11:59: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; bh=bhTb5b1jt9SVhOMM8/MWj9ysHNRAww5tKXAbtc4vU+k=; b=JQGAYLJV+XB/njAAlLyVkKiU2egDnyhy3Lzr99ZYG1HqQPiHCLHfWDaJSAzltaXHKJ 0I/kTw2oW9LOo52ugd9UGafHHsc/JrtYyT9AIHyBZZ1aKc1BK0bb41aluw3C8PRz19mY s0SMWKKsx1Uriscz+kb6wXVnScECiu/1v2RBy2GXg4R6CnK8WPVIZpqjDRR7rVDTvrGB 543BWLXTBNAJG6mWrGtCn1hIOqBHl3goTqVnrm+u0teTClsXkBBPgb6QnMyyUPPMjWEX tPKYeBLBpVNlWMxZGmsTeFNg9KQEzgleeXWu2gdLNy3Y2En8PnWZ03v90lMUHZejXOR/ eAhQ== 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=bhTb5b1jt9SVhOMM8/MWj9ysHNRAww5tKXAbtc4vU+k=; b=FgcfnMq0mM67BtUPK8jOyjmuylXUxOQ8PzyO6wLlAjTrH5qqH41kl8fgYDpWMrVWEE vTp0lvDMMHzo6S/hQprTvpLbJtns0G3xyz6asK71ev5r8s5XGWGbNVxD9LmNaxijpeBm 8LdIURMa6kWYqK/YwYYD1s/7eyDNXB1Op9NidbDq3BT/alljOUGJf81Uz1tYlRljJ7We UZolcNBqnAHWmUmzg9WVMYYi6rKW+EMyeYPofEvU74wBmNFmBusc0iVejfZzCpGZGjem 2zEIPtrDxOBj/vXjlmWJLxyul2L6moE6Td3fGirUsKxsAMgyCra222FRQYtJQDx8Go0j jKlQ== X-Gm-Message-State: APf1xPA8R10s8KiUM30s7Kzzxm22utjwqPS4PRbbfvz7lTaRxPme6odW 44lUAc4Y/N5aj3TXsy9wod331JU4oWNNO9Ci71OY4w== X-Google-Smtp-Source: AG47ELuhghur84RtSr6dZ0byoCDGHIj8OrVKib/AcHznkaJfFOLVlhKnB/CJ+v8WkyXgmFt/Rvm589OqbspqkuhqtPE= X-Received: by 10.31.180.11 with SMTP id d11mr22627866vkf.20.1520625587250; Fri, 09 Mar 2018 11:59:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.4.72 with HTTP; Fri, 9 Mar 2018 11:59:46 -0800 (PST) In-Reply-To: References: <1520542950.4138.16.camel@it.uc3m.es> <1520606535.5012.58.camel@it.uc3m.es> From: Sara el hamdani Date: Fri, 9 Mar 2018 19:59:46 +0000 Message-ID: To: "its@ietf.org" , "ipwave-chairs@ietf.org" Content-Type: multipart/alternative; boundary="001a11438ca6f6ec9e0567003b21" Archived-At: Subject: Re: [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-21 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 09 Mar 2018 19:59:51 -0000 --001a11438ca6f6ec9e0567003b21 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Carlos, ALL I support this draft in its current form. 2018-03-09 15:31 GMT+00:00 Sri Gundavelli (sgundave) : > I have not followed all the discussions on the below thread, but I have > reviewed the document and its is in good shape. > > I do suspect the below concern might be a valid issue and we need to > resolve it and move the document forward. > > The rest of the document is in great shape. > > > Sri > > > > On 3/9/18, 6:42 AM, "its on behalf of Carlos Jes=C3=BAs Bernardos Cano" > wrote: > > >Hi Tony, > > > >Understood. Our intention is to understand if the WG is happy with the > >rest of the document. We are fully aware we have to close the qosdata > >wording and will be done by London. > > > >Thanks, > > > >Carlos > > > >On Thu, 2018-03-08 at 14:33 -0800, Tony Li wrote: > >> Hi Carlos, > >> > >> I feel that the document is NOT ready for publication in its current > >> form. > >> > >> I have no issues that haven=C2=B9t been discussed, but until we close = on > >> the QoSData wording, we should not proceed. > >> I=C2=B9m hopeful that we can close things by London, if not sooner. > >> > >> Tony > >> > >> > >> > On Mar 8, 2018, at 1:02 PM, Carlos Jes=C3=BAs Bernardos Cano >> > 3m.es> wrote: > >> > > >> > Hi, > >> > > >> > Since the document has changed quite a bit since the first WGLC > >> > (done > >> > over version -08), we are are issuing a short WGLC for draft-ietf- > >> > ipwave-ipv6-over-80211ocb-21. > >> > > >> > The WGLC will be open till the 15th of March. Please comment on the > >> > latest version. There is still one open issue about the use of the > >> > 802.11 headers. We plan to close this by the London meeting, so if > >> > yiu > >> > have specific comments on this, please do state them. > >> > > >> > If you have no comments and think the document is ready, please do > >> > send > >> > a note stating that to the WG ML. > >> > > >> > Additional information about the document is below: > >> > > >> > Name: draft-ietf-ipwave-ipv6-over-80211ocb > >> > Revision: 21 > >> > 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-03-03 > >> > Group: ipwave > >> > Pages: 39 > >> > > >> > 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-80211o > >> > cb/ > >> > > >> > There are also htmlized versions available at: > >> > https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-21 > >> > > >> > Thank you for your support. > >> > > >> > -- Russ and Carlos > >> > > >> > _______________________________________________ > >> > 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 *Best regards* *Sara EL HAMDANI* *Phd student -Umi University.* --001a11438ca6f6ec9e0567003b21 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Carlos, ALL

I support this draft in its c= urrent form.


2018-03= -09 15:31 GMT+00:00 Sri Gundavelli (sgundave) <sgundave@cisco.com>= :
I have not followed all the disc= ussions on the below thread, but I have
reviewed the document and its is in good shape.

I do suspect the below concern might be a valid issue and we need to
resolve it and move the document forward.

The rest of the document is in great shape.


Sri



On 3/9/18, 6:42 AM, "its on behalf of Carlos Jes=C3=BAs Bernardos Cano= "
<its-bounces@ietf.org on behalf of cjbc@it.uc3m.es> wrote:

>Hi Tony,
>
>Understood. Our intention is to understand if the WG is happy with the<= br> >rest of the document. We are fully aware we have to close the qosdata >wording and will be done by London.
>
>Thanks,
>
>Carlos
>
>On Thu, 2018-03-08 at 14:33 -0800, Tony Li wrote:
>> Hi Carlos,
>>
>> I feel that the document is NOT ready for publication in its curre= nt
>> form.
>>
>> I have no issues that haven=C2=B9t been discussed, but until we cl= ose on
>> the QoSData wording, we should not proceed.
>> I=C2=B9m hopeful that we can close things by London, if not sooner= .
>>
>> Tony
>>
>>
>> > On Mar 8, 2018, at 1:02 PM, Carlos Jes=C3=BAs Bernardos Cano = <cjbc@it.uc
>> > 3m.es> wrote:
>> >
>> > Hi,
>> >
>> > Since the document has changed quite a bit since the first WG= LC
>> > (done
>> > over version -08), we are are issuing a short WGLC for draft-= ietf-
>> > ipwave-ipv6-over-80211ocb-21.
>> >
>> > The WGLC will be open till the 15th of March. Please comment = on the
>> > latest version. There is still one open issue about the use o= f the
>> > 802.11 headers. We plan to close this by the London meeting, = so if
>> > yiu
>> > have specific comments on this, please do state them.
>> >
>> > If you have no comments and think the document is ready, plea= se do
>> > send
>> > a note stating that to the WG ML.
>> >
>> > Additional information about the document is below:
>> >
>> > Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-ipwa= ve-ipv6-over-80211ocb
>> > Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A021
>> > Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Transmission of IPv6= Packets over IEEE 802.11
>> > Networks
>> > operating in mode Outside the Context of a Basic Service Set = (IPv6-
>> > over-80211-OCB)
>> > Document date:=C2=A0 2018-03-03
>> > Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ipwave
>> > Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 39
>> >
>> > 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
>> > "802.11p")
>> >=C2=A0 =C2=A0there is a need to define a few parameters such a= s the supported
>> >=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 param= eters for IPv6 and
>> > IEEE
>> >=C2=A0 =C2=A0802.11-OCB networks; it portrays the layering of = IPv6 on 802.11-
>> > OCB
>> >=C2=A0 =C2=A0similarly to other known 802.11 and Ethernet laye= rs - by using 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-80211o
>> > cb/
>> >
>> > There are also htmlized versions available at:
>> > https://tools.ietf.= org/html/draft-ietf-ipwave-ipv6-over-80211ocb-21
>> >
>> > Thank you for your support.
>> >
>> > -- Russ and Carlos
>> >
>> > _______________________________________________
>> > its mailing list
>> > its@ietf.org
>> > https://www.ietf.org/mailman/listinfo/it= s
>>
>>
>
>_______________________________________________
>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



--
=
Best regards

= Sara EL HAMDANI
= Phd student=C2=A0-Umi University.
--001a11438ca6f6ec9e0567003b21-- From nobody Fri Mar 9 12:05: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 ED09812D88C for ; Fri, 9 Mar 2018 12:05: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, 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 fAETjqtDv1dV for ; Fri, 9 Mar 2018 12:05:04 -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 3A46D12420B for ; Fri, 9 Mar 2018 12:05:04 -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 w29K52tt008685 for ; Fri, 9 Mar 2018 21:05:02 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 16C96204850 for ; Fri, 9 Mar 2018 21:05:02 +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 087FF2047D2 for ; Fri, 9 Mar 2018 21:05:02 +0100 (CET) Received: from [132.166.84.143] ([132.166.84.143]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w29K51Xp012784 for ; Fri, 9 Mar 2018 21:05:01 +0100 References: <660BFCF2CF184B2C8ACA0743EA9BBB54@SRA6> To: "its@ietf.org" From: Alexandre Petrescu X-Forwarded-Message-Id: <660BFCF2CF184B2C8ACA0743EA9BBB54@SRA6> Message-ID: Date: Fri, 9 Mar 2018 21:05: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: <660BFCF2CF184B2C8ACA0743EA9BBB54@SRA6> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: [ipwave] Fwd: RE: 802.11 Data vs 802.11 QoS Data - 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: Fri, 09 Mar 2018 20:05:06 -0000 by this email you will see opposition from Dick Roy. (FYI the emails from Dick Roy dont show in archives, because of mailer problems). -------- Message transfr -------- Sujet: RE: [ipwave] 802.11 Data vs 802.11 QoS Data - towards resolution Date: Fri, 9 Mar 2018 08:50:06 -0800 De: Dick Roy Rpondre : dickroy@alum.mit.edu Organisation: SRA Pour: tony.li@tony.li, 'Alexandre Petrescu' Copie : its@ietf.org ------------------------------------------------------------------------ *From:*its [mailto:its-bounces@ietf.org] *On Behalf Of *tony.li@tony.li *Sent:* Friday, March 9, 2018 8:36 AM *To:* Alexandre Petrescu *Cc:* its@ietf.org *Subject:* Re: [ipwave] 802.11 Data vs 802.11 QoS Data - towards resolution Alex, >> The IPv6 packet transmitted on 802.11-OCB MUST be immediately preceded >> by a Logical Link Control (LLC) header and an 802.11 header; the value >> of the Subtype sub-field in the Frame Control field of the 802.11 >> header MUST be set to 8 (i.e. 'QoS Data'); the value of the Traffic >> Identifier (TID) sub-field of the QoS Control field of the 802.11 >> header MUST be set to binary 001 (i.e. User Priority 'Background', QoS >> Access Category 'AC_BK'). >> > > Do you agree with the values? > Im fine with this, thank you. Others? We need rough consensus. */[RR] Im not fine with it, unless it is conditioned on transmissions being in Channel 172 in the US, and even that is problematic since we currently have NO rules in place that make such requirements! Requiring ALL Ipv6 packets to be carried in MAC frames of a single type (QoSData in this case) is simply a bad idea, and should NOT be done, neitherand exactly the same argument applies to the priority!/* *//* */You asked again and once more I say dont do it!/* *//* */RR/* Tony From nobody Fri Mar 9 23:51: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 98108126D73 for ; Fri, 9 Mar 2018 23:51:21 -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 Nep5W9r_LxWn for ; Fri, 9 Mar 2018 23:51:19 -0800 (PST) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::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 DCE3F1242EA for ; Fri, 9 Mar 2018 23:51:18 -0800 (PST) Received: by mail-it0-x229.google.com with SMTP id u5-v6so5619371itc.1 for ; Fri, 09 Mar 2018 23:51: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=Jjs15mmqG+qTOKUMhsxoPJM/ni8b54ZHsOwpzfghTbc=; b=wiWb9MMRTFOHOxDJkzeKwxjOGIAxlYBdrZbirsFWMnaK5JEmgQSa1TBW21MFxDeEEa PPwXg4gtE7w1kacD7Ber7yXaUkbhc6hO+o5zyWR9MzCbgfHigce302bjqKx7jy8Pgjls UAF7aGJNVNABpNWemcTb3XXRLLr2BRTsF3kTh9coWXZsG44olu8AZbp3RlqWQ/FhrxJR ENFEyxdunFp6Ap+Vv2qZp/RrrvZ+FMxAmyQLbuH7chLkFhTy/shvukOduG7Tr3H8/l1j QcJa46No2bYexyU0g2dOj4HA0WJQrukpJPRyh79mP22V3XpqQ8g49jzyXWfPdFdzoN3G dczg== 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=Jjs15mmqG+qTOKUMhsxoPJM/ni8b54ZHsOwpzfghTbc=; b=HI14qB9iddMpW7EpiXbLy7+HJ/Jh/XkQAkLpUPWLl1SJKCItJSOY4mDxrdG9l0I54s tZGt7eiZCRyv28HJyi6Fpc06W0cvQlko+E2ddU7mV4rFkGBovwNuI9RYRy0yI3r2ZIas eAbgPWDMlgwWcWM8VoLnA6MSDguP3pSiYykOW1KShbak2poKWBWSWS2DWbDa/Ghspy4V eVwDgix6efMKYfMMnMC5RKvSFzbU0qNM4Vt2drxYaGgVW59zZzwCuaTvKwY3dh4mcKPu 2ak/EAlXOAdt/E9T5CO7YzGqdJvD6LP8gQv8BmUJDwRdh3iLKf8shItqsv9qqbMQwEAw 7bzA== X-Gm-Message-State: AElRT7EO3UcApMd8GzBKYhcdyGVEM9hmLvQ2dHeOnpbdbdxBeKzdIEDw ZvKVhQOJaFBTMpwgx/zCVyWMPZMXQGwfBb9vSRTQrQ== X-Google-Smtp-Source: AG47ELv/+T8Eimm/wHnOHJURDuHUUQ9r8/I6QMFXu5yqswsTc2NnSgFeXcXkg78EdFFJRNhkxnFrlK70rSTONV+TwQk= X-Received: by 10.36.91.201 with SMTP id g192mr857230itb.101.1520668278167; Fri, 09 Mar 2018 23:51:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.24.135 with HTTP; Fri, 9 Mar 2018 23:51:17 -0800 (PST) In-Reply-To: References: <1520542950.4138.16.camel@it.uc3m.es> <1520606535.5012.58.camel@it.uc3m.es> From: John Kenney Date: Sat, 10 Mar 2018 16:51:17 +0900 Message-ID: To: Sara el hamdani Cc: "its@ietf.org" , "ipwave-chairs@ietf.org" Content-Type: multipart/alternative; boundary="001a11424b1c8ab7da05670a2c7c" Archived-At: Subject: Re: [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-21 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 10 Mar 2018 07:51:22 -0000 --001a11424b1c8ab7da05670a2c7c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi All: There has been some question in this thread about whether IPv6 over OCB has been implemented with QoS data frames. I reached out to colleagues working on the NY Pilot Deployment. I was able to confirm that their devices will use QoS data frames to carry IPv6 packets (e.g. to connect to the security credential management system - SCMS). I hope that is helpful, John On Sat, Mar 10, 2018 at 4:59 AM, Sara el hamdani wrote: > Dear Carlos, ALL > > I support this draft in its current form. > > > 2018-03-09 15:31 GMT+00:00 Sri Gundavelli (sgundave) = : > >> I have not followed all the discussions on the below thread, but I have >> reviewed the document and its is in good shape. >> >> I do suspect the below concern might be a valid issue and we need to >> resolve it and move the document forward. >> >> The rest of the document is in great shape. >> >> >> Sri >> >> >> >> On 3/9/18, 6:42 AM, "its on behalf of Carlos Jes=C3=BAs Bernardos Cano" >> wrote: >> >> >Hi Tony, >> > >> >Understood. Our intention is to understand if the WG is happy with the >> >rest of the document. We are fully aware we have to close the qosdata >> >wording and will be done by London. >> > >> >Thanks, >> > >> >Carlos >> > >> >On Thu, 2018-03-08 at 14:33 -0800, Tony Li wrote: >> >> Hi Carlos, >> >> >> >> I feel that the document is NOT ready for publication in its current >> >> form. >> >> >> >> I have no issues that haven=C2=B9t been discussed, but until we close= on >> >> the QoSData wording, we should not proceed. >> >> I=C2=B9m hopeful that we can close things by London, if not sooner. >> >> >> >> Tony >> >> >> >> >> >> > On Mar 8, 2018, at 1:02 PM, Carlos Jes=C3=BAs Bernardos Cano > >> > 3m.es> wrote: >> >> > >> >> > Hi, >> >> > >> >> > Since the document has changed quite a bit since the first WGLC >> >> > (done >> >> > over version -08), we are are issuing a short WGLC for draft-ietf- >> >> > ipwave-ipv6-over-80211ocb-21. >> >> > >> >> > The WGLC will be open till the 15th of March. Please comment on the >> >> > latest version. There is still one open issue about the use of the >> >> > 802.11 headers. We plan to close this by the London meeting, so if >> >> > yiu >> >> > have specific comments on this, please do state them. >> >> > >> >> > If you have no comments and think the document is ready, please do >> >> > send >> >> > a note stating that to the WG ML. >> >> > >> >> > Additional information about the document is below: >> >> > >> >> > Name: draft-ietf-ipwave-ipv6-over-80211ocb >> >> > Revision: 21 >> >> > 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-03-03 >> >> > Group: ipwave >> >> > Pages: 39 >> >> > >> >> > 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-80211o >> >> > cb/ >> >> > >> >> > There are also htmlized versions available at: >> >> > https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-21 >> >> > >> >> > Thank you for your support. >> >> > >> >> > -- Russ and Carlos >> >> > >> >> > _______________________________________________ >> >> > 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 >> > > > > -- > *Best regards* > > > *Sara EL HAMDANI* > *Phd student -Umi University.* > > _______________________________________________ > 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 --001a11424b1c8ab7da05670a2c7c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All:

There has been some question in= this thread about whether IPv6 over OCB has been implemented with QoS data= frames.=C2=A0 I reached out to colleagues working on the NY Pilot Deployme= nt.=C2=A0 I was able to confirm that their devices will use QoS data frames= to carry IPv6 packets (e.g. to connect to the security credential manageme= nt system - SCMS).=C2=A0 =C2=A0=C2=A0

I hope that = is helpful,
John


On Sat, Mar 10, 2018 at 4:59 AM, Sara e= l hamdani <saraelhamdani@gmail.com> wrote:
Dear Carlos, ALL

I support this draft in its c= urrent form.


2018-03-09 15:31 GMT+00:00 Sri Gundavelli (sgundave) <sg= undave@cisco.com>:
I have n= ot followed all the discussions on the below thread, but I have
reviewed the document and its is in good shape.

I do suspect the below concern might be a valid issue and we need to
resolve it and move the document forward.

The rest of the document is in great shape.


Sri



On 3/9/18, 6:42 AM, "its on behalf of Carlos Jes=C3=BAs Bernardos Cano= "
<its-= bounces@ietf.org on behalf of cjbc@it.uc3m.es> wrote:

>Hi Tony,
>
>Understood. Our intention is to understand if the WG is happy with the<= br> >rest of the document. We are fully aware we have to close the qosdata >wording and will be done by London.
>
>Thanks,
>
>Carlos
>
>On Thu, 2018-03-08 at 14:33 -0800, Tony Li wrote:
>> Hi Carlos,
>>
>> I feel that the document is NOT ready for publication in its curre= nt
>> form.
>>
>> I have no issues that haven=C2=B9t been discussed, but until we cl= ose on
>> the QoSData wording, we should not proceed.
>> I=C2=B9m hopeful that we can close things by London, if not sooner= .
>>
>> Tony
>>
>>
>> > On Mar 8, 2018, at 1:02 PM, Carlos Jes=C3=BAs Bernardos Cano = <cjbc@it.uc
>> > 3m.es> wrote:
>> >
>> > Hi,
>> >
>> > Since the document has changed quite a bit since the first WG= LC
>> > (done
>> > over version -08), we are are issuing a short WGLC for draft-= ietf-
>> > ipwave-ipv6-over-80211ocb-21.
>> >
>> > The WGLC will be open till the 15th of March. Please comment = on the
>> > latest version. There is still one open issue about the use o= f the
>> > 802.11 headers. We plan to close this by the London meeting, = so if
>> > yiu
>> > have specific comments on this, please do state them.
>> >
>> > If you have no comments and think the document is ready, plea= se do
>> > send
>> > a note stating that to the WG ML.
>> >
>> > Additional information about the document is below:
>> >
>> > Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-ipwa= ve-ipv6-over-80211ocb
>> > Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A021
>> > Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Transmission of IPv6= Packets over IEEE 802.11
>> > Networks
>> > operating in mode Outside the Context of a Basic Service Set = (IPv6-
>> > over-80211-OCB)
>> > Document date:=C2=A0 2018-03-03
>> > Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ipwave
>> > Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 39
>> >
>> > 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
>> > "802.11p")
>> >=C2=A0 =C2=A0there is a need to define a few parameters such a= s the supported
>> >=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 param= eters for IPv6 and
>> > IEEE
>> >=C2=A0 =C2=A0802.11-OCB networks; it portrays the layering of = IPv6 on 802.11-
>> > OCB
>> >=C2=A0 =C2=A0similarly to other known 802.11 and Ethernet laye= rs - by using 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-80211o
>> > cb/
>> >
>> > There are also htmlized versions available at:
>> > https://tools.ietf.= org/html/draft-ietf-ipwave-ipv6-over-80211ocb-21
>> >
>> > Thank you for your support.
>> >
>> > -- Russ and Carlos
>> >
>> > _______________________________________________
>> > its mailing list
>> > its@ietf.or= g
>> > https://www.ietf.org/mailman/listinfo/it= s
>>
>>
>
>_______________________________________________
>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



<= /div>--
Best regards=

Sara EL HAMDANI
Phd student=C2=A0-Umi Universi= ty.

_______________________________________________
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
--001a11424b1c8ab7da05670a2c7c-- From nobody Sun Mar 11 08:31: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 CA2BC127010 for ; Sun, 11 Mar 2018 08:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.009 X-Spam-Level: X-Spam-Status: No, score=-1.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=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 wGW3SXw99xUD for ; Sun, 11 Mar 2018 08:31:32 -0700 (PDT) Received: from mail-lf0-x242.google.com (mail-lf0-x242.google.com [IPv6:2a00:1450:4010:c07::242]) (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 AEFFC126CC4 for ; Sun, 11 Mar 2018 08:31:31 -0700 (PDT) Received: by mail-lf0-x242.google.com with SMTP id t132-v6so3129881lfe.2 for ; Sun, 11 Mar 2018 08:31:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:reply-to:to:cc:organization:date :mime-version:content-transfer-encoding; bh=/giTmSB0SpmcvlypNqerXycccGUiD2CR1ujhsZmnR4U=; b=05Mkb/WoVJ3oMzFgCRJzL0b2Gf7CVuDT8F4mCVCTQ1yenwu8dYn09aNH+SiW6r4BC4 4MOkwFunl/mUm3qiyp5VmWYOP2++R3pLjRdC6VQ5OwhToj0nB1x6KVbMUpcF+2KC8C/w JkbURbuoZP0aLogatxvKZrKklCOBfgJqYmcOB+7fMUHr1q9NH2UR/G/o03ao1off9vB8 aLZ5yJgLbmXp50A53jS/Xxa+9pLf/cG0AntD6DYoOqKUTfJ5nPI2VBL7CIpsO2709EPR B2NTYWq0XzqspGw/ZK2LDx8LUMhVFSy1kRswoYgsPgKWilLVVx+sIEv66bheVADRRxbf 4LDA== 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 :organization:date:mime-version:content-transfer-encoding; bh=/giTmSB0SpmcvlypNqerXycccGUiD2CR1ujhsZmnR4U=; b=WrS+oycLLB0eu5hmOI+FHYrqXtN9yN7bL3dvXET+fxNA8hOC8/Bab9clksaAwGArlW +pQpFamfLvutMjZ4cqdOuXDcgagbjiKI7ZTFyDJRxxX/rlMUelGWkfji84bnH+4uADGq 8VFIMylaDPj9EMQbc6nMycXtz9cW+X7Zqh4GiYvb2jp/2JElPAwGpHlG1ArYP6cH8VGk 1dXCFcQnESR2CMHHhwzAYUYlmEz75plJXK73yfkJHtkqp0rTDxQ4LNoeY0WOtO+B/Sz7 t/aszwgm2q/CYwEUNsLPIfvCOBUbcuXyHGs2Gw7Qi048nO+MayW5zDhUix1LeiXD8FCo pg0g== X-Gm-Message-State: AElRT7GEIGvxetP+eMdaNiFa6tR+d3CkkH7fGOO8xWfabJFtpKAS9sPr RpCm///Ou8NbeYSHR8uoxyeJ5A8wqDHhww== X-Google-Smtp-Source: AG47ELtVhwPqu5DzD8pR0G2yPu8IryrMCPy7wSwiDWPFxiDqvIdUrz1GV7IQgf0ZS1k06o9pvDaDJQ== X-Received: by 2002:a19:e597:: with SMTP id i23-v6mr3317378lfk.66.1520782289608; Sun, 11 Mar 2018 08:31:29 -0700 (PDT) Received: from acorde (83-233-67-151.cust.bredband2.com. [83.233.67.151]) by smtp.gmail.com with ESMTPSA id a197-v6sm1256478lfe.86.2018.03.11.08.31.27 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 11 Mar 2018 08:31:28 -0700 (PDT) Message-ID: <1520768144.6055.9.camel@it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano Reply-To: cjbc@it.uc3m.es To: its@ietf.org Cc: ipwave-chairs@ietf.org Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" Date: Sun, 11 Mar 2018 12:35:44 +0100 Mime-Version: 1.0 X-Mailer: Evolution 3.26.3-1 Content-Transfer-Encoding: 7bit Archived-At: Subject: [ipwave] Agenda posted X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 15:31:34 -0000 Hi, We posted a tentative agenda some days ago, which has been updated to make room for an additional presentation. The draft agenda has been posted at: https://datatracker.ietf.org/meeting/101/materials/agenda-101-ipwave/ Thanks, Carlos and Russ From nobody Sun Mar 11 22:35: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 029921204DA; Sun, 11 Mar 2018 22:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_HK_NAME_FM_MR_MRS=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id looN8dN2brSg; Sun, 11 Mar 2018 22:35:31 -0700 (PDT) Received: from mail-it0-x243.google.com (mail-it0-x243.google.com [IPv6:2607:f8b0:4001:c0b::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 CD78F12025C; Sun, 11 Mar 2018 22:35:31 -0700 (PDT) Received: by mail-it0-x243.google.com with SMTP id j7-v6so9818502ita.3; Sun, 11 Mar 2018 22:35:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Yc/N0PDToWM3EsCfcLEXH8USRvQq7Wngptl2Y7h4r3c=; b=LHmRf3gCQWWWyZ2Jaas9Plh75PmJzCpmc33JRk2RKmvY/xJEFAsrYgaWB3ZjWBJON4 wTgIM3nVLfACgcT2Hl+K9kM+tAYTolTgNQ0HajObpX/KLkAsRArW+rzPpwREQI/+cuAV vzD6Mq0SYS0k9Jdx2v4aFWBevVsl3Fcu/MfUgVN0RhEdPCxu+Bt2Qls9Q75jQbqa1dgp SHtumwPAQJ/DxXnuzNXBdRciHE0S5pIxbBxnsty6PNMwtZROl667MOOTWj30ByttMfqY 5l4xMtO6G/FBcxpGvxoJN699cLJ+Db6FpPf5mgkYPNV4777bOj4KZnXwmh+6iynaGjCM bY2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Yc/N0PDToWM3EsCfcLEXH8USRvQq7Wngptl2Y7h4r3c=; b=d8N26hpQm7hth2vgEqRSxM8rxpJwkKmaL6zRJHfyknpqmGl7myY0N7PhPIKQpkYqTG +5ihe1lYEPtx9fevBgTPmrrzuajQuxipuvbpkd88ipQEj46ReUwAjm9eXrR7VeHBrZWf ndJ1cGK/3kXFiicQthE0aFXhAPnMTa18MvPCA9zVhK0stHoj6WCF5FWOi/r7K7qAhG5A 34tzukXi0RmUjljrj5bGwVRTbNOoS45tdRbPLmm7kvjLWKY2isPeW/xOEy48jxGSR9U+ ee/1wU+VVCupU4GARWKikueFgrGKWLpyDYfiAumCMx7X2yWr74A1nOJ09+OzmZG5vZNm H7WQ== X-Gm-Message-State: AElRT7H5+2q+AZmIjgEvUdBWDEBIh0pwDssIaHKQWRYxOMHMH2SEOg/C 4TT0QIrKBL5c4xhQN70hglHksgzC+5b2FRkr9QE= X-Google-Smtp-Source: AG47ELs8tiZKPqcfPf4I5pMtQTYexlHX0SCt17oLTPPgl2ndhuBA0rnQBr9WHReEKfvO5l5JpRf7O9GxegXWKEKG59k= X-Received: by 10.36.90.141 with SMTP id v135mr1296867ita.1.1520832931043; Sun, 11 Mar 2018 22:35:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.147.194 with HTTP; Sun, 11 Mar 2018 22:35:00 -0700 (PDT) In-Reply-To: <1520768144.6055.9.camel@it.uc3m.es> References: <1520768144.6055.9.camel@it.uc3m.es> From: "Mr. Jaehoon Paul Jeong" Date: Mon, 12 Mar 2018 14:35:00 +0900 Message-ID: To: CARLOS JESUS BERNARDOS CANO Cc: its@ietf.org, ipwave-chairs@ietf.org, SecCurator_Team , skku_iotlab_seminar@googlegroups.com, "Mr. Jaehoon Paul Jeong" Content-Type: multipart/alternative; boundary="001a1143c3209e2c3e05673082d0" Archived-At: Subject: Re: [ipwave] Agenda posted X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 05:35:34 -0000 --001a1143c3209e2c3e05673082d0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Carlos and Russ, Could you specify my second talk's title named TBD with the following? IPWAVE Standardization Topics: Prefix/Service Discovery, DNS Naming, and Seamless IP Networking. - draft-jeong-ipwave-vehicular-neighbor-discovery-02 ( https://tools.ietf.org/html/draft-jeong-ipwave-vehicular-neighbor-discovery= -02 ) - draft-jeong-ipwave-iot-dns-autoconf-02 (https://tools.ietf.org/html/draft-jeong-ipwave-iot-dns-autoconf-02) The two above drafts are my IPWAVE drafts updated recently. Thanks. Best Regards, Paul On Sun, Mar 11, 2018 at 8:35 PM, Carlos Jes=C3=BAs Bernardos Cano < cjbc@it.uc3m.es> wrote: > Hi, > > We posted a tentative agenda some days ago, which has been updated to > make room for an additional presentation. > > The draft agenda has been posted at: > > https://datatracker.ietf.org/meeting/101/materials/agenda-101-ipwave/ > > Thanks, > > Carlos and Russ > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php --001a1143c3209e2c3e05673082d0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Carlos and Russ,
Could you specify my second talk&#= 39;s title named TBD with the following?

IPWA= VE Standardization Topics: Prefix/Service Discovery, DNS Naming, and Seamle= ss IP Networking.
- draft-jeong-ipwave-vehicular-neighbor-discove= ry-02

- draft-jeong-ipwave-iot-dns-autoconf-02
<= div>
The two above drafts are my IPWAVE drafts updated recent= ly.

Thanks.

Best Regards,=
Paul



On Sun, Mar 11, 2018 at 8:35 PM, Ca= rlos Jes=C3=BAs Bernardos Cano <cjbc@it.uc3m.es> wrote:
Hi,

We posted a tentative agenda some days ago, which has been updated to
make room for an additional presentation.

The draft agenda has been posted at:

https://datatracker.ietf.org/meeting/101/materials/agenda-101-ipwave/

Thanks,

Carlos and Russ

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



--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeon= g, Ph.D.
Assistant Professor
Department of Software
Sungkyunkwan U= niversity
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com,=C2=A0pauljeong@skku.edu
Personal Homepage: http://iotlab.s= kku.edu/people-jaehoon-jeong.php
--001a1143c3209e2c3e05673082d0-- From nobody Mon Mar 12 03:06: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 48FE9127275 for ; Mon, 12 Mar 2018 03:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0UfsIxmHKUMD for ; Mon, 12 Mar 2018 03:06:14 -0700 (PDT) Received: from mail-lf0-x242.google.com (mail-lf0-x242.google.com [IPv6:2a00:1450:4010:c07::242]) (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 7A447126CC7 for ; Mon, 12 Mar 2018 03:06:14 -0700 (PDT) Received: by mail-lf0-x242.google.com with SMTP id w16-v6so1151369lfc.13 for ; Mon, 12 Mar 2018 03:06:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:reply-to:to:cc:date:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=C7QHyn8aJJQGboDRy5w7fv58DaNyGupqSkDxtgfcxO0=; b=MZoup6OxlQXTkZRiAPyofEBFJZRELCby7vxYotYlW/CKc5Lt7CYumbPWNMGD4PQwaV qNnQJ0tG9DTCV/ovwAMwP96uwkJnM2hXusKzZjDWUem0YB/1B5noYg+6XuDgC5U2GlHl IK+vrbueHkyGvVYJrjL7DMA30TwLZ2IpYm1X29HCbcHcHwpd9a5FgP7O9K5tCmBDvC/m ZC68/8Yj2KlJLAAfVERMFaaIWHgHuOiCA9rsTjfxHY8O41Zf1gwDrr6pMqp7sLWH+EK0 WgrHQPS4bknLT4BZcUZf8RhPER1SN3Wr9KARfCD/+Hcgvx1hORbvaw92MgvDMUY+5a53 gmzw== 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=C7QHyn8aJJQGboDRy5w7fv58DaNyGupqSkDxtgfcxO0=; b=SYK6Q4dIwqpYJYVMLq8TRQpAygUJBof9J3NPX+xUMeFwc1JGDvtxE9NoFFLkwOjudJ OcE9LJOwuScC9HZg9n9JywZVeL55rSVcuU/qGYRPhkReiPidEcbEppMfwSWaSsFO7jdk Yo/BapBWJuRXAwQyKQykpubEY/OkrJOuIosDW05cI/B1dvUDzr8dvrzmCPrEdMenPYW7 tsTmUv+/fw2g4bti6fKJbTliVscfDAPwFQ9rRuRl3wpzMNHhwPMhqWoCTaURr1rQY0AH jNEyim1mD3kEstA18Gh6hPb5i8sgvINDX79eFZRaR4IAuuCvv36v5mnkQvPDBeLRFm0I 30rw== X-Gm-Message-State: AElRT7FbO09QSn9dXE1XApwskJUmO+9WlF6ISsua//EDtQtXiEJ5jMs7 jk9hNeL/KmTYk/dk4063dRdBeQ== X-Google-Smtp-Source: AG47ELtp3cl+O+Hef8TKNzAEopBrax5ILKkNbQPcs+ebg2342XDeylFrEdYOq4Z3RACpdfJIM6vrWA== X-Received: by 2002:a19:da1a:: with SMTP id r26-v6mr4822731lfg.76.1520849172688; Mon, 12 Mar 2018 03:06:12 -0700 (PDT) Received: from acorde (194-237-179-26.customer.telia.com. [194.237.179.26]) by smtp.gmail.com with ESMTPSA id d18sm1634543lja.1.2018.03.12.03.06.11 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 12 Mar 2018 03:06:11 -0700 (PDT) Message-ID: <1520849170.6055.85.camel@it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano Reply-To: cjbc@it.uc3m.es To: "Mr. Jaehoon Paul Jeong" Cc: its@ietf.org, ipwave-chairs@ietf.org, SecCurator_Team , skku_iotlab_seminar@googlegroups.com Date: Mon, 12 Mar 2018 11:06:10 +0100 In-Reply-To: References: <1520768144.6055.9.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] Agenda posted X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 10:06:18 -0000 Done! Carlos On Mon, 2018-03-12 at 14:35 +0900, Mr. Jaehoon Paul Jeong wrote: > Hi Carlos and Russ, > Could you specify my second talk's title named TBD with the > following? > > IPWAVE Standardization Topics: Prefix/Service Discovery, DNS Naming, > and Seamless IP Networking. > - draft-jeong-ipwave-vehicular-neighbor-discovery-02 > (https://tools.ietf.org/html/draft-jeong-ipwave-vehicular-neighbor- > discovery-02) > > - draft-jeong-ipwave-iot-dns-autoconf-02 > (https://tools.ietf.org/html/draft-jeong-ipwave-iot-dns-autoconf-02 > ) > > The two above drafts are my IPWAVE drafts updated recently. > > Thanks. > > Best Regards, > Paul > > > > On Sun, Mar 11, 2018 at 8:35 PM, Carlos Jesús Bernardos Cano .uc3m.es> wrote: > > Hi, > > > > We posted a tentative agenda some days ago, which has been updated > > to > > make room for an additional presentation. > > > > The draft agenda has been posted at: > > > > https://datatracker.ietf.org/meeting/101/materials/agenda-101-ipwav > > e/ > > > > Thanks, > > > > Carlos and Russ > > > > _______________________________________________ > > its mailing list > > its@ietf.org > > https://www.ietf.org/mailman/listinfo/its > > > From nobody Tue Mar 13 06:12: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 DCA8E1273B1 for ; Tue, 13 Mar 2018 06:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IR_r0bAuS_0Z for ; Tue, 13 Mar 2018 06:12:25 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5C3C127337 for ; Tue, 13 Mar 2018 06:12:24 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w2DDCMfd083806 for ; Tue, 13 Mar 2018 14:12:22 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9EB902053B1 for ; Tue, 13 Mar 2018 14:12: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 9283F2053A1 for ; Tue, 13 Mar 2018 14:12: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 w2DDCM0F004218 for ; Tue, 13 Mar 2018 14:12:22 +0100 To: "its@ietf.org" References: <660BFCF2CF184B2C8ACA0743EA9BBB54@SRA6> From: Alexandre Petrescu Message-ID: Date: Tue, 13 Mar 2018 14:12: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=windows-1252; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Fwd: RE: 802.11 Data vs 802.11 QoS Data - 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, 13 Mar 2018 13:12:27 -0000 IPWAVErs, On my side: (1) I counted roughly 8 opinions that would favor addition of this text, and roughly 3 against, and (2) since the report of use of IP-with-QoSData to connect to SCMS I am favoring it too. All I can do is hope that in the future the cheap 802.11-OCB capable cards on linux will be able to do QoSData. Other opinions? > The IPv6 packet transmitted on 802.11-OCB MUST be immediately > preceded by a Logical Link Control (LLC) header and an 802.11 header; > the value of the Subtype sub-field in the Frame Control field of the > 802.11 header MUST be set to 8 (i.e. 'QoS Data'); the value of the > Traffic Identifier (TID) sub-field of the QoS Control field of the > 802.11 header MUST be set to binary 001 (i.e. User Priority > 'Background', QoS Access Category 'AC_BK'). Alex (the submission system for new Internet Drafts is closed until Sunday). Le 09/03/2018 21:05, Alexandre Petrescu a crit: > by this email you will see opposition from Dick Roy. > (FYI the emails from Dick Roy dont show in archives, because of mailer > problems). > > > -------- Message transfr -------- > Sujet: RE: [ipwave] 802.11 Data vs 802.11 QoS Data - towards > resolution > Date: Fri, 9 Mar 2018 08:50:06 -0800 > De: Dick Roy > Rpondre : dickroy@alum.mit.edu > Organisation: SRA > Pour: tony.li@tony.li, 'Alexandre Petrescu' > > Copie : its@ietf.org > > > > ------------------------------------------------------------------------ > > *From:*its [mailto:its-bounces@ietf.org] *On Behalf Of *tony.li@tony.li > *Sent:* Friday, March 9, 2018 8:36 AM > *To:* Alexandre Petrescu > *Cc:* its@ietf.org > *Subject:* Re: [ipwave] 802.11 Data vs 802.11 QoS Data - towards resolution > > Alex, > >>> The IPv6 packet transmitted on 802.11-OCB MUST be immediately preceded >>> by a Logical Link Control (LLC) header and an 802.11 header; the value >>> of the Subtype sub-field in the Frame Control field of the 802.11 >>> header MUST be set to 8 (i.e. 'QoS Data'); the value of the Traffic >>> Identifier (TID) sub-field of the QoS Control field of the 802.11 >>> header MUST be set to binary 001 (i.e. User Priority 'Background', QoS >>> Access Category 'AC_BK'). >>> >> >> Do you agree with the values? >> > Im fine with this, thank you. > > Others? We need rough consensus. > > */[RR] Im not fine with it, unless it is conditioned on transmissions > being in Channel 172 in the US, and even that is problematic since we > currently have NO rules in place that make such requirements! Requiring > ALL Ipv6 packets to be carried in MAC frames of a single type (QoSData > in this case) is simply a bad idea, and should NOT be done, neitherand > exactly the same argument applies to the priority!/* > > *//* > > */You asked again and once more I say dont do it!/* > > *//* > > */RR/* > > Tony > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > From nobody Wed Mar 14 10:29: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 9A1FB120724 for ; Wed, 14 Mar 2018 10:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.03 X-Spam-Level: X-Spam-Status: No, score=-0.03 tagged_above=-999 required=5 tests=[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, 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 R2ggoMm1vjBx for ; Wed, 14 Mar 2018 10:29:43 -0700 (PDT) Received: from fed1rmfepo103.cox.net (fed1rmfepo103.cox.net [68.230.241.145]) by ietfa.amsl.com (Postfix) with ESMTP id D967B120047 for ; Wed, 14 Mar 2018 10:29:42 -0700 (PDT) Received: from fed1rmimpo209.cox.net ([68.230.241.160]) by fed1rmfepo103.cox.net (InterMail vM.8.01.05.28 201-2260-151-171-20160122) with ESMTP id <20180314172941.GKUS4490.fed1rmfepo103.cox.net@fed1rmimpo209.cox.net> for ; Wed, 14 Mar 2018 13:29:41 -0400 Received: from smithPC ([174.68.115.141]) by fed1rmimpo209.cox.net with cox id MtVg1x00L336m1J01tVhfE; Wed, 14 Mar 2018 13:29:41 -0400 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A090203.5AA95C05.0078, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.2 cv=Lpvi8jVc c=1 sm=1 tr=0 a=lZ+2k6HZ6QqstbCzvfe+bA==:117 a=lZ+2k6HZ6QqstbCzvfe+bA==:17 a=x7bEGLp0ZPQA:10 a=kGgg9RDvKM0A:10 a=DAwyPP_o2Byb1YXLmDAA:9 a=DEUEbcShw9_gpdjJEeYA:9 a=ByQ7OQthsU7C6pVa:21 a=5Qzq9hjRjTKV73X0:21 a=CjuIK1q_8ugA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=4mqq1c_3U2b_rj6RrKcA:9 a=TFD-aEq0Dankxk4x:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 X-CM-Score: 0.00 Authentication-Results: cox.net; auth=pass (LOGIN) smtp.auth=kevin.s.smith@cox.net From: "Kevin Smith" To: Date: Wed, 14 Mar 2018 10:29:44 -0700 Message-ID: <007201d3bbba$0b160520$21420f60$@cox.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0073_01D3BB7F.5EB8B3C0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdO7uYos/jNSLVF5SvS1C87Kw/LHLA== Content-Language: en-us Archived-At: Subject: [ipwave] ipwave - comments and concerns X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 17:29:45 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0073_01D3BB7F.5EB8B3C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear IETF ipwave working group, My name is Kevin Smith, I am the technical editor for IEEE Std 1609.3 and a few others in the 1609 family of standards. I have some concerns regarding ipwave's interoperability with 1609 WAVE, and a question regarding the need or purpose for ipwave. 1. If ipwave is intended to be interoperable with 1609 WAVE, then ipwave must specify the use of EtherType Protocol Discrimination (EPD) in the LLC sublayer header, i.e., EPD is mandatory. I note that ipwave mentions EPD, but also SNAP and does not specify which method to use. Moreover ipwave discusses an abstract "Ethernet Adaptation Layer" but does not specify a header format, and this further confuses the question for deployers - what should we implement? 2. It is not clear that ipwave provides any functionality that 1609 WAVE does not already provide. 1609 WAVE includes a number of mechanisms that enable IPv6 networks to be configured. In addition to the WSA/WRA mechanism, 1609.3 allows any IETF protocols to be implemented, e.g., IETF RFC 4861, Neighbor Discovery for IP Version 6 (IPv6) (which is listed as a normative reference in 1609.3). Helpful would be some example use-cases that illustrate problems to be solved, and how ipwave will solve those problems (i.e., that 1609 WAVE does not already solve). My concern is that the IETF ipwave document may cause significant confusion among deployers, and possibly lead to a lack of interoperability. Thank you for the opportunity to comment, I look forward to the discussion. Best regards, Kevin ------=_NextPart_000_0073_01D3BB7F.5EB8B3C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear IETF ipwave working = group,

 

My name is Kevin Smith, = I am the technical editor for IEEE Std 1609.3 and a few others in the = 1609 family of standards. I have some concerns regarding ipwave’s = interoperability with 1609 WAVE, and a question regarding the need or = purpose for ipwave.

 

1.       = If ipwave is intended to be interoperable with 1609 WAVE, then ipwave = must specify the use of EtherType Protocol Discrimination (EPD) in the = LLC sublayer header, i.e., EPD is mandatory. I note that ipwave mentions = EPD, but also SNAP and does not specify which method to use. Moreover = ipwave discusses an abstract “Ethernet Adaptation Layer” but = does not specify a header format, and this further confuses the question = for deployers – what should we implement? =   

 

2.       = It is not clear that ipwave provides any functionality that 1609 WAVE = does not already provide. 1609 WAVE includes a number of mechanisms that = enable IPv6 networks to be configured. In addition to the WSA/WRA = mechanism, 1609.3 allows any IETF protocols to be implemented, e.g., = IETF RFC 4861, Neighbor Discovery for IP Version 6 (IPv6) (which is = listed as a normative reference in 1609.3). Helpful would be some = example use-cases that illustrate problems to be solved, and how ipwave = will solve those problems (i.e., that 1609 WAVE does not already solve). =

 

My concern is that the IETF ipwave document may = cause significant confusion among deployers, and possibly lead to a lack = of interoperability. Thank you for the opportunity to comment, I look = forward to the discussion.

 

Best = regards,

Kevin

 

 

------=_NextPart_000_0073_01D3BB7F.5EB8B3C0-- From nobody Wed Mar 14 11:19: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 881971200E5 for ; Wed, 14 Mar 2018 11:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[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 LGH8VRZjmIOX for ; Wed, 14 Mar 2018 11:19:18 -0700 (PDT) Received: from mail.cec.uchile.cl (mail1.cec.uchile.cl [200.9.100.12]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96C851200B9 for ; Wed, 14 Mar 2018 11:19:18 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.cec.uchile.cl (Postfix) with ESMTP id 5A9B8347432 for ; Wed, 14 Mar 2018 15:19:16 -0300 (-03) X-Virus-Scanned: by amavisd-new at ing.uchile.cl Received: from mail.cec.uchile.cl ([127.0.0.1]) by localhost (mail1.cec.uchile.cl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQKtI7H1qNrS for ; Wed, 14 Mar 2018 15:19:16 -0300 (-03) Received: from [172.17.29.7] (unknown [172.17.29.7]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.cec.uchile.cl (Postfix) with ESMTP id 2AC493473F2 for ; Wed, 14 Mar 2018 15:19:16 -0300 (-03) To: its@ietf.org References: <152027400826.14551.2766762404227800440@ietfa.amsl.com> <1B326624F8EE4A19B7C94AED23C7CE5C@SRA6> From: =?UTF-8?Q?Sandra_C=c3=a9spedes_U.?= Message-ID: Date: Wed, 14 Mar 2018 15:19:16 -0300 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-Transfer-Encoding: 8bit Content-Language: en-US X-Antivirus: Avast (VPS 180314-2, 14-03-2018), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicular-networking-02.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 Mar 2018 18:19:21 -0000 Hi Alex On 08-03-2018 14:09, Alexandre Petrescu wrote: > > > Le 08/03/2018 à 16:00, Mr. Jaehoon Paul Jeong a écrit : > [...] > >> The WSA optionally can transmit a local IPv6 prefix, which can be >> used for SLAAC as I understand it. > > Well I dont think any computer uses WSA, instead of an RA, to > configure an address with the SLAAC protocol.  It would be straight > layer violation if the IP stack interpreted a non-IP message (the WSA). As strange as it sounds, that is what the IEEE 1609.3 standard mandates. In section 6.4 - IPv6 configuration, subsection 6.4.1 it says: "For WAVE devices supporting dynamic IP addressing, the WME shall calculate the global IPv6 address via a stateless configuration procedure. This is the procedure described in IETF RFC 4862, except the WAVE device uses its MAC address in conjunction with the IP Prefix received in the WaveRoutingAdvertisement, rather than that received in an IETF RFC 4861 Router Advertisement message. WAVE provides this IP configuration information in the WSA to reduce the need for neighbor and router discovery with their associated overhead and latency." In that sense, we (at IETF) are trying to be careful not to mandate things related to "below IP" layers, but in this standard of IEEE they have specified a behavior for IP devices that do not follow RFC 4862 for IP addressing configuration.  The question then is, if in this group we specify something different (perhaps WAVE devices following what standard RFCs already mandate for IPv6 support) how do we avoid the conflict between the two standards? > > Or maybe we should not call it 'SLAAC' but something else. The 1609.3 does say it is SLAAC as defined by RFC 4862 but with "exceptions" in the type of messages employed for prefix advertisement. > > Alex > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its Regards, -- Sandra L. Céspedes, Ph.D. | Profesora Asistente Departamento de Ingeniería Eléctrica Universidad de Chile Av. Tupper 2007, Santiago, Chile. 8370451 Tel. +56 (2) 29784093 | Of. 504 URL:http://www.cec.uchile.cl/~scespedes --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From nobody Wed Mar 14 11:24: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 509221200E5 for ; Wed, 14 Mar 2018 11:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_REMOTE_IMAGE=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 4DSPGl2D0vNP for ; Wed, 14 Mar 2018 11:24:42 -0700 (PDT) Received: from mail.cec.uchile.cl (mail1.cec.uchile.cl [200.9.100.12]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 417CD1267BB for ; Wed, 14 Mar 2018 11:24:39 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.cec.uchile.cl (Postfix) with ESMTP id DF7303473B7; Wed, 14 Mar 2018 15:24:37 -0300 (-03) X-Virus-Scanned: by amavisd-new at ing.uchile.cl Received: from mail.cec.uchile.cl ([127.0.0.1]) by localhost (mail1.cec.uchile.cl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O21wZzRxiYuX; Wed, 14 Mar 2018 15:24:37 -0300 (-03) Received: from [172.17.29.7] (unknown [172.17.29.7]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.cec.uchile.cl (Postfix) with ESMTP id 791D9347347; Wed, 14 Mar 2018 15:24:37 -0300 (-03) To: "Mr. Jaehoon Paul Jeong" , Alexandre Petrescu Cc: its@ietf.org References: <152027400826.14551.2766762404227800440@ietfa.amsl.com> <1B326624F8EE4A19B7C94AED23C7CE5C@SRA6> From: =?UTF-8?Q?Sandra_C=c3=a9spedes_U.?= Message-ID: <74fd38a7-1a29-f715-58cd-0a51fd6f58e4@ing.uchile.cl> Date: Wed, 14 Mar 2018 15:24:37 -0300 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="------------4437E4C3A064496492560E4A" Content-Language: en-US X-Antivirus: Avast (VPS 180314-2, 14-03-2018), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicular-networking-02.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 Mar 2018 18:24:45 -0000 This is a multi-part message in MIME format. --------------4437E4C3A064496492560E4A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Paul On 09-03-2018 11:42, Mr. Jaehoon Paul Jeong wrote: > Hi Alex, > Thanks for your point. > For the IPv6 address autoconfiguration based on WSA, we may call it > WSA-based Stateless Address Autoconfiguration (WSLAAC). I guess we can give it that name to differentiate it from the standard procedure using RAs as per RFC 4862. How is this going to co-exists in a WAVE device that has to process both WSA with IP prefix advertisement and RAs remains an open question. Regards, Sandra. > Sandra (as the 1st author of the VIP-WAVE paper for the above text) > and others, > Is there any other better name? > https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-02#section-4.1.1 > > Best Regards, > Paul > > On Fri, Mar 9, 2018 at 2:09 AM, Alexandre Petrescu > > > wrote: > > > > Le 08/03/2018 à 16:00, Mr. Jaehoon Paul Jeong a écrit : > [...] > > The WSA optionally can transmit a local IPv6 prefix, which can be > used for SLAAC as I understand it. > > > Well I dont think any computer uses WSA, instead of an RA, to > configure an address with the SLAAC protocol.  It would be > straight layer violation if the IP stack interpreted a non-IP > message (the WSA). > > Or maybe we should not call it 'SLAAC' but something else. > > Alex > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > > > > > -- > =========================== > Mr. Jaehoon (Paul) Jeong, Ph.D. > Assistant Professor > Department of Software > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.paul@gmail.com , > pauljeong@skku.edu > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php > -- Sandra L. Céspedes, Ph.D. | Profesora Asistente Departamento de Ingeniería Eléctrica Universidad de Chile Av. Tupper 2007, Santiago, Chile. 8370451 Tel. +56 (2) 29784093 | Of. 504 URL:http://www.cec.uchile.cl/~scespedes --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus --------------4437E4C3A064496492560E4A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Paul


On 09-03-2018 11:42, Mr. Jaehoon Paul Jeong wrote:
Hi Alex,
Thanks for your point.
For the IPv6 address autoconfiguration based on WSA, we may call it WSA-based Stateless Address Autoconfiguration (WSLAAC).
I guess we can give it that name to differentiate it from the standard procedure using RAs as per RFC 4862. How is this going to co-exists in a WAVE device that has to process both WSA with IP prefix advertisement and RAs remains an open question.

Regards,
Sandra.

Sandra (as the 1st author of the VIP-WAVE paper for the above text) and others,
Is there any other better name?

Best Regards,
Paul

On Fri, Mar 9, 2018 at 2:09 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:


Le 08/03/2018 à 16:00, Mr. Jaehoon Paul Jeong a écrit :
[...]

The WSA optionally can transmit a local IPv6 prefix, which can be
used for SLAAC as I understand it.

 Well I dont think any computer uses WSA, instead of an RA, to configure an address with the SLAAC protocol.  It would be straight layer violation if the IP stack interpreted a non-IP message (the WSA).

Or maybe we should not call it 'SLAAC' but something else.

Alex


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



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

-- 
Sandra L. Céspedes, Ph.D. | Profesora Asistente
Departamento de Ingeniería Eléctrica
Universidad de Chile
Av. Tupper 2007, Santiago, Chile. 8370451
Tel. +56 (2) 29784093 | Of. 504
URL: http://www.cec.uchile.cl/~scespedes

Virus-free. www.avast.com
--------------4437E4C3A064496492560E4A-- From nobody Wed Mar 14 11: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 38BB8126C22 for ; Wed, 14 Mar 2018 11:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[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 dpqSd0rJG4M3 for ; Wed, 14 Mar 2018 11:30:24 -0700 (PDT) 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 8027D1200B9 for ; Wed, 14 Mar 2018 11:30:24 -0700 (PDT) Received: from resomta-po-12v.sys.comcast.net ([96.114.154.236]) by resqmta-po-11v.sys.comcast.net with ESMTP id wB9geS6NrAbJbwBAOeZ62Q; Wed, 14 Mar 2018 18:30:24 +0000 Received: from [172.22.228.216] ([162.210.130.3]) by resomta-po-12v.sys.comcast.net with SMTP id wB8HeSKDgB4k6wB8Jeof8u; Wed, 14 Mar 2018 18:28:22 +0000 From: Tony Li Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_2FCCDAC2-FE7A-43CC-830D-C522FF2ABE89" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 14 Mar 2018 11:28:11 -0700 In-Reply-To: Cc: its@ietf.org To: =?utf-8?B?IlNhbmRyYSBDw6lzcGVkZXMgVS4i?= References: <152027400826.14551.2766762404227800440@ietfa.amsl.com> <1B326624F8EE4A19B7C94AED23C7CE5C@SRA6> X-Mailer: Apple Mail (2.3445.5.20) X-CMAE-Envelope: MS4wfCt+dAtsFAav8pRUmxE/MTI8NO35pdtmdyfe17+Syt8yAUXUDdyQr/1IQe46rqdNuewKi1wGCxMKmHxUjflVqfiUshGhv8Qhluf6ZWfwXOm17Qz6X8VQ HmRT8v4XiHQGhG8Uvt86o0QDwcpezLtxSkAyEbKFfGiF35Zs2LNagnsDcyE7T9cRZmioRhz950NDUg== Archived-At: Subject: Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicular-networking-02.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 Mar 2018 18:30:26 -0000 --Apple-Mail=_2FCCDAC2-FE7A-43CC-830D-C522FF2ABE89 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 14, 2018, at 11:19 AM, Sandra C=C3=A9spedes U. = wrote: >=20 >=20 > As strange as it sounds, that is what the IEEE 1609.3 standard = mandates. In section 6.4 - IPv6 configuration, subsection 6.4.1 it says: = "For WAVE devices supporting dynamic IP addressing, the WME shall = calculate the global IPv6 address via a stateless configuration = procedure. This is the procedure described in IETF RFC 4862, except the = WAVE device uses its MAC address in conjunction with the IP Prefix = received in the WaveRoutingAdvertisement, rather than that received in = an IETF RFC 4861 Router Advertisement message. WAVE provides this IP = configuration information in the WSA to reduce the need for neighbor and = router discovery with their associated overhead and latency." >=20 > In that sense, we (at IETF) are trying to be careful not to mandate = things related to "below IP" layers, but in this standard of IEEE they = have specified a behavior for IP devices that do not follow RFC 4862 for = IP addressing configuration. The question then is, if in this group we = specify something different (perhaps WAVE devices following what = standard RFCs already mandate for IPv6 support) how do we avoid the = conflict between the two standards? Previously the way we avoided these conflicts was quite simple: the IEEE = spec=E2=80=99ed the link layer, the IETF spec=E2=80=99ed the network = layer. And there was no crossover. This represents a violation of that modus operandi, which is seriously = troubling. I think we (ipwave) should reconsider and either explicitly endorse what = 1609.3 is doing or reverse it. Tony --Apple-Mail=_2FCCDAC2-FE7A-43CC-830D-C522FF2ABE89 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Mar 14, 2018, at 11:19 AM, Sandra C=C3=A9spedes U. <scespedes@ing.uchile.cl> wrote:


As strange as it sounds, that is what the IEEE = 1609.3 standard mandates. In section 6.4 - IPv6 configuration, = subsection 6.4.1 it says: "For WAVE devices supporting dynamic IP = addressing, the WME shall calculate the global IPv6 address via a = stateless configuration procedure. This is the procedure described in = IETF RFC 4862, except the WAVE device uses its MAC address in = conjunction with the IP Prefix received in the WaveRoutingAdvertisement, = rather than that received in an IETF RFC 4861 Router Advertisement = message. WAVE provides this IP configuration information in the WSA to = reduce the need for neighbor and router discovery with their associated = overhead and latency."

In that sense, we (at IETF) are trying to be = careful not to mandate things related to "below IP" layers, but in this = standard of IEEE they have specified a behavior for IP devices that do = not follow RFC 4862 for IP addressing configuration.  The question = then is, if in this group we specify something different (perhaps WAVE = devices following what standard RFCs already mandate for IPv6 support) = how do we avoid the conflict between the two standards?


Previously the way we avoided these = conflicts was quite simple: the IEEE spec=E2=80=99ed the link layer, the = IETF spec=E2=80=99ed the network layer. And there was no = crossover.

This = represents a violation of that modus operandi, which is seriously = troubling.

I = think we (ipwave) should reconsider and either explicitly endorse what = 1609.3 is doing or reverse it.

Tony

= --Apple-Mail=_2FCCDAC2-FE7A-43CC-830D-C522FF2ABE89-- From nobody Wed Mar 14 11:46: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 454A2127241 for ; Wed, 14 Mar 2018 11:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kapsch.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eG8I6YwdqDiz for ; Wed, 14 Mar 2018 11:45:56 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0095.outbound.protection.outlook.com [104.47.2.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD27F126FB3 for ; Wed, 14 Mar 2018 11:45:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kapsch.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KmIw/SVazJ1yKacEQ7bpwI5J8yX0v6cNO9r/g/u314I=; b=ETXeBYzxc4l54yP3gDu89yje1WrgIIlw5VcdhxUXGgAedjJ3ytVI/QCx8zozGEnNnPPckfb7TUnSRJu2UBDjv6v3bM2YpO7B5OSBvkXmQqDISMD6OIET2qPNJyxHD6hgyLQJKwjx7W0y7CdCq2t11xVu+Zx2JWsseqbrpTi3PME= Received: from AM0PR0302MB3380.eurprd03.prod.outlook.com (52.133.37.155) by AM0PR0302MB3441.eurprd03.prod.outlook.com (52.133.38.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.567.12; Wed, 14 Mar 2018 18:45:53 +0000 Received: from AM0PR0302MB3380.eurprd03.prod.outlook.com ([fe80::153a:2232:e7b7:7cb4]) by AM0PR0302MB3380.eurprd03.prod.outlook.com ([fe80::153a:2232:e7b7:7cb4%13]) with mapi id 15.20.0567.018; Wed, 14 Mar 2018 18:45:53 +0000 From: Tijink Jasja To: "its@ietf.org" Thread-Topic: [ipwave] ipwave - comments and concerns Thread-Index: AdO7uYos/jNSLVF5SvS1C87Kw/LHLAACm5PA Date: Wed, 14 Mar 2018 18:45:53 +0000 Message-ID: References: <007201d3bbba$0b160520$21420f60$@cox.net> In-Reply-To: <007201d3bbba$0b160520$21420f60$@cox.net> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jasja.Tijink@kapsch.net; x-originating-ip: [212.197.157.62] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM0PR0302MB3441; 7:t/WM3pS1PQWox4sPd/5QktVXy8vqLAy8nBw5+K+DpWZWtF4RR9lsItUlzAGD+sE9Q3f79WoRjCQV/Ps535w81d0gDyM5w8pcqcKB91f5xBr3hTBbcG2A8u2MzzUwL6m4UDJhU8bKGt4sGVcOSVAEa85XKsZSe1LhPX7NuB69eeK+t6dWuB5rASasW2GP5sW9syhgqdU85RGtUq0LI5fpwAnXzXG3W+xrxJy8MxLQp02d0ylhw9f+FNEg1qN+jADV x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: a9bc4eba-1a98-4ec3-1169-08d589dbd0a0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:AM0PR0302MB3441; x-ms-traffictypediagnostic: AM0PR0302MB3441: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231221)(944501244)(52105095)(6041310)(20161123562045)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(6072148)(201708071742011); SRVR:AM0PR0302MB3441; BCL:0; PCL:0; RULEID:; SRVR:AM0PR0302MB3441; x-forefront-prvs: 0611A21987 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400004)(346002)(396003)(376002)(366004)(39380400002)(51414003)(189003)(199004)(6436002)(5660300001)(3660700001)(2950100002)(316002)(5630700001)(186003)(55016002)(74316002)(66066001)(33656002)(68736007)(6306002)(345774005)(14454004)(2351001)(102836004)(9686003)(54896002)(5640700003)(53936002)(6916009)(478600001)(72206003)(59450400001)(3280700002)(2900100001)(5250100002)(26005)(105586002)(25786009)(6506007)(2501003)(7736002)(106356001)(97736004)(86362001)(1730700003)(6116002)(7696005)(76176011)(555904003)(3846002)(2906002)(8676002)(790700001)(81166006)(99286004)(81156014)(8936002)(36394004)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR0302MB3441; H:AM0PR0302MB3380.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: kapsch.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: k9O42jCDtVPtvmSmtrAsSYJFzFgK8S+CqLbx07sXUn39XJq7BaSIMwLGTQCk3EtQiRY7ArdIi5KAFUJOHcuTC6gpjQe9vp33rwBvoaOitwOQFxoN6MXC07j3qoy4KowU+7aBjT8lJw7nqry85D2mY+nDrAXLzeg2U/weg2CoB8S0Z1x5GD8I3My1ZA7tBHFgI1pYfdgixyrdFL8bq4ybE/dV25uiY5U4GChLMp5WXw7uAbM8i1SieixXonx1dzDizsfarSNEyB5pPAN4PMozmDWtU57p5WJspFm2FmaLuBDSZDfEn7e6DuLKCy22ghiZlGcCGvMUET/LIe0QTuC5Wg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM0PR0302MB3380A79A463AEB013AB25D85EFD10AM0PR0302MB3380_" MIME-Version: 1.0 X-OriginatorOrg: kapsch.net X-MS-Exchange-CrossTenant-Network-Message-Id: a9bc4eba-1a98-4ec3-1169-08d589dbd0a0 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Mar 2018 18:45:53.3318 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5f9ce527-7e3e-4e83-a8a4-b6c848f85ab5 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR0302MB3441 Archived-At: Subject: Re: [ipwave] ipwave - comments and concerns X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 18:46:00 -0000 --_000_AM0PR0302MB3380A79A463AEB013AB25D85EFD10AM0PR0302MB3380_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello List, my name is Jasja Tijink and i am a member of the IEEE 1609 working group. I share Kevin's view as per the e-mail below. I believe these aspects need = to be clarified in the draft-ietf- ipwave-ipv6-over-80211ocb-21 before it c= an be considered ready. Best regards, Jasja Von: its [mailto:its-bounces@ietf.org] Im Auftrag von Kevin Smith Gesendet: Mittwoch, 14. M=E4rz 2018 18:30 An: its@ietf.org Betreff: [ipwave] ipwave - comments and concerns Dear IETF ipwave working group, My name is Kevin Smith, I am the technical editor for IEEE Std 1609.3 and a= few others in the 1609 family of standards. I have some concerns regarding= ipwave's interoperability with 1609 WAVE, and a question regarding the nee= d or purpose for ipwave. 1. If ipwave is intended to be interoperable with 1609 WAVE, then ipwave= must specify the use of EtherType Protocol Discrimination (EPD) in the LLC= sublayer header, i.e., EPD is mandatory. I note that ipwave mentions EPD, = but also SNAP and does not specify which method to use. Moreover ipwave dis= cusses an abstract "Ethernet Adaptation Layer" but does not specify a heade= r format, and this further confuses the question for deployers - what shoul= d we implement? 1. It is not clear that ipwave provides any functionality that 1609 WAVE= does not already provide. 1609 WAVE includes a number of mechanisms that e= nable IPv6 networks to be configured. In addition to the WSA/WRA mechanism,= 1609.3 allows any IETF protocols to be implemented, e.g., IETF RFC 4861, N= eighbor Discovery for IP Version 6 (IPv6) (which is listed as a normative r= eference in 1609.3). Helpful would be some example use-cases that illustrat= e problems to be solved, and how ipwave will solve those problems (i.e., th= at 1609 WAVE does not already solve). My concern is that the IETF ipwave document may cause significant confusion= among deployers, and possibly lead to a lack of interoperability. Thank yo= u for the opportunity to comment, I look forward to the discussion. Best regards, Kevin --_000_AM0PR0302MB3380A79A463AEB013AB25D85EFD10AM0PR0302MB3380_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello Lis= t,

&nbs= p;

my name is Jasja Tijink and i am a member of the IEEE 1609 working gr= oup.

I share Kevin’s view as per the e-mail below. I believe these a= spects need to be clarified in the draft-ietf- ipwave-ipv6-over-80211ocb-21 before= it can be considered ready.

 

Best regards,

 

Jasja

 

 

Von: its [mailto:its-bounces@ietf.org] Im Auftrag von Kevin Smith
Gesendet: Mittwoch, 14. M=E4rz 2018 18:30
An: its@ietf.org
Betreff: [ipwave] ipwave - comments and concerns

 

Dear IE= TF ipwave working group,

&n= bsp;

My name= is Kevin Smith, I am the technical editor for IEEE Std 1609.3 and a few ot= hers in the 1609 family of standards. I have some concerns regarding ipwave= ’s interoperability with 1609 WAVE, and a question regarding the need or purpose for ipwave.

&n= bsp;

  1. If ipwave is intended to be interoperable with 1609 WAVE, t= hen ipwave must specify the use of EtherType Protocol Discrimination (EPD) = in the LLC sublayer header, i.e., EPD is mandatory. I note that ipwave mentions EPD, but also SNAP and does not specify which = method to use. Moreover ipwave discusses an abstract “Ethernet Adapta= tion Layer” but does not specify a header format, and this further co= nfuses the question for deployers – what should we implement?   

&n= bsp;

  1. It is not clear that ipwave provides any functionality that= 1609 WAVE does not already provide. 1609 WAVE includes a number of mechani= sms that enable IPv6 networks to be configured. In addition to the WSA/WRA mechanism, 1609.3 allows any IETF protocols to = be implemented, e.g., IETF RFC 4861, Neighbor Discovery for IP Version 6 (I= Pv6) (which is listed as a normative reference in 1609.3). Helpful would be= some example use-cases that illustrate problems to be solved, and how ipwave will solve those problems (i.e., tha= t 1609 WAVE does not already solve).

 

My conc= ern is that the IETF ipwave document may cause significant confusion among = deployers, and possibly lead to a lack of interoperability. Thank you for t= he opportunity to comment, I look forward to the discussion.

&n= bsp;

Best re= gards,

Kevin

 

 

--_000_AM0PR0302MB3380A79A463AEB013AB25D85EFD10AM0PR0302MB3380_-- From nobody Wed Mar 14 12:00: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 3D3E1127599 for ; Wed, 14 Mar 2018 12:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[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 m4zY2KX-C4ih for ; Wed, 14 Mar 2018 12:00:20 -0700 (PDT) Received: from mail-pl0-x242.google.com (mail-pl0-x242.google.com [IPv6:2607:f8b0:400e:c01::242]) (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 CB927126DEE for ; Wed, 14 Mar 2018 12:00:04 -0700 (PDT) Received: by mail-pl0-x242.google.com with SMTP id m22-v6so2225328pls.5 for ; Wed, 14 Mar 2018 12:00:04 -0700 (PDT) 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=VAaC5a3pTMULmdhf9Bq3DH8Q2H/mdvhssC8GBZgXa1Y=; b=ijJdO5qTGG5lWB6zoGkitnW74PkvGt2ywD+fvQHS0u0VnH3duWti0XJhkGza420uqY jxOUwzgOnhmL+UXECL39c6XU1IzIyXu96OnnEts2dIEoJo8N6L+KZ4VpT57D44Et/D2y LioVQXfbNkFnbFN8AZDMNmoECg40lOwnPXVsn6NpwwhkfYQPBzzC576I4wAm35evTI3l YssG4KIBD2/Xq+gGZZ9yY9IgRk5GZGWlZLYrfkAabl+hUp6zSXRTWVEDCpXzFjqJ4EgD OvGkI5Atn9nIF1WSk6Yi2vYCkqm0XLU42ACWqcByMCfpaGPzLyleFPUFSx4yNP38gDO4 Nneg== 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=VAaC5a3pTMULmdhf9Bq3DH8Q2H/mdvhssC8GBZgXa1Y=; b=qbgovfB1Jmp3fwrHzHWueQ35mFXz98zWi9EQ8fW9qCZpvhKO68RddMspVHOJvLM647 j7uqeJKZ06fvyVClRbKKaHeL33NmuMvghbuzFdpoxkO532ygNz494aWXChgekifSX0wq URfCUCyP+ZfAYrArRrOCYtMYtrHfX8E/Wd1GRzM9qTXYyRmtcnhm695UnzlOCJT6zn4z +jTuFV2VchdEy/ZPi/kjH538rHVSXCunlHJNfPkwFZggNsAXIpIoMai9lE94nFXX4xC8 fg7lj5wM+oYuQu/wjTk37d/wVhSA1BFuTM3R88oRutp54CjJ4KaZ+juHqrcRxub5EBux Xmmg== X-Gm-Message-State: AElRT7Fd6DemAbd+SCewVv9seEnxcl5FYhQCESG1YzkxRumSxPCzfIeW WZhjoY9XAo5fMX/dobxIYgc= X-Google-Smtp-Source: AG47ELsSNagyEKUB/758PuMqRYPP28+3BA70YLF2DbeV5bUkBaZet1p23rZBy1ojafJ7Li8APHPD/Q== X-Received: by 2002:a17:902:7088:: with SMTP id z8-v6mr5077044plk.174.1521054004402; Wed, 14 Mar 2018 12:00:04 -0700 (PDT) Received: from localhost.localdomain (c-71-198-163-21.hsd1.ca.comcast.net. [71.198.163.21]) by smtp.gmail.com with ESMTPSA id j11sm6713686pff.94.2018.03.14.12.00.03 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 14 Mar 2018 12:00:03 -0700 (PDT) Message-ID: <1521054002.2261.4.camel@gmail.com> From: Rex Buddenberg To: Tony Li , "\"Sandra" =?ISO-8859-1?Q?C=E9spedes?= "U.\"" Cc: its@ietf.org Date: Wed, 14 Mar 2018 12:00:02 -0700 In-Reply-To: References: <152027400826.14551.2766762404227800440@ietfa.amsl.com> <1B326624F8EE4A19B7C94AED23C7CE5C@SRA6> 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] I-D Action: draft-ietf-ipwave-vehicular-networking-02.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 Mar 2018 19:00:23 -0000 in line On Wed, 2018-03-14 at 11:28 -0700, Tony Li wrote: > > > > On Mar 14, 2018, at 11:19 AM, Sandra Céspedes U. > ile.cl> wrote: > > > > > > As strange as it sounds, that is what the IEEE 1609.3 standard > > mandates. In section 6.4 - IPv6 configuration, subsection 6.4.1 it > > says: "For WAVE devices supporting dynamic IP addressing, the WME > > shall calculate the global IPv6 address via a stateless > > configuration procedure. This is the procedure described in IETF > > RFC 4862, except the WAVE device uses its MAC address in > > conjunction with the IP Prefix received in the > > WaveRoutingAdvertisement, rather than that received in an IETF RFC > > 4861 Router Advertisement message. WAVE provides this IP > > configuration information in the WSA to reduce the need for > > neighbor and router discovery with their associated overhead and > > latency." > > > > In that sense, we (at IETF) are trying to be careful not to mandate > > things related to "below IP" layers, but in this standard of IEEE > > they have specified a behavior for IP devices that do not follow > > RFC 4862 for IP addressing configuration.  The question then is, if > > in this group we specify something different (perhaps WAVE devices > > following what standard RFCs already mandate for IPv6 support) how > > do we avoid the conflict between the two standards? > > Previously the way we avoided these conflicts was quite simple: the > IEEE spec’ed the link layer, the IETF spec’ed the network layer. And > there was no crossover. > Tony, almost.  Since the early 1990s, this handshake division of labor did (and does) exist, but it was between IETF and IEEE 802.  Not IEEE in general.   > This represents a violation of that modus operandi, which is > seriously troubling. Yep. > > I think we (ipwave) should reconsider and either explicitly endorse > what 1609.3 is doing or reverse it. > > Tony > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Wed Mar 14 12:54:27 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 0AF94126B7E for ; Wed, 14 Mar 2018 12:54:25 -0700 (PDT) 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 5VCRa_LyAJCs for ; Wed, 14 Mar 2018 12:54:22 -0700 (PDT) Received: from smtp2.eurecom.fr (smtp2.eurecom.fr [193.55.113.211]) by ietfa.amsl.com (Postfix) with ESMTP id DC449126DED for ; Wed, 14 Mar 2018 12:54:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.48,306,1517871600"; d="scan'208";a="7781175" Received: from waha.eurecom.fr (HELO smtps.eurecom.fr) ([10.3.2.236]) by drago2i.eurecom.fr with ESMTP; 14 Mar 2018 20:54:11 +0100 Received: from [10.133.88.165] (unknown [80.12.43.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtps.eurecom.fr (Postfix) with ESMTPSA id 73451A1; Wed, 14 Mar 2018 20:54:11 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Jerome Haerri X-Mailer: iPhone Mail (15D100) In-Reply-To: <1521054002.2261.4.camel@gmail.com> Date: Wed, 14 Mar 2018 20:54:09 +0100 Cc: Tony Li , =?utf-8?Q?"Sandra_C=C3=A9spedes_U."?= , its@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <4C4CAF8F-60A3-44CF-8913-25C73F695433@eurecom.fr> References: <152027400826.14551.2766762404227800440@ietfa.amsl.com> <1B326624F8EE4A19B7C94AED23C7CE5C@SRA6> <1521054002.2261.4.camel@gmail.com> To: Rex Buddenberg Archived-At: Subject: Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicular-networking-02.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 Mar 2018 19:54:25 -0000 Dear All, I do not think it is a violation of operandi. What happens is there is one n= on-IP L3 stack which assists another IP L3 stack to get configured..it is j= ust that this time, an IP configuration has been done outside the context of= the IETF. Although it should have been linked to IETF (maybe), there were g= ood reasons to do this in that way (similar issues with IP configuration on C= -V2X in ad-hoc mode are also appearing)... Another remark: although the name of the group is called IPWAVE, it is not W= AVE and there are other stacks that WAVE. So mentioning to endorse or not en= dorse WAVE does not solve our coexistence issues..in EU, we have Geonet. In this group there was one question that was asked and answered more than a= year ago: would IPWAVE use WAVE or Geonet for IPv6 over OCB. The answer was= =E2=80=98no=E2=80=99.=20 But it was soecified that it must not violate =E2=80=98any=E2=80=99 existing= WAVE or Geonet functions and must not create =E2=80=98any=E2=80=99 harmful i= nterference with their transmissions on the 5.9Ghz. So, would the answer be =E2=80=98yes=E2=80=99 there would be no business to b= e done in IPWAVE or at least not in the current IDs being discussed, as ther= e are no functional issues in using IPv6 with WAVE or GEONET..maybe some per= formance reduction.=20 We need stakeholders and OEMs in the loop to provide system descriptions the= y have/produce/sell that could not use either Geonet or WAVE (and why), or b= e inefficient with them. We need that :-) See you next week, BR, J=C3=A9r=C3=B4me Maybe we should re-ask this question next week,=20 Envoy=C3=A9 de mon iPhone lve > Le 14 mars 2018 =C3=A0 20:00, Rex Buddenberg a =C3= =A9crit : >=20 > in line >=20 >> On Wed, 2018-03-14 at 11:28 -0700, Tony Li wrote: >>=20 >>=20 >>> On Mar 14, 2018, at 11:19 AM, Sandra C=C3=A9spedes U. >> ile.cl> wrote: >>>=20 >>>=20 >>> As strange as it sounds, that is what the IEEE 1609.3 standard >>> mandates. In section 6.4 - IPv6 configuration, subsection 6.4.1 it >>> says: "For WAVE devices supporting dynamic IP addressing, the WME >>> shall calculate the global IPv6 address via a stateless >>> configuration procedure. This is the procedure described in IETF >>> RFC 4862, except the WAVE device uses its MAC address in >>> conjunction with the IP Prefix received in the >>> WaveRoutingAdvertisement, rather than that received in an IETF RFC >>> 4861 Router Advertisement message. WAVE provides this IP >>> configuration information in the WSA to reduce the need for >>> neighbor and router discovery with their associated overhead and >>> latency." >>>=20 >>> In that sense, we (at IETF) are trying to be careful not to mandate >>> things related to "below IP" layers, but in this standard of IEEE >>> they have specified a behavior for IP devices that do not follow >>> RFC 4862 for IP addressing configuration. The question then is, if >>> in this group we specify something different (perhaps WAVE devices >>> following what standard RFCs already mandate for IPv6 support) how >>> do we avoid the conflict between the two standards? >>=20 >> Previously the way we avoided these conflicts was quite simple: the >> IEEE spec=E2=80=99ed the link layer, the IETF spec=E2=80=99ed the network= layer. And >> there was no crossover. >>=20 > Tony, almost. Since the early 1990s, this handshake division of labor > did (and does) exist, but it was between IETF and IEEE 802. Not IEEE > in general. =20 >=20 >> This represents a violation of that modus operandi, which is >> seriously troubling. >=20 > Yep. >=20 >>=20 >> I think we (ipwave) should reconsider and either explicitly endorse >> what 1609.3 is doing or reverse it. >>=20 >> Tony >>=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 From nobody Thu Mar 15 11:22: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 995CF12D80E for ; Thu, 15 Mar 2018 11:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-nRgrT78i8Q for ; Thu, 15 Mar 2018 11:22:43 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E60D41252BA for ; Thu, 15 Mar 2018 11:22:42 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w2FIMb6h087567; Thu, 15 Mar 2018 19:22:37 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7F23D205D02; Thu, 15 Mar 2018 19:22: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 6E8CC205CAA; Thu, 15 Mar 2018 19:22: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 w2FIMbOf007942; Thu, 15 Mar 2018 19:22:37 +0100 To: Kevin Smith Cc: "its@ietf.org" , Tijink Jasja From: Alexandre Petrescu Message-ID: Date: Thu, 15 Mar 2018 19:22: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 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [ipwave] ipwave - comments and concerns - 1609 WAVE, EPD - 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: Thu, 15 Mar 2018 18:22:46 -0000 Hi Kevin, Kevin wrote recently: > Dear IETF ipwave working group, > > > > My name is Kevin Smith, I am the technical editor for IEEE Std 1609.3 > and a few others in the 1609 family of standards. I have some > concerns regarding ipwave's interoperability with 1609 WAVE, and a > question regarding the need or purpose for ipwave. Generally speaking, the purpose of ipwave WG is set in the Charter. (https://datatracker.ietf.org/wg/ipwave/about/) > 1. If ipwave is intended to be interoperable with 1609 WAVE, > then ipwave must specify the use of EtherType Protocol Discrimination > (EPD) in the LLC sublayer header, i.e., EPD is mandatory. We should interoperate to a maximum. I suggest that in section 4.2.1 "Ethernet Adaptation Layer" we add the following paragraph: > The IPv6 packet transmitted on 802.11-OCB MUST be immediately > preceded by a Logical Link Control (LLC) header and an 802.11 header. > In the LLC header, and in accordance with the EtherType Protocol > Discrimination (EPD), the value of the Type field MUST be set to > 0x86DD (IPv6). In the 802.11 header, the value of the Subtype > sub-field in the Frame Control field MUST be set to 8 (i.e. 'QoS > Data'); the value of the Traffic Identifier (TID) sub-field of the > QoS Control field of the 802.11 header MUST be set to binary 001 > (i.e. User Priority 'Background', QoS Access Category 'AC_BK'). > > In the Ethernet II header, the value of the Type field MUST be set > to 0x86DD (IPv6). Do you agree with this text? > I note that ipwave mentions EPD, but also SNAP and does not specify > which method to use. I propose we remove this phrase: > Other alternative views of layering are EtherType Protocol > Discrimination (EPD), see Appendix E, and SNAP see [RFC1042]. Do you agree? > Moreover ipwave discusses an abstract "Ethernet Adaptation Layer" > but does not specify a header format, and this further confuses the > question for deployers - what should we implement? The Ethernet Adaptation Layer (more precisely 802.11-to-Ethernet AL) is not so abstract, because it is widely implemented. This layer does conversion between headers: at reception from the network it transforms a .11/LLC header into an EthernetII header; reversely, at sending it transforms an EthernetII header into a .11/LLC header. This is shown in Figure 1. The EAL does not intend to specify a header format. The header formats involved are the IEEE 802.11, LLC and EthernetII. The fields in these headers are specified by IEEE. > 2. It is not clear that ipwave provides any functionality that > 1609 WAVE does not already provide. Well, 1609 WAVE does not specify the conversion between .11/LLC headers and EthernetII headers, right? 1609 WAVE does not specify the MTU size for IPv6, right? 1609 WAVE does not specify that IPv6 must be preceded by .11 QoSData (not just .11 Data), and BACKGROUND, right? 1609 WAVE does not recommend in particular RFC8064 to form semantically opaque Interface Identifiers, right? (and a few others). > 1609 WAVE includes a number of mechanisms that enable IPv6 networks > to be configured. In addition to the WSA/WRA mechanism, 1609.3 allows > any IETF protocols to be implemented, e.g., IETF RFC 4861, Neighbor > Discovery for IP Version 6 (IPv6) (which is listed as a normative > reference in 1609.3). Helpful would be some example use-cases that > illustrate problems to be solved, and how ipwave will solve those > problems (i.e., that 1609 WAVE does not already solve). There is a draft that describes some use-cases of IPv6 in vehicular networks: draft-ietf-ipwave-vehicular-networking-02 I think some parts of 1609 WAVE, in particular WRA, are not used in Europe. Whereas this IPv6-over-OCB draft is used the same wherever Internet is present (Europe, America, Continents). > My concern is that the IETF ipwave document may cause significant > confusion among deployers, and possibly lead to a lack of > interoperability. Thank you for the opportunity to comment, I look > forward to the discussion. I would like to help with clarification. Let us discuss this. Alex > > > > Best regards, > > Kevin From nobody Fri Mar 16 04:48: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 F0F8E12704A for ; Fri, 16 Mar 2018 03:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.33 X-Spam-Level: X-Spam-Status: No, score=-4.33 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, T_RP_MATCHES_RCVD=-0.01] 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 K-hpjgto7ltn for ; Fri, 16 Mar 2018 03:33:37 -0700 (PDT) Received: from MAILOUT21.telekom.de (MAILOUT21.telekom.de [80.149.113.251]) (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 6931612025C for ; Fri, 16 Mar 2018 03:33:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1521196416; x=1552732416; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4vEjOcDQPW2/TcIi5goadaYVvYYwiFmSmyqAl3RecOI=; b=4O7iDhvdMo+qVdv/t6nHqOzp4d4rrgoXEXo9nlwIfDQS5hoz08lXYp1G oKeRsIRt1fO9w9KydyrGwoc1LJRD4HnvRTMfPECQnHtIpJa/3Rq9psWG1 A+xHRj6xzm63ZXw7NdUEYvS+TSnyESiuLKRllYGifHgImSHfDXNXf/Vpt q552b6mK+i+qekjtgnyxnk3sx9S53JC6B+q/atI/oTwxAGKK7jTDSvAT3 scmxwdyONgJqtnifNIJ3jWqNxZmRoI5iCiyjL/yDsJXHmE2H6Wia8Mqkm U2o0Ol/a0z1pl4VmxkriUYX/EK9fgoWaUwOgVbnJYPSbqlQxhMNy+JPoK g==; Received: from q4de8psa04t.blf.telekom.de ([10.151.13.130]) by MAILOUT21.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Mar 2018 11:33:32 +0100 X-IronPort-AV: E=Sophos;i="5.48,315,1517871600"; d="scan'208";a="834010371" Received: from he105716.emea1.cds.t-internal.com ([10.169.118.52]) by Q4DE8PSA04V.blf.telekom.de with ESMTP/TLS/AES256-SHA; 16 Mar 2018 11:33:32 +0100 Received: from HE105715.EMEA1.cds.t-internal.com (10.169.118.51) by HE105716.emea1.cds.t-internal.com (10.169.118.52) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Fri, 16 Mar 2018 11:33:32 +0100 Received: from HE105715.EMEA1.cds.t-internal.com ([fe80::e4a0:cc4:20d4:3019]) by HE105715.emea1.cds.t-internal.com ([fe80::e4a0:cc4:20d4:3019%26]) with mapi id 15.00.1365.000; Fri, 16 Mar 2018 11:33:32 +0100 From: To: , , CC: , , , , , , Thread-Topic: [ipwave] New Liaison Statement, "LS on Establishment of SAE Cellular V2X Technical Committee and Associated Task Forces" Thread-Index: AQHTg/c5iiwv/Bpd4kmiv/KExSrVeqPTG3OA Date: Fri, 16 Mar 2018 10:33:32 +0000 Message-ID: <67b280e1f9bb4167bc26e3405861504a@HE105715.emea1.cds.t-internal.com> References: <151491759052.22648.11984709015990586689.idtracker@ietfa.amsl.com> In-Reply-To: <151491759052.22648.11984709015990586689.idtracker@ietfa.amsl.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.15] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Fri, 16 Mar 2018 04:48:54 -0700 Subject: Re: [ipwave] New Liaison Statement, "LS on Establishment of SAE Cellular V2X Technical Committee and Associated Task Forces" X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 10:33:39 -0000 Dear chairs, has there been a reply to this LS? As far as I understand the focus of SAE here includes beside 11p/OCB also P= C5 the cellular sidelink which is not in the charter currently, right? The mail didn't mention a deadline for reply but the upcoming SAE meeting s= hould be completed by now ... Thanks! Best Regards Dirk=20 -----Original Message----- From: its [mailto:its-bounces@ietf.org] On Behalf Of Liaison Statement Mana= gement Tool Sent: Dienstag, 2. Januar 2018 19:27 To: Carlos Bernardos ; Russ Housley Cc: IP Wireless Access in Vehicular Environments Discussion List ; Elizabeth.Perry@sae.org; Russ Housley ; Carlos = Bernardos ; Keith.Wilson@sae.org; Suresh Krishnan ; Terry Manderson Subject: [ipwave] New Liaison Statement, "LS on Establishment of SAE Cellul= ar V2X Technical Committee and Associated Task Forces" Title: LS on Establishment of SAE Cellular V2X Technical Committee and Asso= ciated Task Forces Submission Date: 2018-01-02 URL of the IETF Web page: ht= tps://datatracker.ietf.org/liaison/1552/ From: Jim Misener To: Carlos Bernardos ,Russ Housley Cc: Russ Housley ,Terry Manderson ,Carlos Bernardos ,IP Wireless Access in Vehicular= Environments Discussion List ,Suresh Krishnan Response Contacts: Elizabeth.Perry@sae.org, Keith.Wilson@sae.org Tech= nical Contacts:=20 Purpose: For information Body: 1. Overall Description: The SAE Cellular V2X Technical Committee (C-V2X TC) was formed in June, 201= 7 with the following charter: The SAE Cellular V2X Technical Committee reports to the Vehicle Engineering= Systems Group of the Motor Vehicle Council. The Committee is responsible f= or adapting, developing and maintaining SAE Standards, Recommended Practice= s, and Information Reports that use cellular radio access technologies and = specifically, evolving 4G LTE and 5G cellular technologies that require int= eroperability and performance standards for road vehicles and other road us= ers in order to use the full capabilities of these technologies. The commit= tee also coordinates task force efforts to ensure efficient development and= delivery of SAE documents, acts as liaison to the other organizations invo= lved in the with vehicular-oriented cellular standards and deployments, and= organizes efforts in gathering requirements for SAE standardization and as= signs them to distributed task forces. The C-V2X Technical Committee will work closely with the SAE DSRC Technical= Committee and with their documents to assure efficient reuse and adjustmen= t as appropriate, e.g., strive to maintain a single data dictionary. Partic= ipants in the SAE C-V2X TC include vehicle OEMs, vehicle suppliers, mobile = network operators, mobile network operator equipment suppliers, mobile hand= set manufacturers, chipset manufacturers, road operators, traffic equipment= suppliers, consulting firms, government, and other interested parties. At the current time, three Task Forces constitute the C-V2X TC. The Task Fo= rces and charters are: CV2X Advanced Applications Task Force: Develop definitions of terms, use ca= ses, recommended practices, guidelines, test methods, specifications and pe= rformance standards for vehicles connected using C-V2X, focusing on advance= d V2X applications (i.e., applications that cannot be supported by DSRC and= Rel-14 LTEV2X) that deal with 5G (3GPP NR and LTE evolution) to leverage e= nhanced mobile broadband, use of millimeter wave and other anticipated radi= o access technologies, and the next generation core network including enabl= ers such as NFV/SDN, edge computing, and network slicing. The task force wi= ll encourage research in these areas, and sponsor and facilitate the develo= pment of related standards. The work of this task force will be coordinated= with other task forces in C-V2X Technical Committee, as well as other V2X = related technical committees and standards organizations such as 3GPP, ATIS= , GSM Association, DSRC Technical Committee, On-Road Automated Driving (RAD= ) Technical Committee, ITU-T and ETSI. CV2X Direct Communication Task Force: Develop definitions of terms, use cas= es, recommended practices guidelines, test methods, specifications and perf= ormance standards for vehicles connected using C-V2X, focusing on safety ap= plications that include cooperative awareness, warning notification, safe l= ane change, safe intersection and roundabout crossing, etc. Important topic= s of security, reliability, and quality of service will be part of the char= ter. The task force will encourage research in these areas, and sponsor and= facilitate the development of related standards. The work of this task for= ce will be coordinated with other task forces in CV2X Technical Committee, = as well as other V2X related technical committees and standards organizatio= ns such as DSRC Technical Committee, On-Road Automated Driving (RAD) Techni= cal Committee, 3GPP, ISO, ITU-T and ETSI. CV2X Road Operators Task Force: Work with the ground transportation operati= ng community to identify its high-level needs and develop standards, recomm= ended practices, and information reports to address those needs. 2. Actions: To (SDOs and industry organizations): ACTION: The SAE C-V2X welcomes mutual consideration and communication as we= jointly standardize applicable interoperability and performance specificat= ions to fully leverage 4G LTE and 5G cellular radio access technologies. 3. Date of Next SAE C-V2X Meetings: 3rd Wednesday of every month, 1000 Eastern Time US WebEx 14-15 March, 2018 = Southeast Michigan or Newark NJ (TBD) Attachments: SAE 12302017-1- LS Announcing SAE C-V2X v2final.pdf https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2018-01-02-sae-ce= ll-v2x-ipwave-ls-on-establishment-of-sae-cellular-v2x-technical-committee-a= nd-associated-task-forces-attachment-1.pdf _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its From nobody Fri Mar 16 06:39: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 793871289B0 for ; Fri, 16 Mar 2018 06:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJ8dOCHoPIur for ; Fri, 16 Mar 2018 06:39:46 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48C5A128961 for ; Fri, 16 Mar 2018 06:39:45 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w2GDdiBl134975 for ; Fri, 16 Mar 2018 14:39:44 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 391BC20607B for ; Fri, 16 Mar 2018 14:39: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 2473D205C0B for ; Fri, 16 Mar 2018 14:39: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 w2GDdhXY012347 for ; Fri, 16 Mar 2018 14:39:44 +0100 To: "its@ietf.org" From: Alexandre Petrescu Message-ID: Date: Fri, 16 Mar 2018 14:39: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 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 7bit Archived-At: Subject: [ipwave] QoSData, EPD, 1609 WAVE, EtherType - common text 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: Fri, 16 Mar 2018 13:39:47 -0000 Hi IPWAVErs, I propose the following text to resolve commonly the QoSData and 1609 WAVE EPD recent issues. > The IPv6 packet transmitted on 802.11-OCB MUST be immediately > preceded by a Logical Link Control (LLC) header and an 802.11 > header. In the LLC header, and in accordance with the EtherType > Protocol Discrimination (EPD), the value of the Type field MUST be > set to 0x86DD (IPv6). In the 802.11 header, the value of the Subtype > sub-field in the Frame Control field MUST be set to 8 (i.e. 'QoS > Data'); the value of the Traffic Identifier (TID) sub-field of the > QoS Control field of the 802.11 header MUST be set to binary 001 > (i.e. User Priority 'Background', QoS Access Category 'AC_BK'). > > In the Ethernet II header, the value of the Type field MUST be set to > 0x86DD (IPv6). Remove this phrase: > Other alternative views of layering are EtherType Protocol > Discrimination (EPD), see Appendix E, and SNAP see [RFC1042]. Yours, Alex From nobody Fri Mar 16 06:43: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 40A45128961 for ; Fri, 16 Mar 2018 06:43:54 -0700 (PDT) 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 y5Sb8HamxT48 for ; Fri, 16 Mar 2018 06:43:52 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97ABB126CD8 for ; Fri, 16 Mar 2018 06:43:52 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w2GDhiWE136177; Fri, 16 Mar 2018 14:43:44 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 161E92060CC; Fri, 16 Mar 2018 14:43: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 ED3812060CA; Fri, 16 Mar 2018 14:43:43 +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 w2GDhhci015831; Fri, 16 Mar 2018 14:43:43 +0100 From: Alexandre PETRESCU To: "its@ietf.org" Cc: Tony Li , John Kenney , Dick Roy , Tijink Jasja , Kevin Smith , =?UTF-8?Q?Fran=c3=a7ois_Simon?= , "=?UTF-8?Q?Sandra_C=c3=a9spedes_U.?=" Organization: CEA Message-ID: <114b39d6-351d-a78a-84d6-dec0ca34faf2@cea.fr> Date: Fri, 16 Mar 2018 14:43: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 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060507080301040505030703" Archived-At: Subject: [ipwave] QoSData, EPD, 1609 WAVE, EtherType - common text 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: Fri, 16 Mar 2018 13:43:54 -0000 This is a cryptographically signed message in MIME format. --------------ms060507080301040505030703 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: quoted-printable Hi IPWAVErs, I propose the following text to resolve commonly the QoSData and 1609=20 WAVE EPD recent issues. > The IPv6 packet transmitted on 802.11-OCB MUST be immediately=20 > preceded by a Logical Link Control (LLC) header and an 802.11 > header. In the LLC header, and in accordance with the EtherType > Protocol Discrimination (EPD), the value of the Type field MUST be > set to 0x86DD (IPv6). In the 802.11 header, the value of the Subtype > sub-field in the Frame Control field MUST be set to 8 (i.e. 'QoS=20 > Data'); the value of the Traffic Identifier (TID) sub-field of the=20 > QoS Control field of the 802.11 header MUST be set to binary 001=20 > (i.e. User Priority 'Background', QoS Access Category 'AC_BK'). >=20 > In the Ethernet II header, the value of the Type field MUST be set to > 0x86DD (IPv6). Remove this phrase: > Other alternative views of layering are EtherType Protocol=20 > Discrimination (EPD), see Appendix E, and SNAP see [RFC1042]. Yours, Alex --------------ms060507080301040505030703 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 CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODAzMTYxMzQzNDNaMC8GCSqGSIb3 DQEJBDEiBCBLMlvQjyaYIppnEk2riijXSS2SW7LFzyvw2rBe0ApSHzBSBgkrBgEEAYI3EAQx RTBDMD0xCzAJBgNVBAYTAkZSMQwwCgYDVQQKDANDRUExIDAeBgNVBAMMF0NFQSBBQyBVdGls aXNhdGV1ciAyMDMxAgIYEjBUBgsqhkiG9w0BCRACCzFFoEMwPTELMAkGA1UEBhMCRlIxDDAK BgNVBAoMA0NFQTEgMB4GA1UEAwwXQ0VBIEFDIFV0aWxpc2F0ZXVyIDIwMzECAhgSMGwGCSqG SIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJ KoZIhvcNAQEBBQAEggEALi3KGTAkJzYhIoAQj4qKfdZlaIpA4pN0s7jKsdBEQkyZHggT4Wti mmCCTzVPKoqRC9sKodCOxpRP6hkGoTcLXRKYeR+C1Qp6pbmi6OaXXz7BFnhfncKuwrUflHWE V1WjPpdpyK750GjmS1zHZ3wBiceTFyCPji0ltPn8C3JekvLBRjiNN4wHB3oY7gz4j9DjkH1B QRHw7v9YlxqrZaX70CzB79Ro9c6mp3Joj6zWK8d0BfQPWUj8eHTIJSx2nM+BKmVm8kzXSGAt e81Dkfor/0UJsGpox8JrxlA3coxEA8HWzhbweKi4ok1NzFBVMB6Pvafr5W6zRUOhov7QRb0D RgAAAAAAAA== --------------ms060507080301040505030703-- From nobody Fri Mar 16 09:26: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 AF58F12D86A for ; Fri, 16 Mar 2018 09:26:20 -0700 (PDT) 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 gVohG4ZzNu0Q for ; Fri, 16 Mar 2018 09:26:18 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::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 8743212D868 for ; Fri, 16 Mar 2018 09:26:18 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id z8so2580339wrh.7 for ; Fri, 16 Mar 2018 09:26:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:reply-to:to:cc:date:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=9BBCeKKNiqbXeeEs67HWClFNZEbuCsOzeVcJvVZhdkI=; b=Aa1jUUang3G507/IqiSNdVcLWWwsabUAdFtZksLQVFxJcrDpMGcZEDON7osq4n3FrG 4tcYUMiu+OnwgheAlr0XwU3Yw1pyvDfn/lUrUXVGFEmOKrgxKF4ZCVPTEStVDC0LMZRj p4tEQ7eWA+MjdBxV747XwfWQmgYz6sY6LZ0mxd4vD1oz/zHzdaoKChQlfegBVYIXdcrE uV3VYXkMbX0nWQyRVmE+LSYsAF0Xf/JjhQmu3YfsRoOtucMNaH3GCEtDAHijs5Y7ZB+4 jS5MV1/Xv8jfHfSnVZlKJvJyEyo3UO0xjapDmOFFhGrcuIIOzLZsz0qsSXW17SzUckS4 TFUw== 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=9BBCeKKNiqbXeeEs67HWClFNZEbuCsOzeVcJvVZhdkI=; b=DclaLc3j9QDFatgSYTVBkwzI1J/tqTgMOFxGk6Qm9xOUoyZq1a00jZeOOCk0xPryug bumzpI5pV37o2RM/jWFcJGyk+Jk6bKx/sokj3mENo+9QXBl5Cc/tgvhCN/MPkwLTMRPh MgxqbfwHpjEHneK111j9AyxKBC9QcXhMvhThpvMMBM7MBSEWjd1V2VgSJb1kbbg3u7hg 1ZwQovvZ/WJYTR6izWlMSKPKr9ykP3l2bsv6RLMlZZK0Dl7E7lNqkjJE2h8G+bWgn2Q+ 8mAXJuUVj212aSBiOr0ffRzfsEafxqFA775mcIMmWXEbzkUhjU0/8MiwdhXHZcQAYi3B Wncg== X-Gm-Message-State: AElRT7FCLbtURiRI4QWROuKvYN58e5OQCTtGUzAfk2qfg5PAH4z51A8C 2D0pfo+3ov2x5qyc2QJuXC3PYQ== X-Google-Smtp-Source: AG47ELs+EuZ19uoNtLFQLA9r1/hOFEmJsANEohR8ecSgVxKCcYPsFYQawSJssN3nY9nqh1tWJ2cGHg== X-Received: by 10.223.201.142 with SMTP id f14mr2283138wrh.40.1521217576600; Fri, 16 Mar 2018 09:26:16 -0700 (PDT) Received: from acorde ([2001:720:410:1010:d681:d7ff:fe28:350b]) by smtp.gmail.com with ESMTPSA id m135sm3003021wma.2.2018.03.16.09.26.15 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 16 Mar 2018 09:26:15 -0700 (PDT) Message-ID: <1521217574.4118.17.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" Cc: Sandra =?ISO-8859-1?Q?C=E9spedes?= "U." , Kevin Smith , John Kenney , Tijink Jasja , Tony Li , =?ISO-8859-1?Q?Fran=E7ois?= Simon , Dick Roy Date: Fri, 16 Mar 2018 17:26:14 +0100 In-Reply-To: <114b39d6-351d-a78a-84d6-dec0ca34faf2@cea.fr> References: <114b39d6-351d-a78a-84d6-dec0ca34faf2@cea.fr> 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: Re: [ipwave] QoSData, EPD, 1609 WAVE, EtherType - common text 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: Fri, 16 Mar 2018 16:26:21 -0000 Hi Alex, Thanks for driving this. People, please do express if you agree or not with Alex's proposal. It is important to get as much feedback as possible by the time of the IPWAVE F2F session in London, so we can close this for one and for all. Thanks, Carlos On Fri, 2018-03-16 at 14:43 +0100, Alexandre PETRESCU wrote: > Hi IPWAVErs, > > I propose the following text to resolve commonly the QoSData and > 1609 > WAVE EPD recent issues. > > > The IPv6 packet transmitted on 802.11-OCB MUST be immediately > > preceded by a Logical Link Control (LLC) header and an 802.11 > > header. In the LLC header, and in accordance with the EtherType > > Protocol Discrimination (EPD), the value of the Type field MUST be > > set to 0x86DD (IPv6). In the 802.11 header, the value of the > > Subtype > > sub-field in the Frame Control field MUST be set to 8 (i.e. 'QoS > > Data'); the value of the Traffic Identifier (TID) sub-field of the > > QoS Control field of the 802.11 header MUST be set to binary 001 > > (i.e. User Priority 'Background', QoS Access Category 'AC_BK'). > > > > In the Ethernet II header, the value of the Type field MUST be set > > to > > 0x86DD (IPv6). > > Remove this phrase: > > Other alternative views of layering are EtherType Protocol > > Discrimination (EPD), see Appendix E, and SNAP see [RFC1042]. > > Yours, > > Alex > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Fri Mar 16 09:51: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 D633912711D for ; Fri, 16 Mar 2018 09:48:48 -0700 (PDT) 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 2OGHh0NEFy0J for ; Fri, 16 Mar 2018 09:48:46 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::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 0214E1200C5 for ; Fri, 16 Mar 2018 09:48:46 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id w16-v6so16255872lfc.13 for ; Fri, 16 Mar 2018 09:48:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7Lb5E1GimrbYL8k0BDFivoSkeX8XGtGa9nColaRGWeY=; b=qS5ctANmZWGU4s/CS1XJydO4iZ1GgcC08h5eu4vld4S4hHVoQouKfcft23T7RfJ3e2 eeyQDOrMqxJU1FqVeN05Hb+Mc4MXhYjfYZKwxk7qj5dysyidp4/bLLJ2GN3BkFEOjlHG 5ixPk2XshropUKjDYNW01COCgkXNVlY6V+BpBpmIAKW8c1OitDctSjHlmDiMvdMo0LK+ +iAMlOggnN0PuPH2xUA0ip9paXHPyqWEkF5IS+wQ+TGHJNji548WWJe7lp96RwwHKNi8 a9x/1SL3xImGyC3xRyovMUmMCChqMETOcRWIB7vSN2Qul0W/o7gclIz7vcVMxTEn7qwH VRgg== 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=7Lb5E1GimrbYL8k0BDFivoSkeX8XGtGa9nColaRGWeY=; b=hGFMWCV8zbhj9boST2Slk6UWgNQr9DhfZsaiFTardD/OfkYTyEek4uQ7eNm3vAGK9N USVKrJLlC/nikPc5YprZAtCbNYXhfgNfldPUTTmpAu7OqwPy7S/XkMwPsQXLSwUNPwI6 LcVPNj7lznYJVzB90HRe+ApxSW9WTBHOf/jUEM/0iwasAvi8nJn/1PWMqMCKnUBnAFfz i0svNVXwwlr/XJU/BlSrRUrae7lQ6kIRzrDM9hDw4OiIEutMcsLNsft084MEIgzSYdgE cACyg/in02lqjocJbcJrqF/60nLP4l5WUFgwzYRQnOYRvJknsPCRuuDVuIiglRzTJBEu PIjQ== X-Gm-Message-State: AElRT7HLmM9kqdOXKlkBpkRg49Ti8h06OSKyZaGi9wr3swhLVlYW9akP /gkVjonoRqs+lCB9wS9FreLtLOjWdEbOJ8cVSq8= X-Google-Smtp-Source: AG47ELvCQAn5Bg0Z5dQfV9Vh2JMrs5ShWsIMygvVJtPaY9eBsLWzgWGDt10h/jJO+M7JenXBeAcN9pGYYT3kQvxKZXQ= X-Received: by 10.46.113.17 with SMTP id m17mr1817810ljc.114.1521218924162; Fri, 16 Mar 2018 09:48:44 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:e601:0:0:0:0:0 with HTTP; Fri, 16 Mar 2018 09:48:43 -0700 (PDT) In-Reply-To: <1521217574.4118.17.camel@it.uc3m.es> References: <114b39d6-351d-a78a-84d6-dec0ca34faf2@cea.fr> <1521217574.4118.17.camel@it.uc3m.es> From: Nabil Benamar Date: Fri, 16 Mar 2018 16:48:43 +0000 Message-ID: To: =?UTF-8?Q?Carlos_Jes=C3=BAs_Bernardos_Cano?= Cc: Alexandre PETRESCU , "its@ietf.org" , =?UTF-8?Q?Sandra_C=C3=A9spedes_U=2E?= , Kevin Smith , John Kenney , Tijink Jasja , Tony Li , =?UTF-8?Q?Fran=C3=A7ois_Simon?= , Dick Roy Content-Type: multipart/alternative; boundary="089e0834050e99b2cb05678a61a6" Archived-At: X-Mailman-Approved-At: Fri, 16 Mar 2018 09:51:43 -0700 Subject: Re: [ipwave] QoSData, EPD, 1609 WAVE, EtherType - common text 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: Fri, 16 Mar 2018 16:48:49 -0000 --089e0834050e99b2cb05678a61a6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Carlos, As a co-author of the draft, I have no objection to the changes suggested by Alex. 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 Fri, Mar 16, 2018 at 4:26 PM, Carlos Jes=C3=BAs Bernardos Cano < cjbc@it.uc3m.es> wrote: > Hi Alex, > > Thanks for driving this. > > People, please do express if you agree or not with Alex's proposal. It > is important to get as much feedback as possible by the time of the > IPWAVE F2F session in London, so we can close this for one and for all. > > Thanks, > > Carlos > > On Fri, 2018-03-16 at 14:43 +0100, Alexandre PETRESCU wrote: > > Hi IPWAVErs, > > > > I propose the following text to resolve commonly the QoSData and > > 1609 > > WAVE EPD recent issues. > > > > > The IPv6 packet transmitted on 802.11-OCB MUST be immediately > > > preceded by a Logical Link Control (LLC) header and an 802.11 > > > header. In the LLC header, and in accordance with the EtherType > > > Protocol Discrimination (EPD), the value of the Type field MUST be > > > set to 0x86DD (IPv6). In the 802.11 header, the value of the > > > Subtype > > > sub-field in the Frame Control field MUST be set to 8 (i.e. 'QoS > > > Data'); the value of the Traffic Identifier (TID) sub-field of the > > > QoS Control field of the 802.11 header MUST be set to binary 001 > > > (i.e. User Priority 'Background', QoS Access Category 'AC_BK'). > > > > > > In the Ethernet II header, the value of the Type field MUST be set > > > to > > > 0x86DD (IPv6). > > > > Remove this phrase: > > > Other alternative views of layering are EtherType Protocol > > > Discrimination (EPD), see Appendix E, and SNAP see [RFC1042]. > > > > Yours, > > > > Alex > > > > > > _______________________________________________ > > its mailing list > > its@ietf.org > > https://www.ietf.org/mailman/listinfo/its > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > --089e0834050e99b2cb05678a61a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Carlos,

As a co-author of the draft, I h= ave no objection to the changes suggested by Alex.



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 Fri, Mar 16, 2018 at 4:26 PM, Carlos Jes= =C3=BAs Bernardos Cano <cjbc@it.uc3m.es> wrote:
Hi Alex,

Thanks for driving this.

People, please do express if you agree or not with Alex's proposal. It<= br> is important to get as much feedback as possible by the time of the
IPWAVE F2F session in London, so we can close this for one and for all.

Thanks,

Carlos

On Fri, 2018-03-16 at 14:43 +0100, Alexandre PETRESCU wrote:
> Hi IPWAVErs,
>
> I propose the following text to resolve commonly the QoSData and
> 1609
> WAVE EPD recent issues.
>
> > The IPv6 packet transmitted on 802.11-OCB MUST be immediately
> > preceded by a Logical Link Control (LLC) header and an 802.11
> > header. In the LLC header, and in accordance with the EtherType > > Protocol Discrimination (EPD), the value of the Type field MUST b= e
> > set to 0x86DD (IPv6).=C2=A0 In the 802.11 header, the value of th= e
> > Subtype
> >=C2=A0 sub-field in the Frame Control field MUST be set to 8 (i.e.= 'QoS
> > Data'); the value of the Traffic Identifier (TID) sub-field o= f the
> > QoS Control field of the 802.11 header MUST be set to binary 001<= br> > > (i.e. User Priority 'Background', QoS Access Category = 9;AC_BK').
> >
> > In the Ethernet II header, the value of the Type field MUST be se= t
> > to
> > 0x86DD (IPv6).
>
> Remove this phrase:
> > Other alternative views of layering are EtherType Protocol
> > Discrimination (EPD), see Appendix E, and SNAP see [RFC1042].
>
> Yours,
>
> Alex
>
>
> _______________________________________________
> its mailing list
> its@ietf.org
> https://www.ietf.org/mailman/listinfo/its

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

--089e0834050e99b2cb05678a61a6-- From nobody Fri Mar 16 10:34: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 6903312D0C3 for ; Fri, 16 Mar 2018 10:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.584 X-Spam-Level: X-Spam-Status: No, score=-0.584 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 hTVmxw3lnfzx for ; Fri, 16 Mar 2018 10:34:28 -0700 (PDT) Received: from fed1rmfepo202.cox.net (fed1rmfepo202.cox.net [68.230.241.147]) by ietfa.amsl.com (Postfix) with ESMTP id 987171273E2 for ; Fri, 16 Mar 2018 10:34:27 -0700 (PDT) Received: from fed1rmimpo209.cox.net ([68.230.241.160]) by fed1rmfepo202.cox.net (InterMail vM.8.01.05.28 201-2260-151-171-20160122) with ESMTP id <20180316173427.UKWT4574.fed1rmfepo202.cox.net@fed1rmimpo209.cox.net> for ; Fri, 16 Mar 2018 13:34:27 -0400 Received: from smithPC ([174.68.115.141]) by fed1rmimpo209.cox.net with cox id NhaS1x00a336m1J01haSzQ; Fri, 16 Mar 2018 13:34:26 -0400 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A090205.5AAC0022.00B0, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.2 cv=OZToNlbY c=1 sm=1 tr=0 a=lZ+2k6HZ6QqstbCzvfe+bA==:117 a=lZ+2k6HZ6QqstbCzvfe+bA==:17 a=kj9zAlcOel0A:10 a=x7bEGLp0ZPQA:10 a=kGgg9RDvKM0A:10 a=48vgC7mUAAAA:8 a=kviXuzpPAAAA:8 a=A1EfXRNyAAAA:8 a=uP5ywOSfYjXg0R0wNsAA:9 a=q56tqanBFsn5VCO3:21 a=dqpUwVdrwH5gW22y:21 a=CjuIK1q_8ugA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=qrIFiuKZe2vaD64auk6j:22 a=ho1zAXZTouNDp1r8zZ_w:22 X-CM-Score: 0.00 Authentication-Results: cox.net; auth=pass (LOGIN) smtp.auth=kevin.s.smith@cox.net From: "Kevin Smith" To: "Alexandre PETRESCU" Cc: "'Tijink Jasja'" , References: In-Reply-To: Date: Fri, 16 Mar 2018 10:34:30 -0700 Message-ID: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGhOrR8o8b5YryKQCC/S9k90bJ5fwIDl0bIpCf3FSA= Content-Language: en-us Archived-At: Subject: [ipwave] FW: ipwave - comments and concerns - 1609 WAVE, EPD - 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: Fri, 16 Mar 2018 17:34:30 -0000 Hi Alex, Thanks for the feedback. I have a few comments - but please keep in mind that these comments and opinions are my own and not necessarily those of the 1609 WG at large. I do not have the authority for speak for the WG, I'm just the editor. ;) My comments are inline denoted by [KS]. And please also seem some *new comments* below regarding EAL and "standard Ethernet packets". Best regards, Kevin -----Original Message----- From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu Sent: Thursday, March 15, 2018 11:23 AM To: Kevin Smith Cc: Tijink Jasja ; its@ietf.org Subject: Re: [ipwave] ipwave - comments and concerns - 1609 WAVE, EPD - towards resolution Hi Kevin, Kevin wrote recently: > Dear IETF ipwave working group, > > > > My name is Kevin Smith, I am the technical editor for IEEE Std 1609.3 > and a few others in the 1609 family of standards. I have some concerns > regarding ipwave's interoperability with 1609 WAVE, and a question > regarding the need or purpose for ipwave. Generally speaking, the purpose of ipwave WG is set in the Charter. (https://datatracker.ietf.org/wg/ipwave/about/) > 1. If ipwave is intended to be interoperable with 1609 WAVE, > then ipwave must specify the use of EtherType Protocol Discrimination > (EPD) in the LLC sublayer header, i.e., EPD is mandatory. We should interoperate to a maximum. [KS]: Agreed! I suggest that in section 4.2.1 "Ethernet Adaptation Layer" we add the following paragraph: > The IPv6 packet transmitted on 802.11-OCB MUST be immediately preceded > by a Logical Link Control (LLC) header and an 802.11 header. > In the LLC header, and in accordance with the EtherType Protocol > Discrimination (EPD), the value of the Type field MUST be set to > 0x86DD (IPv6). In the 802.11 header, the value of the Subtype > sub-field in the Frame Control field MUST be set to 8 (i.e. 'QoS > Data'); the value of the Traffic Identifier (TID) sub-field of the QoS > Control field of the 802.11 header MUST be set to binary 001 (i.e. > User Priority 'Background', QoS Access Category 'AC_BK'). > > In the Ethernet II header, the value of the Type field MUST be set to > 0x86DD (IPv6). Do you agree with this text? [KS]: I agree with the part that addresses the LLC header. I don't disagree with the part addressing the 802.11 header, I'm just not an expert in this area and so defer to others. I believe that others in the 1609 WG have been discussing this with the ipwave list? > I note that ipwave mentions EPD, but also SNAP and does not specify > which method to use. I propose we remove this phrase: > Other alternative views of layering are EtherType Protocol > Discrimination (EPD), see Appendix E, and SNAP see [RFC1042]. Do you agree? [KS]: Yes. > Moreover ipwave discusses an abstract "Ethernet Adaptation Layer" > but does not specify a header format, and this further confuses the > question for deployers - what should we implement? The Ethernet Adaptation Layer (more precisely 802.11-to-Ethernet AL) is not so abstract, because it is widely implemented. This layer does conversion between headers: at reception from the network it transforms a .11/LLC header into an EthernetII header; reversely, at sending it transforms an EthernetII header into a .11/LLC header. This is shown in Figure 1. The EAL does not intend to specify a header format. The header formats involved are the IEEE 802.11, LLC and EthernetII. The fields in these headers are specified by IEEE. [KS]: I don't understand why the EAL is relevant to "Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set". If I want to write software that sends IPv6 packets over 802.11 OCB, all I need to know is how to construct the LLC sublayer header, etc. The EAL sounds like a "bridge", and perhaps belongs in a separate document (and perhaps has already been addressed in some existing document?) Regardless, including a description of the EAL does not violate anything in 1609.3, as it is out of scope with 1609.3. Some *new comments* from my side: - ipwave 4.2.1 it states "An 'adaptation' layer is inserted between a MAC layer and the Networking layer." This sounds like a requirement. If I am developing a product that is only concerned with sending IPv6 over OCB, and does not require "bridging", then how do I reconcile this requirement? - ipwave 4.2 it states "IP packets are transmitted over 802.11-OCB as standard Ethernet packets. As with all 802.11 frames, an Ethernet adaptation layer MUST be used with 802.11-OCB as well." Again EAL is stipulated as a requirement. And I'm not sure about the stipulation that packets are transmitted as "standard Ethernet packets", is this accurate? Does this mean that 802.3 headers are included? This is definitely not stipulated in 1609.3. Packets transmitted over OCB by a WAVE device using 1609.3 are well formed IPv6 packets, but not "Ethernet packets", i.e., no 802.3 headers are included. This seems like an interoperability problem between ipwave and 1609 WAVE. > 2. It is not clear that ipwave provides any functionality that > 1609 WAVE does not already provide. Well, 1609 WAVE does not specify the conversion between .11/LLC headers and EthernetII headers, right? [KS]: Correct it does not, as this topic is out of scope for 1609 WAVE (e.g., we don't specify the other interfaces such as Ethernet that may be present in the device). Also see my comments above regarding the EAL. 1609 WAVE does not specify the MTU size for IPv6, right? [KS]: No it does not. 802.11 (normative to 1609) specifies maximum MSDU size as 2304 octets. For WSMP 1609.3 specifies a maximum MSDU size of 2302 (allowing for the 2-octet LLC header), and a default value of 1400. You are correct in that a MSDU size for IPv6 is not specified explicitly, but I don't know if some other RFCs related to IPv6 over 802.11 already do that? Regardless, stipulating a default value of 1500 for MTU size does not violate anything in 1609.3. 1609 WAVE does not specify that IPv6 must be preceded by .11 QoSData (not just .11 Data), and BACKGROUND, right? [KS]: Certainly 1609 does not. 1609 only restricts IPv6 packets to the SCH (they are not allowed on the CCH). 802.11 specifies defaults for all UP and AC parameters, indicates which frame types are allowed, etc. But as far as I can tell the stipulation that IPv6 use QoSData and AC_BK is new and something that ipwave introduces? Again, I'm not an expert on this topic and I believe others in the 1609 WG have been discussing this with the ipwave list. Regardless, this additional restriction does not violate 1609.3. 1609 WAVE does not recommend in particular RFC8064 to form semantically opaque Interface Identifiers, right? [KS]: 1609 does not recommend anything like this, but on the other hand 1609 does not prohibit it either. 1609 does not generally speaking "recommend", rather it "specifies" and leaves all else up to the system designer/implementer/deployer. And as mentioned previously, 1609 allows any and all IETF protocols to be implemented. Regardless, this recommendation does not violate anything in 1609.3. (and a few others). > 1609 WAVE includes a number of mechanisms that enable IPv6 networks to > be configured. In addition to the WSA/WRA mechanism, 1609.3 allows any > IETF protocols to be implemented, e.g., IETF RFC 4861, Neighbor > Discovery for IP Version 6 (IPv6) (which is listed as a normative > reference in 1609.3). Helpful would be some example use-cases that > illustrate problems to be solved, and how ipwave will solve those > problems (i.e., that 1609 WAVE does not already solve). There is a draft that describes some use-cases of IPv6 in vehicular networks: draft-ietf-ipwave-vehicular-networking-02 [KS]: Thanks for pointing me to that, lots of info there! I'll spend some time reviewing that when I can. I think some parts of 1609 WAVE, in particular WRA, are not used in Europe. Whereas this IPv6-over-OCB draft is used the same wherever Internet is present (Europe, America, Continents). [KS]: 1609 went to great lengths to harmonize WSM and WSA frame formats with ISO/ETSI standards, these harmonized frames are included in all of the -2016 revisions to 1609. So for example the 1609.3 WSA is interoperable with the service advertisement used in Europe. See ISO 16460, and see also ETSI TS 102 890-1. > My concern is that the IETF ipwave document may cause significant > confusion among deployers, and possibly lead to a lack of > interoperability. Thank you for the opportunity to comment, I look > forward to the discussion. I would like to help with clarification. Let us discuss this. [KS]: Sounds good! Alex > > > > Best regards, > > Kevin _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its From nobody Fri Mar 16 11:02: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 5633E127876 for ; Fri, 16 Mar 2018 11:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kapsch.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDwt74gsGhxW for ; Fri, 16 Mar 2018 11:02:14 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0134.outbound.protection.outlook.com [104.47.1.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AA9C127369 for ; Fri, 16 Mar 2018 11:02:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kapsch.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bwpDJr6i9FulbSqr6O9WcNTM6vewR8w7rdFDA+HfcxI=; b=EnJdOU83b01zOA3XPnrNlqA8HOl+2j5NLAcN5rjMkU/DMIDBKpxyL8kp+Z8ZrMLPcsnpXLSldXR3v8FGZLEuk4sEDNG2L4J1I9Bd/d6XLOT4UAif1WZf2LzpBoeiLQ4DEz+qWCZDUwl6hs21BuM9mlMQYmS2YnNE7u4Gm/RxL8w= Received: from AM0PR0302MB3380.eurprd03.prod.outlook.com (52.133.37.155) by AM0PR0302MB3233.eurprd03.prod.outlook.com (52.133.37.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.588.14; Fri, 16 Mar 2018 18:02:11 +0000 Received: from AM0PR0302MB3380.eurprd03.prod.outlook.com ([fe80::153a:2232:e7b7:7cb4]) by AM0PR0302MB3380.eurprd03.prod.outlook.com ([fe80::153a:2232:e7b7:7cb4%13]) with mapi id 15.20.0588.016; Fri, 16 Mar 2018 18:02:11 +0000 From: Tijink Jasja To: Kevin Smith , Alexandre PETRESCU CC: "its@ietf.org" Thread-Topic: [ipwave] ipwave - comments and concerns - 1609 WAVE, EPD - towards resolution Thread-Index: AQGhOrR8o8b5YryKQCC/S9k90bJ5fwIDl0bIpCf3FSCAABQxgA== Date: Fri, 16 Mar 2018 18:02:10 +0000 Message-ID: References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> In-Reply-To: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jasja.Tijink@kapsch.net; x-originating-ip: [194.166.238.222] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM0PR0302MB3233; 7:PKcKJKB6S2r4md5YBtqD/jWn4RzZsxybpLELUu5SLMDOq5ZJ3VsAKmGOPbRz6M6q+DlI32NEiOjz4u9qjoYIQsq2JVZgehqjAW3YZHSVsmxx+zT0b7pST27UkL0nWnziwvlqOI8qF1qaXVgo4CEAQuDM1u0wYvZGiestYbiWC39O9McuheVAkOuXzk4zW5eGzbyhGEf2koYcS2ZuQ+ofOkllJeJOOBPd478Th0mqzVs/LbWXuhEVIXeUgKZv0pEQ x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: e9c38887-c0e8-48df-9285-08d58b680a8c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:AM0PR0302MB3233; x-ms-traffictypediagnostic: AM0PR0302MB3233: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(79046362386883)(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(3231221)(944501244)(52105095)(93006095)(93001095)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123562045)(6072148)(201708071742011); SRVR:AM0PR0302MB3233; BCL:0; PCL:0; RULEID:; SRVR:AM0PR0302MB3233; x-forefront-prvs: 0613912E23 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400004)(39380400002)(366004)(396003)(346002)(376002)(51914003)(54014002)(199004)(189003)(13464003)(14454004)(316002)(966005)(555904003)(72206003)(2950100002)(39060400002)(110136005)(25786009)(33656002)(561944003)(4326008)(8676002)(8936002)(97736004)(6436002)(66066001)(81156014)(81166006)(5660300001)(8666007)(5250100002)(6116002)(2900100001)(3846002)(305945005)(7736002)(478600001)(6306002)(55016002)(3280700002)(74316002)(9686003)(105586002)(2906002)(53936002)(106356001)(76176011)(26005)(59450400001)(86362001)(99286004)(68736007)(186003)(7696005)(345774005)(102836004)(53546011)(6506007)(3660700001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR0302MB3233; H:AM0PR0302MB3380.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: kapsch.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: V09ZU/v9WwGLO59o1uTD8z45MKG47HBS0s9lbjaBFTjvA3ClKAZ+EXsyYBS8M/TrGPJi4MNsgygYHF3E9WDLWFruzEiV3kDQ4pkQ0Glw+SrOtI9M0jOvbpUVJRvPtetdO0v/F1YNKo7HxYUd1cudU2B/08PyMPpQCDktZArbp2t+7RaGXUhsjj5FMD67HJ2T17KF7PVHTVfjerkgWULdmrmR8y4vCnAma0RhUNtuvc8rLHTfXdfe0g1I93EKY44nYEjKtJq40xpksMR/XtGn/JkQKaAHfK2DV4j3KBf/B/rb1BFV1HYMux84uoit95DZAqumykkrsEBySZ9POaOQ2A== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: kapsch.net X-MS-Exchange-CrossTenant-Network-Message-Id: e9c38887-c0e8-48df-9285-08d58b680a8c X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2018 18:02:11.1543 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5f9ce527-7e3e-4e83-a8a4-b6c848f85ab5 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR0302MB3233 Archived-At: Subject: Re: [ipwave] ipwave - comments and concerns - 1609 WAVE, EPD - 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: Fri, 16 Mar 2018 18:02:17 -0000 Hello Alex, in addition to Kevin's points, I would like to mention that: 1. I welcome your proposal for the additional text that specifies QoS. This= is necessary for operation in Europe (the specification for the access lay= er can be found in ETSI EN 302 663, where clause 4.6 says that QoS shall be= used). 2. My understanding of the discussion below is that draft-ietf-ipwave-ipv6-= over-80211ocb-21 is "based on" IEEE 1609.3 in that it is compliant with it = (I didn't find any "violation of IEEE 1609.3), and adds additional restrict= ions and /or specifications (such a MTU size, AC_BK, RFC8064, etc.). In tha= t sense draft-ietf-ipwave-ipv6-over-80211ocb-21 is a profile of IEEE 1609.3= . I would suggest making that very clear, with a short sentence/paragraph i= n draft-ietf-ipwave-ipv6-over-80211ocb-21 that explains it to the reader. I= f you disagree, I would like to hear your view on the relation of IEEE 1609= .3 and draft-ietf-ipwave-ipv6-over-80211ocb-21. Best regards Jasja -----Urspr=FCngliche Nachricht----- Von: Kevin Smith [mailto:kevin.s.smith@cox.net]=20 Gesendet: Freitag, 16. M=E4rz 2018 18:35 An: Alexandre PETRESCU Cc: Tijink Jasja ; its@ietf.org Betreff: FW: [ipwave] ipwave - comments and concerns - 1609 WAVE, EPD - tow= ards resolution Hi Alex, Thanks for the feedback. I have a few comments - but please keep in mind th= at these comments and opinions are my own and not necessarily those of the 1609 WG at large. I do not have the authority for speak for the WG, I'm jus= t the editor. ;) My comments are inline denoted by [KS]. And please also seem some *new comments* below regarding EAL and "standard Ethernet packets". Best regards, Kevin -----Original Message----- From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu Sent: Thursday, March 15, 2018 11:23 AM To: Kevin Smith Cc: Tijink Jasja ; its@ietf.org Subject: Re: [ipwave] ipwave - comments and concerns - 1609 WAVE, EPD - tow= ards resolution Hi Kevin, Kevin wrote recently: > Dear IETF ipwave working group, >=20 >=20 >=20 > My name is Kevin Smith, I am the technical editor for IEEE Std 1609.3=20 > and a few others in the 1609 family of standards. I have some concerns=20 > regarding ipwave's interoperability with 1609 WAVE, and a question=20 > regarding the need or purpose for ipwave. Generally speaking, the purpose of ipwave WG is set in the Charter. (https://datatracker.ietf.org/wg/ipwave/about/) > 1. If ipwave is intended to be interoperable with 1609 WAVE,=20 > then ipwave must specify the use of EtherType Protocol Discrimination > (EPD) in the LLC sublayer header, i.e., EPD is mandatory. We should interoperate to a maximum. [KS]: Agreed! I suggest that in section 4.2.1 "Ethernet Adaptation Layer" we add the foll= owing paragraph: > The IPv6 packet transmitted on 802.11-OCB MUST be immediately preceded=20 > by a Logical Link Control (LLC) header and an 802.11 header. > In the LLC header, and in accordance with the EtherType Protocol=20 > Discrimination (EPD), the value of the Type field MUST be set to=20 > 0x86DD (IPv6). In the 802.11 header, the value of the Subtype=20 > sub-field in the Frame Control field MUST be set to 8 (i.e. 'QoS=20 > Data'); the value of the Traffic Identifier (TID) sub-field of the QoS=20 > Control field of the 802.11 header MUST be set to binary 001 (i.e. > User Priority 'Background', QoS Access Category 'AC_BK'). >=20 > In the Ethernet II header, the value of the Type field MUST be set to=20 > 0x86DD (IPv6). Do you agree with this text? [KS]: I agree with the part that addresses the LLC header. I don't disagree= with the part addressing the 802.11 header, I'm just not an expert in this= area and so defer to others. I believe that others in the 1609 WG have bee= n discussing this with the ipwave list?=20 > I note that ipwave mentions EPD, but also SNAP and does not specify=20 > which method to use. I propose we remove this phrase: > Other alternative views of layering are EtherType Protocol=20 > Discrimination (EPD), see Appendix E, and SNAP see [RFC1042]. Do you agree? [KS]: Yes. > Moreover ipwave discusses an abstract "Ethernet Adaptation Layer" > but does not specify a header format, and this further confuses the=20 > question for deployers - what should we implement? The Ethernet Adaptation Layer (more precisely 802.11-to-Ethernet AL) is not= so abstract, because it is widely implemented. This layer does conversion = between headers: at reception from the network it transforms a .11/LLC head= er into an EthernetII header; reversely, at sending it transforms an Ethern= etII header into a .11/LLC header. This is shown in Figure 1. The EAL does not intend to specify a header format. The header formats invo= lved are the IEEE 802.11, LLC and EthernetII. The fields in these headers a= re specified by IEEE. [KS]: I don't understand why the EAL is relevant to "Transmission of IPv6 P= ackets over IEEE 802.11 Networks operating in mode Outside the Context of a= Basic Service Set". If I want to write software that sends IPv6 packets ov= er 802.11 OCB, all I need to know is how to construct the LLC sublayer header,= etc. The EAL sounds like a "bridge", and perhaps belongs in a separate doc= ument (and perhaps has already been addressed in some existing document?) R= egardless, including a description of the EAL does not violate anything in = 1609.3, as it is out of scope with 1609.3.=20 Some *new comments* from my side: - ipwave 4.2.1 it states "An 'adaptation' layer is inserted between a MAC l= ayer and the Networking layer." This sounds like a requirement. If I am dev= eloping a product that is only concerned with sending IPv6 over OCB, and do= es not require "bridging", then how do I reconcile this requirement? - ipwave 4.2 it states "IP packets are transmitted over 802.11-OCB as stand= ard Ethernet packets. As with all 802.11 frames, an Ethernet adaptation lay= er MUST be used with 802.11-OCB as well." Again EAL is stipulated as a requ= irement. And I'm not sure about the stipulation that packets are transmitte= d as "standard Ethernet packets", is this accurate? Does this mean that 802= .3 headers are included? This is definitely not stipulated in 1609.3. Packe= ts transmitted over OCB by a WAVE device using 1609.3 are well formed IPv6 = packets, but not "Ethernet packets", i.e., no 802.3 headers are included. T= his seems like an interoperability problem between ipwave and 1609 WAVE. > 2. It is not clear that ipwave provides any functionality that > 1609 WAVE does not already provide. Well, 1609 WAVE does not specify the conversion between .11/LLC headers and= EthernetII headers, right? [KS]: Correct it does not, as this topic is out of scope for 1609 WAVE (e.g= ., we don't specify the other interfaces such as Ethernet that may be prese= nt in the device). Also see my comments above regarding the EAL. 1609 WAVE does not specify the MTU size for IPv6, right? [KS]: No it does not. 802.11 (normative to 1609) specifies maximum MSDU siz= e as 2304 octets. For WSMP 1609.3 specifies a maximum MSDU size of 2302 (al= lowing for the 2-octet LLC header), and a default value of 1400. You are co= rrect in that a MSDU size for IPv6 is not specified explicitly, but I don't= know if some other RFCs related to IPv6 over 802.11 already do that? Regardless, stipulating a default value of 1500 for MTU size does not viola= te anything in 1609.3. 1609 WAVE does not specify that IPv6 must be preceded by .11 QoSData (not j= ust .11 Data), and BACKGROUND, right? [KS]: Certainly 1609 does not. 1609 only restricts IPv6 packets to the SCH = (they are not allowed on the CCH). 802.11 specifies defaults for all UP and= AC parameters, indicates which frame types are allowed, etc. But as far as= I can tell the stipulation that IPv6 use QoSData and AC_BK is new and some= thing that ipwave introduces? Again, I'm not an expert on this topic and I = believe others in the 1609 WG have been discussing this with the ipwave lis= t. Regardless, this additional restriction does not violate 1609.3. 1609 WAVE does not recommend in particular RFC8064 to form semantically opa= que Interface Identifiers, right? [KS]: 1609 does not recommend anything like this, but on the other hand 160= 9 does not prohibit it either. 1609 does not generally speaking "recommend"= , rather it "specifies" and leaves all else up to the system designer/imple= menter/deployer. And as mentioned previously, 1609 allows any and all IETF = protocols to be implemented. Regardless, this recommendation does not viola= te anything in 1609.3. (and a few others). > 1609 WAVE includes a number of mechanisms that enable IPv6 networks to=20 > be configured. In addition to the WSA/WRA mechanism, 1609.3 allows any=20 > IETF protocols to be implemented, e.g., IETF RFC 4861, Neighbor=20 > Discovery for IP Version 6 (IPv6) (which is listed as a normative=20 > reference in 1609.3). Helpful would be some example use-cases that=20 > illustrate problems to be solved, and how ipwave will solve those=20 > problems (i.e., that 1609 WAVE does not already solve). There is a draft that describes some use-cases of IPv6 in vehicular networks: draft-ietf-ipwave-vehicular-networking-02 [KS]: Thanks for pointing me to that, lots of info there! I'll spend some t= ime reviewing that when I can. I think some parts of 1609 WAVE, in particular WRA, are not used in Europe. Whereas this IPv6-over-OCB draft is used the same wherever Internet is pres= ent (Europe, America, Continents). [KS]: 1609 went to great lengths to harmonize WSM and WSA frame formats wit= h ISO/ETSI standards, these harmonized frames are included in all of the -2= 016 revisions to 1609. So for example the 1609.3 WSA is interoperable with = the service advertisement used in Europe. See ISO 16460, and see also ETSI = TS 102 890-1. > My concern is that the IETF ipwave document may cause significant=20 > confusion among deployers, and possibly lead to a lack of=20 > interoperability. Thank you for the opportunity to comment, I look=20 > forward to the discussion. I would like to help with clarification. Let us discuss this. [KS]: Sounds good!=20 Alex >=20 >=20 >=20 > Best regards, >=20 > Kevin _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its From nobody Sat Mar 17 04:23: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 41B6E127863 for ; Sat, 17 Mar 2018 04:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMW2-63s-n_L for ; Sat, 17 Mar 2018 04:22:57 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A824126D3F for ; Sat, 17 Mar 2018 04:22:57 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w2HBMqQF047051; Sat, 17 Mar 2018 12:22:53 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E699A201FD0; Sat, 17 Mar 2018 12:22:52 +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 D6983200801; Sat, 17 Mar 2018 12:22:52 +0100 (CET) Received: from [132.166.84.56] ([132.166.84.56]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w2HBMqRk000577; Sat, 17 Mar 2018 12:22:52 +0100 To: Tijink Jasja Cc: Kevin Smith , "its@ietf.org" References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> From: Alexandre Petrescu Message-ID: Date: Sat, 17 Mar 2018 12:22:51 +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] ipwave - comments and concerns - 1609 WAVE, EPD - 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: Sat, 17 Mar 2018 11:22:59 -0000 Hello Jasja, Le 16/03/2018 à 19:02, Tijink Jasja a écrit : > Hello Alex, > > in addition to Kevin's points, I would like to mention that: > > 1. I welcome your proposal for the additional text that specifies > QoS. This is necessary for operation in Europe (the specification for > the access layer can be found in ETSI EN 302 663, where clause 4.6 > says that QoS shall be used). Noted. > 2. My understanding of the discussion below is that > draft-ietf-ipwave-ipv6-over-80211ocb-21 is "based on" IEEE 1609.3 in > that it is compliant with it (I didn't find any "violation of IEEE > 1609.3), and adds additional restrictions and /or specifications > (such a MTU size, AC_BK, RFC8064, etc.). In that sense > draft-ietf-ipwave-ipv6-over-80211ocb-21 is a profile of IEEE 1609.3. > I would suggest making that very clear, with a short > sentence/paragraph in draft-ietf-ipwave-ipv6-over-80211ocb-21 that > explains it to the reader. If you disagree, I would like to hear your > view on the relation of IEEE 1609.3 and > draft-ietf-ipwave-ipv6-over-80211ocb-21. I dont really disagree, just where to put it. The draft does refer to 1609.3, in Appendix C "aspects introduced by OCB to 802.11". The vehicular networking draft (draft-ietf-ipwave-vehicular-networking-01) also refers to it right at the beginning. IPv6-over-OCB sounds like an explanation. As such, I suggest we first write more precisely that "IPv6-over-OCB is a profile of 1609.3" and then put it into the vehicular networking draft. How could that be written? Alex From nobody Sat Mar 17 05:10: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 13E2112778E for ; Sat, 17 Mar 2018 05:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x95erLGF2Snk for ; Sat, 17 Mar 2018 05:10:15 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8CFA1270A3 for ; Sat, 17 Mar 2018 05:10:14 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w2HCAAhD004199; Sat, 17 Mar 2018 13:10:10 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E33C1201D89; Sat, 17 Mar 2018 13:10:10 +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 D2046201B5C; Sat, 17 Mar 2018 13:10:10 +0100 (CET) Received: from [132.166.84.56] ([132.166.84.56]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w2HCA7lZ015473; Sat, 17 Mar 2018 13:10:10 +0100 To: Kevin Smith Cc: "'Tijink Jasja'" , its@ietf.org References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> From: Alexandre Petrescu Message-ID: Date: Sat, 17 Mar 2018 13:10: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: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] FW: ipwave - comments and concerns - 1609 WAVE, EPD - 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: Sat, 17 Mar 2018 12:10:18 -0000 Le 16/03/2018 à 18:34, Kevin Smith a écrit : [...] > I suggest that in section 4.2.1 "Ethernet Adaptation Layer" we add > the following paragraph: > >> The IPv6 packet transmitted on 802.11-OCB MUST be immediately >> preceded by a Logical Link Control (LLC) header and an 802.11 >> header. In the LLC header, and in accordance with the EtherType >> Protocol Discrimination (EPD), the value of the Type field MUST be >> set to 0x86DD (IPv6). In the 802.11 header, the value of the >> Subtype sub-field in the Frame Control field MUST be set to 8 (i.e. >> 'QoS Data'); the value of the Traffic Identifier (TID) sub-field of >> the QoS Control field of the 802.11 header MUST be set to binary >> 001 (i.e. User Priority 'Background', QoS Access Category >> 'AC_BK'). >> >> In the Ethernet II header, the value of the Type field MUST be set >> to 0x86DD (IPv6). > > Do you agree with this text? > > [KS]: I agree with the part that addresses the LLC header. I don't > disagree with the part addressing the 802.11 header, I'm just not an > expert in this area and so defer to others. I believe that others in > the 1609 WG have been discussing this with the ipwave list? Noted. Others have discussed the QoS part and there seems to be agreement with that. >> I note that ipwave mentions EPD, but also SNAP and does not >> specify which method to use. > > I propose we remove this phrase: >> Other alternative views of layering are EtherType Protocol >> Discrimination (EPD), see Appendix E, and SNAP see [RFC1042]. > > Do you agree? > > [KS]: Yes. Noted. >> Moreover ipwave discusses an abstract "Ethernet Adaptation Layer" >> but does not specify a header format, and this further confuses >> the question for deployers - what should we implement? > > The Ethernet Adaptation Layer (more precisely 802.11-to-Ethernet AL) > is not so abstract, because it is widely implemented. This layer > does conversion between headers: at reception from the network it > transforms a .11/LLC header into an EthernetII header; reversely, at > sending it transforms an EthernetII header into a .11/LLC header. > This is shown in Figure 1. > > The EAL does not intend to specify a header format. The header > formats involved are the IEEE 802.11, LLC and EthernetII. The fields > in these headers are specified by IEEE. > > [KS]: I don't understand why the EAL is relevant to "Transmission of > IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the > Context of a Basic Service Set". If I want to write software that > sends IPv6 packets over 802.11 OCB, all I need to know is how to > construct the LLC sublayer header, etc. The EAL sounds like a > "bridge", and perhaps belongs in a separate document (and perhaps has > already been addressed in some existing document?) We wanted to have IPv6-over-OCB document that is minimal change from existing works: RFC 2464 IPv6-over-Ethernet and implementations. In implementations, that's how IPv6 works: whenever IPv6 stack wants to sit on a link layer (802.15.4, WiFi, LTE) it actually sits on an Adaptation Layer. Because IPv6 only knows Ethernet (RFC2464). Whenever a new link layer technology appears, people struggle to make it first look like Ethernet. Only then does IPv6 run easily on it. Because of that, I tend to agree it could makes sense to make an IPv6-over-802.11 document first (including EAL), and the OCB version after. The OCB version would be much smaller. At the same time, such document IPv6-over-802.11 does not exist. It could not be developped in the IPWAVE WG which is aiming at vehicle networking, not .11 in general. It would take so long to create a new IPv6-over-.11 document, and only then to advance the IPv6-over-OCB draft. An additional reason as to why it would take long is that the mapping of IPv6 fields on 802.11 fields is not straightforward at all. (QoS is one aspect, but there is also frag fields, security and more). > Regardless, including a description of the EAL does not violate > anything in 1609.3, as it is out of scope with 1609.3. Noted. > > Some *new comments* from my side: > > - ipwave 4.2.1 it states "An 'adaptation' layer is inserted between a > MAC layer and the Networking layer." This sounds like a requirement. > If I am developing a product that is only concerned with sending IPv6 > over OCB, and does not require "bridging", then how do I reconcile > this requirement? It is a requirement indeed. But the adaptation layer is already there, do not worry. If one develops a new product, one is likely to use existing kernels - they do include EAL, even though they dont call it so. If one develops from scratch (very rare), one would have to answer questions like how does Frag fields map between IPv6 and 802.11, security, and other very complicated questions. Agreement would be needed too. I think one will rather prefer too to rely on Ethernet (RFC2464), as so many other people did in the past. "Bridging": I do not know what you mean by 'bridging'? In linux bridging is a tool called 'brctl'. It bridges two distinct interfaces, e.g. an Ethernet interface to a WiFi interface. Here we would 'bridge' Ethernet and 802.11 on the same interface. It's not 'bridging', it's 'adaptation'. Worse: 'brctl' does not work when we want to 'bridge' a OCB interface to an Ethernet interface. I do not why. I guess the 802. groups will figure it out one day and fix it. But Ethernet Adaptation Layer (named 'bridging' by you?) works ok. > - ipwave 4.2 it states "IP packets are transmitted over 802.11-OCB > as standard Ethernet packets. As with all 802.11 frames, an Ethernet > adaptation layer MUST be used with 802.11-OCB as well." Again EAL is > stipulated as a requirement. And I'm not sure about the stipulation > that packets are transmitted as "standard Ethernet packets", is this > accurate? YEs. I verify it this way: Use available Wireshark tool on WiFi interface, enable IPv6 on the computer, and dump some IPv6 packets. They all have EthernetII headers, rather than LLC and 802.11 headers. Then capture the same in 'monitor' mode, or 'mon' interface in 802.11 OCB, and the .11/LLC headers will show instead. > Does this mean that 802.3 headers are included? The EthernetII headers (not 802.3 Ethernet, I believe different) are included in the processing during the execution of this EAL. But these EthernetII headers are not sent on the 802.11 air. > This is definitely not stipulated in 1609.3. Packets transmitted over > OCB by a WAVE device using 1609.3 are well formed IPv6 packets, but > not "Ethernet packets", i.e., no 802.3 headers are included. This > seems like an interoperability problem between ipwave and 1609 WAVE. The packets put on the air on 802.11-OCB links with the IPv6-over-OCB draft do not include EthernetII headers. SO I do not think there is an interop problem 1609 WAVE with IPv6-over-OCB draft. > >> 2. It is not clear that ipwave provides any functionality >> that 1609 WAVE does not already provide. > > Well, 1609 WAVE does not specify the conversion between .11/LLC > headers and EthernetII headers, right? > > [KS]: Correct it does not, as this topic is out of scope for 1609 > WAVE (e.g., we don't specify the other interfaces such as Ethernet > that may be present in the device). Also see my comments above > regarding the EAL. It is in scope here. Maybe 1609 document can refer to here. > 1609 WAVE does not specify the MTU size for IPv6, right? > > [KS]: No it does not. 802.11 (normative to 1609) specifies maximum > MSDU size as 2304 octets. For WSMP 1609.3 specifies a maximum MSDU > size of 2302 (allowing for the 2-octet LLC header), and a default > value of 1400. You are correct in that a MSDU size for IPv6 is not > specified explicitly, but I don't know if some other RFCs related to > IPv6 over 802.11 already do that? Regardless, stipulating a default > value of 1500 for MTU size does not violate anything in 1609.3. Noted. For explanation, the figure 1500 for MTU for IPv6-over-OCB comes from implementations inheriting from old Ethernet behaviour. We dont want to break that. Moreover, it is compatible with RFC8200 (IPv6) which requires the minimum MTU to be at least 1280bytes for all links supporting IPv6. IPv6 people are aware that many links do support more than 1500bytes MTU. I heard of 10000bytes for some core links. Yet the IPv6-over-foo for these links do not require the MTU 10000bytes. > > 1609 WAVE does not specify that IPv6 must be preceded by .11 QoSData > (not just .11 Data), and BACKGROUND, right? > > [KS]: Certainly 1609 does not. 1609 only restricts IPv6 packets to > the SCH (they are not allowed on the CCH). 802.11 specifies defaults > for all UP and AC parameters, indicates which frame types are > allowed, etc. But as far as I can tell the stipulation that IPv6 use > QoSData and AC_BK is new and something that ipwave introduces? It seems so. People agree with it. > Again, I'm not an expert on this topic and I believe others in the > 1609 WG have been discussing this with the ipwave list. Regardless, > this additional restriction does not violate 1609.3. > > 1609 WAVE does not recommend in particular RFC8064 to form > semantically opaque Interface Identifiers, right? > > [KS]: 1609 does not recommend anything like this, but on the other > hand 1609 does not prohibit it either. 1609 does not generally > speaking "recommend", rather it "specifies" and leaves all else up to > the system designer/implementer/deployer. And as mentioned > previously, 1609 allows any and all IETF protocols to be implemented. > Regardless, this recommendation does not violate anything in 1609.3. Noted. > > (and a few others). > >> 1609 WAVE includes a number of mechanisms that enable IPv6 networks >> to be configured. In addition to the WSA/WRA mechanism, 1609.3 >> allows any IETF protocols to be implemented, e.g., IETF RFC 4861, >> Neighbor Discovery for IP Version 6 (IPv6) (which is listed as a >> normative reference in 1609.3). Helpful would be some example >> use-cases that illustrate problems to be solved, and how ipwave >> will solve those problems (i.e., that 1609 WAVE does not already >> solve). > > There is a draft that describes some use-cases of IPv6 in vehicular > networks: draft-ietf-ipwave-vehicular-networking-02 > > [KS]: Thanks for pointing me to that, lots of info there! I'll spend > some time reviewing that when I can. > > I think some parts of 1609 WAVE, in particular WRA, are not used in > Europe. Whereas this IPv6-over-OCB draft is used the same wherever > Internet is present (Europe, America, Continents). > > [KS]: 1609 went to great lengths to harmonize WSM and WSA frame > formats with ISO/ETSI standards, these harmonized frames are included > in all of the -2016 revisions to 1609. So for example the 1609.3 WSA > is interoperable with the service advertisement used in Europe. See > ISO 16460, and see also ETSI TS 102 890-1. I agree harmonization is good and needed. In case that harmonization relies on IPv6 as specified at IETF, these are my comments to the ETSI document. Quickly skimming, it calls it "IPv6 routing advertisement". It is "IPv6 Router Advertisement". The 'default' route is used when no other route is available. The 'default' route typically gives access to the Internet, not to one particular server ("ITS-S": station). For particular servers, one may use RFC4191 instead, for "more specific routes" or, the routes known as 'host-based routes'. Thank you for the comments. Alex >> My concern is that the IETF ipwave document may cause significant >> confusion among deployers, and possibly lead to a lack of >> interoperability. Thank you for the opportunity to comment, I look >> forward to the discussion. > > I would like to help with clarification. Let us discuss this. > > [KS]: Sounds good! > > Alex > >> >> >> >> Best regards, >> >> Kevin > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > > From nobody Sat Mar 17 05:22: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 7909512D77E for ; Sat, 17 Mar 2018 05:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kapsch.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2h9MqQs-3dc0 for ; Sat, 17 Mar 2018 05:22:35 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0706.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1f::706]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 715CF127735 for ; Sat, 17 Mar 2018 05:22:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kapsch.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8UjskyT36LKRsYzegM/xsa59pv2eRU9tzpBKlxXheG4=; b=cxTygp9vVhmFFQ/UaEb9XEzNqj3r1SGzYhNKcAaqjm5kInDU1OvMBbM4tIKKYyvEeG1NpXucVZYs51FaMK6zYWjix4CJzuQ1fVhWCFgp2HjwT5lkcODOOcGmZGDxk6+CE9gNPkXQSeJBl46fNZTbSHcZ2DSR0KV6rjP06b50/Kk= Received: from AM0PR0302MB3380.eurprd03.prod.outlook.com (52.133.37.155) by AM0PR0302MB3186.eurprd03.prod.outlook.com (52.133.36.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.588.14; Sat, 17 Mar 2018 12:22:31 +0000 Received: from AM0PR0302MB3380.eurprd03.prod.outlook.com ([fe80::153a:2232:e7b7:7cb4]) by AM0PR0302MB3380.eurprd03.prod.outlook.com ([fe80::153a:2232:e7b7:7cb4%13]) with mapi id 15.20.0588.016; Sat, 17 Mar 2018 12:22:31 +0000 From: Tijink Jasja To: Alexandre Petrescu CC: Kevin Smith , "its@ietf.org" Thread-Topic: [ipwave] ipwave - comments and concerns - 1609 WAVE, EPD - towards resolution Thread-Index: AQGhOrR8o8b5YryKQCC/S9k90bJ5fwIDl0bIpCf3FSCAABQxgIABJyiAgAALp0A= Date: Sat, 17 Mar 2018 12:22:31 +0000 Message-ID: References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> In-Reply-To: Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jasja.Tijink@kapsch.net; x-originating-ip: [62.47.243.63] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM0PR0302MB3186; 7:ZZ6D4DxNnTW9V5CLwoeoMfYBK2KnTOykkoZ5oykNKEYy0ZdkYsaN7MUwqMVvNFelvgWKfr/XO5w8Gnq7V4nOvhvFIVGJZWnALHEdIojoQT2561YMOs56KAQ/Be5MsUSm3AjmXETdIk1nE27TLv807moOZ/WtKPcgZA+ZOaK9LP906/3XyT16oascMnKUQkfYcREKMfmf+NilG1MQmm89FjxKLrWFSlMFnuSl+HKhGGmseVnhxWiKPsjj3P9Mh6PF x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 850f173c-30d2-405a-5bd3-08d58c01c18e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:AM0PR0302MB3186; x-ms-traffictypediagnostic: AM0PR0302MB3186: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(79046362386883)(85827821059158); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231221)(944501244)(52105095)(10201501046)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:AM0PR0302MB3186; BCL:0; PCL:0; RULEID:; SRVR:AM0PR0302MB3186; x-forefront-prvs: 06141B80DC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(39840400004)(376002)(346002)(366004)(396003)(39380400002)(189003)(199004)(478600001)(6916009)(105586002)(3660700001)(74316002)(305945005)(316002)(7736002)(99286004)(8666007)(72206003)(25786009)(2900100001)(5660300001)(6436002)(6116002)(53936002)(3846002)(66066001)(54906003)(7696005)(106356001)(55016002)(9686003)(33656002)(6506007)(39060400002)(3280700002)(186003)(5250100002)(86362001)(561944003)(59450400001)(4326008)(14454004)(26005)(102836004)(2950100002)(8676002)(81166006)(76176011)(68736007)(8936002)(2906002)(97736004)(81156014)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR0302MB3186; H:AM0PR0302MB3380.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: kapsch.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: bBubiZzFtNnvOZ7JqeGcobTrXDdl2iBSb6MJGTEc6oSex9r+szRRoa5zimLnHc3kAy8t9Cx3AscHTWsSw05UdunEIHnAmkLXxIsA96wzkmTzofCT4SUAf8BC5pMvZ4wICCyEZJyGfXBsvTCP8jBZ1nRhkNnM9yLqDMxieyDUMgAz9CKWRJm7E1VypwxoX3gObUzPjwLlfRotEioTPAnG7eQ+plW2h+fOVI7wdRxp2nZo/EHvIfROd4pSxSI3zsVBbQe1riXtiRDrKVMx0RX6FACzYlkraZtL5flIZPtdao7fkf5ryEjXVzHhwPbF+AYUewKXGzTVzYkhgMyKP3JcxA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: kapsch.net X-MS-Exchange-CrossTenant-Network-Message-Id: 850f173c-30d2-405a-5bd3-08d58c01c18e X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2018 12:22:31.1887 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5f9ce527-7e3e-4e83-a8a4-b6c848f85ab5 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR0302MB3186 Archived-At: Subject: Re: [ipwave] ipwave - comments and concerns - 1609 WAVE, EPD - 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: Sat, 17 Mar 2018 12:22:37 -0000 SGVsbG8gQWxleCwNCg0KQ2FuIHdlIHB1dCBzb21ldGhpbmcgYXQgdGhlIGJlZ2lubmluZyBvZiBk cmFmdC1pZXRmLWlwd2F2ZS1pcHY2LW92ZXItODAyMTFvY2ItMjEsIG1heWJlIGluIHRoZSBpbnRy b2R1Y3Rpb24/DQpJIHN1Z2dlc3Qgc29tZSBsYW5ndWFnZSBsaWtlIHRoZSBmb2xsb3dpbmc6DQoN ClRoaXMgZG9jdW1lbnQgaXMgYSBwcm9maWxlIGJhc2VkIG9uIElFRUUgMTYwOS4zOiBpdCBpbnRy b2R1Y2VzIGFkZGl0aW9uYWwgcmVxdWlyZW1lbnRzIGFuZCBzcGVjaWZpY2F0aW9ucyB0aGF0IGRv IG5vdCB2aW9sYXRlIHRoYXQgYmFzZSBzdGFuZGFyZC4NCg0KUmVnYXJkcyBKYXNqYQ0KDQoNCi0t LS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0NClZvbjogQWxleGFuZHJlIFBldHJlc2N1 IFttYWlsdG86YWxleGFuZHJlLnBldHJlc2N1QGdtYWlsLmNvbV0gDQpHZXNlbmRldDogU2Ftc3Rh ZywgMTcuIE3DpHJ6IDIwMTggMTI6MjMNCkFuOiBUaWppbmsgSmFzamEgPEphc2phLlRpamlua0Br YXBzY2gubmV0Pg0KQ2M6IEtldmluIFNtaXRoIDxrZXZpbi5zLnNtaXRoQGNveC5uZXQ+OyBpdHNA aWV0Zi5vcmcNCkJldHJlZmY6IFJlOiBbaXB3YXZlXSBpcHdhdmUgLSBjb21tZW50cyBhbmQgY29u Y2VybnMgLSAxNjA5IFdBVkUsIEVQRCAtIHRvd2FyZHMgcmVzb2x1dGlvbg0KDQpIZWxsbyBKYXNq YSwNCg0KTGUgMTYvMDMvMjAxOCDDoCAxOTowMiwgVGlqaW5rIEphc2phIGEgw6ljcml0IDoNCj4g SGVsbG8gQWxleCwNCj4gDQo+IGluIGFkZGl0aW9uIHRvIEtldmluJ3MgcG9pbnRzLCBJICB3b3Vs ZCBsaWtlIHRvIG1lbnRpb24gdGhhdDoNCj4gDQo+IDEuIEkgd2VsY29tZSB5b3VyIHByb3Bvc2Fs IGZvciB0aGUgYWRkaXRpb25hbCB0ZXh0IHRoYXQgc3BlY2lmaWVzIFFvUy4gDQo+IFRoaXMgaXMg bmVjZXNzYXJ5IGZvciBvcGVyYXRpb24gaW4gRXVyb3BlICh0aGUgc3BlY2lmaWNhdGlvbiBmb3Ig dGhlIA0KPiBhY2Nlc3MgbGF5ZXIgY2FuIGJlIGZvdW5kIGluIEVUU0kgRU4gMzAyIDY2Mywgd2hl cmUgY2xhdXNlIDQuNiBzYXlzIA0KPiB0aGF0IFFvUyBzaGFsbCBiZSB1c2VkKS4NCg0KTm90ZWQu DQoNCj4gMi4gTXkgdW5kZXJzdGFuZGluZyBvZiB0aGUgZGlzY3Vzc2lvbiBiZWxvdyBpcyB0aGF0 DQo+IGRyYWZ0LWlldGYtaXB3YXZlLWlwdjYtb3Zlci04MDIxMW9jYi0yMSBpcyAiYmFzZWQgb24i IElFRUUgMTYwOS4zIGluICANCj4gdGhhdCBpdCBpcyBjb21wbGlhbnQgd2l0aCBpdCAoSSBkaWRu J3QgZmluZCBhbnkgInZpb2xhdGlvbiBvZiBJRUVFIA0KPiAxNjA5LjMpLCBhbmQgYWRkcyBhZGRp dGlvbmFsIHJlc3RyaWN0aW9ucyBhbmQgL29yIHNwZWNpZmljYXRpb25zIChzdWNoIA0KPiBhIE1U VSBzaXplLCBBQ19CSywgUkZDODA2NCwgZXRjLikuIEluIHRoYXQgc2Vuc2UNCj4gZHJhZnQtaWV0 Zi1pcHdhdmUtaXB2Ni1vdmVyLTgwMjExb2NiLTIxIGlzIGEgcHJvZmlsZSBvZiBJRUVFIDE2MDku My4NCj4gIEkgd291bGQgc3VnZ2VzdCBtYWtpbmcgdGhhdCB2ZXJ5IGNsZWFyLCB3aXRoIGEgc2hv cnQgDQo+IHNlbnRlbmNlL3BhcmFncmFwaCBpbiBkcmFmdC1pZXRmLWlwd2F2ZS1pcHY2LW92ZXIt ODAyMTFvY2ItMjEgdGhhdCANCj4gZXhwbGFpbnMgaXQgdG8gdGhlIHJlYWRlci4gSWYgeW91IGRp c2FncmVlLCBJIHdvdWxkIGxpa2UgdG8gaGVhciB5b3VyIA0KPiB2aWV3IG9uIHRoZSByZWxhdGlv biBvZiBJRUVFIDE2MDkuMyBhbmQgDQo+IGRyYWZ0LWlldGYtaXB3YXZlLWlwdjYtb3Zlci04MDIx MW9jYi0yMS4NCg0KSSBkb250IHJlYWxseSBkaXNhZ3JlZSwganVzdCB3aGVyZSB0byBwdXQgaXQu DQoNClRoZSBkcmFmdCBkb2VzIHJlZmVyIHRvIDE2MDkuMywgaW4gQXBwZW5kaXggQyAiYXNwZWN0 cyBpbnRyb2R1Y2VkIGJ5IE9DQiB0byA4MDIuMTEiLiAgVGhlIHZlaGljdWxhciBuZXR3b3JraW5n IGRyYWZ0DQooZHJhZnQtaWV0Zi1pcHdhdmUtdmVoaWN1bGFyLW5ldHdvcmtpbmctMDEpIGFsc28g cmVmZXJzIHRvIGl0IHJpZ2h0IGF0IHRoZSBiZWdpbm5pbmcuDQoNCklQdjYtb3Zlci1PQ0Igc291 bmRzIGxpa2UgYW4gZXhwbGFuYXRpb24uICBBcyBzdWNoLCBJIHN1Z2dlc3Qgd2UgZmlyc3Qgd3Jp dGUgbW9yZSBwcmVjaXNlbHkgdGhhdCAiSVB2Ni1vdmVyLU9DQiBpcyBhIHByb2ZpbGUgb2YgMTYw OS4zIiBhbmQgdGhlbiBwdXQgaXQgaW50byB0aGUgdmVoaWN1bGFyIG5ldHdvcmtpbmcgZHJhZnQu DQoNCkhvdyBjb3VsZCB0aGF0IGJlIHdyaXR0ZW4/DQoNCkFsZXgNCg== From nobody Sat Mar 17 05:37: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 592B912785F for ; Sat, 17 Mar 2018 05:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_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=kapsch.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4YEf3HBdoNf for ; Sat, 17 Mar 2018 05:37:05 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0094.outbound.protection.outlook.com [104.47.0.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC47C12778E for ; Sat, 17 Mar 2018 05:37:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kapsch.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XPiXAlWytE2l0sA+Hmjs6PTKrE0+Axtar7bE7U0LMJM=; b=wpczaR/Fk8dh2xLj/oNxt3/GPjYxct6csgHa3sGYX9EENeJT++z2LrfvA97zrxmtzClvN11X5FbhxdQaYoRgjfIIgSlIdhPCW1/mo/R8XSXJxR6iNqfH5V6GAk+w1LBk4jHjaCnirRQdPQd4WN/LqNSWZJ/X69hdz27E+wCKj/U= Received: from AM0PR0302MB3380.eurprd03.prod.outlook.com (52.133.37.155) by AM0PR0302MB3188.eurprd03.prod.outlook.com (52.133.36.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.588.14; Sat, 17 Mar 2018 12:37:01 +0000 Received: from AM0PR0302MB3380.eurprd03.prod.outlook.com ([fe80::153a:2232:e7b7:7cb4]) by AM0PR0302MB3380.eurprd03.prod.outlook.com ([fe80::153a:2232:e7b7:7cb4%13]) with mapi id 15.20.0588.016; Sat, 17 Mar 2018 12:37:01 +0000 From: Tijink Jasja To: Alexandre Petrescu , Kevin Smith CC: "its@ietf.org" Thread-Topic: FW: [ipwave] ipwave - comments and concerns - 1609 WAVE, EPD - towards resolution Thread-Index: AQGhOrR8o8b5YryKQCC/S9k90bJ5fwIDl0bIpCf3FSCAAUiOgIAAA9kA Date: Sat, 17 Mar 2018 12:37:01 +0000 Message-ID: References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> In-Reply-To: Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jasja.Tijink@kapsch.net; x-originating-ip: [62.47.243.63] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM0PR0302MB3188; 7:oT9GWQZu4sMSsnNJVy5tNJ4SrVl3/NTLYnZxUDPPUmsO7OUGIH6q0qV8eEKaHMZPFH/XmMnAwkHMJMw66ELyDnpU6Amj1l0hKMBeNjowfGh5lYCBQWeYbtotBh8hhe4DlvLj+ts3MsB7IIieRfdFfYaQTy3MPqdKWUravoGvI5AarjqxGVziJ8QgN5dw7l8rRa05qRnAawAr5GIddovoB6tiN6tGIp0Ek8tU3B4zHWdr6bViAE3KUUPeqi9bf1XO x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: ed84e2f8-9de8-4c69-47ab-08d58c03c86e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:AM0PR0302MB3188; x-ms-traffictypediagnostic: AM0PR0302MB3188: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(79046362386883)(192374486261705)(85827821059158); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3231221)(944501244)(52105095)(3002001)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:AM0PR0302MB3188; BCL:0; PCL:0; RULEID:; SRVR:AM0PR0302MB3188; x-forefront-prvs: 06141B80DC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(396003)(346002)(376002)(39840400004)(39380400002)(366004)(189003)(199004)(4326008)(25786009)(99286004)(8676002)(66066001)(81156014)(14454004)(81166006)(7696005)(8936002)(305945005)(7736002)(76176011)(5660300001)(74316002)(105586002)(110136005)(39060400002)(345774005)(3660700001)(59450400001)(6506007)(68736007)(3280700002)(53936002)(6306002)(9686003)(72206003)(55016002)(97736004)(316002)(186003)(102836004)(86362001)(966005)(2950100002)(2906002)(5250100002)(33656002)(26005)(8666007)(478600001)(2900100001)(6436002)(6116002)(106356001)(3846002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR0302MB3188; H:AM0PR0302MB3380.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: kapsch.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: oDFYXO4MoEH8SIVr0/xIv/Ycp4cfocuORHyy7ouepn0GoXj+CspOGuVey2veyv1gv7eC98C/LgryUu27DtQOUbZydP19J1jwVWDqweoeoVBfpwNpRlHmCiEOi33JuBsqL+PFfWNslFP2akyp8xdmo65VI431pMmWcK0wRjfKXDi2A/ZmNw9THp2lBnASSXynQVvQNZtj/GxCxP1vFrsHw7uE247aoItmeDaCS+KgOu3X2JIovlaI5uVnowR9it+eXY5qf2K9IIBU5l1mPSbpXlC9oWcS+X9/E+4zQFt8CKf/OM7CBr+gdcerzMMP3m5qfdDx/VqZN1ygh0/bSw432A== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: kapsch.net X-MS-Exchange-CrossTenant-Network-Message-Id: ed84e2f8-9de8-4c69-47ab-08d58c03c86e X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2018 12:37:01.6379 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5f9ce527-7e3e-4e83-a8a4-b6c848f85ab5 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR0302MB3188 Archived-At: Subject: Re: [ipwave] FW: ipwave - comments and concerns - 1609 WAVE, EPD - 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: Sat, 17 Mar 2018 12:37:08 -0000 SGkgQWxleCwNCg0Kb24gdGhlIEVBTCB0b3BpYy4gVGFrZSBhZ2FpbiB0aGUgZm9sbG93aW5nIHRl eHQgZnJvbSB0aGUgZHJhZnQ6DQoNCiIgSVAgcGFja2V0cyBhcmUgdHJhbnNtaXR0ZWQgb3ZlciA4 MDIuMTEtT0NCIGFzIHN0YW5kYXJkIEV0aGVybmV0DQogICBwYWNrZXRzLiAgQXMgd2l0aCBhbGwg ODAyLjExIGZyYW1lcywgYW4gRXRoZXJuZXQgYWRhcHRhdGlvbiBsYXllcg0KICAgTVVTVCBiZSB1 c2VkIHdpdGggODAyLjExLU9DQiBhcyB3ZWxsLiINCg0KSSB1bmRlcnN0YW5kIHRoZSBzZWNvbmQg c2VudGVuY2UgaXMgYSByZXF1aXJlbWVudCB5b3UgcHV0IHRvIGltcGxlbWVudGF0aW9ucyB0aGF0 IGZlYXR1cmUgYW4gZXRoZXJuZXQgaW50ZXJmYWNlIGFuZCBhbiA4MDIuMTEgaW50ZXJmYWNlLiAN Cg0KQnV0IHRoZSBmaXJzdCBzZW50ZW5jZTogdGhhdCBvbmUgc2VlbXMgbm90IHRydWUgdG8gbWUg YWNjb3JkaW5nIHRvIHdoYXQgeW91IHJlcG9ydCBvZiB5b3VyIG93biB0ZXN0cyAtIDgwMi4xMSBw YWNrZXRzIGRvIG5vdCBoYXZlIGV0aGVybmV0IGhlYWRlcnMuIFNvIHRoZSBmaXJzdCBzZW50ZW5j ZSBpcyBpbmNvcnJlY3QsIHJpZ2h0PyBPciBkbyBJIHNpbXBseSBtaXN1bmRlcnN0YW5kIGl0IGFu ZCB3aGF0IHlvdSB3YW50IHRvIHNheSBpczogDQoNCiJJUCBwYWNrZXRzIGFyZSB0cmFuc21pdHRl ZCBvdmVyIDgwMi4xMS1PQ0IgYXMgb3ZlciBzdGFuZGFyZCBFdGhlcm5ldDogIGFzIHdpdGggYWxs IDgwMi4xMSBmcmFtZXMsIGFuIEV0aGVybmV0IGFkYXB0YXRpb24gbGF5ZXIgIE1VU1QgYmUgdXNl ZCB3aXRoIDgwMi4xMS1PQ0IgYXMgd2VsbC4iDQoNCg0KUmVnYXJkcyBKYXNqYQ0KDQoNCi0tLS0t VXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0NClZvbjogQWxleGFuZHJlIFBldHJlc2N1IFtt YWlsdG86YWxleGFuZHJlLnBldHJlc2N1QGdtYWlsLmNvbV0gDQpHZXNlbmRldDogU2Ftc3RhZywg MTcuIE3DpHJ6IDIwMTggMTM6MTANCkFuOiBLZXZpbiBTbWl0aCA8a2V2aW4ucy5zbWl0aEBjb3gu bmV0Pg0KQ2M6IFRpamluayBKYXNqYSA8SmFzamEuVGlqaW5rQGthcHNjaC5uZXQ+OyBpdHNAaWV0 Zi5vcmcNCkJldHJlZmY6IFJlOiBGVzogW2lwd2F2ZV0gaXB3YXZlIC0gY29tbWVudHMgYW5kIGNv bmNlcm5zIC0gMTYwOSBXQVZFLCBFUEQgLSB0b3dhcmRzIHJlc29sdXRpb24NCg0KDQpMZSAxNi8w My8yMDE4IMOgIDE4OjM0LCBLZXZpbiBTbWl0aCBhIMOpY3JpdCA6DQpbLi4uXQ0KDQo+IEkgc3Vn Z2VzdCB0aGF0IGluIHNlY3Rpb24gNC4yLjEgIkV0aGVybmV0IEFkYXB0YXRpb24gTGF5ZXIiIHdl IGFkZCB0aGUgDQo+IGZvbGxvd2luZyBwYXJhZ3JhcGg6DQo+IA0KPj4gVGhlIElQdjYgcGFja2V0 IHRyYW5zbWl0dGVkIG9uIDgwMi4xMS1PQ0IgTVVTVCBiZSBpbW1lZGlhdGVseSANCj4+IHByZWNl ZGVkIGJ5IGEgTG9naWNhbCBMaW5rIENvbnRyb2wgKExMQykgaGVhZGVyIGFuZCBhbiA4MDIuMTEg aGVhZGVyLiANCj4+IEluIHRoZSBMTEMgaGVhZGVyLCBhbmQgaW4gYWNjb3JkYW5jZSB3aXRoIHRo ZSBFdGhlclR5cGUgUHJvdG9jb2wgDQo+PiBEaXNjcmltaW5hdGlvbiAoRVBEKSwgdGhlIHZhbHVl IG9mIHRoZSBUeXBlIGZpZWxkIE1VU1QgYmUgIHNldCB0byANCj4+IDB4ODZERCAoSVB2NikuICBJ biB0aGUgODAyLjExIGhlYWRlciwgdGhlIHZhbHVlIG9mIHRoZSBTdWJ0eXBlIA0KPj4gc3ViLWZp ZWxkIGluIHRoZSBGcmFtZSBDb250cm9sIGZpZWxkIE1VU1QgYmUgc2V0IHRvIDggKGkuZS4NCj4+ ICdRb1MgRGF0YScpOyB0aGUgdmFsdWUgb2YgdGhlIFRyYWZmaWMgSWRlbnRpZmllciAoVElEKSBz dWItZmllbGQgb2YgDQo+PiB0aGUgUW9TIENvbnRyb2wgZmllbGQgb2YgdGhlIDgwMi4xMSBoZWFk ZXIgTVVTVCBiZSBzZXQgdG8gYmluYXJ5DQo+PiAwMDEgKGkuZS4gVXNlciBQcmlvcml0eSAnQmFj a2dyb3VuZCcsIFFvUyBBY2Nlc3MgQ2F0ZWdvcnkgJ0FDX0JLJykuDQo+PiANCj4+IEluIHRoZSBF dGhlcm5ldCBJSSBoZWFkZXIsIHRoZSB2YWx1ZSBvZiB0aGUgVHlwZSBmaWVsZCBNVVNUIGJlIHNl dCAgDQo+PiB0byAweDg2REQgKElQdjYpLg0KPiANCj4gRG8geW91IGFncmVlIHdpdGggdGhpcyB0 ZXh0Pw0KPiANCj4gW0tTXTogSSBhZ3JlZSB3aXRoIHRoZSBwYXJ0IHRoYXQgYWRkcmVzc2VzIHRo ZSBMTEMgaGVhZGVyLiBJIGRvbid0IA0KPiBkaXNhZ3JlZSB3aXRoIHRoZSBwYXJ0IGFkZHJlc3Np bmcgdGhlIDgwMi4xMSBoZWFkZXIsIEknbSBqdXN0IG5vdCBhbiAgDQo+IGV4cGVydCBpbiB0aGlz IGFyZWEgYW5kIHNvIGRlZmVyIHRvIG90aGVycy4gSSBiZWxpZXZlIHRoYXQgb3RoZXJzIGluICAN Cj4gdGhlIDE2MDkgV0cgaGF2ZSBiZWVuIGRpc2N1c3NpbmcgdGhpcyB3aXRoIHRoZSBpcHdhdmUg bGlzdD8NCg0KTm90ZWQuDQoNCk90aGVycyBoYXZlIGRpc2N1c3NlZCB0aGUgUW9TIHBhcnQgYW5k IHRoZXJlIHNlZW1zIHRvIGJlIGFncmVlbWVudCB3aXRoIHRoYXQuDQoNCj4+IEkgbm90ZSB0aGF0 IGlwd2F2ZSBtZW50aW9ucyBFUEQsIGJ1dCBhbHNvIFNOQVAgYW5kIGRvZXMgbm90IHNwZWNpZnkg DQo+PiB3aGljaCBtZXRob2QgdG8gdXNlLg0KPiANCj4gSSBwcm9wb3NlIHdlIHJlbW92ZSB0aGlz IHBocmFzZToNCj4+IE90aGVyIGFsdGVybmF0aXZlIHZpZXdzIG9mIGxheWVyaW5nIGFyZSBFdGhl clR5cGUgUHJvdG9jb2wgDQo+PiBEaXNjcmltaW5hdGlvbiAoRVBEKSwgc2VlIEFwcGVuZGl4IEUs IGFuZCBTTkFQIHNlZSBbUkZDMTA0Ml0uDQo+IA0KPiBEbyB5b3UgYWdyZWU/DQo+IA0KPiBbS1Nd OiBZZXMuDQoNCk5vdGVkLg0KDQo+PiBNb3Jlb3ZlciBpcHdhdmUgZGlzY3Vzc2VzIGFuIGFic3Ry YWN0ICJFdGhlcm5ldCBBZGFwdGF0aW9uIExheWVyIiANCj4+IGJ1dCBkb2VzIG5vdCBzcGVjaWZ5 IGEgaGVhZGVyIGZvcm1hdCwgYW5kIHRoaXMgZnVydGhlciBjb25mdXNlcyB0aGUgDQo+PiBxdWVz dGlvbiBmb3IgZGVwbG95ZXJzIC0gd2hhdCBzaG91bGQgd2UgaW1wbGVtZW50Pw0KPiANCj4gVGhl IEV0aGVybmV0IEFkYXB0YXRpb24gTGF5ZXIgKG1vcmUgcHJlY2lzZWx5IDgwMi4xMS10by1FdGhl cm5ldCBBTCkgIA0KPiBpcyBub3Qgc28gYWJzdHJhY3QsIGJlY2F1c2UgaXQgaXMgd2lkZWx5IGlt cGxlbWVudGVkLiBUaGlzIGxheWVyIGRvZXMgDQo+IGNvbnZlcnNpb24gYmV0d2VlbiBoZWFkZXJz OiBhdCByZWNlcHRpb24gZnJvbSB0aGUgbmV0d29yayBpdCANCj4gdHJhbnNmb3JtcyBhIC4xMS9M TEMgaGVhZGVyIGludG8gYW4gRXRoZXJuZXRJSSBoZWFkZXI7IHJldmVyc2VseSwgYXQgIA0KPiBz ZW5kaW5nIGl0IHRyYW5zZm9ybXMgYW4gRXRoZXJuZXRJSSBoZWFkZXIgaW50byBhIC4xMS9MTEMg aGVhZGVyLg0KPiBUaGlzIGlzIHNob3duIGluIEZpZ3VyZSAxLg0KPiANCj4gVGhlIEVBTCBkb2Vz IG5vdCBpbnRlbmQgdG8gc3BlY2lmeSBhIGhlYWRlciBmb3JtYXQuIFRoZSBoZWFkZXIgZm9ybWF0 cyANCj4gaW52b2x2ZWQgYXJlIHRoZSBJRUVFIDgwMi4xMSwgTExDIGFuZCBFdGhlcm5ldElJLiBU aGUgZmllbGRzICBpbiB0aGVzZSANCj4gaGVhZGVycyBhcmUgc3BlY2lmaWVkIGJ5IElFRUUuDQo+ IA0KPiBbS1NdOiBJIGRvbid0IHVuZGVyc3RhbmQgd2h5IHRoZSBFQUwgaXMgcmVsZXZhbnQgdG8g IlRyYW5zbWlzc2lvbiBvZg0KPiAgSVB2NiBQYWNrZXRzIG92ZXIgSUVFRSA4MDIuMTEgTmV0d29y a3Mgb3BlcmF0aW5nIGluIG1vZGUgT3V0c2lkZSB0aGUgIA0KPiBDb250ZXh0IG9mIGEgQmFzaWMg U2VydmljZSBTZXQiLiBJZiBJIHdhbnQgdG8gd3JpdGUgc29mdHdhcmUgdGhhdCANCj4gc2VuZHMg SVB2NiBwYWNrZXRzIG92ZXIgODAyLjExIE9DQiwgYWxsIEkgbmVlZCB0byBrbm93IGlzIGhvdyB0 byANCj4gY29uc3RydWN0IHRoZSBMTEMgc3VibGF5ZXIgaGVhZGVyLCBldGMuIFRoZSBFQUwgc291 bmRzIGxpa2UgYSANCj4gImJyaWRnZSIsIGFuZCBwZXJoYXBzIGJlbG9uZ3MgaW4gYSBzZXBhcmF0 ZSBkb2N1bWVudCAoYW5kIHBlcmhhcHMgaGFzIA0KPiBhbHJlYWR5IGJlZW4gYWRkcmVzc2VkIGlu IHNvbWUgZXhpc3RpbmcgZG9jdW1lbnQ/KQ0KDQpXZSB3YW50ZWQgdG8gaGF2ZSBJUHY2LW92ZXIt T0NCIGRvY3VtZW50IHRoYXQgaXMgbWluaW1hbCBjaGFuZ2UgZnJvbSBleGlzdGluZyB3b3Jrczog UkZDIDI0NjQgSVB2Ni1vdmVyLUV0aGVybmV0IGFuZCBpbXBsZW1lbnRhdGlvbnMuDQoNCkluIGlt cGxlbWVudGF0aW9ucywgdGhhdCdzIGhvdyBJUHY2IHdvcmtzOiB3aGVuZXZlciBJUHY2IHN0YWNr IHdhbnRzIHRvIHNpdCBvbiBhIGxpbmsgbGF5ZXIgKDgwMi4xNS40LCBXaUZpLCBMVEUpIGl0IGFj dHVhbGx5IHNpdHMgb24gYW4gQWRhcHRhdGlvbiBMYXllci4gIEJlY2F1c2UgSVB2NiBvbmx5IGtu b3dzIEV0aGVybmV0IChSRkMyNDY0KS4NCg0KV2hlbmV2ZXIgYSBuZXcgbGluayBsYXllciB0ZWNo bm9sb2d5IGFwcGVhcnMsIHBlb3BsZSBzdHJ1Z2dsZSB0byBtYWtlIGl0IGZpcnN0IGxvb2sgbGlr ZSBFdGhlcm5ldC4gIE9ubHkgdGhlbiBkb2VzIElQdjYgcnVuIGVhc2lseSBvbiBpdC4NCg0KQmVj YXVzZSBvZiB0aGF0LCBJIHRlbmQgdG8gYWdyZWUgaXQgY291bGQgbWFrZXMgc2Vuc2UgdG8gbWFr ZSBhbg0KSVB2Ni1vdmVyLTgwMi4xMSBkb2N1bWVudCBmaXJzdCAoaW5jbHVkaW5nIEVBTCksIGFu ZCB0aGUgT0NCIHZlcnNpb24NCmFmdGVyLiAgIFRoZSBPQ0IgdmVyc2lvbiB3b3VsZCBiZSBtdWNo IHNtYWxsZXIuDQoNCkF0IHRoZSBzYW1lIHRpbWUsIHN1Y2ggZG9jdW1lbnQgSVB2Ni1vdmVyLTgw Mi4xMSBkb2VzIG5vdCBleGlzdC4gIEl0IGNvdWxkIG5vdCBiZSBkZXZlbG9wcGVkIGluIHRoZSBJ UFdBVkUgV0cgd2hpY2ggaXMgYWltaW5nIGF0IHZlaGljbGUgbmV0d29ya2luZywgbm90IC4xMSBp biBnZW5lcmFsLg0KDQpJdCB3b3VsZCB0YWtlIHNvIGxvbmcgdG8gY3JlYXRlIGEgbmV3IElQdjYt b3Zlci0uMTEgZG9jdW1lbnQsIGFuZCBvbmx5IHRoZW4gdG8gYWR2YW5jZSB0aGUgSVB2Ni1vdmVy LU9DQiBkcmFmdC4NCg0KQW4gYWRkaXRpb25hbCByZWFzb24gYXMgdG8gd2h5IGl0IHdvdWxkIHRh a2UgbG9uZyBpcyB0aGF0IHRoZSBtYXBwaW5nIG9mDQpJUHY2IGZpZWxkcyBvbiA4MDIuMTEgZmll bGRzIGlzIG5vdCBzdHJhaWdodGZvcndhcmQgYXQgYWxsLiAgKFFvUyBpcyBvbmUgYXNwZWN0LCBi dXQgdGhlcmUgaXMgYWxzbyBmcmFnIGZpZWxkcywgc2VjdXJpdHkgYW5kIG1vcmUpLg0KDQo+IFJl Z2FyZGxlc3MsIGluY2x1ZGluZyBhIGRlc2NyaXB0aW9uIG9mIHRoZSBFQUwgZG9lcyBub3Qgdmlv bGF0ZSANCj4gYW55dGhpbmcgaW4gMTYwOS4zLCBhcyBpdCBpcyBvdXQgb2Ygc2NvcGUgd2l0aCAx NjA5LjMuDQoNCk5vdGVkLg0KDQo+IA0KPiBTb21lICpuZXcgY29tbWVudHMqIGZyb20gbXkgc2lk ZToNCj4gDQo+IC0gaXB3YXZlIDQuMi4xIGl0IHN0YXRlcyAiQW4gJ2FkYXB0YXRpb24nIGxheWVy IGlzIGluc2VydGVkIGJldHdlZW4gYSANCj4gTUFDIGxheWVyIGFuZCB0aGUgTmV0d29ya2luZyBs YXllci4iIFRoaXMgc291bmRzIGxpa2UgYSByZXF1aXJlbWVudC4NCj4gSWYgSSBhbSBkZXZlbG9w aW5nIGEgcHJvZHVjdCB0aGF0IGlzIG9ubHkgY29uY2VybmVkIHdpdGggc2VuZGluZyBJUHY2IA0K PiBvdmVyIE9DQiwgYW5kIGRvZXMgbm90IHJlcXVpcmUgImJyaWRnaW5nIiwgdGhlbiBob3cgZG8g SSByZWNvbmNpbGUgDQo+IHRoaXMgcmVxdWlyZW1lbnQ/DQoNCkl0IGlzIGEgcmVxdWlyZW1lbnQg aW5kZWVkLiAgQnV0IHRoZSBhZGFwdGF0aW9uIGxheWVyIGlzIGFscmVhZHkgdGhlcmUsIGRvIG5v dCB3b3JyeS4NCg0KSWYgb25lIGRldmVsb3BzIGEgbmV3IHByb2R1Y3QsIG9uZSBpcyBsaWtlbHkg dG8gdXNlIGV4aXN0aW5nIGtlcm5lbHMgLSB0aGV5IGRvIGluY2x1ZGUgRUFMLCBldmVuIHRob3Vn aCB0aGV5IGRvbnQgY2FsbCBpdCBzby4NCg0KSWYgb25lIGRldmVsb3BzIGZyb20gc2NyYXRjaCAo dmVyeSByYXJlKSwgb25lIHdvdWxkIGhhdmUgdG8gYW5zd2VyIHF1ZXN0aW9ucyBsaWtlIGhvdyBk b2VzIEZyYWcgZmllbGRzIG1hcCBiZXR3ZWVuIElQdjYgYW5kIDgwMi4xMSwgc2VjdXJpdHksIGFu ZCBvdGhlciB2ZXJ5IGNvbXBsaWNhdGVkIHF1ZXN0aW9ucy4gIEFncmVlbWVudCB3b3VsZCBiZQ0K bmVlZGVkIHRvby4gICBJIHRoaW5rIG9uZSB3aWxsIHJhdGhlciBwcmVmZXIgdG9vIHRvIHJlbHkg b24gRXRoZXJuZXQNCihSRkMyNDY0KSwgYXMgc28gbWFueSBvdGhlciBwZW9wbGUgZGlkIGluIHRo ZSBwYXN0Lg0KDQoiQnJpZGdpbmciOiBJIGRvIG5vdCBrbm93IHdoYXQgeW91IG1lYW4gYnkgJ2Jy aWRnaW5nJz8gIEluIGxpbnV4IGJyaWRnaW5nIGlzIGEgdG9vbCBjYWxsZWQgJ2JyY3RsJy4gIEl0 IGJyaWRnZXMgdHdvIGRpc3RpbmN0IGludGVyZmFjZXMsIGUuZy4gYW4gRXRoZXJuZXQgaW50ZXJm YWNlIHRvIGEgV2lGaSBpbnRlcmZhY2UuICBIZXJlIHdlIHdvdWxkICdicmlkZ2UnDQpFdGhlcm5l dCBhbmQgODAyLjExIG9uIHRoZSBzYW1lIGludGVyZmFjZS4gIEl0J3Mgbm90ICdicmlkZ2luZycs IGl0J3MgJ2FkYXB0YXRpb24nLg0KDQpXb3JzZTogJ2JyY3RsJyBkb2VzIG5vdCB3b3JrIHdoZW4g d2Ugd2FudCB0byAnYnJpZGdlJyBhIE9DQiBpbnRlcmZhY2UgdG8gYW4gRXRoZXJuZXQgaW50ZXJm YWNlLiAgSSBkbyBub3Qgd2h5LiAgSSBndWVzcyB0aGUgODAyLiBncm91cHMgd2lsbCBmaWd1cmUg aXQgb3V0IG9uZSBkYXkgYW5kIGZpeCBpdC4NCg0KQnV0IEV0aGVybmV0IEFkYXB0YXRpb24gTGF5 ZXIgKG5hbWVkICdicmlkZ2luZycgYnkgeW91Pykgd29ya3Mgb2suDQoNCj4gLSBpcHdhdmUgNC4y IGl0IHN0YXRlcyAiSVAgcGFja2V0cyBhcmUgdHJhbnNtaXR0ZWQgb3ZlciA4MDIuMTEtT0NCIGFz IA0KPiBzdGFuZGFyZCBFdGhlcm5ldCBwYWNrZXRzLiBBcyB3aXRoIGFsbCA4MDIuMTEgZnJhbWVz LCBhbiBFdGhlcm5ldCAgDQo+IGFkYXB0YXRpb24gbGF5ZXIgTVVTVCBiZSB1c2VkIHdpdGggODAy LjExLU9DQiBhcyB3ZWxsLiIgQWdhaW4gRUFMIGlzICANCj4gc3RpcHVsYXRlZCBhcyBhIHJlcXVp cmVtZW50LiBBbmQgSSdtIG5vdCBzdXJlIGFib3V0IHRoZSBzdGlwdWxhdGlvbiAgDQo+IHRoYXQg cGFja2V0cyBhcmUgdHJhbnNtaXR0ZWQgYXMgInN0YW5kYXJkIEV0aGVybmV0IHBhY2tldHMiLCBp cyB0aGlzICANCj4gYWNjdXJhdGU/DQoNCllFcy4NCg0KSSB2ZXJpZnkgaXQgdGhpcyB3YXk6DQoN ClVzZSBhdmFpbGFibGUgV2lyZXNoYXJrIHRvb2wgb24gV2lGaSBpbnRlcmZhY2UsIGVuYWJsZSBJ UHY2IG9uIHRoZSBjb21wdXRlciwgYW5kIGR1bXAgc29tZSBJUHY2IHBhY2tldHMuICBUaGV5IGFs bCBoYXZlIEV0aGVybmV0SUkgaGVhZGVycywgcmF0aGVyIHRoYW4gTExDIGFuZCA4MDIuMTEgaGVh ZGVycy4gIFRoZW4gY2FwdHVyZSB0aGUgc2FtZSBpbiAnbW9uaXRvcicNCm1vZGUsIG9yICdtb24n IGludGVyZmFjZSBpbiA4MDIuMTEgT0NCLCBhbmQgdGhlIC4xMS9MTEMgaGVhZGVycyB3aWxsIHNo b3cgaW5zdGVhZC4NCg0KPiBEb2VzIHRoaXMgbWVhbiB0aGF0IDgwMi4zIGhlYWRlcnMgYXJlIGlu Y2x1ZGVkPw0KDQpUaGUgRXRoZXJuZXRJSSBoZWFkZXJzIChub3QgODAyLjMgRXRoZXJuZXQsIEkg YmVsaWV2ZSBkaWZmZXJlbnQpIGFyZSBpbmNsdWRlZCBpbiB0aGUgcHJvY2Vzc2luZyBkdXJpbmcg dGhlIGV4ZWN1dGlvbiBvZiB0aGlzIEVBTC4gIEJ1dCB0aGVzZSBFdGhlcm5ldElJIGhlYWRlcnMg YXJlIG5vdCBzZW50IG9uIHRoZSA4MDIuMTEgYWlyLg0KDQo+IFRoaXMgaXMgZGVmaW5pdGVseSBu b3Qgc3RpcHVsYXRlZCBpbiAxNjA5LjMuIFBhY2tldHMgdHJhbnNtaXR0ZWQgb3ZlciANCj4gT0NC IGJ5IGEgV0FWRSBkZXZpY2UgdXNpbmcgMTYwOS4zIGFyZSB3ZWxsIGZvcm1lZCBJUHY2IHBhY2tl dHMsIGJ1dCANCj4gbm90ICJFdGhlcm5ldCBwYWNrZXRzIiwgaS5lLiwgbm8gODAyLjMgaGVhZGVy cyBhcmUgaW5jbHVkZWQuIFRoaXMgDQo+IHNlZW1zIGxpa2UgYW4gaW50ZXJvcGVyYWJpbGl0eSBw cm9ibGVtIGJldHdlZW4gaXB3YXZlIGFuZCAxNjA5IFdBVkUuDQoNClRoZSBwYWNrZXRzIHB1dCBv biB0aGUgYWlyIG9uIDgwMi4xMS1PQ0IgbGlua3Mgd2l0aCB0aGUgSVB2Ni1vdmVyLU9DQiBkcmFm dCBkbyBub3QgaW5jbHVkZSBFdGhlcm5ldElJIGhlYWRlcnMuICBTTyBJIGRvIG5vdCB0aGluayB0 aGVyZSBpcyBhbiBpbnRlcm9wIHByb2JsZW0gMTYwOSBXQVZFIHdpdGggSVB2Ni1vdmVyLU9DQiBk cmFmdC4NCg0KPiANCj4+IDIuICAgICAgIEl0IGlzIG5vdCBjbGVhciB0aGF0IGlwd2F2ZSBwcm92 aWRlcyBhbnkgZnVuY3Rpb25hbGl0eSANCj4+IHRoYXQgMTYwOSBXQVZFIGRvZXMgbm90IGFscmVh ZHkgcHJvdmlkZS4NCj4gDQo+IFdlbGwsIDE2MDkgV0FWRSBkb2VzIG5vdCBzcGVjaWZ5IHRoZSBj b252ZXJzaW9uIGJldHdlZW4gLjExL0xMQyANCj4gaGVhZGVycyBhbmQgRXRoZXJuZXRJSSBoZWFk ZXJzLCByaWdodD8NCj4gDQo+IFtLU106IENvcnJlY3QgaXQgZG9lcyBub3QsIGFzIHRoaXMgdG9w aWMgaXMgb3V0IG9mIHNjb3BlIGZvciAxNjA5IFdBVkUgDQo+IChlLmcuLCB3ZSBkb24ndCBzcGVj aWZ5IHRoZSBvdGhlciBpbnRlcmZhY2VzIHN1Y2ggYXMgRXRoZXJuZXQgdGhhdCBtYXkgDQo+IGJl IHByZXNlbnQgaW4gdGhlIGRldmljZSkuIEFsc28gc2VlIG15IGNvbW1lbnRzIGFib3ZlIHJlZ2Fy ZGluZyB0aGUgDQo+IEVBTC4NCg0KSXQgaXMgaW4gc2NvcGUgaGVyZS4gIE1heWJlIDE2MDkgZG9j dW1lbnQgY2FuIHJlZmVyIHRvIGhlcmUuDQoNCj4gMTYwOSBXQVZFIGRvZXMgbm90IHNwZWNpZnkg dGhlIE1UVSBzaXplIGZvciBJUHY2LCByaWdodD8NCj4gDQo+IFtLU106IE5vIGl0IGRvZXMgbm90 LiA4MDIuMTEgKG5vcm1hdGl2ZSB0byAxNjA5KSBzcGVjaWZpZXMgbWF4aW11bSANCj4gTVNEVSBz aXplIGFzIDIzMDQgb2N0ZXRzLiBGb3IgV1NNUCAxNjA5LjMgc3BlY2lmaWVzIGEgbWF4aW11bSBN U0RVIA0KPiBzaXplIG9mIDIzMDIgKGFsbG93aW5nIGZvciB0aGUgMi1vY3RldCBMTEMgaGVhZGVy KSwgYW5kIGEgZGVmYXVsdCANCj4gdmFsdWUgb2YgMTQwMC4gWW91IGFyZSBjb3JyZWN0IGluIHRo YXQgYSBNU0RVIHNpemUgZm9yIElQdjYgaXMgbm90IA0KPiBzcGVjaWZpZWQgZXhwbGljaXRseSwg YnV0IEkgZG9uJ3Qga25vdyBpZiBzb21lIG90aGVyIFJGQ3MgcmVsYXRlZCB0bw0KPiAgSVB2NiBv dmVyIDgwMi4xMSBhbHJlYWR5IGRvIHRoYXQ/IFJlZ2FyZGxlc3MsIHN0aXB1bGF0aW5nIGEgZGVm YXVsdCAgDQo+IHZhbHVlIG9mIDE1MDAgZm9yIE1UVSBzaXplIGRvZXMgbm90IHZpb2xhdGUgYW55 dGhpbmcgaW4gMTYwOS4zLg0KDQpOb3RlZC4NCg0KRm9yIGV4cGxhbmF0aW9uLCB0aGUgZmlndXJl IDE1MDAgZm9yIE1UVSBmb3IgSVB2Ni1vdmVyLU9DQiBjb21lcyBmcm9tIGltcGxlbWVudGF0aW9u cyBpbmhlcml0aW5nIGZyb20gb2xkIEV0aGVybmV0IGJlaGF2aW91ci4gIFdlIGRvbnQgd2FudCB0 byBicmVhayB0aGF0LiAgTW9yZW92ZXIsIGl0IGlzIGNvbXBhdGlibGUgd2l0aCBSRkM4MjAwIChJ UHY2KSB3aGljaCByZXF1aXJlcyB0aGUgbWluaW11bSBNVFUgdG8gYmUgYXQgbGVhc3QgMTI4MGJ5 dGVzIGZvciBhbGwgbGlua3Mgc3VwcG9ydGluZyBJUHY2Lg0KDQpJUHY2IHBlb3BsZSBhcmUgYXdh cmUgdGhhdCBtYW55IGxpbmtzIGRvIHN1cHBvcnQgbW9yZSB0aGFuIDE1MDBieXRlcyBNVFUuICBJ IGhlYXJkIG9mIDEwMDAwYnl0ZXMgZm9yIHNvbWUgY29yZSBsaW5rcy4gIFlldCB0aGUgSVB2Ni1v dmVyLWZvbyBmb3IgdGhlc2UgbGlua3MgZG8gbm90IHJlcXVpcmUgdGhlIE1UVSAxMDAwMGJ5dGVz Lg0KDQoNCj4gDQo+IDE2MDkgV0FWRSBkb2VzIG5vdCBzcGVjaWZ5IHRoYXQgSVB2NiBtdXN0IGJl IHByZWNlZGVkIGJ5IC4xMSBRb1NEYXRhICANCj4gKG5vdCBqdXN0IC4xMSBEYXRhKSwgYW5kIEJB Q0tHUk9VTkQsIHJpZ2h0Pw0KPiANCj4gW0tTXTogQ2VydGFpbmx5IDE2MDkgZG9lcyBub3QuIDE2 MDkgb25seSByZXN0cmljdHMgSVB2NiBwYWNrZXRzIHRvIHRoZSANCj4gU0NIICh0aGV5IGFyZSBu b3QgYWxsb3dlZCBvbiB0aGUgQ0NIKS4gODAyLjExIHNwZWNpZmllcyBkZWZhdWx0cyAgZm9yIA0K PiBhbGwgVVAgYW5kIEFDIHBhcmFtZXRlcnMsIGluZGljYXRlcyB3aGljaCBmcmFtZSB0eXBlcyBh cmUgYWxsb3dlZCwgDQo+IGV0Yy4gQnV0IGFzIGZhciBhcyBJIGNhbiB0ZWxsIHRoZSBzdGlwdWxh dGlvbiB0aGF0IElQdjYgdXNlICBRb1NEYXRhIA0KPiBhbmQgQUNfQksgaXMgbmV3IGFuZCBzb21l dGhpbmcgdGhhdCBpcHdhdmUgaW50cm9kdWNlcz8NCg0KSXQgc2VlbXMgc28uICBQZW9wbGUgYWdy ZWUgd2l0aCBpdC4NCg0KPiBBZ2FpbiwgSSdtIG5vdCBhbiBleHBlcnQgb24gdGhpcyB0b3BpYyBh bmQgSSBiZWxpZXZlIG90aGVycyBpbiB0aGUNCj4gMTYwOSBXRyBoYXZlIGJlZW4gZGlzY3Vzc2lu ZyB0aGlzIHdpdGggdGhlIGlwd2F2ZSBsaXN0LiBSZWdhcmRsZXNzLCANCj4gdGhpcyBhZGRpdGlv bmFsIHJlc3RyaWN0aW9uIGRvZXMgbm90IHZpb2xhdGUgMTYwOS4zLg0KPiANCj4gMTYwOSBXQVZF IGRvZXMgbm90IHJlY29tbWVuZCBpbiBwYXJ0aWN1bGFyIFJGQzgwNjQgdG8gZm9ybSANCj4gc2Vt YW50aWNhbGx5IG9wYXF1ZSBJbnRlcmZhY2UgSWRlbnRpZmllcnMsIHJpZ2h0Pw0KPiANCj4gW0tT XTogMTYwOSBkb2VzIG5vdCByZWNvbW1lbmQgYW55dGhpbmcgbGlrZSB0aGlzLCBidXQgb24gdGhl IG90aGVyIA0KPiBoYW5kIDE2MDkgZG9lcyBub3QgcHJvaGliaXQgaXQgZWl0aGVyLiAxNjA5IGRv ZXMgbm90IGdlbmVyYWxseSANCj4gc3BlYWtpbmcgInJlY29tbWVuZCIsIHJhdGhlciBpdCAic3Bl Y2lmaWVzIiBhbmQgbGVhdmVzIGFsbCBlbHNlIHVwIHRvIA0KPiB0aGUgc3lzdGVtIGRlc2lnbmVy L2ltcGxlbWVudGVyL2RlcGxveWVyLiBBbmQgYXMgbWVudGlvbmVkIHByZXZpb3VzbHksIA0KPiAx NjA5IGFsbG93cyBhbnkgYW5kIGFsbCBJRVRGIHByb3RvY29scyB0byBiZSBpbXBsZW1lbnRlZC4N Cj4gUmVnYXJkbGVzcywgdGhpcyByZWNvbW1lbmRhdGlvbiBkb2VzIG5vdCB2aW9sYXRlIGFueXRo aW5nIGluIDE2MDkuMy4NCg0KTm90ZWQuDQoNCj4gDQo+IChhbmQgYSBmZXcgb3RoZXJzKS4NCj4g DQo+PiAxNjA5IFdBVkUgaW5jbHVkZXMgYSBudW1iZXIgb2YgbWVjaGFuaXNtcyB0aGF0IGVuYWJs ZSBJUHY2IG5ldHdvcmtzIA0KPj4gdG8gYmUgY29uZmlndXJlZC4gSW4gYWRkaXRpb24gdG8gdGhl IFdTQS9XUkEgbWVjaGFuaXNtLCAxNjA5LjMgYWxsb3dzIA0KPj4gYW55IElFVEYgcHJvdG9jb2xz IHRvIGJlIGltcGxlbWVudGVkLCBlLmcuLCBJRVRGIFJGQyA0ODYxLCBOZWlnaGJvciANCj4+IERp c2NvdmVyeSBmb3IgSVAgVmVyc2lvbiA2IChJUHY2KSAod2hpY2ggaXMgbGlzdGVkIGFzIGEgbm9y bWF0aXZlIA0KPj4gcmVmZXJlbmNlIGluIDE2MDkuMykuIEhlbHBmdWwgd291bGQgYmUgc29tZSBl eGFtcGxlIHVzZS1jYXNlcyB0aGF0IA0KPj4gaWxsdXN0cmF0ZSBwcm9ibGVtcyB0byBiZSBzb2x2 ZWQsIGFuZCBob3cgaXB3YXZlIHdpbGwgc29sdmUgdGhvc2UgDQo+PiBwcm9ibGVtcyAoaS5lLiwg dGhhdCAxNjA5IFdBVkUgZG9lcyBub3QgYWxyZWFkeSBzb2x2ZSkuDQo+IA0KPiBUaGVyZSBpcyBh IGRyYWZ0IHRoYXQgZGVzY3JpYmVzIHNvbWUgdXNlLWNhc2VzIG9mIElQdjYgaW4gdmVoaWN1bGFy DQo+IG5ldHdvcmtzOiBkcmFmdC1pZXRmLWlwd2F2ZS12ZWhpY3VsYXItbmV0d29ya2luZy0wMg0K PiANCj4gW0tTXTogVGhhbmtzIGZvciBwb2ludGluZyBtZSB0byB0aGF0LCBsb3RzIG9mIGluZm8g dGhlcmUhIEknbGwgc3BlbmQgIA0KPiBzb21lIHRpbWUgcmV2aWV3aW5nIHRoYXQgd2hlbiBJIGNh bi4NCj4gDQo+IEkgdGhpbmsgc29tZSBwYXJ0cyBvZiAxNjA5IFdBVkUsIGluIHBhcnRpY3VsYXIg V1JBLCBhcmUgbm90IHVzZWQgaW4gDQo+IEV1cm9wZS4gV2hlcmVhcyB0aGlzIElQdjYtb3Zlci1P Q0IgZHJhZnQgaXMgdXNlZCB0aGUgc2FtZSB3aGVyZXZlciANCj4gSW50ZXJuZXQgaXMgcHJlc2Vu dCAoRXVyb3BlLCBBbWVyaWNhLCBDb250aW5lbnRzKS4NCj4gDQo+IFtLU106IDE2MDkgd2VudCB0 byBncmVhdCBsZW5ndGhzIHRvIGhhcm1vbml6ZSBXU00gYW5kIFdTQSBmcmFtZSANCj4gZm9ybWF0 cyB3aXRoIElTTy9FVFNJIHN0YW5kYXJkcywgdGhlc2UgaGFybW9uaXplZCBmcmFtZXMgYXJlIGlu Y2x1ZGVkIA0KPiBpbiBhbGwgb2YgdGhlIC0yMDE2IHJldmlzaW9ucyB0byAxNjA5LiBTbyBmb3Ig ZXhhbXBsZSB0aGUgMTYwOS4zIFdTQSANCj4gaXMgaW50ZXJvcGVyYWJsZSB3aXRoIHRoZSBzZXJ2 aWNlIGFkdmVydGlzZW1lbnQgdXNlZCBpbiBFdXJvcGUuIFNlZSANCj4gSVNPIDE2NDYwLCBhbmQg c2VlIGFsc28gRVRTSSBUUyAxMDIgODkwLTEuDQoNCkkgYWdyZWUgaGFybW9uaXphdGlvbiBpcyBn b29kIGFuZCBuZWVkZWQuDQoNCkluIGNhc2UgdGhhdCBoYXJtb25pemF0aW9uIHJlbGllcyBvbiBJ UHY2IGFzIHNwZWNpZmllZCBhdCBJRVRGLCB0aGVzZSBhcmUgbXkgY29tbWVudHMgdG8gdGhlIEVU U0kgZG9jdW1lbnQuDQoNClF1aWNrbHkgc2tpbW1pbmcsIGl0IGNhbGxzIGl0ICJJUHY2IHJvdXRp bmcgYWR2ZXJ0aXNlbWVudCIuICBJdCBpcyAiSVB2NiBSb3V0ZXIgQWR2ZXJ0aXNlbWVudCIuDQoN ClRoZSAnZGVmYXVsdCcgcm91dGUgaXMgdXNlZCB3aGVuIG5vIG90aGVyIHJvdXRlIGlzIGF2YWls YWJsZS4gIFRoZSAnZGVmYXVsdCcgcm91dGUgdHlwaWNhbGx5IGdpdmVzIGFjY2VzcyB0byB0aGUg SW50ZXJuZXQsIG5vdCB0byBvbmUgcGFydGljdWxhciBzZXJ2ZXIgKCJJVFMtUyI6IHN0YXRpb24p LiAgRm9yIHBhcnRpY3VsYXIgc2VydmVycywgb25lIG1heSB1c2UgUkZDNDE5MSBpbnN0ZWFkLCBm b3IgIm1vcmUgc3BlY2lmaWMgcm91dGVzIiBvciwgdGhlIHJvdXRlcyBrbm93biBhcyAnaG9zdC1i YXNlZCByb3V0ZXMnLg0KDQpUaGFuayB5b3UgZm9yIHRoZSBjb21tZW50cy4NCg0KQWxleA0KDQoN Cg0KPj4gTXkgY29uY2VybiBpcyB0aGF0IHRoZSBJRVRGIGlwd2F2ZSBkb2N1bWVudCBtYXkgY2F1 c2Ugc2lnbmlmaWNhbnQgDQo+PiBjb25mdXNpb24gYW1vbmcgZGVwbG95ZXJzLCBhbmQgcG9zc2li bHkgbGVhZCB0byBhIGxhY2sgb2YgDQo+PiBpbnRlcm9wZXJhYmlsaXR5LiBUaGFuayB5b3UgZm9y IHRoZSBvcHBvcnR1bml0eSB0byBjb21tZW50LCBJIGxvb2sgDQo+PiBmb3J3YXJkIHRvIHRoZSBk aXNjdXNzaW9uLg0KPiANCj4gSSB3b3VsZCBsaWtlIHRvIGhlbHAgd2l0aCBjbGFyaWZpY2F0aW9u LiBMZXQgdXMgZGlzY3VzcyB0aGlzLg0KPiANCj4gW0tTXTogU291bmRzIGdvb2QhDQo+IA0KPiBB bGV4DQo+IA0KPj4gDQo+PiANCj4+IA0KPj4gQmVzdCByZWdhcmRzLA0KPj4gDQo+PiBLZXZpbg0K PiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gaXRz IG1haWxpbmcgbGlzdCANCj4gaXRzQGlldGYub3JnIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaXRzDQo+IA0KPiANCg== From nobody Sat Mar 17 05:51: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 45CA312711A for ; Sat, 17 Mar 2018 05:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 hTNSyRIwJQSA for ; Sat, 17 Mar 2018 05:51:00 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::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 A202D127077 for ; Sat, 17 Mar 2018 05:50:59 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id h76so7730441wme.4 for ; Sat, 17 Mar 2018 05:50:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ce9+vHpZU9TRbUUY5aBr0yh2gVtYj0X6IhSK2MAfpoQ=; b=rdPQPfLbc9k/G6xU3qBFsdNZJHlVenmMOeNpxS0RjKnuRXfdftcrE+ZvY19TbGutDt QbjwYIqNmFe8fvYHGHbe94nZsfhwf3KpJLD1u2RkTPHosWHVzZDFoLPfLXaNqFmL+JUg meTaF6gmylVVgngTWbZuTDE9bj8Qt8mUDEr6Ek+7KU1oZ/7AjLGQfB6htc48bXmpvPnw w0Ws2KuRcDmjEccFzhdmns3hAPmrVFHhDq7We3y4r6LSKz82Ybgv5gKx3XR7jqdSHcSJ EV/ME+poKYay0Bwi5cmrrZ9oa1c/xEtrAOk6roENzrbY17M8D3I3UZm+vjPPu8Ykt5CM nlhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=ce9+vHpZU9TRbUUY5aBr0yh2gVtYj0X6IhSK2MAfpoQ=; b=KT0rmTSVxkGdVXYfS/+7PTb1EUkuX0uv9GXFazJT4zokr0AK/+W+qeGESeKO8IPJ3i w0dru2vxQ1ECqPgpKrhrRlHKsrcs2YD8gVEXoAD3gbrnsz3XT2JAeSkurhsuaI8TY5mH sTiULadHyOrDCD3TaSJYp4R53ddriVsRDJFHYJaGtRUgdEpsr7wECTgVob6vNrZ0UB4b p3K5SF3LNdyoROUa9Lai2Fd9rORNz+UZEGhkTbxVP8jzlB7DPPa8OAesvxa7kviyt3vs d61UcP/GZMagN1hEQ0ZKlpBMv1RmvenHvLG9+ElaBFcFEULy1bi7mfxm7DQUnx68efnE khXQ== X-Gm-Message-State: AElRT7FXO2VY5b4tw/EJ6ggV6Q2R5G1DgGKxOMbMY2sgeDXROfzf4q5l v4whIj/CW9RGfZArVeJ7ISc= X-Google-Smtp-Source: AG47ELtUkvMfbCGsMZzDn4JZzDCnwpxWZDwGvj1ASKoptzumpROQIAHqL2JOeQ9CEWRr+u5tpJQIeA== X-Received: by 10.28.111.19 with SMTP id k19mr3938409wmc.147.1521291058219; Sat, 17 Mar 2018 05:50:58 -0700 (PDT) Received: from ?IPv6:2001:67c:1232:144:b0cb:5e79:5a80:413d? ([2001:67c:1232:144:b0cb:5e79:5a80:413d]) by smtp.gmail.com with ESMTPSA id e10sm9851905wrh.38.2018.03.17.05.50.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 17 Mar 2018 05:50:57 -0700 (PDT) Sender: Tony Li 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: Sat, 17 Mar 2018 12:50:56 +0000 Cc: Alexandre Petrescu , Kevin Smith , "its@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> To: Tijink Jasja X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [ipwave] FW: ipwave - comments and concerns - 1609 WAVE, EPD - 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: Sat, 17 Mar 2018 12:51:01 -0000 > on the EAL topic. Take again the following text from the draft: >=20 > " IP packets are transmitted over 802.11-OCB as standard Ethernet > packets. As with all 802.11 frames, an Ethernet adaptation layer > MUST be used with 802.11-OCB as well." >=20 > I understand the second sentence is a requirement you put to = implementations that feature an ethernet interface and an 802.11 = interface.=20 I suspect that we=E2=80=99ll also get some push back on this sentence = because it is implied to be normative. Since the EAL doesn=E2=80=99t = actually affect the bits on the air, this is simply an implementation = choice and not strictly mandatory. It would probably be easier if we relaxed the wording to make this = informative or recommended instead. Tony From nobody Sat Mar 17 05:54: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 5C83012711A for ; Sat, 17 Mar 2018 05:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kapsch.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxH6Q5uEKzfA for ; Sat, 17 Mar 2018 05:54:44 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-ve1eur03on071e.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe09::71e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E9CF127077 for ; Sat, 17 Mar 2018 05:54:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kapsch.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XSbyFoHfiSDdjSepdmYhhvkp5cDAi1U4br8FnJx2Ca8=; b=eX3t/NgRMBPoshYrYfi3fvXsvx4xJE8TH2wHQ1aOsuqoJAoMQELwOHJMeXQd3GZS7BiS5/ahjb9qGpXjqQY7hsQJWlmJkbLZHMUNwm9rl5DZbSem3qUqRsnDQW79HcP/ZTtTE2GhpT10kHOwAk2lmffskxwgwq/rM+kA6ZHwe+8= Received: from AM0PR0302MB3380.eurprd03.prod.outlook.com (52.133.37.155) by AM0PR0302MB3315.eurprd03.prod.outlook.com (52.133.37.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.588.14; Sat, 17 Mar 2018 12:54:40 +0000 Received: from AM0PR0302MB3380.eurprd03.prod.outlook.com ([fe80::153a:2232:e7b7:7cb4]) by AM0PR0302MB3380.eurprd03.prod.outlook.com ([fe80::153a:2232:e7b7:7cb4%13]) with mapi id 15.20.0588.016; Sat, 17 Mar 2018 12:54:40 +0000 From: Tijink Jasja To: Tony Li CC: Alexandre Petrescu , Kevin Smith , "its@ietf.org" Thread-Topic: [ipwave] FW: ipwave - comments and concerns - 1609 WAVE, EPD - towards resolution Thread-Index: AQHTve6vNar0sShaAkeFJ7T/w10/XKPUYjjA Date: Sat, 17 Mar 2018 12:54:40 +0000 Message-ID: References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> In-Reply-To: Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jasja.Tijink@kapsch.net; x-originating-ip: [62.47.243.63] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM0PR0302MB3315; 6:Wpz7Q4Kt9no2gMYMH0XQgz3Xnft1eGYNSPNlWwwm1SU3wg87XobXUB1b4W/lP9bqo4+1TIM8Q0iYtVXfpCKG6KvTmrncA7NA5L4B7WLQw/kwnKEsu3z20glEtGizx5SERjLJ3KfiYJ6eLRE1BPSS7PtZ/j0RjTDNxBBERezyOkZ8q0fQht5be36I0sM7HsnffnP1UsMdnMZBEQgCHPEN0pb+2ZYDGqDDJ3NpRaIx6fId1mkr9/afTeUyw56DFTfbI1h1z43o6yDxv8om4UXna14MVEZc0HYrX853wkxiNasHcySFjs6nj9o9TKdqWJhq5ja5YIbNXgEBopfGPAHpcoYkBcgVHrpREtIq8ZtI6fp3jaEH2m/d7SEdq+qllxDF; 5:tI/7DekYea+Vg38klBsqSwyOq0lrvb9WRIOuswlfXj8SOfDFesrzvDpdHW2ITKM2KyVn39yMzxOkZRK/J4oAh6ZMhA/X0in1Ct+Mt3LYue8z+vt+T7wGH9RqNBtWwi5qwWOljcpIQcofUsPeD0g8OxgPjE9sn/GEp6UKmn5QMvo=; 24:+0cBbQXye4dPMv5V9iSv57VB3fml5WI82sFFsyH9sAqwXAw+927ZFladweXv2rs/++xlfMzHGqDBgwo6qb/0qgvdOEZDRiLfbKjEhuAcQgQ=; 7:rwDaIE0cU/pcyS9DzBI5Eu/KBMtc/R2i4jBZlNdCG36iN9sZ+t/3QzANn0U2t9ck+jvM46HA8xfAd5+y4uqr+FJFi8B1aNFf7WfcFniewlCibV7VFOjtGJOGXjUQ7dioQ6t+e/TJLwDlRu2wtL76MMAZ8CDFMThk19bWqHW/wmHliQ1nP68KvOJuUs0y0VLA7tpWmBnjuoQu0zTeJizge81eOCDtezssuBxAe+dJEyMA+PGNJp7CERSUpG4KrqvO x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: db7d96e0-f965-478d-1a7b-08d58c063f7c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:AM0PR0302MB3315; x-ms-traffictypediagnostic: AM0PR0302MB3315: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(79046362386883)(85827821059158); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(3231221)(944501300)(52105095)(10201501046)(93006095)(93001095)(6041310)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:AM0PR0302MB3315; BCL:0; PCL:0; RULEID:; SRVR:AM0PR0302MB3315; x-forefront-prvs: 06141B80DC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(396003)(376002)(39380400002)(39840400004)(199004)(189003)(6116002)(9686003)(5660300001)(76176011)(39060400002)(55016002)(7696005)(74316002)(478600001)(4326008)(8666007)(186003)(305945005)(99286004)(7736002)(106356001)(26005)(2950100002)(6916009)(3846002)(105586002)(72206003)(86362001)(81166006)(53936002)(14454004)(2906002)(81156014)(8936002)(66066001)(6436002)(68736007)(102836004)(54906003)(5250100002)(316002)(6506007)(2900100001)(3660700001)(25786009)(3280700002)(93886005)(33656002)(97736004)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR0302MB3315; H:AM0PR0302MB3380.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: kapsch.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: 3RCZHa3EGsjrEEvIVqsA7u+cwfzialHfdBaxX+r2yrPGU63Xuq5SnZCHGWX5QNkXn35ksN/7+4dOrHImDLWbPqiTrqlK2XX3a6Cm35ITq/t/tl4Fx6RH0dtll3J23FdDWSPJRg3bFPZPfZDTljnJeJoCURn1PikPSYQGyE/b/2sCw89XDf5h4EnWwcnR3q14487UzUT0RMlQclJKkN24VOP2i16pcPtvKufGvNXogxTZt86Zglu6GMtGMhwLV3Lj90NRwJViAo2ZvLXHnCKbVF0qXHDZLmFQ6PRvQ/KEOwS5IHV1yPiNSgJ0JUFYTAG4/QMz4E07nFnojk59PfXRvA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: kapsch.net X-MS-Exchange-CrossTenant-Network-Message-Id: db7d96e0-f965-478d-1a7b-08d58c063f7c X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2018 12:54:40.4489 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5f9ce527-7e3e-4e83-a8a4-b6c848f85ab5 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR0302MB3315 Archived-At: Subject: Re: [ipwave] FW: ipwave - comments and concerns - 1609 WAVE, EPD - 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: Sat, 17 Mar 2018 12:54:46 -0000 SSBhZ3JlZSB3aXRoIFRvbnkuDQoNClJlZ2FyZHMgSmFzamENCg0KDQotLS0tLVVyc3Byw7xuZ2xp Y2hlIE5hY2hyaWNodC0tLS0tDQpWb246IFRvbnkgTGkgW21haWx0bzp0b255MWF0aG9tZUBnbWFp bC5jb21dIEltIEF1ZnRyYWcgdm9uIFRvbnkgTGkNCkdlc2VuZGV0OiBTYW1zdGFnLCAxNy4gTcOk cnogMjAxOCAxMzo1MQ0KQW46IFRpamluayBKYXNqYSA8SmFzamEuVGlqaW5rQGthcHNjaC5uZXQ+ DQpDYzogQWxleGFuZHJlIFBldHJlc2N1IDxhbGV4YW5kcmUucGV0cmVzY3VAZ21haWwuY29tPjsg S2V2aW4gU21pdGggPGtldmluLnMuc21pdGhAY294Lm5ldD47IGl0c0BpZXRmLm9yZw0KQmV0cmVm ZjogUmU6IFtpcHdhdmVdIEZXOiBpcHdhdmUgLSBjb21tZW50cyBhbmQgY29uY2VybnMgLSAxNjA5 IFdBVkUsIEVQRCAtIHRvd2FyZHMgcmVzb2x1dGlvbg0KDQoNCj4gb24gdGhlIEVBTCB0b3BpYy4g VGFrZSBhZ2FpbiB0aGUgZm9sbG93aW5nIHRleHQgZnJvbSB0aGUgZHJhZnQ6DQo+IA0KPiAiIElQ IHBhY2tldHMgYXJlIHRyYW5zbWl0dGVkIG92ZXIgODAyLjExLU9DQiBhcyBzdGFuZGFyZCBFdGhl cm5ldCAgDQo+IHBhY2tldHMuICBBcyB3aXRoIGFsbCA4MDIuMTEgZnJhbWVzLCBhbiBFdGhlcm5l dCBhZGFwdGF0aW9uIGxheWVyICANCj4gTVVTVCBiZSB1c2VkIHdpdGggODAyLjExLU9DQiBhcyB3 ZWxsLiINCj4gDQo+IEkgdW5kZXJzdGFuZCB0aGUgc2Vjb25kIHNlbnRlbmNlIGlzIGEgcmVxdWly ZW1lbnQgeW91IHB1dCB0byBpbXBsZW1lbnRhdGlvbnMgdGhhdCBmZWF0dXJlIGFuIGV0aGVybmV0 IGludGVyZmFjZSBhbmQgYW4gODAyLjExIGludGVyZmFjZS4gDQoNCg0KSSBzdXNwZWN0IHRoYXQg d2XigJlsbCBhbHNvIGdldCBzb21lIHB1c2ggYmFjayBvbiB0aGlzIHNlbnRlbmNlIGJlY2F1c2Ug aXQgaXMgaW1wbGllZCB0byBiZSBub3JtYXRpdmUuICBTaW5jZSB0aGUgRUFMIGRvZXNu4oCZdCBh Y3R1YWxseSBhZmZlY3QgdGhlIGJpdHMgb24gdGhlIGFpciwgdGhpcyBpcyBzaW1wbHkgYW4gaW1w bGVtZW50YXRpb24gY2hvaWNlIGFuZCBub3Qgc3RyaWN0bHkgbWFuZGF0b3J5Lg0KDQpJdCB3b3Vs ZCBwcm9iYWJseSBiZSBlYXNpZXIgaWYgd2UgcmVsYXhlZCB0aGUgd29yZGluZyB0byBtYWtlIHRo aXMgaW5mb3JtYXRpdmUgb3IgcmVjb21tZW5kZWQgaW5zdGVhZC4NCg0KVG9ueQ0KDQo= From nobody Sat Mar 17 12:25:54 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 AF59012D7EA for ; Sat, 17 Mar 2018 12:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.583 X-Spam-Level: X-Spam-Status: No, score=-0.583 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] 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 PE3vNyZZqSKp for ; Sat, 17 Mar 2018 12:25:50 -0700 (PDT) Received: from fed1rmfepo201.cox.net (fed1rmfepo201.cox.net [68.230.241.146]) by ietfa.amsl.com (Postfix) with ESMTP id 92E9612711D for ; Sat, 17 Mar 2018 12:25:49 -0700 (PDT) Received: from fed1rmimpo209.cox.net ([68.230.241.160]) by fed1rmfepo201.cox.net (InterMail vM.8.01.05.28 201-2260-151-171-20160122) with ESMTP id <20180317192549.OULN4375.fed1rmfepo201.cox.net@fed1rmimpo209.cox.net> for ; Sat, 17 Mar 2018 15:25:49 -0400 Received: from smithPC ([174.68.115.141]) by fed1rmimpo209.cox.net with cox id P7Ro1x00A336m1J017RogQ; Sat, 17 Mar 2018 15:25:48 -0400 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A090202.5AAD6BBC.0065, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.2 cv=OZToNlbY c=1 sm=1 tr=0 a=lZ+2k6HZ6QqstbCzvfe+bA==:117 a=lZ+2k6HZ6QqstbCzvfe+bA==:17 a=IkcTkHD0fZMA:10 a=x7bEGLp0ZPQA:10 a=kGgg9RDvKM0A:10 a=A1EfXRNyAAAA:8 a=pGLkceISAAAA:8 a=kviXuzpPAAAA:8 a=48vgC7mUAAAA:8 a=V9FFtDx6MIhPqaLmgrYA:9 a=PwhRKkJL0loXesXa:21 a=J1dv_M21_r1IPZ1V:21 a=QEXdDO2ut3YA:10 a=ho1zAXZTouNDp1r8zZ_w:22 a=qrIFiuKZe2vaD64auk6j:22 a=w1C3t2QeGrPiZgrLijVG:22 X-CM-Score: 0.00 Authentication-Results: cox.net; auth=pass (LOGIN) smtp.auth=kevin.s.smith@cox.net From: "Kevin Smith" To: "'Tijink Jasja'" , "'Alexandre Petrescu'" Cc: References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> In-Reply-To: Date: Sat, 17 Mar 2018 12:25:55 -0700 Message-ID: <003b01d3be25$c5239ff0$4f6adfd0$@cox.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGhOrR8o8b5YryKQCC/S9k90bJ5fwGaWEJkAgugfycB2ExIeqQNx4HA Content-Language: en-us Archived-At: Subject: Re: [ipwave] FW: ipwave - comments and concerns - 1609 WAVE, EPD - 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: Sat, 17 Mar 2018 19:25:53 -0000 Hi Alex, I have the same concern as does Jasja regarding the statement found in = the draft: "IP packets are transmitted over 802.11-OCB as standard = Ethernet packets." I believe that statement is technically incorrect, or at best very = confusing. The term "Ethernet" is widely used to refer to wired networks = specified by IEEE 802.3. Ethernet II (or Ethernet Version 2) is one type = of Ethernet frame format, and the one most widely used in IP networks. = There are others. I'm unsure exactly where Ethernet II is specified, = originally is was specified in "Digital Equipment Corporation, Intel, = Xerox, The Ethernet, Version 2.0, November 1982.", but it must have been = incorporated into 802.3 or perhaps some IETF RFCs? I'd propose the text be revised to something more specific like this: = "IPv6 packets are transmitted over 802.11-OCB as QoS Data frames as = specified in IEEE Std 802.11."=20 Note also I changed "IP" to "IPv6".=20 Regards, Kevin -----Original Message----- From: Tijink Jasja [mailto:Jasja.Tijink@kapsch.net]=20 Sent: Saturday, March 17, 2018 5:37 AM To: Alexandre Petrescu ; Kevin Smith = Cc: its@ietf.org Subject: AW: FW: [ipwave] ipwave - comments and concerns - 1609 WAVE, = EPD - towards resolution Hi Alex, on the EAL topic. Take again the following text from the draft: " IP packets are transmitted over 802.11-OCB as standard Ethernet packets. As with all 802.11 frames, an Ethernet adaptation layer MUST be used with 802.11-OCB as well." I understand the second sentence is a requirement you put to = implementations that feature an ethernet interface and an 802.11 = interface.=20 But the first sentence: that one seems not true to me according to what = you report of your own tests - 802.11 packets do not have ethernet = headers. So the first sentence is incorrect, right? Or do I simply = misunderstand it and what you want to say is:=20 "IP packets are transmitted over 802.11-OCB as over standard Ethernet: = as with all 802.11 frames, an Ethernet adaptation layer MUST be used = with 802.11-OCB as well." Regards Jasja -----Urspr=C3=BCngliche Nachricht----- Von: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com]=20 Gesendet: Samstag, 17. M=C3=A4rz 2018 13:10 An: Kevin Smith Cc: Tijink Jasja ; its@ietf.org Betreff: Re: FW: [ipwave] ipwave - comments and concerns - 1609 WAVE, = EPD - towards resolution Le 16/03/2018 =C3=A0 18:34, Kevin Smith a =C3=A9crit : [...] > I suggest that in section 4.2.1 "Ethernet Adaptation Layer" we add the = > following paragraph: >=20 >> The IPv6 packet transmitted on 802.11-OCB MUST be immediately=20 >> preceded by a Logical Link Control (LLC) header and an 802.11 header. = >> In the LLC header, and in accordance with the EtherType Protocol=20 >> Discrimination (EPD), the value of the Type field MUST be set to=20 >> 0x86DD (IPv6). In the 802.11 header, the value of the Subtype=20 >> sub-field in the Frame Control field MUST be set to 8 (i.e. >> 'QoS Data'); the value of the Traffic Identifier (TID) sub-field of=20 >> the QoS Control field of the 802.11 header MUST be set to binary >> 001 (i.e. User Priority 'Background', QoS Access Category 'AC_BK'). >>=20 >> In the Ethernet II header, the value of the Type field MUST be set =20 >> to 0x86DD (IPv6). >=20 > Do you agree with this text? >=20 > [KS]: I agree with the part that addresses the LLC header. I don't=20 > disagree with the part addressing the 802.11 header, I'm just not an =20 > expert in this area and so defer to others. I believe that others in =20 > the 1609 WG have been discussing this with the ipwave list? Noted. Others have discussed the QoS part and there seems to be agreement with = that. >> I note that ipwave mentions EPD, but also SNAP and does not specify=20 >> which method to use. >=20 > I propose we remove this phrase: >> Other alternative views of layering are EtherType Protocol=20 >> Discrimination (EPD), see Appendix E, and SNAP see [RFC1042]. >=20 > Do you agree? >=20 > [KS]: Yes. Noted. >> Moreover ipwave discusses an abstract "Ethernet Adaptation Layer"=20 >> but does not specify a header format, and this further confuses the=20 >> question for deployers - what should we implement? >=20 > The Ethernet Adaptation Layer (more precisely 802.11-to-Ethernet AL) =20 > is not so abstract, because it is widely implemented. This layer does=20 > conversion between headers: at reception from the network it=20 > transforms a .11/LLC header into an EthernetII header; reversely, at =20 > sending it transforms an EthernetII header into a .11/LLC header. > This is shown in Figure 1. >=20 > The EAL does not intend to specify a header format. The header formats = > involved are the IEEE 802.11, LLC and EthernetII. The fields in these = > headers are specified by IEEE. >=20 > [KS]: I don't understand why the EAL is relevant to "Transmission of > IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the = > Context of a Basic Service Set". If I want to write software that=20 > sends IPv6 packets over 802.11 OCB, all I need to know is how to=20 > construct the LLC sublayer header, etc. The EAL sounds like a=20 > "bridge", and perhaps belongs in a separate document (and perhaps has=20 > already been addressed in some existing document?) We wanted to have IPv6-over-OCB document that is minimal change from = existing works: RFC 2464 IPv6-over-Ethernet and implementations. In implementations, that's how IPv6 works: whenever IPv6 stack wants to = sit on a link layer (802.15.4, WiFi, LTE) it actually sits on an = Adaptation Layer. Because IPv6 only knows Ethernet (RFC2464). Whenever a new link layer technology appears, people struggle to make it = first look like Ethernet. Only then does IPv6 run easily on it. Because of that, I tend to agree it could makes sense to make an IPv6-over-802.11 document first (including EAL), and the OCB version after. The OCB version would be much smaller. At the same time, such document IPv6-over-802.11 does not exist. It = could not be developped in the IPWAVE WG which is aiming at vehicle = networking, not .11 in general. It would take so long to create a new IPv6-over-.11 document, and only = then to advance the IPv6-over-OCB draft. An additional reason as to why it would take long is that the mapping of IPv6 fields on 802.11 fields is not straightforward at all. (QoS is one = aspect, but there is also frag fields, security and more). > Regardless, including a description of the EAL does not violate=20 > anything in 1609.3, as it is out of scope with 1609.3. Noted. >=20 > Some *new comments* from my side: >=20 > - ipwave 4.2.1 it states "An 'adaptation' layer is inserted between a=20 > MAC layer and the Networking layer." This sounds like a requirement. > If I am developing a product that is only concerned with sending IPv6=20 > over OCB, and does not require "bridging", then how do I reconcile=20 > this requirement? It is a requirement indeed. But the adaptation layer is already there, = do not worry. If one develops a new product, one is likely to use existing kernels - = they do include EAL, even though they dont call it so. If one develops from scratch (very rare), one would have to answer = questions like how does Frag fields map between IPv6 and 802.11, = security, and other very complicated questions. Agreement would be needed too. I think one will rather prefer too to rely on Ethernet (RFC2464), as so many other people did in the past. "Bridging": I do not know what you mean by 'bridging'? In linux = bridging is a tool called 'brctl'. It bridges two distinct interfaces, = e.g. an Ethernet interface to a WiFi interface. Here we would 'bridge' Ethernet and 802.11 on the same interface. It's not 'bridging', it's = 'adaptation'. Worse: 'brctl' does not work when we want to 'bridge' a OCB interface to = an Ethernet interface. I do not why. I guess the 802. groups will = figure it out one day and fix it. But Ethernet Adaptation Layer (named 'bridging' by you?) works ok. > - ipwave 4.2 it states "IP packets are transmitted over 802.11-OCB as=20 > standard Ethernet packets. As with all 802.11 frames, an Ethernet =20 > adaptation layer MUST be used with 802.11-OCB as well." Again EAL is =20 > stipulated as a requirement. And I'm not sure about the stipulation =20 > that packets are transmitted as "standard Ethernet packets", is this =20 > accurate? YEs. I verify it this way: Use available Wireshark tool on WiFi interface, enable IPv6 on the = computer, and dump some IPv6 packets. They all have EthernetII headers, = rather than LLC and 802.11 headers. Then capture the same in 'monitor' mode, or 'mon' interface in 802.11 OCB, and the .11/LLC headers will = show instead. > Does this mean that 802.3 headers are included? The EthernetII headers (not 802.3 Ethernet, I believe different) are = included in the processing during the execution of this EAL. But these = EthernetII headers are not sent on the 802.11 air. > This is definitely not stipulated in 1609.3. Packets transmitted over=20 > OCB by a WAVE device using 1609.3 are well formed IPv6 packets, but=20 > not "Ethernet packets", i.e., no 802.3 headers are included. This=20 > seems like an interoperability problem between ipwave and 1609 WAVE. The packets put on the air on 802.11-OCB links with the IPv6-over-OCB = draft do not include EthernetII headers. SO I do not think there is an = interop problem 1609 WAVE with IPv6-over-OCB draft. >=20 >> 2. It is not clear that ipwave provides any functionality=20 >> that 1609 WAVE does not already provide. >=20 > Well, 1609 WAVE does not specify the conversion between .11/LLC=20 > headers and EthernetII headers, right? >=20 > [KS]: Correct it does not, as this topic is out of scope for 1609 WAVE = > (e.g., we don't specify the other interfaces such as Ethernet that may = > be present in the device). Also see my comments above regarding the=20 > EAL. It is in scope here. Maybe 1609 document can refer to here. > 1609 WAVE does not specify the MTU size for IPv6, right? >=20 > [KS]: No it does not. 802.11 (normative to 1609) specifies maximum=20 > MSDU size as 2304 octets. For WSMP 1609.3 specifies a maximum MSDU=20 > size of 2302 (allowing for the 2-octet LLC header), and a default=20 > value of 1400. You are correct in that a MSDU size for IPv6 is not=20 > specified explicitly, but I don't know if some other RFCs related to > IPv6 over 802.11 already do that? Regardless, stipulating a default =20 > value of 1500 for MTU size does not violate anything in 1609.3. Noted. For explanation, the figure 1500 for MTU for IPv6-over-OCB comes from = implementations inheriting from old Ethernet behaviour. We dont want to = break that. Moreover, it is compatible with RFC8200 (IPv6) which = requires the minimum MTU to be at least 1280bytes for all links = supporting IPv6. IPv6 people are aware that many links do support more than 1500bytes = MTU. I heard of 10000bytes for some core links. Yet the IPv6-over-foo = for these links do not require the MTU 10000bytes. >=20 > 1609 WAVE does not specify that IPv6 must be preceded by .11 QoSData =20 > (not just .11 Data), and BACKGROUND, right? >=20 > [KS]: Certainly 1609 does not. 1609 only restricts IPv6 packets to the = > SCH (they are not allowed on the CCH). 802.11 specifies defaults for=20 > all UP and AC parameters, indicates which frame types are allowed,=20 > etc. But as far as I can tell the stipulation that IPv6 use QoSData=20 > and AC_BK is new and something that ipwave introduces? It seems so. People agree with it. > Again, I'm not an expert on this topic and I believe others in the > 1609 WG have been discussing this with the ipwave list. Regardless,=20 > this additional restriction does not violate 1609.3. >=20 > 1609 WAVE does not recommend in particular RFC8064 to form=20 > semantically opaque Interface Identifiers, right? >=20 > [KS]: 1609 does not recommend anything like this, but on the other=20 > hand 1609 does not prohibit it either. 1609 does not generally=20 > speaking "recommend", rather it "specifies" and leaves all else up to=20 > the system designer/implementer/deployer. And as mentioned previously, = > 1609 allows any and all IETF protocols to be implemented. > Regardless, this recommendation does not violate anything in 1609.3. Noted. >=20 > (and a few others). >=20 >> 1609 WAVE includes a number of mechanisms that enable IPv6 networks=20 >> to be configured. In addition to the WSA/WRA mechanism, 1609.3 allows = >> any IETF protocols to be implemented, e.g., IETF RFC 4861, Neighbor=20 >> Discovery for IP Version 6 (IPv6) (which is listed as a normative=20 >> reference in 1609.3). Helpful would be some example use-cases that=20 >> illustrate problems to be solved, and how ipwave will solve those=20 >> problems (i.e., that 1609 WAVE does not already solve). >=20 > There is a draft that describes some use-cases of IPv6 in vehicular > networks: draft-ietf-ipwave-vehicular-networking-02 >=20 > [KS]: Thanks for pointing me to that, lots of info there! I'll spend =20 > some time reviewing that when I can. >=20 > I think some parts of 1609 WAVE, in particular WRA, are not used in=20 > Europe. Whereas this IPv6-over-OCB draft is used the same wherever=20 > Internet is present (Europe, America, Continents). >=20 > [KS]: 1609 went to great lengths to harmonize WSM and WSA frame=20 > formats with ISO/ETSI standards, these harmonized frames are included=20 > in all of the -2016 revisions to 1609. So for example the 1609.3 WSA=20 > is interoperable with the service advertisement used in Europe. See=20 > ISO 16460, and see also ETSI TS 102 890-1. I agree harmonization is good and needed. In case that harmonization relies on IPv6 as specified at IETF, these = are my comments to the ETSI document. Quickly skimming, it calls it "IPv6 routing advertisement". It is "IPv6 = Router Advertisement". The 'default' route is used when no other route is available. The = 'default' route typically gives access to the Internet, not to one = particular server ("ITS-S": station). For particular servers, one may = use RFC4191 instead, for "more specific routes" or, the routes known as = 'host-based routes'. Thank you for the comments. Alex >> My concern is that the IETF ipwave document may cause significant=20 >> confusion among deployers, and possibly lead to a lack of=20 >> interoperability. Thank you for the opportunity to comment, I look=20 >> forward to the discussion. >=20 > I would like to help with clarification. Let us discuss this. >=20 > [KS]: Sounds good! >=20 > Alex >=20 >>=20 >>=20 >>=20 >> Best regards, >>=20 >> Kevin >=20 > _______________________________________________ its mailing list=20 > its@ietf.org https://www.ietf.org/mailman/listinfo/its >=20 >=20 From nobody Sat Mar 17 12:56: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 5E6FA12D864 for ; Sat, 17 Mar 2018 12:56:39 -0700 (PDT) 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, RCVD_IN_MSPIKE_H2=-0.001, 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 KVhmZTKH6NKW for ; Sat, 17 Mar 2018 12:56:36 -0700 (PDT) Received: from fed1rmfepo102.cox.net (fed1rmfepo102.cox.net [68.230.241.144]) by ietfa.amsl.com (Postfix) with ESMTP id B950B12D7F2 for ; Sat, 17 Mar 2018 12:56:35 -0700 (PDT) Received: from fed1rmimpo109.cox.net ([68.230.241.158]) by fed1rmfepo102.cox.net (InterMail vM.8.01.05.28 201-2260-151-171-20160122) with ESMTP id <20180317195635.UOUX4561.fed1rmfepo102.cox.net@fed1rmimpo109.cox.net> for ; Sat, 17 Mar 2018 15:56:35 -0400 Received: from smithPC ([174.68.115.141]) by fed1rmimpo109.cox.net with cox id P7wa1x00L336m1J017wa1N; Sat, 17 Mar 2018 15:56:34 -0400 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A090202.5AAD72F3.0006, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.2 cv=cPmQihWN c=1 sm=1 tr=0 a=lZ+2k6HZ6QqstbCzvfe+bA==:117 a=lZ+2k6HZ6QqstbCzvfe+bA==:17 a=IkcTkHD0fZMA:10 a=x7bEGLp0ZPQA:10 a=kGgg9RDvKM0A:10 a=48vgC7mUAAAA:8 a=A1EfXRNyAAAA:8 a=pGLkceISAAAA:8 a=kviXuzpPAAAA:8 a=0bAklNMHpULIHRkONBkA:9 a=51OqeD2nzYkhX__1:21 a=1RrL5Q6ptIhjmTgf:21 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=ho1zAXZTouNDp1r8zZ_w:22 a=qrIFiuKZe2vaD64auk6j:22 X-CM-Score: 0.00 Authentication-Results: cox.net; auth=pass (LOGIN) smtp.auth=kevin.s.smith@cox.net From: "Kevin Smith" To: "'Tijink Jasja'" , "'Alexandre Petrescu'" Cc: References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> In-Reply-To: Date: Sat, 17 Mar 2018 12:56:41 -0700 Message-ID: <004101d3be2a$116baed0$34430c70$@cox.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGhOrR8o8b5YryKQCC/S9k90bJ5fwGaWEJkAgugfycB2ExIegHFOIJRo//AvKA= Content-Language: en-us Archived-At: Subject: Re: [ipwave] FW: ipwave - comments and concerns - 1609 WAVE, EPD - 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: Sat, 17 Mar 2018 19:56:39 -0000 Addendum: Looking at RFC 2464, I see in clause 3. Frame Format the = statement "IPv6 packets are transmitted in standard Ethernet frames."=20 Which of course exactly matches the text I'm questioning in ipwave. So I = see where it comes from. But considering that RFC 2464 was last updated = almost 20 years ago, perhaps the statement is no longer the best way to = describe how IPv6 packets are encapsulated at L2? Anyway, I'm really out of my element here, just doing research. My input = is based on my own experiences and interpretations, having been involved = in 1609 stack development and developing products using 1609 WAVE since = 2005. So when I read ipwave, I was (and still am on some issues) = confused. So hopefully all of this discussion will result in an ipwave = document that clarifies some areas and is less confusing to many of us = in the 1609 WAVE community. I appreciate the discussion. Regards, Kevin P.S. Please do see my comments immediately below ... -----Original Message----- From: its [mailto:its-bounces@ietf.org] On Behalf Of Kevin Smith Sent: Saturday, March 17, 2018 12:26 PM To: 'Tijink Jasja' ; 'Alexandre Petrescu' = Cc: its@ietf.org Subject: Re: [ipwave] FW: ipwave - comments and concerns - 1609 WAVE, = EPD - towards resolution Hi Alex, I have the same concern as does Jasja regarding the statement found in = the draft: "IP packets are transmitted over 802.11-OCB as standard = Ethernet packets." I believe that statement is technically incorrect, or at best very = confusing. The term "Ethernet" is widely used to refer to wired networks = specified by IEEE 802.3. Ethernet II (or Ethernet Version 2) is one type = of Ethernet frame format, and the one most widely used in IP networks. = There are others. I'm unsure exactly where Ethernet II is specified, = originally is was specified in "Digital Equipment Corporation, Intel, = Xerox, The Ethernet, Version 2.0, November 1982.", but it must have been = incorporated into 802.3 or perhaps some IETF RFCs? I'd propose the text be revised to something more specific like this: = "IPv6 packets are transmitted over 802.11-OCB as QoS Data frames as = specified in IEEE Std 802.11."=20 Note also I changed "IP" to "IPv6".=20 Regards, Kevin -----Original Message----- From: Tijink Jasja [mailto:Jasja.Tijink@kapsch.net]=20 Sent: Saturday, March 17, 2018 5:37 AM To: Alexandre Petrescu ; Kevin Smith = Cc: its@ietf.org Subject: AW: FW: [ipwave] ipwave - comments and concerns - 1609 WAVE, = EPD - towards resolution Hi Alex, on the EAL topic. Take again the following text from the draft: " IP packets are transmitted over 802.11-OCB as standard Ethernet packets. As with all 802.11 frames, an Ethernet adaptation layer MUST be used with 802.11-OCB as well." I understand the second sentence is a requirement you put to = implementations that feature an ethernet interface and an 802.11 = interface.=20 But the first sentence: that one seems not true to me according to what = you report of your own tests - 802.11 packets do not have ethernet = headers. So the first sentence is incorrect, right? Or do I simply = misunderstand it and what you want to say is:=20 "IP packets are transmitted over 802.11-OCB as over standard Ethernet: = as with all 802.11 frames, an Ethernet adaptation layer MUST be used = with 802.11-OCB as well." Regards Jasja -----Urspr=C3=BCngliche Nachricht----- Von: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com]=20 Gesendet: Samstag, 17. M=C3=A4rz 2018 13:10 An: Kevin Smith Cc: Tijink Jasja ; its@ietf.org Betreff: Re: FW: [ipwave] ipwave - comments and concerns - 1609 WAVE, = EPD - towards resolution Le 16/03/2018 =C3=A0 18:34, Kevin Smith a =C3=A9crit : [...] > I suggest that in section 4.2.1 "Ethernet Adaptation Layer" we add the = > following paragraph: >=20 >> The IPv6 packet transmitted on 802.11-OCB MUST be immediately=20 >> preceded by a Logical Link Control (LLC) header and an 802.11 header. = >> In the LLC header, and in accordance with the EtherType Protocol=20 >> Discrimination (EPD), the value of the Type field MUST be set to=20 >> 0x86DD (IPv6). In the 802.11 header, the value of the Subtype=20 >> sub-field in the Frame Control field MUST be set to 8 (i.e. >> 'QoS Data'); the value of the Traffic Identifier (TID) sub-field of=20 >> the QoS Control field of the 802.11 header MUST be set to binary >> 001 (i.e. User Priority 'Background', QoS Access Category 'AC_BK'). >>=20 >> In the Ethernet II header, the value of the Type field MUST be set =20 >> to 0x86DD (IPv6). >=20 > Do you agree with this text? >=20 > [KS]: I agree with the part that addresses the LLC header. I don't=20 > disagree with the part addressing the 802.11 header, I'm just not an =20 > expert in this area and so defer to others. I believe that others in =20 > the 1609 WG have been discussing this with the ipwave list? Noted. Others have discussed the QoS part and there seems to be agreement with = that. >> I note that ipwave mentions EPD, but also SNAP and does not specify=20 >> which method to use. >=20 > I propose we remove this phrase: >> Other alternative views of layering are EtherType Protocol=20 >> Discrimination (EPD), see Appendix E, and SNAP see [RFC1042]. >=20 > Do you agree? >=20 > [KS]: Yes. Noted. >> Moreover ipwave discusses an abstract "Ethernet Adaptation Layer"=20 >> but does not specify a header format, and this further confuses the=20 >> question for deployers - what should we implement? >=20 > The Ethernet Adaptation Layer (more precisely 802.11-to-Ethernet AL) =20 > is not so abstract, because it is widely implemented. This layer does=20 > conversion between headers: at reception from the network it=20 > transforms a .11/LLC header into an EthernetII header; reversely, at =20 > sending it transforms an EthernetII header into a .11/LLC header. > This is shown in Figure 1. >=20 > The EAL does not intend to specify a header format. The header formats = > involved are the IEEE 802.11, LLC and EthernetII. The fields in these = > headers are specified by IEEE. >=20 > [KS]: I don't understand why the EAL is relevant to "Transmission of > IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the = > Context of a Basic Service Set". If I want to write software that=20 > sends IPv6 packets over 802.11 OCB, all I need to know is how to=20 > construct the LLC sublayer header, etc. The EAL sounds like a=20 > "bridge", and perhaps belongs in a separate document (and perhaps has=20 > already been addressed in some existing document?) We wanted to have IPv6-over-OCB document that is minimal change from = existing works: RFC 2464 IPv6-over-Ethernet and implementations. In implementations, that's how IPv6 works: whenever IPv6 stack wants to = sit on a link layer (802.15.4, WiFi, LTE) it actually sits on an = Adaptation Layer. Because IPv6 only knows Ethernet (RFC2464). Whenever a new link layer technology appears, people struggle to make it = first look like Ethernet. Only then does IPv6 run easily on it. Because of that, I tend to agree it could makes sense to make an IPv6-over-802.11 document first (including EAL), and the OCB version after. The OCB version would be much smaller. At the same time, such document IPv6-over-802.11 does not exist. It = could not be developped in the IPWAVE WG which is aiming at vehicle = networking, not .11 in general. It would take so long to create a new IPv6-over-.11 document, and only = then to advance the IPv6-over-OCB draft. An additional reason as to why it would take long is that the mapping of IPv6 fields on 802.11 fields is not straightforward at all. (QoS is one = aspect, but there is also frag fields, security and more). > Regardless, including a description of the EAL does not violate=20 > anything in 1609.3, as it is out of scope with 1609.3. Noted. >=20 > Some *new comments* from my side: >=20 > - ipwave 4.2.1 it states "An 'adaptation' layer is inserted between a=20 > MAC layer and the Networking layer." This sounds like a requirement. > If I am developing a product that is only concerned with sending IPv6=20 > over OCB, and does not require "bridging", then how do I reconcile=20 > this requirement? It is a requirement indeed. But the adaptation layer is already there, = do not worry. If one develops a new product, one is likely to use existing kernels - = they do include EAL, even though they dont call it so. If one develops from scratch (very rare), one would have to answer = questions like how does Frag fields map between IPv6 and 802.11, = security, and other very complicated questions. Agreement would be needed too. I think one will rather prefer too to rely on Ethernet (RFC2464), as so many other people did in the past. "Bridging": I do not know what you mean by 'bridging'? In linux = bridging is a tool called 'brctl'. It bridges two distinct interfaces, = e.g. an Ethernet interface to a WiFi interface. Here we would 'bridge' Ethernet and 802.11 on the same interface. It's not 'bridging', it's = 'adaptation'. Worse: 'brctl' does not work when we want to 'bridge' a OCB interface to = an Ethernet interface. I do not why. I guess the 802. groups will = figure it out one day and fix it. But Ethernet Adaptation Layer (named 'bridging' by you?) works ok. > - ipwave 4.2 it states "IP packets are transmitted over 802.11-OCB as=20 > standard Ethernet packets. As with all 802.11 frames, an Ethernet =20 > adaptation layer MUST be used with 802.11-OCB as well." Again EAL is =20 > stipulated as a requirement. And I'm not sure about the stipulation =20 > that packets are transmitted as "standard Ethernet packets", is this =20 > accurate? YEs. I verify it this way: Use available Wireshark tool on WiFi interface, enable IPv6 on the = computer, and dump some IPv6 packets. They all have EthernetII headers, = rather than LLC and 802.11 headers. Then capture the same in 'monitor' mode, or 'mon' interface in 802.11 OCB, and the .11/LLC headers will = show instead. > Does this mean that 802.3 headers are included? The EthernetII headers (not 802.3 Ethernet, I believe different) are = included in the processing during the execution of this EAL. But these = EthernetII headers are not sent on the 802.11 air. > This is definitely not stipulated in 1609.3. Packets transmitted over=20 > OCB by a WAVE device using 1609.3 are well formed IPv6 packets, but=20 > not "Ethernet packets", i.e., no 802.3 headers are included. This=20 > seems like an interoperability problem between ipwave and 1609 WAVE. The packets put on the air on 802.11-OCB links with the IPv6-over-OCB = draft do not include EthernetII headers. SO I do not think there is an = interop problem 1609 WAVE with IPv6-over-OCB draft. >=20 >> 2. It is not clear that ipwave provides any functionality=20 >> that 1609 WAVE does not already provide. >=20 > Well, 1609 WAVE does not specify the conversion between .11/LLC=20 > headers and EthernetII headers, right? >=20 > [KS]: Correct it does not, as this topic is out of scope for 1609 WAVE = > (e.g., we don't specify the other interfaces such as Ethernet that may = > be present in the device). Also see my comments above regarding the=20 > EAL. It is in scope here. Maybe 1609 document can refer to here. > 1609 WAVE does not specify the MTU size for IPv6, right? >=20 > [KS]: No it does not. 802.11 (normative to 1609) specifies maximum=20 > MSDU size as 2304 octets. For WSMP 1609.3 specifies a maximum MSDU=20 > size of 2302 (allowing for the 2-octet LLC header), and a default=20 > value of 1400. You are correct in that a MSDU size for IPv6 is not=20 > specified explicitly, but I don't know if some other RFCs related to > IPv6 over 802.11 already do that? Regardless, stipulating a default =20 > value of 1500 for MTU size does not violate anything in 1609.3. Noted. For explanation, the figure 1500 for MTU for IPv6-over-OCB comes from = implementations inheriting from old Ethernet behaviour. We dont want to = break that. Moreover, it is compatible with RFC8200 (IPv6) which = requires the minimum MTU to be at least 1280bytes for all links = supporting IPv6. IPv6 people are aware that many links do support more than 1500bytes = MTU. I heard of 10000bytes for some core links. Yet the IPv6-over-foo = for these links do not require the MTU 10000bytes. >=20 > 1609 WAVE does not specify that IPv6 must be preceded by .11 QoSData =20 > (not just .11 Data), and BACKGROUND, right? >=20 > [KS]: Certainly 1609 does not. 1609 only restricts IPv6 packets to the = > SCH (they are not allowed on the CCH). 802.11 specifies defaults for=20 > all UP and AC parameters, indicates which frame types are allowed,=20 > etc. But as far as I can tell the stipulation that IPv6 use QoSData=20 > and AC_BK is new and something that ipwave introduces? It seems so. People agree with it. > Again, I'm not an expert on this topic and I believe others in the > 1609 WG have been discussing this with the ipwave list. Regardless,=20 > this additional restriction does not violate 1609.3. >=20 > 1609 WAVE does not recommend in particular RFC8064 to form=20 > semantically opaque Interface Identifiers, right? >=20 > [KS]: 1609 does not recommend anything like this, but on the other=20 > hand 1609 does not prohibit it either. 1609 does not generally=20 > speaking "recommend", rather it "specifies" and leaves all else up to=20 > the system designer/implementer/deployer. And as mentioned previously, = > 1609 allows any and all IETF protocols to be implemented. > Regardless, this recommendation does not violate anything in 1609.3. Noted. >=20 > (and a few others). >=20 >> 1609 WAVE includes a number of mechanisms that enable IPv6 networks=20 >> to be configured. In addition to the WSA/WRA mechanism, 1609.3 allows = >> any IETF protocols to be implemented, e.g., IETF RFC 4861, Neighbor=20 >> Discovery for IP Version 6 (IPv6) (which is listed as a normative=20 >> reference in 1609.3). Helpful would be some example use-cases that=20 >> illustrate problems to be solved, and how ipwave will solve those=20 >> problems (i.e., that 1609 WAVE does not already solve). >=20 > There is a draft that describes some use-cases of IPv6 in vehicular > networks: draft-ietf-ipwave-vehicular-networking-02 >=20 > [KS]: Thanks for pointing me to that, lots of info there! I'll spend =20 > some time reviewing that when I can. >=20 > I think some parts of 1609 WAVE, in particular WRA, are not used in=20 > Europe. Whereas this IPv6-over-OCB draft is used the same wherever=20 > Internet is present (Europe, America, Continents). >=20 > [KS]: 1609 went to great lengths to harmonize WSM and WSA frame=20 > formats with ISO/ETSI standards, these harmonized frames are included=20 > in all of the -2016 revisions to 1609. So for example the 1609.3 WSA=20 > is interoperable with the service advertisement used in Europe. See=20 > ISO 16460, and see also ETSI TS 102 890-1. I agree harmonization is good and needed. In case that harmonization relies on IPv6 as specified at IETF, these = are my comments to the ETSI document. Quickly skimming, it calls it "IPv6 routing advertisement". It is "IPv6 = Router Advertisement". The 'default' route is used when no other route is available. The = 'default' route typically gives access to the Internet, not to one = particular server ("ITS-S": station). For particular servers, one may = use RFC4191 instead, for "more specific routes" or, the routes known as = 'host-based routes'. Thank you for the comments. Alex >> My concern is that the IETF ipwave document may cause significant=20 >> confusion among deployers, and possibly lead to a lack of=20 >> interoperability. Thank you for the opportunity to comment, I look=20 >> forward to the discussion. >=20 > I would like to help with clarification. Let us discuss this. >=20 > [KS]: Sounds good! >=20 > Alex >=20 >>=20 >>=20 >>=20 >> Best regards, >>=20 >> Kevin >=20 > _______________________________________________ its mailing list=20 > its@ietf.org https://www.ietf.org/mailman/listinfo/its >=20 >=20 _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its From nobody Sat Mar 17 13:05: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 8931112D7F2 for ; Sat, 17 Mar 2018 13:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.583 X-Spam-Level: X-Spam-Status: No, score=-0.583 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] 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 lOI1yeVF6oSl for ; Sat, 17 Mar 2018 13:05:53 -0700 (PDT) Received: from fed1rmfepo203.cox.net (fed1rmfepo203.cox.net [68.230.241.148]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC9F120724 for ; Sat, 17 Mar 2018 13:05:53 -0700 (PDT) Received: from fed1rmimpo209.cox.net ([68.230.241.160]) by fed1rmfepo203.cox.net (InterMail vM.8.01.05.28 201-2260-151-171-20160122) with ESMTP id <20180317200552.OFXS4590.fed1rmfepo203.cox.net@fed1rmimpo209.cox.net> for ; Sat, 17 Mar 2018 16:05:52 -0400 Received: from smithPC ([174.68.115.141]) by fed1rmimpo209.cox.net with cox id P85s1x006336m1J0185sp5; Sat, 17 Mar 2018 16:05:52 -0400 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A090201.5AAD7520.0047, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.2 cv=OZToNlbY c=1 sm=1 tr=0 a=lZ+2k6HZ6QqstbCzvfe+bA==:117 a=lZ+2k6HZ6QqstbCzvfe+bA==:17 a=IkcTkHD0fZMA:10 a=x7bEGLp0ZPQA:10 a=kGgg9RDvKM0A:10 a=48vgC7mUAAAA:8 a=kviXuzpPAAAA:8 a=A1EfXRNyAAAA:8 a=F0RCBN4kDVXiG_8pEqoA:9 a=xjT2ggPoHVJ2ujYH:21 a=zAWjDdtKHz4bgzFZ:21 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=qrIFiuKZe2vaD64auk6j:22 a=ho1zAXZTouNDp1r8zZ_w:22 X-CM-Score: 0.00 Authentication-Results: cox.net; auth=pass (LOGIN) smtp.auth=kevin.s.smith@cox.net From: "Kevin Smith" To: "'Alexandre Petrescu'" Cc: "'Tijink Jasja'" , References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> In-Reply-To: Date: Sat, 17 Mar 2018 13:05:58 -0700 Message-ID: <004401d3be2b$5dc99700$195cc500$@cox.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGhOrR8o8b5YryKQCC/S9k90bJ5fwGaWEJkAwrZTaakFIKW8A== Content-Language: en-us Archived-At: Subject: Re: [ipwave] FW: ipwave - comments and concerns - 1609 WAVE, EPD - 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: Sat, 17 Mar 2018 20:05:55 -0000 Hi Alex, Thanks for the responses. I've responded separately regarding the = "standard Ethernet packets" text, but had some other comments. Additional comments follow denoted with *****[KS] to help you find them = (as this email getting quite long).=20 Thanks, Kevin -----Original Message----- From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu Sent: Saturday, March 17, 2018 5:10 AM To: Kevin Smith Cc: 'Tijink Jasja' ; its@ietf.org Subject: Re: [ipwave] FW: ipwave - comments and concerns - 1609 WAVE, = EPD - towards resolution Le 16/03/2018 =C3=A0 18:34, Kevin Smith a =C3=A9crit : [...] > I suggest that in section 4.2.1 "Ethernet Adaptation Layer" we add the = > following paragraph: >=20 >> The IPv6 packet transmitted on 802.11-OCB MUST be immediately=20 >> preceded by a Logical Link Control (LLC) header and an 802.11 header. = >> In the LLC header, and in accordance with the EtherType Protocol=20 >> Discrimination (EPD), the value of the Type field MUST be set to=20 >> 0x86DD (IPv6). In the 802.11 header, the value of the Subtype=20 >> sub-field in the Frame Control field MUST be set to 8 (i.e. >> 'QoS Data'); the value of the Traffic Identifier (TID) sub-field of=20 >> the QoS Control field of the 802.11 header MUST be set to binary >> 001 (i.e. User Priority 'Background', QoS Access Category 'AC_BK'). >>=20 >> In the Ethernet II header, the value of the Type field MUST be set =20 >> to 0x86DD (IPv6). >=20 > Do you agree with this text? >=20 > [KS]: I agree with the part that addresses the LLC header. I don't=20 > disagree with the part addressing the 802.11 header, I'm just not an =20 > expert in this area and so defer to others. I believe that others in =20 > the 1609 WG have been discussing this with the ipwave list? Noted. Others have discussed the QoS part and there seems to be agreement with = that. >> I note that ipwave mentions EPD, but also SNAP and does not specify=20 >> which method to use. >=20 > I propose we remove this phrase: >> Other alternative views of layering are EtherType Protocol=20 >> Discrimination (EPD), see Appendix E, and SNAP see [RFC1042]. >=20 > Do you agree? >=20 > [KS]: Yes. Noted. >> Moreover ipwave discusses an abstract "Ethernet Adaptation Layer"=20 >> but does not specify a header format, and this further confuses the=20 >> question for deployers - what should we implement? >=20 > The Ethernet Adaptation Layer (more precisely 802.11-to-Ethernet AL) =20 > is not so abstract, because it is widely implemented. This layer does=20 > conversion between headers: at reception from the network it=20 > transforms a .11/LLC header into an EthernetII header; reversely, at =20 > sending it transforms an EthernetII header into a .11/LLC header. > This is shown in Figure 1. >=20 > The EAL does not intend to specify a header format. The header formats = > involved are the IEEE 802.11, LLC and EthernetII. The fields in these = > headers are specified by IEEE. >=20 > [KS]: I don't understand why the EAL is relevant to "Transmission of > IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the = > Context of a Basic Service Set". If I want to write software that=20 > sends IPv6 packets over 802.11 OCB, all I need to know is how to=20 > construct the LLC sublayer header, etc. The EAL sounds like a=20 > "bridge", and perhaps belongs in a separate document (and perhaps has=20 > already been addressed in some existing document?) We wanted to have IPv6-over-OCB document that is minimal change from = existing works: RFC 2464 IPv6-over-Ethernet and implementations. In implementations, that's how IPv6 works: whenever IPv6 stack wants to = sit on a link layer (802.15.4, WiFi, LTE) it actually sits on an = Adaptation Layer. Because IPv6 only knows Ethernet (RFC2464). Whenever a new link layer technology appears, people struggle to make it = first look like Ethernet. Only then does IPv6 run easily on it. Because of that, I tend to agree it could makes sense to make an IPv6-over-802.11 document first (including EAL), and the OCB version after. The OCB version would be much smaller. At the same time, such document IPv6-over-802.11 does not exist. It = could not be developped in the IPWAVE WG which is aiming at vehicle = networking, not .11 in general. It would take so long to create a new IPv6-over-.11 document, and only = then to advance the IPv6-over-OCB draft. An additional reason as to why it would take long is that the mapping of IPv6 fields on 802.11 fields is not straightforward at all. (QoS is one = aspect, but there is also frag fields, security and more). *****[KS]: OK thanks for the explanation. > Regardless, including a description of the EAL does not violate=20 > anything in 1609.3, as it is out of scope with 1609.3. Noted. >=20 > Some *new comments* from my side: >=20 > - ipwave 4.2.1 it states "An 'adaptation' layer is inserted between a=20 > MAC layer and the Networking layer." This sounds like a requirement. > If I am developing a product that is only concerned with sending IPv6=20 > over OCB, and does not require "bridging", then how do I reconcile=20 > this requirement? It is a requirement indeed. But the adaptation layer is already there, = do not worry. If one develops a new product, one is likely to use existing kernels - = they do include EAL, even though they dont call it so. If one develops from scratch (very rare), one would have to answer = questions like how does Frag fields map between IPv6 and 802.11, = security, and other very complicated questions. Agreement would be needed too. I think one will rather prefer too to rely on Ethernet (RFC2464), as so many other people did in the past. *****[KS]: Sure, but if developers are re-using existing implementations = they don't really need a standard, except to perhaps explain how it = should have been implemented. The primary reason to have standards is to = enable interoperability, and instructs those developing new (or perhaps = debugging old) implementations as to how to create (or maintain) = products that play well with others.=20 "Bridging": I do not know what you mean by 'bridging'? In linux = bridging is a tool called 'brctl'. It bridges two distinct interfaces, = e.g. an Ethernet interface to a WiFi interface. Here we would 'bridge' Ethernet and 802.11 on the same interface. It's not 'bridging', it's = 'adaptation'. *****[KS]: Bridging, is as you describe, e.g., bridging two distinct = physical interfaces. What confuses me is your statement: "Here we would = 'bridge' Ethernet and 802.11 on the same interface." This seems = contradictory. The term "Ethernet" is widely used to describe wired = Ethernet as described in IEEE 802.3. So "Ethernet" is one physical = interface, and 802.11 is a different physical interface. But I'm = starting to believe that this may be where we are crossing our wires, so = to speak.=20 ***** What I'm gathering is that ipwave assumes that an Ethernet II = frame will be received, and need to be "adapted" to an 802.11 frame = format so that it may be transmitted 802.11-OCB. If this is the case, = then perhaps the ipwave document is not clear enough about this. And = again, I'm making an assumption here, but should the name of the = document be titled something like "Adaptation of Ethernet II frames for = Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode = Outside the Context of a Basic Service Set"? Worse: 'brctl' does not work when we want to 'bridge' a OCB interface to = an Ethernet interface. I do not why. I guess the 802. groups will = figure it out one day and fix it. But Ethernet Adaptation Layer (named 'bridging' by you?) works ok. > - ipwave 4.2 it states "IP packets are transmitted over 802.11-OCB as=20 > standard Ethernet packets. As with all 802.11 frames, an Ethernet =20 > adaptation layer MUST be used with 802.11-OCB as well." Again EAL is =20 > stipulated as a requirement. And I'm not sure about the stipulation =20 > that packets are transmitted as "standard Ethernet packets", is this =20 > accurate? YEs. I verify it this way: Use available Wireshark tool on WiFi interface, enable IPv6 on the = computer, and dump some IPv6 packets. They all have EthernetII headers, = rather than LLC and 802.11 headers. Then capture the same in 'monitor' mode, or 'mon' interface in 802.11 OCB, and the .11/LLC headers will = show instead. *****[KS]: I've read that packet captures from Wireshark and tcpdump = display frames received from 802.11 adapters this way, and they are = referred to as "fake Ethernet" frames. This is a function of the = software drivers apparently, and for some reason they deliver these = "fake Ethernet" frames to capture software like Wireshark. If you use = monitor mode then you get the "true" 802.11 frame representation of = received frames, not the "fake Ethernet" frames. Monitor mode will show = how the frames are actually received over the 802.11 interface, i.e., as = 802.11 frames and not as Ethernet II frames. > Does this mean that 802.3 headers are included? The EthernetII headers (not 802.3 Ethernet, I believe different) are = included in the processing during the execution of this EAL. But these = EthernetII headers are not sent on the 802.11 air. > This is definitely not stipulated in 1609.3. Packets transmitted over=20 > OCB by a WAVE device using 1609.3 are well formed IPv6 packets, but=20 > not "Ethernet packets", i.e., no 802.3 headers are included. This=20 > seems like an interoperability problem between ipwave and 1609 WAVE. The packets put on the air on 802.11-OCB links with the IPv6-over-OCB = draft do not include EthernetII headers. SO I do not think there is an = interop problem 1609 WAVE with IPv6-over-OCB draft. *****[KS]: I understand, and this is good! But I think the current text = is confusing things by stating that "standard Ethernet packets" are = transmitted over 802.11-OCB (as I wrote about in a separate email). >=20 >> 2. It is not clear that ipwave provides any functionality=20 >> that 1609 WAVE does not already provide. >=20 > Well, 1609 WAVE does not specify the conversion between .11/LLC=20 > headers and EthernetII headers, right? >=20 > [KS]: Correct it does not, as this topic is out of scope for 1609 WAVE = > (e.g., we don't specify the other interfaces such as Ethernet that may = > be present in the device). Also see my comments above regarding the=20 > EAL. It is in scope here. Maybe 1609 document can refer to here. > 1609 WAVE does not specify the MTU size for IPv6, right? >=20 > [KS]: No it does not. 802.11 (normative to 1609) specifies maximum=20 > MSDU size as 2304 octets. For WSMP 1609.3 specifies a maximum MSDU=20 > size of 2302 (allowing for the 2-octet LLC header), and a default=20 > value of 1400. You are correct in that a MSDU size for IPv6 is not=20 > specified explicitly, but I don't know if some other RFCs related to > IPv6 over 802.11 already do that? Regardless, stipulating a default =20 > value of 1500 for MTU size does not violate anything in 1609.3. Noted. For explanation, the figure 1500 for MTU for IPv6-over-OCB comes from = implementations inheriting from old Ethernet behaviour. We dont want to = break that. Moreover, it is compatible with RFC8200 (IPv6) which = requires the minimum MTU to be at least 1280bytes for all links = supporting IPv6. IPv6 people are aware that many links do support more than 1500bytes = MTU. I heard of 10000bytes for some core links. Yet the IPv6-over-foo = for these links do not require the MTU 10000bytes. >=20 > 1609 WAVE does not specify that IPv6 must be preceded by .11 QoSData =20 > (not just .11 Data), and BACKGROUND, right? >=20 > [KS]: Certainly 1609 does not. 1609 only restricts IPv6 packets to the = > SCH (they are not allowed on the CCH). 802.11 specifies defaults for=20 > all UP and AC parameters, indicates which frame types are allowed,=20 > etc. But as far as I can tell the stipulation that IPv6 use QoSData=20 > and AC_BK is new and something that ipwave introduces? It seems so. People agree with it. *****[KS]: Yes sounds like it, all good! > Again, I'm not an expert on this topic and I believe others in the > 1609 WG have been discussing this with the ipwave list. Regardless,=20 > this additional restriction does not violate 1609.3. >=20 > 1609 WAVE does not recommend in particular RFC8064 to form=20 > semantically opaque Interface Identifiers, right? >=20 > [KS]: 1609 does not recommend anything like this, but on the other=20 > hand 1609 does not prohibit it either. 1609 does not generally=20 > speaking "recommend", rather it "specifies" and leaves all else up to=20 > the system designer/implementer/deployer. And as mentioned previously, = > 1609 allows any and all IETF protocols to be implemented. > Regardless, this recommendation does not violate anything in 1609.3. Noted. >=20 > (and a few others). >=20 >> 1609 WAVE includes a number of mechanisms that enable IPv6 networks=20 >> to be configured. In addition to the WSA/WRA mechanism, 1609.3 allows = >> any IETF protocols to be implemented, e.g., IETF RFC 4861, Neighbor=20 >> Discovery for IP Version 6 (IPv6) (which is listed as a normative=20 >> reference in 1609.3). Helpful would be some example use-cases that=20 >> illustrate problems to be solved, and how ipwave will solve those=20 >> problems (i.e., that 1609 WAVE does not already solve). >=20 > There is a draft that describes some use-cases of IPv6 in vehicular > networks: draft-ietf-ipwave-vehicular-networking-02 >=20 > [KS]: Thanks for pointing me to that, lots of info there! I'll spend =20 > some time reviewing that when I can. >=20 > I think some parts of 1609 WAVE, in particular WRA, are not used in=20 > Europe. Whereas this IPv6-over-OCB draft is used the same wherever=20 > Internet is present (Europe, America, Continents). >=20 > [KS]: 1609 went to great lengths to harmonize WSM and WSA frame=20 > formats with ISO/ETSI standards, these harmonized frames are included=20 > in all of the -2016 revisions to 1609. So for example the 1609.3 WSA=20 > is interoperable with the service advertisement used in Europe. See=20 > ISO 16460, and see also ETSI TS 102 890-1. I agree harmonization is good and needed. In case that harmonization relies on IPv6 as specified at IETF, these = are my comments to the ETSI document. Quickly skimming, it calls it "IPv6 routing advertisement". It is "IPv6 = Router Advertisement". The 'default' route is used when no other route is available. The = 'default' route typically gives access to the Internet, not to one = particular server ("ITS-S": station). For particular servers, one may = use RFC4191 instead, for "more specific routes" or, the routes known as = 'host-based routes'. Thank you for the comments. Alex >> My concern is that the IETF ipwave document may cause significant=20 >> confusion among deployers, and possibly lead to a lack of=20 >> interoperability. Thank you for the opportunity to comment, I look=20 >> forward to the discussion. >=20 > I would like to help with clarification. Let us discuss this. >=20 > [KS]: Sounds good! >=20 > Alex >=20 >>=20 >>=20 >>=20 >> Best regards, >>=20 >> Kevin >=20 > _______________________________________________ its mailing list=20 > its@ietf.org https://www.ietf.org/mailman/listinfo/its >=20 >=20 _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its From nobody Sun Mar 18 05:16: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 04DA512704A for ; Sun, 18 Mar 2018 05:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 uS6uX80yebqH for ; Sun, 18 Mar 2018 05:16:48 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C9991270A7 for ; Sun, 18 Mar 2018 05:16:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 171E3300A10 for ; Sun, 18 Mar 2018 08:16:46 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id dOIh0AEWBr_W for ; Sun, 18 Mar 2018 08:16:42 -0400 (EDT) Received: from dhcp-9a0d.meeting.ietf.org (dhcp-9a0d.meeting.ietf.org [31.133.154.13]) by mail.smeinc.net (Postfix) with ESMTPSA id 39C8E3004AA; Sun, 18 Mar 2018 08:16:41 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <67b280e1f9bb4167bc26e3405861504a@HE105715.emea1.cds.t-internal.com> Date: Sun, 18 Mar 2018 08:16:44 -0400 Cc: =?utf-8?Q?Carlos_Jes=C3=BAs_Bernardos_Cano?= , its , Elizabeth.Perry@sae.org, Keith.Wilson@sae.org, Suresh Krishnan , Terry Manderson Content-Transfer-Encoding: quoted-printable Message-Id: <742B6A15-381D-474D-8C41-0128A9396A22@vigilsec.com> References: <151491759052.22648.11984709015990586689.idtracker@ietfa.amsl.com> <67b280e1f9bb4167bc26e3405861504a@HE105715.emea1.cds.t-internal.com> To: Dirk.von-Hugo@telekom.de X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [ipwave] New Liaison Statement, "LS on Establishment of SAE Cellular V2X Technical Committee and Associated Task Forces" X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 18 Mar 2018 12:16:51 -0000 Dear Dirk: The Liaison Statement says: ACTION: The SAE C-V2X welcomes mutual consideration and communication as we jointly standardize applicable interoperability and performance specifications to fully leverage 4G LTE and 5G cellular radio access technologies. That action does not apply to the IETF IPWAVE WG. We are not doing any = work for 4G LTE or 5G. It would seem odd to reply to the formal liaison = statement to say that. Russ > On Mar 16, 2018, at 6:33 AM, Dirk.von-Hugo@telekom.de wrote: >=20 > Dear chairs, > has there been a reply to this LS? > As far as I understand the focus of SAE here includes beside 11p/OCB = also PC5 the cellular sidelink which is not in the charter currently, = right? > The mail didn't mention a deadline for reply but the upcoming SAE = meeting should be completed by now ... > Thanks! > Best Regards > Dirk=20 > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Liaison Statement = Management Tool > Sent: Dienstag, 2. Januar 2018 19:27 > To: Carlos Bernardos ; Russ Housley = > Cc: IP Wireless Access in Vehicular Environments Discussion List = ; Elizabeth.Perry@sae.org; Russ Housley = ; Carlos Bernardos ; = Keith.Wilson@sae.org; Suresh Krishnan ; Terry = Manderson > Subject: [ipwave] New Liaison Statement, "LS on Establishment of SAE = Cellular V2X Technical Committee and Associated Task Forces" >=20 > Title: LS on Establishment of SAE Cellular V2X Technical Committee and = Associated Task Forces Submission Date: 2018-01-02 URL of the IETF Web = page: https://datatracker.ietf.org/liaison/1552/ >=20 > From: Jim Misener > To: Carlos Bernardos ,Russ Housley = > Cc: Russ Housley ,Terry Manderson = ,Carlos Bernardos ,IP = Wireless Access in Vehicular Environments Discussion List = ,Suresh Krishnan Response Contacts: = Elizabeth.Perry@sae.org, Keith.Wilson@sae.org Technical Contacts:=20 > Purpose: For information >=20 > Body: 1. Overall Description: > The SAE Cellular V2X Technical Committee (C-V2X TC) was formed in = June, 2017 with the following charter: >=20 > The SAE Cellular V2X Technical Committee reports to the Vehicle = Engineering Systems Group of the Motor Vehicle Council. The Committee is = responsible for adapting, developing and maintaining SAE Standards, = Recommended Practices, and Information Reports that use cellular radio = access technologies and specifically, evolving 4G LTE and 5G cellular = technologies that require interoperability and performance standards for = road vehicles and other road users in order to use the full capabilities = of these technologies. The committee also coordinates task force efforts = to ensure efficient development and delivery of SAE documents, acts as = liaison to the other organizations involved in the with = vehicular-oriented cellular standards and deployments, and organizes = efforts in gathering requirements for SAE standardization and assigns = them to distributed task forces. > The C-V2X Technical Committee will work closely with the SAE DSRC = Technical Committee and with their documents to assure efficient reuse = and adjustment as appropriate, e.g., strive to maintain a single data = dictionary. Participants in the SAE C-V2X TC include vehicle OEMs, = vehicle suppliers, mobile network operators, mobile network operator = equipment suppliers, mobile handset manufacturers, chipset = manufacturers, road operators, traffic equipment suppliers, consulting = firms, government, and other interested parties. >=20 > At the current time, three Task Forces constitute the C-V2X TC. The = Task Forces and charters are: >=20 > CV2X Advanced Applications Task Force: Develop definitions of terms, = use cases, recommended practices, guidelines, test methods, = specifications and performance standards for vehicles connected using = C-V2X, focusing on advanced V2X applications (i.e., applications that = cannot be supported by DSRC and Rel-14 LTEV2X) that deal with 5G (3GPP = NR and LTE evolution) to leverage enhanced mobile broadband, use of = millimeter wave and other anticipated radio access technologies, and the = next generation core network including enablers such as NFV/SDN, edge = computing, and network slicing. The task force will encourage research = in these areas, and sponsor and facilitate the development of related = standards. The work of this task force will be coordinated with other = task forces in C-V2X Technical Committee, as well as other V2X related = technical committees and standards organizations such as 3GPP, ATIS, GSM = Association, DSRC Technical Committee, On-Road Automated Driving (RAD) = Technical Committee, ITU-T and ETSI. >=20 > CV2X Direct Communication Task Force: Develop definitions of terms, = use cases, recommended practices guidelines, test methods, = specifications and performance standards for vehicles connected using = C-V2X, focusing on safety applications that include cooperative = awareness, warning notification, safe lane change, safe intersection and = roundabout crossing, etc. Important topics of security, reliability, and = quality of service will be part of the charter. The task force will = encourage research in these areas, and sponsor and facilitate the = development of related standards. The work of this task force will be = coordinated with other task forces in CV2X Technical Committee, as well = as other V2X related technical committees and standards organizations = such as DSRC Technical Committee, On-Road Automated Driving (RAD) = Technical Committee, 3GPP, ISO, ITU-T and ETSI. >=20 > CV2X Road Operators Task Force: Work with the ground transportation = operating community to identify its high-level needs and develop = standards, recommended practices, and information reports to address = those needs. >=20 > 2. Actions: >=20 > To (SDOs and industry organizations): >=20 > ACTION: The SAE C-V2X welcomes mutual consideration and communication = as we jointly standardize applicable interoperability and performance = specifications to fully leverage 4G LTE and 5G cellular radio access = technologies. >=20 > 3. Date of Next SAE C-V2X Meetings: > 3rd Wednesday of every month, 1000 Eastern Time US WebEx > 14-15 March, 2018 = Southeast Michigan or Newark NJ (TBD) > Attachments: >=20 > SAE 12302017-1- LS Announcing SAE C-V2X v2final.pdf > = https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2018-01-02-sae-cell-= v2x-ipwave-ls-on-establishment-of-sae-cellular-v2x-technical-committee-and= -associated-task-forces-attachment-1.pdf >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Sun Mar 18 05:40: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 1552012778E for ; Sun, 18 Mar 2018 05:40:13 -0700 (PDT) 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 mkVYwcdHA9MT for ; Sun, 18 Mar 2018 05:40:09 -0700 (PDT) Received: from smtp2.eurecom.fr (smtp2.eurecom.fr [193.55.113.211]) by ietfa.amsl.com (Postfix) with ESMTP id 43555126D3F for ; Sun, 18 Mar 2018 05:40:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.48,325,1517871600"; d="scan'208";a="7793201" Received: from monza.eurecom.fr ([192.168.106.15]) by drago2i.eurecom.fr with ESMTP; 18 Mar 2018 13:40:08 +0100 Received: from xerus29 (unknown [192.168.200.16]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by monza.eurecom.fr (Postfix) with ESMTPSA id 8D2791066; Sun, 18 Mar 2018 13:40:07 +0100 (CET) From: =?iso-8859-1?B?Suly9G1lIEjkcnJp?= To: "'Russ Housley'" , Cc: "'its'" , , =?iso-8859-1?Q?'Carlos_Jes=FAs_Bernardos_Cano'?= , , "'Suresh Krishnan'" , "'Terry Manderson'" References: <151491759052.22648.11984709015990586689.idtracker@ietfa.amsl.com> <67b280e1f9bb4167bc26e3405861504a@HE105715.emea1.cds.t-internal.com> <742B6A15-381D-474D-8C41-0128A9396A22@vigilsec.com> In-Reply-To: <742B6A15-381D-474D-8C41-0128A9396A22@vigilsec.com> Date: Sun, 18 Mar 2018 13:40:07 +0100 Organization: EURECOM Message-ID: <00f601d3beb6$3f415d50$bdc417f0$@eurecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQLRr28BW32gYI0I1LqdO2LT/AUVzgI6ntYjAj2Ndx6htkn/UA== Archived-At: Subject: Re: [ipwave] New Liaison Statement, "LS on Establishment of SAE Cellular V2X Technical Committee and Associated Task Forces" X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 18 Mar 2018 12:40:13 -0000 Dear Russ, All, Indeed, too early to reply. But actually, although the current charter = does not mention it explicitly, and the current IDs WGLC are purely on OCB, = the IPv6 optimizations for vehicular environments that are currently in an = ID state could also fit to C-V2X. Indeed, the C-V2X provides a basic IPv6 functionality (IPv6 support and prefix exchange during L3 link establishment), but leaves 'everything' (except security..not clear at = that stage) on IP to IETF. And on the current prototype we develop, we = already see some issues in handling IP for C-V2X (in Ad-Hoc mode)... So, we should discuss this during the recharter and see: 1) IPWAVE should be L2 agnostic ? 2) Does C-V2X require specific modifications similar to what the ipv6-over-ocb describes for ITS-G5 ? 3) Could the new C-V2X IPv6 optimizations (DNS, IP address continuity, etc..) also apply to C-V2X ? Should we have this also on the agenda for tomorrow? BR, J=E9r=F4me -----Original Message----- From: its [mailto:its-bounces@ietf.org] On Behalf Of Russ Housley Sent: Sunday 18 March 2018 13:17 To: Dirk.von-Hugo@telekom.de Cc: its; Elizabeth.Perry@sae.org; Carlos Jes=FAs Bernardos Cano; Keith.Wilson@sae.org; Suresh Krishnan; Terry Manderson Subject: Re: [ipwave] New Liaison Statement, "LS on Establishment of SAE Cellular V2X Technical Committee and Associated Task Forces" Dear Dirk: The Liaison Statement says: ACTION: The SAE C-V2X welcomes mutual consideration and communication as = we jointly standardize applicable interoperability and performance specifications to fully leverage 4G LTE and 5G cellular radio access technologies. That action does not apply to the IETF IPWAVE WG. We are not doing any work for 4G LTE or 5G. It would seem odd to reply to the formal liaison statement to say that. Russ > On Mar 16, 2018, at 6:33 AM, Dirk.von-Hugo@telekom.de wrote: >=20 > Dear chairs, > has there been a reply to this LS? > As far as I understand the focus of SAE here includes beside 11p/OCB = also PC5 the cellular sidelink which is not in the charter currently, right? > The mail didn't mention a deadline for reply but the upcoming SAE = meeting should be completed by now ... > Thanks! > Best Regards > Dirk > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Liaison Statement = > Management Tool > Sent: Dienstag, 2. Januar 2018 19:27 > To: Carlos Bernardos ; Russ Housley=20 > > Cc: IP Wireless Access in Vehicular Environments Discussion List=20 > ; Elizabeth.Perry@sae.org; Russ Housley=20 > ; Carlos Bernardos ;=20 > Keith.Wilson@sae.org; Suresh Krishnan ; Terry=20 > Manderson > Subject: [ipwave] New Liaison Statement, "LS on Establishment of SAE Cellular V2X Technical Committee and Associated Task Forces" >=20 > Title: LS on Establishment of SAE Cellular V2X Technical Committee and = > Associated Task Forces Submission Date: 2018-01-02 URL of the IETF Web = > page: https://datatracker.ietf.org/liaison/1552/ >=20 > From: Jim Misener > To: Carlos Bernardos ,Russ Housley=20 > > Cc: Russ Housley ,Terry Manderson ,Carlos Bernardos ,IP = Wireless Access in Vehicular Environments Discussion List ,Suresh Krishnan Response Contacts: Elizabeth.Perry@sae.org, Keith.Wilson@sae.org Technical Contacts:=20 > Purpose: For information >=20 > Body: 1. Overall Description: > The SAE Cellular V2X Technical Committee (C-V2X TC) was formed in = June, 2017 with the following charter: >=20 > The SAE Cellular V2X Technical Committee reports to the Vehicle Engineering Systems Group of the Motor Vehicle Council. The Committee is responsible for adapting, developing and maintaining SAE Standards, Recommended Practices, and Information Reports that use cellular radio access technologies and specifically, evolving 4G LTE and 5G cellular technologies that require interoperability and performance standards for road vehicles and other road users in order to use the full capabilities = of these technologies. The committee also coordinates task force efforts to ensure efficient development and delivery of SAE documents, acts as = liaison to the other organizations involved in the with vehicular-oriented = cellular standards and deployments, and organizes efforts in gathering = requirements for SAE standardization and assigns them to distributed task forces. > The C-V2X Technical Committee will work closely with the SAE DSRC Technical Committee and with their documents to assure efficient reuse = and adjustment as appropriate, e.g., strive to maintain a single data dictionary. Participants in the SAE C-V2X TC include vehicle OEMs, = vehicle suppliers, mobile network operators, mobile network operator equipment suppliers, mobile handset manufacturers, chipset manufacturers, road operators, traffic equipment suppliers, consulting firms, government, = and other interested parties. >=20 > At the current time, three Task Forces constitute the C-V2X TC. The = Task Forces and charters are: >=20 > CV2X Advanced Applications Task Force: Develop definitions of terms,=20 > use cases, recommended practices, guidelines, test methods,=20 > specifications and performance standards for vehicles connected using=20 > C-V2X, focusing on advanced V2X applications (i.e., applications that=20 > cannot be supported by DSRC and Rel-14 LTEV2X) that deal with 5G (3GPP = > NR and LTE evolution) to leverage enhanced mobile broadband, use of=20 > millimeter wave and other anticipated radio access technologies, and=20 > the next generation core network including enablers such as NFV/SDN,=20 > edge computing, and network slicing. The task force will encourage=20 > research in these areas, and sponsor and facilitate the development of = > related standards. The work of this task force will be coordinated=20 > with other task forces in C-V2X Technical Committee, as well as other=20 > V2X related technical committees and standards organizations such as=20 > 3GPP, ATIS, GSM Association, DSRC Technical Committee, On-Road=20 > Automated Driving (RAD) Technical Committee , ITU-T and ETSI. >=20 > CV2X Direct Communication Task Force: Develop definitions of terms, = use cases, recommended practices guidelines, test methods, specifications = and performance standards for vehicles connected using C-V2X, focusing on = safety applications that include cooperative awareness, warning notification, = safe lane change, safe intersection and roundabout crossing, etc. Important topics of security, reliability, and quality of service will be part of = the charter. The task force will encourage research in these areas, and = sponsor and facilitate the development of related standards. The work of this = task force will be coordinated with other task forces in CV2X Technical Committee, as well as other V2X related technical committees and = standards organizations such as DSRC Technical Committee, On-Road Automated = Driving (RAD) Technical Committee, 3GPP, ISO, ITU-T and ETSI. >=20 > CV2X Road Operators Task Force: Work with the ground transportation operating community to identify its high-level needs and develop = standards, recommended practices, and information reports to address those needs. >=20 > 2. Actions: >=20 > To (SDOs and industry organizations): >=20 > ACTION: The SAE C-V2X welcomes mutual consideration and communication = as we jointly standardize applicable interoperability and performance specifications to fully leverage 4G LTE and 5G cellular radio access technologies. >=20 > 3. Date of Next SAE C-V2X Meetings: > 3rd Wednesday of every month, 1000 Eastern Time US WebEx > 14-15 March, 2018 Southeast Michigan or Newark NJ (TBD) > Attachments: >=20 > SAE 12302017-1- LS Announcing SAE C-V2X v2final.pdf > =20 > https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2018-01-02-sae-c > ell-v2x-ipwave-ls-on-establishment-of-sae-cellular-v2x-technical-commi > ttee-and-associated-task-forces-attachment-1.pdf >=20 > _______________________________________________ > 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 Sun Mar 18 05:50: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 7598A127873 for ; Sun, 18 Mar 2018 05:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 bQx4I5SxZ5W2 for ; Sun, 18 Mar 2018 05:50:17 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E50A51277BB for ; Sun, 18 Mar 2018 05:50:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C329E300A1D for ; Sun, 18 Mar 2018 08:50:14 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id RkVmEQWFSJVg for ; Sun, 18 Mar 2018 08:50:09 -0400 (EDT) Received: from dhcp-8e33.meeting.ietf.org (dhcp-8e33.meeting.ietf.org [31.133.142.51]) by mail.smeinc.net (Postfix) with ESMTPSA id 3AD753004AA; Sun, 18 Mar 2018 08:50:08 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <00f601d3beb6$3f415d50$bdc417f0$@eurecom.fr> Date: Sun, 18 Mar 2018 08:50:11 -0400 Cc: Dirk.von-Hugo@telekom.de, its , Elizabeth.Perry@sae.org, =?utf-8?Q?Carlos_Jes=C3=BAs_Bernardos_Cano?= , Keith.Wilson@sae.org, Suresh Krishnan , Terry Manderson Content-Transfer-Encoding: quoted-printable Message-Id: References: <151491759052.22648.11984709015990586689.idtracker@ietfa.amsl.com> <67b280e1f9bb4167bc26e3405861504a@HE105715.emea1.cds.t-internal.com> <742B6A15-381D-474D-8C41-0128A9396A22@vigilsec.com> <00f601d3beb6$3f415d50$bdc417f0$@eurecom.fr> To: =?utf-8?B?SsOpcsO0bWUgSMOkcnJp?= X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [ipwave] New Liaison Statement, "LS on Establishment of SAE Cellular V2X Technical Committee and Associated Task Forces" X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 18 Mar 2018 12:50:19 -0000 J=C3=A9r=C3=B4me: The IPWAVE WG charter says: This group's primary deliverable (and the only Standards track item) will be a document that will specify the mechanisms for transmission of IPv6 datagrams over IEEE 802.11-OCB mode. The last 30 minutes of the meeting agenda allow time for discussion of = rechartering. A recharter would be needed to go into the topics that = you suggest. Russ > On Mar 18, 2018, at 8:40 AM, J=C3=A9r=C3=B4me H=C3=A4rri = wrote: >=20 > Dear Russ, All, >=20 > Indeed, too early to reply. But actually, although the current charter = does > not mention it explicitly, and the current IDs WGLC are purely on OCB, = the > IPv6 optimizations for vehicular environments that are currently in an = ID > state could also fit to C-V2X. Indeed, the C-V2X provides a basic IPv6 > functionality (IPv6 support and prefix exchange during L3 link > establishment), but leaves 'everything' (except security..not clear at = that > stage) on IP to IETF. And on the current prototype we develop, we = already > see some issues in handling IP for C-V2X (in Ad-Hoc mode)... >=20 > So, we should discuss this during the recharter and see: > 1) IPWAVE should be L2 agnostic ? > 2) Does C-V2X require specific modifications similar to what the > ipv6-over-ocb describes for ITS-G5 ? > 3) Could the new C-V2X IPv6 optimizations (DNS, IP address continuity, > etc..) also apply to C-V2X ? >=20 > Should we have this also on the agenda for tomorrow? >=20 > BR, >=20 > J=C3=A9r=C3=B4me >=20 > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Russ Housley > Sent: Sunday 18 March 2018 13:17 > To: Dirk.von-Hugo@telekom.de > Cc: its; Elizabeth.Perry@sae.org; Carlos Jes=C3=BAs Bernardos Cano; > Keith.Wilson@sae.org; Suresh Krishnan; Terry Manderson > Subject: Re: [ipwave] New Liaison Statement, "LS on Establishment of = SAE > Cellular V2X Technical Committee and Associated Task Forces" >=20 > Dear Dirk: >=20 > The Liaison Statement says: >=20 > ACTION: The SAE C-V2X welcomes mutual consideration and communication = as we > jointly standardize applicable interoperability and performance > specifications to fully leverage 4G LTE and 5G cellular radio access > technologies. >=20 > That action does not apply to the IETF IPWAVE WG. We are not doing = any > work for 4G LTE or 5G. It would seem odd to reply to the formal = liaison > statement to say that. >=20 > Russ >=20 >=20 >> On Mar 16, 2018, at 6:33 AM, Dirk.von-Hugo@telekom.de wrote: >>=20 >> Dear chairs, >> has there been a reply to this LS? >> As far as I understand the focus of SAE here includes beside 11p/OCB = also > PC5 the cellular sidelink which is not in the charter currently, = right? >> The mail didn't mention a deadline for reply but the upcoming SAE = meeting > should be completed by now ... >> Thanks! >> Best Regards >> Dirk >> -----Original Message----- >> From: its [mailto:its-bounces@ietf.org] On Behalf Of Liaison = Statement=20 >> Management Tool >> Sent: Dienstag, 2. Januar 2018 19:27 >> To: Carlos Bernardos ; Russ Housley=20 >> >> Cc: IP Wireless Access in Vehicular Environments Discussion List=20 >> ; Elizabeth.Perry@sae.org; Russ Housley=20 >> ; Carlos Bernardos ;=20 >> Keith.Wilson@sae.org; Suresh Krishnan ; Terry=20 >> Manderson >> Subject: [ipwave] New Liaison Statement, "LS on Establishment of SAE > Cellular V2X Technical Committee and Associated Task Forces" >>=20 >> Title: LS on Establishment of SAE Cellular V2X Technical Committee = and=20 >> Associated Task Forces Submission Date: 2018-01-02 URL of the IETF = Web=20 >> page: https://datatracker.ietf.org/liaison/1552/ >>=20 >> From: Jim Misener >> To: Carlos Bernardos ,Russ Housley=20 >> >> Cc: Russ Housley ,Terry Manderson > ,Carlos Bernardos ,IP = Wireless > Access in Vehicular Environments Discussion List ,Suresh > Krishnan Response Contacts: = Elizabeth.Perry@sae.org, > Keith.Wilson@sae.org Technical Contacts:=20 >> Purpose: For information >>=20 >> Body: 1. Overall Description: >> The SAE Cellular V2X Technical Committee (C-V2X TC) was formed in = June, > 2017 with the following charter: >>=20 >> The SAE Cellular V2X Technical Committee reports to the Vehicle > Engineering Systems Group of the Motor Vehicle Council. The Committee = is > responsible for adapting, developing and maintaining SAE Standards, > Recommended Practices, and Information Reports that use cellular radio > access technologies and specifically, evolving 4G LTE and 5G cellular > technologies that require interoperability and performance standards = for > road vehicles and other road users in order to use the full = capabilities of > these technologies. The committee also coordinates task force efforts = to > ensure efficient development and delivery of SAE documents, acts as = liaison > to the other organizations involved in the with vehicular-oriented = cellular > standards and deployments, and organizes efforts in gathering = requirements > for SAE standardization and assigns them to distributed task forces. >> The C-V2X Technical Committee will work closely with the SAE DSRC > Technical Committee and with their documents to assure efficient reuse = and > adjustment as appropriate, e.g., strive to maintain a single data > dictionary. Participants in the SAE C-V2X TC include vehicle OEMs, = vehicle > suppliers, mobile network operators, mobile network operator equipment > suppliers, mobile handset manufacturers, chipset manufacturers, road > operators, traffic equipment suppliers, consulting firms, government, = and > other interested parties. >>=20 >> At the current time, three Task Forces constitute the C-V2X TC. The = Task > Forces and charters are: >>=20 >> CV2X Advanced Applications Task Force: Develop definitions of terms,=20= >> use cases, recommended practices, guidelines, test methods,=20 >> specifications and performance standards for vehicles connected using=20= >> C-V2X, focusing on advanced V2X applications (i.e., applications that=20= >> cannot be supported by DSRC and Rel-14 LTEV2X) that deal with 5G = (3GPP=20 >> NR and LTE evolution) to leverage enhanced mobile broadband, use of=20= >> millimeter wave and other anticipated radio access technologies, and=20= >> the next generation core network including enablers such as NFV/SDN,=20= >> edge computing, and network slicing. The task force will encourage=20 >> research in these areas, and sponsor and facilitate the development = of=20 >> related standards. The work of this task force will be coordinated=20 >> with other task forces in C-V2X Technical Committee, as well as other=20= >> V2X related technical committees and standards organizations such as=20= >> 3GPP, ATIS, GSM Association, DSRC Technical Committee, On-Road=20 >> Automated Driving (RAD) Technical Committee > , ITU-T and ETSI. >>=20 >> CV2X Direct Communication Task Force: Develop definitions of terms, = use > cases, recommended practices guidelines, test methods, specifications = and > performance standards for vehicles connected using C-V2X, focusing on = safety > applications that include cooperative awareness, warning notification, = safe > lane change, safe intersection and roundabout crossing, etc. Important > topics of security, reliability, and quality of service will be part = of the > charter. The task force will encourage research in these areas, and = sponsor > and facilitate the development of related standards. The work of this = task > force will be coordinated with other task forces in CV2X Technical > Committee, as well as other V2X related technical committees and = standards > organizations such as DSRC Technical Committee, On-Road Automated = Driving > (RAD) Technical Committee, 3GPP, ISO, ITU-T and ETSI. >>=20 >> CV2X Road Operators Task Force: Work with the ground transportation > operating community to identify its high-level needs and develop = standards, > recommended practices, and information reports to address those needs. >>=20 >> 2. Actions: >>=20 >> To (SDOs and industry organizations): >>=20 >> ACTION: The SAE C-V2X welcomes mutual consideration and communication = as > we jointly standardize applicable interoperability and performance > specifications to fully leverage 4G LTE and 5G cellular radio access > technologies. >>=20 >> 3. Date of Next SAE C-V2X Meetings: >> 3rd Wednesday of every month, 1000 Eastern Time US WebEx >> 14-15 March, 2018 > Southeast Michigan or Newark NJ (TBD) >> Attachments: >>=20 >> SAE 12302017-1- LS Announcing SAE C-V2X v2final.pdf >>=20 >> = https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2018-01-02-sae-c >> = ell-v2x-ipwave-ls-on-establishment-of-sae-cellular-v2x-technical-commi >> ttee-and-associated-task-forces-attachment-1.pdf >>=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 From nobody Sun Mar 18 09:15: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 A120E128954 for ; Sun, 18 Mar 2018 09:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1QccGt_My-1 for ; Sun, 18 Mar 2018 09:15:40 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D83A1127AD4 for ; Sun, 18 Mar 2018 09:15:39 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w2IGFYdZ010429; Sun, 18 Mar 2018 17:15:34 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id BD791201720; Sun, 18 Mar 2018 17:15: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 ADF2B200DEB; Sun, 18 Mar 2018 17:15:34 +0100 (CET) Received: from [132.166.84.193] ([132.166.84.193]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w2IGFXUH019846; Sun, 18 Mar 2018 17:15:33 +0100 To: "its@ietf.org" Cc: Tijink Jasja , Kevin Smith References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> From: Alexandre Petrescu Message-ID: <5cc6bd32-0812-288a-2db0-b0de53626f1e@gmail.com> Date: Sun, 18 Mar 2018 17:15:33 +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] =?utf-8?q?=5Bipwave=C3=AE=5D_IPv6-over-OCB_as_a_profile?= =?utf-8?q?_of_1609_WAVE?= X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 18 Mar 2018 16:15:41 -0000 Hi IPWAVErs, Do you disagree we add this phrase in the Introduction: > This document is a profile based on IEEE 1609.3: it introduces > additional requirements and specifications that do not violate that > base standard. For my part I find addition of this text neutral and ok, although I am not sure what is a profile for 1609 WAVE. In Bluetooth, a 'profile' is something very much precise, like 'LAN profile', etc. Alex Le 17/03/2018 à 13:22, Tijink Jasja a écrit : > Hello Alex, > > Can we put something at the beginning of > draft-ietf-ipwave-ipv6-over-80211ocb-21, maybe in the introduction? > I suggest some language like the following: > > This document is a profile based on IEEE 1609.3: it introduces > additional requirements and specifications that do not violate that > base standard. > > Regards Jasja > > > -----Ursprüngliche Nachricht----- Von: Alexandre Petrescu > [mailto:alexandre.petrescu@gmail.com] Gesendet: Samstag, 17. März > 2018 12:23 An: Tijink Jasja Cc: Kevin > Smith ; its@ietf.org Betreff: Re: [ipwave] > ipwave - comments and concerns - 1609 WAVE, EPD - towards resolution > > Hello Jasja, > > Le 16/03/2018 à 19:02, Tijink Jasja a écrit : >> Hello Alex, >> >> in addition to Kevin's points, I would like to mention that: >> >> 1. I welcome your proposal for the additional text that specifies >> QoS. This is necessary for operation in Europe (the specification >> for the access layer can be found in ETSI EN 302 663, where clause >> 4.6 says that QoS shall be used). > > Noted. > >> 2. My understanding of the discussion below is that >> draft-ietf-ipwave-ipv6-over-80211ocb-21 is "based on" IEEE 1609.3 >> in that it is compliant with it (I didn't find any "violation of >> IEEE 1609.3), and adds additional restrictions and /or >> specifications (such a MTU size, AC_BK, RFC8064, etc.). In that >> sense draft-ietf-ipwave-ipv6-over-80211ocb-21 is a profile of IEEE >> 1609.3. I would suggest making that very clear, with a short >> sentence/paragraph in draft-ietf-ipwave-ipv6-over-80211ocb-21 that >> explains it to the reader. If you disagree, I would like to hear >> your view on the relation of IEEE 1609.3 and >> draft-ietf-ipwave-ipv6-over-80211ocb-21. > > I dont really disagree, just where to put it. > > The draft does refer to 1609.3, in Appendix C "aspects introduced by > OCB to 802.11". The vehicular networking draft > (draft-ietf-ipwave-vehicular-networking-01) also refers to it right > at the beginning. > > IPv6-over-OCB sounds like an explanation. As such, I suggest we > first write more precisely that "IPv6-over-OCB is a profile of > 1609.3" and then put it into the vehicular networking draft. > > How could that be written? > > Alex > From nobody Sun Mar 18 09:22: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 C6BC612D87D for ; Sun, 18 Mar 2018 09:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xph3VtY7tknK for ; Sun, 18 Mar 2018 09:22:35 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E01D712D88A for ; Sun, 18 Mar 2018 09:22:34 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w2IGMUm5011182; Sun, 18 Mar 2018 17:22:30 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7A93B201720; Sun, 18 Mar 2018 17:22: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 69DA5200DEB; Sun, 18 Mar 2018 17:22:30 +0100 (CET) Received: from [132.166.84.114] ([132.166.84.114]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w2IGMTua019559; Sun, 18 Mar 2018 17:22:29 +0100 To: Tijink Jasja , Kevin Smith Cc: "its@ietf.org" References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> From: Alexandre Petrescu Message-ID: <9841a8be-6230-7f0f-5230-67bfe6c166af@gmail.com> Date: Sun, 18 Mar 2018 17:22: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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] FW: ipwave - comments and concerns - 1609 WAVE, EPD - 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: Sun, 18 Mar 2018 16:22:41 -0000 Le 17/03/2018 à 13:37, Tijink Jasja a écrit : > Hi Alex, > > on the EAL topic. Take again the following text from the draft: > > " IP packets are transmitted over 802.11-OCB as standard Ethernet > packets. As with all 802.11 frames, an Ethernet adaptation layer > MUST be used with 802.11-OCB as well." > > I understand the second sentence is a requirement you put to > implementations that feature an ethernet interface and an 802.11 > interface. Well no, I do not want it to be understood that way. "are transmitted" means: the packets are transmitted by the IPv6 stack to the driver. In a computer there is userland, protocol stack, and driver. But I agree with you it can be read as you say. > But the first sentence: that one seems not true to me according to > what you report of your own tests - 802.11 packets do not have > ethernet headers. So the first sentence is incorrect, right? Or do I > simply misunderstand it and what you want to say is: > > "IP packets are transmitted over 802.11-OCB as over standard > Ethernet: as with all 802.11 frames, an Ethernet adaptation layer > MUST be used with 802.11-OCB as well." I agree with you, it is the same misunderstanding. It should be better written, without being too descriptive and still be normative. Alex > > > Regards Jasja > > > -----Ursprüngliche Nachricht----- Von: Alexandre Petrescu > [mailto:alexandre.petrescu@gmail.com] Gesendet: Samstag, 17. März > 2018 13:10 An: Kevin Smith Cc: Tijink Jasja > ; its@ietf.org Betreff: Re: FW: [ipwave] > ipwave - comments and concerns - 1609 WAVE, EPD - towards resolution > > > Le 16/03/2018 à 18:34, Kevin Smith a écrit : [...] > >> I suggest that in section 4.2.1 "Ethernet Adaptation Layer" we add >> the following paragraph: >> >>> The IPv6 packet transmitted on 802.11-OCB MUST be immediately >>> preceded by a Logical Link Control (LLC) header and an 802.11 >>> header. In the LLC header, and in accordance with the EtherType >>> Protocol Discrimination (EPD), the value of the Type field MUST >>> be set to 0x86DD (IPv6). In the 802.11 header, the value of the >>> Subtype sub-field in the Frame Control field MUST be set to 8 >>> (i.e. 'QoS Data'); the value of the Traffic Identifier (TID) >>> sub-field of the QoS Control field of the 802.11 header MUST be >>> set to binary 001 (i.e. User Priority 'Background', QoS Access >>> Category 'AC_BK'). >>> >>> In the Ethernet II header, the value of the Type field MUST be >>> set to 0x86DD (IPv6). >> >> Do you agree with this text? >> >> [KS]: I agree with the part that addresses the LLC header. I don't >> disagree with the part addressing the 802.11 header, I'm just not >> an expert in this area and so defer to others. I believe that >> others in the 1609 WG have been discussing this with the ipwave >> list? > > Noted. > > Others have discussed the QoS part and there seems to be agreement > with that. > >>> I note that ipwave mentions EPD, but also SNAP and does not >>> specify which method to use. >> >> I propose we remove this phrase: >>> Other alternative views of layering are EtherType Protocol >>> Discrimination (EPD), see Appendix E, and SNAP see [RFC1042]. >> >> Do you agree? >> >> [KS]: Yes. > > Noted. > >>> Moreover ipwave discusses an abstract "Ethernet Adaptation >>> Layer" but does not specify a header format, and this further >>> confuses the question for deployers - what should we implement? >> >> The Ethernet Adaptation Layer (more precisely 802.11-to-Ethernet >> AL) is not so abstract, because it is widely implemented. This >> layer does conversion between headers: at reception from the >> network it transforms a .11/LLC header into an EthernetII header; >> reversely, at sending it transforms an EthernetII header into a >> .11/LLC header. This is shown in Figure 1. >> >> The EAL does not intend to specify a header format. The header >> formats involved are the IEEE 802.11, LLC and EthernetII. The >> fields in these headers are specified by IEEE. >> >> [KS]: I don't understand why the EAL is relevant to "Transmission >> of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside >> the Context of a Basic Service Set". If I want to write software >> that sends IPv6 packets over 802.11 OCB, all I need to know is how >> to construct the LLC sublayer header, etc. The EAL sounds like a >> "bridge", and perhaps belongs in a separate document (and perhaps >> has already been addressed in some existing document?) > > We wanted to have IPv6-over-OCB document that is minimal change from > existing works: RFC 2464 IPv6-over-Ethernet and implementations. > > In implementations, that's how IPv6 works: whenever IPv6 stack wants > to sit on a link layer (802.15.4, WiFi, LTE) it actually sits on an > Adaptation Layer. Because IPv6 only knows Ethernet (RFC2464). > > Whenever a new link layer technology appears, people struggle to make > it first look like Ethernet. Only then does IPv6 run easily on it. > > Because of that, I tend to agree it could makes sense to make an > IPv6-over-802.11 document first (including EAL), and the OCB version > after. The OCB version would be much smaller. > > At the same time, such document IPv6-over-802.11 does not exist. It > could not be developped in the IPWAVE WG which is aiming at vehicle > networking, not .11 in general. > > It would take so long to create a new IPv6-over-.11 document, and > only then to advance the IPv6-over-OCB draft. > > An additional reason as to why it would take long is that the mapping > of IPv6 fields on 802.11 fields is not straightforward at all. (QoS > is one aspect, but there is also frag fields, security and more). > >> Regardless, including a description of the EAL does not violate >> anything in 1609.3, as it is out of scope with 1609.3. > > Noted. > >> >> Some *new comments* from my side: >> >> - ipwave 4.2.1 it states "An 'adaptation' layer is inserted between >> a MAC layer and the Networking layer." This sounds like a >> requirement. If I am developing a product that is only concerned >> with sending IPv6 over OCB, and does not require "bridging", then >> how do I reconcile this requirement? > > It is a requirement indeed. But the adaptation layer is already > there, do not worry. > > If one develops a new product, one is likely to use existing kernels > - they do include EAL, even though they dont call it so. > > If one develops from scratch (very rare), one would have to answer > questions like how does Frag fields map between IPv6 and 802.11, > security, and other very complicated questions. Agreement would be > needed too. I think one will rather prefer too to rely on Ethernet > (RFC2464), as so many other people did in the past. > > "Bridging": I do not know what you mean by 'bridging'? In linux > bridging is a tool called 'brctl'. It bridges two distinct > interfaces, e.g. an Ethernet interface to a WiFi interface. Here we > would 'bridge' Ethernet and 802.11 on the same interface. It's not > 'bridging', it's 'adaptation'. > > Worse: 'brctl' does not work when we want to 'bridge' a OCB interface > to an Ethernet interface. I do not why. I guess the 802. groups > will figure it out one day and fix it. > > But Ethernet Adaptation Layer (named 'bridging' by you?) works ok. > >> - ipwave 4.2 it states "IP packets are transmitted over 802.11-OCB >> as standard Ethernet packets. As with all 802.11 frames, an >> Ethernet adaptation layer MUST be used with 802.11-OCB as well." >> Again EAL is stipulated as a requirement. And I'm not sure about >> the stipulation that packets are transmitted as "standard Ethernet >> packets", is this accurate? > > YEs. > > I verify it this way: > > Use available Wireshark tool on WiFi interface, enable IPv6 on the > computer, and dump some IPv6 packets. They all have EthernetII > headers, rather than LLC and 802.11 headers. Then capture the same > in 'monitor' mode, or 'mon' interface in 802.11 OCB, and the .11/LLC > headers will show instead. > >> Does this mean that 802.3 headers are included? > > The EthernetII headers (not 802.3 Ethernet, I believe different) are > included in the processing during the execution of this EAL. But > these EthernetII headers are not sent on the 802.11 air. > >> This is definitely not stipulated in 1609.3. Packets transmitted >> over OCB by a WAVE device using 1609.3 are well formed IPv6 >> packets, but not "Ethernet packets", i.e., no 802.3 headers are >> included. This seems like an interoperability problem between >> ipwave and 1609 WAVE. > > The packets put on the air on 802.11-OCB links with the IPv6-over-OCB > draft do not include EthernetII headers. SO I do not think there is > an interop problem 1609 WAVE with IPv6-over-OCB draft. > >> >>> 2. It is not clear that ipwave provides any functionality >>> that 1609 WAVE does not already provide. >> >> Well, 1609 WAVE does not specify the conversion between .11/LLC >> headers and EthernetII headers, right? >> >> [KS]: Correct it does not, as this topic is out of scope for 1609 >> WAVE (e.g., we don't specify the other interfaces such as Ethernet >> that may be present in the device). Also see my comments above >> regarding the EAL. > > It is in scope here. Maybe 1609 document can refer to here. > >> 1609 WAVE does not specify the MTU size for IPv6, right? >> >> [KS]: No it does not. 802.11 (normative to 1609) specifies maximum >> MSDU size as 2304 octets. For WSMP 1609.3 specifies a maximum MSDU >> size of 2302 (allowing for the 2-octet LLC header), and a default >> value of 1400. You are correct in that a MSDU size for IPv6 is not >> specified explicitly, but I don't know if some other RFCs related >> to IPv6 over 802.11 already do that? Regardless, stipulating a >> default value of 1500 for MTU size does not violate anything in >> 1609.3. > > Noted. > > For explanation, the figure 1500 for MTU for IPv6-over-OCB comes from > implementations inheriting from old Ethernet behaviour. We dont want > to break that. Moreover, it is compatible with RFC8200 (IPv6) which > requires the minimum MTU to be at least 1280bytes for all links > supporting IPv6. > > IPv6 people are aware that many links do support more than 1500bytes > MTU. I heard of 10000bytes for some core links. Yet the > IPv6-over-foo for these links do not require the MTU 10000bytes. > > >> >> 1609 WAVE does not specify that IPv6 must be preceded by .11 >> QoSData (not just .11 Data), and BACKGROUND, right? >> >> [KS]: Certainly 1609 does not. 1609 only restricts IPv6 packets to >> the SCH (they are not allowed on the CCH). 802.11 specifies >> defaults for all UP and AC parameters, indicates which frame types >> are allowed, etc. But as far as I can tell the stipulation that >> IPv6 use QoSData and AC_BK is new and something that ipwave >> introduces? > > It seems so. People agree with it. > >> Again, I'm not an expert on this topic and I believe others in the >> 1609 WG have been discussing this with the ipwave list. >> Regardless, this additional restriction does not violate 1609.3. >> >> 1609 WAVE does not recommend in particular RFC8064 to form >> semantically opaque Interface Identifiers, right? >> >> [KS]: 1609 does not recommend anything like this, but on the other >> hand 1609 does not prohibit it either. 1609 does not generally >> speaking "recommend", rather it "specifies" and leaves all else up >> to the system designer/implementer/deployer. And as mentioned >> previously, 1609 allows any and all IETF protocols to be >> implemented. Regardless, this recommendation does not violate >> anything in 1609.3. > > Noted. > >> >> (and a few others). >> >>> 1609 WAVE includes a number of mechanisms that enable IPv6 >>> networks to be configured. In addition to the WSA/WRA mechanism, >>> 1609.3 allows any IETF protocols to be implemented, e.g., IETF >>> RFC 4861, Neighbor Discovery for IP Version 6 (IPv6) (which is >>> listed as a normative reference in 1609.3). Helpful would be some >>> example use-cases that illustrate problems to be solved, and how >>> ipwave will solve those problems (i.e., that 1609 WAVE does not >>> already solve). >> >> There is a draft that describes some use-cases of IPv6 in >> vehicular networks: draft-ietf-ipwave-vehicular-networking-02 >> >> [KS]: Thanks for pointing me to that, lots of info there! I'll >> spend some time reviewing that when I can. >> >> I think some parts of 1609 WAVE, in particular WRA, are not used >> in Europe. Whereas this IPv6-over-OCB draft is used the same >> wherever Internet is present (Europe, America, Continents). >> >> [KS]: 1609 went to great lengths to harmonize WSM and WSA frame >> formats with ISO/ETSI standards, these harmonized frames are >> included in all of the -2016 revisions to 1609. So for example the >> 1609.3 WSA is interoperable with the service advertisement used in >> Europe. See ISO 16460, and see also ETSI TS 102 890-1. > > I agree harmonization is good and needed. > > In case that harmonization relies on IPv6 as specified at IETF, these > are my comments to the ETSI document. > > Quickly skimming, it calls it "IPv6 routing advertisement". It is > "IPv6 Router Advertisement". > > The 'default' route is used when no other route is available. The > 'default' route typically gives access to the Internet, not to one > particular server ("ITS-S": station). For particular servers, one > may use RFC4191 instead, for "more specific routes" or, the routes > known as 'host-based routes'. > > Thank you for the comments. > > Alex > > > >>> My concern is that the IETF ipwave document may cause >>> significant confusion among deployers, and possibly lead to a >>> lack of interoperability. Thank you for the opportunity to >>> comment, I look forward to the discussion. >> >> I would like to help with clarification. Let us discuss this. >> >> [KS]: Sounds good! >> >> Alex >> >>> >>> >>> >>> Best regards, >>> >>> Kevin >> >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/listinfo/its >> >> From nobody Sun Mar 18 09:24: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 B5CAF127333 for ; Sun, 18 Mar 2018 09:24:24 -0700 (PDT) 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 vRbAS0xAVlgU for ; Sun, 18 Mar 2018 09:24:22 -0700 (PDT) Received: from smtp2.eurecom.fr (smtp2.eurecom.fr [193.55.113.211]) by ietfa.amsl.com (Postfix) with ESMTP id 0E2FD127286 for ; Sun, 18 Mar 2018 09:24:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.48,326,1517871600"; d="scan'208";a="7793549" Received: from waha.eurecom.fr (HELO smtps.eurecom.fr) ([10.3.2.236]) by drago2i.eurecom.fr with ESMTP; 18 Mar 2018 17:24:20 +0100 Received: from [10.43.9.18] (unknown [92.54.140.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtps.eurecom.fr (Postfix) with ESMTPSA id B78913D3; Sun, 18 Mar 2018 17:24:20 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Jerome Haerri X-Mailer: iPhone Mail (15D100) In-Reply-To: <5cc6bd32-0812-288a-2db0-b0de53626f1e@gmail.com> Date: Sun, 18 Mar 2018 16:24:19 +0000 Cc: "its@ietf.org" , Tijink Jasja , Kevin Smith Content-Transfer-Encoding: quoted-printable Message-Id: References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <5cc6bd32-0812-288a-2db0-b0de53626f1e@gmail.com> To: Alexandre Petrescu Archived-At: Subject: Re: [ipwave] =?utf-8?q?=5Bipwave=C3=AE=5D_IPv6-over-OCB_as_a_profile?= =?utf-8?q?_of_1609_WAVE?= X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 18 Mar 2018 16:24:25 -0000 Dear All, I disagree for two reasons:=20 First this is not a profile, but an alternative operation of IP without rely= ing on WSM. Second, this document will also apply outside of the US, and then IEEE 1609.= 3 does not apply and thus would make this document confusing. Best Regards, J=C3=A9r=C3=B4me Envoy=C3=A9 de mon iPhone > Le 18 mars 2018 =C3=A0 16:15, Alexandre Petrescu a =C3=A9crit : >=20 > Hi IPWAVErs, >=20 > Do you disagree we add this phrase in the Introduction: >=20 >> This document is a profile based on IEEE 1609.3: it introduces additional= requirements and specifications that do not violate that base standard. >=20 > For my part I find addition of this text neutral and ok, although I am > not sure what is a profile for 1609 WAVE. In Bluetooth, a 'profile' is > something very much precise, like 'LAN profile', etc. >=20 > Alex >=20 >=20 >> Le 17/03/2018 =C3=A0 13:22, Tijink Jasja a =C3=A9crit : >> Hello Alex, >> Can we put something at the beginning of draft-ietf-ipwave-ipv6-over-8021= 1ocb-21, maybe in the introduction? >> I suggest some language like the following: >> This document is a profile based on IEEE 1609.3: it introduces additional= requirements and specifications that do not violate that base standard. >> Regards Jasja >> -----Urspr=C3=BCngliche Nachricht----- Von: Alexandre Petrescu [mailto:al= exandre.petrescu@gmail.com] Gesendet: Samstag, 17. M=C3=A4rz 2018 12:23 An: T= ijink Jasja Cc: Kevin >> Smith ; its@ietf.org Betreff: Re: [ipwave] >> ipwave - comments and concerns - 1609 WAVE, EPD - towards resolution >> Hello Jasja, >>> Le 16/03/2018 =C3=A0 19:02, Tijink Jasja a =C3=A9crit : >>> Hello Alex, >>> in addition to Kevin's points, I would like to mention that: >>> 1. I welcome your proposal for the additional text that specifies QoS. T= his is necessary for operation in Europe (the specification for the access l= ayer can be found in ETSI EN 302 663, where clause 4.6 says that QoS shall b= e used). >> Noted. >>> 2. My understanding of the discussion below is that draft-ietf-ipwave-ip= v6-over-80211ocb-21 is "based on" IEEE 1609.3 in that it is compliant with i= t (I didn't find any "violation of IEEE 1609.3), and adds additional restric= tions and /or specifications (such a MTU size, AC_BK, RFC8064, etc.). In tha= t sense draft-ietf-ipwave-ipv6-over-80211ocb-21 is a profile of IEEE 1609.3.= I would suggest making that very clear, with a short sentence/paragraph in d= raft-ietf-ipwave-ipv6-over-80211ocb-21 that >>> explains it to the reader. If you disagree, I would like to hear your vi= ew on the relation of IEEE 1609.3 and draft-ietf-ipwave-ipv6-over-80211ocb-2= 1. >> I dont really disagree, just where to put it. >> The draft does refer to 1609.3, in Appendix C "aspects introduced by OCB t= o 802.11". The vehicular networking draft (draft-ietf-ipwave-vehicular-netw= orking-01) also refers to it right at the beginning. >> IPv6-over-OCB sounds like an explanation. As such, I suggest we first wr= ite more precisely that "IPv6-over-OCB is a profile of 1609.3" and then put i= t into the vehicular networking draft. >> How could that be written? >> Alex >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Sun Mar 18 09:45: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 A5D88127369 for ; Sun, 18 Mar 2018 09:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kapsch.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3GdhI6XfTY7d for ; Sun, 18 Mar 2018 09:45:07 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0721.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe02::721]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93F7812895E for ; Sun, 18 Mar 2018 09:45:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kapsch.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/D5NLttxsoApSlNuHkumRr3ABXZrHgONmAfanIbtLQU=; b=2ZB3262h+r2aoCQjFDGzpdKiQ4vhwQRompfnXb6JzhyWvUXicmkQ4ordCcTOSL06DKat/OJGnWdlRHrMmdBxgU5FQoOQRFNUnkFwQUA5UFIpmnsnG+lqWEn4WREPZeTPVbVER/gt0OtJF58fiB0AJ0+Sm5tlaUFtf1gjDWunJhw= Received: from AM0PR0302MB3380.eurprd03.prod.outlook.com (52.133.37.155) by AM0PR0302MB3348.eurprd03.prod.outlook.com (52.133.37.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.588.14; Sun, 18 Mar 2018 16:45:04 +0000 Received: from AM0PR0302MB3380.eurprd03.prod.outlook.com ([fe80::153a:2232:e7b7:7cb4]) by AM0PR0302MB3380.eurprd03.prod.outlook.com ([fe80::153a:2232:e7b7:7cb4%13]) with mapi id 15.20.0588.016; Sun, 18 Mar 2018 16:45:04 +0000 From: Tijink Jasja To: Jerome Haerri , Alexandre Petrescu CC: Kevin Smith , "its@ietf.org" Thread-Topic: =?utf-8?B?W2lwd2F2ZV0gIFtpcHdhdmXDrl0gSVB2Ni1vdmVyLU9DQiBhcyBhIHByb2Zp?= =?utf-8?Q?le_of_1609_WAVE?= Thread-Index: AQHTvtRe8X8cOrmeWk68f0ucuVBXmqPWLXiAgAAEKMA= Date: Sun, 18 Mar 2018 16:45:03 +0000 Message-ID: References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <5cc6bd32-0812-288a-2db0-b0de53626f1e@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jasja.Tijink@kapsch.net; x-originating-ip: [188.22.229.187] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM0PR0302MB3348; 7:7BnIzbrB7MfI0OakU/DfZGOAInVDjxmUKEpNWmcQuqhe/ld59tAhrS+37xjnXplihkx9xgBPh71qE7hRZEeDk5sguw6opCBxmW3TnzBuyVUGvQAVGLCt69++5M2U9TjfACZowd7FtF+5Mdl72wtoFoO7SkBZgQZmlr1SCCc1K4DUL1ViGi2KLKrDmwXm7A/+Bb+AfoA8q5NC2CjxBwqB/1PXl8f8Aua0U8vtOMoSeeY521flnf1aiVitnIVKudWk x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: c257e858-b105-4cc0-515b-08d58cef9954 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:AM0PR0302MB3348; x-ms-traffictypediagnostic: AM0PR0302MB3348: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(79046362386883)(192374486261705)(85827821059158); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231221)(944501300)(52105095)(10201501046)(6041310)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:AM0PR0302MB3348; BCL:0; PCL:0; RULEID:; SRVR:AM0PR0302MB3348; x-forefront-prvs: 06157D541C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39840400004)(39380400002)(396003)(346002)(376002)(199004)(189003)(3846002)(6116002)(59450400001)(9686003)(305945005)(102836004)(97736004)(316002)(7736002)(8936002)(6306002)(26005)(5250100002)(74316002)(2950100002)(53936002)(186003)(8666007)(25786009)(6436002)(66066001)(86362001)(3660700001)(76176011)(4326008)(3280700002)(7696005)(106356001)(68736007)(105586002)(2900100001)(39060400002)(478600001)(2906002)(81166006)(81156014)(93886005)(54906003)(110136005)(55016002)(99286004)(224303003)(6506007)(72206003)(966005)(14454004)(561944003)(33656002)(5660300001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR0302MB3348; H:AM0PR0302MB3380.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: kapsch.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: nLCLPjJDCdNrx4gavwrmIAZ/MsMvkd4XcjTblG70Zv2xCM+oc7CfPZG2y//B4Wjx7M30eGBwiaK0baRqhSvz+yPFEKv87KbVGj3voFvOHtKQsH9fsMDl251VJ7s9L05HsTiLVawXLbKias8sIda4ikFMKOmSzjLaL0Gt1bjTc7FRQ3NV+4sgtNqdsmXXGsdRnujuucevqe87qf8Q/8OpHKeIQmMd3XrAvjB2VptRG78ucDSyWHJzLxE6pckg2dBdHHcDckDTensvEKm4gWMnWfyVPK5LLzd6t8Llk1QIwp4MOWaEtzirq/QqMiHGxjiViZ5hcbFGb/TU/FUbt26VAQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: kapsch.net X-MS-Exchange-CrossTenant-Network-Message-Id: c257e858-b105-4cc0-515b-08d58cef9954 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Mar 2018 16:45:03.8899 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5f9ce527-7e3e-4e83-a8a4-b6c848f85ab5 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR0302MB3348 Archived-At: Subject: Re: [ipwave] =?utf-8?q?=5Bipwave=C3=AE=5D_IPv6-over-OCB_as_a_profile?= =?utf-8?q?_of_1609_WAVE?= X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 18 Mar 2018 16:45:11 -0000 SGVsbG8gSmVyb21lLA0KDQppIGFtIG5vdCBzdXJlIHRoYXQgSSB1bmRlcnN0YW5kIHlvdXIgcmVh c29ucy4NCg0KRmlyc3Qgb2YgYWxsIEkgYW0gbm90IHN1cmUgd2h5IHlvdSBzdGF0ZSAiYWx0ZXJu YXRpdmUgb3BlcmF0aW9uIHdpdGhvdXQgcmVseWluZyBvbiBXU00iLiBJbiB3aGljaCB3YXkgMTYw OS4zJ3MgSVAgbW9kZSByZWxpZXMgb24gV1NNPw0KDQpTZWNvbmRseSwganVzdCB0byBtYWtlIGFu IGV4YW1wbGUgSUVFRSAxNjA5LjIgKFdBVkUgc2VjdXJpdHkgc3RhbmRhcmQpIGlzIHVzZWQgaW4g RXVyb3BlIHNpbmNlIEVUU0kgVFMgMTAzIDA5NyBtYWtlcyBhIHByb2ZpbGUgb3V0IG9mIGl0Lg0K DQoNCkFueWhvdywgZXZlbiBpZiB5b3UgZG9uJ3QgbGlrZSB0aGUgc2VudGVuY2UgY2FuIHlvdXIg YW5zd2VyIG91ciBvcmlnaW5hbCBxdWVzdGlvbjogd2hhdCBmdW5jdGlvbmFsaXR5IGRvZXMgdGhl IGRyYWZ0IHByb3ZpZGUgdGhhdCAgMTYwOSBXQVZFIGRvZXMgbm90IGFscmVhZHkgcHJvdmlkZSAo ZXhjZXB0IGZvciB0aGUgRUFMIGFzcGVjdCwgd2hpY2ggc2VlbXMgbW9yZSBhbiBpbXBsZW1lbnRh dGlvbiByZXF1aXJlbWVudCk/DQoNCg0KUmVnYXJkcyBKYXNqYQ0KDQoNCi0tLS0tVXJzcHLDvG5n bGljaGUgTmFjaHJpY2h0LS0tLS0NClZvbjogaXRzIFttYWlsdG86aXRzLWJvdW5jZXNAaWV0Zi5v cmddIEltIEF1ZnRyYWcgdm9uIEplcm9tZSBIYWVycmkNCkdlc2VuZGV0OiBTb25udGFnLCAxOC4g TcOkcnogMjAxOCAxNzoyNA0KQW46IEFsZXhhbmRyZSBQZXRyZXNjdSA8YWxleGFuZHJlLnBldHJl c2N1QGdtYWlsLmNvbT4NCkNjOiBUaWppbmsgSmFzamEgPEphc2phLlRpamlua0BrYXBzY2gubmV0 PjsgS2V2aW4gU21pdGggPGtldmluLnMuc21pdGhAY294Lm5ldD47IGl0c0BpZXRmLm9yZw0KQmV0 cmVmZjogUmU6IFtpcHdhdmVdIFtpcHdhdmXDrl0gSVB2Ni1vdmVyLU9DQiBhcyBhIHByb2ZpbGUg b2YgMTYwOSBXQVZFDQoNCkRlYXIgQWxsLA0KDQpJIGRpc2FncmVlIGZvciB0d28gcmVhc29uczog DQpGaXJzdCB0aGlzIGlzIG5vdCBhIHByb2ZpbGUsIGJ1dCBhbiBhbHRlcm5hdGl2ZSBvcGVyYXRp b24gb2YgSVAgd2l0aG91dCByZWx5aW5nIG9uIFdTTS4NClNlY29uZCwgdGhpcyBkb2N1bWVudCB3 aWxsIGFsc28gYXBwbHkgb3V0c2lkZSBvZiB0aGUgVVMsIGFuZCB0aGVuIElFRUUgMTYwOS4zIGRv ZXMgbm90IGFwcGx5IGFuZCB0aHVzIHdvdWxkIG1ha2UgdGhpcyBkb2N1bWVudCBjb25mdXNpbmcu DQoNCkJlc3QgUmVnYXJkcywNCg0KSsOpcsO0bWUNCg0KRW52b3nDqSBkZSBtb24gaVBob25lDQoN Cj4gTGUgMTggbWFycyAyMDE4IMOgIDE2OjE1LCBBbGV4YW5kcmUgUGV0cmVzY3UgPGFsZXhhbmRy ZS5wZXRyZXNjdUBnbWFpbC5jb20+IGEgw6ljcml0IDoNCj4gDQo+IEhpIElQV0FWRXJzLA0KPiAN Cj4gRG8geW91IGRpc2FncmVlIHdlIGFkZCB0aGlzIHBocmFzZSBpbiB0aGUgSW50cm9kdWN0aW9u Og0KPiANCj4+IFRoaXMgZG9jdW1lbnQgaXMgYSBwcm9maWxlIGJhc2VkIG9uIElFRUUgMTYwOS4z OiBpdCBpbnRyb2R1Y2VzIGFkZGl0aW9uYWwgcmVxdWlyZW1lbnRzIGFuZCBzcGVjaWZpY2F0aW9u cyB0aGF0IGRvIG5vdCB2aW9sYXRlIHRoYXQgYmFzZSBzdGFuZGFyZC4NCj4gDQo+IEZvciBteSBw YXJ0IEkgZmluZCBhZGRpdGlvbiBvZiB0aGlzIHRleHQgbmV1dHJhbCBhbmQgb2ssIGFsdGhvdWdo IEkgYW0gDQo+IG5vdCBzdXJlIHdoYXQgaXMgYSBwcm9maWxlIGZvciAxNjA5IFdBVkUuICBJbiBC bHVldG9vdGgsIGEgJ3Byb2ZpbGUnIA0KPiBpcyBzb21ldGhpbmcgdmVyeSBtdWNoIHByZWNpc2Us IGxpa2UgJ0xBTiBwcm9maWxlJywgZXRjLg0KPiANCj4gQWxleA0KPiANCj4gDQo+PiBMZSAxNy8w My8yMDE4IMOgIDEzOjIyLCBUaWppbmsgSmFzamEgYSDDqWNyaXQgOg0KPj4gSGVsbG8gQWxleCwN Cj4+IENhbiB3ZSBwdXQgc29tZXRoaW5nIGF0IHRoZSBiZWdpbm5pbmcgb2YgZHJhZnQtaWV0Zi1p cHdhdmUtaXB2Ni1vdmVyLTgwMjExb2NiLTIxLCBtYXliZSBpbiB0aGUgaW50cm9kdWN0aW9uPw0K Pj4gSSBzdWdnZXN0IHNvbWUgbGFuZ3VhZ2UgbGlrZSB0aGUgZm9sbG93aW5nOg0KPj4gVGhpcyBk b2N1bWVudCBpcyBhIHByb2ZpbGUgYmFzZWQgb24gSUVFRSAxNjA5LjM6IGl0IGludHJvZHVjZXMg YWRkaXRpb25hbCByZXF1aXJlbWVudHMgYW5kIHNwZWNpZmljYXRpb25zIHRoYXQgZG8gbm90IHZp b2xhdGUgdGhhdCBiYXNlIHN0YW5kYXJkLg0KPj4gUmVnYXJkcyBKYXNqYQ0KPj4gLS0tLS1VcnNw csO8bmdsaWNoZSBOYWNocmljaHQtLS0tLSBWb246IEFsZXhhbmRyZSBQZXRyZXNjdSANCj4+IFtt YWlsdG86YWxleGFuZHJlLnBldHJlc2N1QGdtYWlsLmNvbV0gR2VzZW5kZXQ6IFNhbXN0YWcsIDE3 LiBNw6RyeiANCj4+IDIwMTggMTI6MjMgQW46IFRpamluayBKYXNqYSA8SmFzamEuVGlqaW5rQGth cHNjaC5uZXQ+IENjOiBLZXZpbiBTbWl0aCANCj4+IDxrZXZpbi5zLnNtaXRoQGNveC5uZXQ+OyBp dHNAaWV0Zi5vcmcgQmV0cmVmZjogUmU6IFtpcHdhdmVdIGlwd2F2ZSAtIA0KPj4gY29tbWVudHMg YW5kIGNvbmNlcm5zIC0gMTYwOSBXQVZFLCBFUEQgLSB0b3dhcmRzIHJlc29sdXRpb24gSGVsbG8g DQo+PiBKYXNqYSwNCj4+PiBMZSAxNi8wMy8yMDE4IMOgIDE5OjAyLCBUaWppbmsgSmFzamEgYSDD qWNyaXQgOg0KPj4+IEhlbGxvIEFsZXgsDQo+Pj4gaW4gYWRkaXRpb24gdG8gS2V2aW4ncyBwb2lu dHMsIEkgIHdvdWxkIGxpa2UgdG8gbWVudGlvbiB0aGF0Og0KPj4+IDEuIEkgd2VsY29tZSB5b3Vy IHByb3Bvc2FsIGZvciB0aGUgYWRkaXRpb25hbCB0ZXh0IHRoYXQgc3BlY2lmaWVzIFFvUy4gVGhp cyBpcyBuZWNlc3NhcnkgZm9yIG9wZXJhdGlvbiBpbiBFdXJvcGUgKHRoZSBzcGVjaWZpY2F0aW9u IGZvciB0aGUgYWNjZXNzIGxheWVyIGNhbiBiZSBmb3VuZCBpbiBFVFNJIEVOIDMwMiA2NjMsIHdo ZXJlIGNsYXVzZSA0LjYgc2F5cyB0aGF0IFFvUyBzaGFsbCBiZSB1c2VkKS4NCj4+IE5vdGVkLg0K Pj4+IDIuIE15IHVuZGVyc3RhbmRpbmcgb2YgdGhlIGRpc2N1c3Npb24gYmVsb3cgaXMgdGhhdCAN Cj4+PiBkcmFmdC1pZXRmLWlwd2F2ZS1pcHY2LW92ZXItODAyMTFvY2ItMjEgaXMgImJhc2VkIG9u IiBJRUVFIDE2MDkuMyBpbiB0aGF0IGl0IGlzIGNvbXBsaWFudCB3aXRoIGl0IChJIGRpZG4ndCBm aW5kIGFueSAidmlvbGF0aW9uIG9mIElFRUUgMTYwOS4zKSwgYW5kIGFkZHMgYWRkaXRpb25hbCBy ZXN0cmljdGlvbnMgYW5kIC9vciBzcGVjaWZpY2F0aW9ucyAoc3VjaCBhIE1UVSBzaXplLCBBQ19C SywgUkZDODA2NCwgZXRjLikuIEluIHRoYXQgc2Vuc2UgZHJhZnQtaWV0Zi1pcHdhdmUtaXB2Ni1v dmVyLTgwMjExb2NiLTIxIGlzIGEgcHJvZmlsZSBvZiBJRUVFIDE2MDkuMy4gSSB3b3VsZCBzdWdn ZXN0IG1ha2luZyB0aGF0IHZlcnkgY2xlYXIsIHdpdGggYSBzaG9ydCBzZW50ZW5jZS9wYXJhZ3Jh cGggaW4gZHJhZnQtaWV0Zi1pcHdhdmUtaXB2Ni1vdmVyLTgwMjExb2NiLTIxIHRoYXQgZXhwbGFp bnMgaXQgdG8gdGhlIHJlYWRlci4gSWYgeW91IGRpc2FncmVlLCBJIHdvdWxkIGxpa2UgdG8gaGVh ciB5b3VyIHZpZXcgb24gdGhlIHJlbGF0aW9uIG9mIElFRUUgMTYwOS4zIGFuZCBkcmFmdC1pZXRm LWlwd2F2ZS1pcHY2LW92ZXItODAyMTFvY2ItMjEuDQo+PiBJIGRvbnQgcmVhbGx5IGRpc2FncmVl LCBqdXN0IHdoZXJlIHRvIHB1dCBpdC4NCj4+IFRoZSBkcmFmdCBkb2VzIHJlZmVyIHRvIDE2MDku MywgaW4gQXBwZW5kaXggQyAiYXNwZWN0cyBpbnRyb2R1Y2VkIGJ5IE9DQiB0byA4MDIuMTEiLiAg VGhlIHZlaGljdWxhciBuZXR3b3JraW5nIGRyYWZ0IChkcmFmdC1pZXRmLWlwd2F2ZS12ZWhpY3Vs YXItbmV0d29ya2luZy0wMSkgYWxzbyByZWZlcnMgdG8gaXQgcmlnaHQgYXQgdGhlIGJlZ2lubmlu Zy4NCj4+IElQdjYtb3Zlci1PQ0Igc291bmRzIGxpa2UgYW4gZXhwbGFuYXRpb24uICBBcyBzdWNo LCBJIHN1Z2dlc3Qgd2UgZmlyc3Qgd3JpdGUgbW9yZSBwcmVjaXNlbHkgdGhhdCAiSVB2Ni1vdmVy LU9DQiBpcyBhIHByb2ZpbGUgb2YgMTYwOS4zIiBhbmQgdGhlbiBwdXQgaXQgaW50byB0aGUgdmVo aWN1bGFyIG5ldHdvcmtpbmcgZHJhZnQuDQo+PiBIb3cgY291bGQgdGhhdCBiZSB3cml0dGVuPw0K Pj4gQWxleA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gaXRzIG1haWxpbmcgbGlzdA0KPiBpdHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pdHMNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCml0cyBtYWlsaW5nIGxpc3QNCml0c0BpZXRmLm9yZw0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pdHMNCg== From nobody Sun Mar 18 09:50: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 A2E05126C25 for ; Sun, 18 Mar 2018 09:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 gDu3FyLQI0WC for ; Sun, 18 Mar 2018 09:50:02 -0700 (PDT) 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 DAD4B1289B0 for ; Sun, 18 Mar 2018 09:50:01 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id z8so6522909wrh.7 for ; Sun, 18 Mar 2018 09:50:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=K0WlEefgZMzJRcPlc5fdl1F8DO2SQrs4Ym1ORlRdLM8=; b=gNYPc3qmLPuJQ/tH0R4Q5vfo6uo4vb3qzcH5rwn/V74w0lwgnPDpurXuCrLgAFnhvv K1Sz/FEg8NMGAZ5dLQ4QhnCOF6ubAyVpQ9BuS6iQbcR7J8Qsm7FTJdBj8+XT6aGj99Yk zPPfo/y95kv9zz/4jkzf9WJ5Rhz3CTDDHViLUcfIw3XV6heOzL4GTSA69TZhJ6rzqmLA p9XrzW+0K8Z3ckig1gWhfPkH/lrVrO4C1gQeWhH5RdV82FbmgcjlVji5d7GkQZcGWc+/ mWZWW1Rip1emkFcRFAilep1KpKW0MXbrAoKAj3Zwja6J4277vg8h/pb3qsUaUnaE+II2 gKCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=K0WlEefgZMzJRcPlc5fdl1F8DO2SQrs4Ym1ORlRdLM8=; b=fJO49rrJBaSFtsUowhVwIbcDwR2fDjcbfz1I7yswXO+bQUIRk6NA1oABIAqtRjHU+i 59AhqIX4fktK+e4ASFtRo09cA9AsVAxpJcMSVIckg1VEGdUtw0SPWxByjJgAHsBhs+6m 2wj6BFkJshZi/vUHwd0rUrMlvZ/OYyLhHc3Il5fauw0KgjcTGeh4mc+WlujZNr2t2jmc f10e04+gGGLpEIpeLcPQCvquFoyUucOJvcPtrGbkFWPQlw49MACB53DrvdS+XkKa4rff ZyvcZP5Si0+jMArLOQdbvJQpxqsHbj1t0iQMFUMEj+NvTcJhJmD5KY2I0ElxcRTkVyYW 41kQ== X-Gm-Message-State: AElRT7FHW0/p3kO9lKHSXonFBuOhjM+QLW9sw3ysn21CPgKH134gfeBI OHwuK9P57FYDJGt67x95TWy6KsLU X-Google-Smtp-Source: AG47ELsNjiuoQk+nSZa92Rn3VZshTYTDoAwg5PSdJTd1OJZ44Le4xVMMTfC8JXGPyviRKGKze5hXfQ== X-Received: by 10.223.188.12 with SMTP id s12mr7136663wrg.266.1521391800458; Sun, 18 Mar 2018 09:50:00 -0700 (PDT) Received: from ?IPv6:2001:67c:1232:144:656a:289f:5f44:8b2a? ([2001:67c:1232:144:656a:289f:5f44:8b2a]) by smtp.gmail.com with ESMTPSA id w95sm2796578wrb.83.2018.03.18.09.49.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Mar 2018 09:49:59 -0700 (PDT) Sender: Tony Li From: tony.li@tony.li Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_D72EDBC7-3FA0-4287-A3B9-BC75240D4092" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Sun, 18 Mar 2018 16:49:58 +0000 In-Reply-To: Cc: Jerome Haerri , Alexandre Petrescu , Kevin Smith , "its@ietf.org" To: Tijink Jasja References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <5cc6bd32-0812-288a-2db0-b0de53626f1e@gmail.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [ipwave] =?utf-8?q?=5Bipwave=C3=AE=5D_IPv6-over-OCB_as_a_profile?= =?utf-8?q?_of_1609_WAVE?= X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 18 Mar 2018 16:50:03 -0000 --Apple-Mail=_D72EDBC7-3FA0-4287-A3B9-BC75240D4092 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Anyhow, even if you don't like the sentence can your answer our = original question: what functionality does the draft provide that 1609 = WAVE does not already provide (except for the EAL aspect, which seems = more an implementation requirement)? The point is not to provide functionality. Rather, the point is to = document an agreement on what implementations should do if they want to = be interoperable. As noted, there are many conceivable ways of = transmitting IPv6 over OCB. We want to agree on just one. That=E2=80=99s = necessary and sufficient for this document. Tony --Apple-Mail=_D72EDBC7-3FA0-4287-A3B9-BC75240D4092 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Anyhow, even if you don't like = the sentence can your answer our original question: what functionality = does the draft provide that  1609 WAVE does not already provide = (except for the EAL aspect, which seems more an implementation = requirement)?


The point is not to = provide functionality. Rather, the point is to document an agreement on = what implementations should do if they want to be interoperable. As = noted, there are many conceivable ways of transmitting IPv6 over OCB. We = want to agree on just one.  That=E2=80=99s necessary and sufficient = for this document.

Tony

= --Apple-Mail=_D72EDBC7-3FA0-4287-A3B9-BC75240D4092-- From nobody Sun Mar 18 10:08: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 20ED2126DFF for ; Sun, 18 Mar 2018 10:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kapsch.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wxmNpiINKXi for ; Sun, 18 Mar 2018 10:08:04 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0731.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1e::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2F7B120047 for ; Sun, 18 Mar 2018 10:08:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kapsch.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=EUi4PrasTIyycbwGJd+ZvXuQuBb7c6QYKP+3KBMtqnc=; b=lBzwZeo0dWDXkaFxQEkMduZNm2Z2E05FNQ1eMOMwmGIkkcEC7oXjhRFn4vziJ/lW7/dglUTwFduTDvIlpplwKZEcNXT50yVEDnPexPUu9mjUKjwHoWa6Ev9bHedNDN4jMdd59pSzrseq1N+PZdAQ/W5YR64RdOtR6RbniETgJu8= Received: from AM0PR0302MB3380.eurprd03.prod.outlook.com (52.133.37.155) by AM0PR0302MB3346.eurprd03.prod.outlook.com (52.133.37.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.588.14; Sun, 18 Mar 2018 17:08:00 +0000 Received: from AM0PR0302MB3380.eurprd03.prod.outlook.com ([fe80::153a:2232:e7b7:7cb4]) by AM0PR0302MB3380.eurprd03.prod.outlook.com ([fe80::153a:2232:e7b7:7cb4%13]) with mapi id 15.20.0588.016; Sun, 18 Mar 2018 17:08:00 +0000 From: Tijink Jasja To: "tony.li@tony.li" CC: Jerome Haerri , Alexandre Petrescu , Kevin Smith , "its@ietf.org" Thread-Topic: =?utf-8?B?W2lwd2F2ZV0gW2lwd2F2ZcOuXSBJUHY2LW92ZXItT0NCIGFzIGEgcHJvZmls?= =?utf-8?Q?e_of_1609_WAVE?= Thread-Index: AQHTvtkqkEclTj1C2k2BIytCE0jzlqPWOQOg Date: Sun, 18 Mar 2018 17:08:00 +0000 Message-ID: References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <5cc6bd32-0812-288a-2db0-b0de53626f1e@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jasja.Tijink@kapsch.net; x-originating-ip: [188.22.229.187] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM0PR0302MB3346; 6:5MbQHt2CQPImNNJWdCrGULF41hTT1UYPDkMVbP64Gea1vNpy+ln6LLwAv2tU9ckC5blO5bXA6xjpUWVujenpoLBtQBa9yJeb5Kz3L0r59GQDXye6ztA6tkGh+1ASoAAoMMJiKLkQ5t9jcpknlB9L9QcoAPKJoZesa8jXZJ2hIDRa95kEDBBODrbXp6mgLIvx8pksqQwRLAuOtFBkSxMA6z+hgT/gGus+9vSy21OW7uPtpjVVWCw5X87XN+NjXn66avkKJcLkQtoySd+kuVCDum9vk/O2A3PZk9JfrOjXN/aIkBDw7gADG8NpmG8OKSc/wr5qD5DZ1SiepAqc0rMHFcxnrTd0QrrRwXWUmpSfRp0yaePWeyhSPYyT7Fsnxh2F; 5:PFJC2ip5wccgt31HvnLNwE9vrPtZgoGCcSHsQPMLLczrbzvIstAa4cpcUFmS8FlESetnPO8DoQi9IIacHiHAPUzG/ML1htttCQROgKh3pRsCRvgEBr/0TzptpFJJVIP57/7lr4R7oXB0CgA3RmtKHuon7sUgAqndURqXU79TaZM=; 24:TLFWtxykwyOF1/IQQASbbpkZT46T+T9NnkF/XR/y9sM4qqb1FSl3VzVZ6cInMsl83NlC9fMzmkBKtqgR7yV9hNmOo5o9lRa/tGIRh4xoz6Q=; 7:JZDyvamqIKD0iefsFCpd9wx6FMr/YZeqWYcDSi0xXsJPzTqqn57yDiN+htg0qWU2qyy3Ft+UdzyHl3KA7Q47AemegKobPEweP7Ztz8jScdYMXRTXH5pkxPB1Xv8GdwJD1OqznTz+JfclPvEl5JmWzFiMaK57T2GO1yGgu2D933OGFtuBC2sLZsL1/Gh3Z3TYWITcMzDrCTbp8bLqzYc3xu6/gUMdKlXQqaz8SJB7ve51fbaxi5PigSfiUzDBc2xq x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: cf5bf6a0-20d0-4a70-5f13-08d58cf2cd8e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:AM0PR0302MB3346; x-ms-traffictypediagnostic: AM0PR0302MB3346: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(79046362386883)(85827821059158)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231221)(944501300)(52105095)(10201501046)(6041310)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:AM0PR0302MB3346; BCL:0; PCL:0; RULEID:; SRVR:AM0PR0302MB3346; x-forefront-prvs: 06157D541C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39380400002)(376002)(366004)(346002)(39840400004)(189003)(199004)(5250100002)(81166006)(81156014)(6436002)(5640700003)(2906002)(97736004)(93886005)(102836004)(39060400002)(8936002)(86362001)(54896002)(2501003)(8666007)(316002)(6116002)(3846002)(790700001)(7696005)(478600001)(66066001)(33656002)(6306002)(3660700001)(7736002)(6506007)(9686003)(3280700002)(53936002)(68736007)(2351001)(4326008)(105586002)(106356001)(5660300001)(2900100001)(26005)(54906003)(76176011)(25786009)(99286004)(55016002)(5630700001)(186003)(74316002)(6916009)(72206003)(14454004)(224303003)(2950100002)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR0302MB3346; H:AM0PR0302MB3380.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: kapsch.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: IkX083SIzKIgOKUW+0tTMPaawogcYPdubHZWASOtIFlDu+mYmS4tEkjW09kT4j1YCii9oLleJoFL4s62FcfrnCPTXCIKCAX11NlPKRZXlBpnJdejESFYYZuXPC0F5p9PazwAM1AxLieahWdV4u4qjLwRitccdYIwUo4WPQD46oL/CPgKWTV8R6/rVaHfFFcyuL/szGlv9h+n8xipOVbJQK06KarCUT0ZmCkmvIRYjRie98+m3JXVsUw8kYejuU+OqCkyYUJDNwU386W6Ec4nyg6JyvLpk8+lHig7s1H9nTe8vICfZYmwXbvq+weMwD2JxyYDemieW5xpieq1GO6GJQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM0PR0302MB338088B8413D2B593BF7CE7CEFD50AM0PR0302MB3380_" MIME-Version: 1.0 X-OriginatorOrg: kapsch.net X-MS-Exchange-CrossTenant-Network-Message-Id: cf5bf6a0-20d0-4a70-5f13-08d58cf2cd8e X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Mar 2018 17:08:00.0489 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5f9ce527-7e3e-4e83-a8a4-b6c848f85ab5 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR0302MB3346 Archived-At: Subject: Re: [ipwave] =?utf-8?q?=5Bipwave=C3=AE=5D_IPv6-over-OCB_as_a_profile?= =?utf-8?q?_of_1609_WAVE?= X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 18 Mar 2018 17:08:06 -0000 --_000_AM0PR0302MB338088B8413D2B593BF7CE7CEFD50AM0PR0302MB3380_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 4oCmc28gaWYgd2UgcHV0IGl0IHRoYXQgd2F5Og0KDQpJcyBpdCBwb3NzaWJsZSB0byBleHBsYWlu IGhvdyBhbiBpbXBsZW1lbnRhdGlvbiBvZiB0aGlzIGRyYWZ0IGludGVyb3BlcmF0ZXMgd2l0aCBh biBpbXBsZW1lbnRhdGlvbiBvZiBJRUVFIDE2MDkuMz8NCg0KUmVnYXJkcyBKYXNqYQ0KDQpWb246 IFRvbnkgTGkgW21haWx0bzp0b255MWF0aG9tZUBnbWFpbC5jb21dIEltIEF1ZnRyYWcgdm9uIHRv bnkubGlAdG9ueS5saQ0KR2VzZW5kZXQ6IFNvbm50YWcsIDE4LiBNw6RyeiAyMDE4IDE3OjUwDQpB bjogVGlqaW5rIEphc2phIDxKYXNqYS5UaWppbmtAa2Fwc2NoLm5ldD4NCkNjOiBKZXJvbWUgSGFl cnJpIDxqZXJvbWUuaGFlcnJpQGV1cmVjb20uZnI+OyBBbGV4YW5kcmUgUGV0cmVzY3UgPGFsZXhh bmRyZS5wZXRyZXNjdUBnbWFpbC5jb20+OyBLZXZpbiBTbWl0aCA8a2V2aW4ucy5zbWl0aEBjb3gu bmV0PjsgaXRzQGlldGYub3JnDQpCZXRyZWZmOiBSZTogW2lwd2F2ZV0gW2lwd2F2ZcOuXSBJUHY2 LW92ZXItT0NCIGFzIGEgcHJvZmlsZSBvZiAxNjA5IFdBVkUNCg0KDQpBbnlob3csIGV2ZW4gaWYg eW91IGRvbid0IGxpa2UgdGhlIHNlbnRlbmNlIGNhbiB5b3VyIGFuc3dlciBvdXIgb3JpZ2luYWwg cXVlc3Rpb246IHdoYXQgZnVuY3Rpb25hbGl0eSBkb2VzIHRoZSBkcmFmdCBwcm92aWRlIHRoYXQg IDE2MDkgV0FWRSBkb2VzIG5vdCBhbHJlYWR5IHByb3ZpZGUgKGV4Y2VwdCBmb3IgdGhlIEVBTCBh c3BlY3QsIHdoaWNoIHNlZW1zIG1vcmUgYW4gaW1wbGVtZW50YXRpb24gcmVxdWlyZW1lbnQpPw0K DQoNClRoZSBwb2ludCBpcyBub3QgdG8gcHJvdmlkZSBmdW5jdGlvbmFsaXR5LiBSYXRoZXIsIHRo ZSBwb2ludCBpcyB0byBkb2N1bWVudCBhbiBhZ3JlZW1lbnQgb24gd2hhdCBpbXBsZW1lbnRhdGlv bnMgc2hvdWxkIGRvIGlmIHRoZXkgd2FudCB0byBiZSBpbnRlcm9wZXJhYmxlLiBBcyBub3RlZCwg dGhlcmUgYXJlIG1hbnkgY29uY2VpdmFibGUgd2F5cyBvZiB0cmFuc21pdHRpbmcgSVB2NiBvdmVy IE9DQi4gV2Ugd2FudCB0byBhZ3JlZSBvbiBqdXN0IG9uZS4gIFRoYXTigJlzIG5lY2Vzc2FyeSBh bmQgc3VmZmljaWVudCBmb3IgdGhpcyBkb2N1bWVudC4NCg0KVG9ueQ0KDQo= --_000_AM0PR0302MB338088B8413D2B593BF7CE7CEFD50AM0PR0302MB3380_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5t c29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFt ZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBj bTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9u dC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFu LkUtTWFpbEZvcm1hdHZvcmxhZ2UxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4u RS1NYWlsRm9ybWF0dm9ybGFnZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp emU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsN CgltYXJnaW46NzAuODVwdCA3MC44NXB0IDIuMGNtIDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJERS1BVCIg bGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPuKApnNvIGlmIHdlIHB1dCBpdCB0aGF0IHdheTo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JcyBpdCBwb3NzaWJsZSB0byBleHBsYWluIGhvdyBh biBpbXBsZW1lbnRhdGlvbiBvZiB0aGlzIGRyYWZ0IGludGVyb3BlcmF0ZXMgd2l0aCBhbiBpbXBs ZW1lbnRhdGlvbiBvZiBJRUVFIDE2MDkuMz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij5SZWdhcmRzIEphc2phPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20g MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkRFIj5Wb246PC9zcGFu PjwvYj48c3BhbiBsYW5nPSJERSI+IFRvbnkgTGkgW21haWx0bzp0b255MWF0aG9tZUBnbWFpbC5j b21dDQo8Yj5JbSBBdWZ0cmFnIHZvbiA8L2I+dG9ueS5saUB0b255LmxpPGJyPg0KPGI+R2VzZW5k ZXQ6PC9iPiBTb25udGFnLCAxOC4gTcOkcnogMjAxOCAxNzo1MDxicj4NCjxiPkFuOjwvYj4gVGlq aW5rIEphc2phICZsdDtKYXNqYS5UaWppbmtAa2Fwc2NoLm5ldCZndDs8YnI+DQo8Yj5DYzo8L2I+ IEplcm9tZSBIYWVycmkgJmx0O2plcm9tZS5oYWVycmlAZXVyZWNvbS5mciZndDs7IEFsZXhhbmRy ZSBQZXRyZXNjdSAmbHQ7YWxleGFuZHJlLnBldHJlc2N1QGdtYWlsLmNvbSZndDs7IEtldmluIFNt aXRoICZsdDtrZXZpbi5zLnNtaXRoQGNveC5uZXQmZ3Q7OyBpdHNAaWV0Zi5vcmc8YnI+DQo8Yj5C ZXRyZWZmOjwvYj4gUmU6IFtpcHdhdmVdIFtpcHdhdmXDrl0gSVB2Ni1vdmVyLU9DQiBhcyBhIHBy b2ZpbGUgb2YgMTYwOSBXQVZFPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Bbnlob3csIGV2ZW4g aWYgeW91IGRvbid0IGxpa2UgdGhlIHNlbnRlbmNlIGNhbiB5b3VyIGFuc3dlciBvdXIgb3JpZ2lu YWwgcXVlc3Rpb246IHdoYXQgZnVuY3Rpb25hbGl0eSBkb2VzIHRoZSBkcmFmdCBwcm92aWRlIHRo YXQgJm5ic3A7MTYwOSBXQVZFIGRvZXMgbm90IGFscmVhZHkgcHJvdmlkZSAoZXhjZXB0DQogZm9y IHRoZSBFQUwgYXNwZWN0LCB3aGljaCBzZWVtcyBtb3JlIGFuIGltcGxlbWVudGF0aW9uIHJlcXVp cmVtZW50KT88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgcG9pbnQgaXMgbm90IHRvIHByb3ZpZGUgZnVuY3Rp b25hbGl0eS4gUmF0aGVyLCB0aGUgcG9pbnQgaXMgdG8gZG9jdW1lbnQgYW4gYWdyZWVtZW50IG9u IHdoYXQgaW1wbGVtZW50YXRpb25zIHNob3VsZCBkbyBpZiB0aGV5IHdhbnQgdG8gYmUgaW50ZXJv cGVyYWJsZS4gQXMgbm90ZWQsIHRoZXJlIGFyZSBtYW55IGNvbmNlaXZhYmxlIHdheXMgb2YgdHJh bnNtaXR0aW5nIElQdjYgb3ZlciBPQ0IuIFdlIHdhbnQNCiB0byBhZ3JlZSBvbiBqdXN0IG9uZS4g Jm5ic3A7VGhhdOKAmXMgbmVjZXNzYXJ5IGFuZCBzdWZmaWNpZW50IGZvciB0aGlzIGRvY3VtZW50 LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U b255PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_AM0PR0302MB338088B8413D2B593BF7CE7CEFD50AM0PR0302MB3380_-- From nobody Sun Mar 18 10:24: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 27A47129C59 for ; Sun, 18 Mar 2018 10:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbKzZu7K8jB5 for ; Sun, 18 Mar 2018 10:24:46 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82FFE126DFF for ; Sun, 18 Mar 2018 10:24:46 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w2IHOfE4033585; Sun, 18 Mar 2018 18:24:41 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D76A3201519; Sun, 18 Mar 2018 18:24:41 +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 BE15D200801; Sun, 18 Mar 2018 18:24:41 +0100 (CET) Received: from [132.166.84.41] ([132.166.84.41]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w2IHOfHt010217; Sun, 18 Mar 2018 18:24:41 +0100 To: Kevin Smith , "'Tijink Jasja'" Cc: its@ietf.org References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <003b01d3be25$c5239ff0$4f6adfd0$@cox.net> From: Alexandre Petrescu Message-ID: Date: Sun, 18 Mar 2018 18:24: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: <003b01d3be25$c5239ff0$4f6adfd0$@cox.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] IP or IPv6 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 18 Mar 2018 17:24:48 -0000 Le 17/03/2018 à 20:25, Kevin Smith a écrit : [...] > Note also I changed "IP" to "IPv6". At the risk of being called provokative: can one think there is another version of IP that deserves being described? If not, the only version that can be understood when reading "IP" is "IPv6". I do not see why being explicit and say v6, when IP is sufficient and shorter. Alex [...] From nobody Sun Mar 18 10:26: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 9FF5712946D for ; Sun, 18 Mar 2018 10:26:45 -0700 (PDT) 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 FgLs9eab2-qd for ; Sun, 18 Mar 2018 10:26:44 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D4A3129C59 for ; Sun, 18 Mar 2018 10:26:43 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w2IHQdXu034239; Sun, 18 Mar 2018 18:26:39 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 523BE201653; Sun, 18 Mar 2018 18:26: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 3FDD1200B95; Sun, 18 Mar 2018 18:26:39 +0100 (CET) Received: from [132.166.84.41] ([132.166.84.41]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w2IHQcAW010741; Sun, 18 Mar 2018 18:26:38 +0100 Cc: Tony Li , Tijink Jasja , Kevin Smith , "its@ietf.org" References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> From: Alexandre Petrescu Message-ID: <23f068f5-36ff-ced3-495b-f888549981bc@gmail.com> Date: Sun, 18 Mar 2018 18:26: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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] clarification of EAL text X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 18 Mar 2018 17:26:45 -0000 I suggest this clarification of the EAL text. OLD: > IP packets are transmitted over 802.11-OCB as standard Ethernet > packets. As with all 802.11 frames, an Ethernet adaptation layer > MUST be used with 802.11-OCB as well." NEW: > Within an IP-RSU, or within an IP-OBU, the IP packets are communicated > by the IP stack to and from the 802.11-OCB driver as standard Ethernet > II frames. IP packets MUST be transmitted over 802.11-OCB media as > QoS Data frames whose format is specified in IEEE Std 802.11. > > Before sending the IP packets on the 802.11 media, and after receiving > packets from the 802.11 media, the use of an adaptation layer that > adapts between the frame formats of 802.11 and of Ethernet II is > RECOMMENDED. The Ethernet II headers MUST NOT be transmitted on > 802.11 media. Alex Le 17/03/2018 à 13:50, Tony Li a écrit : > >> on the EAL topic. Take again the following text from the draft: >> >> " IP packets are transmitted over 802.11-OCB as standard Ethernet >> packets. As with all 802.11 frames, an Ethernet adaptation layer >> MUST be used with 802.11-OCB as well." >> >> I understand the second sentence is a requirement you put to >> implementations that feature an ethernet interface and an 802.11 >> interface. > > > I suspect that we’ll also get some push back on this sentence > because it is implied to be normative. Since the EAL doesn’t > actually affect the bits on the air, this is simply an implementation > choice and not strictly mandatory. > > It would probably be easier if we relaxed the wording to make this > informative or recommended instead. > > Tony > > From nobody Sun Mar 18 10: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 BC521126DFF for ; Sun, 18 Mar 2018 10:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.584 X-Spam-Level: X-Spam-Status: No, score=-0.584 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 7Fs080tgD1vw for ; Sun, 18 Mar 2018 10:34:35 -0700 (PDT) Received: from fed1rmfepo203.cox.net (fed1rmfepo203.cox.net [68.230.241.148]) by ietfa.amsl.com (Postfix) with ESMTP id 195C1129502 for ; Sun, 18 Mar 2018 10:34:35 -0700 (PDT) Received: from fed1rmimpo210.cox.net ([68.230.241.161]) by fed1rmfepo203.cox.net (InterMail vM.8.01.05.28 201-2260-151-171-20160122) with ESMTP id <20180318173434.BQXE4590.fed1rmfepo203.cox.net@fed1rmimpo210.cox.net> for ; Sun, 18 Mar 2018 13:34:34 -0400 Received: from smithPC ([174.68.115.141]) by fed1rmimpo210.cox.net with cox id PVaa1x004336m1J01Vaapt; Sun, 18 Mar 2018 13:34:34 -0400 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A090203.5AAEA32A.004F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.2 cv=WL0PZjkR c=1 sm=1 tr=0 a=lZ+2k6HZ6QqstbCzvfe+bA==:117 a=lZ+2k6HZ6QqstbCzvfe+bA==:17 a=IkcTkHD0fZMA:10 a=x7bEGLp0ZPQA:10 a=kGgg9RDvKM0A:10 a=48vgC7mUAAAA:8 a=kviXuzpPAAAA:8 a=A1EfXRNyAAAA:8 a=eT32HIbS8QQkp1WSBOAA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=qrIFiuKZe2vaD64auk6j:22 a=ho1zAXZTouNDp1r8zZ_w:22 X-CM-Score: 0.00 Authentication-Results: cox.net; auth=pass (LOGIN) smtp.auth=kevin.s.smith@cox.net From: "Kevin Smith" To: "'Alexandre Petrescu'" , "'Tijink Jasja'" Cc: References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <003b01d3be25$c5239ff0$4f6adfd0$@cox.net> In-Reply-To: Date: Sun, 18 Mar 2018 10:34:40 -0700 Message-ID: <00c301d3bedf$64fca620$2ef5f260$@cox.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGhOrR8o8b5YryKQCC/S9k90bJ5fwGaWEJkAgugfycB2ExIegL6LQxIAYB64p6j64ET0A== Content-Language: en-us Archived-At: Subject: Re: [ipwave] IP or IPv6 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 18 Mar 2018 17:34:36 -0000 Alex, As the title of the document is " Transmission of *IPv6* Packets over = ...", it seems to me that the scope is restricted to IPv6. Also note = that IPv6 (along with WSMP) are the only L3 protocols allowed by 1609 = WAVE, i.e., IPv4 is not allowed. Best, Kevin -----Original Message----- From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu Sent: Sunday, March 18, 2018 10:25 AM To: Kevin Smith ; 'Tijink Jasja' = Cc: its@ietf.org Subject: Re: [ipwave] IP or IPv6 Le 17/03/2018 =C3=A0 20:25, Kevin Smith a =C3=A9crit : [...] > Note also I changed "IP" to "IPv6". At the risk of being called provokative: can one think there is another = version of IP that deserves being described? If not, the only version = that can be understood when reading "IP" is "IPv6". I do not see why being explicit and say v6, when IP is sufficient and = shorter. Alex [...] _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its From nobody Sun Mar 18 10:40: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 90379127136 for ; Sun, 18 Mar 2018 10:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.93 X-Spam-Level: X-Spam-Status: No, score=-1.93 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, 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 FFpbGEIgehln for ; Sun, 18 Mar 2018 10:39:59 -0700 (PDT) Received: from fed1rmfepo203.cox.net (fed1rmfepo203.cox.net [68.230.241.148]) by ietfa.amsl.com (Postfix) with ESMTP id 587CF129C6C for ; Sun, 18 Mar 2018 10:39:59 -0700 (PDT) Received: from fed1rmimpo305.cox.net ([68.230.241.173]) by fed1rmfepo203.cox.net (InterMail vM.8.01.05.28 201-2260-151-171-20160122) with ESMTP id <20180318173958.BTEB4590.fed1rmfepo203.cox.net@fed1rmimpo305.cox.net> for ; Sun, 18 Mar 2018 13:39:58 -0400 Received: from smithPC ([174.68.115.141]) by fed1rmimpo305.cox.net with cox id PVfy1x005336m1J01VfyTL; Sun, 18 Mar 2018 13:39:58 -0400 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A090204.5AAEA46E.006D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.2 cv=Q4ui28+a c=1 sm=1 tr=0 a=lZ+2k6HZ6QqstbCzvfe+bA==:117 a=lZ+2k6HZ6QqstbCzvfe+bA==:17 a=x7bEGLp0ZPQA:10 a=DAwyPP_o2Byb1YXLmDAA:9 a=pGLkceISAAAA:8 a=A1EfXRNyAAAA:8 a=kviXuzpPAAAA:8 a=48vgC7mUAAAA:8 a=pYhpDhOrYDTgmpdKl2gA:9 a=uiv64U5u5MWQd8DJ:21 a=aozQFFHVrM7GoDHO:21 a=wPNLvfGTeEIA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=9jb6P23Mc8mTrAc3lXAA:9 a=CzH2jHNOMKGjZhvg:21 a=ERzDyzqQCBe9gMF1:21 a=v5oBEXaCBn6whNxc:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=ho1zAXZTouNDp1r8zZ_w:22 a=qrIFiuKZe2vaD64auk6j:22 a=w1C3t2QeGrPiZgrLijVG:22 X-CM-Score: 0.00 Authentication-Results: cox.net; auth=pass (LOGIN) smtp.auth=kevin.s.smith@cox.net From: "Kevin Smith" To: , "'Jerome Haerri'" , "'Alexandre Petrescu'" Cc: "'Tijink Jasja'" , References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <5cc6bd32-0812-288a-2db0-b0de53626f1e@gmail.com> In-Reply-To: Date: Sun, 18 Mar 2018 10:40:04 -0700 Message-ID: <00c501d3bee0$26270700$72751500$@cox.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C6_01D3BEA5.79C9B5A0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGhOrR8o8b5YryKQCC/S9k90bJ5fwGaWEJkAVayqmAC0zYUGgHJZZEvAaEIiFAAcwBKmQG/5PRJo+A87jA= Content-Language: en-us Archived-At: Subject: Re: [ipwave] =?iso-8859-1?q?=5Bipwave=EE=5D_IPv6-over-OCB_as_a_profi?= =?iso-8859-1?q?le_of_1609_WAVE?= X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 18 Mar 2018 17:40:03 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00C6_01D3BEA5.79C9B5A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Jerome and all, =20 As Dick points out, IPv6 does not in any way rely on WSMP.=20 =20 IPv6 packets are NOT encapsulated by WSM. WSMP and IPv6 are two = completely separate protocols. =20 Best, Kevin =20 From: Dick Roy [mailto:dickroy@alum.mit.edu]=20 Sent: Sunday, March 18, 2018 9:44 AM To: 'Jerome Haerri' ; 'Alexandre Petrescu' Cc: 'Tijink Jasja' ; 'Kevin Smith' ; its@ietf.org Subject: RE: [ipwave] [ipwave=EE] IPv6-over-OCB as a profile of 1609 = WAVE =20 =20 =20 -----Original Message----- From: its [mailto:its-bounces@ietf.org] On Behalf Of Jerome Haerri Sent: Sunday, March 18, 2018 5:24 PM To: Alexandre Petrescu Cc: Tijink Jasja; Kevin Smith; its@ietf.org =20 Subject: Re: [ipwave] [ipwave=EE] IPv6-over-OCB as a profile of 1609 = WAVE =20 Dear All, =20 I disagree for two reasons:=20 First this is not a profile, but an alternative operation of IP without relying on WSM. =20 [RR] WSMP is a networking (and transport) protocol just like IP. The = above statement makes no sense in that respect. One network layer protocol = never "relies on another". That said, if IPv6-over-OCB is a profile of some = other set of standards, then you are wasting your time. What is needed are modifications to IPv6 to handle rapidly varying network topologies. = Where have you heard that before?? ^))) We don't need or want the IETF to = specify how lower layers MUST behave when sending IP packets. Naturally if = there are recommendations for lower layer performance that will make the IP functions perform better, make those recommendations. Just NO SHALLs or MUSTs on any lower layer protocols please! Stick to IPv6 funtionality. =20 Second, this document will also apply outside of the US, and then IEEE 1609.3 does not apply and thus would make this document confusing. =20 [RR] Not so. IEEE 1609 is an international set of standards, and in particular, IEEE 1609.3 is over the air interoperable with ISO 29281-2 = FNTP and therefore can operate anywhere FNTP operates around the world.=20 =20 =20 Best Regards, =20 J=E9r=F4me =20 Envoy=E9 de mon iPhone =20 > Le 18 mars 2018 =E0 16:15, Alexandre Petrescu = > a =E9crit : >=20 > Hi IPWAVErs, >=20 > Do you disagree we add this phrase in the Introduction: >=20 >> This document is a profile based on IEEE 1609.3: it introduces = additional requirements and specifications that do not violate that base standard. >=20 > For my part I find addition of this text neutral and ok, although I am > not sure what is a profile for 1609 WAVE. In Bluetooth, a 'profile' = is > something very much precise, like 'LAN profile', etc. >=20 > Alex >=20 >=20 >> Le 17/03/2018 =E0 13:22, Tijink Jasja a =E9crit : >> Hello Alex, >> Can we put something at the beginning of draft-ietf-ipwave-ipv6-over-80211ocb-21, maybe in the introduction? >> I suggest some language like the following: >> This document is a profile based on IEEE 1609.3: it introduces = additional requirements and specifications that do not violate that base standard. >> Regards Jasja >> -----Urspr=FCngliche Nachricht----- Von: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] Gesendet: Samstag, 17. M=E4rz 2018 = 12:23 An: Tijink Jasja > Cc: Kevin >> Smith >; its@ietf.org Betreff: Re: [ipwave] >> ipwave - comments and concerns - 1609 WAVE, EPD - towards resolution >> Hello Jasja, >>> Le 16/03/2018 =E0 19:02, Tijink Jasja a =E9crit : >>> Hello Alex, >>> in addition to Kevin's points, I would like to mention that: >>> 1. I welcome your proposal for the additional text that specifies = QoS. This is necessary for operation in Europe (the specification for the = access layer can be found in ETSI EN 302 663, where clause 4.6 says that QoS = shall be used). >> Noted. >>> 2. My understanding of the discussion below is that draft-ietf-ipwave-ipv6-over-80211ocb-21 is "based on" IEEE 1609.3 in = that it is compliant with it (I didn't find any "violation of IEEE 1609.3), and = adds additional restrictions and /or specifications (such a MTU size, AC_BK, RFC8064, etc.). In that sense draft-ietf-ipwave-ipv6-over-80211ocb-21 is = a profile of IEEE 1609.3. I would suggest making that very clear, with a = short sentence/paragraph in draft-ietf-ipwave-ipv6-over-80211ocb-21 that >>> explains it to the reader. If you disagree, I would like to hear = your view on the relation of IEEE 1609.3 and draft-ietf-ipwave-ipv6-over-80211ocb-21. >> I dont really disagree, just where to put it. >> The draft does refer to 1609.3, in Appendix C "aspects introduced by = OCB to 802.11". The vehicular networking draft (draft-ietf-ipwave-vehicular-networking-01) also refers to it right at = the beginning. >> IPv6-over-OCB sounds like an explanation. As such, I suggest we = first write more precisely that "IPv6-over-OCB is a profile of 1609.3" and = then put it into the vehicular networking draft. >> How could that be written? >> Alex >=20 > _______________________________________________ > 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 ------=_NextPart_000_00C6_01D3BEA5.79C9B5A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello Jerome and all,

 

As Dick points out, IPv6 does not in any way rely on WSMP. =

 

IPv6 packets are NOT encapsulated by WSM. WSMP and IPv6 are two = completely separate protocols.

 

Best,

Kevin

 

From:<= /b> = Dick Roy [mailto:dickroy@alum.mit.edu]
Sent: Sunday, March = 18, 2018 9:44 AM
To: 'Jerome Haerri' = <jerome.haerri@eurecom.fr>; 'Alexandre Petrescu' = <alexandre.petrescu@gmail.com>
Cc: 'Tijink Jasja' = <Jasja.Tijink@kapsch.net>; 'Kevin Smith' = <kevin.s.smith@cox.net>; its@ietf.org
Subject: RE: = [ipwave] [ipwave=EE] IPv6-over-OCB as a profile of 1609 = WAVE

 

 

 

-----Original Message-----
From: its [mailto:its-bounces@ietf.org] On = Behalf Of Jerome Haerri
Sent: Sunday, March 18, 2018 5:24 PM
To: = Alexandre Petrescu
Cc: Tijink Jasja; Kevin Smith; its@ietf.org
Subject: Re: [ipwave] = [ipwave=EE] IPv6-over-OCB as a profile of 1609 WAVE

 

Dear = All,

 

I disagree for two reasons:

First this is not a profile, but an alternative = operation of IP without relying on WSM.

 

[RR] WSMP is a networking (and transport) protocol = just like IP.  The above statement makes no sense in that respect. = One network layer protocol never "relies on another".  = That said, if IPv6-over-OCB is a profile of some other set of standards, = then you are wasting your time.  What is needed are modifications = to IPv6 to handle rapidly varying network topologies.  Where have = you heard that before?? ^)))  We don't need or want the IETF to = specify how lower layers MUST behave when sending IP packets. =  Naturally if there are recommendations for lower layer performance = that will make the IP functions perform better, make those = recommendations.  Just NO SHALLs or MUSTs on any lower layer = protocols please! Stick to IPv6 funtionality.

 

Second, this document will also apply outside of = the US, and then IEEE 1609.3 does not apply and thus would make this = document confusing.

 

[RR] Not so.  IEEE 1609 is an international = set of standards, and in particular, IEEE 1609.3 is over the air = interoperable with ISO 29281-2 FNTP and therefore can operate anywhere = FNTP operates around the world.

 

 

Best = Regards,

 

J=E9r=F4me

 

Envoy=E9 de mon iPhone

 

> = Le 18 mars 2018 =E0 16:15, Alexandre Petrescu <alexandre.petrescu@gmail.com= > a =E9crit :

> =

> Hi = IPWAVErs,

>

> Do you disagree we add this phrase in the = Introduction:

> =

>> This document is a = profile based on IEEE 1609.3: it introduces additional requirements and = specifications that do not violate that base standard.

>

> = For my part I find addition of this text neutral and ok, although I = am

> not sure what is a profile = for 1609 WAVE.  In Bluetooth, a 'profile' is

> something very much precise, like 'LAN = profile', etc.

> =

> Alex

>

> =

>> Le 17/03/2018 =E0 13:22, = Tijink Jasja a =E9crit :

>> = Hello Alex,

>> Can we put = something at the beginning of draft-ietf-ipwave-ipv6-over-80211ocb-21, = maybe in the introduction?

>> I suggest some language like the = following:

>> This document = is a profile based on IEEE 1609.3: it introduces additional requirements = and specifications that do not violate that base = standard.

>> Regards = Jasja

>> = -----Urspr=FCngliche Nachricht----- Von: Alexandre Petrescu [mailto:alexandre.petrescu@gm= ail.com] Gesendet: Samstag, 17. M=E4rz 2018 12:23 An: Tijink Jasja = <Jasja.Tijink@kapsch.net> = Cc: Kevin

>> Smith <kevin.s.smith@cox.net>; its@ietf.org Betreff: Re: = [ipwave]

>> ipwave - = comments and concerns - 1609 WAVE, EPD - towards = resolution

>> Hello = Jasja,

>>> Le 16/03/2018 = =E0 19:02, Tijink Jasja a =E9crit :

>>> Hello Alex,

>>> in addition to Kevin's points, I  = would like to mention that:

>>> 1. I welcome your proposal for the = additional text that specifies QoS. This is necessary for operation in = Europe (the specification for the access layer can be found in ETSI EN = 302 663, where clause 4.6 says that QoS shall be used).

>> Noted.

>>> 2. My understanding of the discussion = below is that draft-ietf-ipwave-ipv6-over-80211ocb-21 is "based = on" IEEE 1609.3 in that it is compliant with it (I didn't find any = "violation of IEEE 1609.3), and adds additional restrictions and = /or specifications (such a MTU size, AC_BK, RFC8064, etc.). In that = sense draft-ietf-ipwave-ipv6-over-80211ocb-21 is a profile of IEEE = 1609.3. I would suggest making that very clear, with a short = sentence/paragraph in draft-ietf-ipwave-ipv6-over-80211ocb-21 = that

>>> explains it to = the reader. If you disagree, I would like to hear your view on the = relation of IEEE 1609.3 and = draft-ietf-ipwave-ipv6-over-80211ocb-21.

>> I dont really disagree, just where to put = it.

>> The draft does refer = to 1609.3, in Appendix C "aspects introduced by OCB to = 802.11".  The vehicular networking draft = (draft-ietf-ipwave-vehicular-networking-01) also refers to it right at = the beginning.

>> = IPv6-over-OCB sounds like an explanation.  As such, I suggest we = first write more precisely that "IPv6-over-OCB is a profile of = 1609.3" and then put it into the vehicular networking = draft.

>> How could that be = written?

>> = Alex

>

> = _______________________________________________

> its mailing list

> its@ietf.org

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

 

_______________________________________________=

its mailing list

its@ietf.org

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

------=_NextPart_000_00C6_01D3BEA5.79C9B5A0-- From nobody Sun Mar 18 10:42: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 3DA99129C6E for ; Sun, 18 Mar 2018 10:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j54s7vUZgeHs for ; Sun, 18 Mar 2018 10:42:22 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E5BF127136 for ; Sun, 18 Mar 2018 10:42:21 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w2IHgH1h020645; Sun, 18 Mar 2018 18:42:17 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A31F0200DEB; Sun, 18 Mar 2018 18:42: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 890EA200D9C; Sun, 18 Mar 2018 18:42:17 +0100 (CET) Received: from [132.166.84.41] ([132.166.84.41]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w2IHgHPc026652; Sun, 18 Mar 2018 18:42:17 +0100 To: Kevin Smith , "'Tijink Jasja'" Cc: its@ietf.org References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <003b01d3be25$c5239ff0$4f6adfd0$@cox.net> <00c301d3bedf$64fca620$2ef5f260$@cox.net> From: Alexandre Petrescu Message-ID: Date: Sun, 18 Mar 2018 18:42:15 +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: <00c301d3bedf$64fca620$2ef5f260$@cox.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] IP or IPv6 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 18 Mar 2018 17:42:24 -0000 Le 18/03/2018 à 18:34, Kevin Smith a écrit : > Alex, > > As the title of the document is " Transmission of *IPv6* Packets > over ...", Maybe we should change the title to just say "IP". > it seems to me that the scope is restricted to IPv6. Yes. > Also note that IPv6 (along with WSMP) are the only L3 protocols > allowed by 1609 WAVE, i.e., IPv4 is not allowed. In a world where IPv4 is not allowed, not specified, etc., IP can only mean IPv6. Alex > > Best, Kevin > > -----Original Message----- From: its [mailto:its-bounces@ietf.org] > On Behalf Of Alexandre Petrescu Sent: Sunday, March 18, 2018 10:25 AM > To: Kevin Smith ; 'Tijink Jasja' > Cc: its@ietf.org Subject: Re: [ipwave] IP > or IPv6 > > > > Le 17/03/2018 à 20:25, Kevin Smith a écrit : [...] > >> Note also I changed "IP" to "IPv6". > > At the risk of being called provokative: can one think there is > another version of IP that deserves being described? If not, the > only version that can be understood when reading "IP" is "IPv6". > > I do not see why being explicit and say v6, when IP is sufficient > and shorter. > > Alex [...] > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > > From nobody Sun Mar 18 10:53: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 406571241F5 for ; Sun, 18 Mar 2018 10:53:01 -0700 (PDT) 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 x7bGr1_suH3V for ; Sun, 18 Mar 2018 10:53:00 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF9B01270FC for ; Sun, 18 Mar 2018 10:52:59 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w2IHqtoN038140; Sun, 18 Mar 2018 18:52:55 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B2E412010C0; Sun, 18 Mar 2018 18:52: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 9E0E6200C1F; Sun, 18 Mar 2018 18:52:55 +0100 (CET) Received: from [132.166.84.41] ([132.166.84.41]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w2IHqsi1032026; Sun, 18 Mar 2018 18:52:54 +0100 To: Tijink Jasja , "tony.li@tony.li" Cc: Jerome Haerri , Kevin Smith , "its@ietf.org" References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <5cc6bd32-0812-288a-2db0-b0de53626f1e@gmail.com> From: Alexandre Petrescu Message-ID: <97e69e6a-72d4-fcf9-65ce-4c2042dd2f8c@gmail.com> Date: Sun, 18 Mar 2018 18:52: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] =?utf-8?q?=5Bipwave=C3=AE=5D_IPv6-over-OCB_as_a_profile?= =?utf-8?q?_of_1609_WAVE?= X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 18 Mar 2018 17:53:01 -0000 Le 18/03/2018 à 18:08, Tijink Jasja a écrit : > …so if we put it that way: > > Is it possible to explain how an implementation of this draft > interoperates with an implementation of IEEE 1609.3? To me, 1609.3 should just refer to IETF, this draft, abunch of other RFCs, and have no normative text about what IP should or should not do. At some points where 1609.3 feels inclined and tempted to do IP, could copy paste some parts of this draft, reflect some values. E.g. 1609.3 should also say "IP on OCB as QoSData with BK and MTU1500". Then we are sure to have interoperability between an IPv6-over-OCB computer and an 1609.3 computer. But an 1609.3 document that says SLAAC uses WRA is a risk to interoperability. Alex > > Regards Jasja > > *Von:*Tony Li [mailto:tony1athome@gmail.com] *Im Auftrag von > *tony.li@tony.li > *Gesendet:* Sonntag, 18. März 2018 17:50 > *An:* Tijink Jasja > *Cc:* Jerome Haerri ; Alexandre Petrescu > ; Kevin Smith ; > its@ietf.org > *Betreff:* Re: [ipwave] [ipwaveî] IPv6-over-OCB as a profile of 1609 WAVE > > Anyhow, even if you don't like the sentence can your answer our > original question: what functionality does the draft provide that >  1609 WAVE does not already provide (except for the EAL aspect, > which seems more an implementation requirement)? > > The point is not to provide functionality. Rather, the point is to > document an agreement on what implementations should do if they want to > be interoperable. As noted, there are many conceivable ways of > transmitting IPv6 over OCB. We want to agree on just one.  That’s > necessary and sufficient for this document. > > Tony > From nobody Sun Mar 18 10:59: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 C136C126DFF for ; Sun, 18 Mar 2018 10:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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_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 MV_BREL0EXDd for ; Sun, 18 Mar 2018 10:59:48 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::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 8EE4E124D6C for ; Sun, 18 Mar 2018 10:59:47 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id v207-v6so2404466lfa.10 for ; Sun, 18 Mar 2018 10:59:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Cwh8bBj3pZbxhCxYxUY2A5bapG5aiHphfMk3nEM7ujA=; b=px3eiRAcosJvJjbzAYHtd5vdo4dLcN1cCXPIPiZKGU/nwC/97tSa0CBIa6fQbpS6L5 29ZHzM/PIxcWUpqcSgrYJWwIvzfOs0qVmyEbeert0kqx4vQbBIcE8HXVVnOtsp4D6jyn Xmsw6Z3fIIe4atxNadEOVhxulNTV7lsY8Fct0pRsRgWjcnF12o6OjJwG8/chHwzALcjL X7wnPFjqZou/DzaWF+qw51VJlVCLcs4qtYB1FVvOHlbUlnF/4isGLw7hzErpitsB27q1 4ieXA+9liNcMkNSIfi8y02I7zurTRSw+Wb3aKi7lpatZrr29J5V9s1VI0x2YotQiaBhD 5Yrw== 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=Cwh8bBj3pZbxhCxYxUY2A5bapG5aiHphfMk3nEM7ujA=; b=tkL5bbgINEFf6Vj4iEIUIOpg7s1uXSPLS7G/zJSZNTZ36Ee99O8+GXBExg+QAaa7ok T5DcvNib+DMu6OjEjPpfsScj9EoF9KxnV4O/v8VjICPigHLJV2LqGJaEAj6iQAlJU4+a aNQwKt4Zm34P/R7rRQqI9/7DZEv8FJyIA5xseUYw+EfPmAXo8sIYdpBrb9XI+djB8wIH wqP/OzVxjqy6qFYBHh0prVlyq4nUGua95pKPrIbk6/GFiK4UEvFSU8pzZX8Gdr6KDHEe dKPcdoRh/mv0vNK3ZQkIbZZPNQF19QUYsLWtywM8OdOpzp0YgHozpTNkKiME80PPvo/s nwPw== X-Gm-Message-State: AElRT7HMlVTdf+6Kdo+g6Vq9eSkATRKf8QMNH2uwqbxqc0gk8JIdqZTm O+FCCR9LutBc4kBeC8OJPap5HcQf5tHUBNqsZDU= X-Google-Smtp-Source: AG47ELtLj3ey/KD72bWZM2tbxfsweubXUvJC3denn+yyP3Ld7SGd34Zoa3KVbRUh3t0cz13/bJDTAud/LFP8QTEALos= X-Received: by 10.46.146.25 with SMTP id k25mr5892118ljg.100.1521395985753; Sun, 18 Mar 2018 10:59:45 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:e601:0:0:0:0:0 with HTTP; Sun, 18 Mar 2018 10:59:44 -0700 (PDT) In-Reply-To: References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <003b01d3be25$c5239ff0$4f6adfd0$@cox.net> <00c301d3bedf$64fca620$2ef5f260$@cox.net> From: Nabil Benamar Date: Sun, 18 Mar 2018 17:59:44 +0000 Message-ID: To: Alexandre Petrescu Cc: Kevin Smith , Tijink Jasja , "its@ietf.org" Content-Type: multipart/alternative; boundary="089e0827e7a04b2c0d0567b39b54" Archived-At: Subject: Re: [ipwave] IP or IPv6 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 18 Mar 2018 17:59:50 -0000 --089e0827e7a04b2c0d0567b39b54 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi All, Let me remind you that we have already had this discussion and we agreed that this document is for IPv6 ONLY. 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 Sun, Mar 18, 2018 at 5:42 PM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > > > Le 18/03/2018 =C3=A0 18:34, Kevin Smith a =C3=A9crit : > >> Alex, >> >> As the title of the document is " Transmission of *IPv6* Packets >> over ...", >> > > Maybe we should change the title to just say "IP". > > it seems to me that the scope is restricted to IPv6. >> > > Yes. > > Also note that IPv6 (along with WSMP) are the only L3 protocols >> allowed by 1609 WAVE, i.e., IPv4 is not allowed. >> > > In a world where IPv4 is not allowed, not specified, etc., IP can only > mean IPv6. > > Alex > > > >> Best, Kevin >> >> -----Original Message----- From: its [mailto:its-bounces@ietf.org] >> On Behalf Of Alexandre Petrescu Sent: Sunday, March 18, 2018 10:25 AM >> To: Kevin Smith ; 'Tijink Jasja' < >> Jasja.Tijink@kapsch.net> Cc: its@ietf.org Subject: Re: [ipwave] IP or >> IPv6 >> >> >> >> Le 17/03/2018 =C3=A0 20:25, Kevin Smith a =C3=A9crit : [...] >> >> Note also I changed "IP" to "IPv6". >>> >> >> At the risk of being called provokative: can one think there is another >> version of IP that deserves being described? If not, the >> only version that can be understood when reading "IP" is "IPv6". >> >> I do not see why being explicit and say v6, when IP is sufficient >> and shorter. >> >> 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 > --089e0827e7a04b2c0d0567b39b54 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

Let me remind you that we have alre= ady had this discussion and we agreed that this document is for IPv6 ONLY.<= /div>



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 Sun, Mar 18, 2018 at 5:42 PM, Alexandre P= etrescu <alexandre.petrescu@gmail.com> wrote:
=


Le 18/03/2018 =C3=A0 18:34, Kevin Smith a =C3=A9crit :
Alex,

As the title of the document is " Transmission of *IPv6* Packets
over ...",

 Maybe we should change the title to just say "IP".

it seems to me that the scope is restricted to IPv6.

 Yes.

Also note that IPv6 (along with WSMP) are the only L3 protocols
allowed by 1609 WAVE, i.e., IPv4 is not allowed.

 In a world where IPv4 is not allowed, not specified, etc., IP can only mean= IPv6.

Alex



Best, Kevin

-----Original Message----- From: its [mailto:its-bounces@ietf.org]
On Behalf Of Alexandre Petrescu Sent: Sunday, March 18, 2018 10:25 AM
=C2=A0To: Kevin Smith <kevin.s.smith@cox.net>; 'Tijink Jasja' <Jasja.Tijink@kapsch= .net> Cc: its@ietf= .org Subject: Re: [ipwave] IP or IPv6



Le 17/03/2018 =C3=A0 20:25, Kevin Smith a =C3=A9crit : [...]

Note also I changed "IP" to "IPv6".

At the risk of being called provokative: can one think there is another ver= sion of IP that deserves being described? If not, the
only version that can be understood when reading "IP" is "IP= v6".

I do not see why being explicit and say v6, when IP is sufficient
and shorter.

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

--089e0827e7a04b2c0d0567b39b54-- From nobody Sun Mar 18 11:06: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 8C0F9127136 for ; Sun, 18 Mar 2018 11:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5_T0SM584wS for ; Sun, 18 Mar 2018 11:06:38 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B28B124D6C for ; Sun, 18 Mar 2018 11:06:37 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w2II6VZm040312; Sun, 18 Mar 2018 19:06:31 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4A4A3200F56; Sun, 18 Mar 2018 19:06: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 36310200D9C; Sun, 18 Mar 2018 19:06:31 +0100 (CET) Received: from [132.166.84.93] ([132.166.84.93]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w2II6U6B007687; Sun, 18 Mar 2018 19:06:30 +0100 To: dickroy@alum.mit.edu Cc: "'Tijink Jasja'" , "'Kevin Smith'" , "'Tony Li'" , its@ietf.org References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <23f068f5-36ff-ced3-495b-f888549981bc@gmail.com> <2089D655102C4BDFA9437A886A5F8D75@SRA6> From: Alexandre Petrescu Message-ID: <2ee7ff6c-fdf9-b18d-6948-bd9f7a5ff35e@gmail.com> Date: Sun, 18 Mar 2018 19:06: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: <2089D655102C4BDFA9437A886A5F8D75@SRA6> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] clarification of EAL text X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 18 Mar 2018 18:06:40 -0000 Le 18/03/2018 à 18:53, Dick Roy a écrit : > Making requirements on MAC sublayer protocols is WAY out of scope. Of > course bridges translate between 802.11 and 802.3 EAL is not a bridge, it is an adaptation layer. Alex > It's NOT up to the IETF > to tell them how to do it! And once more, if some implementation wants to ue > data frames, that's up to them. They will simply ignore any QoS > requirements. > > > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu > Sent: Sunday, March 18, 2018 6:27 PM > To: undisclosed-recipients: > Cc: Tijink Jasja; Kevin Smith; Tony Li; its@ietf.org > Subject: Re: [ipwave] clarification of EAL text > > I suggest this clarification of the EAL text. > > OLD: >> IP packets are transmitted over 802.11-OCB as standard Ethernet >> packets. As with all 802.11 frames, an Ethernet adaptation layer >> MUST be used with 802.11-OCB as well." > > NEW: >> Within an IP-RSU, or within an IP-OBU, the IP packets are communicated >> by the IP stack to and from the 802.11-OCB driver as standard Ethernet >> II frames. IP packets MUST be transmitted over 802.11-OCB media as >> QoS Data frames whose format is specified in IEEE Std 802.11. >> >> Before sending the IP packets on the 802.11 media, and after receiving >> packets from the 802.11 media, the use of an adaptation layer that >> adapts between the frame formats of 802.11 and of Ethernet II is >> RECOMMENDED. The Ethernet II headers MUST NOT be transmitted on >> 802.11 media. > > Alex > > > Le 17/03/2018 à 13:50, Tony Li a écrit : >> >>> on the EAL topic. Take again the following text from the draft: >>> >>> " IP packets are transmitted over 802.11-OCB as standard Ethernet >>> packets. As with all 802.11 frames, an Ethernet adaptation layer >>> MUST be used with 802.11-OCB as well." >>> >>> I understand the second sentence is a requirement you put to >>> implementations that feature an ethernet interface and an 802.11 >>> interface. >> >> >> I suspect that we'll also get some push back on this sentence >> because it is implied to be normative. Since the EAL doesn't >> actually affect the bits on the air, this is simply an implementation >> choice and not strictly mandatory. >> >> It would probably be easier if we relaxed the wording to make this >> informative or recommended instead. >> >> Tony >> >> > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > From nobody Sun Mar 18 11:11: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 56F6B126DFF for ; Sun, 18 Mar 2018 11:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 Eux6X5T6-CDn for ; Sun, 18 Mar 2018 11:11:36 -0700 (PDT) Received: from fed1rmfepo101.cox.net (fed1rmfepo101.cox.net [68.230.241.143]) by ietfa.amsl.com (Postfix) with ESMTP id EDA89124D6C for ; Sun, 18 Mar 2018 11:11:35 -0700 (PDT) Received: from fed1rmimpo306.cox.net ([68.230.241.174]) by fed1rmfepo101.cox.net (InterMail vM.8.01.05.28 201-2260-151-171-20160122) with ESMTP id <20180318181135.REUR4385.fed1rmfepo101.cox.net@fed1rmimpo306.cox.net> for ; Sun, 18 Mar 2018 14:11:35 -0400 Received: from smithPC ([174.68.115.141]) by fed1rmimpo306.cox.net with cox id PWBa1x008336m1J01WBaSJ; Sun, 18 Mar 2018 14:11:34 -0400 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A090204.5AAEABD7.002B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.2 cv=XLxAcUpE c=1 sm=1 tr=0 a=lZ+2k6HZ6QqstbCzvfe+bA==:117 a=lZ+2k6HZ6QqstbCzvfe+bA==:17 a=8nJEP1OIZ-IA:10 a=x7bEGLp0ZPQA:10 a=kviXuzpPAAAA:8 a=A1EfXRNyAAAA:8 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=W2Llw0GxKQ7WXBPR1YIA:9 a=UX6PMFQaGsVL1PpC:21 a=Y3X2ua5ieRbDpIbb:21 a=wPNLvfGTeEIA:10 a=qrIFiuKZe2vaD64auk6j:22 a=ho1zAXZTouNDp1r8zZ_w:22 a=w1C3t2QeGrPiZgrLijVG:22 X-CM-Score: 0.00 Authentication-Results: cox.net; auth=pass (LOGIN) smtp.auth=kevin.s.smith@cox.net From: "Kevin Smith" To: , "'Tijink Jasja'" , "'Alexandre Petrescu'" Cc: References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <004101d3be2a$116baed0$34430c70$@cox.net> In-Reply-To: Date: Sun, 18 Mar 2018 11:11:40 -0700 Message-ID: <00f401d3bee4$90860700$b1921500$@cox.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGhOrR8o8b5YryKQCC/S9k90bJ5fwGaWEJkAgugfycB2ExIegHFOIJRAbe/ue0CElOL8aPi398g Content-Language: en-us Archived-At: Subject: Re: [ipwave] FW: ipwave - comments and concerns - 1609 WAVE, EPD - 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: Sun, 18 Mar 2018 18:11:39 -0000 Hello All, Thank you Dick for the clarification regarding Ethernet II: It has been incorporated into IEEE 802.3. I suspected it but didn't have the time to = dig into it. I believe it is accurate to say that if we write "Ethernet = frame" then we are talking about a frame specified by IEEE 802.3. Regarding using QoS data frames - ipwave does not intend to state that = it is a requirement in 802.11. Clearly 802.11 lists several options for frame types when operating OCB. However ipwave (if for example it were a = profile of 1609.3) is requiring that QoS data frames be used. The text, that I wrote, on review, is ambiguous. However Alex has = restated it as "IP packets MUST be transmitted over 802.11-OCB media as QoS Data frames whose format is specified in IEEE Std 802.11." =20 Best, Kevin -----Original Message----- From: Dick Roy [mailto:dickroy@alum.mit.edu]=20 Sent: Sunday, March 18, 2018 3:22 AM To: 'Kevin Smith' ; 'Tijink Jasja' ; 'Alexandre Petrescu' Cc: its@ietf.org Subject: RE: [ipwave] FW: ipwave - comments and concerns - 1609 WAVE, = EPD - towards resolution The confusion starts with the undefined term "Ethernet Adaptation Layer (EAL)" and the misguided attempts to use that term in the document. There in NO adaptation layer in 1609.3/802.11-OCB. At the MAC sublayer, type encoding is used in the 5.9GHz band, that's it. BTW - at the MAC sublayer, PDUs are called frames. So IPv6 packets (NPDUs) are MSDUs. = There is no adaptation necessary. =20 As for QoS data frames, once again that is NOT a requirement in 802.11 = (or 1609.3) so don't say that! Ethernet II is part of 802.3, and today the only used part. Length = encoding (and SNAP) at the LLC sublayer are appendages that are rapidly dying = away now. The most important fact is that they are NOT used in IPv6 / = 802.11-OCB in 5.9GHz.=20 RR -----Original Message----- From: its [mailto:its-bounces@ietf.org] On Behalf Of Kevin Smith Sent: Saturday, March 17, 2018 8:57 PM To: 'Tijink Jasja'; 'Alexandre Petrescu' Cc: its@ietf.org Subject: Re: [ipwave] FW: ipwave - comments and concerns - 1609 WAVE, = EPD - towards resolution Addendum: Looking at RFC 2464, I see in clause 3. Frame Format the = statement "IPv6 packets are transmitted in standard Ethernet frames."=20 Which of course exactly matches the text I'm questioning in ipwave. So I = see where it comes from. But considering that RFC 2464 was last updated = almost 20 years ago, perhaps the statement is no longer the best way to = describe how IPv6 packets are encapsulated at L2? Anyway, I'm really out of my element here, just doing research. My input = is based on my own experiences and interpretations, having been involved in 1609 stack development and developing products using 1609 WAVE since = 2005. So when I read ipwave, I was (and still am on some issues) confused. So hopefully all of this discussion will result in an ipwave document that clarifies some areas and is less confusing to many of us in the 1609 = WAVE community. I appreciate the discussion. Regards, Kevin P.S. Please do see my comments immediately below ... -----Original Message----- From: its [mailto:its-bounces@ietf.org] On Behalf Of Kevin Smith Sent: Saturday, March 17, 2018 12:26 PM To: 'Tijink Jasja' ; 'Alexandre Petrescu' Cc: its@ietf.org Subject: Re: [ipwave] FW: ipwave - comments and concerns - 1609 WAVE, = EPD - towards resolution Hi Alex, I have the same concern as does Jasja regarding the statement found in = the draft: "IP packets are transmitted over 802.11-OCB as standard Ethernet packets." I believe that statement is technically incorrect, or at best very confusing. The term "Ethernet" is widely used to refer to wired networks specified by IEEE 802.3. Ethernet II (or Ethernet Version 2) is one type = of Ethernet frame format, and the one most widely used in IP networks. = There are others. I'm unsure exactly where Ethernet II is specified, = originally is was specified in "Digital Equipment Corporation, Intel, Xerox, The = Ethernet, Version 2.0, November 1982.", but it must have been incorporated into = 802.3 or perhaps some IETF RFCs? I'd propose the text be revised to something more specific like this: = "IPv6 packets are transmitted over 802.11-OCB as QoS Data frames as specified = in IEEE Std 802.11."=20 Note also I changed "IP" to "IPv6".=20 Regards, Kevin -----Original Message----- From: Tijink Jasja [mailto:Jasja.Tijink@kapsch.net] Sent: Saturday, March 17, 2018 5:37 AM To: Alexandre Petrescu ; Kevin Smith Cc: its@ietf.org Subject: AW: FW: [ipwave] ipwave - comments and concerns - 1609 WAVE, = EPD - towards resolution Hi Alex, on the EAL topic. Take again the following text from the draft: " IP packets are transmitted over 802.11-OCB as standard Ethernet packets. As with all 802.11 frames, an Ethernet adaptation layer MUST be used with 802.11-OCB as well." I understand the second sentence is a requirement you put to = implementations that feature an ethernet interface and an 802.11 interface.=20 But the first sentence: that one seems not true to me according to what = you report of your own tests - 802.11 packets do not have ethernet headers. = So the first sentence is incorrect, right? Or do I simply misunderstand it = and what you want to say is:=20 "IP packets are transmitted over 802.11-OCB as over standard Ethernet: = as with all 802.11 frames, an Ethernet adaptation layer MUST be used with 802.11-OCB as well." Regards Jasja -----Urspr=FCngliche Nachricht----- Von: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] Gesendet: Samstag, 17. M=E4rz 2018 13:10 An: Kevin Smith Cc: Tijink Jasja ; its@ietf.org Betreff: Re: FW: [ipwave] ipwave - comments and concerns - 1609 WAVE, = EPD - towards resolution Le 16/03/2018 =E0 18:34, Kevin Smith a =E9crit : [...] > I suggest that in section 4.2.1 "Ethernet Adaptation Layer" we add the = > following paragraph: >=20 >> The IPv6 packet transmitted on 802.11-OCB MUST be immediately=20 >> preceded by a Logical Link Control (LLC) header and an 802.11 header. = >> In the LLC header, and in accordance with the EtherType Protocol=20 >> Discrimination (EPD), the value of the Type field MUST be set to=20 >> 0x86DD (IPv6). In the 802.11 header, the value of the Subtype=20 >> sub-field in the Frame Control field MUST be set to 8 (i.e. >> 'QoS Data'); the value of the Traffic Identifier (TID) sub-field of=20 >> the QoS Control field of the 802.11 header MUST be set to binary >> 001 (i.e. User Priority 'Background', QoS Access Category 'AC_BK'). >>=20 >> In the Ethernet II header, the value of the Type field MUST be set =20 >> to 0x86DD (IPv6). >=20 > Do you agree with this text? >=20 > [KS]: I agree with the part that addresses the LLC header. I don't=20 > disagree with the part addressing the 802.11 header, I'm just not an =20 > expert in this area and so defer to others. I believe that others in =20 > the 1609 WG have been discussing this with the ipwave list? Noted. Others have discussed the QoS part and there seems to be agreement with that. >> I note that ipwave mentions EPD, but also SNAP and does not specify=20 >> which method to use. >=20 > I propose we remove this phrase: >> Other alternative views of layering are EtherType Protocol=20 >> Discrimination (EPD), see Appendix E, and SNAP see [RFC1042]. >=20 > Do you agree? >=20 > [KS]: Yes. Noted. >> Moreover ipwave discusses an abstract "Ethernet Adaptation Layer"=20 >> but does not specify a header format, and this further confuses the=20 >> question for deployers - what should we implement? >=20 > The Ethernet Adaptation Layer (more precisely 802.11-to-Ethernet AL) =20 > is not so abstract, because it is widely implemented. This layer does=20 > conversion between headers: at reception from the network it=20 > transforms a .11/LLC header into an EthernetII header; reversely, at =20 > sending it transforms an EthernetII header into a .11/LLC header. > This is shown in Figure 1. >=20 > The EAL does not intend to specify a header format. The header formats = > involved are the IEEE 802.11, LLC and EthernetII. The fields in these = > headers are specified by IEEE. >=20 > [KS]: I don't understand why the EAL is relevant to "Transmission of > IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the = > Context of a Basic Service Set". If I want to write software that=20 > sends IPv6 packets over 802.11 OCB, all I need to know is how to=20 > construct the LLC sublayer header, etc. The EAL sounds like a=20 > "bridge", and perhaps belongs in a separate document (and perhaps has=20 > already been addressed in some existing document?) We wanted to have IPv6-over-OCB document that is minimal change from existing works: RFC 2464 IPv6-over-Ethernet and implementations. In implementations, that's how IPv6 works: whenever IPv6 stack wants to = sit on a link layer (802.15.4, WiFi, LTE) it actually sits on an Adaptation Layer. Because IPv6 only knows Ethernet (RFC2464). Whenever a new link layer technology appears, people struggle to make it first look like Ethernet. Only then does IPv6 run easily on it. Because of that, I tend to agree it could makes sense to make an IPv6-over-802.11 document first (including EAL), and the OCB version after. The OCB version would be much smaller. At the same time, such document IPv6-over-802.11 does not exist. It = could not be developped in the IPWAVE WG which is aiming at vehicle = networking, not .11 in general. It would take so long to create a new IPv6-over-.11 document, and only = then to advance the IPv6-over-OCB draft. An additional reason as to why it would take long is that the mapping of IPv6 fields on 802.11 fields is not straightforward at all. (QoS is one aspect, but there is also frag fields, security and more). > Regardless, including a description of the EAL does not violate=20 > anything in 1609.3, as it is out of scope with 1609.3. Noted. >=20 > Some *new comments* from my side: >=20 > - ipwave 4.2.1 it states "An 'adaptation' layer is inserted between a=20 > MAC layer and the Networking layer." This sounds like a requirement. > If I am developing a product that is only concerned with sending IPv6=20 > over OCB, and does not require "bridging", then how do I reconcile=20 > this requirement? It is a requirement indeed. But the adaptation layer is already there, = do not worry. If one develops a new product, one is likely to use existing kernels - = they do include EAL, even though they dont call it so. If one develops from scratch (very rare), one would have to answer = questions like how does Frag fields map between IPv6 and 802.11, security, and = other very complicated questions. Agreement would be needed too. I think one will rather prefer too to rely on Ethernet (RFC2464), as so many other people did in the past. "Bridging": I do not know what you mean by 'bridging'? In linux = bridging is a tool called 'brctl'. It bridges two distinct interfaces, e.g. an = Ethernet interface to a WiFi interface. Here we would 'bridge' Ethernet and 802.11 on the same interface. It's not 'bridging', it's 'adaptation'. Worse: 'brctl' does not work when we want to 'bridge' a OCB interface to = an Ethernet interface. I do not why. I guess the 802. groups will figure = it out one day and fix it. But Ethernet Adaptation Layer (named 'bridging' by you?) works ok. > - ipwave 4.2 it states "IP packets are transmitted over 802.11-OCB as=20 > standard Ethernet packets. As with all 802.11 frames, an Ethernet =20 > adaptation layer MUST be used with 802.11-OCB as well." Again EAL is =20 > stipulated as a requirement. And I'm not sure about the stipulation =20 > that packets are transmitted as "standard Ethernet packets", is this =20 > accurate? YEs. I verify it this way: Use available Wireshark tool on WiFi interface, enable IPv6 on the = computer, and dump some IPv6 packets. They all have EthernetII headers, rather = than LLC and 802.11 headers. Then capture the same in 'monitor' mode, or 'mon' interface in 802.11 OCB, and the .11/LLC headers will = show instead. > Does this mean that 802.3 headers are included? The EthernetII headers (not 802.3 Ethernet, I believe different) are included in the processing during the execution of this EAL. But these EthernetII headers are not sent on the 802.11 air. > This is definitely not stipulated in 1609.3. Packets transmitted over=20 > OCB by a WAVE device using 1609.3 are well formed IPv6 packets, but=20 > not "Ethernet packets", i.e., no 802.3 headers are included. This=20 > seems like an interoperability problem between ipwave and 1609 WAVE. The packets put on the air on 802.11-OCB links with the IPv6-over-OCB = draft do not include EthernetII headers. SO I do not think there is an = interop problem 1609 WAVE with IPv6-over-OCB draft. >=20 >> 2. It is not clear that ipwave provides any functionality=20 >> that 1609 WAVE does not already provide. >=20 > Well, 1609 WAVE does not specify the conversion between .11/LLC=20 > headers and EthernetII headers, right? >=20 > [KS]: Correct it does not, as this topic is out of scope for 1609 WAVE = > (e.g., we don't specify the other interfaces such as Ethernet that may = > be present in the device). Also see my comments above regarding the=20 > EAL. It is in scope here. Maybe 1609 document can refer to here. > 1609 WAVE does not specify the MTU size for IPv6, right? >=20 > [KS]: No it does not. 802.11 (normative to 1609) specifies maximum=20 > MSDU size as 2304 octets. For WSMP 1609.3 specifies a maximum MSDU=20 > size of 2302 (allowing for the 2-octet LLC header), and a default=20 > value of 1400. You are correct in that a MSDU size for IPv6 is not=20 > specified explicitly, but I don't know if some other RFCs related to > IPv6 over 802.11 already do that? Regardless, stipulating a default =20 > value of 1500 for MTU size does not violate anything in 1609.3. Noted. For explanation, the figure 1500 for MTU for IPv6-over-OCB comes from implementations inheriting from old Ethernet behaviour. We dont want to break that. Moreover, it is compatible with RFC8200 (IPv6) which = requires the minimum MTU to be at least 1280bytes for all links supporting IPv6. IPv6 people are aware that many links do support more than 1500bytes = MTU. I heard of 10000bytes for some core links. Yet the IPv6-over-foo for = these links do not require the MTU 10000bytes. >=20 > 1609 WAVE does not specify that IPv6 must be preceded by .11 QoSData =20 > (not just .11 Data), and BACKGROUND, right? >=20 > [KS]: Certainly 1609 does not. 1609 only restricts IPv6 packets to the = > SCH (they are not allowed on the CCH). 802.11 specifies defaults for=20 > all UP and AC parameters, indicates which frame types are allowed,=20 > etc. But as far as I can tell the stipulation that IPv6 use QoSData=20 > and AC_BK is new and something that ipwave introduces? It seems so. People agree with it. > Again, I'm not an expert on this topic and I believe others in the > 1609 WG have been discussing this with the ipwave list. Regardless,=20 > this additional restriction does not violate 1609.3. >=20 > 1609 WAVE does not recommend in particular RFC8064 to form=20 > semantically opaque Interface Identifiers, right? >=20 > [KS]: 1609 does not recommend anything like this, but on the other=20 > hand 1609 does not prohibit it either. 1609 does not generally=20 > speaking "recommend", rather it "specifies" and leaves all else up to=20 > the system designer/implementer/deployer. And as mentioned previously, = > 1609 allows any and all IETF protocols to be implemented. > Regardless, this recommendation does not violate anything in 1609.3. Noted. >=20 > (and a few others). >=20 >> 1609 WAVE includes a number of mechanisms that enable IPv6 networks=20 >> to be configured. In addition to the WSA/WRA mechanism, 1609.3 allows = >> any IETF protocols to be implemented, e.g., IETF RFC 4861, Neighbor=20 >> Discovery for IP Version 6 (IPv6) (which is listed as a normative=20 >> reference in 1609.3). Helpful would be some example use-cases that=20 >> illustrate problems to be solved, and how ipwave will solve those=20 >> problems (i.e., that 1609 WAVE does not already solve). >=20 > There is a draft that describes some use-cases of IPv6 in vehicular > networks: draft-ietf-ipwave-vehicular-networking-02 >=20 > [KS]: Thanks for pointing me to that, lots of info there! I'll spend =20 > some time reviewing that when I can. >=20 > I think some parts of 1609 WAVE, in particular WRA, are not used in=20 > Europe. Whereas this IPv6-over-OCB draft is used the same wherever=20 > Internet is present (Europe, America, Continents). >=20 > [KS]: 1609 went to great lengths to harmonize WSM and WSA frame=20 > formats with ISO/ETSI standards, these harmonized frames are included=20 > in all of the -2016 revisions to 1609. So for example the 1609.3 WSA=20 > is interoperable with the service advertisement used in Europe. See=20 > ISO 16460, and see also ETSI TS 102 890-1. I agree harmonization is good and needed. In case that harmonization relies on IPv6 as specified at IETF, these = are my comments to the ETSI document. Quickly skimming, it calls it "IPv6 routing advertisement". It is "IPv6 Router Advertisement". The 'default' route is used when no other route is available. The = 'default' route typically gives access to the Internet, not to one particular = server ("ITS-S": station). For particular servers, one may use RFC4191 = instead, for "more specific routes" or, the routes known as 'host-based routes'. Thank you for the comments. Alex >> My concern is that the IETF ipwave document may cause significant=20 >> confusion among deployers, and possibly lead to a lack of=20 >> interoperability. Thank you for the opportunity to comment, I look=20 >> forward to the discussion. >=20 > I would like to help with clarification. Let us discuss this. >=20 > [KS]: Sounds good! >=20 > Alex >=20 >>=20 >>=20 >>=20 >> Best regards, >>=20 >> Kevin >=20 > _______________________________________________ its mailing list=20 > its@ietf.org https://www.ietf.org/mailman/listinfo/its >=20 >=20 _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its From nobody Sun Mar 18 11:13: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 5880B126DFF for ; Sun, 18 Mar 2018 11:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7Jbd30fYF_C for ; Sun, 18 Mar 2018 11:13:49 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AA41124D6C for ; Sun, 18 Mar 2018 11:13:48 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w2IIDeXE024883; Sun, 18 Mar 2018 19:13:40 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9BC49201642; Sun, 18 Mar 2018 19:13: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 885FC200E9F; Sun, 18 Mar 2018 19:13:40 +0100 (CET) Received: from [132.166.84.93] ([132.166.84.93]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w2IIDeng011538; Sun, 18 Mar 2018 19:13:40 +0100 To: Kevin Smith , dickroy@alum.mit.edu, "'Jerome Haerri'" Cc: "'Tijink Jasja'" , its@ietf.org References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <5cc6bd32-0812-288a-2db0-b0de53626f1e@gmail.com> <00c501d3bee0$26270700$72751500$@cox.net> From: Alexandre Petrescu Message-ID: Date: Sun, 18 Mar 2018 19:13:39 +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: <00c501d3bee0$26270700$72751500$@cox.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] =?utf-8?q?=5Bipwave=C3=AE=5D_IPv6-over-OCB_as_a_profile?= =?utf-8?q?_of_1609_WAVE?= X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 18 Mar 2018 18:13:51 -0000 Le 18/03/2018 18:40, Kevin Smith a crit: > Hello Jerome and all, > > As Dick points out, IPv6 does not in any way rely on WSMP. > > IPv6 packets are NOT encapsulated by WSM. WSMP and IPv6 are two > completely separate protocols. I tend to agree IPv6 is not encapsulated by WSM. But, IPv6 means more things than just the way packets are encapsulated. In particular IPv6 also means SLAAC. SLAAC is a mandatory part of IPv6. SLAAC is an IPv6 protocol and uses IPv6 Router Advertisements. SLAAC does not use WRAs. In this sense, WSMP specifying that SLAAC uses WRA, can be read as IPv6 relying on WSMP. Alex > > Best, > > Kevin > > *From:*Dick Roy [mailto:dickroy@alum.mit.edu] > *Sent:* Sunday, March 18, 2018 9:44 AM > *To:* 'Jerome Haerri' ; 'Alexandre Petrescu' > > *Cc:* 'Tijink Jasja' ; 'Kevin Smith' > ; its@ietf.org > *Subject:* RE: [ipwave] [ipwave] IPv6-over-OCB as a profile of 1609 WAVE > > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Jerome Haerri > Sent: Sunday, March 18, 2018 5:24 PM > To: Alexandre Petrescu > Cc: Tijink Jasja; Kevin Smith; its@ietf.org > Subject: Re: [ipwave] [ipwave] IPv6-over-OCB as a profile of 1609 WAVE > > Dear All, > > I disagree for two reasons: > > First this is not a profile, but an alternative operation of IP without > relying on WSM. > > [RR] WSMP is a networking (and transport) protocol just like IP. The > above statement makes no sense in that respect. One network layer > protocol never "relies on another". That said, if IPv6-over-OCB is a > profile of some other set of standards, then you are wasting your time. > What is needed are modifications to IPv6 to handle rapidly varying > network topologies. Where have you heard that before?? ^))) We don't > need or want the IETF to specify how lower layers MUST behave when > sending IP packets. Naturally if there are recommendations for lower > layer performance that will make the IP functions perform better, make > those recommendations. Just NO SHALLs or MUSTs on any lower layer > protocols please! Stick to IPv6 funtionality. > > Second, this document will also apply outside of the US, and then IEEE > 1609.3 does not apply and thus would make this document confusing. > > [RR] Not so. IEEE 1609 is an international set of standards, and in > particular, IEEE 1609.3 is over the air interoperable with ISO 29281-2 > FNTP and therefore can operate anywhere FNTP operates around the world. > > Best Regards, > > Jrme > > Envoy de mon iPhone > > > Le 18 mars 2018 16:15, Alexandre Petrescu > > a > crit : > > > > > > Hi IPWAVErs, > > > > > > Do you disagree we add this phrase in the Introduction: > > > > > >> This document is a profile based on IEEE 1609.3: it introduces > additional requirements and specifications that do not violate that base > standard. > > > > > > For my part I find addition of this text neutral and ok, although I am > > > not sure what is a profile for 1609 WAVE. In Bluetooth, a 'profile' is > > > something very much precise, like 'LAN profile', etc. > > > > > > Alex > > > > > > > > >> Le 17/03/2018 13:22, Tijink Jasja a crit : > > >> Hello Alex, > > >> Can we put something at the beginning of > draft-ietf-ipwave-ipv6-over-80211ocb-21, maybe in the introduction? > > >> I suggest some language like the following: > > >> This document is a profile based on IEEE 1609.3: it introduces > additional requirements and specifications that do not violate that base > standard. > > >> Regards Jasja > > >> -----Ursprngliche Nachricht----- Von: Alexandre Petrescu > [mailto:alexandre.petrescu@gmail.com] Gesendet: Samstag, 17. Mrz 2018 > 12:23 An: Tijink Jasja > Cc: Kevin > > >> Smith >; > its@ietf.org Betreff: Re: [ipwave] > > >> ipwave - comments and concerns - 1609 WAVE, EPD - towards resolution > > >> Hello Jasja, > > >>> Le 16/03/2018 19:02, Tijink Jasja a crit : > > >>> Hello Alex, > > >>> in addition to Kevin's points, I would like to mention that: > > >>> 1. I welcome your proposal for the additional text that specifies > QoS. This is necessary for operation in Europe (the specification for > the access layer can be found in ETSI EN 302 663, where clause 4.6 says > that QoS shall be used). > > >> Noted. > > >>> 2. My understanding of the discussion below is that > draft-ietf-ipwave-ipv6-over-80211ocb-21 is "based on" IEEE 1609.3 in > that it is compliant with it (I didn't find any "violation of IEEE > 1609.3), and adds additional restrictions and /or specifications (such a > MTU size, AC_BK, RFC8064, etc.). In that sense > draft-ietf-ipwave-ipv6-over-80211ocb-21 is a profile of IEEE 1609.3. I > would suggest making that very clear, with a short sentence/paragraph in > draft-ietf-ipwave-ipv6-over-80211ocb-21 that > > >>> explains it to the reader. If you disagree, I would like to hear > your view on the relation of IEEE 1609.3 and > draft-ietf-ipwave-ipv6-over-80211ocb-21. > > >> I dont really disagree, just where to put it. > > >> The draft does refer to 1609.3, in Appendix C "aspects introduced by > OCB to 802.11". The vehicular networking draft > (draft-ietf-ipwave-vehicular-networking-01) also refers to it right at > the beginning. > > >> IPv6-over-OCB sounds like an explanation. As such, I suggest we > first write more precisely that "IPv6-over-OCB is a profile of 1609.3" > and then put it into the vehicular networking draft. > > >> How could that be written? > > >> 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 Sun Mar 18 11:17: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 D4BCE126BF3 for ; Sun, 18 Mar 2018 11:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zW5_Ce2m-61F for ; Sun, 18 Mar 2018 11:17:26 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC494124D6C for ; Sun, 18 Mar 2018 11:17:25 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w2IIHH8O042082; Sun, 18 Mar 2018 19:17:17 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 95E3B200C1F; Sun, 18 Mar 2018 19:17: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 83442200B95; Sun, 18 Mar 2018 19:17:17 +0100 (CET) Received: from [132.166.84.93] ([132.166.84.93]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w2IIHGeW013960; Sun, 18 Mar 2018 19:17:16 +0100 To: Kevin Smith , dickroy@alum.mit.edu, "'Tijink Jasja'" Cc: its@ietf.org References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <004101d3be2a$116baed0$34430c70$@cox.net> <00f401d3bee4$90860700$b1921500$@cox.net> From: Alexandre Petrescu Message-ID: <75b07c49-f201-a316-47fc-62edf75d64f6@gmail.com> Date: Sun, 18 Mar 2018 19:17: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: <00f401d3bee4$90860700$b1921500$@cox.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] FW: ipwave - comments and concerns - 1609 WAVE, EPD - 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: Sun, 18 Mar 2018 18:17:31 -0000 Le 18/03/2018 à 19:11, Kevin Smith a écrit : > Hello All, > > Thank you Dick for the clarification regarding Ethernet II: It has been > incorporated into IEEE 802.3. I suspected it but didn't have the time to dig > into it. I believe it is accurate to say that if we write "Ethernet frame" > then we are talking about a frame specified by IEEE 802.3. > > Regarding using QoS data frames - ipwave does not intend to state that it is > a requirement in 802.11. Clearly 802.11 lists several options for frame > types when operating OCB. However ipwave (if for example it were a profile > of 1609.3) is requiring that QoS data frames be used. > > The text, that I wrote, on review, is ambiguous. However Alex has restated > it as "IP packets MUST be transmitted over 802.11-OCB media as QoS Data > frames whose format is specified in IEEE Std 802.11." We agree on the list that 802.11 document allows IPv6 be transmitted as QoSData, or Data. We also agree (roughly 6 to 3) that in OCB mode, for vehicles it is best QoSData and BACKGROUND (not Data, not QoSData and VOICE, or any other). This text will be on the slide tomorrow. Alex > > Best, > Kevin > > -----Original Message----- > From: Dick Roy [mailto:dickroy@alum.mit.edu] > Sent: Sunday, March 18, 2018 3:22 AM > To: 'Kevin Smith' ; 'Tijink Jasja' > ; 'Alexandre Petrescu' > > Cc: its@ietf.org > Subject: RE: [ipwave] FW: ipwave - comments and concerns - 1609 WAVE, EPD - > towards resolution > > The confusion starts with the undefined term "Ethernet Adaptation Layer > (EAL)" and the misguided attempts to use that term in the document. > > There in NO adaptation layer in 1609.3/802.11-OCB. At the MAC sublayer, > type encoding is used in the 5.9GHz band, that's it. BTW - at the MAC > sublayer, PDUs are called frames. So IPv6 packets (NPDUs) are MSDUs. There > is no adaptation necessary. > > As for QoS data frames, once again that is NOT a requirement in 802.11 (or > 1609.3) so don't say that! > > Ethernet II is part of 802.3, and today the only used part. Length encoding > (and SNAP) at the LLC sublayer are appendages that are rapidly dying away > now. The most important fact is that they are NOT used in IPv6 / 802.11-OCB > in 5.9GHz. > > RR > > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Kevin Smith > Sent: Saturday, March 17, 2018 8:57 PM > To: 'Tijink Jasja'; 'Alexandre Petrescu' > Cc: its@ietf.org > Subject: Re: [ipwave] FW: ipwave - comments and concerns - 1609 WAVE, EPD - > towards resolution > > Addendum: Looking at RFC 2464, I see in clause 3. Frame Format the statement > "IPv6 packets are transmitted in standard Ethernet frames." > > Which of course exactly matches the text I'm questioning in ipwave. So I see > where it comes from. But considering that RFC 2464 was last updated almost > 20 years ago, perhaps the statement is no longer the best way to describe > how IPv6 packets are encapsulated at L2? > > Anyway, I'm really out of my element here, just doing research. My input is > based on my own experiences and interpretations, having been involved in > 1609 stack development and developing products using 1609 WAVE since 2005. > So when I read ipwave, I was (and still am on some issues) confused. So > hopefully all of this discussion will result in an ipwave document that > clarifies some areas and is less confusing to many of us in the 1609 WAVE > community. > > I appreciate the discussion. > > Regards, > Kevin > P.S. Please do see my comments immediately below ... > > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Kevin Smith > Sent: Saturday, March 17, 2018 12:26 PM > To: 'Tijink Jasja' ; 'Alexandre Petrescu' > > Cc: its@ietf.org > Subject: Re: [ipwave] FW: ipwave - comments and concerns - 1609 WAVE, EPD - > towards resolution > > Hi Alex, > > I have the same concern as does Jasja regarding the statement found in the > draft: "IP packets are transmitted over 802.11-OCB as standard Ethernet > packets." > > I believe that statement is technically incorrect, or at best very > confusing. The term "Ethernet" is widely used to refer to wired networks > specified by IEEE 802.3. Ethernet II (or Ethernet Version 2) is one type of > Ethernet frame format, and the one most widely used in IP networks. There > are others. I'm unsure exactly where Ethernet II is specified, originally is > was specified in "Digital Equipment Corporation, Intel, Xerox, The Ethernet, > Version 2.0, November 1982.", but it must have been incorporated into 802.3 > or perhaps some IETF RFCs? > > I'd propose the text be revised to something more specific like this: "IPv6 > packets are transmitted over 802.11-OCB as QoS Data frames as specified in > IEEE Std 802.11." > > Note also I changed "IP" to "IPv6". > > Regards, > Kevin > > -----Original Message----- > From: Tijink Jasja [mailto:Jasja.Tijink@kapsch.net] > Sent: Saturday, March 17, 2018 5:37 AM > To: Alexandre Petrescu ; Kevin Smith > > Cc: its@ietf.org > Subject: AW: FW: [ipwave] ipwave - comments and concerns - 1609 WAVE, EPD - > towards resolution > > Hi Alex, > > on the EAL topic. Take again the following text from the draft: > > " IP packets are transmitted over 802.11-OCB as standard Ethernet > packets. As with all 802.11 frames, an Ethernet adaptation layer > MUST be used with 802.11-OCB as well." > > I understand the second sentence is a requirement you put to implementations > that feature an ethernet interface and an 802.11 interface. > > But the first sentence: that one seems not true to me according to what you > report of your own tests - 802.11 packets do not have ethernet headers. So > the first sentence is incorrect, right? Or do I simply misunderstand it and > what you want to say is: > > "IP packets are transmitted over 802.11-OCB as over standard Ethernet: as > with all 802.11 frames, an Ethernet adaptation layer MUST be used with > 802.11-OCB as well." > > > Regards Jasja > > > -----Ursprüngliche Nachricht----- > Von: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] > Gesendet: Samstag, 17. März 2018 13:10 > An: Kevin Smith > Cc: Tijink Jasja ; its@ietf.org > Betreff: Re: FW: [ipwave] ipwave - comments and concerns - 1609 WAVE, EPD - > towards resolution > > > Le 16/03/2018 à 18:34, Kevin Smith a écrit : > [...] > >> I suggest that in section 4.2.1 "Ethernet Adaptation Layer" we add the >> following paragraph: >> >>> The IPv6 packet transmitted on 802.11-OCB MUST be immediately >>> preceded by a Logical Link Control (LLC) header and an 802.11 header. >>> In the LLC header, and in accordance with the EtherType Protocol >>> Discrimination (EPD), the value of the Type field MUST be set to >>> 0x86DD (IPv6). In the 802.11 header, the value of the Subtype >>> sub-field in the Frame Control field MUST be set to 8 (i.e. >>> 'QoS Data'); the value of the Traffic Identifier (TID) sub-field of >>> the QoS Control field of the 802.11 header MUST be set to binary >>> 001 (i.e. User Priority 'Background', QoS Access Category 'AC_BK'). >>> >>> In the Ethernet II header, the value of the Type field MUST be set >>> to 0x86DD (IPv6). >> >> Do you agree with this text? >> >> [KS]: I agree with the part that addresses the LLC header. I don't >> disagree with the part addressing the 802.11 header, I'm just not an >> expert in this area and so defer to others. I believe that others in >> the 1609 WG have been discussing this with the ipwave list? > > Noted. > > Others have discussed the QoS part and there seems to be agreement with > that. > >>> I note that ipwave mentions EPD, but also SNAP and does not specify >>> which method to use. >> >> I propose we remove this phrase: >>> Other alternative views of layering are EtherType Protocol >>> Discrimination (EPD), see Appendix E, and SNAP see [RFC1042]. >> >> Do you agree? >> >> [KS]: Yes. > > Noted. > >>> Moreover ipwave discusses an abstract "Ethernet Adaptation Layer" >>> but does not specify a header format, and this further confuses the >>> question for deployers - what should we implement? >> >> The Ethernet Adaptation Layer (more precisely 802.11-to-Ethernet AL) >> is not so abstract, because it is widely implemented. This layer does >> conversion between headers: at reception from the network it >> transforms a .11/LLC header into an EthernetII header; reversely, at >> sending it transforms an EthernetII header into a .11/LLC header. >> This is shown in Figure 1. >> >> The EAL does not intend to specify a header format. The header formats >> involved are the IEEE 802.11, LLC and EthernetII. The fields in these >> headers are specified by IEEE. >> >> [KS]: I don't understand why the EAL is relevant to "Transmission of >> IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the >> Context of a Basic Service Set". If I want to write software that >> sends IPv6 packets over 802.11 OCB, all I need to know is how to >> construct the LLC sublayer header, etc. The EAL sounds like a >> "bridge", and perhaps belongs in a separate document (and perhaps has >> already been addressed in some existing document?) > > We wanted to have IPv6-over-OCB document that is minimal change from > existing works: RFC 2464 IPv6-over-Ethernet and implementations. > > In implementations, that's how IPv6 works: whenever IPv6 stack wants to sit > on a link layer (802.15.4, WiFi, LTE) it actually sits on an Adaptation > Layer. Because IPv6 only knows Ethernet (RFC2464). > > Whenever a new link layer technology appears, people struggle to make it > first look like Ethernet. Only then does IPv6 run easily on it. > > Because of that, I tend to agree it could makes sense to make an > IPv6-over-802.11 document first (including EAL), and the OCB version > after. The OCB version would be much smaller. > > At the same time, such document IPv6-over-802.11 does not exist. It could > not be developped in the IPWAVE WG which is aiming at vehicle networking, > not .11 in general. > > It would take so long to create a new IPv6-over-.11 document, and only then > to advance the IPv6-over-OCB draft. > > An additional reason as to why it would take long is that the mapping of > IPv6 fields on 802.11 fields is not straightforward at all. (QoS is one > aspect, but there is also frag fields, security and more). > >> Regardless, including a description of the EAL does not violate >> anything in 1609.3, as it is out of scope with 1609.3. > > Noted. > >> >> Some *new comments* from my side: >> >> - ipwave 4.2.1 it states "An 'adaptation' layer is inserted between a >> MAC layer and the Networking layer." This sounds like a requirement. >> If I am developing a product that is only concerned with sending IPv6 >> over OCB, and does not require "bridging", then how do I reconcile >> this requirement? > > It is a requirement indeed. But the adaptation layer is already there, do > not worry. > > If one develops a new product, one is likely to use existing kernels - they > do include EAL, even though they dont call it so. > > If one develops from scratch (very rare), one would have to answer questions > like how does Frag fields map between IPv6 and 802.11, security, and other > very complicated questions. Agreement would be > needed too. I think one will rather prefer too to rely on Ethernet > (RFC2464), as so many other people did in the past. > > "Bridging": I do not know what you mean by 'bridging'? In linux bridging is > a tool called 'brctl'. It bridges two distinct interfaces, e.g. an Ethernet > interface to a WiFi interface. Here we would 'bridge' > Ethernet and 802.11 on the same interface. It's not 'bridging', it's > 'adaptation'. > > Worse: 'brctl' does not work when we want to 'bridge' a OCB interface to an > Ethernet interface. I do not why. I guess the 802. groups will figure it > out one day and fix it. > > But Ethernet Adaptation Layer (named 'bridging' by you?) works ok. > >> - ipwave 4.2 it states "IP packets are transmitted over 802.11-OCB as >> standard Ethernet packets. As with all 802.11 frames, an Ethernet >> adaptation layer MUST be used with 802.11-OCB as well." Again EAL is >> stipulated as a requirement. And I'm not sure about the stipulation >> that packets are transmitted as "standard Ethernet packets", is this >> accurate? > > YEs. > > I verify it this way: > > Use available Wireshark tool on WiFi interface, enable IPv6 on the computer, > and dump some IPv6 packets. They all have EthernetII headers, rather than > LLC and 802.11 headers. Then capture the same in 'monitor' > mode, or 'mon' interface in 802.11 OCB, and the .11/LLC headers will show > instead. > >> Does this mean that 802.3 headers are included? > > The EthernetII headers (not 802.3 Ethernet, I believe different) are > included in the processing during the execution of this EAL. But these > EthernetII headers are not sent on the 802.11 air. > >> This is definitely not stipulated in 1609.3. Packets transmitted over >> OCB by a WAVE device using 1609.3 are well formed IPv6 packets, but >> not "Ethernet packets", i.e., no 802.3 headers are included. This >> seems like an interoperability problem between ipwave and 1609 WAVE. > > The packets put on the air on 802.11-OCB links with the IPv6-over-OCB draft > do not include EthernetII headers. SO I do not think there is an interop > problem 1609 WAVE with IPv6-over-OCB draft. > >> >>> 2. It is not clear that ipwave provides any functionality >>> that 1609 WAVE does not already provide. >> >> Well, 1609 WAVE does not specify the conversion between .11/LLC >> headers and EthernetII headers, right? >> >> [KS]: Correct it does not, as this topic is out of scope for 1609 WAVE >> (e.g., we don't specify the other interfaces such as Ethernet that may >> be present in the device). Also see my comments above regarding the >> EAL. > > It is in scope here. Maybe 1609 document can refer to here. > >> 1609 WAVE does not specify the MTU size for IPv6, right? >> >> [KS]: No it does not. 802.11 (normative to 1609) specifies maximum >> MSDU size as 2304 octets. For WSMP 1609.3 specifies a maximum MSDU >> size of 2302 (allowing for the 2-octet LLC header), and a default >> value of 1400. You are correct in that a MSDU size for IPv6 is not >> specified explicitly, but I don't know if some other RFCs related to >> IPv6 over 802.11 already do that? Regardless, stipulating a default >> value of 1500 for MTU size does not violate anything in 1609.3. > > Noted. > > For explanation, the figure 1500 for MTU for IPv6-over-OCB comes from > implementations inheriting from old Ethernet behaviour. We dont want to > break that. Moreover, it is compatible with RFC8200 (IPv6) which requires > the minimum MTU to be at least 1280bytes for all links supporting IPv6. > > IPv6 people are aware that many links do support more than 1500bytes MTU. I > heard of 10000bytes for some core links. Yet the IPv6-over-foo for these > links do not require the MTU 10000bytes. > > >> >> 1609 WAVE does not specify that IPv6 must be preceded by .11 QoSData >> (not just .11 Data), and BACKGROUND, right? >> >> [KS]: Certainly 1609 does not. 1609 only restricts IPv6 packets to the >> SCH (they are not allowed on the CCH). 802.11 specifies defaults for >> all UP and AC parameters, indicates which frame types are allowed, >> etc. But as far as I can tell the stipulation that IPv6 use QoSData >> and AC_BK is new and something that ipwave introduces? > > It seems so. People agree with it. > >> Again, I'm not an expert on this topic and I believe others in the >> 1609 WG have been discussing this with the ipwave list. Regardless, >> this additional restriction does not violate 1609.3. >> >> 1609 WAVE does not recommend in particular RFC8064 to form >> semantically opaque Interface Identifiers, right? >> >> [KS]: 1609 does not recommend anything like this, but on the other >> hand 1609 does not prohibit it either. 1609 does not generally >> speaking "recommend", rather it "specifies" and leaves all else up to >> the system designer/implementer/deployer. And as mentioned previously, >> 1609 allows any and all IETF protocols to be implemented. >> Regardless, this recommendation does not violate anything in 1609.3. > > Noted. > >> >> (and a few others). >> >>> 1609 WAVE includes a number of mechanisms that enable IPv6 networks >>> to be configured. In addition to the WSA/WRA mechanism, 1609.3 allows >>> any IETF protocols to be implemented, e.g., IETF RFC 4861, Neighbor >>> Discovery for IP Version 6 (IPv6) (which is listed as a normative >>> reference in 1609.3). Helpful would be some example use-cases that >>> illustrate problems to be solved, and how ipwave will solve those >>> problems (i.e., that 1609 WAVE does not already solve). >> >> There is a draft that describes some use-cases of IPv6 in vehicular >> networks: draft-ietf-ipwave-vehicular-networking-02 >> >> [KS]: Thanks for pointing me to that, lots of info there! I'll spend >> some time reviewing that when I can. >> >> I think some parts of 1609 WAVE, in particular WRA, are not used in >> Europe. Whereas this IPv6-over-OCB draft is used the same wherever >> Internet is present (Europe, America, Continents). >> >> [KS]: 1609 went to great lengths to harmonize WSM and WSA frame >> formats with ISO/ETSI standards, these harmonized frames are included >> in all of the -2016 revisions to 1609. So for example the 1609.3 WSA >> is interoperable with the service advertisement used in Europe. See >> ISO 16460, and see also ETSI TS 102 890-1. > > I agree harmonization is good and needed. > > In case that harmonization relies on IPv6 as specified at IETF, these are my > comments to the ETSI document. > > Quickly skimming, it calls it "IPv6 routing advertisement". It is "IPv6 > Router Advertisement". > > The 'default' route is used when no other route is available. The 'default' > route typically gives access to the Internet, not to one particular server > ("ITS-S": station). For particular servers, one may use RFC4191 instead, > for "more specific routes" or, the routes known as 'host-based routes'. > > Thank you for the comments. > > Alex > > > >>> My concern is that the IETF ipwave document may cause significant >>> confusion among deployers, and possibly lead to a lack of >>> interoperability. Thank you for the opportunity to comment, I look >>> forward to the discussion. >> >> I would like to help with clarification. Let us discuss this. >> >> [KS]: Sounds good! >> >> Alex >> >>> >>> >>> >>> Best regards, >>> >>> Kevin >> >> _______________________________________________ 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 Sun Mar 18 11:20: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 B2464124D6C for ; Sun, 18 Mar 2018 11:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQIJWYZ-gWqu for ; Sun, 18 Mar 2018 11:20:27 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F79812025C for ; Sun, 18 Mar 2018 11:20:27 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w2IIKJg3025589; Sun, 18 Mar 2018 19:20:19 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id CD35D200DEB; Sun, 18 Mar 2018 19:20: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 B5AAA200C32; Sun, 18 Mar 2018 19:20:19 +0100 (CET) Received: from [132.166.84.93] ([132.166.84.93]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w2IIKIu4015558; Sun, 18 Mar 2018 19:20:19 +0100 To: dickroy@alum.mit.edu, "'Tijink Jasja'" , tony.li@tony.li Cc: "'Kevin Smith'" , "'Jerome Haerri'" , its@ietf.org References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <5cc6bd32-0812-288a-2db0-b0de53626f1e@gmail.com> <97e69e6a-72d4-fcf9-65ce-4c2042dd2f8c@gmail.com> <267E8545CBC54201B933BB3E4E0BFAF2@SRA6> From: Alexandre Petrescu Message-ID: <1ce014cd-c0b0-0dc2-9cca-f0fe1335f521@gmail.com> Date: Sun, 18 Mar 2018 19:20:18 +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: <267E8545CBC54201B933BB3E4E0BFAF2@SRA6> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] =?utf-8?q?=5Bipwave=C3=AE=5D_IPv6-over-OCB_as_a_profile?= =?utf-8?q?_of_1609_WAVE?= X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 18 Mar 2018 18:20:30 -0000 Le 18/03/2018 à 19:01, Dick Roy a écrit : > The WRA in a WSA optionally contains a local IPv6 prefix so that SLAAC can > be performed in the receiver of the WSA/WRA. It does not state how. That > is left to the IETF RFCs naturally. Is there a requirement from IEEE to IETF to develop a SLAAC with WRAs instead of RAs? Or is it just a writer musings about how it could work? Is there an implementation of SLAAC with WRAs? Alex > > More below ... > > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu > Sent: Sunday, March 18, 2018 6:53 PM > To: Tijink Jasja; tony.li@tony.li > Cc: Kevin Smith; Jerome Haerri; its@ietf.org > Subject: Re: [ipwave] [ipwaveî] IPv6-over-OCB as a profile of 1609 WAVE > > > > Le 18/03/2018 à 18:08, Tijink Jasja a écrit : >> .so if we put it that way: >> >> Is it possible to explain how an implementation of this draft >> interoperates with an implementation of IEEE 1609.3? > > To me, 1609.3 should just refer to IETF, this draft, abunch of other > RFCs, and have no normative text about what IP should or should not do. > > [RR] That is exactly what it does. Where did you get any ideas to the > contrary > > At some points where 1609.3 feels inclined and tempted to do IP, could > copy paste some parts of this draft, reflect some values. E.g. 1609.3 > should also say "IP on OCB as QoSData with BK and MTU1500". > > Then we are sure to have interoperability between an IPv6-over-OCB > computer and an 1609.3 computer. > > But an 1609.3 document that says SLAAC uses WRA is a risk to > interoperability. > [RR] See above. You have it backwards. > > Alex > >> >> Regards Jasja >> >> *Von:*Tony Li [mailto:tony1athome@gmail.com] *Im Auftrag von >> *tony.li@tony.li >> *Gesendet:* Sonntag, 18. März 2018 17:50 >> *An:* Tijink Jasja >> *Cc:* Jerome Haerri ; Alexandre Petrescu >> ; Kevin Smith ; >> its@ietf.org >> *Betreff:* Re: [ipwave] [ipwaveî] IPv6-over-OCB as a profile of 1609 WAVE >> >> Anyhow, even if you don't like the sentence can your answer our >> original question: what functionality does the draft provide that >>  1609 WAVE does not already provide (except for the EAL aspect, >> which seems more an implementation requirement)? >> >> The point is not to provide functionality. Rather, the point is to >> document an agreement on what implementations should do if they want to >> be interoperable. As noted, there are many conceivable ways of >> transmitting IPv6 over OCB. We want to agree on just one.  That's >> necessary and sufficient for this document. >> >> Tony >> > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > From nobody Sun Mar 18 12:28: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 87EDF129C59 for ; Sun, 18 Mar 2018 12:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.931 X-Spam-Level: X-Spam-Status: No, score=-1.931 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 N38jhVvPA9cs for ; Sun, 18 Mar 2018 12:28:04 -0700 (PDT) Received: from fed1rmfepo103.cox.net (fed1rmfepo103.cox.net [68.230.241.145]) by ietfa.amsl.com (Postfix) with ESMTP id 85ACC126D73 for ; Sun, 18 Mar 2018 12:28:04 -0700 (PDT) Received: from fed1rmimpo210.cox.net ([68.230.241.161]) by fed1rmfepo103.cox.net (InterMail vM.8.01.05.28 201-2260-151-171-20160122) with ESMTP id <20180318192804.RTQQ4490.fed1rmfepo103.cox.net@fed1rmimpo210.cox.net> for ; Sun, 18 Mar 2018 15:28:04 -0400 Received: from smithPC ([174.68.115.141]) by fed1rmimpo210.cox.net with cox id PXU31x00Y336m1J01XU31l; Sun, 18 Mar 2018 15:28:03 -0400 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A090205.5AAEBDC4.0002, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.2 cv=WL0PZjkR c=1 sm=1 tr=0 a=lZ+2k6HZ6QqstbCzvfe+bA==:117 a=lZ+2k6HZ6QqstbCzvfe+bA==:17 a=IkcTkHD0fZMA:10 a=x7bEGLp0ZPQA:10 a=kGgg9RDvKM0A:10 a=48vgC7mUAAAA:8 a=A1EfXRNyAAAA:8 a=kviXuzpPAAAA:8 a=lYzDGeMn1uVqOu6hEPgA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=ho1zAXZTouNDp1r8zZ_w:22 a=qrIFiuKZe2vaD64auk6j:22 X-CM-Score: 0.00 Authentication-Results: cox.net; auth=pass (LOGIN) smtp.auth=kevin.s.smith@cox.net From: "Kevin Smith" To: "'Alexandre Petrescu'" Cc: "'Tijink Jasja'" , "'Tony Li'" , References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> In-Reply-To: Date: Sun, 18 Mar 2018 12:28:09 -0700 Message-ID: <011701d3beef$3fc03a60$bf40af20$@cox.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGhOrR8o8b5YryKQCC/S9k90bJ5fwGaWEJkAgugfycBhvEjmgFRTB0vAxNaQq6j7r6aYA== Content-Language: en-us Archived-At: Subject: Re: [ipwave] clarification of EAL text X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 18 Mar 2018 19:28:06 -0000 Hi Alex, I think the NEW proposed text has resolved a few of the issues I've been = concerned about. However the statement "Within an IP-RSU, or within an = IP-OBU, the IP packets are communicated by the IP stack to and from the = 802.11-OCB driver as standard Ethernet II frames." seems to make some = assumptions about implementations. As data travels up the layered protocol stack, headers are processed and = stripped off, payloads delivered to the next higher layer. It seems like = an assumption to say that an 802.11-OCB driver will receive Ethernet II = frames. It might instead receive IPv6 packets and use some mechanism = (implementation dependent) to determine that the packet needs to be = routed over 802.11-OCB.=20 A system diagram showing typical IP-RSU/IP-OBU communication flow would = be helpful, to identify system architecture assumptions being made by = ipwave. Best, Kevin -----Original Message----- From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu Sent: Sunday, March 18, 2018 10:27 AM Cc: Tijink Jasja ; Kevin Smith = ; Tony Li ; its@ietf.org Subject: Re: [ipwave] clarification of EAL text I suggest this clarification of the EAL text. OLD: > IP packets are transmitted over 802.11-OCB as standard Ethernet=20 > packets. As with all 802.11 frames, an Ethernet adaptation layer MUST = > be used with 802.11-OCB as well." NEW: > Within an IP-RSU, or within an IP-OBU, the IP packets are communicated = > by the IP stack to and from the 802.11-OCB driver as standard Ethernet = > II frames. IP packets MUST be transmitted over 802.11-OCB media as=20 > QoS Data frames whose format is specified in IEEE Std 802.11. >=20 > Before sending the IP packets on the 802.11 media, and after receiving = > packets from the 802.11 media, the use of an adaptation layer that=20 > adapts between the frame formats of 802.11 and of Ethernet II is=20 > RECOMMENDED. The Ethernet II headers MUST NOT be transmitted on > 802.11 media. Alex Le 17/03/2018 =C3=A0 13:50, Tony Li a =C3=A9crit : >=20 >> on the EAL topic. Take again the following text from the draft: >>=20 >> " IP packets are transmitted over 802.11-OCB as standard Ethernet=20 >> packets. As with all 802.11 frames, an Ethernet adaptation layer=20 >> MUST be used with 802.11-OCB as well." >>=20 >> I understand the second sentence is a requirement you put to=20 >> implementations that feature an ethernet interface and an 802.11=20 >> interface. >=20 >=20 > I suspect that we=E2=80=99ll also get some push back on this sentence = because=20 > it is implied to be normative. Since the EAL doesn=E2=80=99t actually = affect=20 > the bits on the air, this is simply an implementation choice and not=20 > strictly mandatory. >=20 > It would probably be easier if we relaxed the wording to make this=20 > informative or recommended instead. >=20 > Tony >=20 >=20 _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its From nobody Sun Mar 18 13:19: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 D61FA12AAB6 for ; Sun, 18 Mar 2018 13:19:57 -0700 (PDT) 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 fyM8mmUNpBIk for ; Sun, 18 Mar 2018 13:19:54 -0700 (PDT) Received: from smtp2.eurecom.fr (smtp2.eurecom.fr [193.55.113.211]) by ietfa.amsl.com (Postfix) with ESMTP id B840E127876 for ; Sun, 18 Mar 2018 13:19:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.48,327,1517871600"; d="scan'208,217";a="7793779" Received: from monza.eurecom.fr ([192.168.106.15]) by drago2i.eurecom.fr with ESMTP; 18 Mar 2018 21:19:52 +0100 Received: from xerus29 (unknown [192.168.200.18]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by monza.eurecom.fr (Postfix) with ESMTPSA id 2D7AD188; Sun, 18 Mar 2018 21:19:52 +0100 (CET) From: =?iso-8859-1?B?Suly9G1lIEjkcnJp?= To: "'Kevin Smith'" , , "'Alexandre Petrescu'" Cc: "'Tijink Jasja'" , References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <5cc6bd32-0812-288a-2db0-b0de53626f1e@gmail.com> <00c501d3bee0$26270700$72751500$@cox.net> In-Reply-To: <00c501d3bee0$26270700$72751500$@cox.net> Date: Sun, 18 Mar 2018 21:19:51 +0100 Organization: EURECOM Message-ID: <000701d3bef6$78eb86d0$6ac29470$@eurecom.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01D3BEFE.DAB71AC0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGhOrR8o8b5YryKQCC/S9k90bJ5fwGaWEJkAVayqmAC0zYUGgHJZZEvAaEIiFAAcwBKmQG/5PRJAkgknA2jzh85AA== Content-Language: en-us Archived-At: Subject: Re: [ipwave] =?iso-8859-1?q?=5Bipwave=EE=5D_IPv6-over-OCB_as_a_profi?= =?iso-8859-1?q?le_of_1609_WAVE?= X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 18 Mar 2018 20:19:58 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0008_01D3BEFE.DAB71AC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Kevin, =20 I never mentioned that IPv6 was encapsulated by WSM, it clearly does not=85only the ETSI does that.=20 =20 However, the IEEE 1609.3, section 5.1 and 6.4.3 shows that IPv6 requires = WME for configuring its IP flow, and that the dynamic addressing is done = from receiving a WSA. This is what I meant by IPv6 relying on WSMP (here a = WSA). So, indeed two different protocols, but interlinked.=20 =20 I agree with Dick and others that providing a way to do enhanced IPv6 in dynamic environment is the major task of this group=85there will be some interesting presentation on this tomorrow.=20 =20 Now, I am still skeptical to make an =91restrictive=92 mention of the ID = to be a profile to IEEE 1609.3, as it would be correct in the US, but it would = give the impression that the ID would not apply to EU.=20 =20 If the group opts to keep this sentence, then maybe we should add = something like: =93In Regions operating IEEE 1609.x set of standards, this = document is a profile based on=85=94=20 =20 BR, =20 J=E9r=F4me =20 From: Kevin Smith [mailto:kevin.s.smith@cox.net]=20 Sent: Sunday 18 March 2018 18:40 To: dickroy@alum.mit.edu; 'Jerome Haerri'; 'Alexandre Petrescu' Cc: 'Tijink Jasja'; its@ietf.org Subject: RE: [ipwave] [ipwave=EE] IPv6-over-OCB as a profile of 1609 = WAVE =20 Hello Jerome and all, =20 As Dick points out, IPv6 does not in any way rely on WSMP.=20 =20 IPv6 packets are NOT encapsulated by WSM. WSMP and IPv6 are two = completely separate protocols. =20 Best, Kevin =20 From: Dick Roy [mailto:dickroy@alum.mit.edu]=20 Sent: Sunday, March 18, 2018 9:44 AM To: 'Jerome Haerri' ; 'Alexandre Petrescu' Cc: 'Tijink Jasja' ; 'Kevin Smith' ; its@ietf.org Subject: RE: [ipwave] [ipwave=EE] IPv6-over-OCB as a profile of 1609 = WAVE =20 =20 =20 -----Original Message----- From: its [mailto:its-bounces@ietf.org] On Behalf Of Jerome Haerri Sent: Sunday, March 18, 2018 5:24 PM To: Alexandre Petrescu Cc: Tijink Jasja; Kevin Smith; its@ietf.org Subject: Re: [ipwave] [ipwave=EE] IPv6-over-OCB as a profile of 1609 = WAVE =20 Dear All, =20 I disagree for two reasons:=20 First this is not a profile, but an alternative operation of IP without relying on WSM. =20 [RR] WSMP is a networking (and transport) protocol just like IP. The = above statement makes no sense in that respect. One network layer protocol = never "relies on another". That said, if IPv6-over-OCB is a profile of some = other set of standards, then you are wasting your time. What is needed are modifications to IPv6 to handle rapidly varying network topologies. = Where have you heard that before?? ^))) We don't need or want the IETF to = specify how lower layers MUST behave when sending IP packets. Naturally if = there are recommendations for lower layer performance that will make the IP functions perform better, make those recommendations. Just NO SHALLs or MUSTs on any lower layer protocols please! Stick to IPv6 funtionality. =20 Second, this document will also apply outside of the US, and then IEEE 1609.3 does not apply and thus would make this document confusing. =20 [RR] Not so. IEEE 1609 is an international set of standards, and in particular, IEEE 1609.3 is over the air interoperable with ISO 29281-2 = FNTP and therefore can operate anywhere FNTP operates around the world.=20 =20 =20 Best Regards, =20 J=E9r=F4me =20 Envoy=E9 de mon iPhone =20 > Le 18 mars 2018 =E0 16:15, Alexandre Petrescu = a =E9crit : >=20 > Hi IPWAVErs, >=20 > Do you disagree we add this phrase in the Introduction: >=20 >> This document is a profile based on IEEE 1609.3: it introduces = additional requirements and specifications that do not violate that base standard. >=20 > For my part I find addition of this text neutral and ok, although I am > not sure what is a profile for 1609 WAVE. In Bluetooth, a 'profile' = is > something very much precise, like 'LAN profile', etc. >=20 > Alex >=20 >=20 >> Le 17/03/2018 =E0 13:22, Tijink Jasja a =E9crit : >> Hello Alex, >> Can we put something at the beginning of draft-ietf-ipwave-ipv6-over-80211ocb-21, maybe in the introduction? >> I suggest some language like the following: >> This document is a profile based on IEEE 1609.3: it introduces = additional requirements and specifications that do not violate that base standard. >> Regards Jasja >> -----Urspr=FCngliche Nachricht----- Von: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] Gesendet: Samstag, 17. M=E4rz 2018 = 12:23 An: Tijink Jasja Cc: Kevin >> Smith ; its@ietf.org Betreff: Re: [ipwave] >> ipwave - comments and concerns - 1609 WAVE, EPD - towards resolution >> Hello Jasja, >>> Le 16/03/2018 =E0 19:02, Tijink Jasja a =E9crit : >>> Hello Alex, >>> in addition to Kevin's points, I would like to mention that: >>> 1. I welcome your proposal for the additional text that specifies = QoS. This is necessary for operation in Europe (the specification for the = access layer can be found in ETSI EN 302 663, where clause 4.6 says that QoS = shall be used). >> Noted. >>> 2. My understanding of the discussion below is that draft-ietf-ipwave-ipv6-over-80211ocb-21 is "based on" IEEE 1609.3 in = that it is compliant with it (I didn't find any "violation of IEEE 1609.3), and = adds additional restrictions and /or specifications (such a MTU size, AC_BK, RFC8064, etc.). In that sense draft-ietf-ipwave-ipv6-over-80211ocb-21 is = a profile of IEEE 1609.3. I would suggest making that very clear, with a = short sentence/paragraph in draft-ietf-ipwave-ipv6-over-80211ocb-21 that >>> explains it to the reader. If you disagree, I would like to hear = your view on the relation of IEEE 1609.3 and draft-ietf-ipwave-ipv6-over-80211ocb-21. >> I dont really disagree, just where to put it. >> The draft does refer to 1609.3, in Appendix C "aspects introduced by = OCB to 802.11". The vehicular networking draft (draft-ietf-ipwave-vehicular-networking-01) also refers to it right at = the beginning. >> IPv6-over-OCB sounds like an explanation. As such, I suggest we = first write more precisely that "IPv6-over-OCB is a profile of 1609.3" and = then put it into the vehicular networking draft. >> How could that be written? >> Alex >=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 ------=_NextPart_000_0008_01D3BEFE.DAB71AC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear Kevin,

 

I never mentioned that IPv6 was encapsulated by WSM, it clearly does = not…only the ETSI does that.

 

However, the IEEE 1609.3, section 5.1 and 6.4.3 shows that IPv6 = requires WME for configuring its IP flow, and that the dynamic = addressing is done from receiving a WSA. This is what I meant by IPv6 = relying on WSMP (here a WSA). So, indeed two different protocols, but = interlinked.

 

I agree with Dick and others that providing a way to do enhanced IPv6 = in dynamic environment is the major task of this group…there will = be some interesting presentation on this tomorrow. =

 

Now, I am still skeptical to make an ‘restrictive’ = mention of the ID to be a profile to IEEE 1609.3, as it would be correct = in the US, but it would give the impression that the ID would not apply = to EU.

 

If the group opts to keep this sentence, then maybe we should add = something like: “In Regions operating IEEE 1609.x set of = standards, this document is a profile based on…” =

 

BR,

 

J=E9r=F4me

 

From:= = Kevin Smith [mailto:kevin.s.smith@cox.net]
Sent: Sunday 18 = March 2018 18:40
To: dickroy@alum.mit.edu; 'Jerome Haerri'; = 'Alexandre Petrescu'
Cc: 'Tijink Jasja'; = its@ietf.org
Subject: RE: [ipwave] [ipwave=EE] IPv6-over-OCB = as a profile of 1609 WAVE

 

Hello Jerome and all,

 

As Dick points out, IPv6 does not in any way rely on WSMP. =

 

IPv6 packets are NOT encapsulated by WSM. WSMP and IPv6 are two = completely separate protocols.

 

Best,

Kevin

 

From: Dick Roy = [mailto:dickroy@alum.mit.edu] =
Sent: Sunday, March 18, 2018 9:44 AM
To: 'Jerome = Haerri' <jerome.haerri@eurecom.fr>= ; 'Alexandre Petrescu' <alexandre.petrescu@gmail.com= >
Cc: 'Tijink Jasja' <Jasja.Tijink@kapsch.net>; = 'Kevin Smith' <kevin.s.smith@cox.net>; its@ietf.org
Subject: RE: = [ipwave] [ipwave=EE] IPv6-over-OCB as a profile of 1609 = WAVE

 

 

 

-----Original Message-----
From: its [mailto:its-bounces@ietf.org] On = Behalf Of Jerome Haerri
Sent: Sunday, March 18, 2018 5:24 PM
To: = Alexandre Petrescu
Cc: Tijink Jasja; Kevin Smith; its@ietf.org
Subject: Re: [ipwave] = [ipwave=EE] IPv6-over-OCB as a profile of 1609 WAVE

 

Dear = All,

 

I disagree for two reasons:

First this is not a profile, but an alternative = operation of IP without relying on WSM.

 

[RR] WSMP is a networking (and transport) protocol = just like IP.  The above statement makes no sense in that respect. = One network layer protocol never "relies on another".  = That said, if IPv6-over-OCB is a profile of some other set of standards, = then you are wasting your time.  What is needed are modifications = to IPv6 to handle rapidly varying network topologies.  Where have = you heard that before?? ^)))  We don't need or want the IETF to = specify how lower layers MUST behave when sending IP packets. =  Naturally if there are recommendations for lower layer performance = that will make the IP functions perform better, make those = recommendations.  Just NO SHALLs or MUSTs on any lower layer = protocols please! Stick to IPv6 funtionality.

 

Second, this document will also apply outside of = the US, and then IEEE 1609.3 does not apply and thus would make this = document confusing.

 

[RR] Not so.  IEEE 1609 is an international = set of standards, and in particular, IEEE 1609.3 is over the air = interoperable with ISO 29281-2 FNTP and therefore can operate anywhere = FNTP operates around the world.

 

 

Best = Regards,

 

J=E9r=F4me

 

Envoy=E9 de mon iPhone

 

> = Le 18 mars 2018 =E0 16:15, Alexandre Petrescu <alexandre.petrescu@gmail.com= > a =E9crit :

> =

> Hi = IPWAVErs,

>

> Do you disagree we add this phrase in the = Introduction:

> =

>> This document is a = profile based on IEEE 1609.3: it introduces additional requirements and = specifications that do not violate that base standard.

>

> = For my part I find addition of this text neutral and ok, although I = am

> not sure what is a profile = for 1609 WAVE.  In Bluetooth, a 'profile' is

> something very much precise, like 'LAN = profile', etc.

> =

> Alex

>

> =

>> Le 17/03/2018 =E0 13:22, = Tijink Jasja a =E9crit :

>> = Hello Alex,

>> Can we put = something at the beginning of draft-ietf-ipwave-ipv6-over-80211ocb-21, = maybe in the introduction?

>> I suggest some language like the = following:

>> This document = is a profile based on IEEE 1609.3: it introduces additional requirements = and specifications that do not violate that base = standard.

>> Regards = Jasja

>> = -----Urspr=FCngliche Nachricht----- Von: Alexandre Petrescu [mailto:alexandre.petrescu@gm= ail.com] Gesendet: Samstag, 17. M=E4rz 2018 12:23 An: Tijink Jasja = <Jasja.Tijink@kapsch.net> = Cc: Kevin

>> Smith <kevin.s.smith@cox.net>; its@ietf.org Betreff: Re: = [ipwave]

>> ipwave - = comments and concerns - 1609 WAVE, EPD - towards = resolution

>> Hello = Jasja,

>>> Le 16/03/2018 = =E0 19:02, Tijink Jasja a =E9crit :

>>> Hello Alex,

>>> in addition to Kevin's points, I  = would like to mention that:

>>> 1. I welcome your proposal for the = additional text that specifies QoS. This is necessary for operation in = Europe (the specification for the access layer can be found in ETSI EN = 302 663, where clause 4.6 says that QoS shall be used).

>> Noted.

>>> 2. My understanding of the discussion = below is that draft-ietf-ipwave-ipv6-over-80211ocb-21 is "based = on" IEEE 1609.3 in that it is compliant with it (I didn't find any = "violation of IEEE 1609.3), and adds additional restrictions and = /or specifications (such a MTU size, AC_BK, RFC8064, etc.). In that = sense draft-ietf-ipwave-ipv6-over-80211ocb-21 is a profile of IEEE = 1609.3. I would suggest making that very clear, with a short = sentence/paragraph in draft-ietf-ipwave-ipv6-over-80211ocb-21 = that

>>> explains it to = the reader. If you disagree, I would like to hear your view on the = relation of IEEE 1609.3 and = draft-ietf-ipwave-ipv6-over-80211ocb-21.

>> I dont really disagree, just where to put = it.

>> The draft does refer = to 1609.3, in Appendix C "aspects introduced by OCB to = 802.11".  The vehicular networking draft = (draft-ietf-ipwave-vehicular-networking-01) also refers to it right at = the beginning.

>> = IPv6-over-OCB sounds like an explanation.  As such, I suggest we = first write more precisely that "IPv6-over-OCB is a profile of = 1609.3" and then put it into the vehicular networking = draft.

>> How could that be = written?

>> = Alex

>

> = _______________________________________________

> its mailing list

> its@ietf.org

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

 

_______________________________________________=

its mailing list

its@ietf.org

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

------=_NextPart_000_0008_01D3BEFE.DAB71AC0-- From nobody Sun Mar 18 14: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 75C3912AF84 for ; Sun, 18 Mar 2018 14:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 74is0Fz1SPhd for ; Sun, 18 Mar 2018 14:02:42 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C616120727 for ; Sun, 18 Mar 2018 14:02:42 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id n3so11995234wmd.1 for ; Sun, 18 Mar 2018 14:02:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=1AVHgNvTL9r+pdIIn0RGjrS68YFvhDTFm6kKoyvJ4Jw=; b=W0NAzDX5SWpXPeMc7WWKJMqcBtS4gv/HN6ZI2blMi5x9CJZ7ujPf9Q9X3ekHv03K2N M3tBmKJMX5hEiuZZZMQZSjgCgOdAdRuXji8n8MIAVG3E9WPElHdot3ng0yCu207LE1UF uOX1zBiIcWSjNN5fXvM3XbMujqDB/VaSBKVTA5i9hs8+LtqkX6hLmugc6pdnMITekrpB Tc0SJXtUmecnlwSxa9VZeJUqEf+eXYeuVboptScNDZJrHqfGoKsb+FS5X1YS3+do51iL 6iLRXzL4hn8y/AzwbAYAU1vG4dbfRJqdscw9DZVJflCtoLslTBj0N6xXi9gxeFtKJRjh Dciw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=1AVHgNvTL9r+pdIIn0RGjrS68YFvhDTFm6kKoyvJ4Jw=; b=b08cTH0YWJ3qdOr7aUSVUMYf40Y7jrpi+q6FSE/V/TWJPtTR7gY8AHfx7LgD8NvDCo ZUHUtpGG763oCXogaE4wBoiURUaa+kSC264XsKzggzhermv03CH+V5DmsvmZLotKfaKW wXFQLWx5w67p5xWHV6qA2xiwpsGwNdvo46oYclbYHHrYN6JTSRffxM23GZQXRZgp66Vk SxrBKRZzHIPl0FGMQQIJO1Rblt3DVMWzZcRIFB3Pq4wsKZEjCqW8Fj/a+nyzSPF6PWYA OMD47YV6kmjhAZl10iULp2M9ZaxV0/P+TWIYYNfHPEzuwPFGMvN3gb5TgoIOOvoJD+Pd st4A== X-Gm-Message-State: AElRT7G0V9sP9QgrAfb98GUUcT7FfKRGBnyOW+VZijNUEwjLPsozuJa6 rMiWJ+T1bIawueVybxe7qiSPgxPl X-Google-Smtp-Source: AG47ELuEGLtoH6+PLuX4siLOA3OsJJBCX7M4qJzCXkAj3GnzT5Nd6/XcSFwsSyglzXgIVlxFUHatbw== X-Received: by 10.28.58.144 with SMTP id h138mr6551657wma.42.1521406960658; Sun, 18 Mar 2018 14:02:40 -0700 (PDT) Received: from ?IPv6:2001:67c:1232:144:656a:289f:5f44:8b2a? ([2001:67c:1232:144:656a:289f:5f44:8b2a]) by smtp.gmail.com with ESMTPSA id 140sm18475050wmi.34.2018.03.18.14.02.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Mar 2018 14:02:39 -0700 (PDT) Sender: Tony Li From: tony.li@tony.li Message-Id: <5B58DDC2-6D29-4F47-8E78-8D4C242E560C@tony.li> Content-Type: multipart/alternative; boundary="Apple-Mail=_520FE60C-2A11-45F2-AF6E-1659DB557121" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Sun, 18 Mar 2018 21:02:38 +0000 In-Reply-To: Cc: Alexandre Petrescu , Tijink Jasja , Kevin Smith , "its@ietf.org" To: Nabil Benamar References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <003b01d3be25$c5239ff0$4f6adfd0$@cox.net> <00c301d3bedf$64fca620$2ef5f260$@cox.net> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [ipwave] IP or IPv6 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 18 Mar 2018 21:02:44 -0000 --Apple-Mail=_520FE60C-2A11-45F2-AF6E-1659DB557121 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yes, we agreed in the charter that we are standardizing on IPv6 only and = that IPv4 is out of scope. I=E2=80=99ll also remind folks that there is another draft that already = documents IPv4 over OCB. Tony > On Mar 18, 2018, at 5:59 PM, Nabil Benamar > wrote: >=20 > Hi All, >=20 > Let me remind you that we have already had this discussion and we = agreed that this document is for IPv6 ONLY. >=20 >=20 >=20 > Best regards > Nabil Benamar > ------------------- > =D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88 >=20 >=20 >=20 >=20 >=20 >=20 > On Sun, Mar 18, 2018 at 5:42 PM, Alexandre Petrescu = > = wrote: >=20 >=20 > Le 18/03/2018 =C3=A0 18:34, Kevin Smith a =C3=A9crit : > Alex, >=20 > As the title of the document is " Transmission of *IPv6* Packets > over ...", >=20 > Maybe we should change the title to just say "IP". >=20 > it seems to me that the scope is restricted to IPv6. >=20 > Yes. >=20 > Also note that IPv6 (along with WSMP) are the only L3 protocols > allowed by 1609 WAVE, i.e., IPv4 is not allowed. >=20 > In a world where IPv4 is not allowed, not specified, etc., IP can only = mean IPv6. >=20 > Alex >=20 >=20 >=20 > Best, Kevin >=20 > -----Original Message----- From: its [mailto:its-bounces@ietf.org = ] > On Behalf Of Alexandre Petrescu Sent: Sunday, March 18, 2018 10:25 AM > To: Kevin Smith >; 'Tijink Jasja' = > Cc: = its@ietf..org Subject: Re: [ipwave] IP or IPv6 >=20 >=20 >=20 > Le 17/03/2018 =C3=A0 20:25, Kevin Smith a =C3=A9crit : [...] >=20 > Note also I changed "IP" to "IPv6". >=20 > At the risk of being called provokative: can one think there is = another version of IP that deserves being described? If not, the > only version that can be understood when reading "IP" is "IPv6". >=20 > I do not see why being explicit and say v6, when IP is sufficient > and shorter. >=20 > Alex [...] >=20 > _______________________________________________ its mailing list = its@ietf.org = https://www.ietf.org/mailman/listinfo/its = >=20 >=20 >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its = >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its --Apple-Mail=_520FE60C-2A11-45F2-AF6E-1659DB557121 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Yes, we agreed in the charter that we are standardizing = on IPv6 only and that IPv4 is out of scope.

I=E2=80=99ll also remind folks that = there is another draft that already documents IPv4 over OCB.

Tony


On Mar = 18, 2018, at 5:59 PM, Nabil Benamar <benamar73@gmail.com>= wrote:

Hi = All,
Let= me remind you that we have already had this discussion and we agreed = that this document is for IPv6 ONLY.



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 Sun, Mar 18, 2018 at 5:42 = PM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:


Le 18/03/2018 =C3=A0 18:34, Kevin Smith a =C3=A9crit :
Alex,

As the title of the document is " Transmission of *IPv6* Packets
over ...",

 Maybe we should change the title to just say "IP".

it seems to me that the scope is restricted to IPv6.

 Yes.

Also note that IPv6 (along with WSMP) are the only L3 protocols
allowed by 1609 WAVE, i.e., IPv4 is not allowed.

 In a world where IPv4 is not allowed, not specified, etc., IP can only = mean IPv6.

Alex



Best, Kevin

-----Original Message----- From: its [mailto:its-bounces@ietf.org]
On Behalf Of Alexandre Petrescu Sent: Sunday, March 18, 2018 10:25 AM
 To: Kevin Smith <kevin.s.smith@cox.net>; 'Tijink = Jasja' <Jasja.Tijink@kapsch..net> Cc: its@ietf..org Subject: Re: [ipwave] IP or IPv6



Le 17/03/2018 =C3=A0 20:25, Kevin Smith a =C3=A9crit : [...]

Note also I changed "IP" to "IPv6".

At the risk of being called provokative: can one think there is another = version of IP that deserves being described? If not, the
only version that can be understood when reading "IP" is "IPv6".

I do not see why being explicit and say v6, when IP is sufficient
and shorter.

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

= --Apple-Mail=_520FE60C-2A11-45F2-AF6E-1659DB557121-- From nobody Sun Mar 18 14:11: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 89F34120727 for ; Sun, 18 Mar 2018 14:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 AuVEnPr72mvV for ; Sun, 18 Mar 2018 14:11:18 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c: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 AC55E12D775 for ; Sun, 18 Mar 2018 14:11:17 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id l16so2573555wmh.3 for ; Sun, 18 Mar 2018 14:11:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=WdAbNU1wdz7+fQw71kCjrgT6tgG5OdAc6kinUll7StA=; b=GptTWrrZGhy7S7VEzv85vD6XW3TstpXF+Yvq7xDoaUc094Tm/APAhn5IB0jOFi8tXH dBV9Gg1ejsfFYC3fWYYdLnLMSPzUpYdAmZ7Gx0xtX1CeJPGTXed85DecU8yDfONGeTKJ rl1vvhQMKKQX4/H/QakLyXoC6ZcnRizX39neV2cJNaNLM/LTkbtxs5NgcaMQ2M6wW6Yh XTaLvpoeM40xpklyTMSuDk9jzi23kGAxlwuJOtaP25LeL0IJwrNJshYEFGYyJgJRyV1y D57F66jyy9Cg/XofUPLuZF5EOaY/jovU8TsrimMzmt2iW1GpDamCoSPkKxJ2cMoRcvEO zopg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=WdAbNU1wdz7+fQw71kCjrgT6tgG5OdAc6kinUll7StA=; b=ZH5UDgGwGinOmiNOfdaifPYeslDJzhH34X2BGwn0J4Hg7hW/dNujthIynP9vOdUwRs 0BI5aWmyE8pSuUwPc/uU9fQSCrBiKvIDrHNGiehsL2cBqNsY/Tcy4NVyE3W6NwfHs3rp VyyDpS9vtVh5DIRXnUFXKaaqI6f9JoDIQWVemiA5tN0Czjpk+P7kt10TLl2ZzS825Aga 06J8ae3VzEmRL11xlMhmqKZGzdufru2HhzzZnfZtpMXzCmCsn/thKDSqJllocILTPD88 VGB0BHBijoQ0R58vvnVe/iKKDhOk/58wMK0/x1/rUxZqpVqGsCs55aB5Y6h0KnHgF0QL kSig== X-Gm-Message-State: AElRT7FyOoAO/xJZKs+E/6wRMk4scFVUdqmVrakdvATtXTkCr1QagN+f DDG1LjPxaV6fWDyRDTq0yvE= X-Google-Smtp-Source: AG47ELuAj3qHJteLV7ZJV3xPYo0Nm3iLDHuFXAG+PhvHvtrHt5MEsPJSURaXmJTVrhDgD1cOk5/PbA== X-Received: by 10.28.66.90 with SMTP id p87mr1452436wma.58.1521407476272; Sun, 18 Mar 2018 14:11:16 -0700 (PDT) Received: from ?IPv6:2001:67c:1232:144:656a:289f:5f44:8b2a? ([2001:67c:1232:144:656a:289f:5f44:8b2a]) by smtp.gmail.com with ESMTPSA id l11sm10905736wrg.71.2018.03.18.14.11.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Mar 2018 14:11:15 -0700 (PDT) Sender: Tony Li From: tony.li@tony.li Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_537CEBCC-5131-4910-923A-ED1090C4E7D3" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Sun, 18 Mar 2018 21:11:14 +0000 In-Reply-To: <5B6EDDCFBD8B46D6AA91912E4187FFCF@SRA6> Cc: Tijink Jasja , Kevin Smith , Alexandre Petrescu , Jerome Haerri , its@ietf.org To: dickroy@alum.mit.edu References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <5cc6bd32-0812-288a-2db0-b0de53626f1e@gmail.com> <5B6EDDCFBD8B46D6AA91912E4187FFCF@SRA6> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [ipwave] =?utf-8?q?=5Bipwave=C3=AE=5D_IPv6-over-OCB_as_a_profile?= =?utf-8?q?_of_1609_WAVE?= X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 18 Mar 2018 21:11:19 -0000 --Apple-Mail=_537CEBCC-5131-4910-923A-ED1090C4E7D3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 18, 2018, at 5:47 PM, Dick Roy wrote: >=20 > RR] That may be where the situation has degraded to, however that was = never the original intent. The original intent, the reason the BoF was = created in the first place, was because ISO people went to the IETF = (Thierry and a few others) to see if they would look into modifications = to the IPv6 protocols so that it could function in rapidly varying = network topologies (aka vehicular environments). We were not asking for = the IETF to specify what implementations at the lower layers should do, = ONLY what network layer functionalities needed to be implemented. Any = and ALL talk of what lower layers would be required to do was originally = way out of scope. Any requirements the IETF makes on lower layer will = w.p.1 fall on deaf ears =E2=80=A6 aka are a waste of time and effort. Interesting. There has been little discussion of situations that are not handled = adequately today. My experience suggests that no modifications are necessary at the = network layer. Specifying which aspects of the lower layers to use have always been the = key point of the charter: "This group's primary deliverable (and the only Standards track item) will be a document that will specify the mechanisms for transmission of IPv6 datagrams over IEEE 802.11-OCB mode.=E2=80=9D Tony --Apple-Mail=_537CEBCC-5131-4910-923A-ED1090C4E7D3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Mar 18, 2018, at 5:47 PM, Dick Roy <dickroy@alum.mit.edu> wrote:

RR] That may be where the = situation has degraded to, however that was never the original = intent.  The original intent, the reason the BoF was created in the = first place, was because ISO people went to the IETF (Thierry and a few = others) to see if they would look into modifications to the IPv6 = protocols so that it could function in rapidly varying network = topologies (aka vehicular environments).  We were not asking for = the IETF to specify what implementations at the lower layers should do, = ONLY what network layer functionalities needed to be implemented. =  Any and ALL talk of what lower layers would be required to do was = originally way out of scope.  Any requirements the IETF makes on = lower layer will w.p.1 fall on deaf ears =E2=80=A6 aka are a waste of = time and effort.


Interesting.

There has been little discussion of situations that are not = handled adequately today.

My experience suggests that no modifications are necessary at = the network layer.

Specifying which aspects of the lower layers to use have = always been the key point of the charter:

"This group's primary deliverable (and = the only Standards track
item) will be a document that will specify the mechanisms = for
transmission of IPv6 datagrams over IEEE = 802.11-OCB mode.=E2=80=9D

Tony

= --Apple-Mail=_537CEBCC-5131-4910-923A-ED1090C4E7D3-- From nobody Sun Mar 18 14:18: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 35FC2120727 for ; Sun, 18 Mar 2018 14:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 7HDfOVO_Ez2f for ; Sun, 18 Mar 2018 14:18:45 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c: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 3DF7E12D778 for ; Sun, 18 Mar 2018 14:18:45 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id 139so12027218wmn.2 for ; Sun, 18 Mar 2018 14:18:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OUkioSDfnUhE8ZhK9kTFDTrWvMEK/m0y97N1Tg6REqc=; b=ZVhvmojpzJF8LU8mU62clf0lvho16Sk9+yWg2dI5hCZ9gS+ESWy8Z2nXJAWbmiZIBC UbvK8nrDCN9mHhMT/kToVRTMvJ/VcDjcz+6M2KIElMOFZ0rsj0aYnb4S9SC23pqapxzD qPe4vKYXAuQy/y5IVTKo2gassFeeL5XBWDmbvobpACHrfWCBkXrpC4q6bp+UrUjR9sSh Ny0Z8U8t/EVMMkGPejOE42WclcObiR/7mAzvD2k92RwibmT36s37s3fafq6yhoFhBzjb 2LuAd3DNvdZySMkJ3vObPlhmMve7LyKR2fTg7UMCEv71BRMuVrROxiAdpyGjmxuJueiO 9bEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=OUkioSDfnUhE8ZhK9kTFDTrWvMEK/m0y97N1Tg6REqc=; b=b+DhAOBxkmjSv0CHP8iCPjBQGSoXrxNTYBaoos50c0kGukLWHn6jyEjeKZXBqAphRB 9sokkBcdqg3ajXU4LrkuKo7P3njX/RAFC/qTXpoBk7t6nFPHXMnzouQ92MjPY74XQ3UI DJbpnXgWXpGGAzqyqjwRlAEP1Ydge75gzPx8nR0niXYR6cgscdP465/eeN4MPR/VKBUW kXiSyjXWkI5QunqldM8p4kIRm935ew7jsd4y0TeNLUw2ABhw8zEZgLVkuHVQsslhpUx/ is9hk/0od2np0NPHE78RYS/SQ6vEEewQHPumCs6A7VNY+v9ur5q0XKMXrB4Z2uHpNPxA jVQA== X-Gm-Message-State: AElRT7EAv2a10dJVD0AwRs4tsiCmx8feTkwwQpzLR4oxPMVwVcyd8muH XxO3R9ckNCDrd7kDCqbhFbg= X-Google-Smtp-Source: AG47ELvU5yhmht3/rlseeGpOJFTjKgfxIcHN+LAb8fZ7bgic8Tk05qmJXxPQ4x8cMS4sDIldqFVgfA== X-Received: by 10.28.71.204 with SMTP id m73mr6515957wmi.111.1521407923797; Sun, 18 Mar 2018 14:18:43 -0700 (PDT) Received: from ?IPv6:2001:67c:1232:144:656a:289f:5f44:8b2a? ([2001:67c:1232:144:656a:289f:5f44:8b2a]) by smtp.gmail.com with ESMTPSA id c192sm11928319wma.12.2018.03.18.14.18.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Mar 2018 14:18:43 -0700 (PDT) Sender: Tony Li 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: <23f068f5-36ff-ced3-495b-f888549981bc@gmail.com> Date: Sun, 18 Mar 2018 21:18:42 +0000 Cc: Tijink Jasja , Kevin Smith , "its@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <0738710F-EC0E-43C4-995D-6AFB10C656AF@tony.li> References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <23f068f5-36ff-ced3-495b-f888549981bc@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [ipwave] clarification of EAL text X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 18 Mar 2018 21:18:47 -0000 I continue to object to this text. Again, we should only be standardizing (normative text) on the bits as = they appear on the air. The interface between the driver and the operating system is an API that = is wholly out of scope for our charter. I can accept including some informative text in this regard, but it = should not be normative. I=E2=80=99d like to propose alternate text: IP packets MUST be transmitted over 802.11-OCB media as QoS Data frames whose format is specified in IEEE Std 802.11. To simplify the API between the operating system and the = 802.11-OCB media, device drivers MAY implement an Ethernet Adaptation = Layer that translates Ethernet II frames to the 802.11 format and vice = versa. Tony > On Mar 18, 2018, at 5:26 PM, Alexandre Petrescu = wrote: >=20 > I suggest this clarification of the EAL text. >=20 > OLD: >> IP packets are transmitted over 802.11-OCB as standard Ethernet = packets. As with all 802.11 frames, an Ethernet adaptation layer MUST = be used with 802.11-OCB as well." >=20 > NEW: >> Within an IP-RSU, or within an IP-OBU, the IP packets are = communicated >> by the IP stack to and from the 802.11-OCB driver as standard = Ethernet >> II frames. IP packets MUST be transmitted over 802.11-OCB media as >> QoS Data frames whose format is specified in IEEE Std 802.11. >> Before sending the IP packets on the 802.11 media, and after = receiving >> packets from the 802.11 media, the use of an adaptation layer that >> adapts between the frame formats of 802.11 and of Ethernet II is >> RECOMMENDED. The Ethernet II headers MUST NOT be transmitted on >> 802.11 media. >=20 > Alex >=20 >=20 > Le 17/03/2018 =C3=A0 13:50, Tony Li a =C3=A9crit : >>> on the EAL topic. Take again the following text from the draft: >>> " IP packets are transmitted over 802.11-OCB as standard Ethernet = packets. As with all 802.11 frames, an Ethernet adaptation layer MUST = be used with 802.11-OCB as well." >>> I understand the second sentence is a requirement you put to = implementations that feature an ethernet interface and an 802.11 = interface. >> I suspect that we=E2=80=99ll also get some push back on this sentence >> because it is implied to be normative. Since the EAL doesn=E2=80=99t >> actually affect the bits on the air, this is simply an implementation >> choice and not strictly mandatory. >> It would probably be easier if we relaxed the wording to make this = informative or recommended instead. >> Tony From nobody Sun Mar 18 14:55: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 CDA08124217 for ; Sun, 18 Mar 2018 14:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 Z9F1wKMrlizD for ; Sun, 18 Mar 2018 14:55:12 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D143E1205F0 for ; Sun, 18 Mar 2018 14:55:11 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id n3so12117882wmd.1 for ; Sun, 18 Mar 2018 14:55:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=00xdyM9+x+ERuv/jk8/718twbapFuAxhlCm1nrM58zY=; b=W5I5J++vEgOyogM74EMGmhN5NuH1CasVZ+IVfFba6FfPK7uxdp/ygqfwV5hh3Fs6c1 53afrAgJk8cOOeeZDsdN0Gn9Y2p083GOHDdkbhScOjkbTKkm4QPLM+gyp1zYlJqftHV2 SBpm1wnSiFNv3vrv769XSQ7BnZ991P9fzAf0fm+QvOKJGb06WQiqtOC26dHb5A8vd6YD 7yQmWH+pUe3nWe8ptLh0smF1Nk3oTEByFgiVSXGIwn1NxtAMoK92Buj9ZI7OvwZWK1lY iHtJUFZ3gFx1IB9VqOsi8FoqVUTXYQ7JUxQ+AYSg8qOcQtfgfcJW954D/uKd8525hUrg Qv3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=00xdyM9+x+ERuv/jk8/718twbapFuAxhlCm1nrM58zY=; b=X2dv7Dnyn9rn2wl50oCQ5Z7YngGM5U82/bfvy77Tj6VUj2FklefLZQLvDeEx/39JoZ Y7myD+vYu0h87RAeN/NPIlFpr8dexju1ZmjXscdPWG+PYQ8umgm3/XCBk3mb3Fsq5BJ4 PiFGKY0/ea+0FrAk8yVHu4f7rVYM8uzDwrMUmbEtf+TNZ47DVIFlashJdufJrTHY+TI3 Ja6/I+kX+nWSduS4WwAsIC9rsCVh0tIYGcWGEj+gUowqJ+9cymDQp8BvdZ0MhTJmmjCV imi52vUVzYcffoYGdE0XVhzh7ARXLoEQvf7pjOWkyB5u5P7MVlki1lfGbICKHtHynyr7 o4XQ== X-Gm-Message-State: AElRT7HWx94t/L6/4sCjCeFyyuqjkq7ikhOOF31Oy45gAgfUPtdElGG5 tRsBEbFLyJ7LeNaNtYNJkNE= X-Google-Smtp-Source: AG47ELuEkSDtRMfQgSGF8NG88nQqeQEJXoONiF6u88IvprvyakL7QP/m5cKsh5IVxrUK3kNlnqNNEQ== X-Received: by 10.28.5.145 with SMTP id 139mr6543803wmf.31.1521410110415; Sun, 18 Mar 2018 14:55:10 -0700 (PDT) Received: from ?IPv6:2001:67c:1232:144:656a:289f:5f44:8b2a? ([2001:67c:1232:144:656a:289f:5f44:8b2a]) by smtp.gmail.com with ESMTPSA id 190sm12037240wmu.35.2018.03.18.14.55.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Mar 2018 14:55:09 -0700 (PDT) Sender: Tony Li From: tony.li@tony.li Message-Id: <2E6AB388-032A-4D0A-9B11-21B715E2E91D@tony.li> Content-Type: multipart/alternative; boundary="Apple-Mail=_B89312D6-76FC-4C52-B39A-D8776C32BBD3" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Sun, 18 Mar 2018 21:55:08 +0000 In-Reply-To: <51846972669440819C0B5F05AFC89A6A@SRA6> Cc: Alexandre Petrescu , Tijink Jasja , Kevin Smith , its@ietf.org To: dickroy@alum.mit.edu References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <23f068f5-36ff-ced3-495b-f888549981bc@gmail.com> <0738710F-EC0E-43C4-995D-6AFB10C656AF@tony.li> <51846972669440819C0B5F05AFC89A6A@SRA6> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [ipwave] clarification of EAL text X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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, 18 Mar 2018 21:55:14 -0000 --Apple-Mail=_B89312D6-76FC-4C52-B39A-D8776C32BBD3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > IP packets MUST be transmitted over 802.11-OCB media as > QoS Data frames whose format is specified in IEEE Std 802.11. > [RR] This text should be removed in its entirety. There is absolutely = no valid technical reason for making such a requirement, AND it is out = of scope for the IETF to do so. If I want to send an IPv6 packet over = 802.11 in OCB mode using Data fraes, I will and the IETF can not stop = me.=20 That=E2=80=99s true. You just won=E2=80=99t interoperate with the rest = of us. =20 > =20 > To simplify the API between the operating system and the = 802.11-OCB media, device drivers MAY implement an Ethernet Adaptation = Layer that translates Ethernet II frames to the 802.11 format and vice = versa. > [RR] APIs are Application Programming Interfaces that exist ABOVE the = communications stack, i.e. ABOVE the Application Layer! They have = absolutely nothing to do with implementing MAC SAPs. Once more, = functions/software that perform a translation between to MAC sublayer = protocols are 1) out of scope of the IETF for darn sure, and 2) are = layer-internal translation functions that reside in bridges, NOT an = adaptation layer of any kind.=20 > =20 > I would not use either of these sentences. They are both wrong on = many counts. Sorry you don=E2=80=99t like the wording, but =E2=80=98API' has been = applied to many interfaces, not just to applications. Whether it=E2=80=99s= bridging or adaptation layer is a matter of wordsmithing. The semantics = remains the same. Tony --Apple-Mail=_B89312D6-76FC-4C52-B39A-D8776C32BBD3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
    =   IP packets MUST = be transmitted over 802.11-OCB media as
      QoS Data frames whose = format is specified in IEEE Std 802.11.
[RR] This text should be removed in its = entirety. There is absolutely no valid technical reason for making such = a requirement, AND it is out of scope for the IETF to do so. If I want = to send an IPv6 packet over 802.11 in OCB mode using Data fraes, I will = and the IETF can not stop me. 


That=E2=80=99s true. =  You just won=E2=80=99t interoperate with the rest of us. =  


 
      To simplify the API between = the operating system and the 802.11-OCB media, device drivers MAY = implement an Ethernet Adaptation Layer that translates Ethernet II = frames to the 802.11 format and vice versa.
[RR] APIs are Application Programming = Interfaces that exist ABOVE the communications stack, i.e. ABOVE the = Application Layer!  They have absolutely nothing to do with = implementing MAC SAPs. Once more, functions/software that perform a = translation between to MAC sublayer protocols are 1) out of scope of the = IETF for darn sure, and 2) are layer-internal translation functions that = reside in bridges, NOT an adaptation layer of any kind. 
 
I would not use = either of these sentences.  They are both wrong on many counts.


Sorry you don=E2=80=99t = like the wording, but =E2=80=98API' has been applied to many interfaces, = not just to applications. Whether it=E2=80=99s bridging or adaptation = layer is a matter of wordsmithing. The semantics remains the = same.


Tony


= --Apple-Mail=_B89312D6-76FC-4C52-B39A-D8776C32BBD3-- From nobody Sun Mar 18 22:59: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 28037126CD8 for ; Sun, 18 Mar 2018 22:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.009 X-Spam-Level: X-Spam-Status: No, score=-3.009 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, RCVD_IN_MSPIKE_H5=-1, 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 (1024-bit key) header.d=kapsch.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Pp4ygdhY7VS for ; Sun, 18 Mar 2018 22:59:09 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0106.outbound.protection.outlook.com [104.47.2.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1F43124207 for ; Sun, 18 Mar 2018 22:59:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kapsch.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cMSbkw9grhouWR7XxGRD4npoxxOLPZrh2haN30YzlkA=; b=pAxOEKbu8oaL08CH0K6B/XX4/9OpTDqC7N1gVte1+KvDwTggOuOpFIim1lQXbnELNjNhRsu+VXa8XdRy2tVssexdsCdmyuntGGVsb18m6FCV2Aw6T6iO2TDTtlVWOm0Fi1ZxTgc2/8657OWq0NPscFJiXzbMjvUGs8Jr74WP5RQ= Received: from AM0PR0302MB3380.eurprd03.prod.outlook.com (52.133.37.155) by AM0PR0302MB3428.eurprd03.prod.outlook.com (52.133.38.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.588.14; Mon, 19 Mar 2018 05:59:05 +0000 Received: from AM0PR0302MB3380.eurprd03.prod.outlook.com ([fe80::153a:2232:e7b7:7cb4]) by AM0PR0302MB3380.eurprd03.prod.outlook.com ([fe80::153a:2232:e7b7:7cb4%13]) with mapi id 15.20.0588.017; Mon, 19 Mar 2018 05:59:05 +0000 From: Tijink Jasja To: =?iso-8859-1?B?Suly9G1lIEjkcnJp?= , 'Kevin Smith' , "dickroy@alum.mit.edu" , 'Alexandre Petrescu' CC: "its@ietf.org" Thread-Topic: =?iso-8859-1?Q?[ipwave]__[ipwave=EE]_IPv6-over-OCB_as_a_profile_of_1609_W?= =?iso-8859-1?Q?AVE?= Thread-Index: AQHTvtRe8X8cOrmeWk68f0ucuVBXmgGaWEJkAVayqmAC0zYUGgHJZZEvAaEIiFAAcwBKmQG/5PRJo+A87jD/myW2gIAAn5bQ Date: Mon, 19 Mar 2018 05:59:05 +0000 Message-ID: References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <5cc6bd32-0812-288a-2db0-b0de53626f1e@gmail.com> <00c501d3bee0$26270700$72751500$@cox.net> <000701d3bef6$78eb86d0$6ac29470$@eurecom.fr> In-Reply-To: <000701d3bef6$78eb86d0$6ac29470$@eurecom.fr> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jasja.Tijink@kapsch.net; x-originating-ip: [188.22.229.187] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM0PR0302MB3428; 7:4lXf6rQUbQK6Xcosa2ScbltP7P0hRGevkrFbXdPICvF8nR3ThmInNaW26lSgkRrGu3d7cdB2KXtHYmAtSj+aNqvu9/0Dz9EyKcv7O+BKLWK84MJN7TFr7BhZ4L/Z4HicjyQYfvGbiqghHmSpQ9exfvWj+QM2rHrYTkWY2A8X8GtLqy9qumqFrk86dx3cLMv6ie4KdbIYvqSNccnHDA31UF3kCs4HNvM69QoOpQ4Ogtx+5YtZsBvFDQlG44/QcSU5 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: b6fbe68d-ca29-4db6-7871-08d58d5e85d0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:AM0PR0302MB3428; x-ms-traffictypediagnostic: AM0PR0302MB3428: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(79046362386883)(85827821059158)(21748063052155)(240460790083961); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(3231221)(944501244)(52105095)(93006095)(93001095)(10201501046)(6041310)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:AM0PR0302MB3428; BCL:0; PCL:0; RULEID:; SRVR:AM0PR0302MB3428; x-forefront-prvs: 06167FAD59 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400004)(39380400002)(396003)(346002)(366004)(376002)(13464003)(199004)(189003)(6436002)(2501003)(55016002)(53936002)(86362001)(9686003)(2171002)(7736002)(105586002)(81156014)(106356001)(224303003)(8666007)(236005)(6306002)(316002)(14454004)(966005)(110136005)(74316002)(5660300001)(606006)(5250100002)(97736004)(81166006)(6506007)(59450400001)(33656002)(8936002)(4326008)(72206003)(76176011)(2950100002)(6116002)(561944003)(3660700001)(478600001)(3846002)(68736007)(25786009)(54896002)(790700001)(2900100001)(102836004)(93886005)(3280700002)(7696005)(186003)(99286004)(66066001)(39060400002)(2906002)(26005)(53546011)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR0302MB3428; H:AM0PR0302MB3380.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: kapsch.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: OUg5GqX1OVpr1ePQS/avOEo06rWp1arRXRuyWTPMIssfe3q/OpKI1AXFH3K54N+Un0pdehMa/Bkq4NbKfm74lFb7tG5qK7ZMwXmK1kLvtvDzxFFWmqAqUXhy3m2H2ppf/9A7czRvglOhlfg6ZF+2ED7tkvd9GUE6fY8bAEbI0H5emry5nAV5Km9E+uUFKV4IUTPkmtKjnhtwRKWOx1wMaWeF27hvHgNtNFRjHR+Qn36qwhYqbL7jvKED1dIdjbIvDJVmzJpreEnja/8AIriXw8+b1C8cmzQ7/InDG4PdWkjCqfJKb7u+54R6CksU3UDnVc6OBqQmfivx9TfH3f/lJQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM0PR0302MB3380F8833C7D835D3DBC1363EFD40AM0PR0302MB3380_" MIME-Version: 1.0 X-OriginatorOrg: kapsch.net X-MS-Exchange-CrossTenant-Network-Message-Id: b6fbe68d-ca29-4db6-7871-08d58d5e85d0 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Mar 2018 05:59:05.2548 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5f9ce527-7e3e-4e83-a8a4-b6c848f85ab5 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR0302MB3428 Archived-At: Subject: Re: [ipwave] =?iso-8859-1?q?=5Bipwave=EE=5D_IPv6-over-OCB_as_a_profi?= =?iso-8859-1?q?le_of_1609_WAVE?= X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 05:59:13 -0000 --_000_AM0PR0302MB3380F8833C7D835D3DBC1363EFD40AM0PR0302MB3380_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Good morning, in my opinion, IEEE 1609.3 allows dynamic addressing to be done using RAs a= nd WRA. I do not see an obligation (read: requirement, or "shall") to "use"= WRAs on receiver side and most importantly, I do not see a conflict betwee= n SLAAC using RA or WRA. The WRA is just another option provided to the dev= ice. Coming back to my original proposal I would amend it to say: This document is based on IEEE 1609.3 but does not require the sending/rece= iving of a WSA containing a WRA. Is that acceptable? Regards Jasja Von: J=E9r=F4me H=E4rri [mailto:jerome.haerri@eurecom.fr] Gesendet: Sonntag, 18. M=E4rz 2018 21:20 An: 'Kevin Smith' ; dickroy@alum.mit.edu; 'Alexandre= Petrescu' Cc: Tijink Jasja ; its@ietf.org Betreff: RE: [ipwave] [ipwave=EE] IPv6-over-OCB as a profile of 1609 WAVE Dear Kevin, I never mentioned that IPv6 was encapsulated by WSM, it clearly does not...= only the ETSI does that. However, the IEEE 1609.3, section 5.1 and 6.4.3 shows that IPv6 requires WM= E for configuring its IP flow, and that the dynamic addressing is done from= receiving a WSA. This is what I meant by IPv6 relying on WSMP (here a WSA)= . So, indeed two different protocols, but interlinked. I agree with Dick and others that providing a way to do enhanced IPv6 in dy= namic environment is the major task of this group...there will be some inte= resting presentation on this tomorrow. Now, I am still skeptical to make an 'restrictive' mention of the ID to be = a profile to IEEE 1609.3, as it would be correct in the US, but it would gi= ve the impression that the ID would not apply to EU. If the group opts to keep this sentence, then maybe we should add something= like: "In Regions operating IEEE 1609.x set of standards, this document is= a profile based on..." BR, J=E9r=F4me From: Kevin Smith [mailto:kevin.s.smith@cox.net] Sent: Sunday 18 March 2018 18:40 To: dickroy@alum.mit.edu; 'Jerome Haerri'; 'Al= exandre Petrescu' Cc: 'Tijink Jasja'; its@ietf.org Subject: RE: [ipwave] [ipwave=EE] IPv6-over-OCB as a profile of 1609 WAVE Hello Jerome and all, As Dick points out, IPv6 does not in any way rely on WSMP. IPv6 packets are NOT encapsulated by WSM. WSMP and IPv6 are two completely = separate protocols. Best, Kevin From: Dick Roy [mailto:dickroy@alum.mit.edu] Sent: Sunday, March 18, 2018 9:44 AM To: 'Jerome Haerri' >; 'Alexandre Petrescu' > Cc: 'Tijink Jasja' = >; 'Kevin Smith' >; its= @ietf.org Subject: RE: [ipwave] [ipwave=EE] IPv6-over-OCB as a profile of 1609 WAVE -----Original Message----- From: its [mailto:its-bounces@ietf.org] On Behalf Of Jerome Haerri Sent: Sunday, March 18, 2018 5:24 PM To: Alexandre Petrescu Cc: Tijink Jasja; Kevin Smith; its@ietf.org Subject: Re: [ipwave] [ipwave=EE] IPv6-over-OCB as a profile of 1609 WAVE Dear All, I disagree for two reasons: First this is not a profile, but an alternative operation of IP without rel= ying on WSM. [RR] WSMP is a networking (and transport) protocol just like IP. The above= statement makes no sense in that respect. One network layer protocol never= "relies on another". That said, if IPv6-over-OCB is a profile of some oth= er set of standards, then you are wasting your time. What is needed are mo= difications to IPv6 to handle rapidly varying network topologies. Where ha= ve you heard that before?? ^))) We don't need or want the IETF to specify = how lower layers MUST behave when sending IP packets. Naturally if there a= re recommendations for lower layer performance that will make the IP functi= ons perform better, make those recommendations. Just NO SHALLs or MUSTs on= any lower layer protocols please! Stick to IPv6 funtionality. Second, this document will also apply outside of the US, and then IEEE 1609= .3 does not apply and thus would make this document confusing. [RR] Not so. IEEE 1609 is an international set of standards, and in partic= ular, IEEE 1609.3 is over the air interoperable with ISO 29281-2 FNTP and t= herefore can operate anywhere FNTP operates around the world. Best Regards, J=E9r=F4me Envoy=E9 de mon iPhone > Le 18 mars 2018 =E0 16:15, Alexandre Petrescu > a =E9crit : > > Hi IPWAVErs, > > Do you disagree we add this phrase in the Introduction: > >> This document is a profile based on IEEE 1609.3: it introduces additiona= l requirements and specifications that do not violate that base standard. > > For my part I find addition of this text neutral and ok, although I am > not sure what is a profile for 1609 WAVE. In Bluetooth, a 'profile' is > something very much precise, like 'LAN profile', etc. > > Alex > > >> Le 17/03/2018 =E0 13:22, Tijink Jasja a =E9crit : >> Hello Alex, >> Can we put something at the beginning of draft-ietf-ipwave-ipv6-over-802= 11ocb-21, maybe in the introduction? >> I suggest some language like the following: >> This document is a profile based on IEEE 1609.3: it introduces additiona= l requirements and specifications that do not violate that base standard. >> Regards Jasja >> -----Urspr=FCngliche Nachricht----- Von: Alexandre Petrescu [mailto:alex= andre.petrescu@gmail.com] Gesendet: Samstag, 17. M=E4rz 2018 12:23 An: Tiji= nk Jasja > Cc: Kevi= n >> Smith >; its@ietf.or= g Betreff: Re: [ipwave] >> ipwave - comments and concerns - 1609 WAVE, EPD - towards resolution >> Hello Jasja, >>> Le 16/03/2018 =E0 19:02, Tijink Jasja a =E9crit : >>> Hello Alex, >>> in addition to Kevin's points, I would like to mention that: >>> 1. I welcome your proposal for the additional text that specifies QoS. = This is necessary for operation in Europe (the specification for the access= layer can be found in ETSI EN 302 663, where clause 4.6 says that QoS shal= l be used). >> Noted. >>> 2. My understanding of the discussion below is that draft-ietf-ipwave-i= pv6-over-80211ocb-21 is "based on" IEEE 1609.3 in that it is compliant with= it (I didn't find any "violation of IEEE 1609.3), and adds additional rest= rictions and /or specifications (such a MTU size, AC_BK, RFC8064, etc.). In= that sense draft-ietf-ipwave-ipv6-over-80211ocb-21 is a profile of IEEE 16= 09.3. I would suggest making that very clear, with a short sentence/paragra= ph in draft-ietf-ipwave-ipv6-over-80211ocb-21 that >>> explains it to the reader. If you disagree, I would like to hear your v= iew on the relation of IEEE 1609.3 and draft-ietf-ipwave-ipv6-over-80211ocb= -21. >> I dont really disagree, just where to put it. >> The draft does refer to 1609.3, in Appendix C "aspects introduced by OCB= to 802.11". The vehicular networking draft (draft-ietf-ipwave-vehicular-n= etworking-01) also refers to it right at the beginning. >> IPv6-over-OCB sounds like an explanation. As such, I suggest we first w= rite more precisely that "IPv6-over-OCB is a profile of 1609.3" and then pu= t it into the vehicular networking draft. >> How could that be written? >> 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 --_000_AM0PR0302MB3380F8833C7D835D3DBC1363EFD40AM0PR0302MB3380_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Good morn= ing,

&nbs= p;

in my opi= nion, IEEE 1609.3 allows dynamic addressing to be done using RAs and WRA. I= do not see an obligation (read: requirement, or “shall”) to “use” WRAs on receiver side and most i= mportantly, I do not see a conflict between SLAAC using RA or WRA. The WRA = is just another option provided to the device.

&nbs= p;

Coming ba= ck to my original proposal I would amend it to say:

&nbs= p;

This docu= ment is based on IEEE 1609.3 but does not require the sending/receiving of = a WSA containing a WRA.

&nbs= p;

Is that a= cceptable?

&nbs= p;

Regards J= asja

&nbs= p;

&nbs= p;

Von: J=E9r= =F4me H=E4rri [mailto:jerome.haerri@eurecom.fr]
Gesendet: Sonntag, 18. M=E4rz 2018 21:20
An: 'Kevin Smith' <kevin.s.smith@cox.net>; dickroy@alum.mit.ed= u; 'Alexandre Petrescu' <alexandre.petrescu@gmail.com>
Cc: Tijink Jasja <Jasja.Tijink@kapsch.net>; its@ietf.org
Betreff: RE: [ipwave] [ipwave=EE] IPv6-over-OCB as a profile of 1609= WAVE

 

Dear Kevin,=

 

I never mentioned that= IPv6 was encapsulated by WSM, it clearly does not…only the ETSI does= that.

 

However, the IEEE 1609= .3, section 5.1 and 6.4.3 shows that IPv6 requires WME for configuring its = IP flow, and that the dynamic addressing is done from receiving a WSA. This is what I meant by IPv6 relying on WSMP (here a= WSA). So, indeed two different protocols, but interlinked.

 

I agree with Dick and = others that providing a way to do enhanced IPv6 in dynamic environment is t= he major task of this group…there will be some interesting presentation on this tomorrow.

 

Now, I am still skepti= cal to make an ‘restrictive’ mention of the ID to be a profile = to IEEE 1609.3, as it would be correct in the US, but it would give the impression that the ID would not apply to EU. <= /p>

 

If the group opts to k= eep this sentence, then maybe we should add something like: “In Regio= ns operating IEEE 1609.x set of standards, this document is a profile based on…”

 

BR,<= /p>

 

J=E9r=F4me<= /span>

 

From: Ke= vin Smith [mailto:kevin.s.smith@co= x.net]
Sent: Sunday 18 March 2018 18:40
To: dickroy@alum.mit.edu= ; 'Jerome Haerri'; 'Alexandre Petrescu'
Cc: 'Tijink Jasja'; its@ietf.org=
Subject: RE: [ipwave] [ipwave=EE] IPv6-over-OCB as a profile of 1609= WAVE

 

Hello Jerome and all,<= o:p>

 

As Dick points out, IP= v6 does not in any way rely on WSMP.

 

IPv6 packets are NOT e= ncapsulated by WSM. WSMP and IPv6 are two completely separate protocols.

 

Best,

Kevin

 

From: = Dick Roy [mailto:dickroy@alum.mit.e= du]
Sent: Sunday, March 18, 2018 9:44 AM
To: 'Jerome Haerri' <= jerome.haerri@eurecom.fr>; 'Alexandre Petrescu' <alexandre.petrescu@gmail.com>
Cc: 'Tijink Jasja' <Ja= sja.Tijink@kapsch.net>; 'Kevin Smith' <kevin.s.smith@cox.net>; its@ietf.org
Subject: RE: [ipwave] [ipwave=EE] IPv6-over-OCB as a profile of 1609= WAVE

 

 

 

-----Original Message----- From: its [mailto:its-bounces@ietf.= org] On Behalf Of Jerome Haerri
Sent: Sunday, March 18, 2018 5:24 PM
To: Alexandre Petrescu
Cc: Tijink Jasja; Kevin Smith; its@ietf.org=
Subject: Re: [ipwave] [ipwave=EE] IPv6-over-OCB as a profile of 1609 WAVE

 

Dear All,<= /p>

 

I disagree for two reasons: =

First this is not a profile,= but an alternative operation of IP without relying on WSM.

&= nbsp;

[RR] WSMP is a networking (and transport) protocol j= ust like IP.  The above statement makes no sense in that respect. One = network layer protocol never "relies on another".  That said, if IPv6-over-OCB is a profile of some other set of standards, t= hen you are wasting your time.  What is needed are modifications to IP= v6 to handle rapidly varying network topologies.  Where have you heard= that before?? ^)))  We don't need or want the IETF to specify how lower layers MUST behave when sending IP packets. =  Naturally if there are recommendations for lower layer performance th= at will make the IP functions perform better, make those recommendations. &= nbsp;Just NO SHALLs or MUSTs on any lower layer protocols please! Stick to IPv6 funtionality.

&= nbsp;

Second, this document will a= lso apply outside of the US, and then IEEE 1609.3 does not apply and thus w= ould make this document confusing.

&= nbsp;

[RR] Not so.  IEEE 1609 is an international set= of standards, and in particular, IEEE 1609.3 is over the air interoperable= with ISO 29281-2 FNTP and therefore can operate anywhere FNTP operates around the world.

&= nbsp;

 

Best Regards,

 

J=E9r=F4me=

 

Envoy=E9 de mon iPhone<= /o:p>

 

> Le 18 mars 2018 =E0 16:= 15, Alexandre Petrescu <= alexandre.petrescu@gmail.com> a =E9crit :

>

> Hi IPWAVErs,=

>

> Do you disagree we add = this phrase in the Introduction:

>

>> This document is a = profile based on IEEE 1609.3: it introduces additional requirements and spe= cifications that do not violate that base standard.

>

> For my part I find addi= tion of this text neutral and ok, although I am

> not sure what is a prof= ile for 1609 WAVE.  In Bluetooth, a 'profile' is

> something very much pre= cise, like 'LAN profile', etc.

>

> Alex<= /p>

>

>

>> Le 17/03/2018 =E0 1= 3:22, Tijink Jasja a =E9crit :

>> Hello Alex,

>> Can we put somethin= g at the beginning of draft-ietf-ipwave-ipv6-over-80211ocb-21, maybe in the= introduction?

>> I suggest some lang= uage like the following:

>> This document is a = profile based on IEEE 1609.3: it introduces additional requirements and spe= cifications that do not violate that base standard.

>> Regards Jasja<= /o:p>

>> -----Urspr=FCnglich= e Nachricht----- Von: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] Gesendet: Samstag, = 17. M=E4rz 2018 12:23 An: Tijink Jasja <Jasja.Tijink@kapsch.net> Cc: Kevin

>> Smith <kevin.s.smith@cox.net>; its@ietf.org Betreff: Re: [ipwave]=

>> ipwave - comments a= nd concerns - 1609 WAVE, EPD - towards resolution

>> Hello Jasja,

>>> Le 16/03/2018 = =E0 19:02, Tijink Jasja a =E9crit :

>>> Hello Alex,

>>> in addition to = Kevin's points, I  would like to mention that:

>>> 1. I welcome yo= ur proposal for the additional text that specifies QoS. This is necessary f= or operation in Europe (the specification for the access layer can be found= in ETSI EN 302 663, where clause 4.6 says that QoS shall be used).

>> Noted.

>>> 2. My understan= ding of the discussion below is that draft-ietf-ipwave-ipv6-over-80211ocb-2= 1 is "based on" IEEE 1609.3 in that it is compliant with it (I di= dn't find any "violation of IEEE 1609.3), and adds additional restrictions and /or specifications (such a MTU size, AC_BK, RFC8064, etc.= ). In that sense draft-ietf-ipwave-ipv6-over-80211ocb-21 is a profile of IE= EE 1609.3. I would suggest making that very clear, with a short sentence/pa= ragraph in draft-ietf-ipwave-ipv6-over-80211ocb-21 that

>>> explains it to = the reader. If you disagree, I would like to hear your view on the relation= of IEEE 1609.3 and draft-ietf-ipwave-ipv6-over-80211ocb-21.

>> I dont really disag= ree, just where to put it.

>> The draft does refe= r to 1609.3, in Appendix C "aspects introduced by OCB to 802.11".=   The vehicular networking draft (draft-ietf-ipwave-vehicular-networki= ng-01) also refers to it right at the beginning.

>> IPv6-over-OCB sound= s like an explanation.  As such, I suggest we first write more precise= ly that "IPv6-over-OCB is a profile of 1609.3" and then put it in= to the vehicular networking draft.

>> How could that be w= ritten?

>> Alex

>

> _______________________= ________________________

> its mailing list

> its@ietf.org

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

 

____________________________= ___________________

its mailing list<= /span>

its@ietf.org

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

--_000_AM0PR0302MB3380F8833C7D835D3DBC1363EFD40AM0PR0302MB3380_-- From nobody Mon Mar 19 01:17: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 99537120721 for ; Mon, 19 Mar 2018 01:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ToFMOPFX1RUq for ; Mon, 19 Mar 2018 01:17:05 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8962D120227 for ; Mon, 19 Mar 2018 01:17:05 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w2J8Gxjk046461; Mon, 19 Mar 2018 09:16:59 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A6BFB20173D; Mon, 19 Mar 2018 09:16: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 967F32014A2; Mon, 19 Mar 2018 09:16:59 +0100 (CET) Received: from [132.166.84.241] ([132.166.84.241]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w2J8Gt9v032586; Mon, 19 Mar 2018 09:16:57 +0100 To: Kevin Smith Cc: "'Tijink Jasja'" , its@ietf.org References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <004401d3be2b$5dc99700$195cc500$@cox.net> From: Alexandre Petrescu Message-ID: <5478538a-a081-fb68-1739-355b84594cdb@gmail.com> Date: Mon, 19 Mar 2018 09:16: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: <004401d3be2b$5dc99700$195cc500$@cox.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] FW: ipwave - comments and concerns - 1609 WAVE, EPD - 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: Mon, 19 Mar 2018 08:17:08 -0000 Le 17/03/2018 à 21:05, Kevin Smith a écrit : [...] > If one develops from scratch (very rare), one would have to answer > questions like how does Frag fields map between IPv6 and 802.11, > security, and other very complicated questions. Agreement would be > needed too. I think one will rather prefer too to rely on Ethernet > (RFC2464), as so many other people did in the past. > > *****[KS]: Sure, but if developers are re-using existing > implementations they don't really need a standard, except to perhaps > explain how it should have been implemented. The primary reason to > have standards is to enable interoperability, and instructs those > developing new (or perhaps debugging old) implementations as to how > to create (or maintain) products that play well with others. There is a fine balance to be struck. Because it is also hard to write an IETF standard that is not implemented at all (running code is necessary to make a standard at IETF), and it is easier to write a Best Current Practice or INFORMATIONAL (not Standards Track) that documents something that is already deployed. [...] > ***** What I'm gathering is that ipwave assumes that an Ethernet II > frame will be received, and need to be "adapted" to an 802.11 frame > format so that it may be transmitted 802.11-OCB. If this is the case, > then perhaps the ipwave document is not clear enough about this. And For clarification: ipwave is the name of the WG. The short name of the document discussed is more like "IPv6-over-80211-OCB", seen in the page header. The ipwave WG generates other documents like the vehicular-networking document and maybe others in the future. > again, I'm making an assumption here, but should the name of the > document be titled something like "Adaptation of Ethernet II frames > for Transmission of IPv6 Packets over IEEE 802.11 Networks operating > in mode Outside the Context of a Basic Service Set"? The suggestion sounds reasonable, but it would break away from the tradition of titleing IPv6-over-foo documents "Transmission of IPv6 over...". All RFCs at IETF about IPv6-over-foo are titled that way. [...] >> the stipulation that packets are transmitted as "standard Ethernet >> packets", is this accurate? > > YEs. > > I verify it this way: > > Use available Wireshark tool on WiFi interface, enable IPv6 on the > computer, and dump some IPv6 packets. They all have EthernetII > headers, rather than LLC and 802.11 headers. Then capture the same > in 'monitor' mode, or 'mon' interface in 802.11 OCB, and the .11/LLC > headers will show instead. > > *****[KS]: I've read that packet captures from Wireshark and tcpdump > display frames received from 802.11 adapters this way, and they are > referred to as "fake Ethernet" frames. Wireshark calls them "EthernetII" headers, not fake. I think people do call them 'fake' but wireshark doesnt. There are more headers in there that people call 'fake' even though wireshark does not call them fake. Even on the monitor interface showing the 802.11 headers truly going on the wire, there are other headers that people call 'fake' because they dont go on the wire (in linux, e.g. the "Radiotap Header".) In a sense, the normal capture shows the beautiful view of the world of IPv6 and Ethernet and RFC2464, whereas the nitty-gritty details are in monitor mode. [...] Alex From nobody Mon Mar 19 01:18: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 72577120227 for ; Mon, 19 Mar 2018 01:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrjbcntPHTRw for ; Mon, 19 Mar 2018 01:17:59 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5067E124319 for ; Mon, 19 Mar 2018 01:17:59 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w2J8Hp7i046844; Mon, 19 Mar 2018 09:17:51 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 21968200D9C; Mon, 19 Mar 2018 09:17:51 +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 0D2D22007F0; Mon, 19 Mar 2018 09:17:51 +0100 (CET) Received: from [132.166.84.241] ([132.166.84.241]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w2J8HmvM001327; Mon, 19 Mar 2018 09:17:49 +0100 To: dickroy@alum.mit.edu Cc: "'Tijink Jasja'" , "'Kevin Smith'" , "'Tony Li'" , its@ietf.org References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <23f068f5-36ff-ced3-495b-f888549981bc@gmail.com> <2089D655102C4BDFA9437A886A5F8D75@SRA6> <2ee7ff6c-fdf9-b18d-6948-bd9f7a5ff35e@gmail.com> From: Alexandre Petrescu Message-ID: <10f0135c-083f-2d80-0c9c-9fe389bee643@gmail.com> Date: Mon, 19 Mar 2018 09:17: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] clarification of EAL text X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 08:18:01 -0000 Le 18/03/2018 à 21:12, Dick Roy a écrit : > > > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu > Sent: Sunday, March 18, 2018 7:06 PM > To: dickroy@alum.mit.edu > Cc: 'Tijink Jasja'; 'Kevin Smith'; 'Tony Li'; its@ietf.org > Subject: Re: [ipwave] clarification of EAL text > > > > Le 18/03/2018 à 18:53, Dick Roy a écrit : >> Making requirements on MAC sublayer protocols is WAY out of scope. Of >> course bridges translate between 802.11 and 802.3 > > EAL [RR] as was described below is not a bridge, it is an adaptation layer. > [RR] If EAL takes an 802.11 MPDU and creates from it an 802.3 MPDU, then it > is by definition performing the translation function of a bridge. It's not > a layer of any kind, nor a shim between layers of any kind. It is a MAC > protocol translator, and those are by definition bridge functions. But many agreed RFCs outside IPWAVE WG say that's not bridging, and it is adaptation layer. Do you have the energy to make these counter statements and persuade these other WGs that what they do is actually bridging? Alex > > RR > > Alex > >> It's NOT up to the IETF >> to tell them how to do it! And once more, if some implementation wants to > ue >> data frames, that's up to them. They will simply ignore any QoS >> requirements. >> >> >> -----Original Message----- >> From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu >> Sent: Sunday, March 18, 2018 6:27 PM >> To: undisclosed-recipients: >> Cc: Tijink Jasja; Kevin Smith; Tony Li; its@ietf.org >> Subject: Re: [ipwave] clarification of EAL text >> >> I suggest this clarification of the EAL text. >> >> OLD: >>> IP packets are transmitted over 802.11-OCB as standard Ethernet >>> packets. As with all 802.11 frames, an Ethernet adaptation layer >>> MUST be used with 802.11-OCB as well." >> >> NEW: >>> Within an IP-RSU, or within an IP-OBU, the IP packets are communicated >>> by the IP stack to and from the 802.11-OCB driver as standard Ethernet >>> II frames. IP packets MUST be transmitted over 802.11-OCB media as >>> QoS Data frames whose format is specified in IEEE Std 802.11. >>> >>> Before sending the IP packets on the 802.11 media, and after receiving >>> packets from the 802.11 media, the use of an adaptation layer that >>> adapts between the frame formats of 802.11 and of Ethernet II is >>> RECOMMENDED. The Ethernet II headers MUST NOT be transmitted on >>> 802.11 media. >> >> Alex >> >> >> Le 17/03/2018 à 13:50, Tony Li a écrit : >>> >>>> on the EAL topic. Take again the following text from the draft: >>>> >>>> " IP packets are transmitted over 802.11-OCB as standard Ethernet >>>> packets. As with all 802.11 frames, an Ethernet adaptation layer >>>> MUST be used with 802.11-OCB as well." >>>> >>>> I understand the second sentence is a requirement you put to >>>> implementations that feature an ethernet interface and an 802.11 >>>> interface. >>> >>> >>> I suspect that we'll also get some push back on this sentence >>> because it is implied to be normative. Since the EAL doesn't >>> actually affect the bits on the air, this is simply an implementation >>> choice and not strictly mandatory. >>> >>> It would probably be easier if we relaxed the wording to make this >>> informative or recommended instead. >>> >>> 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 Mon Mar 19 01: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 A790B120721 for ; Mon, 19 Mar 2018 01:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKfKW8mRBQ0E for ; Mon, 19 Mar 2018 01:18:18 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AFF7124319 for ; Mon, 19 Mar 2018 01:18:17 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w2J8I9Tj046998; Mon, 19 Mar 2018 09:18:09 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D5DCA2014A2; Mon, 19 Mar 2018 09:18: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 C1BB92007F0; Mon, 19 Mar 2018 09:18:09 +0100 (CET) Received: from [132.166.84.241] ([132.166.84.241]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w2J8I5Co001777; Mon, 19 Mar 2018 09:18:06 +0100 To: dickroy@alum.mit.edu, "'Kevin Smith'" Cc: "'Tijink Jasja'" , "'Tony Li'" , its@ietf.org References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <011701d3beef$3fc03a60$bf40af20$@cox.net> <743F6EEEB9BA49E7BE04DC2FB8407D3E@SRA6> From: Alexandre Petrescu Message-ID: Date: Mon, 19 Mar 2018 09:18: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: <743F6EEEB9BA49E7BE04DC2FB8407D3E@SRA6> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] clarification of EAL text X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 08:18:21 -0000 Le 18/03/2018 21:35, Dick Roy a crit: > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Kevin Smith > Sent: Sunday, March 18, 2018 8:28 PM > To: 'Alexandre Petrescu' > Cc: 'Tijink Jasja'; 'Tony Li'; its@ietf.org > Subject: Re: [ipwave] clarification of EAL text > > Hi Alex, > > I think the NEW proposed text has resolved a few of the issues I've been > concerned about. However the statement "Within an IP-RSU, or within an > IP-OBU, the IP packets are communicated by the IP stack to and from the > 802.11-OCB driver as standard Ethernet II frames." seems to make some > assumptions about implementations. > > As data travels up the layered protocol stack, headers are processed and > stripped off, payloads delivered to the next higher layer. It seems like > an assumption to say that an 802.11-OCB driver will receive Ethernet II > frames. > > */[RR] Any 802.11 driver that receives an 802.3 MPDU (from the PHY > layer) will pitch it in the waste can! 802.11 knows NOTHING about 802.3!/* > > It might instead receive IPv6 packets and use some mechanism > (implementation dependent) to determine that the packet needs to be > routed over 802.11-OCB. > > */[RR] This is a routing function and will only work if the unit has > implemented IPv6 routing. If not, the packet will be pitched once again > because it is not intended for that host!/* An adaptation layer is not a routing function. Adaptation layers work ok in (the rare) systems where there is no routing implemented. Alex > > A system diagram showing typical IP-RSU/IP-OBU communication flow would > be helpful, to identify system architecture assumptions being made by > ipwave. > > Best, > > Kevin > > -----Original Message----- > > From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu > > Sent: Sunday, March 18, 2018 10:27 AM > > Cc: Tijink Jasja ; Kevin Smith > ; Tony Li ; its@ietf.org > > Subject: Re: [ipwave] clarification of EAL text > > I suggest this clarification of the EAL text. > > OLD: > >> IP packets are transmitted over 802.11-OCB as standard Ethernet > >> packets. As with all 802.11 frames, an Ethernet adaptation layer MUST > >> be used with 802.11-OCB as well." > > NEW: > >> Within an IP-RSU, or within an IP-OBU, the IP packets are communicated > >> by the IP stack to and from the 802.11-OCB driver as standard Ethernet > >> II frames. IP packets MUST be transmitted over 802.11-OCB media as > >> QoS Data frames whose format is specified in IEEE Std 802.11. > >> > >> Before sending the IP packets on the 802.11 media, and after receiving > >> packets from the 802.11 media, the use of an adaptation layer that > >> adapts between the frame formats of 802.11 and of Ethernet II is > >> RECOMMENDED. The Ethernet II headers MUST NOT be transmitted on > >> 802.11 media. > > Alex > > Le 17/03/2018 13:50, Tony Li a crit : > >> > >>> on the EAL topic. Take again the following text from the draft: > >>> > >>> " IP packets are transmitted over 802.11-OCB as standard Ethernet > >>> packets. As with all 802.11 frames, an Ethernet adaptation layer > >>> MUST be used with 802.11-OCB as well." > >>> > >>> I understand the second sentence is a requirement you put to > >>> implementations that feature an ethernet interface and an 802.11 > >>> interface. > >> > >> > >> I suspect that well also get some push back on this sentence because > >> it is implied to be normative. Since the EAL doesnt actually affect > >> the bits on the air, this is simply an implementation choice and not > >> strictly mandatory. > >> > >> It would probably be easier if we relaxed the wording to make this > >> informative or recommended instead. > >> > >> 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 Mon Mar 19 01:18:54 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 D5BB1124319 for ; Mon, 19 Mar 2018 01:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8d42mF-OWWI for ; Mon, 19 Mar 2018 01:18:51 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0A71120721 for ; Mon, 19 Mar 2018 01:18:50 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w2J8IixO047266; Mon, 19 Mar 2018 09:18:44 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9BAAF2014A2; Mon, 19 Mar 2018 09:18: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 866C1200D9C; Mon, 19 Mar 2018 09:18:44 +0100 (CET) Received: from [132.166.84.241] ([132.166.84.241]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w2J8Ic1B002334; Mon, 19 Mar 2018 09:18:39 +0100 To: dickroy@alum.mit.edu, "'Kevin Smith'" , "'Jerome Haerri'" Cc: "'Tijink Jasja'" , its@ietf.org References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <5cc6bd32-0812-288a-2db0-b0de53626f1e@gmail.com> <00c501d3bee0$26270700$72751500$@cox.net> From: Alexandre Petrescu Message-ID: <6f0fabc2-6df7-b072-e2b9-e6f6f86cd5a3@gmail.com> Date: Mon, 19 Mar 2018 09:18: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: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] =?utf-8?q?=5Bipwave=C3=AE=5D_IPv6-over-OCB_as_a_profile?= =?utf-8?q?_of_1609_WAVE?= X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 08:18:53 -0000 Le 18/03/2018 21:08, Dick Roy a crit: > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu > Sent: Sunday, March 18, 2018 7:14 PM > To: Kevin Smith; dickroy@alum.mit.edu; 'Jerome Haerri' > Cc: 'Tijink Jasja'; its@ietf.org > Subject: Re: [ipwave] [ipwave] IPv6-over-OCB as a profile of 1609 WAVE > > Le 18/03/2018 18:40, Kevin Smith a crit: > >> Hello Jerome and all, > >> > >> As Dick points out, IPv6 does not in any way rely on WSMP. > >> > >> IPv6 packets are NOT encapsulated by WSM. WSMP and IPv6 are two > >> completely separate protocols. > > I tend to agree IPv6 is not encapsulated by WSM. > > But, IPv6 means more things than just the way packets are encapsulated. > > In particular IPv6 also means SLAAC. SLAAC is a mandatory part of IPv6. > > SLAAC is an IPv6 protocol and uses IPv6 Router Advertisements. SLAAC > > does not use WRAs. > > */[RR] SLAAC does not USE RAs either. Well, it does. SLAAC Stateful Address Auto-Configuration is a common name for both RFC4862 using RAs and RFC2464 IPv6-over-Ethernet using a constant fe80. > SLAAC, unless I misunderstand it, > specifies how to take a local prefix, received somehow, It's not a generic somehow, it is a precise RA per RFC4862: > Global addresses are formed by appending an interface identifier to a > prefix of appropriate length. Prefixes are obtained from Prefix > Information options contained in Router Advertisements. > and configure > locally valid IPv6 addresses that will be unique on the local network > (LAN). Doesnt matter how the prefix is obtained as far as the > configuration protocol is concerned./* It does. If there is no RA on the link then there is a big trouble. I will save the DHCPv6 alternative details, but please be aware of this text in RFC4862 "SLAAC": > In this case [no RAs], the forwarding node's address must be manually > configured in hosts to be able to send packets off-link, since the > only mechanism to configure the default router's address > automatically is the one using Router Advertisements. > > In this sense, WSMP specifying that SLAAC uses WRA, can be read as IPv6 > > relying on WSMP. > > */[RR] Its better thought of as a necessary side channel for receiving > a local prefix than as relying on a WRA. /* That side channel is ok as concept, but it is not SLAAC. Alex > > Alex > >> > >> Best, > >> > >> Kevin > >> > >> *From:*Dick Roy [mailto:dickroy@alum.mit.edu] > >> *Sent:* Sunday, March 18, 2018 9:44 AM > >> *To:* 'Jerome Haerri' ; 'Alexandre Petrescu' > >> > >> *Cc:* 'Tijink Jasja' ; 'Kevin Smith' > >> ; its@ietf.org > >> *Subject:* RE: [ipwave] [ipwave] IPv6-over-OCB as a profile of 1609 WAVE > >> > >> -----Original Message----- > >> From: its [mailto:its-bounces@ietf.org] On Behalf Of Jerome Haerri > >> Sent: Sunday, March 18, 2018 5:24 PM > >> To: Alexandre Petrescu > >> Cc: Tijink Jasja; Kevin Smith; its@ietf.org > >> Subject: Re: [ipwave] [ipwave] IPv6-over-OCB as a profile of 1609 WAVE > >> > >> Dear All, > >> > >> I disagree for two reasons: > >> > >> First this is not a profile, but an alternative operation of IP without > >> relying on WSM. > >> > >> [RR] WSMP is a networking (and transport) protocol just like IP. The > >> above statement makes no sense in that respect. One network layer > >> protocol never "relies on another". That said, if IPv6-over-OCB is a > >> profile of some other set of standards, then you are wasting your time. > >> What is needed are modifications to IPv6 to handle rapidly varying > >> network topologies. Where have you heard that before?? ^))) We don't > >> need or want the IETF to specify how lower layers MUST behave when > >> sending IP packets. Naturally if there are recommendations for lower > >> layer performance that will make the IP functions perform better, make > >> those recommendations. Just NO SHALLs or MUSTs on any lower layer > >> protocols please! Stick to IPv6 funtionality. > >> > >> Second, this document will also apply outside of the US, and then IEEE > >> 1609.3 does not apply and thus would make this document confusing. > >> > >> [RR] Not so. IEEE 1609 is an international set of standards, and in > >> particular, IEEE 1609.3 is over the air interoperable with ISO 29281-2 > >> FNTP and therefore can operate anywhere FNTP operates around the world. > >> > >> Best Regards, > >> > >> Jrme > >> > >> Envoy de mon iPhone > >> > >> > Le 18 mars 2018 16:15, Alexandre Petrescu > >> > a > >> crit : > >> > >> > > >> > >> > Hi IPWAVErs, > >> > >> > > >> > >> > Do you disagree we add this phrase in the Introduction: > >> > >> > > >> > >> >> This document is a profile based on IEEE 1609.3: it introduces > >> additional requirements and specifications that do not violate that base > >> standard. > >> > >> > > >> > >> > For my part I find addition of this text neutral and ok, although I am > >> > >> > not sure what is a profile for 1609 WAVE. In Bluetooth, a 'profile' is > >> > >> > something very much precise, like 'LAN profile', etc. > >> > >> > > >> > >> > Alex > >> > >> > > >> > >> > > >> > >> >> Le 17/03/2018 13:22, Tijink Jasja a crit : > >> > >> >> Hello Alex, > >> > >> >> Can we put something at the beginning of > >> draft-ietf-ipwave-ipv6-over-80211ocb-21, maybe in the introduction? > >> > >> >> I suggest some language like the following: > >> > >> >> This document is a profile based on IEEE 1609.3: it introduces > >> additional requirements and specifications that do not violate that base > >> standard. > >> > >> >> Regards Jasja > >> > >> >> -----Ursprngliche Nachricht----- Von: Alexandre Petrescu > >> [mailto:alexandre.petrescu@gmail.com] Gesendet: Samstag, 17. Mrz 2018 > >> 12:23 An: Tijink Jasja >> > Cc: Kevin > >> > >> >> Smith >; > >> its@ietf.org Betreff: Re: [ipwave] > >> > >> >> ipwave - comments and concerns - 1609 WAVE, EPD - towards resolution > >> > >> >> Hello Jasja, > >> > >> >>> Le 16/03/2018 19:02, Tijink Jasja a crit : > >> > >> >>> Hello Alex, > >> > >> >>> in addition to Kevin's points, I would like to mention that: > >> > >> >>> 1. I welcome your proposal for the additional text that specifies > >> QoS. This is necessary for operation in Europe (the specification for > >> the access layer can be found in ETSI EN 302 663, where clause 4.6 says > >> that QoS shall be used). > >> > >> >> Noted. > >> > >> >>> 2. My understanding of the discussion below is that > >> draft-ietf-ipwave-ipv6-over-80211ocb-21 is "based on" IEEE 1609.3 in > >> that it is compliant with it (I didn't find any "violation of IEEE > >> 1609.3), and adds additional restrictions and /or specifications (such a > >> MTU size, AC_BK, RFC8064, etc.). In that sense > >> draft-ietf-ipwave-ipv6-over-80211ocb-21 is a profile of IEEE 1609.3. I > >> would suggest making that very clear, with a short sentence/paragraph in > >> draft-ietf-ipwave-ipv6-over-80211ocb-21 that > >> > >> >>> explains it to the reader. If you disagree, I would like to hear > >> your view on the relation of IEEE 1609.3 and > >> draft-ietf-ipwave-ipv6-over-80211ocb-21. > >> > >> >> I dont really disagree, just where to put it. > >> > >> >> The draft does refer to 1609.3, in Appendix C "aspects introduced by > >> OCB to 802.11". The vehicular networking draft > >> (draft-ietf-ipwave-vehicular-networking-01) also refers to it right at > >> the beginning. > >> > >> >> IPv6-over-OCB sounds like an explanation. As such, I suggest we > >> first write more precisely that "IPv6-over-OCB is a profile of 1609.3" > >> and then put it into the vehicular networking draft. > >> > >> >> How could that be written? > >> > >> >> 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 Mon Mar 19 02:34: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 E49AF1243F6 for ; Mon, 19 Mar 2018 02:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 CAYYfcsFD2ZR for ; Mon, 19 Mar 2018 02:33:58 -0700 (PDT) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::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 BD29E127023 for ; Mon, 19 Mar 2018 02:33:55 -0700 (PDT) Received: by mail-wr0-x235.google.com with SMTP id h2so17782523wre.12 for ; Mon, 19 Mar 2018 02:33:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=JfHhf8wF+TJHZnE+1BYvXp4sGXVz6GKGTSHxhODknIM=; b=b/coGk1dNpGyCfOFL65lwMDZ3T7WWQA6cZjE/3B8IgLs42BWJwOhAsyGrB/x2LyU++ veGJPjUooEEcCO48JBOP0xGM7L71rIDGjwpcQVMWkei1fYwMoimoy4dVrJvrLAzkSkmK kLl9ofDCU0GFBY2jaL+lfBUvb7i2Y7r0n4JxJgNmpzRQKDvdsDymEAVI+p83HkpRW/T+ E1iAtI7LyeKPiuMkA/vfO6EfLpfl96DV/qJDk0hALqXOWIMgSDYDiS+135eumUnWuQ5U +ccTNRM2dFLeW35klk6peUg/elIBeMXyeJQ/o4NQVbDSQq0SpjbcaGmMos6zkj7RF4AG AfbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=JfHhf8wF+TJHZnE+1BYvXp4sGXVz6GKGTSHxhODknIM=; b=Hp3DrwUgomXYuQFQaG1ZG13ODdY7rGxLQ+23QM+gzjiYNKZV8rI68zm8W9CTttFBsX ib93PwFymadkoet0zxvH4HcJwXPnTSp1vdqpZaa6RB0hO2m1w1Nf0kHSeKQy2SadOPrM mwXOFKVssj73H2AD1mzPA3k+cHBD4TDZhSEhDWDCVEw7O+BuRBQJclyaCT0xs/zlgXwX S3gtKs5PwN7zVfqhzz0CMgZ30WRxcW0i+AZggYy1LCa2BX2k8c8hnBwxrNNuKq9w45H4 PZsrQ+Mjh+lD7Embqgia1FjQZ/eaAmuczlwOBkKCFEXB33tyS9t6OL34p4Xy6gR6Wkgu R82g== X-Gm-Message-State: AElRT7GYpwXJ0v9GahPW4MacCMEEc729nu80JQLiZipoUCJqaASZj01B 6JMbPzgH/LGVsdKGhyLPqsQ= X-Google-Smtp-Source: AG47ELu9/3ArSFZC5WRZCRy6Py3ttT7+6YaoZgCXJlMYeanTIay1dY8z6MYq2xQSQTBG96yzzsA91A== X-Received: by 10.223.144.35 with SMTP id h32mr9248674wrh.2.1521452034302; Mon, 19 Mar 2018 02:33:54 -0700 (PDT) Received: from ?IPv6:2001:67c:1232:144:6889:bf35:89b9:96fb? ([2001:67c:1232:144:6889:bf35:89b9:96fb]) by smtp.gmail.com with ESMTPSA id g4sm9314519wrd.1.2018.03.19.02.33.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Mar 2018 02:33:53 -0700 (PDT) Sender: Tony Li From: tony.li@tony.li Message-Id: <01C28783-7A4E-4F88-8163-0D49D8304822@tony.li> Content-Type: multipart/alternative; boundary="Apple-Mail=_8C23337E-02C5-4133-85DD-F3C074588AE4" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Mon, 19 Mar 2018 09:33:52 +0000 In-Reply-To: <9031BA808F7C4C059F4BAA40AC58038F@SRA6> Cc: Tijink Jasja , Kevin Smith , Alexandre Petrescu , its@ietf.org To: dickroy@alum.mit.edu References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <23f068f5-36ff-ced3-495b-f888549981bc@gmail.com> <0738710F-EC0E-43C4-995D-6AFB10C656AF@tony.li> <51846972669440819C0B5F05AFC89A6A@SRA6> <2E6AB388-032A-4D0A-9B11-21B715E2E91D@tony.li> <9031BA808F7C4C059F4BAA40AC58038F@SRA6> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [ipwave] clarification of EAL text X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 09:34:00 -0000 --Apple-Mail=_8C23337E-02C5-4133-85DD-F3C074588AE4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > That=E2=80=99s true. You just won=E2=80=99t interoperate with the = rest of us. =20 > [RR] How the LANs below the IP network layer operate is of no concern = to IP. Sorry, but no. We specify how we are going to use the LANs below IP. > Interoperability is ensured because only nodes on a given LAN will = get a MAC frame containing the IP packet. If the IP packet is to be sent = over several LANs, a bridge will take care of that. The = interoperability you seek is guaranteed by the system specifications of = the deployer of the system. The IETF specifies how IP packets are to be encapsulated. If it = didn=E2=80=99t, we would see Data, QoS Data, and WSM encapsulation. Not = to mention a variety of MTUs. That=E2=80=99s proven to break = interoperability. Also, we do not change specifications for each and every different radio = system. The point of having one so that we all interoperate by default. > If the specs state all nodes do QoS and Data frames at the MAC, or = just QoS frames, then so be it. It s NOT up to the IETF to make this = decision, ever! The IP layer has NO business telling the lower layers = what to do. It can =E2=80=9Crecommend=E2=80=9D, but it MUST not = mandate!:^)) Sorry, I disagree. It is the IETF=E2=80=99s job to standardize this. It = has done so on each and every link layer up until now and will = necessarily continue to do so. Tony --Apple-Mail=_8C23337E-02C5-4133-85DD-F3C074588AE4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
That=E2=80=99s true.  You = just won=E2=80=99t interoperate with the rest of us.  
[RR] How the LANs below the IP network layer operate is of no = concern to = IP.


Sorry, but no.  We specify how we are going = to use the LANs below IP.


  = Interoperability is ensured because only nodes on a given LAN will get a = MAC frame containing the IP packet. If the IP packet is to be sent over = several LANs, a bridge will take care of that.  The = interoperability you seek is guaranteed by the system specifications of = the deployer of the = system.



The = IETF specifies how IP packets are to be encapsulated. If it didn=E2=80=99t= , we would see Data, QoS Data, and WSM encapsulation. Not to mention a = variety of MTUs.  That=E2=80=99s proven to break = interoperability.

Also, we do not = change specifications for each and every different radio system. The = point of having one so that we all interoperate by = default.



 If the = specs state all nodes do QoS and Data frames at the MAC, or just QoS = frames, then so be it.  It s NOT up to the IETF to make this = decision, ever! The IP layer has NO business telling the lower layers = what to do. It can =E2=80=9Crecommend=E2=80=9D, but it MUST not = mandate!:^))



Sorry, I disagree. It is the IETF=E2=80=99s job to = standardize this. It has done so on each and every link layer up until = now and will necessarily continue to do so.

Tony


= --Apple-Mail=_8C23337E-02C5-4133-85DD-F3C074588AE4-- From nobody Mon Mar 19 08:13: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 129DC127871 for ; Mon, 19 Mar 2018 08:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 QqwAJviPzMFu for ; Mon, 19 Mar 2018 08:13:57 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 836EB1270AB for ; Mon, 19 Mar 2018 08:13:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 763503009FB for ; Mon, 19 Mar 2018 11:13:55 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id p615IEBQenMY for ; Mon, 19 Mar 2018 11:13:54 -0400 (EDT) Received: from dhcp-8e33.meeting.ietf.org (dhcp-8e33.meeting.ietf.org [31.133.142.51]) by mail.smeinc.net (Postfix) with ESMTPSA id E07BC3002C7 for ; Mon, 19 Mar 2018 11:13:53 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 19 Mar 2018 11:13:54 -0400 References: <660BFCF2CF184B2C8ACA0743EA9BBB54@SRA6> To: "its@ietf.org" In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 15:13:59 -0000 In the session earlier today, Alex offered text to resolve this topic. = He said: The IPv6 packet transmitted on 802.11-OCB MUST be immediately = preceded by a Logical Link Control (LLC) header and an 802.11 header. In the LLC header, and in accordance with the EtherType Protocol Discrimination (EPD), the value of the Type field MUST be set to 0x86DD (IPv6). In the 802.11 header, the value of the Subtype sub-field in the Frame Control field MUST be set to 8 (i.e. 'QoS Data'); the value of the Traffic Identifier (TID) sub-field of the = QoS Control field of the 802.11 header MUST be set to binary 001 (i.e. User Priority 'Background', QoS Access Category 'AC_BK'). No one in the room raised any concern with this text. If you have a = concern, please speak on the list now. In a another part of the meeting, J=C3=A9r=C3=B4me talked about Mapping = IP to Access Category in 802.11-OCB. It was pointed out that RFC 8325 = was recently published on the standards track. Tony Li pointed out that = there is no integrity protection for these bits. As an individual, I wonder if it would be better to say something like: = If DiffServ is being used, set the QoS Access Category as described in = RFC 8325, otherwise set the QoS Access Category of 'AC_BK'. What do others think? Russ From nobody Mon Mar 19 09:07: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 34D9C12D873 for ; Mon, 19 Mar 2018 09:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 zfH3-QZ8Gg4K for ; Mon, 19 Mar 2018 09:07:49 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB24612D7E5 for ; Mon, 19 Mar 2018 09:07:48 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id s206so13379795wme.0 for ; Mon, 19 Mar 2018 09:07:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=aDpO7c9mOvyYEqeqVAJvcyEPviPO6WwjjKdGgVU+Nkc=; b=tKgYx93pOxWVutnO3V12y2nTVnbg0PyRKN+1D0HpSpmnlEcdTK2S67yxjJnqlDLL9I r6i0l93EbpvfEwvLIko7QoZVJPAx8PqVSOc08deK6CwmWpulvIhsLjx0AUzvqB78gKNR Qda55k8RHOS4LNKleqh9xIQYrfWoiR05vFN6tiTc0KL7C7GAQoySJD1tOQVqmU69FsgG cPTU8sl4E8Dl4BEK/OPxf8Hl3ro3XrHEN3cDvr8q+im9udOpmlvAPszon1JMuPdXUY0/ GFsmrsZjYd4/hAAO5ItMgREKdA73epzzBo0bhG7mCWagoNbrKDjIbirlEKq9mnXsBcpT qA2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=aDpO7c9mOvyYEqeqVAJvcyEPviPO6WwjjKdGgVU+Nkc=; b=VYsA+CxsZtBj4PJ3h/HW4wI+XF66VTOxN2D88pCPDcyuZC0xAo5DRxpoFASuc1tzwj AKCKY78YSr0L00H+gCT7r4YiRzAns3z9oQtKr/h6H+7oOXJrWl7gaBTSJu2blKhXndaa Wa+kPvqk6Bl8xZZIBfpEriWV2AAhaRnNMhcLGGNEmYWFEkrqmq/JkLq3LfhskEDCP8Uk sACAcqLIkgyA837qVnpTpTMZqOAaZd+W18P9KnPAD+xd8Bivi2iqHRiLj/fPp5BJWt1H CLL+Relmw6C7vrMWCR3YT8pB8754SVk5FpIfmt0ZdrR4PqC8EBkWgHL/xULf4oCqzgOJ Zl+g== X-Gm-Message-State: AElRT7HZ2FfGFKPotrDf4HbpHQ4mgnyN5wlWwVooayTY28ywh2xDRwdI c0plC0lg7XFRaN825H9Tg2v7/q5x X-Google-Smtp-Source: AG47ELvpyvTR3qV7jmJnHRTJfrRUhELDDgNAkDZ4E6w4DJmw3IyepGWZitl7RBkPsTtoALayIbgt+g== X-Received: by 10.28.178.136 with SMTP id b130mr2328626wmf.68.1521475667460; Mon, 19 Mar 2018 09:07:47 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:9455:490d:e2f7:ff8a? ([2001:67c:370:128:9455:490d:e2f7:ff8a]) by smtp.gmail.com with ESMTPSA id o11sm385687wrg.91.2018.03.19.09.07.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Mar 2018 09:07:46 -0700 (PDT) Sender: Tony Li 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: Date: Mon, 19 Mar 2018 16:07:46 +0000 Cc: "its@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <39A1E8E8-18B1-43B6-BF01-FA875AD084BC@tony.li> References: <660BFCF2CF184B2C8ACA0743EA9BBB54@SRA6> To: Russ Housley X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 16:07:52 -0000 Russ, As the writer of the device driver has NO idea whether or not DiffServ = is in use (a rare case), they are very likely to make the mistake that = this is somehow beneficial when the converse is actually true. There was also no discussion of the EAL, so I suspect that we still need = to reach closure on that text. Tony > On Mar 19, 2018, at 3:13 PM, Russ Housley = wrote: >=20 > In the session earlier today, Alex offered text to resolve this topic. = He said: >=20 > The IPv6 packet transmitted on 802.11-OCB MUST be immediately = preceded > by a Logical Link Control (LLC) header and an 802.11 header. In the > LLC header, and in accordance with the EtherType Protocol > Discrimination (EPD), the value of the Type field MUST be set to > 0x86DD (IPv6). In the 802.11 header, the value of the Subtype > sub-field in the Frame Control field MUST be set to 8 (i.e. 'QoS > Data'); the value of the Traffic Identifier (TID) sub-field of the = QoS > Control field of the 802.11 header MUST be set to binary 001 (i.e. > User Priority 'Background', QoS Access Category 'AC_BK'). >=20 > No one in the room raised any concern with this text. If you have a = concern, please speak on the list now. >=20 > In a another part of the meeting, J=C3=A9r=C3=B4me talked about = Mapping IP to Access Category in 802.11-OCB. It was pointed out that = RFC 8325 was recently published on the standards track. Tony Li pointed = out that there is no integrity protection for these bits. >=20 > As an individual, I wonder if it would be better to say something = like: If DiffServ is being used, set the QoS Access Category as = described in RFC 8325, otherwise set the QoS Access Category of 'AC_BK'. >=20 > What do others think? >=20 > Russ >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Mon Mar 19 12:07: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 BD32D12D88C for ; Mon, 19 Mar 2018 12:07:16 -0700 (PDT) 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 VF70gugY_bUZ for ; Mon, 19 Mar 2018 12:07:14 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF7EA12025C for ; Mon, 19 Mar 2018 12:07:13 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id o64so3829090qkl.7 for ; Mon, 19 Mar 2018 12:07:13 -0700 (PDT) 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=U21/+mscOqqOeYBsNqSjHc7kodLdTFzfAQM6tcEefVQ=; b=clV41nlBopIbdpQibklKvBTxYPoDD81moT8Htc9E3RDxh5vUxsznzigndDrabXpSmM JIw1TmQ3PvttRywDfFSqaApk5jM3yhqMLnsZrgEwdqm9oKcKqIUCFEjMNAvds7pGrLR8 J+2vEo6aS+cDHUaE3GQlxxMpATg7TlkA+T3UTbWPjoPa+SMNc24eSFQfgxHgSxZ0Ny1x AE0bnAjYe9P8sg+yFDSqRYN34YadIAXQwCn1umeLQ9P7YWC1xDwNHc9/rJmB4PkeYWtu KxzVb9FuTKp1trWRVZB3KbR9ylMxt0IS0tXD5FKxBwll6W8gNq5sPeIljp4dclf7+p74 5FZw== 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=U21/+mscOqqOeYBsNqSjHc7kodLdTFzfAQM6tcEefVQ=; b=lNfO5J3O/gBwdlDtGMVO+kGNsdyXhnYsxk1bafTbeGcbajV2V407J80p/yzPMIk+nI PDqsAzcd+NFygfa5hW0h8kU2+/+ex0AU655AnO0VRwJZ8nQO/Lk6vbIK+aeDa4VHJsjM iuBkMC2ffzQxMS7uabyvoX7mPMr9NhP+cQ8rCIiYxe3EQkMR7B+LdjYvFbaUJkHcwzrR effUDrbCP5So4+aly4uCfgVyp/y+iPiAvVvt6ExwBHqn3g4Rjvc3eiPzpYBmWgCQ5xP1 vASjT6K4Tkf0dzom6QE/QQWi3JqH4EEuI0dyD6nO0fu0Pak678e4HS6Wzt81pP8Brn5t lYMA== X-Gm-Message-State: AElRT7FL7z0ZwmRuXlWcP4YgYI8V00dhCx9GUJvt5aCipGeSLLIX2JVV 0W5wAP2rL/IHwW5vzQEVGw4= X-Google-Smtp-Source: AG47ELsjHx8Mp7Lk3OALzuUk4z0a1abMMYsRoT1UdnqGTcXKwWWBXGYT47RkCMB6enMGmv+/EThiNw== X-Received: by 10.55.115.67 with SMTP id o64mr19009118qkc.144.1521486432701; Mon, 19 Mar 2018 12:07:12 -0700 (PDT) Received: from FrancoisPC (pool-108-48-182-86.washdc.fios.verizon.net. [108.48.182.86]) by smtp.gmail.com with ESMTPSA id m53sm485940qtf.67.2018.03.19.12.07.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Mar 2018 12:07:11 -0700 (PDT) From: =?utf-8?Q?Fran=C3=A7ois_Simon?= To: , References: <114b39d6-351d-a78a-84d6-dec0ca34faf2@cea.fr> <1521217574.4118.17.camel@it.uc3m.es> In-Reply-To: <1521217574.4118.17.camel@it.uc3m.es> Date: Mon, 19 Mar 2018 15:07:10 -0400 Message-ID: <002201d3bfb5$7bc54cf0$734fe6d0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0023_01D3BF93.F4B867E0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGeiO4rVNApph2vjf1DeHVUky5GZwHkwU2spDMwwgA= Content-Language: en-us Archived-At: Subject: Re: [ipwave] QoSData, EPD, 1609 WAVE, EtherType - common text 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: Mon, 19 Mar 2018 19:07:16 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0023_01D3BF93.F4B867E0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable the value of the Traffic Identifier (TID) sub-field of=20 > > the QoS Control field of the 802.11 header MUST be set to binary 001 = > > (i.e. User Priority 'Background', QoS Access Category 'AC_BK'). I am not sure why the access category MUST be set to AC_BK. Does all = IPv6 exchanges will be of the lowest priority? This does not give much = flexibility for various applications. AC_BK is mostly used for bulk = data transfer or printer job. Perhaps set as a default would be more = appropriate. Fygs -----Original Message----- From: Carlos Jes=C3=BAs Bernardos Cano =20 Sent: Friday, March 16, 2018 12:26 PM To: Alexandre PETRESCU ; its@ietf.org Cc: Sandra C=C3=A9spedes U. ; Kevin Smith = ; John Kenney ; Tijink = Jasja ; Tony Li ; = Fran=C3=A7ois Simon ; Dick Roy = Subject: Re: [ipwave] QoSData, EPD, 1609 WAVE, EtherType - common text = towards resolution Hi Alex, Thanks for driving this. People, please do express if you agree or not with Alex's proposal. It = is important to get as much feedback as possible by the time of the = IPWAVE F2F session in London, so we can close this for one and for all. Thanks, Carlos On Fri, 2018-03-16 at 14:43 +0100, Alexandre PETRESCU wrote: > Hi IPWAVErs, >=20 > I propose the following text to resolve commonly the QoSData and > 1609 > WAVE EPD recent issues. >=20 > > The IPv6 packet transmitted on 802.11-OCB MUST be immediately=20 > > preceded by a Logical Link Control (LLC) header and an 802.11=20 > > header. In the LLC header, and in accordance with the EtherType=20 > > Protocol Discrimination (EPD), the value of the Type field MUST be=20 > > set to 0x86DD (IPv6). In the 802.11 header, the value of the=20 > > Subtype sub-field in the Frame Control field MUST be set to 8 (i.e. = > > 'QoS Data'); the value of the Traffic Identifier (TID) sub-field of=20 > > the QoS Control field of the 802.11 header MUST be set to binary 001 = > > (i.e. User Priority 'Background', QoS Access Category 'AC_BK'). > >=20 > > In the Ethernet II header, the value of the Type field MUST be set=20 > > to 0x86DD (IPv6). >=20 > Remove this phrase: > > Other alternative views of layering are EtherType Protocol=20 > > Discrimination (EPD), see Appendix E, and SNAP see [RFC1042]. >=20 > Yours, >=20 > Alex >=20 >=20 > _______________________________________________ > its mailing list > its@ietf.org =20 > https://www.ietf.org/mailman/listinfo/its ------=_NextPart_000_0023_01D3BF93.F4B867E0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable RE: [ipwave] QoSData, EPD, 1609 WAVE, EtherType - common text = towards resolution

the value of = the Traffic Identifier (TID) sub-field of

> > = the QoS Control field of the 802.11 header MUST be set to binary 001 =

> > = (i.e. User Priority 'Background', QoS Access Category = 'AC_BK').

I am not sure = why the access category MUST be set to AC_BK. Does all IPv6 exchanges will be of the lowest = priority?  This does not give much flexibility for various = applications.  AC_BK is mostly used for bulk data transfer or printer = job.  Perhaps set as a default would be more = appropriate.

Fygs

-----Original = Message-----
From: Carlos Jes=C3=BAs Bernardos Cano <cjbc@it.uc3m.es>
Sent: Friday, March 16, 2018 12:26 PM
To: Alexandre PETRESCU <alexandre.petrescu@cea.fr>; = its@ietf.org
Cc: Sandra C=C3=A9spedes U. <scespedes@ing.uchile.cl>; Kevin Smith = <kevin.s.smith@cox.net>; John Kenney = <jkenney@us.toyota-itc.com>; Tijink Jasja = <Jasja.Tijink@kapsch.net>; Tony Li <tony.li@tony.li>; = Fran=C3=A7ois Simon <fygsimon@gmail.com>; Dick Roy = <dickroy@alum.mit.edu>
Subject: Re: [ipwave] QoSData, EPD, 1609 WAVE, EtherType - common text = towards resolution

Hi = Alex,

Thanks for = driving this.

People, please = do express if you agree or not with Alex's proposal. It is important to = get as much feedback as possible by the time of the IPWAVE F2F session = in London, so we can close this for one and for all.

Thanks,

Carlos

On Fri, = 2018-03-16 at 14:43 +0100, Alexandre PETRESCU wrote:

> Hi = IPWAVErs,

> =

> I propose = the following text to resolve commonly the QoSData and

> = 1609

> WAVE EPD = recent issues.

> =

> > The = IPv6 packet transmitted on 802.11-OCB MUST be immediately =

> > = preceded by a Logical Link Control (LLC) header and an 802.11 =

> > = header. In the LLC header, and in accordance with the EtherType =

> > = Protocol Discrimination (EPD), the value of the Type field MUST be =

> > set = to 0x86DD (IPv6).  In the 802.11 header, the value of the =

> > = Subtype  sub-field in the Frame Control field MUST be set to 8 = (i.e.

> > 'QoS = Data'); the value of the Traffic Identifier (TID) sub-field of =

> > the = QoS Control field of the 802.11 header MUST be set to binary 001 =

> > (i.e. = User Priority 'Background', QoS Access Category = 'AC_BK').

> > =

> > In = the Ethernet II header, the value of the Type field MUST be set =

> > to = 0x86DD (IPv6).

> =

> Remove = this phrase:

> > Other = alternative views of layering are EtherType Protocol

> > = Discrimination (EPD), see Appendix E, and SNAP see = [RFC1042].

> =

> = Yours,

> =

> = Alex

> =

> =

> = _______________________________________________

> its = mailing list

> its@ietf.org

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

------=_NextPart_000_0023_01D3BF93.F4B867E0-- From nobody Mon Mar 19 14:07: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 043FE1270A0 for ; Mon, 19 Mar 2018 14:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-RUfB79q4zA for ; Mon, 19 Mar 2018 14:07:12 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::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 E7636126D73 for ; Mon, 19 Mar 2018 14:07:11 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id z73so15799646wrb.0 for ; Mon, 19 Mar 2018 14:07:11 -0700 (PDT) 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=sgbJLYae90WV24OR9kDp0JOoNZgq61zkNZSWS7mBUus=; b=izvzzTkBt5F/Zx4uf0habwhPkknM2TsiXzOAjY8SQYWeFBirp4k4NOIEHA58mbg+Na QPtyNH2A3jxkZFvYh8gaJ5t+h7mbp5TAMdhuO7VuNqktbDfj3NQckyZDkLxm7MwCifqf KXULW1s/ToMutmQYaSzaISwAqR52475lSZan2VklCgxyHNSdMMMhgZBIY3TyVXf8SkYN D2ayWBo/oXvnzrSsZbNJrguzVzYEgr9aItxndCHgXM0csFG8ZAEGhusVB/N637WcjOkX I+34fvQtEOGuzhPRNIlIonRKS9EZVSamG2/TpTao5jfLfIV69xsFCvd/daWvpHPptseg f3uQ== 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=sgbJLYae90WV24OR9kDp0JOoNZgq61zkNZSWS7mBUus=; b=aHPSFeHmx1sq9PEnzLBicKUbqAHIdpnN3Z1QeVt1hyHjBn3id8VdgoyeKXnZRxmulJ TSLy8kz5+D3tUqYyQcmYYcRj7pQiRHkB37RhIIwODbZsYiTjbwEU/XmgpcI+ugwOXVS0 Xt+CvsIqfLWDQx0dLHTnfmcVnXHSWLhYBfx6sUGtHuMdKI61TMumTDnzYxfW4pjBnNY1 RQ8Bs4a/5up1qyJ1s6aa3cxiyZlxdU91tMwV12zJDkgHcogmKCsmSGRl1kZ3jgZqzs/s GBzM2FkVd/Pkr7xcA7kGw94OxnjTMVM/w37weHETKDMLV7RzQKOOUH73nRNIRdYq/9f1 KW6Q== X-Gm-Message-State: AElRT7EWTcEDC+KNST5qz7sU1UMR4g6Rk+5qONEm6uuN6fVaA6SIlCaX xznub13gAfsgoWJEEiynxzk= X-Google-Smtp-Source: AG47ELuH4wzeguL4b1mL2fhLcH8+QrIWrKby86czZxkTsMX6yiDCYf9Pr7Jzjd4Ep9gSI+7YcXV+kg== X-Received: by 10.223.136.112 with SMTP id e45mr9922384wre.189.1521493630524; Mon, 19 Mar 2018 14:07:10 -0700 (PDT) Received: from ?IPv6:2001:67c:1232:144:942a:816e:7f2e:58be? ([2001:67c:1232:144:942a:816e:7f2e:58be]) by smtp.gmail.com with ESMTPSA id i127sm62147wmf.33.2018.03.19.14.07.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Mar 2018 14:07:09 -0700 (PDT) From: Tony Li Message-Id: <30632EBD-9104-46AE-9B9B-FE1B80A193AB@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_DF4DA8D7-C7D2-4CA9-A9E0-DA9E9A32915D" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Mon, 19 Mar 2018 21:07:08 +0000 In-Reply-To: <002201d3bfb5$7bc54cf0$734fe6d0$@gmail.com> Cc: =?utf-8?Q?Carlos_Jes=C3=BAs_Bernardos_Cano?= , its@ietf.org To: =?utf-8?Q?Fran=C3=A7ois_Simon?= References: <114b39d6-351d-a78a-84d6-dec0ca34faf2@cea.fr> <1521217574.4118.17.camel@it.uc3m.es> <002201d3bfb5$7bc54cf0$734fe6d0$@gmail.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [ipwave] QoSData, EPD, 1609 WAVE, EtherType - common text 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: Mon, 19 Mar 2018 21:07:15 -0000 --Apple-Mail=_DF4DA8D7-C7D2-4CA9-A9E0-DA9E9A32915D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > I am not sure why the access category MUST be set to AC_BK. Does all = IPv6 exchanges will be of the lowest priority? This does not give much = flexibility for various applications. AC_BK is mostly used for bulk = data transfer or printer job. Perhaps set as a default would be more = appropriate. As noted previously and in the meeting, there is no security of the IPv6 = traffic class and very few networks make an effort to police it meaning = that it is largely unused. If we attempt to make use of it without some means of ensuring its = validity, we then encourage hackers to attack their protocol stacks to = get better service at the expense of others. Tony --Apple-Mail=_DF4DA8D7-C7D2-4CA9-A9E0-DA9E9A32915D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

I am not sure why the access category MUST = be set to AC_BK. Does all = IPv6 exchanges will be of the lowest = priority?  This does not give much = flexibility for various applications.  AC_BK is mostly used for bulk data transfer or printer = job.  Perhaps set as a default would be more = appropriate.


As noted previously and = in the meeting, there is no security of the IPv6 traffic class and very = few networks make an effort to police it meaning that it is largely = unused.

If we = attempt to make use of it without some means of ensuring its validity, = we then encourage hackers to attack their protocol stacks to get better = service at the expense of others.

Tony

= --Apple-Mail=_DF4DA8D7-C7D2-4CA9-A9E0-DA9E9A32915D-- From nobody Tue Mar 20 05:51: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 D7660127078 for ; Tue, 20 Mar 2018 05:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZ-fXAmcWesc for ; Tue, 20 Mar 2018 05:51:11 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B34F8127599 for ; Tue, 20 Mar 2018 05:51:05 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w2KCowUA137305; Tue, 20 Mar 2018 13:50:58 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8BBE8203720; Tue, 20 Mar 2018 13:50: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 794E52010D4; Tue, 20 Mar 2018 13:50: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 w2KCowNv014442; Tue, 20 Mar 2018 13:50:58 +0100 To: tony.li@tony.li Cc: Tijink Jasja , Kevin Smith , "its@ietf.org" References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <23f068f5-36ff-ced3-495b-f888549981bc@gmail.com> <0738710F-EC0E-43C4-995D-6AFB10C656AF@tony.li> From: Alexandre Petrescu Message-ID: Date: Tue, 20 Mar 2018 13:50: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: <0738710F-EC0E-43C4-995D-6AFB10C656AF@tony.li> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] clarification of EAL text X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 12:51:13 -0000 Le 18/03/2018 à 22:18, tony.li@tony.li a écrit : > > I continue to object to this text. > > Again, we should only be standardizing (normative text) on the bits > as they appear on the air. > > The interface between the driver and the operating system is an API > that is wholly out of scope for our charter. > > I can accept including some informative text in this regard, but it > should not be normative. > > I’d like to propose alternate text: > > > IP packets MUST be transmitted over 802.11-OCB media as QoS Data > frames whose format is specified in IEEE Std 802.11. > > To simplify the API between the operating system and the 802.11-OCB > media, device drivers MAY implement an Ethernet Adaptation Layer that > translates Ethernet II frames to the 802.11 format and vice versa. I agree. Alex > > Tony > > >> On Mar 18, 2018, at 5:26 PM, Alexandre Petrescu >> wrote: >> >> I suggest this clarification of the EAL text. >> >> OLD: >>> IP packets are transmitted over 802.11-OCB as standard Ethernet >>> packets. As with all 802.11 frames, an Ethernet adaptation layer >>> MUST be used with 802.11-OCB as well." >> >> NEW: >>> Within an IP-RSU, or within an IP-OBU, the IP packets are >>> communicated by the IP stack to and from the 802.11-OCB driver as >>> standard Ethernet II frames. IP packets MUST be transmitted over >>> 802.11-OCB media as QoS Data frames whose format is specified in >>> IEEE Std 802.11. Before sending the IP packets on the 802.11 >>> media, and after receiving packets from the 802.11 media, the use >>> of an adaptation layer that adapts between the frame formats of >>> 802.11 and of Ethernet II is RECOMMENDED. The Ethernet II >>> headers MUST NOT be transmitted on 802.11 media. >> >> Alex >> >> >> Le 17/03/2018 à 13:50, Tony Li a écrit : >>>> on the EAL topic. Take again the following text from the >>>> draft: " IP packets are transmitted over 802.11-OCB as standard >>>> Ethernet packets. As with all 802.11 frames, an Ethernet >>>> adaptation layer MUST be used with 802.11-OCB as well." I >>>> understand the second sentence is a requirement you put to >>>> implementations that feature an ethernet interface and an >>>> 802.11 interface. >>> I suspect that we’ll also get some push back on this sentence >>> because it is implied to be normative. Since the EAL doesn’t >>> actually affect the bits on the air, this is simply an >>> implementation choice and not strictly mandatory. It would >>> probably be easier if we relaxed the wording to make this >>> informative or recommended instead. Tony > > From nobody Tue Mar 20 05:55: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 75238127078 for ; Tue, 20 Mar 2018 05:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wu14j7Eg7Rnc for ; Tue, 20 Mar 2018 05:54:55 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::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 065E51243FE for ; Tue, 20 Mar 2018 05:54:55 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id s9so1436480qke.12 for ; Tue, 20 Mar 2018 05:54:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=WNPjeStPR1BTl2GPoNQCdyVsDegmtZfqsR8YLFNUlWY=; b=b21oexN42sGs39HvIJeEz8NUR6JU1ntkIpTLiW0Bv0FBguAOH2/y8F+ETBuFA4wtLa kWXCtDs2TeWGZkjQZm0CrtFvpoJMRt9kFQAoqLM/SYzqjSTYAmdpniIFLxU3o/z+DNnD zDr0mSDhaXIjOwrmP3dv+76BGwFekeMZzjnZyJbLZ1TZIoeU6dzuB/eq/0Wf9PLN1d20 LMsgIR1yLbnK7K0OfTdJ5+yBM/bgThM34TFiBs2alaBm5Pz/jCelFGiu8WkPErzCwbPh BSOjBUnhX7NmDRdswnS/gKSxn4yI/7GTCMzQLE6yYZbWGuFtJEKSpSFkzB7XGjsWr6nt XW/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=WNPjeStPR1BTl2GPoNQCdyVsDegmtZfqsR8YLFNUlWY=; b=ii/cojGFUMWuLJQOy5GXiW5jJTZHxcC5R1QkmB+x4GnkDk3fY8H+B4qqB3AsW9gsJN qZRsPKqXBTbIo88BI5dsjouIDDAzl9lZXUJCnfa+i7tZeuGh60M1T9EQepLg00AlVwQp toYXeT97uP9rvBKbVrlbFhZZM7D90az01YNm0cPhXpr0ZgzZzP1+krwm6bvuMSt2Ib+9 CPLpFI9Zbn3nPBg0ONZ5oggCl0fivtFH9KN5KfVffzkW6+IzmL9b417kGHeBd2aWp7eP omKtH1z/cZs5ZBHSiIGG1kOM7iX6NQfvxeOExtDbXPaiJliLWMjYiFWJ6iX+9/8sVquU EHIA== X-Gm-Message-State: AElRT7GXB066cY6hA4npZ/KSP9sufLBwz3FFZh57QCLHmJgP2QvLp+OR DVwms4XbwS7KajQtX2mNjz2l2w== X-Google-Smtp-Source: AG47ELuHalUJS8iExNktKlee7fMHXFX39ym3a/hXPoZJmFgfGRqUWw7jL6CDcGLWhMDfAIudSrTmAA== X-Received: by 10.55.157.66 with SMTP id g63mr23623454qke.107.1521550493820; Tue, 20 Mar 2018 05:54:53 -0700 (PDT) Received: from FrancoisPC (50-253-61-187-static.hfc.comcastbusiness.net. [50.253.61.187]) by smtp.gmail.com with ESMTPSA id a12sm1132036qtm.74.2018.03.20.05.54.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Mar 2018 05:54:53 -0700 (PDT) From: =?iso-8859-1?Q?Fran=E7ois_Simon?= To: "'Kevin Smith'" Cc: References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> In-Reply-To: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> Date: Tue, 20 Mar 2018 08:54:52 -0400 Message-ID: <004d01d3c04a$a3ed57f0$ebc807d0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004E_01D3C029.1CDE28F0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGhOrR8o8b5YryKQCC/S9k90bJ5fwGaWEJkpDAjVZA= Content-Language: en-us Archived-At: Subject: Re: [ipwave] FW: ipwave - comments and concerns - 1609 WAVE, EPD - 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, 20 Mar 2018 12:54:58 -0000 This is a multipart message in MIME format. ------=_NextPart_000_004E_01D3C029.1CDE28F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If ipwave is intended to be interoperable with 1609 WAVE, then ipwave = must specify the use of EtherType Protocol Discrimination (EPD) in the LLC sublayer header, i.e., EPD is mandatory. If interoperable with 1609 or not, EPD is mandatory in the 5.9 GHz band. =85 the 802.11 header MUST be set to binary 001 (i.e. > User Priority 'Background', QoS Access Category 'AC_BK'). "MUST" be AC_BK is too restrictive. It should be left to be set = according to the application. - ipwave 4.2.1 it states "An 'adaptation' layer is inserted between a = MAC layer and the Networking layer." This sounds like a requirement. If I am developing a product that is only concerned with sending IPv6 over OCB, = and does not require "bridging", then how do I reconcile this requirement? If my recollection is correct, the original document stated "IPv6 over = the data link layer; DL =3D LLC + MAC. General: Since the first draft of the IPWAVE it was made clear the 1609 WAVE was = out of scope. Fygs -----Original Message----- From: its On Behalf Of Kevin Smith Sent: Friday, March 16, 2018 1:35 PM To: Alexandre PETRESCU Cc: 'Tijink Jasja' ; its@ietf.org Subject: [ipwave] FW: ipwave - comments and concerns - 1609 WAVE, EPD - towards resolution Hi Alex, Thanks for the feedback. I have a few comments - but please keep in mind that these comments and opinions are my own and not necessarily those of = the 1609 WG at large. I do not have the authority for speak for the WG, I'm = just the editor. ;) My comments are inline denoted by [KS]. And please also seem some *new comments* below regarding EAL and "standard Ethernet packets". Best regards, Kevin -----Original Message----- From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu Sent: Thursday, March 15, 2018 11:23 AM To: Kevin Smith > Cc: Tijink Jasja >; its@ietf.org =20 Subject: Re: [ipwave] ipwave - comments and concerns - 1609 WAVE, EPD - towards resolution Hi Kevin, Kevin wrote recently: > Dear IETF ipwave working group, >=20 >=20 >=20 > My name is Kevin Smith, I am the technical editor for IEEE Std 1609.3=20 > and a few others in the 1609 family of standards. I have some concerns = > regarding ipwave's interoperability with 1609 WAVE, and a question=20 > regarding the need or purpose for ipwave. Generally speaking, the purpose of ipwave WG is set in the Charter. (https://datatracker.ietf.org/wg/ipwave/about/) > 1. If ipwave is intended to be interoperable with 1609 WAVE,=20 > then ipwave must specify the use of EtherType Protocol Discrimination > (EPD) in the LLC sublayer header, i.e., EPD is mandatory. We should interoperate to a maximum. [KS]: Agreed! I suggest that in section 4.2.1 "Ethernet Adaptation Layer" we add the following paragraph: > The IPv6 packet transmitted on 802.11-OCB MUST be immediately preceded = > by a Logical Link Control (LLC) header and an 802.11 header. > In the LLC header, and in accordance with the EtherType Protocol=20 > Discrimination (EPD), the value of the Type field MUST be set to=20 > 0x86DD (IPv6). In the 802.11 header, the value of the Subtype=20 > sub-field in the Frame Control field MUST be set to 8 (i.e. 'QoS=20 > Data'); the value of the Traffic Identifier (TID) sub-field of the QoS = > Control field of the 802.11 header MUST be set to binary 001 (i.e. > User Priority 'Background', QoS Access Category 'AC_BK'). >=20 > In the Ethernet II header, the value of the Type field MUST be set to=20 > 0x86DD (IPv6). Do you agree with this text? [KS]: I agree with the part that addresses the LLC header. I don't = disagree with the part addressing the 802.11 header, I'm just not an expert in = this area and so defer to others. I believe that others in the 1609 WG have = been discussing this with the ipwave list?=20 > I note that ipwave mentions EPD, but also SNAP and does not specify=20 > which method to use. I propose we remove this phrase: > Other alternative views of layering are EtherType Protocol=20 > Discrimination (EPD), see Appendix E, and SNAP see [RFC1042]. Do you agree? [KS]: Yes. > Moreover ipwave discusses an abstract "Ethernet Adaptation Layer" > but does not specify a header format, and this further confuses the=20 > question for deployers - what should we implement? The Ethernet Adaptation Layer (more precisely 802.11-to-Ethernet AL) is = not so abstract, because it is widely implemented. This layer does = conversion between headers: at reception from the network it transforms a .11/LLC header into an EthernetII header; reversely, at sending it transforms an EthernetII header into a .11/LLC header. This is shown in Figure 1. The EAL does not intend to specify a header format. The header formats involved are the IEEE 802.11, LLC and EthernetII. The fields in these headers are specified by IEEE. [KS]: I don't understand why the EAL is relevant to "Transmission of = IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context = of a Basic Service Set". If I want to write software that sends IPv6 packets = over 802.11 OCB, all I need to know is how to construct the LLC sublayer = header, etc. The EAL sounds like a "bridge", and perhaps belongs in a separate document (and perhaps has already been addressed in some existing = document?) Regardless, including a description of the EAL does not violate anything = in 1609.3, as it is out of scope with 1609.3.=20 Some *new comments* from my side: - ipwave 4.2.1 it states "An 'adaptation' layer is inserted between a = MAC layer and the Networking layer." This sounds like a requirement. If I am developing a product that is only concerned with sending IPv6 over OCB, = and does not require "bridging", then how do I reconcile this requirement? - ipwave 4.2 it states "IP packets are transmitted over 802.11-OCB as standard Ethernet packets. As with all 802.11 frames, an Ethernet = adaptation layer MUST be used with 802.11-OCB as well." Again EAL is stipulated as = a requirement. And I'm not sure about the stipulation that packets are transmitted as "standard Ethernet packets", is this accurate? Does this = mean that 802.3 headers are included? This is definitely not stipulated in 1609.3. Packets transmitted over OCB by a WAVE device using 1609.3 are = well formed IPv6 packets, but not "Ethernet packets", i.e., no 802.3 headers = are included. This seems like an interoperability problem between ipwave and 1609 WAVE. > 2. It is not clear that ipwave provides any functionality that > 1609 WAVE does not already provide. Well, 1609 WAVE does not specify the conversion between .11/LLC headers = and EthernetII headers, right? [KS]: Correct it does not, as this topic is out of scope for 1609 WAVE (e.g., we don't specify the other interfaces such as Ethernet that may = be present in the device). Also see my comments above regarding the EAL. 1609 WAVE does not specify the MTU size for IPv6, right? [KS]: No it does not. 802.11 (normative to 1609) specifies maximum MSDU = size as 2304 octets. For WSMP 1609.3 specifies a maximum MSDU size of 2302 (allowing for the 2-octet LLC header), and a default value of 1400. You = are correct in that a MSDU size for IPv6 is not specified explicitly, but I don't know if some other RFCs related to IPv6 over 802.11 already do = that? Regardless, stipulating a default value of 1500 for MTU size does not violate anything in 1609.3. 1609 WAVE does not specify that IPv6 must be preceded by .11 QoSData = (not just .11 Data), and BACKGROUND, right? [KS]: Certainly 1609 does not. 1609 only restricts IPv6 packets to the = SCH (they are not allowed on the CCH). 802.11 specifies defaults for all UP = and AC parameters, indicates which frame types are allowed, etc. But as far = as I can tell the stipulation that IPv6 use QoSData and AC_BK is new and something that ipwave introduces? Again, I'm not an expert on this topic = and I believe others in the 1609 WG have been discussing this with the = ipwave list. Regardless, this additional restriction does not violate 1609.3. 1609 WAVE does not recommend in particular RFC8064 to form semantically opaque Interface Identifiers, right? [KS]: 1609 does not recommend anything like this, but on the other hand = 1609 does not prohibit it either. 1609 does not generally speaking = "recommend", rather it "specifies" and leaves all else up to the system designer/implementer/deployer. And as mentioned previously, 1609 allows = any and all IETF protocols to be implemented. Regardless, this = recommendation does not violate anything in 1609.3. (and a few others). > 1609 WAVE includes a number of mechanisms that enable IPv6 networks to = > be configured. In addition to the WSA/WRA mechanism, 1609.3 allows any = > IETF protocols to be implemented, e.g., IETF RFC 4861, Neighbor=20 > Discovery for IP Version 6 (IPv6) (which is listed as a normative=20 > reference in 1609.3). Helpful would be some example use-cases that=20 > illustrate problems to be solved, and how ipwave will solve those=20 > problems (i.e., that 1609 WAVE does not already solve). There is a draft that describes some use-cases of IPv6 in vehicular networks: draft-ietf-ipwave-vehicular-networking-02 [KS]: Thanks for pointing me to that, lots of info there! I'll spend = some time reviewing that when I can. I think some parts of 1609 WAVE, in particular WRA, are not used in = Europe. Whereas this IPv6-over-OCB draft is used the same wherever Internet is present (Europe, America, Continents). [KS]: 1609 went to great lengths to harmonize WSM and WSA frame formats = with ISO/ETSI standards, these harmonized frames are included in all of the = -2016 revisions to 1609. So for example the 1609.3 WSA is interoperable with = the service advertisement used in Europe. See ISO 16460, and see also ETSI = TS 102 890-1. > My concern is that the IETF ipwave document may cause significant=20 > confusion among deployers, and possibly lead to a lack of=20 > interoperability. Thank you for the opportunity to comment, I look=20 > forward to the discussion. I would like to help with clarification. Let us discuss this. [KS]: Sounds good!=20 Alex >=20 >=20 >=20 > Best regards, >=20 > Kevin _______________________________________________ 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_004E_01D3C029.1CDE28F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipwave] FW: ipwave - comments and concerns - 1609 WAVE, EPD = - towards resolution

If ipwave is = intended to be interoperable with 1609 WAVE,  then ipwave must = specify the use of EtherType Protocol = Discrimination  (EPD) in the LLC sublayer header, i.e., EPD is = mandatory.

If = interoperable with 1609 or not, EPD is mandatory in the 5.9 GHz band.


… the 802.11 header MUST be set to binary 001 = (i.e.

> User = Priority 'Background', QoS Access Category = 'AC_BK').

"MUST" be AC_BK is too = restrictive.  It should be left to be set according to = the application.

- ipwave = 4.2.1 it states "An 'adaptation' layer is inserted between a MAC = layer and the Networking layer." This sounds like a requirement. If = I am developing a product that is only concerned with sending IPv6 over = OCB, and does not require "bridging", then how do I reconcile = this requirement?

If my = recollection is correct, the original document stated = "IPv6 = over the data link layer;   DL =3D LLC + = MAC.

General:

Since the first = draft of the IPWAVE it was made clear the 1609 WAVE was out of = scope.

Fygs

-----Original = Message-----
From: its <its-bounces@ietf.org> On Behalf Of Kevin Smith
Sent: Friday, March 16, 2018 1:35 PM
To: Alexandre PETRESCU <alexandre.petrescu@cea.fr>
Cc: 'Tijink Jasja' <Jasja.Tijink@kapsch.net>; its@ietf.org
Subject: [ipwave] FW: ipwave - comments and concerns - 1609 WAVE, EPD - = towards resolution

Hi = Alex,

Thanks for the = feedback. I have a few comments - but please keep in mind that these = comments and opinions are my own and not necessarily those of = the

1609 WG at = large. I do not have the authority for speak for the WG, I'm just the = editor. ;)

My comments are = inline denoted by [KS]. And please also seem some *new

comments* below = regarding EAL and "standard Ethernet = packets".

Best = regards,

Kevin

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

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

Sent: Thursday, = March 15, 2018 11:23 AM

To: Kevin Smith = <kevin.s.smith@cox.net>

Cc: Tijink = Jasja <Jasja.Tijink@kapsch.net>; its@ietf.org

Subject: Re: = [ipwave] ipwave - comments and concerns - 1609 WAVE, EPD - towards = resolution

Hi = Kevin,

Kevin wrote = recently:

> Dear IETF = ipwave working group,

> =

> =

> =

> My name is = Kevin Smith, I am the technical editor for IEEE Std 1609.3 =

> and a few = others in the 1609 family of standards. I have some concerns =

> regarding = ipwave's interoperability with 1609 WAVE, and a question =

> regarding = the need or purpose for ipwave.

Generally = speaking, the purpose of ipwave WG is set in the = Charter.

(https://datatracker.ietf.org/wg/ipwave/about/)

> = 1.       If ipwave is intended to be = interoperable with 1609 WAVE,

> then = ipwave must specify the use of EtherType Protocol = Discrimination

> (EPD) in = the LLC sublayer header, i.e., EPD is mandatory.

We should = interoperate to a maximum.

[KS]: = Agreed!

I suggest that = in section 4.2.1 "Ethernet Adaptation Layer" we add the = following paragraph:

> The IPv6 = packet transmitted on 802.11-OCB MUST be immediately preceded =

> by a = Logical Link Control (LLC) header and an 802.11 = header.

> In the LLC = header, and in accordance with the EtherType Protocol

> = Discrimination (EPD), the value of the Type field MUST be set to =

> 0x86DD = (IPv6).  In the 802.11 header, the value of the Subtype =

> sub-field = in the Frame Control field MUST be set to 8 (i.e. 'QoS =

> Data'); = the value of the Traffic Identifier (TID) sub-field of the QoS =

> Control = field of the 802.11 header MUST be set to binary 001 = (i.e.

> User = Priority 'Background', QoS Access Category 'AC_BK').

> =

> In the = Ethernet II header, the value of the Type field MUST be set to =

> 0x86DD = (IPv6).

Do you agree = with this text?

[KS]: I agree = with the part that addresses the LLC header. I don't disagree with the = part addressing the 802.11 header, I'm just not an expert in this area = and so defer to others. I believe that others in the 1609 WG have been = discussing this with the ipwave list?

> I note = that ipwave mentions EPD, but also SNAP and does not specify =

> which = method to use.

I propose we = remove this phrase:

> Other = alternative views of layering are EtherType Protocol

> = Discrimination (EPD), see Appendix E, and SNAP see = [RFC1042].

Do you = agree?

[KS]: = Yes.

> Moreover = ipwave discusses an abstract "Ethernet Adaptation = Layer"

> but does = not specify a header format, and this further confuses the =

> question = for deployers - what should we implement?

The Ethernet = Adaptation Layer (more precisely 802.11-to-Ethernet AL) is not so = abstract, because it is widely implemented. This layer does conversion = between headers: at reception from the network it transforms a .11/LLC = header into an EthernetII header; reversely, at sending it transforms an = EthernetII header into a .11/LLC header. This is shown in Figure = 1.

The EAL does = not intend to specify a header format. The header formats involved are = the IEEE 802.11, LLC and EthernetII. The fields in these headers are = specified by IEEE.

[KS]: I don't = understand why the EAL is relevant to "Transmission of IPv6 Packets = over IEEE 802.11 Networks operating in mode Outside the Context of a = Basic Service Set". If I want to write software that sends IPv6 = packets over

802.11 OCB, all = I need to know is how to construct the LLC sublayer header, etc. The EAL = sounds like a "bridge", and perhaps belongs in a separate = document (and perhaps has already been addressed in some existing = document?) Regardless, including a description of the EAL does not = violate anything in 1609.3, as it is out of scope with 1609.3. =

Some *new = comments* from my side:

- ipwave 4.2.1 = it states "An 'adaptation' layer is inserted between a MAC layer = and the Networking layer." This sounds like a requirement. If I am = developing a product that is only concerned with sending IPv6 over OCB, = and does not require "bridging", then how do I reconcile this = requirement?

- ipwave 4.2 it = states "IP packets are transmitted over 802.11-OCB as standard = Ethernet packets. As with all 802.11 frames, an Ethernet adaptation = layer MUST be used with 802.11-OCB as well." Again EAL is = stipulated as a requirement. And I'm not sure about the stipulation that = packets are transmitted as "standard Ethernet packets", is = this accurate? Does this mean that 802.3 headers are included? This is = definitely not stipulated in 1609.3. Packets transmitted over OCB by a = WAVE device using 1609.3 are well formed IPv6 packets, but not = "Ethernet packets", i.e., no 802.3 headers are included. This = seems like an interoperability problem between ipwave = and

1609 = WAVE.

> = 2.       It is not clear that ipwave = provides any functionality that

>  1609 = WAVE does not already provide.

Well, 1609 WAVE = does not specify the conversion between .11/LLC headers and EthernetII = headers, right?

[KS]: Correct = it does not, as this topic is out of scope for 1609 WAVE (e.g., we don't = specify the other interfaces such as Ethernet that may be present in the = device). Also see my comments above regarding the EAL.

1609 WAVE does = not specify the MTU size for IPv6, right?

[KS]: No it = does not. 802.11 (normative to 1609) specifies maximum MSDU size as 2304 = octets. For WSMP 1609.3 specifies a maximum MSDU size of 2302 (allowing = for the 2-octet LLC header), and a default value of 1400. You are = correct in that a MSDU size for IPv6 is not specified explicitly, but I = don't know if some other RFCs related to IPv6 over 802.11 already do = that?

Regardless, = stipulating a default value of 1500 for MTU size does not violate = anything in 1609.3.

1609 WAVE does = not specify that IPv6 must be preceded by .11 QoSData (not just .11 = Data), and BACKGROUND, right?

[KS]: Certainly = 1609 does not. 1609 only restricts IPv6 packets to the SCH (they are not = allowed on the CCH). 802.11 specifies defaults for all UP and AC = parameters, indicates which frame types are allowed, etc. But as far as = I can tell the stipulation that IPv6 use QoSData and AC_BK is new and = something that ipwave introduces? Again, I'm not an expert on this topic = and I believe others in the 1609 WG have been discussing this with the = ipwave list. Regardless, this additional restriction does not violate = 1609.3.

1609 WAVE does = not recommend in particular RFC8064 to form semantically opaque = Interface Identifiers, right?

[KS]: 1609 does = not recommend anything like this, but on the other hand 1609 does not = prohibit it either. 1609 does not generally speaking = "recommend", rather it "specifies" and leaves all = else up to the system designer/implementer/deployer. And as mentioned = previously, 1609 allows any and all IETF protocols to be implemented. = Regardless, this recommendation does not violate anything in = 1609.3.

(and a few = others).

> 1609 WAVE = includes a number of mechanisms that enable IPv6 networks to =

> be = configured. In addition to the WSA/WRA mechanism, 1609.3 allows any =

> IETF = protocols to be implemented, e.g., IETF RFC 4861, Neighbor =

> Discovery = for IP Version 6 (IPv6) (which is listed as a normative =

> reference = in 1609.3). Helpful would be some example use-cases that =

> illustrate = problems to be solved, and how ipwave will solve those =

> problems = (i.e., that 1609 WAVE does not already solve).

There is a = draft that describes some use-cases of IPv6 in = vehicular

networks: = draft-ietf-ipwave-vehicular-networking-02

[KS]: Thanks = for pointing me to that, lots of info there! I'll spend some time = reviewing that when I can.

I think some = parts of 1609 WAVE, in particular WRA, are not used in = Europe.

Whereas this = IPv6-over-OCB draft is used the same wherever Internet is present = (Europe, America, Continents).

[KS]: 1609 went = to great lengths to harmonize WSM and WSA frame formats with ISO/ETSI = standards, these harmonized frames are included in all of the -2016 = revisions to 1609. So for example the 1609.3 WSA is interoperable with = the service advertisement used in Europe. See ISO 16460, and see also = ETSI TS

102 = 890-1.

> My concern = is that the IETF ipwave document may cause significant =

> confusion = among deployers, and possibly lead to a lack of

> = interoperability. Thank you for the opportunity to comment, I look =

> forward to = the discussion.

I would like to = help with clarification. Let us discuss this.

[KS]: Sounds = good!

Alex

> =

> =

> =

> Best = regards,

> =

> = Kevin

_______________________________________________

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_004E_01D3C029.1CDE28F0-- From nobody Tue Mar 20 06:24: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 390E3126DED for ; Tue, 20 Mar 2018 06:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b_QZlIObHLyN for ; Tue, 20 Mar 2018 06:24:19 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7B33124B17 for ; Tue, 20 Mar 2018 06:24:18 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w2KDOEih008021; Tue, 20 Mar 2018 14:24:14 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0F0FA20581A; Tue, 20 Mar 2018 14:24:14 +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 EFC55201767; Tue, 20 Mar 2018 14:24: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 w2KDOD51023510; Tue, 20 Mar 2018 14:24:13 +0100 To: Kevin Smith Cc: "'Tijink Jasja'" , "'Tony Li'" , its@ietf.org References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <011701d3beef$3fc03a60$bf40af20$@cox.net> From: Alexandre Petrescu Message-ID: <29006129-f7f7-1560-c09d-e795905876c3@gmail.com> Date: Tue, 20 Mar 2018 14:24: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: <011701d3beef$3fc03a60$bf40af20$@cox.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] clarification of EAL text X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 13:24:21 -0000 Le 18/03/2018 à 20:28, Kevin Smith a écrit : > Hi Alex, > > I think the NEW proposed text has resolved a few of the issues I've > been concerned about. However the statement "Within an IP-RSU, or > within an IP-OBU, the IP packets are communicated by the IP stack to > and from the 802.11-OCB driver as standard Ethernet II frames." seems > to make some assumptions about implementations. > > As data travels up the layered protocol stack, headers are processed > and stripped off, payloads delivered to the next higher layer. It > seems like an assumption to say that an 802.11-OCB driver will > receive Ethernet II frames. It might instead receive IPv6 packets and > use some mechanism (implementation dependent) to determine that the > packet needs to be routed over 802.11-OCB. > > A system diagram showing typical IP-RSU/IP-OBU communication flow > would be helpful, to identify system architecture assumptions being > made by ipwave. It is in Figure 1, 2 and 4. Alex > > Best, Kevin > > -----Original Message----- From: its [mailto:its-bounces@ietf.org] On > Behalf Of Alexandre Petrescu Sent: Sunday, March 18, 2018 10:27 AM > Cc: Tijink Jasja ; Kevin Smith > ; Tony Li ; its@ietf.org > Subject: Re: [ipwave] clarification of EAL text > > I suggest this clarification of the EAL text. > > OLD: >> IP packets are transmitted over 802.11-OCB as standard Ethernet >> packets. As with all 802.11 frames, an Ethernet adaptation layer >> MUST be used with 802.11-OCB as well." > > NEW: >> Within an IP-RSU, or within an IP-OBU, the IP packets are >> communicated by the IP stack to and from the 802.11-OCB driver as >> standard Ethernet II frames. IP packets MUST be transmitted over >> 802.11-OCB media as QoS Data frames whose format is specified in >> IEEE Std 802.11. >> >> Before sending the IP packets on the 802.11 media, and after >> receiving packets from the 802.11 media, the use of an adaptation >> layer that adapts between the frame formats of 802.11 and of >> Ethernet II is RECOMMENDED. The Ethernet II headers MUST NOT be >> transmitted on 802.11 media. > > Alex > > > Le 17/03/2018 à 13:50, Tony Li a écrit : >> >>> on the EAL topic. Take again the following text from the draft: >>> >>> " IP packets are transmitted over 802.11-OCB as standard >>> Ethernet packets. As with all 802.11 frames, an Ethernet >>> adaptation layer MUST be used with 802.11-OCB as well." >>> >>> I understand the second sentence is a requirement you put to >>> implementations that feature an ethernet interface and an 802.11 >>> interface. >> >> >> I suspect that we’ll also get some push back on this sentence >> because it is implied to be normative. Since the EAL doesn’t >> actually affect the bits on the air, this is simply an >> implementation choice and not strictly mandatory. >> >> It would probably be easier if we relaxed the wording to make this >> informative or recommended instead. >> >> Tony >> >> > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > > From nobody Tue Mar 20 06:37: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 37DC21270AE for ; Tue, 20 Mar 2018 06:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRonaq57lHA2 for ; Tue, 20 Mar 2018 06:37:49 -0700 (PDT) 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 B8EDA126DED for ; Tue, 20 Mar 2018 06:37:48 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id n11so1274164qti.4 for ; Tue, 20 Mar 2018 06:37:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=vNQ/wUkWswGSxGfKf3y+rXbGyMC0ltfy/VxWdrHVpe4=; b=ZNadGjz3s2LzjPkMXPRgQ2r1WBMPq7YvKOBlkT+9QAPsgW7wsZE6QKfIi0dzPXi/Va Pgmq2eurDA9LN0rDrwy6B9rnxfT9ec89Vg3en57pfl5A/kNloQjPKmIZfOIa24BKz64y O+YI5fHJ8tApLbZvi4LMgGr+IY98mPXsBQWAEoLDmrSi8Wq/1kHYNb3a7QfVrTx/3iwW iqMf1wxHpHeCc2JhrVfP8X0SV6SOFB79hadHnwTVulqf96UoWpZ4IIpIR1EmsUW1+PHs s7g8YysAdfcILaRVhcYIMmM3pY0BnUwjYu9JRB3OW62vkwkfNz+v7lFChoWH6VzSFKho PoiA== 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=vNQ/wUkWswGSxGfKf3y+rXbGyMC0ltfy/VxWdrHVpe4=; b=Uua4cCKfsJJkky9iPyrFQNsv6QkjOsq1+xNkRT5cGwG1M1T/VoOJV/wjcTfx4i0xG9 yTw7TDVsIMc+3/HYdz1m16NqoWpcS0qgQ777joaiSe/cZW2h8VTkoeOKeKQhnZli4ir4 ZacbsaAzHqtEL5Wx4L/k0bHdJWyYvqQW+q+MZp498YUii5jxrxQ51MDGdxR2mu2idpmE DcywEZujDsFUo87gt9owinB4DdVYTzKa8Y5jBSv+JTfNxJlj/lDsL/Q/HkGn7JX427HK 5FpTlL1Y4HeOCEFGKcFZE7XeIGOaasKGCQ3MFMphvCnVLrEkrlCQmG3DcnEFlsWeQLLu oUcQ== X-Gm-Message-State: AElRT7GBH6a7io3mpAQNj9+oQKUOfpRgMA1K6RNKbs+BKIS0+R4pzHb+ 0l9vixHinwo6okyM1gRoDaY= X-Google-Smtp-Source: AG47ELuq1CM4qhVgPxj0ee56Sg5wTAV2PfMiYpxTZ1I0sip8v3o2yz3ptEX55Y7DCY4Nj9viA+0KKQ== X-Received: by 10.237.52.162 with SMTP id x31mr23639600qtd.19.1521553067838; Tue, 20 Mar 2018 06:37:47 -0700 (PDT) Received: from FrancoisPC (50-253-61-187-static.hfc.comcastbusiness.net. [50.253.61.187]) by smtp.gmail.com with ESMTPSA id i63sm1161974qtb.96.2018.03.20.06.37.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Mar 2018 06:37:47 -0700 (PDT) From: =?utf-8?Q?Fran=C3=A7ois_Simon?= To: "'Tijink Jasja'" , "'Alexandre Petrescu'" Cc: "'Kevin Smith'" , References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> In-Reply-To: Date: Tue, 20 Mar 2018 09:37:44 -0400 Message-ID: <009201d3c050$a2202a50$e6607ef0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0093_01D3C02F.1B10FB50" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGhOrR8o8b5YryKQCC/S9k90bJ5fwGaWEJkAVayqmAC0zYUGgHJZZEvpAG7M7A= Content-Language: en-us Archived-At: Subject: Re: [ipwave] ipwave - comments and concerns - 1609 WAVE, EPD - 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, 20 Mar 2018 13:37:51 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0093_01D3C02F.1B10FB50 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable This document is a profile based on IEEE 1609.3: it introduces = additional requirements and specifications that do not violate that base = standard. Absolutely NOT. This IPWAVE document is NOT a profile of IEEE 1609.3. = Framework and Taxonomy of International Standardized Profiles (somewhat = paraphrased): A profile identifies a set of base standards, together = with appropriate options and parameters necessary to accomplish = identified functions for purposes including: (a) interoperability, and = (b) methodology for referencing the various uses of the base standards, = meaningful both to users and suppliers. ISO TR 10000 Fygs -----Original Message----- From: its On Behalf Of Tijink Jasja Sent: Saturday, March 17, 2018 8:23 AM To: Alexandre Petrescu Cc: Kevin Smith ; its@ietf.org Subject: Re: [ipwave] ipwave - comments and concerns - 1609 WAVE, EPD - = towards resolution Hello Alex, Can we put something at the beginning of = draft-ietf-ipwave-ipv6-over-80211ocb-21, maybe in the introduction? I suggest some language like the following: This document is a profile based on IEEE 1609.3: it introduces = additional requirements and specifications that do not violate that base = standard. Regards Jasja -----Urspr=C3=BCngliche Nachricht----- Von: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] Gesendet: Samstag, 17. M=C3=A4rz 2018 12:23 An: Tijink Jasja > Cc: Kevin Smith >; = its@ietf.org =20 Betreff: Re: [ipwave] ipwave - comments and concerns - 1609 WAVE, EPD - = towards resolution Hello Jasja, Le 16/03/2018 =C3=A0 19:02, Tijink Jasja a =C3=A9crit : > Hello Alex, >=20 > in addition to Kevin's points, I would like to mention that: >=20 > 1. I welcome your proposal for the additional text that specifies QoS. = > This is necessary for operation in Europe (the specification for the=20 > access layer can be found in ETSI EN 302 663, where clause 4.6 says=20 > that QoS shall be used). Noted. > 2. My understanding of the discussion below is that > draft-ietf-ipwave-ipv6-over-80211ocb-21 is "based on" IEEE 1609.3 in=20 > that it is compliant with it (I didn't find any "violation of IEEE=20 > 1609.3), and adds additional restrictions and /or specifications (such = > a MTU size, AC_BK, RFC8064, etc.). In that sense > draft-ietf-ipwave-ipv6-over-80211ocb-21 is a profile of IEEE 1609.3. > I would suggest making that very clear, with a short=20 > sentence/paragraph in draft-ietf-ipwave-ipv6-over-80211ocb-21 that=20 > explains it to the reader. If you disagree, I would like to hear your=20 > view on the relation of IEEE 1609.3 and=20 > draft-ietf-ipwave-ipv6-over-80211ocb-21. I dont really disagree, just where to put it. The draft does refer to 1609.3, in Appendix C "aspects introduced by OCB = to 802.11". The vehicular networking draft (draft-ietf-ipwave-vehicular-networking-01) also refers to it right at = the beginning. IPv6-over-OCB sounds like an explanation. As such, I suggest we first = write more precisely that "IPv6-over-OCB is a profile of 1609.3" and = then put it into the vehicular networking draft. How could that be written? Alex _______________________________________________ its mailing list its@ietf.org =20 https://www.ietf.org/mailman/listinfo/its ------=_NextPart_000_0093_01D3C02F.1B10FB50 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable RE: [ipwave] ipwave - comments and concerns - 1609 WAVE, EPD - = towards resolution

This = document is a profile based on IEEE 1609.3: it introduces additional = requirements and specifications that do not violate that base = standard.

Absolutely NOT. This IPWAVE document is NOT a profile = of IEEE 1609.3. Framework and Taxonomy of International Standardized = Profiles = (somewhat paraphrased):  A profile identifies a set of base standards, together = with appropriate options and parameters necessary to accomplish = identified functions for purposes including: (a) interoperability, and = (b) methodology for referencing the various uses of the base standards, = meaningful both to users and suppliers. ISO TR 10000

Fygs

-----Original = Message-----
From: its <its-bounces@ietf.org> On Behalf Of Tijink Jasja
Sent: Saturday, March 17, 2018 8:23 AM
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Cc: Kevin Smith <kevin.s.smith@cox.net>; its@ietf.org
Subject: Re: [ipwave] ipwave - comments and concerns - 1609 WAVE, EPD - = towards resolution

Hello = Alex,

Can we put = something at the beginning of draft-ietf-ipwave-ipv6-over-80211ocb-21, = maybe in the introduction?

I suggest some = language like the following:

This document = is a profile based on IEEE 1609.3: it introduces additional requirements = and specifications that do not violate that base = standard.

Regards = Jasja


-----Urspr=C3=BCngliche = Nachricht-----

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

Gesendet: = Samstag, 17. M=C3=A4rz 2018 12:23

An: Tijink = Jasja <Jasja.Tijink@kapsch.net>

Cc: Kevin Smith = <kevin.s.smith@cox.net>; its@ietf.org

Betreff: Re: = [ipwave] ipwave - comments and concerns - 1609 WAVE, EPD - towards = resolution

Hello = Jasja,

Le 16/03/2018 = =C3=A0 19:02, Tijink Jasja a =C3=A9crit :

> Hello = Alex,

> =

> in = addition to Kevin's points, I  would like to mention = that:

> =

> 1. I = welcome your proposal for the additional text that specifies QoS. =

> This is = necessary for operation in Europe (the specification for the =

> access = layer can be found in ETSI EN 302 663, where clause 4.6 says =

> that QoS = shall be used).

Noted.

> 2. My = understanding of the discussion below is that

> = draft-ietf-ipwave-ipv6-over-80211ocb-21 is "based on" IEEE = 1609.3 in

> that it is = compliant with it (I didn't find any "violation of IEEE =

> 1609.3), = and adds additional restrictions and /or specifications (such =

> a MTU = size, AC_BK, RFC8064, etc.). In that sense

> = draft-ietf-ipwave-ipv6-over-80211ocb-21 is a profile of IEEE = 1609.3.

>  I = would suggest making that very clear, with a short

> = sentence/paragraph in draft-ietf-ipwave-ipv6-over-80211ocb-21 that =

> explains = it to the reader. If you disagree, I would like to hear your =

> view on = the relation of IEEE 1609.3 and

> = draft-ietf-ipwave-ipv6-over-80211ocb-21.

I dont really = disagree, just where to put it.

The draft does = refer to 1609.3, in Appendix C "aspects introduced by OCB to = 802.11".  The vehicular networking draft

(draft-ietf-ipwave-vehicular-networking-01) also refers = to it right at the beginning.

IPv6-over-OCB = sounds like an explanation.  As such, I suggest we first write more = precisely that "IPv6-over-OCB is a profile of 1609.3" and then = put it into the vehicular networking draft.

How could that = be written?

Alex

_______________________________________________

its mailing = list

its@ietf.org

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

------=_NextPart_000_0093_01D3C02F.1B10FB50-- From nobody Tue Mar 20 06:54: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 D3C0C12FA80 for ; Tue, 20 Mar 2018 06:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stizGeLpN3sp for ; Tue, 20 Mar 2018 06:54:48 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7737612ECBF for ; Tue, 20 Mar 2018 06:54:19 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id g184so1670145qkd.10 for ; Tue, 20 Mar 2018 06:54:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=y32H4jHykLZr5E38fByfVN0Zxgiy2ulN5OLyTQgW/U0=; b=ZAM5orgdUivRp2FiZRrMhI9Yoc4HM+Ws3CBJ84BK7+bIfaEDl1Hzv0Jy75Zix21amb EqMlQQseFHEwMxd5NABKa+fks/ZC2JJ4aZHAqZUy9ODEOeaKZR6O25Y3w7s//FOWO6ET 1KofIQmUERmcvuDVgEzk+OeQc6crrUKfVkLUAc3SEjdgiPfBinFamrGwlPvRSxuw6dFQ 6ZyjoHQHmw6zr1ghFskoBHtCp9FAkrtC3NlvWojX+j3l1e6krULCqrBWtdLEFquhiYA6 hKHEOa6fplObiX02BWo8ywErCBcxzEQ408F48ERvwEP/wkB1sKrp8YoOJVLvinhcNZiZ 1wVw== 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=y32H4jHykLZr5E38fByfVN0Zxgiy2ulN5OLyTQgW/U0=; b=IgqjV7OeJIkfiI6vnpd0YZYqMOLpzf2TkKq6qsvh8plxgOaNDlSCts1grPBvWPUMf0 5z6wRj3pFU3euzkF9gFU5xzhCCsK1+u4/eNk+T9vSFCjpuKkr8WBHN2ebGRtuYuZ6PED ThwICh/z+F+9es0NKbIKTtmkr6sbOgNV0SKgisunPy0A5/VCAR45I/m4rxbqFEgHr4KR CN3CcpVobD+2WPYGRI6/8RhUI9ckKfzstBp0yIiIIqFpnDG4vK9odPq2ZeWEuDLO8ZMT nPPGxENsZegexJmpaOU77ltDCClWV7m2/tQUHf0RndNEf2pmEYwEZTPeD5EUNtIlXdH6 LYXw== X-Gm-Message-State: AElRT7HPSQtKNBXeNDaUKSDog+CaP40S2JoOIT6RhbNQGtUb0CcIIGYD KCBmilzb9MDDHNCO6C81sYs= X-Google-Smtp-Source: AG47ELtBlgehTtS4WJocMoKjwz/NVBqO7YbHhK6f1r4jqHg7Zys7p98AwsmRuUe66ldrz+jXCPBK2A== X-Received: by 10.55.33.2 with SMTP id h2mr22395008qkh.310.1521554058620; Tue, 20 Mar 2018 06:54:18 -0700 (PDT) Received: from FrancoisPC (50-253-61-187-static.hfc.comcastbusiness.net. [50.253.61.187]) by smtp.gmail.com with ESMTPSA id q184sm1718197qkf.79.2018.03.20.06.54.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Mar 2018 06:54:17 -0700 (PDT) From: =?utf-8?Q?Fran=C3=A7ois_Simon?= To: "'Alexandre Petrescu'" , Cc: "'Tijink Jasja'" , "'Kevin Smith'" References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <5cc6bd32-0812-288a-2db0-b0de53626f1e@gmail.com> In-Reply-To: <5cc6bd32-0812-288a-2db0-b0de53626f1e@gmail.com> Date: Tue, 20 Mar 2018 09:54:17 -0400 Message-ID: <009c01d3c052$f0a78cc0$d1f6a640$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009D_01D3C031.69985DC0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGhOrR8o8b5YryKQCC/S9k90bJ5fwGaWEJkAVayqmAC0zYUGgHJZZEvAaEIiFCj9LmCIA== Content-Language: en-us Archived-At: Subject: Re: [ipwave] =?utf-8?q?=5Bipwave=C3=AE=5D_IPv6-over-OCB_as_a_profile?= =?utf-8?q?_of_1609_WAVE?= X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 13:54:54 -0000 This is a multipart message in MIME format. ------=_NextPart_000_009D_01D3C031.69985DC0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable This document is a profile based on IEEE 1609.3: it introduces = additional requirements and specifications that do not violate that = base standard. For my part I find addition of this text neutral and ok, although I am = not sure what is a profile for 1609 WAVE. In Bluetooth, a 'profile' is = something very much precise, like 'LAN profile', etc. I am NOT ok with it: 1) - I did not think that IEEE 1609 Series was in scope of the document; 2) - OCB is NOT a profile of 1609 WAVE. See previously sent definition. Fygs -----Original Message----- From: its On Behalf Of Alexandre Petrescu Sent: Sunday, March 18, 2018 12:16 PM To: its@ietf.org Cc: Tijink Jasja ; Kevin Smith = Subject: Re: [ipwave] [ipwave=C3=AE] IPv6-over-OCB as a profile of 1609 = WAVE Hi IPWAVErs, Do you disagree we add this phrase in the Introduction: > This document is a profile based on IEEE 1609.3: it introduces=20 > additional requirements and specifications that do not violate that=20 > base standard. For my part I find addition of this text neutral and ok, although I am = not sure what is a profile for 1609 WAVE. In Bluetooth, a 'profile' is = something very much precise, like 'LAN profile', etc. Alex Le 17/03/2018 =C3=A0 13:22, Tijink Jasja a =C3=A9crit : > Hello Alex, >=20 > Can we put something at the beginning of=20 > draft-ietf-ipwave-ipv6-over-80211ocb-21, maybe in the introduction? > I suggest some language like the following: >=20 > This document is a profile based on IEEE 1609.3: it introduces=20 > additional requirements and specifications that do not violate that=20 > base standard. >=20 > Regards Jasja >=20 >=20 > -----Urspr=C3=BCngliche Nachricht----- Von: Alexandre Petrescu=20 > [mailto:alexandre.petrescu@gmail.com] Gesendet: Samstag, 17. M=C3=A4rz > 2018 12:23 An: Tijink Jasja > Cc: Kevin Smith=20 > >; its@ietf.org = Betreff: Re: [ipwave] ipwave -=20 > comments and concerns - 1609 WAVE, EPD - towards resolution >=20 > Hello Jasja, >=20 > Le 16/03/2018 =C3=A0 19:02, Tijink Jasja a =C3=A9crit : >> Hello Alex, >>=20 >> in addition to Kevin's points, I would like to mention that: >>=20 >> 1. I welcome your proposal for the additional text that specifies=20 >> QoS. This is necessary for operation in Europe (the specification for = >> the access layer can be found in ETSI EN 302 663, where clause >> 4.6 says that QoS shall be used). >=20 > Noted. >=20 >> 2. My understanding of the discussion below is that >> draft-ietf-ipwave-ipv6-over-80211ocb-21 is "based on" IEEE 1609.3 in=20 >> that it is compliant with it (I didn't find any "violation of IEEE=20 >> 1609.3), and adds additional restrictions and /or specifications=20 >> (such a MTU size, AC_BK, RFC8064, etc.). In that sense=20 >> draft-ietf-ipwave-ipv6-over-80211ocb-21 is a profile of IEEE 1609.3.=20 >> I would suggest making that very clear, with a short=20 >> sentence/paragraph in draft-ietf-ipwave-ipv6-over-80211ocb-21 that =20 >> explains it to the reader. If you disagree, I would like to hear your = >> view on the relation of IEEE 1609.3 and=20 >> draft-ietf-ipwave-ipv6-over-80211ocb-21. >=20 > I dont really disagree, just where to put it. >=20 > The draft does refer to 1609.3, in Appendix C "aspects introduced by=20 > OCB to 802.11". The vehicular networking draft > (draft-ietf-ipwave-vehicular-networking-01) also refers to it right at = > the beginning. >=20 > IPv6-over-OCB sounds like an explanation. As such, I suggest we first = > write more precisely that "IPv6-over-OCB is a profile of 1609.3" and=20 > then put it into the vehicular networking draft. >=20 > How could that be written? >=20 > Alex >=20 _______________________________________________ its mailing list its@ietf.org =20 https://www.ietf.org/mailman/listinfo/its ------=_NextPart_000_009D_01D3C031.69985DC0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable RE: [ipwave] [ipwave=C3=AE] IPv6-over-OCB as a profile of 1609 = WAVE

This = document is a profile based on IEEE 1609.3: it introduces additional = requirements and specifications that do not violate that  base = standard.

For my part = I find addition of this text neutral and ok, although I am not sure what = is a profile for 1609 WAVE.  In Bluetooth, a 'profile' is something = very much precise, like 'LAN profile', etc.

I am NOT ok = with it:

1) - I did not = think that IEEE 1609 Series was in scope of the = document;

2) - OCB is NOT a profile of 1609 WAVE.  See = previously sent definition.

Fygs

-----Original = Message-----
From: its <its-bounces@ietf.org> On Behalf Of Alexandre = Petrescu
Sent: Sunday, March 18, 2018 12:16 PM
To: its@ietf.org
Cc: Tijink Jasja <Jasja.Tijink@kapsch.net>; Kevin Smith = <kevin.s.smith@cox.net>
Subject: Re: [ipwave] [ipwave=C3=AE] IPv6-over-OCB as a profile of 1609 = WAVE

Hi = IPWAVErs,

Do you disagree = we add this phrase in the Introduction:

> This = document is a profile based on IEEE 1609.3: it introduces =

> additional = requirements and specifications that do not violate that =

> base = standard.

For my part I = find addition of this text neutral and ok, although I am not sure what = is a profile for 1609 WAVE.  In Bluetooth, a 'profile' is something = very much precise, like 'LAN profile', etc.

Alex


Le 17/03/2018 = =C3=A0 13:22, Tijink Jasja a =C3=A9crit :

> Hello = Alex,

> =

> Can we put = something at the beginning of

> = draft-ietf-ipwave-ipv6-over-80211ocb-21, maybe in the = introduction?

> I suggest = some language like the following:

> =

> This = document is a profile based on IEEE 1609.3: it introduces =

> additional = requirements and specifications that do not violate that =

> base = standard.

> =

> Regards = Jasja

> =

> =

> = -----Urspr=C3=BCngliche Nachricht----- Von: Alexandre Petrescu =

> = [mailto:alexandre.petrescu@gmail.com] = Gesendet: Samstag, 17. M=C3=A4rz

> 2018 12:23 = An: Tijink Jasja <Jasja.Tijink@kapsch.net> Cc: Kevin Smith

> = <kevin.s.smith@cox.net>; its@ietf.org = Betreff: Re: [ipwave] ipwave -

> comments = and concerns - 1609 WAVE, EPD - towards resolution

> =

> Hello = Jasja,

> =

> Le = 16/03/2018 =C3=A0 19:02, Tijink Jasja a =C3=A9crit :

>> Hello = Alex,

>> =

>> in = addition to Kevin's points, I  would like to mention = that:

>> =

>> 1. I = welcome your proposal for the additional text that specifies =

>> QoS. = This is necessary for operation in Europe (the specification for =

>> the = access layer can be found in ETSI EN 302 663, where = clause

>> 4.6 = says that QoS shall be used).

> =

> = Noted.

> =

>> 2. My = understanding of the discussion below is that

>> = draft-ietf-ipwave-ipv6-over-80211ocb-21 is "based on" IEEE = 1609.3 in

>> that = it is compliant with it (I didn't find any "violation of IEEE =

>> = 1609.3), and adds additional restrictions and /or specifications =

>> (such = a MTU size, AC_BK, RFC8064, etc.). In that sense

>> = draft-ietf-ipwave-ipv6-over-80211ocb-21 is a profile of IEEE 1609.3. =

>> I = would suggest making that very clear, with a short

>> = sentence/paragraph in draft-ietf-ipwave-ipv6-over-80211ocb-21 that  =

>> = explains it to the reader. If you disagree, I would like to hear your =

>> view = on the relation of IEEE 1609.3 and

>> = draft-ietf-ipwave-ipv6-over-80211ocb-21.

> =

> I dont = really disagree, just where to put it.

> =

> The draft = does refer to 1609.3, in Appendix C "aspects introduced by =

> OCB to = 802.11".  The vehicular networking draft

> = (draft-ietf-ipwave-vehicular-networking-01) also refers to it right at =

> the = beginning.

> =

> = IPv6-over-OCB sounds like an explanation.  As such, I suggest we = first

> write more = precisely that "IPv6-over-OCB is a profile of 1609.3" and =

> then put = it into the vehicular networking draft.

> =

> How could = that be written?

> =

> = Alex

> =

_______________________________________________

its mailing = list

its@ietf.org

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

------=_NextPart_000_009D_01D3C031.69985DC0-- From nobody Tue Mar 20 06:59: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 E7FCD1270AE for ; Tue, 20 Mar 2018 06:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KgUE2LISTEtn for ; Tue, 20 Mar 2018 06:59:11 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84520127076 for ; Tue, 20 Mar 2018 06:59:11 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id o184so1686003qkd.13 for ; Tue, 20 Mar 2018 06:59:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=W94bp1LmexvgZv7vAqH/SN86kKVEmx3AtEf1TayosjM=; b=ZxuI3/vByQI1h8uWcpnnHpsxVGpkFd8TiNuBABglTj1rXVID+otSzbQN99/Ae2wDjJ ZqLld1prAsjd7/y3D6XWQtoB8SYf+qgNPhvvEydb54II/GuxAzMYbl4AaqPE8g2qtm4a jjrcXjd6JDDOpO9OQ8oE1GvNniAd3Bh8/seDybvFadS+5evCJJVDqUJ5xFxFqVYGgT5k +9Ftguwcp+iNod/sDZVforDZ1zckwVS4xy7ASuD8eyc5AsjkIxG2UXTnSLGbMf0Kvpx1 PFwbV+tvABDnaSmDWZTKiXuGmWkh8tqbQeljh12kgi4X8hnXuhCUBgTnSZiurOgOaJ0b IVzQ== 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=W94bp1LmexvgZv7vAqH/SN86kKVEmx3AtEf1TayosjM=; b=UJkzGPtAWp2e+v7tgSUyaNpyv0adnysCtTbqaJK+YkzGKOBt2UfHHcG0zWQ3G4MIzs LNPDrsihHr83J8Ing9wllRo4ZWGq3gaM6zPcCO8b48tdqlAQoUa1PCgB9VQ528d53i5z /V4OEzYSlLhweTXaeG+UBjLsYFN+Ak+1I6FSleEFweXHSrFzOvFOnf6rq2O5waLQ+mct V+NeKLVrmoPoQIiiNMOKMibnoQeRoOtK5YXvpfSVNp3CVFFAlSAj6qlVEk7CuMQsXzT1 IEjtIQTwjdnKynYM4Jx6eRbNUcrilI18DVvmRx7yxishcpWgfvbiCnjcD9Z63L5ptzJ4 1UmA== X-Gm-Message-State: AElRT7FoJMWNMbVkvNjmyz9K31NrrNKljVYdjYL6Ir+UuOH2gzEKfDnG ukzjPwK0rlbJ7CUIviqdyrk= X-Google-Smtp-Source: AG47ELuUg3x05JUx83nwriDyf13mjYkGcIMvkxd4b7MaaCyTjfvJC99ckl1K/MnAjxB+8UR3DAsNLw== X-Received: by 10.55.107.70 with SMTP id g67mr23671618qkc.105.1521554350608; Tue, 20 Mar 2018 06:59:10 -0700 (PDT) Received: from FrancoisPC (50-253-61-187-static.hfc.comcastbusiness.net. [50.253.61.187]) by smtp.gmail.com with ESMTPSA id 1sm1233590qtr.85.2018.03.20.06.59.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Mar 2018 06:59:09 -0700 (PDT) From: =?utf-8?Q?Fran=C3=A7ois_Simon?= To: "'Tijink Jasja'" , "'Jerome Haerri'" , "'Alexandre Petrescu'" Cc: "'Kevin Smith'" , References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <5cc6bd32-0812-288a-2db0-b0de53626f1e@gmail.com> In-Reply-To: Date: Tue, 20 Mar 2018 09:59:09 -0400 Message-ID: <000701d3c053$9e9e9d50$dbdbd7f0$@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: AQGhOrR8o8b5YryKQCC/S9k90bJ5fwGaWEJkAVayqmAC0zYUGgHJZZEvAaEIiFAAcwBKmQJCGZTJo98TKLA= Content-Language: en-us Archived-At: Subject: Re: [ipwave] =?utf-8?q?=5Bipwave=C3=AE=5D_IPv6-over-OCB_as_a_profile?= =?utf-8?q?_of_1609_WAVE?= X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 13:59:14 -0000 See ISO TR 10000 standard for profile definition. BTW: I thought that = 1609 is out of scope. Fygs -----Original Message----- From: its On Behalf Of Tijink Jasja Sent: Sunday, March 18, 2018 12:45 PM To: Jerome Haerri ; Alexandre Petrescu = Cc: Kevin Smith ; its@ietf.org Subject: Re: [ipwave] [ipwave=C3=AE] IPv6-over-OCB as a profile of 1609 = WAVE Hello Jerome, i am not sure that I understand your reasons. First of all I am not sure why you state "alternative operation without = relying on WSM". In which way 1609.3's IP mode relies on WSM? Secondly, just to make an example IEEE 1609.2 (WAVE security standard) = is used in Europe since ETSI TS 103 097 makes a profile out of it. Anyhow, even if you don't like the sentence can your answer our original = question: what functionality does the draft provide that 1609 WAVE does = not already provide (except for the EAL aspect, which seems more an = implementation requirement)? Regards Jasja -----Urspr=C3=BCngliche Nachricht----- Von: its [mailto:its-bounces@ietf.org] Im Auftrag von Jerome Haerri Gesendet: Sonntag, 18. M=C3=A4rz 2018 17:24 An: Alexandre Petrescu Cc: Tijink Jasja ; Kevin Smith = ; its@ietf.org Betreff: Re: [ipwave] [ipwave=C3=AE] IPv6-over-OCB as a profile of 1609 = WAVE Dear All, I disagree for two reasons:=20 First this is not a profile, but an alternative operation of IP without = relying on WSM. Second, this document will also apply outside of the US, and then IEEE = 1609.3 does not apply and thus would make this document confusing. Best Regards, J=C3=A9r=C3=B4me Envoy=C3=A9 de mon iPhone > Le 18 mars 2018 =C3=A0 16:15, Alexandre Petrescu = a =C3=A9crit : >=20 > Hi IPWAVErs, >=20 > Do you disagree we add this phrase in the Introduction: >=20 >> This document is a profile based on IEEE 1609.3: it introduces = additional requirements and specifications that do not violate that base = standard. >=20 > For my part I find addition of this text neutral and ok, although I am = > not sure what is a profile for 1609 WAVE. In Bluetooth, a 'profile' > is something very much precise, like 'LAN profile', etc. >=20 > Alex >=20 >=20 >> Le 17/03/2018 =C3=A0 13:22, Tijink Jasja a =C3=A9crit : >> Hello Alex, >> Can we put something at the beginning of = draft-ietf-ipwave-ipv6-over-80211ocb-21, maybe in the introduction? >> I suggest some language like the following: >> This document is a profile based on IEEE 1609.3: it introduces = additional requirements and specifications that do not violate that base = standard. >> Regards Jasja >> -----Urspr=C3=BCngliche Nachricht----- Von: Alexandre Petrescu=20 >> [mailto:alexandre.petrescu@gmail.com] Gesendet: Samstag, 17. = M=C3=A4rz >> 2018 12:23 An: Tijink Jasja Cc: Kevin Smith = >> ; its@ietf.org Betreff: Re: [ipwave] ipwave -=20 >> comments and concerns - 1609 WAVE, EPD - towards resolution Hello=20 >> Jasja, >>> Le 16/03/2018 =C3=A0 19:02, Tijink Jasja a =C3=A9crit : >>> Hello Alex, >>> in addition to Kevin's points, I would like to mention that: >>> 1. I welcome your proposal for the additional text that specifies = QoS. This is necessary for operation in Europe (the specification for = the access layer can be found in ETSI EN 302 663, where clause 4.6 says = that QoS shall be used). >> Noted. >>> 2. My understanding of the discussion below is that >>> draft-ietf-ipwave-ipv6-over-80211ocb-21 is "based on" IEEE 1609.3 in = that it is compliant with it (I didn't find any "violation of IEEE = 1609.3), and adds additional restrictions and /or specifications (such a = MTU size, AC_BK, RFC8064, etc.). In that sense = draft-ietf-ipwave-ipv6-over-80211ocb-21 is a profile of IEEE 1609.3. I = would suggest making that very clear, with a short sentence/paragraph in = draft-ietf-ipwave-ipv6-over-80211ocb-21 that explains it to the reader. = If you disagree, I would like to hear your view on the relation of IEEE = 1609.3 and draft-ietf-ipwave-ipv6-over-80211ocb-21. >> I dont really disagree, just where to put it. >> The draft does refer to 1609.3, in Appendix C "aspects introduced by = OCB to 802.11". The vehicular networking draft = (draft-ietf-ipwave-vehicular-networking-01) also refers to it right at = the beginning. >> IPv6-over-OCB sounds like an explanation. As such, I suggest we = first write more precisely that "IPv6-over-OCB is a profile of 1609.3" = and then put it into the vehicular networking draft. >> How could that be written? >> Alex >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its From nobody Tue Mar 20 07:01: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 ED3E01242F5 for ; Tue, 20 Mar 2018 07:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 074QKhz8aSVS for ; Tue, 20 Mar 2018 07:00:59 -0700 (PDT) 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 9ED441270AE for ; Tue, 20 Mar 2018 07:00:59 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id s2so1657080qti.2 for ; Tue, 20 Mar 2018 07:00:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=DnIgY22LzjPKTl6U38G1fGGdFBAi9mfQHcX7VfKl9kg=; b=j2zti8qZslhK3p22ZoUtcSWWZyMGIP54ZYGxPHe6jHgPnNhA3H+U3cx+UFAK3W240q JoVkNUlI/68dottvreDJ3gImjiNRtnRUsGxjiYpFn9lHLFKUU1z9l5G3SV5TBe8l6bUk nGgGLWTYcmudOFlVvcH7jjfazV5/fi4WdmpXIElY1BCDr5QlgO+DQQ6tkF238SmLl09L psPz/CdivWvyo2HeUxAazWFgOOa5hmjmyHDujfrTV1nyc1ghkmux/4ujc4nVOLZjFu1h DmNECkHsG09BDL9w/lLts7tGwfTBPXJPE3u3lUCyS7CHLltF/XbR7tj9K5pRxVaKSX2l hKPw== 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=DnIgY22LzjPKTl6U38G1fGGdFBAi9mfQHcX7VfKl9kg=; b=CDMrwrC1ysx2Lyht4H0vQP+MynXHtHpM9tMDvtXQCeFPk/OQ5Ndb0NGwmZx1wb0VU5 //8CZmxh+fK++650Te8rEPHKg1vry+hFU3Il1SBk/ztIhes+gkjfeWFfxjnScRNY7bvj hNLwajXj376a3g48kkHghG6V8PqASVKvmDCkNgN8hxijgq5u4RlGll6Bw7mB4HfqIOgR lZG4FLYf7je1mD+aotFGxa/ST3uAih3n/789VHlOJyJTTaFr908jTdDDdRrIh0+fRdNx qSP9ZaMjY7ezRBDzG4I+BY++Zsjkeg7ZSzyhC8Jwjlt3zoYjZ2S/QHVC5NoAZZ/ZxhM7 sc+Q== X-Gm-Message-State: AElRT7HGIghri6WdcdjSkgHQuJXVjxddrena60R/9EG7QmtJBkSbzOie Zm9IRNCUKUbY7p8um8JC7ho= X-Google-Smtp-Source: AG47ELtcNZ9atmqXSlS+TkC/qGprGGgCbfznLcstyITH6sSeVPNv9jF8s97sTbm1zFgy6Z5xxWlm5w== X-Received: by 10.200.46.227 with SMTP id i32mr24884200qta.157.1521554458801; Tue, 20 Mar 2018 07:00:58 -0700 (PDT) Received: from FrancoisPC (50-253-61-187-static.hfc.comcastbusiness.net. [50.253.61.187]) by smtp.gmail.com with ESMTPSA id l38sm1277954qta.68.2018.03.20.07.00.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Mar 2018 07:00:57 -0700 (PDT) From: =?utf-8?Q?Fran=C3=A7ois_Simon?= To: "'Tijink Jasja'" , Cc: "'Kevin Smith'" , "'Alexandre Petrescu'" , "'Jerome Haerri'" , References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <5cc6bd32-0812-288a-2db0-b0de53626f1e@gmail.com> In-Reply-To: Date: Tue, 20 Mar 2018 10:00:57 -0400 Message-ID: <001001d3c053$df29bf30$9d7d3d90$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01D3C032.581A9030" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGhOrR8o8b5YryKQCC/S9k90bJ5fwGaWEJkAVayqmAC0zYUGgHJZZEvAaEIiFAAcwBKmQJCGZTJAfxEhY8BiJkiz6PC7QbA Content-Language: en-us Archived-At: Subject: Re: [ipwave] =?utf-8?q?=5Bipwave=C3=AE=5D_IPv6-over-OCB_as_a_profile?= =?utf-8?q?_of_1609_WAVE?= X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 14:01:04 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0011_01D3C032.581A9030 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Nop! =20 =20 Fygs =20 From: its On Behalf Of Tijink Jasja Sent: Sunday, March 18, 2018 1:08 PM To: tony.li@tony.li Cc: Kevin Smith ; Alexandre Petrescu = ; Jerome Haerri = ; its@ietf.org Subject: Re: [ipwave] [ipwave=C3=AE] IPv6-over-OCB as a profile of 1609 = WAVE =20 =E2=80=A6so if we put it that way: =20 Is it possible to explain how an implementation of this draft = interoperates with an implementation of IEEE 1609.3? =20 Regards Jasja =20 Von: Tony Li [mailto:tony1athome@gmail.com] Im Auftrag von = tony.li@tony.li =20 Gesendet: Sonntag, 18. M=C3=A4rz 2018 17:50 An: Tijink Jasja > Cc: Jerome Haerri >; Alexandre Petrescu = >; = Kevin Smith >; = its@ietf.org =20 Betreff: Re: [ipwave] [ipwave=C3=AE] IPv6-over-OCB as a profile of 1609 = WAVE =20 =20 Anyhow, even if you don't like the sentence can your answer our original = question: what functionality does the draft provide that 1609 WAVE does = not already provide (except for the EAL aspect, which seems more an = implementation requirement)? =20 =20 The point is not to provide functionality. Rather, the point is to = document an agreement on what implementations should do if they want to = be interoperable. As noted, there are many conceivable ways of = transmitting IPv6 over OCB. We want to agree on just one. = That=E2=80=99s necessary and sufficient for this document. =20 Tony =20 ------=_NextPart_000_0011_01D3C032.581A9030 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Nop!=C2=A0=C2=A0

 

Fygs

 

From: its = <its-bounces@ietf.org> On Behalf Of Tijink = Jasja
Sent: Sunday, March 18, 2018 1:08 PM
To: = tony.li@tony.li
Cc: Kevin Smith <kevin.s.smith@cox.net>; = Alexandre Petrescu <alexandre.petrescu@gmail.com>; Jerome Haerri = <jerome.haerri@eurecom.fr>; its@ietf.org
Subject: Re: = [ipwave] [ipwave=C3=AE] IPv6-over-OCB as a profile of 1609 = WAVE

 

=E2=80=A6so = if we put it that way:

 

Is it = possible to explain how an implementation of this draft interoperates = with an implementation of IEEE 1609.3?

 

Regards = Jasja

 

Von: Tony Li [mailto:tony1athome@gmail.com] = Im Auftrag von tony.li@tony.li
Gesendet: = Sonntag, 18. M=C3=A4rz 2018 17:50
An: Tijink Jasja <Jasja.Tijink@kapsch.net>Cc: Jerome Haerri <jerome.haerri@eurecom.fr>= ; Alexandre Petrescu <alexandre.petrescu@gmail.com= >; Kevin Smith <kevin.s.smith@cox.net>; its@ietf.org
Betreff: Re: = [ipwave] [ipwave=C3=AE] IPv6-over-OCB as a profile of 1609 = WAVE

 

 

Anyhow, = even if you don't like the sentence can your answer our original = question: what functionality does the draft provide that  1609 WAVE = does not already provide (except for the EAL aspect, which seems more an = implementation requirement)?

 

 

The point is not to provide = functionality. Rather, the point is to document an agreement on what = implementations should do if they want to be interoperable. As noted, = there are many conceivable ways of transmitting IPv6 over OCB. We want = to agree on just one.  That=E2=80=99s necessary and sufficient for = this document.

 

Tony

 

<= /html> ------=_NextPart_000_0011_01D3C032.581A9030-- From nobody Tue Mar 20 07:07: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 8E87812EAD1 for ; Tue, 20 Mar 2018 07:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMBsuXugGY3x for ; Tue, 20 Mar 2018 07:06:59 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 206A712E8D6 for ; Tue, 20 Mar 2018 07:06:59 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id w6so1733372qkb.4 for ; Tue, 20 Mar 2018 07:06:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=BnSzr56GyeAL3FGMKLqt0ceX+geKQu2BMod4z0AIrOo=; b=ql5SGIgH5XIlJ3sEaG0pzOJsHcHRoJSNsaTdJyyNCoXps6nri4v3TAKtVxNl82OOUK dOg61ksgLFbX3P9s2lcE8GCM/ftnLlMYWiJK1+zCxMyhMg2OnCnGN705zH/qIipt9Fbi 4Qvw/CMYZMO5sYqmkG2b6aAIPucgCmAB8M249pI8SuJidcdYAK9XpcDOatUsRhFTVY9/ L16tB+v2VM0ZXETbJbDO//ZokraxrZ+OL6StunB2VrPHTde1ZaPxcCP9WiJfP9zi5HtQ 6KzTnPolUXAnDz7elGwH2E8MOXz+/lis1H4IrcHnShlU1bZxZwkvBVUnAp3AIzoEgXlJ lU3Q== 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=BnSzr56GyeAL3FGMKLqt0ceX+geKQu2BMod4z0AIrOo=; b=BmUh9Kl8nY2XVA7BMcpYQjtEbn5pwjhM1qGHG2f0y4KH//ZRPbrWre6EIPEPW7TXQA HbXk9xzjg0VwmT4a66L7eZ2SivdKRI7wUPcaB/HrK5gzzW+tea2TgzDntAYUDIY34ber RWrWvqq/yXD0J5xjTGUHZSep3FSb+s2B/wtkc9r46FoSJSy3WyVjZHSTIrZ/34cck7zq K8rZb/TuvZy0KhEnjmuJeKGE1qxH1hHaE1jtAwxk70ZHG35K7HnCho0yhkBSphJtgGoJ kdmIUPacSVSK7ezrZwIx5Vu8ge7AYwTjy6do5WM+L667npe6Zgd0AyjW4iiW4ZeSAnn4 pBaA== X-Gm-Message-State: AElRT7Fy+QAlUC5aCSZaU4fTXATc+N74MrDTs+oCUZ1MUx/bTNH7hNWN +KE+c9beeIYDkv9btpx9/yY= X-Google-Smtp-Source: AG47ELu14K4z3l04+lvHPKHjnK+7xj/b3Vg8wjyXPp6FQ3BnYI87E2Av+BFWt1GrOTaHVOKBemeZBw== X-Received: by 10.55.192.20 with SMTP id o20mr23112692qki.257.1521554818165; Tue, 20 Mar 2018 07:06:58 -0700 (PDT) Received: from FrancoisPC (50-253-61-187-static.hfc.comcastbusiness.net. [50.253.61.187]) by smtp.gmail.com with ESMTPSA id d198sm1717946qkg.91.2018.03.20.07.06.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Mar 2018 07:06:57 -0700 (PDT) From: =?utf-8?Q?Fran=C3=A7ois_Simon?= To: "'Kevin Smith'" , "'Alexandre Petrescu'" , "'Tijink Jasja'" Cc: References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <003b01d3be25$c5239ff0$4f6adfd0$@cox.net> <00c301d3bedf$64fca620$2ef5f260$@cox.net> In-Reply-To: <00c301d3bedf$64fca620$2ef5f260$@cox.net> Date: Tue, 20 Mar 2018 10:06:57 -0400 Message-ID: <001d01d3c054$b5ccf390$2166dab0$@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: AQGhOrR8o8b5YryKQCC/S9k90bJ5fwGaWEJkAgugfycB2ExIegL6LQxIAYB64p4BT8Z0y6Pj7kFg Content-Language: en-us Archived-At: Subject: Re: [ipwave] IP or IPv6 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 14:07:06 -0000 Only a 1609 restriction. Fygs -----Original Message----- From: its On Behalf Of Kevin Smith Sent: Sunday, March 18, 2018 1:35 PM To: 'Alexandre Petrescu' ; 'Tijink Jasja' = Cc: its@ietf.org Subject: Re: [ipwave] IP or IPv6 Alex, As the title of the document is " Transmission of *IPv6* Packets over = ...", it seems to me that the scope is restricted to IPv6. Also note = that IPv6 (along with WSMP) are the only L3 protocols allowed by 1609 = WAVE, i.e., IPv4 is not allowed. Best, Kevin -----Original Message----- From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu Sent: Sunday, March 18, 2018 10:25 AM To: Kevin Smith ; 'Tijink Jasja' = Cc: its@ietf.org Subject: Re: [ipwave] IP or IPv6 Le 17/03/2018 =C3=A0 20:25, Kevin Smith a =C3=A9crit : [...] > Note also I changed "IP" to "IPv6". At the risk of being called provokative: can one think there is another = version of IP that deserves being described? If not, the only version = that can be understood when reading "IP" is "IPv6". I do not see why being explicit and say v6, when IP is sufficient and = shorter. 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 Mar 20 07: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 4D3261200FC for ; Tue, 20 Mar 2018 07:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iK9dYrqJudtj for ; Tue, 20 Mar 2018 07:14:12 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B09D21270AE for ; Tue, 20 Mar 2018 07:14:08 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id j26so1694191qtl.11 for ; Tue, 20 Mar 2018 07:14:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=sfSpGb/ZA8d5NyPi+boKFsUlmZKphkpbsRw2xIq3YjQ=; b=O+4I2B5p2YTy/QsTXVfB4+LkMSkk93cWFIdfK1SjEUhAo/FlVDxAxz82Dnlqm2L2IR VYrzH9JfxwC9BfTq/O1ndr/VjrjyR7T8eCF8MhU1my3VBJO/RuX7Qn3pmMenuEeDvcSr zNXY7JiPM1qu4OGJPbu83xZ6k/FUzGvulL1fXcsE9y9LEAc8psTiF4SlWG1MtezZ4r1u TzSGSOKBweV1Yw/5FPaf377yrceR500uORUNVYP2MfhoNCtuerjUmL8XRfFj5tRDB+OZ +Z8n5IUEYQ5nSZSNLvMOehX76VbBA4yb4BzGjDCN6I6MhEPWZ8iuIH9/w2X95SXcURLu TrkQ== 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=sfSpGb/ZA8d5NyPi+boKFsUlmZKphkpbsRw2xIq3YjQ=; b=OPzXUT4WlWgpjRf5kfo8m5ar7g2tDo0cqG7a/K1/KgwayFUbC4BZbb2RR3dpwZFSN+ kkV1Mm/fjXqNQEC298V/XQx4H24wnXPCcToERV6f1BQ+7iw+mqhgb4MpoEx/BY1Mbnsm kSGoWydqnFd6N6P5lawaAAkjumZKJUU5XvMhO+nSDeUs1pfAaPuzIQL0Fk1FY9KTIy9X /m069HJdC6hDdIfba3eDOkSpr3tmwZSuhmvVsF8NE9ki9ZzNRJ5uiFcMk7sUtxPlx35G VH8OmDKyq43cTdHKogHm+PCDYmj10TXRhMyQJXYF4I1bawBR74nhZ7POV8IjVLU2pa1D 3fsw== X-Gm-Message-State: AElRT7EXERKJECvLKRRqKwR6Z9jN83llE3FxkwHnnNQRvlARI2Wye6ru VolEtrRqVESiHMaeoXErgmU= X-Google-Smtp-Source: AG47ELuAxcWl10jP41oWdrUlShDxItm3nzYsAIP2YPM8DzscxwqhByDuOUGbQ6+6hw5WYv/c3dugtQ== X-Received: by 10.200.19.11 with SMTP id e11mr17694627qtj.14.1521555247834; Tue, 20 Mar 2018 07:14:07 -0700 (PDT) Received: from FrancoisPC (50-253-61-187-static.hfc.comcastbusiness.net. [50.253.61.187]) by smtp.gmail.com with ESMTPSA id c4sm1200142qtj.86.2018.03.20.07.14.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Mar 2018 07:14:07 -0700 (PDT) From: =?utf-8?Q?Fran=C3=A7ois_Simon?= To: , Cc: "'Tijink Jasja'" , "'Kevin Smith'" , "'Alexandre Petrescu'" , "'Jerome Haerri'" , References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <5cc6bd32-0812-288a-2db0-b0de53626f1e@gmail.com> <5B6EDDCFBD8B46D6AA91912E4187FFCF@SRA6> In-Reply-To: Date: Tue, 20 Mar 2018 10:14:07 -0400 Message-ID: <003e01d3c055$b5d78570$21869050$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003F_01D3C034.2EC85670" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGhOrR8o8b5YryKQCC/S9k90bJ5fwGaWEJkAVayqmAC0zYUGgHJZZEvAaEIiFAAcwBKmQJCGZTJAfxEhY8BmEsNxQMzUfmpo6jYb1A= Content-Language: en-us Archived-At: Subject: Re: [ipwave] =?utf-8?q?=5Bipwave=C3=AE=5D_IPv6-over-OCB_as_a_profile?= =?utf-8?q?_of_1609_WAVE?= X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 14:14:14 -0000 This is a multipart message in MIME format. ------=_NextPart_000_003F_01D3C034.2EC85670 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Absolutely agree with Dr. Roy. =20 Fygs =20 From: its On Behalf Of tony.li@tony.li Sent: Sunday, March 18, 2018 5:11 PM To: dickroy@alum.mit.edu Cc: Tijink Jasja ; Kevin Smith = ; Alexandre Petrescu = ; Jerome Haerri = ; its@ietf.org Subject: Re: [ipwave] [ipwave=C3=AE] IPv6-over-OCB as a profile of 1609 = WAVE =20 =20 On Mar 18, 2018, at 5:47 PM, Dick Roy > wrote: =20 RR] That may be where the situation has degraded to, however that was = never the original intent. The original intent, the reason the BoF was = created in the first place, was because ISO people went to the IETF = (Thierry and a few others) to see if they would look into modifications = to the IPv6 protocols so that it could function in rapidly varying = network topologies (aka vehicular environments). We were not asking for = the IETF to specify what implementations at the lower layers should do, = ONLY what network layer functionalities needed to be implemented. Any = and ALL talk of what lower layers would be required to do was originally = way out of scope. Any requirements the IETF makes on lower layer will = w.p.1 fall on deaf ears =E2=80=A6 aka are a waste of time and effort. =20 =20 Interesting. =20 There has been little discussion of situations that are not handled = adequately today. =20 My experience suggests that no modifications are necessary at the = network layer. =20 Specifying which aspects of the lower layers to use have always been the = key point of the charter: =20 "This group's primary deliverable (and the only Standards track item) will be a document that will specify the mechanisms for transmission of IPv6 datagrams over IEEE 802.11-OCB mode.=E2=80=9D Tony ------=_NextPart_000_003F_01D3C034.2EC85670 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Absolutely = agree with Dr. Roy.

 

Fygs

 

From: its = <its-bounces@ietf.org> On Behalf Of = tony.li@tony.li
Sent: Sunday, March 18, 2018 5:11 = PM
To: dickroy@alum.mit.edu
Cc: Tijink Jasja = <Jasja.Tijink@kapsch.net>; Kevin Smith = <kevin.s.smith@cox.net>; Alexandre Petrescu = <alexandre.petrescu@gmail.com>; Jerome Haerri = <jerome.haerri@eurecom.fr>; its@ietf.org
Subject: Re: = [ipwave] [ipwave=C3=AE] IPv6-over-OCB as a profile of 1609 = WAVE

 

 



On Mar 18, 2018, at 5:47 PM, Dick Roy <dickroy@alum.mit.edu> = wrote:

 

RR] = That may be where the situation has degraded to, however that was never = the original intent.  The original intent, the reason the BoF was = created in the first place, was because ISO people went to the IETF = (Thierry and a few others) to see if they would look into modifications = to the IPv6 protocols so that it could function in rapidly varying = network topologies (aka vehicular environments).  We were not = asking for the IETF to specify what implementations at the lower layers = should do, ONLY what network layer functionalities needed to be = implemented.  Any and ALL talk of what lower layers would be = required to do was originally way out of scope.  Any requirements = the IETF makes on lower layer will w.p.1 fall on deaf ears =E2=80=A6 aka = are a waste of time and = effort.

 

 

Interesting.

 

There has been little discussion of situations that = are not handled adequately today.

 

My experience suggests that no modifications are = necessary at the network layer.

 

Specifying which aspects of the lower layers to use = have always been the key point of the = charter:

 

"This group's primary = deliverable (and the only Standards track

item) will be a document = that will specify the mechanisms for
transmission of IPv6 datagrams over IEEE = 802.11-OCB mode.=E2=80=9D



Tony



------=_NextPart_000_003F_01D3C034.2EC85670-- From nobody Tue Mar 20 07:18: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 9417F12D879 for ; Tue, 20 Mar 2018 07:18:08 -0700 (PDT) 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 9JVDOMYwbI6e for ; Tue, 20 Mar 2018 07:18:07 -0700 (PDT) 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 DACB31200B9 for ; Tue, 20 Mar 2018 07:18:06 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id h4so1711575qtn.13 for ; Tue, 20 Mar 2018 07:18:06 -0700 (PDT) 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=VHQsO0wEU7Ugn63k1VWMl5anhVtjLq+6WQsPoQy6j9U=; b=t+1xUpFF9le6ZQX07RDV9apL+MXQpRgbg3EM7ch6WfVE9g7/gjJ0IByZdqElnyeKKp tssKzq+4rrwLn/6bh4IDKtcV5AlT9e65BY7YrRuBbQgEj1VI2wFqKFEq0onKhtvkxkmZ VQhMkdRZoLHtmXtPhb+az1YNHO/h/L8WTWUTmTzcDnUnWhaTjdysMTuUUmYhFwtJsknK z7nrSapt5DNGasgEmsXsVo+VI+I04AR8yxfDRFH73mRg3WQLexFz9PPNlQN8yWdq3CfT mwX8iSNhsCrMSWaUAJFe48TSrzqoR2wTYpeSeXnUxUkaTzOivr6tfKszzVRGopQeJwYn 2BKg== 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=VHQsO0wEU7Ugn63k1VWMl5anhVtjLq+6WQsPoQy6j9U=; b=gmtbuU65xzWSDHOsY65JgGBSpJMhHRGV6rgxQ8ZmNR/GZJfSdcstcvA8AswiFzntEB 8Gbvsgb0c6Dx2u+JcjjHIZWMo1GAT8sU8L3G6G4oFkF68RCwSxP6vT9vFO75OwG/bi+m OELFWCMrcUEc2Wa9P5xjoiC4lQI3rRo3udczJvH7ZRboYNBfD945bf6KfK5+2e8MSjkD LO68PA5n6v+q4lUN/gvUfEnL/LlKESPtvyUjJnc/z4yt5C6ML3QZYxwY1jURBs2Xw1pC 57YZ5PPm+9wKzP1oYp+oCNqER4fZt6Q7MbGJsJ2hXBTYW6DIbZmVyI+Us6ebi150dVA5 4FCQ== X-Gm-Message-State: AElRT7GwM1cpPRdh/5Av+CmCLgg1fVcHikDE08m6pMLcvY1ZdkYi3FNf SxUkAIuxSUakuBkXkQruJFuykA== X-Google-Smtp-Source: AG47ELsu+FWx90cAKTOc1ZUgnT1jy4NtgPiLFVcgqQhzNXTT1l3VNvTYb02RAPLa7tEwU2eN4Bv7+g== X-Received: by 10.200.7.69 with SMTP id k5mr19350105qth.165.1521555486106; Tue, 20 Mar 2018 07:18:06 -0700 (PDT) Received: from FrancoisPC (50-253-61-187-static.hfc.comcastbusiness.net. [50.253.61.187]) by smtp.gmail.com with ESMTPSA id g52sm1272554qta.73.2018.03.20.07.18.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Mar 2018 07:18:05 -0700 (PDT) From: =?utf-8?Q?Fran=C3=A7ois_Simon?= To: "'Russ Housley'" , References: <660BFCF2CF184B2C8ACA0743EA9BBB54@SRA6> In-Reply-To: Date: Tue, 20 Mar 2018 10:18:05 -0400 Message-ID: <006a01d3c056$43e26fb0$cba74f10$@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: AQHXMIgblr0a3rEHaZ5YiKmP3jMrRwMGPU2vAh/dJ4gBJhV6yqOf6beg Content-Language: en-us Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 14:18:11 -0000 MUST ..... AC_BK does not make sense. Fygs -----Original Message----- From: its On Behalf Of Russ Housley Sent: Monday, March 19, 2018 11:14 AM To: its@ietf.org Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data In the session earlier today, Alex offered text to resolve this topic. = He said: The IPv6 packet transmitted on 802.11-OCB MUST be immediately = preceded by a Logical Link Control (LLC) header and an 802.11 header. In the LLC header, and in accordance with the EtherType Protocol Discrimination (EPD), the value of the Type field MUST be set to 0x86DD (IPv6). In the 802.11 header, the value of the Subtype sub-field in the Frame Control field MUST be set to 8 (i.e. 'QoS Data'); the value of the Traffic Identifier (TID) sub-field of the = QoS Control field of the 802.11 header MUST be set to binary 001 (i.e. User Priority 'Background', QoS Access Category 'AC_BK'). No one in the room raised any concern with this text. If you have a = concern, please speak on the list now. In a another part of the meeting, J=C3=A9r=C3=B4me talked about Mapping = IP to Access Category in 802.11-OCB. It was pointed out that RFC 8325 = was recently published on the standards track. Tony Li pointed out that = there is no integrity protection for these bits. As an individual, I wonder if it would be better to say something like: = If DiffServ is being used, set the QoS Access Category as described in = RFC 8325, otherwise set the QoS Access Category of 'AC_BK'. What do others think? Russ _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its From nobody Tue Mar 20 07: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 B2F4A124BFA for ; Tue, 20 Mar 2018 07:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 54_84LnF_r58 for ; Tue, 20 Mar 2018 07:24:32 -0700 (PDT) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (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 DEA181200FC for ; Tue, 20 Mar 2018 07:24:31 -0700 (PDT) Received: by mail-wm0-x241.google.com with SMTP id h76so3829847wme.4 for ; Tue, 20 Mar 2018 07:24:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KPspkMTBxGu6hVso1yiwOJX8SJRA5Mos8zeaQZSy3Tg=; b=UCNjVf2kAnPxel7OmHNr4oVJ5A8/QE0Ec7jTXPbxB7BuxeuE0O+IpuadfVuVdn8hVM 7kvDHiDWd8camYeKOrvFbesJVVHm0bTi8sILug3p1v6zN/7RlVBkoGKIgXUjQkYU4xlK 2PMr0db1PNjUMbLEQHzWGW82feYhDUZrVbDUpldrdaDc0aVKGiPiLFmMP9ABRp/TWr6e tIn/Hde0OJyi1VJBOPwdrinL7jGVwrCZ6/gYCFJ5RfnaOn14hJU9vnx2WCB+7urRyRVZ in+8bOVjAlHbcSInaPnswtxXGKFnCDkrvYmBeQ6n4Hus0E00cTvynGZ0hVCTKVkcwWZ4 UYAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=KPspkMTBxGu6hVso1yiwOJX8SJRA5Mos8zeaQZSy3Tg=; b=PjkEGpXNJ1LgI4Y/Bh25FH5K3Qz5mkK2Dx9k7lbU9zJn8397A2pEn6oXbBaqZQZPxh jbn8pyJ8TyLUhTTuUdr1JiGaarmR8iqKmpYYUqoAPYuPvp4TnMhA1coPrm3ENswreedJ rW4bQgI3zkUInZ402D9RIohp1eq5cV0afu0YqPMQbwoudhmuMf8oB+q/sCM+SUaFdbKw qSd63DXoHvNJK1ApGkyYFXnRW0+B7auXTGIyw9/v0I5VpMADh8Gdnxdvh51/uPdTHxDW lYKIuYSUe+/eVAKCWa+s1L+PU4XcQUAhJ9pyrKmMH+Qae0elZOnuwNn3WOPJFYtdiFk+ epzg== X-Gm-Message-State: AElRT7FuIbZAxBttwnMLZR+IFxxFfGfO8DucpTbZx7XkkUkGQFrgdYfH lm71M+APomGVfF2O1VR97V2qA3nDduU= X-Google-Smtp-Source: AG47ELtFfrT/iczHCD1yWCu0H3NQl8BX/wV3PhDFiXlF98OJiUcAw6pfLmMc5xi7Xj7FviOJ4HPuMw== X-Received: by 10.28.0.210 with SMTP id 201mr2298084wma.10.1521555870381; Tue, 20 Mar 2018 07:24:30 -0700 (PDT) Received: from dhcp-8f31.meeting.ietf.org (dhcp-8f31.meeting.ietf.org. [31.133.143.49]) by smtp.gmail.com with ESMTPSA id e74sm1953770wmg.27.2018.03.20.07.24.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Mar 2018 07:24:29 -0700 (PDT) Sender: Tony Li 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: <006a01d3c056$43e26fb0$cba74f10$@gmail.com> Date: Tue, 20 Mar 2018 14:24:28 +0000 Cc: Russ Housley , its@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <660BFCF2CF184B2C8ACA0743EA9BBB54@SRA6> <006a01d3c056$43e26fb0$cba74f10$@gmail.com> To: =?utf-8?Q?Fran=C3=A7ois_Simon?= X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 14:24:34 -0000 What would make more sense? You do not want people using higher = priority. If you don=E2=80=99t say MUST, then everything will be marked = as voice. T > On Mar 20, 2018, at 2:18 PM, Fran=C3=A7ois Simon = wrote: >=20 > MUST ..... AC_BK does not make sense. Fygs >=20 > -----Original Message----- > From: its On Behalf Of Russ Housley > Sent: Monday, March 19, 2018 11:14 AM > To: its@ietf.org > Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data >=20 > In the session earlier today, Alex offered text to resolve this topic. = He said: >=20 > The IPv6 packet transmitted on 802.11-OCB MUST be immediately = preceded > by a Logical Link Control (LLC) header and an 802.11 header. In the > LLC header, and in accordance with the EtherType Protocol > Discrimination (EPD), the value of the Type field MUST be set to > 0x86DD (IPv6). In the 802.11 header, the value of the Subtype > sub-field in the Frame Control field MUST be set to 8 (i.e. 'QoS > Data'); the value of the Traffic Identifier (TID) sub-field of the = QoS > Control field of the 802.11 header MUST be set to binary 001 (i.e. > User Priority 'Background', QoS Access Category 'AC_BK'). >=20 > No one in the room raised any concern with this text. If you have a = concern, please speak on the list now. >=20 > In a another part of the meeting, J=C3=A9r=C3=B4me talked about = Mapping IP to Access Category in 802.11-OCB. It was pointed out that = RFC 8325 was recently published on the standards track. Tony Li pointed = out that there is no integrity protection for these bits. >=20 > As an individual, I wonder if it would be better to say something = like: If DiffServ is being used, set the QoS Access Category as = described in RFC 8325, otherwise set the QoS Access Category of 'AC_BK'. >=20 > What do others think? >=20 > Russ >=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 From nobody Tue Mar 20 08:21: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 B87C312E8A8 for ; Tue, 20 Mar 2018 08:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 TeOD5Ag1Xo11 for ; Tue, 20 Mar 2018 08:21:03 -0700 (PDT) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73312127775 for ; Tue, 20 Mar 2018 08:20:58 -0700 (PDT) Received: by mail-wr0-x22c.google.com with SMTP id z8so2097472wrh.7 for ; Tue, 20 Mar 2018 08:20:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc:message-id :references:to; bh=4ihEjl4TncY2RuhENZH9b6BLWjNXRLw66DPp39aLU84=; b=e6sARxLPh9hX5wLYQgH8BYUvmBXxBFEtDxM0zyRDE75yuruw8P0AmMobOQ1OBGt0kX VnwI9r3PBNB6B+p/NLlPNZyXOLrFDuKvJeIHtF8U94UCLDm5Mkw8B/cdzDUi3eEqbVeF 6sxgULdMS7+1qLExwM3QBBjLYjYjFCdsNUz3ZvqlJnaEgDPsvjE17QgJAS++CWLx9L3+ 3FoeNjTDiStvf4my2KdD5yb2umxlC4AhwGjSque5xiB+KJE6O0ZRmU7FS/TbYkviVFAV FK8pyLTD+wx9WTnKh6YNIq8Fpo+0i8NJhMDDpUWI5xpBjmoAgz1QaGW7fXhOmIG15wwj BUtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; bh=4ihEjl4TncY2RuhENZH9b6BLWjNXRLw66DPp39aLU84=; b=NaiTVkMRH8CUNwdHDd/3fvpGA0YBJZz8hweS2ZpiMED5HGPJdh0SGm5n+1SOsE2CaZ 9H+7HuMW2890LLbXSYNrG2gW09nWsMCtd5GJ0od6ez/1d8DrAG22nV0xu5YLnFsYWQC8 +UDlMRsc6HZNKdE8wLoAYZNAx0jtVYPIbcnZh1mkWL/11BzDev1i82kNFTz2KaLfMsLy OxyAylyN3zmPcEiWUvJ2dLtEbNKDtZqPsbPSJ1wsrKZA45+AvG9E5sJ+a1lkh5llhlg4 8QCDn/eDPtrWkcxi38X9x2f5QhLEf6g8Av4mkzwIv+N9re+827pRXUYpFvZFL5eqDv64 AXEA== X-Gm-Message-State: AElRT7HkMJzZcf0B9rJq2YUseBRMCJWT/23btffz4i2gaovsvF1Rnj5+ gLqpINFf7G2b4uy6N3tFNBWu9E/Iafo= X-Google-Smtp-Source: AG47ELtmerbBuc+KLdJSoTOwu+XKRPtrh1ULkNmcZKzDUhsmD9lAIauNTHYrQSQv+VuR5S8XgYmUSg== X-Received: by 10.223.134.213 with SMTP id 21mr12521649wry.221.1521559256973; Tue, 20 Mar 2018 08:20:56 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:f4c3:3897:e168:d340? ([2001:67c:370:128:f4c3:3897:e168:d340]) by smtp.gmail.com with ESMTPSA id 104sm2011119wrl.26.2018.03.20.08.20.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Mar 2018 08:20:56 -0700 (PDT) Sender: Tony Li Content-Type: multipart/alternative; boundary="Apple-Mail=_ED7A1BBE-E315-4721-967F-270481F5489D" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: tony.li@tony.li X-Priority: 3 (Normal) In-Reply-To: Date: Tue, 20 Mar 2018 15:20:55 +0000 Cc: =?utf-8?B?RnJhbsODwqdvaXMgU2ltb24=?= , Russ Housley , its@ietf.org Message-Id: References: <660BFCF2CF184B2C8ACA0743EA9BBB54@SRA6> <006a01d3c056$43e26fb0$cba74f10$@gmail.com> To: dickroy@intellicommunications.com X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 15:21:06 -0000 --Apple-Mail=_ED7A1BBE-E315-4721-967F-270481F5489D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 20, 2018, at 2:42 PM, dickroy@intellicommunications.com wrote: >=20 > That said, ANYTHING the IETF says about this will be ignored, believe = me.=20 > J2945/1 and others will apply and they are m ost assuredly using ALL > prioities. No one is suggesting any restrictions for anything other than IP = packets, so I don=E2=80=99t see your point. T --Apple-Mail=_ED7A1BBE-E315-4721-967F-270481F5489D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Mar 20, 2018, at 2:42 PM, dickroy@intellicommunications.com wrote:

That said, ANYTHING the IETF = says about this will be ignored, believe me. 
J2945/1 and others will apply and they are m ost = assuredly using ALL
prioities.


No one is suggesting any = restrictions for anything other than IP packets, so I don=E2=80=99t see = your point.

T

= --Apple-Mail=_ED7A1BBE-E315-4721-967F-270481F5489D-- From nobody Tue Mar 20 08:52:05 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 E60EB126C0F; Tue, 20 Mar 2018 08:51:59 -0700 (PDT) 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.75.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152156111990.9784.3306758714439451553@ietfa.amsl.com> Date: Tue, 20 Mar 2018 08:51:59 -0700 Archived-At: Subject: [ipwave] I-D Action: draft-ietf-ipwave-ipv6-over-80211ocb-22.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, 20 Mar 2018 15:52:00 -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-22.txt Pages : 39 Date : 2018-03-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. 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-22 https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-22 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-22 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 Mar 20 08:54: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 0E1AA126C0F for ; Tue, 20 Mar 2018 08:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0h_rnqsiqlOq for ; Tue, 20 Mar 2018 08:54:09 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38465126579 for ; Tue, 20 Mar 2018 08:54:08 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w2KFs66I035442 for ; Tue, 20 Mar 2018 16:54:06 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id BE45A206BC8 for ; Tue, 20 Mar 2018 16:54: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 B4D77206AF7 for ; Tue, 20 Mar 2018 16:54:06 +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 w2KFs6g7009103 for ; Tue, 20 Mar 2018 16:54:06 +0100 References: <152156112012.9784.4818312750079552894.idtracker@ietfa.amsl.com> To: "its@ietf.org" From: Alexandre Petrescu X-Forwarded-Message-Id: <152156112012.9784.4818312750079552894.idtracker@ietfa.amsl.com> Message-ID: <362b3ad0-0d77-b89e-3d92-5f1657aa4642@gmail.com> Date: Tue, 20 Mar 2018 16:54: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: <152156112012.9784.4818312750079552894.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: [ipwave] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-22.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, 20 Mar 2018 15:54:12 -0000 Hi IPWAVErs, Following our discussion during the IPWAVE WG meeting in London, this is the draft including the last changes. Yours, Alex -------- Message transféré -------- Sujet : New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-22.txt Date : Tue, 20 Mar 2018 08:52:00 -0700 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-22.txt has been successfully submitted by Alexandre Petrescu and posted to the IETF repository. Name: draft-ietf-ipwave-ipv6-over-80211ocb Revision: 22 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-03-20 Group: ipwave Pages: 39 URL: https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-22.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-22 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-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. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Tue Mar 20 09:11: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 C60601275FD for ; Tue, 20 Mar 2018 09:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 N2NzITRjAkJ0 for ; Tue, 20 Mar 2018 09:11:34 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::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 9D8EF1270AB for ; Tue, 20 Mar 2018 09:11:32 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id e194so4508356wmd.3 for ; Tue, 20 Mar 2018 09:11:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc:message-id :references:to; bh=/BGzBcxQthqWncz4fj58iW1OpUxdov94uoZR3oqntPA=; b=fLdtfUxoRZXTGGmodT5nO6hcTbvS6iASGzg3Cs2LuObqqgvHJLrNh/Q3rIc4q0vvus NdUzl9UO9jtb5qhz3IeouyMb6cmMqyziiLry1WAxJMeQdO/rwl8xXOfpomTnxwhWycvt OiG1MRFbzZNUzZJ/U8npzIMHQejZfZ85H50/rfv5mKOlhYBd4LgnJ9NHxES2sHMUmIFE miY0ofkFbjo19ejuor9P2OqHOUfYmTfnu5ZIhzjsN/DEB1WzCu5mChe9VreTFA6crEds fBf010HIeidkk1HcRuoeeObp+49Ob18zwpKSc3QCNgavc+wFDj8Auss4YryNPXjPTGIZ bo6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; bh=/BGzBcxQthqWncz4fj58iW1OpUxdov94uoZR3oqntPA=; b=d+ZEulfPIZWYYbsFdp1GgWfM7m0n7EME+TKGoh7NxC0EeDQtLXsTyZiK/PDpeMhLHe MHraBGZfLsZDE1nPnK0BekVi0vOn7TMVnzYBZWRkffUtdwJjNhoeEkuIz+jCT9WSl6K8 /MIPeqLGELzN7lp33TW2JriqYkbSU9rU6fi0hHXZ2gdcRqBWulCOONS+sSglYCJr+4Id GqdKUL0s9/giQ2OnRxZfN+MGKOsftnmXgCcUgklIqZxWv5/6fx6RNUvoxMWT18bl6rGR wN75c3wc2SWdIZvZzl2KZlGpzwQZBWvQgVK+lU7EXdD2rZKHzNrbk2o1qBsBUxhIE1e4 IRqQ== X-Gm-Message-State: AElRT7GKHjkxZPTMWhk/VYJ16drDSS1h3/rdhi7lfz5izPxS/75nkCHo EYnLMYUgmZpkuhWGWXSCTtFsSogw67s= X-Google-Smtp-Source: AG47ELsFvfKfWaG1VFE8TD24VuEbGPp2g/pHyAfQ01+I7z1pNDL4fJt64uvMaMsp+5glifWDiYsVoQ== X-Received: by 10.28.11.79 with SMTP id 76mr166788wml.41.1521562291207; Tue, 20 Mar 2018 09:11:31 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:5a2:25da:2d8:f2b4? ([2001:67c:370:128:5a2:25da:2d8:f2b4]) by smtp.gmail.com with ESMTPSA id 9sm2615828wml.22.2018.03.20.09.11.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Mar 2018 09:11:30 -0700 (PDT) Sender: Tony Li Content-Type: multipart/alternative; boundary="Apple-Mail=_7814AA29-F568-480D-8719-A1A5E13D4F32" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: tony.li@tony.li X-Priority: 3 (Normal) In-Reply-To: <99d50f17989ff340d401de5442d39023.squirrel@emailmg.ipower.com> Date: Tue, 20 Mar 2018 16:11:27 +0000 Cc: =?utf-8?B?RnJhbsODwqdvaXMgU2ltb24=?= , Russ Housley , its@ietf.org Message-Id: References: <660BFCF2CF184B2C8ACA0743EA9BBB54@SRA6> <006a01d3c056$43e26fb0$cba74f10$@gmail.com> <99d50f17989ff340d401de5442d39023.squirrel@emailmg.ipower.com> To: dickroy@intellicommunications.com X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 16:11:36 -0000 --Apple-Mail=_7814AA29-F568-480D-8719-A1A5E13D4F32 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 20, 2018, at 3:35 PM, dickroy@intellicommunications.com wrote: >=20 > Everything I said above applies to ANY NPDU, including an IPv6 NPDU!=20= > Ch180 is liekly to have many ITS services that use IPv6, and those > services will be prioitized and those prioirties will filter on down > through UNITDATA.reuests to the MAC! That's what I mean. The guys > deploying the system will determine the prioities, not the ITETF. >=20 > Hope that clears it up... It does completely. =20 I=E2=80=99m beginning to realize that you object to standardization. = ;-) If they choose not to comply with the RFC that=E2=80=99s fine. We=E2=80=99= re not setting laws here. But they should also not complain when they = don=E2=80=99t interoperate or when they get hacked. Tony --Apple-Mail=_7814AA29-F568-480D-8719-A1A5E13D4F32 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Mar 20, 2018, at 3:35 PM, dickroy@intellicommunications.com wrote:

Everything I said above applies = to ANY NPDU, including an IPv6 NPDU! 
Ch180 is liekly to have many ITS services that = use IPv6, and those
services will be prioitized and = those prioirties will filter on down
through UNITDATA.reuests to the = MAC!  That's what I mean.  The guys
deploying the system  will determine the = prioities, not the ITETF.

Hope that clears it = up...


It does completely.  

I=E2=80=99m beginning to = realize that you object to standardization.  ;-)

If they choose not to = comply with the RFC that=E2=80=99s fine. We=E2=80=99re not setting laws = here.  But they should also not complain when they don=E2=80=99t = interoperate or when they get hacked.

Tony

= --Apple-Mail=_7814AA29-F568-480D-8719-A1A5E13D4F32-- From nobody Wed Mar 21 01:10: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 9FE9E12D958 for ; Wed, 21 Mar 2018 01:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gu6IBYUgAX9g for ; Wed, 21 Mar 2018 01:10:18 -0700 (PDT) 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 8937912D954 for ; Wed, 21 Mar 2018 01:10:18 -0700 (PDT) Received: by mail-ot0-x22e.google.com with SMTP id i28-v6so4687057otf.8 for ; Wed, 21 Mar 2018 01:10:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eONEq3078EBTkVV9AaEQBp8qz9fgUXxQT/aJVTfQ9J8=; b=qMBdWS27y5UyvZ7IUgGdY0c80iWehaqO7/b1ypyHlJo5zB7IEFDlb66orLmE5Plh3J vpg24XemKs5pI/nNdV4AKoe+16gObDPAsV3YvVhLsnCHSFaNjY787FmhhAYoaqq0mofh IAP+ZFCKM/XxWsbH5OoxtAJ0aLy+FenKE2OwdcmmIw7JU01eDE9m31viJM5b9xHx7kTI 9IVu7gYC2VSOCRMGocYj1sX1RJXbjBpU2/JegGQDp/PzNTASvRICKUdt5L5VVGIvoN0w 0j9zzIi8WSEIOhCgMKMM/GiA/kuX2T5Pn0VIJN+ieCOADrRvDCuVwftDo/AHy0J+rODg J6sA== 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=eONEq3078EBTkVV9AaEQBp8qz9fgUXxQT/aJVTfQ9J8=; b=ESkDmwx+tvd4kHRprVV0iouicmuDwtiIwDi/8M1a2Wrsrw7uDOAe7iBt6Kdfs/qwPs rBXgvsF7fTLauckdt0V0RXEaIeb7J6wnVj4i6S6WlDQY3tGq5D3WfKzOv1G5X2xBO+kK jsFi+bLrAvWQq/5+yhA8rCNNZfzO9vBd3DLvla0B/JrMO8pVh6Jmv5Crn+6P6VO7kwCE PCF+E3Is+vbYt3VQ170PunEIkx7xx6PgFUg8P8ubbo1LLp2A7g4z0qS+ecoy/LoDxO2D F3huv0qNtPROPFmsVM2xlrklGCjfcgsBvMG72nFfj6Ha8YQLjWD/hx/DQxYotpMDnYkA k/Fw== X-Gm-Message-State: AElRT7Ha5AsnwGHu5w/rTbc3Qh3YvZIyGm974FYMW162NZu55VEoo+JF G0E9HqD/zjqrwmbH4rEOzUPlet4g1KCI05a85+Q= X-Google-Smtp-Source: AG47ELs63dLa5/mR8a6eMCLuW9EO1A5DBlKf1BID8Ofj7itd9T9/PYhAWkYbczMVkuVlLOaEuXn1IUwtbtpxQW12ULk= X-Received: by 2002:a9d:26c2:: with SMTP id i2-v6mr9030699otd.132.1521619817942; Wed, 21 Mar 2018 01:10:17 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:1442:0:0:0:0:0 with HTTP; Wed, 21 Mar 2018 01:10:17 -0700 (PDT) In-Reply-To: <009c01d3c052$f0a78cc0$d1f6a640$@gmail.com> References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <5cc6bd32-0812-288a-2db0-b0de53626f1e@gmail.com> <009c01d3c052$f0a78cc0$d1f6a640$@gmail.com> From: Abdussalam Baryun Date: Wed, 21 Mar 2018 10:10:17 +0200 Message-ID: To: =?UTF-8?Q?Fran=C3=A7ois_Simon?= Cc: Alexandre Petrescu , its , Tijink Jasja , Kevin Smith Content-Type: multipart/alternative; boundary="000000000000bb52790567e7b87f" Archived-At: Subject: Re: [ipwave] =?utf-8?q?=5Bipwave=C3=AE=5D_IPv6-over-OCB_as_a_profile?= =?utf-8?q?_of_1609_WAVE?= X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 08:10:21 -0000 --000000000000bb52790567e7b87f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 AB On Tue, Mar 20, 2018 at 3:54 PM, Fran=C3=A7ois Simon w= rote: > *This document is a profile based on IEEE 1609.3: it introduces additiona= l > requirements and specifications that do not violate that base standard.* > > *For my part I find addition of this text neutral and ok, although I am > not sure what is a profile for 1609 WAVE. In Bluetooth, a 'profile' is > something very much precise, like 'LAN profile', etc.* > > I am NOT ok with it: > > 1) - I did not think that IEEE 1609 Series was in scope of the document; > > 2) - OCB is NOT a profile of 1609 WAVE. See previously sent definition. > > Fygs > > -----Original Message----- > From: its On Behalf Of Alexandre Petrescu > Sent: Sunday, March 18, 2018 12:16 PM > To: its@ietf.org > Cc: Tijink Jasja ; Kevin Smith < > kevin.s.smith@cox.net> > Subject: Re: [ipwave] [ipwave=C3=AE] IPv6-over-OCB as a profile of 1609 W= AVE > > Hi IPWAVErs, > > Do you disagree we add this phrase in the Introduction: > > > This document is a profile based on IEEE 1609.3: it introduces > > > additional requirements and specifications that do not violate that > > > base standard. > > For my part I find addition of this text neutral and ok, although I am no= t > sure what is a profile for 1609 WAVE. In Bluetooth, a 'profile' is > something very much precise, like 'LAN profile', etc. > > Alex > > Le 17/03/2018 =C3=A0 13:22, Tijink Jasja a =C3=A9crit : > > > Hello Alex, > > > > > > Can we put something at the beginning of > > > draft-ietf-ipwave-ipv6-over-80211ocb-21, maybe in the introduction? > > > I suggest some language like the following: > > > > > > This document is a profile based on IEEE 1609.3: it introduces > > > additional requirements and specifications that do not violate that > > > base standard. > > > > > > Regards Jasja > > > > > > > > > -----Urspr=C3=BCngliche Nachricht----- Von: Alexandre Petrescu > > > [mailto:alexandre.petrescu@gmail.com ] > Gesendet: Samstag, 17. M=C3=A4rz > > > 2018 12:23 An: Tijink Jasja Cc: Kevin Smith > > > ; its@ietf.org Betreff: Re: [ipwave] ipwave - > > > comments and concerns - 1609 WAVE, EPD - towards resolution > > > > > > Hello Jasja, > > > > > > Le 16/03/2018 =C3=A0 19:02, Tijink Jasja a =C3=A9crit : > > >> Hello Alex, > > >> > > >> in addition to Kevin's points, I would like to mention that: > > >> > > >> 1. I welcome your proposal for the additional text that specifies > > >> QoS. This is necessary for operation in Europe (the specification for > > >> the access layer can be found in ETSI EN 302 663, where clause > > >> 4.6 says that QoS shall be used). > > > > > > Noted. > > > > > >> 2. My understanding of the discussion below is that > > >> draft-ietf-ipwave-ipv6-over-80211ocb-21 is "based on" IEEE 1609.3 in > > >> that it is compliant with it (I didn't find any "violation of IEEE > > >> 1609.3), and adds additional restrictions and /or specifications > > >> (such a MTU size, AC_BK, RFC8064, etc.). In that sense > > >> draft-ietf-ipwave-ipv6-over-80211ocb-21 is a profile of IEEE 1609.3. > > >> I would suggest making that very clear, with a short > > >> sentence/paragraph in draft-ietf-ipwave-ipv6-over-80211ocb-21 that > > >> explains it to the reader. If you disagree, I would like to hear your > > >> view on the relation of IEEE 1609.3 and > > >> draft-ietf-ipwave-ipv6-over-80211ocb-21. > > > > > > I dont really disagree, just where to put it. > > > > > > The draft does refer to 1609.3, in Appendix C "aspects introduced by > > > OCB to 802.11". The vehicular networking draft > > > (draft-ietf-ipwave-vehicular-networking-01) also refers to it right at > > > the beginning. > > > > > > IPv6-over-OCB sounds like an explanation. As such, I suggest we first > > > write more precisely that "IPv6-over-OCB is a profile of 1609.3" and > > > then put it into the vehicular networking draft. > > > > > > How could that be written? > > > > > > 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 > > --000000000000bb52790567e7b87f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1

AB

On Tue, Mar 20, 2018 at 3:5= 4 PM, Fran=C3=A7ois Simon <fygsimon@gmail.com> wrote:

This document= is a profile based on IEEE 1609.3: it introduces additional requirements a= nd specifications that do not violate that=C2=A0 base standard.<= /span>

For my part I= find addition of this text neutral and ok, although I am not sure what is = a profile for 1609 WAVE.=C2=A0 In Bluetooth, a 'profile' is somethi= ng very much precise, like 'LAN profile', etc.

I am NOT = ok with it:

1) - I did not t= hink that IEEE 1609 Series was in scope of the document;

2<= span lang=3D"en-us">) - OCB is NOT a profile of 1609= WAVE.=C2=A0 See previously sent definition.

Fygs

-----Original Me= ssage-----
From: its <its= -bounces@ietf.org> On Behalf Of Alexandre Petrescu
Sent: Sunday, March 18, 2018 12:16 PM
To: its@ietf.org
Cc: Tijink Jasja <Jasja.Tijink@kapsch.net>; Kevin Smith <kevin.s.smith@cox.net>
Subject: Re: [ipwave] [ipwave=C3=AE] IPv6-over-OCB as a profile of 1609 WAV= E

Hi IPWAVErs,

Do you disagree = we add this phrase in the Introduction:

> This docume= nt is a profile based on IEEE 1609.3: it introduces

> additional = requirements and specifications that do not violate that

> base standa= rd.

For my part I fi= nd addition of this text neutral and ok, although I am not sure what is a p= rofile for 1609 WAVE.=C2=A0 In Bluetooth, a 'profile' is something = very much precise, like 'LAN profile', etc.

Alex


Le 17/03/2018 = =C3=A0 13:22, Tijink Jasja a =C3=A9crit :

> Hello Alex,=

>

> Can we put = something at the beginning of

> draft-ietf-= ipwave-ipv6-over-80211ocb-21, maybe in the introduction?=

> I suggest s= ome language like the following:

>

> This docume= nt is a profile based on IEEE 1609.3: it introduces

> additional = requirements and specifications that do not violate that

> base standa= rd.

>

> Regards Jas= ja

>

>

> -----Urspr= =C3=BCngliche Nachricht----- Von: Alexandre Petrescu

> [mailto:a= lexandre.petrescu@gmail.com<= /a>] Gesendet: Samstag, 17. M= =C3=A4rz

> 2018 12:23 = An: Tijink Jasja <Jasja.Tijink@kapsch.net> Cc: Kevin Smit= h

> <= kevin.s.smit= h@cox.net>; its@ietf.org<= span lang=3D"en-us"> Betreff: Re: [ipwave] ipwave - =

> comments an= d concerns - 1609 WAVE, EPD - towards resolution

>

> Hello Jasja= ,

>

> Le 16/03/20= 18 =C3=A0 19:02, Tijink Jasja a =C3=A9crit :

>> Hello A= lex,

>> =

>> in addi= tion to Kevin's points, I=C2=A0 would like to mention that:

>> =

>> 1. I we= lcome your proposal for the additional text that specifies

>> QoS. Th= is is necessary for operation in Europe (the specification for

>> the acc= ess layer can be found in ETSI EN 302 663, where clause

>> 4.6 say= s that QoS shall be used).

>

> Noted.

>

>> 2. My u= nderstanding of the discussion below is that

>> draft-i= etf-ipwave-ipv6-over-80211ocb-21 is "based on" IEEE 1609.3 i= n

>> that it= is compliant with it (I didn't find any "violation of IEEE

>> 1609.3)= , and adds additional restrictions and /or specifications

>> (such a= MTU size, AC_BK, RFC8064, etc.). In that sense

>> draft-i= etf-ipwave-ipv6-over-80211ocb-21 is a profile of IEEE 1609.3. <= /span>

>> I would= suggest making that very clear, with a short

>> sentenc= e/paragraph in draft-ietf-ipwave-ipv6-over-80211ocb-21 that=C2=A0

>> explain= s it to the reader. If you disagree, I would like to hear your

>> view on= the relation of IEEE 1609.3 and

>> draft-i= etf-ipwave-ipv6-over-80211ocb-21.

>

> I dont real= ly disagree, just where to put it.

>

> The draft d= oes refer to 1609.3, in Appendix C "aspects introduced by

> OCB to 802.= 11".=C2=A0 The vehicular networking draft

> (draft-ietf= -ipwave-vehicular-networking-01) also refers to it right at

> the beginni= ng.

>

> IPv6-over-O= CB sounds like an explanation.=C2=A0 As such, I suggest we first

> write more = precisely that "IPv6-over-OCB is a profile of 1609.3" and =

> then put it= into the vehicular networking draft.

>

> How could t= hat be written?

>

> Alex=

>

________________= _______________________________

its mailing list=

its@ietf.org<= /font>

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


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


--000000000000bb52790567e7b87f-- From nobody Wed Mar 21 01:31: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 E0ADD126CC4 for ; Wed, 21 Mar 2018 01:31:45 -0700 (PDT) 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 if5xkghZKwks for ; Wed, 21 Mar 2018 01:31:44 -0700 (PDT) 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 18BD5120724 for ; Wed, 21 Mar 2018 01:31:44 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id q71-v6so3641691oic.6 for ; Wed, 21 Mar 2018 01:31:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ctxpZGIcv/p19eovGKI0EYvmPIRyZPA01ms2yOHYmIk=; b=VOsE/4BBYf3ZmMX2wnzxWrHGTXfl7y2IkG/w1dnENKJFbrifSg5NUIWmsxbT6Bwg08 jEmJ4CxkxhtZu2Uus0po6wWZQBlXxsbxzrVvhSBt45s8KNgCfinP4BbqCL73VpE9ib7g ufaCvFyyN4bov7mO8OfdMWGQVgSaDKEumCq8DJy68mOckis2LraL32/uVOYYqaKA86C7 g74K1nwlwI4ROOHdZVjZ2nkg73oMjslmQ1mVzGSi4+hrvKUcO4aKqNAMPNhDt4ZUKi62 LwoaKn4IXidMxEpWfF32eTpf4PTGeMhOQOo+zwNgNKmxeB8e9n5JfrlwlK97WI7hGpde ogQw== 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=ctxpZGIcv/p19eovGKI0EYvmPIRyZPA01ms2yOHYmIk=; b=iPSDXW8XSVsTmCtR3ZZS0JS1OfoybhkcyYH1BAsLWdrWGtDIluJm3Zo1d8dD0Kn5OK LGxxzSEVNNZkaCfucmC6jNJ0VTG2Y+D01sGtLbUYJtrvtuekn+Y8TKJ4mz5AIZxqPyDX O9rI8CP0MmsHjab5kZhVZGMp7ljVrv72imtJZw+/2Ysqvb3dxQrA7gZxNFCjPLSYHEzz cgtz4G43WW1IU/ti1kfdng8f9eAFAafnJCZutUH3p9RuRYDXlDXOWBM3WZcCPwJNL71l aT2r7CxLHOedjjiNapJzGvIxiN2dWuTHJXClZW+xRhgkyBXsY5SuQvTZOnXtlcMEBYJC MtXw== X-Gm-Message-State: AElRT7HWsTDYn2hOuUKxYn9RFxp5uxhDRxt+XWc96eVOCKr7tjygDE2R P1ePNCTtILIuxjUxdcIvpkBa1nxvvYRDp+JZ6Tw= X-Google-Smtp-Source: AG47ELuuWzcePr5LVuyIr8jKKIgS7f1swZARx8zPFWNluQeSCdHdjwdQzZ4bOsK3cIIuHzwVnae1Oiq7c5nfIGnL6+0= X-Received: by 10.202.48.198 with SMTP id w189mr8762005oiw.29.1521621103544; Wed, 21 Mar 2018 01:31:43 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:1442:0:0:0:0:0 with HTTP; Wed, 21 Mar 2018 01:31:42 -0700 (PDT) In-Reply-To: <006a01d3c056$43e26fb0$cba74f10$@gmail.com> References: <660BFCF2CF184B2C8ACA0743EA9BBB54@SRA6> <006a01d3c056$43e26fb0$cba74f10$@gmail.com> From: Abdussalam Baryun Date: Wed, 21 Mar 2018 10:31:42 +0200 Message-ID: To: =?UTF-8?Q?Fran=C3=A7ois_Simon?= Cc: Russ Housley , its Content-Type: multipart/alternative; boundary="001a113cc5b85c0cd80567e805f8" Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 08:31:46 -0000 --001a113cc5b85c0cd80567e805f8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 On Tue, Mar 20, 2018 at 4:18 PM, Fran=C3=A7ois Simon w= rote: > MUST ..... AC_BK does not make sense. Fygs > > -----Original Message----- > From: its On Behalf Of Russ Housley > Sent: Monday, March 19, 2018 11:14 AM > To: its@ietf.org > Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data > > In the session earlier today, Alex offered text to resolve this topic. H= e > said: > > The IPv6 packet transmitted on 802.11-OCB MUST be immediately preceded > by a Logical Link Control (LLC) header and an 802.11 header. In the > LLC header, and in accordance with the EtherType Protocol > Discrimination (EPD), the value of the Type field MUST be set to > 0x86DD (IPv6). In the 802.11 header, the value of the Subtype > sub-field in the Frame Control field MUST be set to 8 (i.e. 'QoS > Data'); the value of the Traffic Identifier (TID) sub-field of the QoS > Control field of the 802.11 header MUST be set to binary 001 (i.e. > User Priority 'Background', QoS Access Category 'AC_BK'). > > No one in the room raised any concern with this text. If you have a > concern, please speak on the list now. > > In a another part of the meeting, J=C3=A9r=C3=B4me talked about Mapping I= P to Access > Category in 802.11-OCB. It was pointed out that RFC 8325 was recently > published on the standards track. Tony Li pointed out that there is no > integrity protection for these bits. > > As an individual, I wonder if it would be better to say something like: > If DiffServ is being used, set the QoS Access Category as described in RF= C > 8325, otherwise set the QoS Access Category of 'AC_BK'. > > What do others think? > > Russ > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > --001a113cc5b85c0cd80567e805f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1

On Tue, Mar 20, 2018 at 4:18 PM, Fran=C3=A7ois Simon <fygsimon@gm= ail.com> wrote:
MUST ..... = AC_BK does not make sense.=C2=A0 =C2=A0 Fygs

-----Original Message-----
From: its <its-bounces@ietf.org<= /a>> On Behalf Of Russ Housley
Sent: Monday, March 19, 2018 11:14 AM
To: its@ietf.org
Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data

In the session earlier today, Alex offered text to resolve this topic.=C2= =A0 He said:

=C2=A0 =C2=A0The IPv6 packet transmitted on 802.11-OCB MUST be immediately = preceded
=C2=A0 =C2=A0by a Logical Link Control (LLC) header and an 802.11 header.= =C2=A0 In the
=C2=A0 =C2=A0LLC header, and in accordance with the EtherType Protocol
=C2=A0 =C2=A0Discrimination (EPD), the value of the Type field MUST be set = to
=C2=A0 =C2=A00x86DD (IPv6).=C2=A0 In the 802.11 header, the value of the Su= btype
=C2=A0 =C2=A0sub-field in the Frame Control field MUST be set to 8 (i.e. &#= 39;QoS
=C2=A0 =C2=A0Data'); the value of the Traffic Identifier (TID) sub-fiel= d of the QoS
=C2=A0 =C2=A0Control field of the 802.11 header MUST be set to binary 001 (= i.e.
=C2=A0 =C2=A0User Priority 'Background', QoS Access Category 'A= C_BK').

No one in the room raised any concern with this text.=C2=A0 If you have a c= oncern, please speak on the list now.

In a another part of the meeting, J=C3=A9r=C3=B4me talked about Mapping IP = to Access Category in 802.11-OCB.=C2=A0 It was pointed out that RFC 8325 wa= s recently published on the standards track.=C2=A0 Tony Li pointed out that= there is no integrity protection for these bits.

As an individual, I wonder if it would be better to say something like:=C2= =A0 If DiffServ is being used, set the QoS Access Category as described in = RFC 8325, otherwise set the QoS Access Category of 'AC_BK'.

What do others think?

Russ

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

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

--001a113cc5b85c0cd80567e805f8-- From nobody Wed Mar 21 03: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 AE9F9120721 for ; Wed, 21 Mar 2018 03:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, 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 WgmWa7xFvaXv for ; Wed, 21 Mar 2018 03:19:26 -0700 (PDT) Received: from smtp2.eurecom.fr (smtp2.eurecom.fr [193.55.113.211]) by ietfa.amsl.com (Postfix) with ESMTP id 9441812420B for ; Wed, 21 Mar 2018 03:19:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.48,339,1517871600"; d="scan'208,217";a="7806858" Received: from monza.eurecom.fr ([192.168.106.15]) by drago2i.eurecom.fr with ESMTP; 21 Mar 2018 11:19:24 +0100 Received: from xerus29 (unknown [192.168.200.13]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by monza.eurecom.fr (Postfix) with ESMTPSA id BD51D12AC; Wed, 21 Mar 2018 11:19:23 +0100 (CET) From: =?utf-8?B?SsOpcsO0bWUgSMOkcnJp?= To: "'Abdussalam Baryun'" , =?utf-8?Q?'Fran=C3=A7ois_Simon'?= Cc: "'Tijink Jasja'" , "'Kevin Smith'" , "'Alexandre Petrescu'" , "'its'" References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <5cc6bd32-0812-288a-2db0-b0de53626f1e@gmail.com> <009c01d3c052$f0a78cc0$d1f6a640$@gmail.com> In-Reply-To: Date: Wed, 21 Mar 2018 11:19:23 +0100 Organization: EURECOM Message-ID: <007b01d3c0fe$15ad9540$4108bfc0$@eurecom.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007C_01D3C106.77792930" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGaWEJkAry2Qz1njSL6GO9twDWKnAFWsqpgAtM2FBoByWWRLwGhCIhQArm6hnYCVeWkAKPoKtQw Content-Language: en-us Archived-At: Subject: Re: [ipwave] =?utf-8?q?=5Bipwave=C3=AE=5D_IPv6-over-OCB_as_a_profile?= =?utf-8?q?_of_1609_WAVE?= X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 10:19:29 -0000 This is a multipart message in MIME format. ------=_NextPart_000_007C_01D3C106.77792930 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Dear all, =20 I support the feedback from Mr. Simon and Baryun=E2=80=A6As said before = (but not loud enough) this document is not linked to IEEE 1609.3. Adding = this would make it confusing. =20 However, we could add something like: =E2=80=9Cthis document describes = an alternative mechanism to the IPv6 configuration described in = 1609.3=E2=80=9D, if people really want to see 1609.3 stated in this = work. BR, =20 J=C3=A9r=C3=B4me =20 From: its [mailto:its-bounces@ietf.org] On Behalf Of Abdussalam Baryun Sent: Wednesday 21 March 2018 09:10 To: Fran=C3=A7ois Simon Cc: Tijink Jasja; Kevin Smith; Alexandre Petrescu; its Subject: Re: [ipwave] [ipwave=C3=AE] IPv6-over-OCB as a profile of 1609 = WAVE =20 +1 =20 AB =20 On Tue, Mar 20, 2018 at 3:54 PM, Fran=C3=A7ois Simon = wrote: This document is a profile based on IEEE 1609.3: it introduces = additional requirements and specifications that do not violate that = base standard. For my part I find addition of this text neutral and ok, although I am = not sure what is a profile for 1609 WAVE. In Bluetooth, a 'profile' is = something very much precise, like 'LAN profile', etc. I am NOT ok with it: 1) - I did not think that IEEE 1609 Series was in scope of the document; 2) - OCB is NOT a profile of 1609 WAVE. See previously sent definition. Fygs -----Original Message----- From: its On Behalf Of Alexandre Petrescu Sent: Sunday, March 18, 2018 12:16 PM To: its@ietf.org Cc: Tijink Jasja ; Kevin Smith = Subject: Re: [ipwave] [ipwave=C3=AE] IPv6-over-OCB as a profile of 1609 = WAVE Hi IPWAVErs, Do you disagree we add this phrase in the Introduction: > This document is a profile based on IEEE 1609.3: it introduces=20 > additional requirements and specifications that do not violate that=20 > base standard. For my part I find addition of this text neutral and ok, although I am = not sure what is a profile for 1609 WAVE. In Bluetooth, a 'profile' is = something very much precise, like 'LAN profile', etc. Alex =20 Le 17/03/2018 =C3=A0 13:22, Tijink Jasja a =C3=A9crit : > Hello Alex, >=20 > Can we put something at the beginning of=20 > draft-ietf-ipwave-ipv6-over-80211ocb-21, maybe in the introduction? > I suggest some language like the following: >=20 > This document is a profile based on IEEE 1609.3: it introduces=20 > additional requirements and specifications that do not violate that=20 > base standard. >=20 > Regards Jasja >=20 >=20 > -----Urspr=C3=BCngliche Nachricht----- Von: Alexandre Petrescu=20 > [ = mailto:alexandre.petrescu@gmail.com] Gesendet: Samstag, 17. M=C3=A4rz > 2018 12:23 An: Tijink Jasja < = Jasja.Tijink@kapsch.net> Cc: Kevin Smith=20 > < kevin.s.smith@cox.net>; = its@ietf.org Betreff: Re: [ipwave] ipwave -=20 > comments and concerns - 1609 WAVE, EPD - towards resolution >=20 > Hello Jasja, >=20 > Le 16/03/2018 =C3=A0 19:02, Tijink Jasja a =C3=A9crit : >> Hello Alex, >>=20 >> in addition to Kevin's points, I would like to mention that: >>=20 >> 1. I welcome your proposal for the additional text that specifies=20 >> QoS. This is necessary for operation in Europe (the specification for = >> the access layer can be found in ETSI EN 302 663, where clause >> 4.6 says that QoS shall be used). >=20 > Noted. >=20 >> 2. My understanding of the discussion below is that >> draft-ietf-ipwave-ipv6-over-80211ocb-21 is "based on" IEEE 1609.3 in=20 >> that it is compliant with it (I didn't find any "violation of IEEE=20 >> 1609.3), and adds additional restrictions and /or specifications=20 >> (such a MTU size, AC_BK, RFC8064, etc.). In that sense=20 >> draft-ietf-ipwave-ipv6-over-80211ocb-21 is a profile of IEEE 1609.3.=20 >> I would suggest making that very clear, with a short=20 >> sentence/paragraph in draft-ietf-ipwave-ipv6-over-80211ocb-21 that =20 >> explains it to the reader. If you disagree, I would like to hear your = >> view on the relation of IEEE 1609.3 and=20 >> draft-ietf-ipwave-ipv6-over-80211ocb-21. >=20 > I dont really disagree, just where to put it. >=20 > The draft does refer to 1609.3, in Appendix C "aspects introduced by=20 > OCB to 802.11". The vehicular networking draft > (draft-ietf-ipwave-vehicular-networking-01) also refers to it right at = > the beginning. >=20 > IPv6-over-OCB sounds like an explanation. As such, I suggest we first = > write more precisely that "IPv6-over-OCB is a profile of 1609.3" and=20 > then put it into the vehicular networking draft. >=20 > How could that be written? >=20 > Alex >=20 _______________________________________________ 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 ------=_NextPart_000_007C_01D3C106.77792930 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Dear all,

 

I support the feedback from Mr. Simon and Baryun=E2=80=A6As said = before (but not loud enough) this document is not linked to IEEE 1609.3. = Adding this would make it confusing.

 

However, we could add something like: =E2=80=9Cthis document = describes an alternative mechanism to the IPv6 configuration described = in 1609.3=E2=80=9D, if people really want to see 1609.3 stated in this = work.


BR,

 

J=C3=A9r=C3=B4me

 

From:= = its [mailto:its-bounces@ietf.org] On Behalf Of Abdussalam = Baryun
Sent: Wednesday 21 March 2018 09:10
To: = Fran=C3=A7ois Simon
Cc: Tijink Jasja; Kevin Smith; Alexandre = Petrescu; its
Subject: Re: [ipwave] [ipwave=C3=AE] = IPv6-over-OCB as a profile of 1609 WAVE

 

+1

 

AB

 

On Tue, = Mar 20, 2018 at 3:54 PM, Fran=C3=A7ois Simon <fygsimon@gmail.com> = wrote:

This document is a profile = based on IEEE 1609.3: it introduces additional requirements and = specifications that do not violate that  base = standard.

For my part I find addition = of this text neutral and ok, although I am not sure what is a profile = for 1609 WAVE.  In Bluetooth, a 'profile' is something very much = precise, like 'LAN profile', etc.

I am NOT ok with = it:

1) - I did not think that = IEEE 1609 Series was in scope of the = document;

2) - OCB is NOT a profile = of 1609 WAVE.  See previously sent = definition.

Fygs

-----Original = Message-----
From: its <its-bounces@ietf.org> On Behalf Of Alexandre = Petrescu
Sent: Sunday, March 18, 2018 12:16 PM
To: its@ietf.org
Cc: = Tijink Jasja <Jasja.Tijink@kapsch.net>; Kevin Smith <kevin.s.smith@cox.net>
Subject: Re: [ipwave] = [ipwave=C3=AE] IPv6-over-OCB as a profile of 1609 = WAVE

Hi = IPWAVErs,

Do you disagree we add this = phrase in the Introduction:

> This document is a = profile based on IEEE 1609.3: it introduces =

> additional = requirements and specifications that do not violate that =

> base = standard.

For my part I find addition = of this text neutral and ok, although I am not sure what is a profile = for 1609 WAVE.  In Bluetooth, a 'profile' is something very much = precise, like 'LAN profile', etc.

Alex

 

Le 17/03/2018 =C3=A0 13:22, = Tijink Jasja a =C3=A9crit :

> Hello = Alex,

> =

> Can we put something = at the beginning of

> = draft-ietf-ipwave-ipv6-over-80211ocb-21, maybe in the = introduction?

> I suggest some = language like the following:

> =

> This document is a = profile based on IEEE 1609.3: it introduces =

> additional = requirements and specifications that do not violate that =

> base = standard.

> =

> Regards = Jasja

> =

> =

> = -----Urspr=C3=BCngliche Nachricht----- Von: Alexandre Petrescu =

> [mailto:alexandre.petrescu@gm= ail.com] = Gesendet: Samstag, 17. M=C3=A4rz

> 2018 12:23 An: Tijink = Jasja <Jasja.Tijink@kapsch.net> Cc: Kevin = Smith

> <kevin.s.smith@cox.net= >; its@ietf.org Betreff: Re: [ipwave] = ipwave -

> comments and concerns = - 1609 WAVE, EPD - towards resolution

> =

> Hello = Jasja,

> =

> Le 16/03/2018 =C3=A0 = 19:02, Tijink Jasja a =C3=A9crit :

>> Hello = Alex,

>> =

>> in addition to = Kevin's points, I  would like to mention = that:

>> =

>> 1. I welcome your = proposal for the additional text that specifies =

>> QoS. This is = necessary for operation in Europe (the specification for =

>> the access layer = can be found in ETSI EN 302 663, where = clause

>> 4.6 says that QoS = shall be used).

> =

> = Noted.

> =

>> 2. My = understanding of the discussion below is = that

>> = draft-ietf-ipwave-ipv6-over-80211ocb-21 is "based on" IEEE = 1609.3 in

>> that it is = compliant with it (I didn't find any "violation of IEEE =

>> 1609.3), and adds = additional restrictions and /or specifications =

>> (such a MTU size, = AC_BK, RFC8064, etc.). In that sense

>> = draft-ietf-ipwave-ipv6-over-80211ocb-21 is a profile of IEEE 1609.3. =

>> I would suggest = making that very clear, with a short

>> sentence/paragraph = in draft-ietf-ipwave-ipv6-over-80211ocb-21 that  =

>> explains it to the = reader. If you disagree, I would like to hear your =

>> view on the = relation of IEEE 1609.3 and

>> = draft-ietf-ipwave-ipv6-over-80211ocb-21.

> =

> I dont really = disagree, just where to put it.

> =

> The draft does refer = to 1609.3, in Appendix C "aspects introduced by =

> OCB to = 802.11".  The vehicular networking = draft

> = (draft-ietf-ipwave-vehicular-networking-01) also refers to it right at =

> the = beginning.

> =

> IPv6-over-OCB sounds = like an explanation.  As such, I suggest we first =

> write more precisely = that "IPv6-over-OCB is a profile of 1609.3" and =

> then put it into the = vehicular networking draft.

> =

> How could that be = written?

> =

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

 

------=_NextPart_000_007C_01D3C106.77792930-- From nobody Wed Mar 21 03:22: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 666D7120721 for ; Wed, 21 Mar 2018 03:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 EqPQT9cPD1T4 for ; Wed, 21 Mar 2018 03:22:10 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 C7A1D12E87F for ; Wed, 21 Mar 2018 03:22:09 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id l16so8788698wmh.3 for ; Wed, 21 Mar 2018 03:22:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=AJQ98JcRKDTBaeVg8jxCEEXNgP3LiDPuYT1T7/F5048=; b=YiELsro5kXF6u1oOEtIr/hJ+sjPOsE63I99jHWFFmoqrvufkfWVxUj9ow6NC7MwSQH hgLD//jOgy8S2ZkOs8P1qfAxE/8GO+rwy/u9WTjgyLJ8qwcEQ5IbifOOHfStIpl5IVma RKXKGXmI9IAo51FpXBwzFe3FqewCynyVqQ5HTBUbJIbnHuQQw5rXUkoXabRfSTXJceGI J1e5I6qHvU0cY5N4LmR8ufeeuMzWjJj/i2soGnBHcP31nSmKl4n/zxAW8l2ed/qpxBNj oFWVdyuVh+R+nlAlR41HjGk0gQVpF5fSt7VIjkzlLwTs6OCzJ4akoagWtCrg1LuVoBSU 6Wig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=AJQ98JcRKDTBaeVg8jxCEEXNgP3LiDPuYT1T7/F5048=; b=i9qVuu69aOHzBZXzTZ4jNbUSHxdNpFbD1j+zR54784LonxDmvcN/s4lHcY+sMix0fU gfH18+kH2NSmNMQ1oJZ+tOg9RmhORVkxzw+s78EAlC0yHzfiGGeR7PK8Y/8ESug1Q+Ul NTjgNDeIzhUf3/51kemHbH0K1I7i8aIFaLBIRs0gVZkdRB0ZhkE2aWQGVhTBSGSVjgIF gLmxc6jqg3AWhV3aYTyBJBmrqwnqRcXm/7uROE0xVXb0IndX3wyvpKnLnvM2vzz0E+7K 2JWRdVZrPRimmfIEp4c3Q+HJ2CV3OVylJoXCya9wWK5/SeoXYE2nj7jzqjdTjkP05eFI nLgg== X-Gm-Message-State: AElRT7HE3tW6YbYggi4bVqHNzRKJN36+QMOoQHVlo47YKUE6dRIUPYPx 7WRnIlLVTged3ZXwYTt6d20= X-Google-Smtp-Source: AG47ELuL6+tVKrSFcwPoDsfRKtYEf525b3q2IOU5UmUArTAajXe1uG+Yw79b7XaOA55lc5d7InUzHA== X-Received: by 10.28.191.70 with SMTP id p67mr2414036wmf.17.1521627728379; Wed, 21 Mar 2018 03:22:08 -0700 (PDT) Received: from ?IPv6:2001:67c:1232:144:20aa:5a12:9c97:c27? ([2001:67c:1232:144:20aa:5a12:9c97:c27]) by smtp.gmail.com with ESMTPSA id c14sm3222841wrd.17.2018.03.21.03.22.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Mar 2018 03:22:07 -0700 (PDT) Sender: Tony Li From: tony.li@tony.li Message-Id: <483EE910-B566-4760-B36B-91575C07F6D9@tony.li> Content-Type: multipart/alternative; boundary="Apple-Mail=_BB37EA64-B25B-4986-AFFE-F10586912602" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 21 Mar 2018 10:22:04 +0000 In-Reply-To: <007b01d3c0fe$15ad9540$4108bfc0$@eurecom.fr> Cc: Abdussalam Baryun , =?utf-8?Q?Fran=C3=A7ois_Simon?= , Tijink Jasja , Kevin Smith , Alexandre Petrescu , its To: =?utf-8?B?SsOpcsO0bWUgSMOkcnJp?= References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <5cc6bd32-0812-288a-2db0-b0de53626f1e@gmail.com> <009c01d3c052$f0a78cc0$d1f6a640$@gmail.com> <007b01d3c0fe$15ad9540$4108bfc0$@eurecom.fr> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [ipwave] =?utf-8?q?=5Bipwave=C3=AE=5D_IPv6-over-OCB_as_a_profile?= =?utf-8?q?_of_1609_WAVE?= X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 10:22:11 -0000 --Apple-Mail=_BB37EA64-B25B-4986-AFFE-F10586912602 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > However, we could add something like: =E2=80=9Cthis document describes = an alternative mechanism to the IPv6 configuration described in = 1609.3=E2=80=9D, if people really want to see 1609.3 stated in this = work. I=E2=80=99m fine with this and would suggest that we use the word = =E2=80=9Creplacement=E2=80=9D rather than =E2=80=9Calternative=E2=80=9D. = We should not endorse two IPv6 encapsulations. Tony --Apple-Mail=_BB37EA64-B25B-4986-AFFE-F10586912602 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

However, we could add something = like: =E2=80=9Cthis document describes an alternative mechanism to the = IPv6 configuration described in 1609.3=E2=80=9D, if people really want = to see 1609.3 stated in this work.


I=E2=80=99m fine with = this and would suggest that we use the word =E2=80=9Creplacement=E2=80=9D = rather than =E2=80=9Calternative=E2=80=9D.  We should not endorse = two IPv6 encapsulations.

Tony


= --Apple-Mail=_BB37EA64-B25B-4986-AFFE-F10586912602-- From nobody Wed Mar 21 03:26: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 3171B12DA17 for ; Wed, 21 Mar 2018 03:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=onboardsecurity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NrEOuwAQepT0 for ; Wed, 21 Mar 2018 03:26:34 -0700 (PDT) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96FA912420B for ; Wed, 21 Mar 2018 03:26:34 -0700 (PDT) Received: by mail-pg0-x22d.google.com with SMTP id t9so397827pgo.3 for ; Wed, 21 Mar 2018 03:26:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onboardsecurity.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ycRunIO/qP7k5QvtU76Ega6QjNNcd3r8NN8PXgVCDPA=; b=F9n4wIQtR8bpNFRoid3KIoRs+2a892DGpC8tMp+/jjVYGYvajFYoxZPZ/DhbzvunJG hQvpgZ3xEgqYDYpE6zrBObEXJ98iTVpyINiINRQZcWBROVGNzNJqyFAPDbg4KCAwfTwT T32gHi25HdQCo7fABusn5R5F+aW5ImYp3RryQ= 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=ycRunIO/qP7k5QvtU76Ega6QjNNcd3r8NN8PXgVCDPA=; b=WYcMO1WjmjXNmuA38Zu6CX+Kay7Emr416tPncB54Fcj03bbAe1XnqaH7W64gvgxQA1 0NAl47ZvOPYszfmusAJsoGNC1yvwwj7HZS6ItuUANos1gtBPhX5auF7/Gs4z5m6Lk1yH 0b1YxQO1MX1smKfFVOSRLqqChfJTyyWLU0gK31qDuojObWXbj9yQLtmUaXqZedlKEKr0 eNzHjMHiAoNlQy3TuX/NdnFS9CjEIwNhPmzB24GAbJLIXQzhtGgVuH1e1QukO57csE0I /yOPgkrUKqctYtYh3ZDpoddZWXsc6lw8up4KO4FS5hoTPgjvJ5X/a7H9xGn5J536jp49 7E8A== X-Gm-Message-State: AElRT7Exw67mmgGaXxpyP5suEDQmZGqrLHruJRyoOpQ4XhtG7vQghqqd vr8gom8ICG1SoBw9ard0qjeUu+wFXmVWYVjrh22Png== X-Google-Smtp-Source: AG47ELtSkybLxB6kak+vWq5NZQq2ATCSvUfklXBa2F4ud83tl78+b8PYzlcgEmkjfcywPS9OnGlnZS6VZzYq/qjTYo0= X-Received: by 10.98.97.1 with SMTP id v1mr16674153pfb.119.1521627993925; Wed, 21 Mar 2018 03:26:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.156.1 with HTTP; Wed, 21 Mar 2018 03:26:13 -0700 (PDT) In-Reply-To: <483EE910-B566-4760-B36B-91575C07F6D9@tony.li> References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <5cc6bd32-0812-288a-2db0-b0de53626f1e@gmail.com> <009c01d3c052$f0a78cc0$d1f6a640$@gmail.com> <007b01d3c0fe$15ad9540$4108bfc0$@eurecom.fr> <483EE910-B566-4760-B36B-91575C07F6D9@tony.li> From: William Whyte Date: Wed, 21 Mar 2018 06:26:13 -0400 Message-ID: To: Tony Li Cc: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , its , =?UTF-8?Q?Fran=C3=A7ois_Simon?= , Tijink Jasja , Alexandre Petrescu , Kevin Smith , Abdussalam Baryun Content-Type: multipart/alternative; boundary="94eb2c04f22a0f00d10567e9a0da" Archived-At: Subject: Re: [ipwave] =?utf-8?q?=5Bipwave=C3=AE=5D_IPv6-over-OCB_as_a_profile?= =?utf-8?q?_of_1609_WAVE?= X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 10:26:36 -0000 --94eb2c04f22a0f00d10567e9a0da Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tony -- it's an alternative mechanism for configuration, not for encapsulation, so I think "alternative" is better than "replacement" here. William On Wed, Mar 21, 2018 at 6:22 AM, wrote: > > > However, we could add something like: =E2=80=9Cthis document describes an > alternative mechanism to the IPv6 configuration described in 1609.3=E2=80= =9D, if > people really want to see 1609.3 stated in this work. > > > > I=E2=80=99m fine with this and would suggest that we use the word =E2=80= =9Creplacement=E2=80=9D > rather than =E2=80=9Calternative=E2=80=9D. We should not endorse two IPv= 6 encapsulations. > > Tony > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > --=20 PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS: wwhyte@onboardsecurity.com --94eb2c04f22a0f00d10567e9a0da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tony -- it's an alternative mechanism for configura= tion, not for encapsulation, so I think "alternative" is better t= han "replacement" here.

William

On Wed, Mar 21, 2018= at 6:22 AM, <tony.li@tony.li> wrote:


How= ever, we could add something like: =E2=80=9Cthis document describes an alte= rnative mechanism to the IPv6 configuration described in 1609.3=E2=80=9D, i= f people really want to see 1609.3 stated in this work.


I=E2=80=99m fine with this and w= ould suggest that we use the word =E2=80=9Creplacement=E2=80=9D rather than= =E2=80=9Calternative=E2=80=9D.=C2=A0 We should not endorse two IPv6 encaps= ulations.

Tony



_______________= ________________________________
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
--94eb2c04f22a0f00d10567e9a0da-- From nobody Wed Mar 21 03:58: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 D5B5412D967 for ; Wed, 21 Mar 2018 03:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.009 X-Spam-Level: X-Spam-Status: No, score=-3.009 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, RCVD_IN_MSPIKE_H5=-1, 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 (1024-bit key) header.d=kapsch.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0r5-u0jqv4qi for ; Wed, 21 Mar 2018 03:58:47 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0126.outbound.protection.outlook.com [104.47.0.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF7D7124E15 for ; Wed, 21 Mar 2018 03:58:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kapsch.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xL68mOrIewM3TMn+7fI1tTSuyl8teKNS6nszyC3reXg=; b=jrPwXLSvmH1hrUNMzjbWsR2mGp6dglg16LUfY6TUMVkoy7k+jWczeZI9W1Fq12MptKtHi+zfCynvEMgHbuPBFxBD+LqjJuvlR16F2BF6FP82GF00C+ytaAC6vmzk/LQY+nIYIteWp9BQk+LVP87qI/5//OxZzhJItj9c+LUhup0= Received: from AM0PR0302MB3380.eurprd03.prod.outlook.com (52.133.37.155) by AM0PR0302MB3233.eurprd03.prod.outlook.com (52.133.37.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.609.10; Wed, 21 Mar 2018 10:58:42 +0000 Received: from AM0PR0302MB3380.eurprd03.prod.outlook.com ([fe80::153a:2232:e7b7:7cb4]) by AM0PR0302MB3380.eurprd03.prod.outlook.com ([fe80::153a:2232:e7b7:7cb4%13]) with mapi id 15.20.0609.010; Wed, 21 Mar 2018 10:58:42 +0000 From: Tijink Jasja To: =?utf-8?B?SsOpcsO0bWUgSMOkcnJp?= , 'Abdussalam Baryun' , =?utf-8?B?J0ZyYW7Dp29pcyBTaW1vbic=?= CC: 'Kevin Smith' , 'Alexandre Petrescu' , 'its' Thread-Topic: =?utf-8?B?W2lwd2F2ZV0gIFtpcHdhdmXDrl0gSVB2Ni1vdmVyLU9DQiBhcyBhIHByb2Zp?= =?utf-8?Q?le_of_1609_WAVE?= Thread-Index: AQHTwP4jI3uxlTl5RkCnAjNH2KGUlaPaev4A Date: Wed, 21 Mar 2018 10:58:42 +0000 Message-ID: References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <5cc6bd32-0812-288a-2db0-b0de53626f1e@gmail.com> <009c01d3c052$f0a78cc0$d1f6a640$@gmail.com> <007b01d3c0fe$15ad9540$4108bfc0$@eurecom.fr> In-Reply-To: <007b01d3c0fe$15ad9540$4108bfc0$@eurecom.fr> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jasja.Tijink@kapsch.net; x-originating-ip: [80.121.42.103] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM0PR0302MB3233; 7:9tLYA7CPTbsPbAPcwFLAOLTDWZ52U6e9ngxgovGS0m2p4jj9KE7QNiJWgN1Kr0Z6K5zPEjr523bOhbZRwKEzg6Po+KVpmKOz6QynZiA9YISrv6OrSFAKJT0WQ76oHqMtBnfUmEkRFMA5TtM0rz0BvMmM0WvxOPuutzWc6JS1Pj7TS3ckA3lHLDVEtQPZG0qCOVR0elT5RQn0l5ePunu2wCpiMwkry3G91XiXXyl4F5L+kqS0li/K2HrkZQfoychk x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 71063a4f-4488-4b30-cd17-08d58f1ab5c1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:AM0PR0302MB3233; x-ms-traffictypediagnostic: AM0PR0302MB3233: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(79046362386883)(131327999870524)(85827821059158)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231221)(944501322)(52105095)(10201501046)(3002001)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:AM0PR0302MB3233; BCL:0; PCL:0; RULEID:; SRVR:AM0PR0302MB3233; x-forefront-prvs: 0618E4E7E1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(39850400004)(366004)(396003)(346002)(376002)(13464003)(189003)(199004)(186003)(66066001)(6506007)(53546011)(7696005)(6436002)(102836004)(39060400002)(8666007)(99286004)(26005)(3660700001)(55016002)(25786009)(4326008)(59450400001)(68736007)(53936002)(54896002)(6306002)(236005)(5250100002)(9686003)(76176011)(54906003)(966005)(86362001)(105586002)(2900100001)(110136005)(5660300001)(316002)(478600001)(7736002)(606006)(14454004)(6116002)(2950100002)(790700001)(3846002)(74316002)(106356001)(224303003)(3280700002)(81156014)(97736004)(561944003)(93886005)(72206003)(2906002)(33656002)(81166006)(8936002)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR0302MB3233; H:AM0PR0302MB3380.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: kapsch.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: 8+lUJuWgizX/tAsJXgCQgQLO1V2Eluty5StJYTfV7P0vdutr6VDJJWL6X18ZQYPcGU9VSgYgSPKwQsFoBO9z9MMfy2yNvNFiiCOpjFBhsrCjfkFEvttmjqZvDyFzGy/igRponrbq+sbX7CbVyW45NnJQMi421Qb5Ubzz3NcP+M+jO5sjiq7HSOhFfVmRFfStqZ/8zAUTmY7qkN3Ie1/Vsq1+Q3yKZbUn6UUfoizVFyRqkEkmAW6Cfznn4Z/FYjCKx80SyKtvetVqPW3DbVga0p9wAzPJ/EBE4/iNwPrOpHbNwCaPWGjKrl2k3wxVQ7JdpiJailXHB33tmlXLnBuYTg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM0PR0302MB3380739956201CF5A2BD2976EFAA0AM0PR0302MB3380_" MIME-Version: 1.0 X-OriginatorOrg: kapsch.net X-MS-Exchange-CrossTenant-Network-Message-Id: 71063a4f-4488-4b30-cd17-08d58f1ab5c1 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Mar 2018 10:58:42.3466 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5f9ce527-7e3e-4e83-a8a4-b6c848f85ab5 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR0302MB3233 Archived-At: Subject: Re: [ipwave] =?utf-8?q?=5Bipwave=C3=AE=5D_IPv6-over-OCB_as_a_profile?= =?utf-8?q?_of_1609_WAVE?= X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 10:58:50 -0000 --_000_AM0PR0302MB3380739956201CF5A2BD2976EFAA0AM0PR0302MB3380_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCnRoYW5rIHlvdSBhbGwgZm9yIHRoZSBmZWVkYmFjaywgYXQgbGVhc3QgSSBrbm93 IHdoYXQgZHJhZnQtaWV0Zi1pcHdhdmUtaXB2Ni1vdmVyLTgwMjExb2NiLTIyIGlzIG5vdC4gVGhh dCBpcyBoZWxwZnVsIGF0IGxlYXN0IHBhcnRseeKApg0KSSBzdGlsbCB3b25kZXIgaWYgc29tZWJv ZHkgY2FuIGV4cGxhaW4gdG8gbWUgd2hhdCBkcmFmdC1pZXRmLWlwd2F2ZS1pcHY2LW92ZXItODAy MTFvY2ItMjIgcmVhbGx5IGlzIGludGVuZGVkIHRvIGJlIGFuZCBzdGF0ZSB0aGlzIGNsZWFybHkg aW4gdGhlIGRvY3VtZW50Lg0KSSBhbSBub3QgdHJ5aW5nIHRvIGJlIHByb3ZvY2F0aXZlIG9yIG9i c3RydWN0aXZlLCBJIGp1c3Qgd291bGQgbGlrZSB0byBzZWUgY2xhcml0eS4gSSBzZWUgbWFueSAg 4oCcc2ltaWxhcml0aWVz4oCdIG9mIGRyYWZ0LWlldGYtaXB3YXZlLWlwdjYtb3Zlci04MDIxMW9j Yi0yMiB3aXRoIDE2MDkuMywgYnV0IHN0aWxsIGl0IGlzIG5vdCBhIHByb2ZpbGUsIGl0IGlzIG5v dCBpbnRlcm9wZXJhYmxlIHdpdGggaXQsIGFuZCBpdCBpcyBvdXQgb2Ygc2NvcGUgKHdoYXRldmVy IHRoYXQgbWVhbnMpLiBUaGF0IGlzIGNvbmZ1c2luZyBpZiB5b3Ugd291bGQgbGlrZSB0byBiZSBj b21wbGlhbnQgdG8gYm90aCBzdGFuZGFyZHMuDQoNCkkgc2VlIGF0IGxlYXN0IHRocmVlIGVsZW1l bnRzIGluIGRyYWZ0LWlldGYtaXB3YXZlLWlwdjYtb3Zlci04MDIxMW9jYi0yMi4gUGxlYXNlIGFk ZCBtb3JlIGlmIHlvdSB3aXNoOg0KDQoNCiAgMS4gIE92ZXIgdGhlIGFpciBmb3JtYXQgb2YgaXB2 NiBvdmVyIE9DQi4NCg0KVG8gbWUgaXQgc2VlbXMgdGhhdCBkcmFmdC1pZXRmLWlwd2F2ZS1pcHY2 LW92ZXItODAyMTFvY2ItMjIgaXMgY29tcGxpYW50IHdpdGggb3IgY29ycmVzcG9uZGluZyB0byB0 aGUgSUVFRSAxNjA5LjMgSVB2NiBtb2RlLCBidXQgcmVzdHJpY3RzIHRoZSBmcmFtZSBvcHRpb25z IHRvIFFvUyBEYXRhIHdpdGggQUNfQksgKHRoaXMgc291bmRzIGxpa2UgYSBwcm9maWxlIHRvIG1l KS4NCg0KDQogIDEuICBDb25maWd1cmF0aW9uIG9mIElQdjYNCkxldOKAmXMgY29uc2lkZXIgdGhl IGNvdW50ZXJwcm9wb3NhbDog4oCcdGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYW4gYWx0ZXJuYXRp dmUgbWVjaGFuaXNtIHRvIHRoZSBJUHY2IGNvbmZpZ3VyYXRpb24gZGVzY3JpYmVkIGluIDE2MDku M+KAnS4gSSBhbSBub3Qgc3VyZSB3aHkgaXQgaXMg4oCcYWx0ZXJuYXRpdmXigJ0gKGJ1dCBpdCBk ZXBlbmRzIG9uIGhvdyB5b3UgaW50ZXJwcmV0IHRoZSB3b3JkKSAuIElFRUUgMTYwOS4zIGFsbG93 cyBTTEFBQyB1c2luZyBSQSBvciBXUkEsIHNvIHRoZXJlIGlzIG5vdGhpbmcgYWx0ZXJuYXRpdmUg aW4gZHJhZnQtaWV0Zi1pcHdhdmUtaXB2Ni1vdmVyLTgwMjExb2NiLTIyLCBpdCBpcyBqdXN0IG1v cmUgcmVzdHJpY3RpdmUgc2luY2UgaXQgZG9lcyBub3Qgc3VwcG9ydCBXUkEuICh0aGlzIHNvdW5k cyBsaWtlIGEgcHJvZmlsZSB0byBtZSkNCg0KDQogIDEuICBFQUwuIFRoaXMgaXMgbm90IHNwZWNp ZmllZCBieSBJRUVFIDE2MDkuMyBhbmQgdG8gbWUgaXMgYW4gaW1wbGVtZW50YXRpb24gZGV0YWls LCBub3QgYW4gb3Zlci10aGUtYWlyIGZ1bmN0aW9uYWxpdHkuDQoNCkFueXRoaW5nIHRvIGFkZCBv ciBjaGFuZ2UgaW4gdGhpcyBoaWdoIGxldmVsIHN1bW1hcnk/DQoNClJlZ2FyZHMgSmFzamENCg0K DQpWb246IErDqXLDtG1lIEjDpHJyaSBbbWFpbHRvOmplcm9tZS5oYWVycmlAZXVyZWNvbS5mcl0N Ckdlc2VuZGV0OiBNaXR0d29jaCwgMjEuIE3DpHJ6IDIwMTggMTE6MTkNCkFuOiAnQWJkdXNzYWxh bSBCYXJ5dW4nIDxhYmR1c3NhbGFtYmFyeXVuQGdtYWlsLmNvbT47ICdGcmFuw6dvaXMgU2ltb24n IDxmeWdzaW1vbkBnbWFpbC5jb20+DQpDYzogVGlqaW5rIEphc2phIDxKYXNqYS5UaWppbmtAa2Fw c2NoLm5ldD47ICdLZXZpbiBTbWl0aCcgPGtldmluLnMuc21pdGhAY294Lm5ldD47ICdBbGV4YW5k cmUgUGV0cmVzY3UnIDxhbGV4YW5kcmUucGV0cmVzY3VAZ21haWwuY29tPjsgJ2l0cycgPGl0c0Bp ZXRmLm9yZz4NCkJldHJlZmY6IFJFOiBbaXB3YXZlXSBbaXB3YXZlw65dIElQdjYtb3Zlci1PQ0Ig YXMgYSBwcm9maWxlIG9mIDE2MDkgV0FWRQ0KDQpEZWFyIGFsbCwNCg0KSSBzdXBwb3J0IHRoZSBm ZWVkYmFjayBmcm9tIE1yLiBTaW1vbiBhbmQgQmFyeXVu4oCmQXMgc2FpZCBiZWZvcmUgKGJ1dCBu b3QgbG91ZCBlbm91Z2gpIHRoaXMgZG9jdW1lbnQgaXMgbm90IGxpbmtlZCB0byBJRUVFIDE2MDku My4gQWRkaW5nIHRoaXMgd291bGQgbWFrZSBpdCBjb25mdXNpbmcuDQoNCkhvd2V2ZXIsIHdlIGNv dWxkIGFkZCBzb21ldGhpbmcgbGlrZTog4oCcdGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYW4gYWx0 ZXJuYXRpdmUgbWVjaGFuaXNtIHRvIHRoZSBJUHY2IGNvbmZpZ3VyYXRpb24gZGVzY3JpYmVkIGlu IDE2MDkuM+KAnSwgaWYgcGVvcGxlIHJlYWxseSB3YW50IHRvIHNlZSAxNjA5LjMgc3RhdGVkIGlu IHRoaXMgd29yay4NCg0KQlIsDQoNCkrDqXLDtG1lDQoNCkZyb206IGl0cyBbbWFpbHRvOml0cy1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWJkdXNzYWxhbSBCYXJ5dW4NClNlbnQ6IFdl ZG5lc2RheSAyMSBNYXJjaCAyMDE4IDA5OjEwDQpUbzogRnJhbsOnb2lzIFNpbW9uDQpDYzogVGlq aW5rIEphc2phOyBLZXZpbiBTbWl0aDsgQWxleGFuZHJlIFBldHJlc2N1OyBpdHMNClN1YmplY3Q6 IFJlOiBbaXB3YXZlXSBbaXB3YXZlw65dIElQdjYtb3Zlci1PQ0IgYXMgYSBwcm9maWxlIG9mIDE2 MDkgV0FWRQ0KDQorMQ0KDQpBQg0KDQpPbiBUdWUsIE1hciAyMCwgMjAxOCBhdCAzOjU0IFBNLCBG cmFuw6dvaXMgU2ltb24gPGZ5Z3NpbW9uQGdtYWlsLmNvbTxtYWlsdG86Znlnc2ltb25AZ21haWwu Y29tPj4gd3JvdGU6DQoNClRoaXMgZG9jdW1lbnQgaXMgYSBwcm9maWxlIGJhc2VkIG9uIElFRUUg MTYwOS4zOiBpdCBpbnRyb2R1Y2VzIGFkZGl0aW9uYWwgcmVxdWlyZW1lbnRzIGFuZCBzcGVjaWZp Y2F0aW9ucyB0aGF0IGRvIG5vdCB2aW9sYXRlIHRoYXQgIGJhc2Ugc3RhbmRhcmQuDQoNCkZvciBt eSBwYXJ0IEkgZmluZCBhZGRpdGlvbiBvZiB0aGlzIHRleHQgbmV1dHJhbCBhbmQgb2ssIGFsdGhv dWdoIEkgYW0gbm90IHN1cmUgd2hhdCBpcyBhIHByb2ZpbGUgZm9yIDE2MDkgV0FWRS4gIEluIEJs dWV0b290aCwgYSAncHJvZmlsZScgaXMgc29tZXRoaW5nIHZlcnkgbXVjaCBwcmVjaXNlLCBsaWtl ICdMQU4gcHJvZmlsZScsIGV0Yy4NCg0KSSBhbSBOT1Qgb2sgd2l0aCBpdDoNCg0KMSkgLSBJIGRp ZCBub3QgdGhpbmsgdGhhdCBJRUVFIDE2MDkgU2VyaWVzIHdhcyBpbiBzY29wZSBvZiB0aGUgZG9j dW1lbnQ7DQoNCjIpIC0gT0NCIGlzIE5PVCBhIHByb2ZpbGUgb2YgMTYwOSBXQVZFLiAgU2VlIHBy ZXZpb3VzbHkgc2VudCBkZWZpbml0aW9uLg0KDQpGeWdzDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBpdHMgPGl0cy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzppdHMtYm91bmNl c0BpZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBBbGV4YW5kcmUgUGV0cmVzY3UNClNlbnQ6IFN1bmRh eSwgTWFyY2ggMTgsIDIwMTggMTI6MTYgUE0NClRvOiBpdHNAaWV0Zi5vcmc8bWFpbHRvOml0c0Bp ZXRmLm9yZz4NCkNjOiBUaWppbmsgSmFzamEgPEphc2phLlRpamlua0BrYXBzY2gubmV0PG1haWx0 bzpKYXNqYS5UaWppbmtAa2Fwc2NoLm5ldD4+OyBLZXZpbiBTbWl0aCA8a2V2aW4ucy5zbWl0aEBj b3gubmV0PG1haWx0bzprZXZpbi5zLnNtaXRoQGNveC5uZXQ+Pg0KU3ViamVjdDogUmU6IFtpcHdh dmVdIFtpcHdhdmXDrl0gSVB2Ni1vdmVyLU9DQiBhcyBhIHByb2ZpbGUgb2YgMTYwOSBXQVZFDQoN CkhpIElQV0FWRXJzLA0KDQpEbyB5b3UgZGlzYWdyZWUgd2UgYWRkIHRoaXMgcGhyYXNlIGluIHRo ZSBJbnRyb2R1Y3Rpb246DQoNCj4gVGhpcyBkb2N1bWVudCBpcyBhIHByb2ZpbGUgYmFzZWQgb24g SUVFRSAxNjA5LjM6IGl0IGludHJvZHVjZXMNCg0KPiBhZGRpdGlvbmFsIHJlcXVpcmVtZW50cyBh bmQgc3BlY2lmaWNhdGlvbnMgdGhhdCBkbyBub3QgdmlvbGF0ZSB0aGF0DQoNCj4gYmFzZSBzdGFu ZGFyZC4NCg0KRm9yIG15IHBhcnQgSSBmaW5kIGFkZGl0aW9uIG9mIHRoaXMgdGV4dCBuZXV0cmFs IGFuZCBvaywgYWx0aG91Z2ggSSBhbSBub3Qgc3VyZSB3aGF0IGlzIGEgcHJvZmlsZSBmb3IgMTYw OSBXQVZFLiAgSW4gQmx1ZXRvb3RoLCBhICdwcm9maWxlJyBpcyBzb21ldGhpbmcgdmVyeSBtdWNo IHByZWNpc2UsIGxpa2UgJ0xBTiBwcm9maWxlJywgZXRjLg0KDQpBbGV4DQoNCg0KTGUgMTcvMDMv MjAxOCDDoCAxMzoyMiwgVGlqaW5rIEphc2phIGEgw6ljcml0IDoNCg0KPiBIZWxsbyBBbGV4LA0K DQo+DQoNCj4gQ2FuIHdlIHB1dCBzb21ldGhpbmcgYXQgdGhlIGJlZ2lubmluZyBvZg0KDQo+IGRy YWZ0LWlldGYtaXB3YXZlLWlwdjYtb3Zlci04MDIxMW9jYi0yMSwgbWF5YmUgaW4gdGhlIGludHJv ZHVjdGlvbj8NCg0KPiBJIHN1Z2dlc3Qgc29tZSBsYW5ndWFnZSBsaWtlIHRoZSBmb2xsb3dpbmc6 DQoNCj4NCg0KPiBUaGlzIGRvY3VtZW50IGlzIGEgcHJvZmlsZSBiYXNlZCBvbiBJRUVFIDE2MDku MzogaXQgaW50cm9kdWNlcw0KDQo+IGFkZGl0aW9uYWwgcmVxdWlyZW1lbnRzIGFuZCBzcGVjaWZp Y2F0aW9ucyB0aGF0IGRvIG5vdCB2aW9sYXRlIHRoYXQNCg0KPiBiYXNlIHN0YW5kYXJkLg0KDQo+ DQoNCj4gUmVnYXJkcyBKYXNqYQ0KDQo+DQoNCj4NCg0KPiAtLS0tLVVyc3Byw7xuZ2xpY2hlIE5h Y2hyaWNodC0tLS0tIFZvbjogQWxleGFuZHJlIFBldHJlc2N1DQoNCj4gW21haWx0bzphbGV4YW5k cmUucGV0cmVzY3VAZ21haWwuY29tXSBHZXNlbmRldDogU2Ftc3RhZywgMTcuIE3DpHJ6DQoNCj4g MjAxOCAxMjoyMyBBbjogVGlqaW5rIEphc2phIDxKYXNqYS5UaWppbmtAa2Fwc2NoLm5ldDxtYWls dG86SmFzamEuVGlqaW5rQGthcHNjaC5uZXQ+PiBDYzogS2V2aW4gU21pdGgNCg0KPiA8a2V2aW4u cy5zbWl0aEBjb3gubmV0PG1haWx0bzprZXZpbi5zLnNtaXRoQGNveC5uZXQ+PjsgaXRzQGlldGYu b3JnPG1haWx0bzppdHNAaWV0Zi5vcmc+IEJldHJlZmY6IFJlOiBbaXB3YXZlXSBpcHdhdmUgLQ0K DQo+IGNvbW1lbnRzIGFuZCBjb25jZXJucyAtIDE2MDkgV0FWRSwgRVBEIC0gdG93YXJkcyByZXNv bHV0aW9uDQoNCj4NCg0KPiBIZWxsbyBKYXNqYSwNCg0KPg0KDQo+IExlIDE2LzAzLzIwMTggw6Ag MTk6MDIsIFRpamluayBKYXNqYSBhIMOpY3JpdCA6DQoNCj4+IEhlbGxvIEFsZXgsDQoNCj4+DQoN Cj4+IGluIGFkZGl0aW9uIHRvIEtldmluJ3MgcG9pbnRzLCBJICB3b3VsZCBsaWtlIHRvIG1lbnRp b24gdGhhdDoNCg0KPj4NCg0KPj4gMS4gSSB3ZWxjb21lIHlvdXIgcHJvcG9zYWwgZm9yIHRoZSBh ZGRpdGlvbmFsIHRleHQgdGhhdCBzcGVjaWZpZXMNCg0KPj4gUW9TLiBUaGlzIGlzIG5lY2Vzc2Fy eSBmb3Igb3BlcmF0aW9uIGluIEV1cm9wZSAodGhlIHNwZWNpZmljYXRpb24gZm9yDQoNCj4+IHRo ZSBhY2Nlc3MgbGF5ZXIgY2FuIGJlIGZvdW5kIGluIEVUU0kgRU4gMzAyIDY2Mywgd2hlcmUgY2xh dXNlDQoNCj4+IDQuNiBzYXlzIHRoYXQgUW9TIHNoYWxsIGJlIHVzZWQpLg0KDQo+DQoNCj4gTm90 ZWQuDQoNCj4NCg0KPj4gMi4gTXkgdW5kZXJzdGFuZGluZyBvZiB0aGUgZGlzY3Vzc2lvbiBiZWxv dyBpcyB0aGF0DQoNCj4+IGRyYWZ0LWlldGYtaXB3YXZlLWlwdjYtb3Zlci04MDIxMW9jYi0yMSBp cyAiYmFzZWQgb24iIElFRUUgMTYwOS4zIGluDQoNCj4+IHRoYXQgaXQgaXMgY29tcGxpYW50IHdp dGggaXQgKEkgZGlkbid0IGZpbmQgYW55ICJ2aW9sYXRpb24gb2YgSUVFRQ0KDQo+PiAxNjA5LjMp LCBhbmQgYWRkcyBhZGRpdGlvbmFsIHJlc3RyaWN0aW9ucyBhbmQgL29yIHNwZWNpZmljYXRpb25z DQoNCj4+IChzdWNoIGEgTVRVIHNpemUsIEFDX0JLLCBSRkM4MDY0LCBldGMuKS4gSW4gdGhhdCBz ZW5zZQ0KDQo+PiBkcmFmdC1pZXRmLWlwd2F2ZS1pcHY2LW92ZXItODAyMTFvY2ItMjEgaXMgYSBw cm9maWxlIG9mIElFRUUgMTYwOS4zLg0KDQo+PiBJIHdvdWxkIHN1Z2dlc3QgbWFraW5nIHRoYXQg dmVyeSBjbGVhciwgd2l0aCBhIHNob3J0DQoNCj4+IHNlbnRlbmNlL3BhcmFncmFwaCBpbiBkcmFm dC1pZXRmLWlwd2F2ZS1pcHY2LW92ZXItODAyMTFvY2ItMjEgdGhhdA0KDQo+PiBleHBsYWlucyBp dCB0byB0aGUgcmVhZGVyLiBJZiB5b3UgZGlzYWdyZWUsIEkgd291bGQgbGlrZSB0byBoZWFyIHlv dXINCg0KPj4gdmlldyBvbiB0aGUgcmVsYXRpb24gb2YgSUVFRSAxNjA5LjMgYW5kDQoNCj4+IGRy YWZ0LWlldGYtaXB3YXZlLWlwdjYtb3Zlci04MDIxMW9jYi0yMS4NCg0KPg0KDQo+IEkgZG9udCBy ZWFsbHkgZGlzYWdyZWUsIGp1c3Qgd2hlcmUgdG8gcHV0IGl0Lg0KDQo+DQoNCj4gVGhlIGRyYWZ0 IGRvZXMgcmVmZXIgdG8gMTYwOS4zLCBpbiBBcHBlbmRpeCBDICJhc3BlY3RzIGludHJvZHVjZWQg YnkNCg0KPiBPQ0IgdG8gODAyLjExIi4gIFRoZSB2ZWhpY3VsYXIgbmV0d29ya2luZyBkcmFmdA0K DQo+IChkcmFmdC1pZXRmLWlwd2F2ZS12ZWhpY3VsYXItbmV0d29ya2luZy0wMSkgYWxzbyByZWZl cnMgdG8gaXQgcmlnaHQgYXQNCg0KPiB0aGUgYmVnaW5uaW5nLg0KDQo+DQoNCj4gSVB2Ni1vdmVy LU9DQiBzb3VuZHMgbGlrZSBhbiBleHBsYW5hdGlvbi4gIEFzIHN1Y2gsIEkgc3VnZ2VzdCB3ZSBm aXJzdA0KDQo+IHdyaXRlIG1vcmUgcHJlY2lzZWx5IHRoYXQgIklQdjYtb3Zlci1PQ0IgaXMgYSBw cm9maWxlIG9mIDE2MDkuMyIgYW5kDQoNCj4gdGhlbiBwdXQgaXQgaW50byB0aGUgdmVoaWN1bGFy IG5ldHdvcmtpbmcgZHJhZnQuDQoNCj4NCg0KPiBIb3cgY291bGQgdGhhdCBiZSB3cml0dGVuPw0K DQo+DQoNCj4gQWxleA0KDQo+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQoNCml0cyBtYWlsaW5nIGxpc3QNCg0KaXRzQGlldGYub3JnPG1haWx0bzpp dHNAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXRz DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQppdHMg bWFpbGluZyBsaXN0DQppdHNAaWV0Zi5vcmc8bWFpbHRvOml0c0BpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXRzDQoNCg== --_000_AM0PR0302MB3380739956201CF5A2BD2976EFAA0AM0PR0302MB3380_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkiOw0K CXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlNwcmVjaGJsYXNlbnRleHQg WmNobiI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLHNhbnMtc2VyaWY7fQ0KcC5Nc29MaXN0UGFy YWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28t c3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsN CgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFs MA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5TcHJlY2hibGFz ZW50ZXh0WmNobg0KCXttc28tc3R5bGUtbmFtZToiU3ByZWNoYmxhc2VudGV4dCBaY2huIjsNCglt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6U3ByZWNoYmxhc2VudGV4dDsN Cglmb250LWZhbWlseToiU2Vnb2UgVUkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FLU1haWxGb3JtYXR2 b3JsYWdlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpwLkJhbGxvb25UZXh0LCBsaS5CYWxs b29uVGV4dCwgZGl2LkJhbGxvb25UZXh0DQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQi Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5 bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIixzYW5z LXNlcmlmO30NCnNwYW4uRS1NYWlsRm9ybWF0dm9ybGFnZTI1DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y OndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMg Ki8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE4NTgwODA0Mzk7DQoJbXNvLWxpc3QtdHlwZTpo eWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi03NDE4NDY4NzYgMjAxNzg1MzU5IDIwMTc4 NTM2OSAyMDE3ODUzNzEgMjAxNzg1MzU5IDIwMTc4NTM2OSAyMDE3ODUzNzEgMjAxNzg1MzU5IDIw MTc4NTM2OSAyMDE3ODUzNzE7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0O30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBo YS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDot OS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBs aXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxp c3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVs OA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0Kb2wNCgl7bWFyZ2luLWJv dHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iREUtQVQiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGVsbG8sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj50aGFu ayB5b3UgYWxsIGZvciB0aGUgZmVlZGJhY2ssIGF0IGxlYXN0IEkga25vdyB3aGF0IGRyYWZ0LWll dGYtaXB3YXZlLWlwdjYtb3Zlci04MDIxMW9jYi0yMiBpcyBub3QuIFRoYXQgaXMgaGVscGZ1bCBh dCBsZWFzdCBwYXJ0bHnigKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj5JIHN0aWxsIHdvbmRlciBpZiBzb21lYm9keSBjYW4gZXhwbGFpbiB0byBtZSB3aGF0IGRy YWZ0LWlldGYtaXB3YXZlLWlwdjYtb3Zlci04MDIxMW9jYi0yMiByZWFsbHkgaXMgaW50ZW5kZWQg dG8gYmUgYW5kIHN0YXRlIHRoaXMgY2xlYXJseQ0KIGluIHRoZSBkb2N1bWVudC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIGFtIG5vdCB0cnlpbmcgdG8gYmUg cHJvdm9jYXRpdmUgb3Igb2JzdHJ1Y3RpdmUsIEkganVzdCB3b3VsZCBsaWtlIHRvIHNlZSBjbGFy aXR5LiBJIHNlZSBtYW55ICZuYnNwO+KAnHNpbWlsYXJpdGllc+KAnSBvZiBkcmFmdC1pZXRmLWlw d2F2ZS1pcHY2LW92ZXItODAyMTFvY2ItMjINCiB3aXRoIDE2MDkuMywgYnV0IHN0aWxsIGl0IGlz IG5vdCBhIHByb2ZpbGUsIGl0IGlzIG5vdCBpbnRlcm9wZXJhYmxlIHdpdGggaXQsIGFuZCBpdCBp cyBvdXQgb2Ygc2NvcGUgKHdoYXRldmVyIHRoYXQgbWVhbnMpLiBUaGF0IGlzIGNvbmZ1c2luZyBp ZiB5b3Ugd291bGQgbGlrZSB0byBiZSBjb21wbGlhbnQgdG8gYm90aCBzdGFuZGFyZHMuDQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIHNlZSBhdCBsZWFzdCB0aHJlZSBl bGVtZW50cyBpbiBkcmFmdC1pZXRmLWlwd2F2ZS1pcHY2LW92ZXItODAyMTFvY2ItMjIuIFBsZWFz ZSBhZGQgbW9yZSBpZiB5b3Ugd2lzaDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8b2wgc3R5bGU9Im1hcmdp bi10b3A6MGNtIiBzdGFydD0iMSIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowY207bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPk92ZXIg dGhlIGFpciBmb3JtYXQgb2YgaXB2NiBvdmVyIE9DQi48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwv b2w+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VG8gbWUgaXQgc2VlbXMgdGhhdCBkcmFm dC1pZXRmLWlwd2F2ZS1pcHY2LW92ZXItODAyMTFvY2ItMjIgaXMgY29tcGxpYW50IHdpdGggb3Ig Y29ycmVzcG9uZGluZyB0byB0aGUgSUVFRSAxNjA5LjMgSVB2NiBtb2RlLA0KIGJ1dCByZXN0cmlj dHMgdGhlIGZyYW1lIG9wdGlvbnMgdG8gUW9TIERhdGEgd2l0aCBBQ19CSyAodGhpcyBzb3VuZHMg bGlrZSBhIHByb2ZpbGUgdG8gbWUpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxvbCBzdHlsZT0ibWFyZ2lu LXRvcDowY20iIHN0YXJ0PSIyIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFw aCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBjbTttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Q29uZmln dXJhdGlvbiBvZiBJUHY2PG86cD48L286cD48L3NwYW4+PC9saT48L29sPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+TGV04oCZcyBjb25zaWRlciB0aGUgY291bnRlcnByb3Bvc2FsOiDigJx0aGlzIGRv Y3VtZW50IGRlc2NyaWJlcyBhbiBhbHRlcm5hdGl2ZSBtZWNoYW5pc20gdG8gdGhlIElQdjYgY29u ZmlndXJhdGlvbiBkZXNjcmliZWQgaW4gMTYwOS4z4oCdLg0KIEkgYW0gbm90IHN1cmUgd2h5IGl0 IGlzIOKAnGFsdGVybmF0aXZl4oCdIChidXQgaXQgZGVwZW5kcyBvbiBob3cgeW91IGludGVycHJl dCB0aGUgd29yZCkgLiBJRUVFIDE2MDkuMyBhbGxvd3MgU0xBQUMgdXNpbmcgUkEgb3IgV1JBLCBz byB0aGVyZSBpcyBub3RoaW5nIGFsdGVybmF0aXZlIGluIGRyYWZ0LWlldGYtaXB3YXZlLWlwdjYt b3Zlci04MDIxMW9jYi0yMiwgaXQgaXMganVzdCBtb3JlIHJlc3RyaWN0aXZlIHNpbmNlIGl0IGRv ZXMgbm90IHN1cHBvcnQNCiBXUkEuICh0aGlzIHNvdW5kcyBsaWtlIGEgcHJvZmlsZSB0byBtZSk8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGNtIiBzdGFydD0iMyIgdHlw ZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDow Y207bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkVBTC4gVGhpcyBpcyBub3Qgc3BlY2lmaWVkIGJ5 IElFRUUgMTYwOS4zIGFuZCB0byBtZSBpcyBhbiBpbXBsZW1lbnRhdGlvbiBkZXRhaWwsDQogbm90 IGFuIG92ZXItdGhlLWFpciBmdW5jdGlvbmFsaXR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC9v bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPkFueXRoaW5nIHRvIGFkZCBvciBjaGFuZ2UgaW4gdGhpcyBoaWdo IGxldmVsIHN1bW1hcnk/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UmVn YXJkcyBKYXNqYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBsYW5nPSJERSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Wb246PC9zcGFuPjwvYj48c3Bh biBsYW5nPSJERSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gSsOpcsO0bWUgSMOkcnJpIFttYWlsdG86amVyb21lLmhh ZXJyaUBldXJlY29tLmZyXQ0KPGJyPg0KPGI+R2VzZW5kZXQ6PC9iPiBNaXR0d29jaCwgMjEuIE3D pHJ6IDIwMTggMTE6MTk8YnI+DQo8Yj5Bbjo8L2I+ICdBYmR1c3NhbGFtIEJhcnl1bicgJmx0O2Fi ZHVzc2FsYW1iYXJ5dW5AZ21haWwuY29tJmd0OzsgJ0ZyYW7Dp29pcyBTaW1vbicgJmx0O2Z5Z3Np bW9uQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IFRpamluayBKYXNqYSAmbHQ7SmFzamEu VGlqaW5rQGthcHNjaC5uZXQmZ3Q7OyAnS2V2aW4gU21pdGgnICZsdDtrZXZpbi5zLnNtaXRoQGNv eC5uZXQmZ3Q7OyAnQWxleGFuZHJlIFBldHJlc2N1JyAmbHQ7YWxleGFuZHJlLnBldHJlc2N1QGdt YWlsLmNvbSZndDs7ICdpdHMnICZsdDtpdHNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+QmV0cmVmZjo8 L2I+IFJFOiBbaXB3YXZlXSBbaXB3YXZlw65dIElQdjYtb3Zlci1PQ0IgYXMgYSBwcm9maWxlIG9m IDE2MDkgV0FWRTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+RGVhciBhbGwsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPkkgc3VwcG9ydCB0aGUgZmVlZGJhY2sgZnJvbSBNci4gU2ltb24gYW5kIEJhcnl1 buKApkFzIHNhaWQgYmVmb3JlIChidXQgbm90IGxvdWQgZW5vdWdoKSB0aGlzIGRvY3VtZW50IGlz IG5vdCBsaW5rZWQgdG8gSUVFRSAxNjA5LjMuIEFkZGluZyB0aGlzIHdvdWxkDQogbWFrZSBpdCBj b25mdXNpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhvd2V2ZXIsIHdlIGNvdWxkIGFkZCBzb21ldGhpbmcgbGlr ZTog4oCcdGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYW4gYWx0ZXJuYXRpdmUgbWVjaGFuaXNtIHRv IHRoZSBJUHY2IGNvbmZpZ3VyYXRpb24gZGVzY3JpYmVkIGluIDE2MDkuM+KAnSwgaWYgcGVvcGxl DQogcmVhbGx5IHdhbnQgdG8gc2VlIDE2MDkuMyBzdGF0ZWQgaW4gdGhpcyB3b3JrLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PGJyPg0KQlIsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkrDqXLDtG1lPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPkZy b206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPiBpdHMgWzxhIGhyZWY9 Im1haWx0bzppdHMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOml0cy1ib3VuY2VzQGlldGYub3Jn PC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QWJkdXNzYWxhbSBCYXJ5dW48YnI+DQo8Yj5TZW50 OjwvYj4gV2VkbmVzZGF5IDIxIE1hcmNoIDIwMTggMDk6MTA8YnI+DQo8Yj5Ubzo8L2I+IEZyYW7D p29pcyBTaW1vbjxicj4NCjxiPkNjOjwvYj4gVGlqaW5rIEphc2phOyBLZXZpbiBTbWl0aDsgQWxl eGFuZHJlIFBldHJlc2N1OyBpdHM8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtpcHdhdmVdIFtp cHdhdmXDrl0gSVB2Ni1vdmVyLU9DQiBhcyBhIHByb2ZpbGUgb2YgMTYwOSBXQVZFPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiYjNDM7MTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QUI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPk9uIFR1ZSwgTWFyIDIwLCAyMDE4IGF0IDM6NTQgUE0sIEZyYW7D p29pcyBTaW1vbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZ5Z3NpbW9uQGdtYWlsLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmZ5Z3NpbW9uQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8cD48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhpcyBkb2N1bWVudCBpcyBhIHBy b2ZpbGUgYmFzZWQgb24gSUVFRSAxNjA5LjM6IGl0IGludHJvZHVjZXMgYWRkaXRpb25hbCByZXF1 aXJlbWVudHMgYW5kIHNwZWNpZmljYXRpb25zIHRoYXQgZG8gbm90IHZpb2xhdGUgdGhhdCZuYnNw OyBiYXNlIHN0YW5kYXJkLjwvc3Bhbj48L2k+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gb3IgbXkgcGFydCBJIGZpbmQgYWRkaXRp b24gb2YgdGhpcyB0ZXh0IG5ldXRyYWwgYW5kIG9rLCBhbHRob3VnaCBJIGFtIG5vdCBzdXJlIHdo YXQgaXMgYSBwcm9maWxlIGZvciAxNjA5IFdBVkUuJm5ic3A7IEluIEJsdWV0b290aCwgYSAncHJv ZmlsZScgaXMgc29tZXRoaW5nIHZlcnkgbXVjaCBwcmVjaXNlLCBsaWtlICdMQU4gcHJvZmlsZScs DQogZXRjLjwvc3Bhbj48L2k+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5JIGFtIE5PVCBvayB3aXRoIGl0Ojwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjEpIC0gSSBk aWQgbm90IHRoaW5rIHRoYXQgSUVFRSAxNjA5IFNlcmllcyB3YXMgaW4gc2NvcGUgb2YgdGhlIGRv Y3VtZW50Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPjIpIC0gT0NCIGlzIE5PVCBhIHByb2ZpbGUgb2YgMTYwOSBXQVZFLiZu YnNwOyBTZWUgcHJldmlvdXNseSBzZW50IGRlZmluaXRpb24uPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Rnlnczwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogaXRzICZsdDs8YSBocmVmPSJt YWlsdG86aXRzLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pdHMtYm91bmNlc0Bp ZXRmLm9yZzwvYT4mZ3Q7IE9uIEJlaGFsZiBPZiBBbGV4YW5kcmUgUGV0cmVzY3U8YnI+DQpTZW50 OiBTdW5kYXksIE1hcmNoIDE4LCAyMDE4IDEyOjE2IFBNPGJyPg0KVG86IDxhIGhyZWY9Im1haWx0 bzppdHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pdHNAaWV0Zi5vcmc8L2E+PGJyPg0KQ2M6 IFRpamluayBKYXNqYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOkphc2phLlRpamlua0BrYXBzY2gubmV0 IiB0YXJnZXQ9Il9ibGFuayI+SmFzamEuVGlqaW5rQGthcHNjaC5uZXQ8L2E+Jmd0OzsgS2V2aW4g U21pdGggJmx0OzxhIGhyZWY9Im1haWx0bzprZXZpbi5zLnNtaXRoQGNveC5uZXQiIHRhcmdldD0i X2JsYW5rIj5rZXZpbi5zLnNtaXRoQGNveC5uZXQ8L2E+Jmd0Ozxicj4NClN1YmplY3Q6IFJlOiBb aXB3YXZlXSBbaXB3YXZlw65dIElQdjYtb3Zlci1PQ0IgYXMgYSBwcm9maWxlIG9mIDE2MDkgV0FW RTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SGkgSVBXQVZFcnMsPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RG8geW91IGRpc2Fn cmVlIHdlIGFkZCB0aGlzIHBocmFzZSBpbiB0aGUgSW50cm9kdWN0aW9uOjwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsg VGhpcyBkb2N1bWVudCBpcyBhIHByb2ZpbGUgYmFzZWQgb24gSUVFRSAxNjA5LjM6IGl0IGludHJv ZHVjZXMNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiZndDsgYWRkaXRpb25hbCByZXF1aXJlbWVudHMgYW5kIHNwZWNpZmlj YXRpb25zIHRoYXQgZG8gbm90IHZpb2xhdGUgdGhhdA0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyBiYXNlIHN0YW5k YXJkLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPkZvciBteSBwYXJ0IEkgZmluZCBhZGRpdGlvbiBvZiB0aGlzIHRleHQgbmV1 dHJhbCBhbmQgb2ssIGFsdGhvdWdoIEkgYW0gbm90IHN1cmUgd2hhdCBpcyBhIHByb2ZpbGUgZm9y IDE2MDkgV0FWRS4mbmJzcDsgSW4gQmx1ZXRvb3RoLCBhICdwcm9maWxlJyBpcyBzb21ldGhpbmcg dmVyeSBtdWNoIHByZWNpc2UsIGxpa2UgJ0xBTiBwcm9maWxlJywgZXRjLjwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkFsZXg8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+TGUgMTcvMDMvMjAxOCDDoCAxMzoyMiwgVGlqaW5rIEphc2ph IGEgw6ljcml0IDo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IEhlbGxvIEFsZXgsPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4mZ3Q7IENhbiB3ZSBwdXQgc29tZXRoaW5nIGF0IHRoZSBiZWdpbm5pbmcgb2YNCjwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PiZndDsgZHJhZnQtaWV0Zi1pcHdhdmUtaXB2Ni1vdmVyLTgwMjExb2NiLTIxLCBtYXliZSBpbiB0 aGUgaW50cm9kdWN0aW9uPzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgSSBzdWdnZXN0IHNvbWUgbGFuZ3VhZ2UgbGlr ZSB0aGUgZm9sbG93aW5nOjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyBUaGlzIGRvY3VtZW50 IGlzIGEgcHJvZmlsZSBiYXNlZCBvbiBJRUVFIDE2MDkuMzogaXQgaW50cm9kdWNlcw0KPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jmd0OyBhZGRpdGlvbmFsIHJlcXVpcmVtZW50cyBhbmQgc3BlY2lmaWNhdGlvbnMgdGhhdCBk byBub3QgdmlvbGF0ZSB0aGF0DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IGJhc2Ugc3RhbmRhcmQuPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ Jmd0OyA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4mZ3Q7IFJlZ2FyZHMgSmFzamE8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IDwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZn dDsgPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+Jmd0OyAtLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tIFZvbjog QWxleGFuZHJlIFBldHJlc2N1DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IFs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxhIGhyZWY9Im1haWx0bzphbGV4YW5kcmUucGV0cmVzY3VAZ21haWwuY29tIiB0YXJnZXQ9 Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+bWFpbHRvOmFsZXhhbmRyZS5wZXRyZXNjdUBnbWFpbC5jb208L3NwYW4+PC9hPjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+XQ0KIEdlc2VuZGV0OiBTYW1zdGFnLCAxNy4gTcOkcno8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4mZ3Q7IDIwMTggMTI6MjMgQW46IFRpamluayBKYXNqYSAmbHQ7PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48YSBocmVmPSJtYWlsdG86SmFzamEuVGlqaW5rQGthcHNjaC5uZXQiIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5KYXNqYS5UaWppbmtAa2Fwc2NoLm5ldDwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4mZ3Q7DQogQ2M6IEtldmluIFNtaXRoIDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgJmx0Ozwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PGEgaHJlZj0ibWFpbHRvOmtldmluLnMuc21pdGhAY294Lm5ldCIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPmtldmluLnMuc21pdGhAY294Lm5ldDwvc3Bhbj48L2E+PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4mZ3Q7Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+DQo8YSBocmVmPSJtYWlsdG86 aXRzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+aXRzQGlldGYub3JnPC9zcGFuPjwvYT48L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiBCZXRyZWZmOiBSZTogW2lwd2F2ZV0gaXB3YXZlIC0NCjwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PiZndDsgY29tbWVudHMgYW5kIGNvbmNlcm5zIC0gMTYwOSBXQVZFLCBFUEQgLSB0b3dhcmRzIHJl c29sdXRpb248L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4mZ3Q7IDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgSGVsbG8gSmFzamEsPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ Jmd0OyA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4mZ3Q7IExlIDE2LzAzLzIwMTggw6AgMTk6MDIsIFRpamluayBKYXNqYSBh IMOpY3JpdCA6PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDsgSGVsbG8gQWxleCw8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyA8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4mZ3Q7Jmd0OyBpbiBhZGRpdGlvbiB0byBLZXZpbidzIHBvaW50cywgSSZuYnNwOyB3 b3VsZCBsaWtlIHRvIG1lbnRpb24gdGhhdDo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyA8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7 Jmd0OyAxLiBJIHdlbGNvbWUgeW91ciBwcm9wb3NhbCBmb3IgdGhlIGFkZGl0aW9uYWwgdGV4dCB0 aGF0IHNwZWNpZmllcw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDsgUW9TLiBUaGlzIGlzIG5lY2Vzc2FyeSBm b3Igb3BlcmF0aW9uIGluIEV1cm9wZSAodGhlIHNwZWNpZmljYXRpb24gZm9yDQo8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4m Z3Q7Jmd0OyB0aGUgYWNjZXNzIGxheWVyIGNhbiBiZSBmb3VuZCBpbiBFVFNJIEVOIDMwMiA2NjMs IHdoZXJlIGNsYXVzZTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7IDQuNiBzYXlzIHRoYXQgUW9TIHNoYWxsIGJl IHVzZWQpLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiZndDsgPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyBOb3RlZC48L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IDwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiZndDsmZ3Q7IDIuIE15IHVuZGVyc3RhbmRpbmcgb2YgdGhlIGRpc2N1c3Npb24gYmVs b3cgaXMgdGhhdDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7IGRyYWZ0LWlldGYtaXB3YXZlLWlwdjYtb3Zlci04 MDIxMW9jYi0yMSBpcyAmcXVvdDtiYXNlZCBvbiZxdW90OyBJRUVFIDE2MDkuMyBpbg0KPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jmd0OyZndDsgdGhhdCBpdCBpcyBjb21wbGlhbnQgd2l0aCBpdCAoSSBkaWRuJ3QgZmluZCBh bnkgJnF1b3Q7dmlvbGF0aW9uIG9mIElFRUUNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7IDE2MDkuMyksIGFu ZCBhZGRzIGFkZGl0aW9uYWwgcmVzdHJpY3Rpb25zIGFuZCAvb3Igc3BlY2lmaWNhdGlvbnMNCjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiZndDsmZ3Q7IChzdWNoIGEgTVRVIHNpemUsIEFDX0JLLCBSRkM4MDY0LCBldGMuKS4g SW4gdGhhdCBzZW5zZQ0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDsgZHJhZnQtaWV0Zi1pcHdhdmUtaXB2Ni1v dmVyLTgwMjExb2NiLTIxIGlzIGEgcHJvZmlsZSBvZiBJRUVFIDE2MDkuMy4NCjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZn dDsmZ3Q7IEkgd291bGQgc3VnZ2VzdCBtYWtpbmcgdGhhdCB2ZXJ5IGNsZWFyLCB3aXRoIGEgc2hv cnQNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiZndDsmZ3Q7IHNlbnRlbmNlL3BhcmFncmFwaCBpbiBkcmFmdC1pZXRmLWlw d2F2ZS1pcHY2LW92ZXItODAyMTFvY2ItMjEgdGhhdCZuYnNwOw0KPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDsg ZXhwbGFpbnMgaXQgdG8gdGhlIHJlYWRlci4gSWYgeW91IGRpc2FncmVlLCBJIHdvdWxkIGxpa2Ug dG8gaGVhciB5b3VyDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyB2aWV3IG9uIHRoZSByZWxhdGlvbiBvZiBJ RUVFIDE2MDkuMyBhbmQNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7IGRyYWZ0LWlldGYtaXB3YXZlLWlwdjYt b3Zlci04MDIxMW9jYi0yMS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgSSBkb250IHJlYWxs eSBkaXNhZ3JlZSwganVzdCB3aGVyZSB0byBwdXQgaXQuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4m Z3Q7IFRoZSBkcmFmdCBkb2VzIHJlZmVyIHRvIDE2MDkuMywgaW4gQXBwZW5kaXggQyAmcXVvdDth c3BlY3RzIGludHJvZHVjZWQgYnkNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgT0NCIHRvIDgwMi4xMSZxdW90Oy4m bmJzcDsgVGhlIHZlaGljdWxhciBuZXR3b3JraW5nIGRyYWZ0PC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyAoZHJhZnQt aWV0Zi1pcHdhdmUtdmVoaWN1bGFyLW5ldHdvcmtpbmctMDEpIGFsc28gcmVmZXJzIHRvIGl0IHJp Z2h0IGF0DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4mZ3Q7IHRoZSBiZWdpbm5pbmcuPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4mZ3Q7IElQdjYtb3Zlci1PQ0Igc291bmRzIGxpa2UgYW4gZXhwbGFuYXRpb24uJm5ic3A7IEFz IHN1Y2gsIEkgc3VnZ2VzdCB3ZSBmaXJzdA0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyB3cml0ZSBtb3JlIHByZWNp c2VseSB0aGF0ICZxdW90O0lQdjYtb3Zlci1PQ0IgaXMgYSBwcm9maWxlIG9mIDE2MDkuMyZxdW90 OyBhbmQNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiZndDsgdGhlbiBwdXQgaXQgaW50byB0aGUgdmVoaWN1bGFyIG5ldHdv cmtpbmcgZHJhZnQuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IEhvdyBjb3VsZCB0aGF0IGJl IHdyaXR0ZW4/PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+Jmd0OyA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IEFsZXg8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IDwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+aXRzIG1haWxpbmcgbGlzdDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Im1haWx0bzppdHNA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5pdHNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2l0cyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXRzPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCml0cyBtYWls aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86aXRzQGlldGYub3JnIj5pdHNAaWV0Zi5vcmc8 L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p dHMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2l0czwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_AM0PR0302MB3380739956201CF5A2BD2976EFAA0AM0PR0302MB3380_-- From nobody Wed Mar 21 05:18: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 E0E6F127010 for ; Wed, 21 Mar 2018 05:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfdykAbzWCmG for ; Wed, 21 Mar 2018 05:18:11 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA0D012D82F for ; Wed, 21 Mar 2018 05:18:09 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w2LCI4fP005190; Wed, 21 Mar 2018 13:18:04 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 961E8203E78; Wed, 21 Mar 2018 13:18:04 +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 8425A203D38; Wed, 21 Mar 2018 13:18:04 +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 w2LCI4FD006666; Wed, 21 Mar 2018 13:18:04 +0100 To: Tijink Jasja , =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , "'Abdussalam Baryun'" , "=?UTF-8?Q?'Fran=c3=a7ois_Simon'?=" Cc: "'Kevin Smith'" , "'its'" References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <5cc6bd32-0812-288a-2db0-b0de53626f1e@gmail.com> <009c01d3c052$f0a78cc0$d1f6a640$@gmail.com> <007b01d3c0fe$15ad9540$4108bfc0$@eurecom.fr> From: Alexandre Petrescu Message-ID: <8daedb8d-8da1-aa02-33dd-ad81cf1a178e@gmail.com> Date: Wed, 21 Mar 2018 13:18: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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] IPv6-over-OCB as a profile of 1609 WAVE X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 12:18:13 -0000 Jasja, Le 21/03/2018 à 11:58, Tijink Jasja a écrit : > Hello, > > thank you all for the feedback, at least I know what > draft-ietf-ipwave-ipv6-over-80211ocb-22 is not. That is helpful at > least partly… > > I still wonder if somebody can explain to me what > draft-ietf-ipwave-ipv6-over-80211ocb-22 really is intended to be and > state this clearly in the document. > > I am not trying to be provocative or obstructive, I just would like > to see clarity. I see many “similarities” of > draft-ietf-ipwave-ipv6-over-80211ocb-22 with 1609.3, but still it is > not a profile, it is not interoperable with it, and it is out of > scope (whatever that means). That is confusing if you would like to > be compliant to both standards. > > I see at least three elements in > draft-ietf-ipwave-ipv6-over-80211ocb-22. Please add more if you > wish: > > 1. Over the air format of ipv6 over OCB. > > To me it seems that draft-ietf-ipwave-ipv6-over-80211ocb-22 is > compliant with or corresponding to the IEEE 1609.3 IPv6 mode, Noted. > but restricts the frame options to QoS Data with AC_BK (this sounds > like a profile to me). 1. if one wants to change that, one needs to persuade John Kenney, and Tony Li, first. 2. If 1609.3 WAVE IPv6 uses something else than QoSData with AC_BK (e.g. Data, or QoSData with AC_BE) then the local regulation in America and Europe might dislike it. I am not sure, but one should double check. > 2. Configuration of IPv6 > > Let’s consider the counterproposal: “this document describes an > alternative mechanism to the IPv6 configuration described in 1609.3”. > I am not sure why it is “alternative” (but it depends on how you > interpret the word) . The -22 does not say that. > IEEE 1609.3 allows SLAAC using RA or WRA, so there is nothing > alternative in draft-ietf-ipwave-ipv6-over-80211ocb-22, it is just > more restrictive since it does not support WRA. (this sounds like a > profile to me) It is normal that draft-ietf-ipwave-ipv6-over-80211ocb-22 does not support WRA, because WRA is not an IP message. If one wants 1609.3-SLAAC to work with WRA (rather than RA) then there are a few questions IMHO (In My Humble Oppinion). None of these impacts draft-ietf-ipwave-ipv6-over-80211ocb-22. - decide whether only the prefix, or other parts from RA too need to be reflected in the WRA. (lifetimes, others, check RFC4862) - decide whether in IEEE 1609.3 the default route comes from the WRA as well (not just the prefix). If yes, decide whether the address of the default router comes from the src address of the WRA or from an SLLAO carried by the WRA. - decide whether you want a system to work correctly while only WRA is present, both WRA and RA, or just RA. - decide whether the prefix length in the WRA must be precisely 64, or can be of another length. - decide whether the Interface ID definition in this draft can be used for the IEEE 1609.3-SLAAC. I hope yes. - others. All these have no impact on draft-ietf-ipwave-ipv6-over-80211ocb-22. > 3. EAL. This is not specified by IEEE 1609.3 and to me is an > implementation detail, not an over-the-air functionality. Yes, EAL is an implementation detail, and not over-the-air functionality. Do you think that the implementation detail of IEEE 1609.3 puts the IPv6 packets directly on 802.11, rather than on an adaptation layer? Alex [...] From nobody Wed Mar 21 06:42: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 54BDC127078 for ; Wed, 21 Mar 2018 06:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3Jj6XpVza_v for ; Wed, 21 Mar 2018 06:42:40 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c: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 443DB1243FE for ; Wed, 21 Mar 2018 06:42:40 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id h21so9762854wmd.1 for ; Wed, 21 Mar 2018 06:42:40 -0700 (PDT) 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=heh5Rh2A95DCaGfLUFTo0RPYHBbMH+Va5EhIoJpZ13Q=; b=hExkYTkNhxs3updcp1txqxPf1n2xEMDgPbSiZBT+DNcGioUB6dAiBpcaBU+yDglbLq luL2aWDb6Q3bA5HM9wvHQut9FfFvQ7mdA5Ltvu3ScURnSXM7rP/NNZGeTHcwcNQHNVXT ByB8H0OJoyLs+NqeC92fJSREb7Kto2ODVswhSHK9VDJGqcWtFXUvX0nP3hz3RbPy85Jl u8PD1cQIgBdi8KBqkzpS5IH041kTKvCx8leSBzNy41fXnB8WixHLfMkZOr0FNPh62DTo j/fMqP1a0XXG0ZWqu9J5pgGhwQA+8CQur0f6TCW8ZN6uyMm3lEVg8PqX3+xhyvTYnqH5 dsQw== 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=heh5Rh2A95DCaGfLUFTo0RPYHBbMH+Va5EhIoJpZ13Q=; b=rY7oYMO25bZUyZLkmgInl+jY4sYlha3PyQc0y90AjkJv+GXLQvg9xTi42EuYEiTuko eK7U2Q/BX0IIaZeMcIjIjzN5GMBKhv/We2HAufg7aNGyFHy9cm06D0jEW0/d8vZZ3cos 4dZ2aSnkDn1YJSgARFzWqYP5UT0qZeGVZFJ0hTaSL6qM8U0MpWT0MEEQ2hRoxsS3w5lS vLcaUr/fciaDcFJHJWPGepjKuxERyjoTYMImPbFSxmadZAC9zB5JoAZfY4bpGgMZnFo/ lNkTNvuCRZdOXJcqfK+t3CSpyCZAvNN7WRpWl7sle8cLRqfvaGacQ8yrm+jAmrcJpGXh T+KQ== X-Gm-Message-State: AElRT7H40d8BlSy8tAW1x+/BtuI6a693CbDfWcZXOvS/VUm3HB5A41cW F4U35GK54ezdMAPVOh6keOg= X-Google-Smtp-Source: AG47ELtqXtxWxADPpk9f21LpCpTpeHLh3I9rAN0+y2DkRFqo6zeVJnSi9fSS+zM+ibTQUYjiLYgiJQ== X-Received: by 10.28.135.140 with SMTP id j134mr2877179wmd.157.1521639758823; Wed, 21 Mar 2018 06:42:38 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:7ced:ae79:d2a1:1a73? ([2001:67c:370:128:7ced:ae79:d2a1:1a73]) by smtp.gmail.com with ESMTPSA id b81sm1556499wmb.22.2018.03.21.06.42.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Mar 2018 06:42:37 -0700 (PDT) From: Tony Li Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_84EDAACB-608C-40DF-B374-DD9D5CA3E512" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 21 Mar 2018 13:42:37 +0000 In-Reply-To: <8daedb8d-8da1-aa02-33dd-ad81cf1a178e@gmail.com> Cc: Tijink Jasja , =?utf-8?B?SsOpcsO0bWUgSMOkcnJp?= , Abdussalam Baryun , =?utf-8?Q?Fran=C3=A7ois_Simon?= , Kevin Smith , its To: Alexandre Petrescu References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <5cc6bd32-0812-288a-2db0-b0de53626f1e@gmail.com> <009c01d3c052$f0a78cc0$d1f6a640$@gmail.com> <007b01d3c0fe$15ad9540$4108bfc0$@eurecom.fr> <8daedb8d-8da1-aa02-33dd-ad81cf1a178e@gmail.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [ipwave] IPv6-over-OCB as a profile of 1609 WAVE X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 13:42:42 -0000 --Apple-Mail=_84EDAACB-608C-40DF-B374-DD9D5CA3E512 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 21, 2018, at 12:18 PM, Alexandre Petrescu = wrote: >=20 > It is normal that draft-ietf-ipwave-ipv6-over-80211ocb-22 does not > support WRA, because WRA is not an IP message. >=20 > If one wants 1609.3-SLAAC to work with WRA (rather than RA) then there > are a few questions IMHO (In My Humble Oppinion). None of these = impacts > draft-ietf-ipwave-ipv6-over-80211ocb-22. >=20 > - decide whether only the prefix, or other parts from RA too need to = be > reflected in the WRA. (lifetimes, others, check RFC4862) > - decide whether in IEEE 1609.3 the default route comes from the WRA = as > well (not just the prefix). If yes, decide whether the address of = the > default router comes from the src address of the WRA or from an SLLAO > carried by the WRA. > - decide whether you want a system to work correctly while only WRA is > present, both WRA and RA, or just RA. > - decide whether the prefix length in the WRA must be precisely 64, or > can be of another length. > - decide whether the Interface ID definition in this draft can be used > for the IEEE 1609.3-SLAAC. I hope yes. > - others. Our draft really should say something about WRA, one way or another. Lacking any compelling reason to use WRA, I would propose that we say = that WRA should NOT be used. Tony --Apple-Mail=_84EDAACB-608C-40DF-B374-DD9D5CA3E512 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Mar 21, 2018, at 12:18 PM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:

It is normal that = draft-ietf-ipwave-ipv6-over-80211ocb-22 does not
support WRA, because WRA is not an IP = message.

If one wants 1609.3-SLAAC to = work with WRA (rather than RA) then there
are a few questions IMHO (In My = Humble Oppinion).  None of these impacts
draft-ietf-ipwave-ipv6-over-80211ocb-22.- decide whether only the prefix, or other parts = from RA too need to be
 reflected in the WRA. = (lifetimes, others, check RFC4862)
- decide whether in IEEE 1609.3 = the default route comes from the WRA as
 well (not just the = prefix).  If yes, decide whether the address of the
 default router comes from the src address = of the WRA or from an SLLAO
 carried by the = WRA.
- decide whether you want a system to = work correctly while only WRA is
 present, both WRA and RA, = or just RA.
- decide whether the prefix length in the = WRA must be precisely 64, or
 can be of another = length.
- decide whether the Interface ID = definition in this draft can be used
 for the IEEE 1609.3-SLAAC. =  I hope yes.
- = others.



Our = draft really should say something about WRA, one way or = another.

Lacking= any compelling reason to use WRA, I would propose that we say that WRA = should NOT be used.

Tony

= --Apple-Mail=_84EDAACB-608C-40DF-B374-DD9D5CA3E512-- From nobody Wed Mar 21 06:49: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 428AA12702E for ; Wed, 21 Mar 2018 06:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=onboardsecurity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNd6DfK0YeOe for ; Wed, 21 Mar 2018 06:49:07 -0700 (PDT) Received: from mail-pl0-x232.google.com (mail-pl0-x232.google.com [IPv6:2607:f8b0:400e:c01::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 23F851243FE for ; Wed, 21 Mar 2018 06:49:07 -0700 (PDT) Received: by mail-pl0-x232.google.com with SMTP id f5-v6so3122144plj.13 for ; Wed, 21 Mar 2018 06:49:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onboardsecurity.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yHbWzJfJIYrN+ZUSgtpfXeR8U3yqpOEmXBUqhVw5XXU=; b=Z36N3sWy9p72ZpvkO6JoItZWGfsrZ9ash7KjN3Q8zVMx1pIbvQDhBX+17lyPm/SJrx BYP26w2yTquLrC0amYnoufE0HUh2xdlOTesshG8hoAiXFl4JaxJIyVbDRrWJeZOSbpzO 2Rr+XCeRUwy13oXlBHMM3Mmy0QKi+xMmKFm7s= 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=yHbWzJfJIYrN+ZUSgtpfXeR8U3yqpOEmXBUqhVw5XXU=; b=a2m/55ynD00QMw85JdhqI7ERFvNJwWG/aBBz7vI/BfpvwKQO9EF9yrQ3Oz6zsw9xbt afutCsmT/x+ziewP5f2b+pfASuuGLZJXaGP2B7z/Zw5N7Xo7Tjsabbu5Gohk1o7zR/+c LJM0wgCK4DFSSauKumabzGcIBPyjgff68ZkwwOR7soqpR3TWxZYy8HupoMtq3yIVaLxN duQyZQncxGh8+vPZ7yHPipq/g/jx35AtsE4Jdo9QZvJ7Wtaa0zwOQdbum8h+b8SePp5T RIrWcWEivqaVAvG3V1tKLuPr7ym9lkGDV9AtEN9JL+4ihIee4SbWNSob7YNrMA5SxyGf DHUA== X-Gm-Message-State: AElRT7E1eD+qKAM68Cej33jBABP+G3dNbm+bq8aFMtcilN790jAtMy65 smduR1MpNYlEdoNjIv4Ro/FmNksseNe0LHz0f3Trjg== X-Google-Smtp-Source: AG47ELvrD2fr1DGgPZbly3gRdKU1saNM9vVboCd3GSVvMoBHwn4tEglG2pTKJsTBDxLCA2TpcosSjn4wHT/lgIgINdk= X-Received: by 2002:a17:902:6785:: with SMTP id g5-v6mr18260040plk.369.1521640146676; Wed, 21 Mar 2018 06:49:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.156.1 with HTTP; Wed, 21 Mar 2018 06:48:45 -0700 (PDT) In-Reply-To: References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <5cc6bd32-0812-288a-2db0-b0de53626f1e@gmail.com> <009c01d3c052$f0a78cc0$d1f6a640$@gmail.com> <007b01d3c0fe$15ad9540$4108bfc0$@eurecom.fr> <8daedb8d-8da1-aa02-33dd-ad81cf1a178e@gmail.com> From: William Whyte Date: Wed, 21 Mar 2018 09:48:45 -0400 Message-ID: To: Tony Li Cc: Alexandre Petrescu , its , =?UTF-8?Q?Fran=C3=A7ois_Simon?= , =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , Tijink Jasja , Kevin Smith , Abdussalam Baryun Content-Type: multipart/alternative; boundary="0000000000006b38800567ec7479" Archived-At: Subject: Re: [ipwave] IPv6-over-OCB as a profile of 1609 WAVE X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 13:49:09 -0000 --0000000000006b38800567ec7479 Content-Type: text/plain; charset="UTF-8" > I would propose that we say that WRA should NOT be used. WRA is there and WAVE devices already support it; I don't see a reason to rule it out, though I don't see a problem with specifying additional mechanisms. William On Wed, Mar 21, 2018 at 9:42 AM, Tony Li wrote: > > > On Mar 21, 2018, at 12:18 PM, Alexandre Petrescu < > alexandre.petrescu@gmail.com> wrote: > > It is normal that draft-ietf-ipwave-ipv6-over-80211ocb-22 does not > support WRA, because WRA is not an IP message. > > If one wants 1609.3-SLAAC to work with WRA (rather than RA) then there > are a few questions IMHO (In My Humble Oppinion). None of these impacts > draft-ietf-ipwave-ipv6-over-80211ocb-22. > > - decide whether only the prefix, or other parts from RA too need to be > reflected in the WRA. (lifetimes, others, check RFC4862) > - decide whether in IEEE 1609.3 the default route comes from the WRA as > well (not just the prefix). If yes, decide whether the address of the > default router comes from the src address of the WRA or from an SLLAO > carried by the WRA. > - decide whether you want a system to work correctly while only WRA is > present, both WRA and RA, or just RA. > - decide whether the prefix length in the WRA must be precisely 64, or > can be of another length. > - decide whether the Interface ID definition in this draft can be used > for the IEEE 1609.3-SLAAC. I hope yes. > - others. > > > > > Our draft really should say something about WRA, one way or another. > > Lacking any compelling reason to use WRA, I would propose that we say that > WRA should NOT be used. > > Tony > > > _______________________________________________ > 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 --0000000000006b38800567ec7479 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0I would propose that = we say that WRA should NOT be used.
<= br>
WRA is there and WAVE= devices already support it; I don't see a reason to rule it out, thoug= h I don't see a problem with specifying additional mechanisms.

William
=
On Wed, Mar 21, 2018 at 9:42 AM, Tony Li <tony1athome@gmail.com> wrote:


On Mar 21, 2018, a= t 12:18 PM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:
=
It is normal that draft-ietf-ipwave-ipv6-over-= 80211ocb-22 does not
support= WRA, because WRA is not an IP message.

If one wants 1609.3-SLAAC to work with WRA (rather than RA) then ther= e
are a few questions IMHO (In My= Humble Oppinion).=C2=A0 None of these impacts
draft-ietf-ipwave-ipv6-over-80211ocb-22.

- decide whether only the prefix, or other parts= from RA too need to be
=C2=A0ref= lected in the WRA. (lifetimes, others, check RFC4862)
- decide whether in IEEE 1609.3 the default route come= s from the WRA as
=C2=A0well (not= just the prefix).=C2=A0 If yes, decide whether the address of the=C2=A0default router comes from the src a= ddress of the WRA or from an SLLAO
- dec= ide whether you want a system to work correctly while only WRA is=C2=A0present, both WRA and RA, or just RA= .
- decide whether the prefix len= gth in the WRA must be precisely 64, or
=C2=A0can be of another length.
- decide whether the Interface ID definition in this draft can be use= d
=C2=A0for the IEEE 1609.3-SLAAC= .=C2=A0 I hope yes.
- others.



O= ur draft really should say something about WRA, one way or another.

Lacking any compelling reason to use WRA, I would propose= that we say that WRA should NOT be used.

Tony


_______________________________________________
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
--0000000000006b38800567ec7479-- From nobody Wed Mar 21 06:50: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 82D4B1243FE for ; Wed, 21 Mar 2018 06:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-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 (1024-bit key) header.d=kapsch.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWlpAYTt88ee for ; Wed, 21 Mar 2018 06:49:56 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20101.outbound.protection.outlook.com [40.107.2.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9E4B12E039 for ; Wed, 21 Mar 2018 06:49:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kapsch.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=HZ0FMmwbbiRwaTqNS+lZSnPs7OY/bpKGZinSi2MBjwg=; b=bZgCgrQlS6sLBQfxWvsz9jAg6s7qPgMPpirslvRR3fRwCBn2ChuK9r6gOQbtRa6Obts7MdZleAQw7mXlczebksq6n4mH8DQLme7NUm242mRa159WZAATK1Bwf8MuYGrU/9aS6DWxIKCAn9fgjCbroHwCTvNLwSjcNKq87+XEgvM= Received: from AM0PR0302MB3380.eurprd03.prod.outlook.com (52.133.37.155) by AM0PR0302MB3186.eurprd03.prod.outlook.com (52.133.36.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.609.10; Wed, 21 Mar 2018 13:49:50 +0000 Received: from AM0PR0302MB3380.eurprd03.prod.outlook.com ([fe80::153a:2232:e7b7:7cb4]) by AM0PR0302MB3380.eurprd03.prod.outlook.com ([fe80::153a:2232:e7b7:7cb4%13]) with mapi id 15.20.0609.010; Wed, 21 Mar 2018 13:49:50 +0000 From: Tijink Jasja To: Alexandre Petrescu , =?utf-8?B?SsOpcsO0bWUgSMOkcnJp?= , 'Abdussalam Baryun' , =?utf-8?B?J0ZyYW7Dp29pcyBTaW1vbic=?= CC: 'Kevin Smith' , 'its' Thread-Topic: [ipwave] IPv6-over-OCB as a profile of 1609 WAVE Thread-Index: AQHTwQ6vGBsVmMBin0iosBWYEvGtlKPasqNw Date: Wed, 21 Mar 2018 13:49:50 +0000 Message-ID: References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <5cc6bd32-0812-288a-2db0-b0de53626f1e@gmail.com> <009c01d3c052$f0a78cc0$d1f6a640$@gmail.com> <007b01d3c0fe$15ad9540$4108bfc0$@eurecom.fr> <8daedb8d-8da1-aa02-33dd-ad81cf1a178e@gmail.com> In-Reply-To: <8daedb8d-8da1-aa02-33dd-ad81cf1a178e@gmail.com> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jasja.Tijink@kapsch.net; x-originating-ip: [80.121.42.103] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM0PR0302MB3186; 7:pvGikaD5jbZQ6b/THg4RJjDvM0bEI7xu0/0fHhqwn7ZvN30n/0aBy9n0u1ro93uNdk+pTOlkgUp1AAto1w9ozV3/0h0PytxdGlDdlZV23QNol8yBUdDdUC1ljQwUGo0fQH34IPe48HsHobyjbMc+cqbba7PeUee/7UGNeLGYcovAN4X9QyxVvTil1k/wTX2+JauEYI2chkn1KFRuF2xxLqFwmaPo9DNhgHBrsTaKR8y8O4Pq5le/n016ikfhD2Vt x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 87054504-b0d9-45a7-d735-08d58f329e27 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:AM0PR0302MB3186; x-ms-traffictypediagnostic: AM0PR0302MB3186: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(79046362386883)(131327999870524)(85827821059158); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231221)(944501323)(52105095)(10201501046)(3002001)(6041310)(20161123560045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:AM0PR0302MB3186; BCL:0; PCL:0; RULEID:; SRVR:AM0PR0302MB3186; x-forefront-prvs: 0618E4E7E1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(396003)(346002)(39850400004)(376002)(366004)(189003)(199004)(68736007)(106356001)(72206003)(9686003)(5250100002)(2900100001)(3660700001)(8666007)(93886005)(316002)(561944003)(76176011)(14454004)(105586002)(33656002)(99286004)(55016002)(81156014)(7696005)(305945005)(25786009)(478600001)(7736002)(81166006)(102836004)(8936002)(86362001)(2906002)(97736004)(3280700002)(6436002)(3846002)(74316002)(186003)(66066001)(8676002)(26005)(39060400002)(6506007)(5660300001)(110136005)(6116002)(54906003)(53936002)(4326008)(2950100002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR0302MB3186; H:AM0PR0302MB3380.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: kapsch.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: jFl3VfHMz7yyOJP5yLaHan9YWSU8vxzVy+HHObwKtrozYQ69dpI6UoMEaepPHo+a2qJclPwOeB8jOejkLik/31xXg2dI5rtEtuTXZyJ4SjFtAKbzVdWuYItFquUEkI2f0Loi2XQzrhCA0JAbnbucbu3J91RfSKTjyw+EL/ukzcHd9t0hBXGbl9y1hzoAymSi1d03DCkaeoMirgILb9lbT3NjtFS8/DvTqJEBimSlVIi7zB1IOdf5YUZegFC6SodTdkBcA+ENOMMURL/hKK4JJHa/ki7U9+OPmj4nQ7ZjlyhteHcVCZxQpKInvDr6Nw/vaDUOHZjwCY1zA3ajI+9eFg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: kapsch.net X-MS-Exchange-CrossTenant-Network-Message-Id: 87054504-b0d9-45a7-d735-08d58f329e27 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Mar 2018 13:49:50.5934 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5f9ce527-7e3e-4e83-a8a4-b6c848f85ab5 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR0302MB3186 Archived-At: Subject: Re: [ipwave] IPv6-over-OCB as a profile of 1609 WAVE X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 13:49:58 -0000 SGkgQWxleCwNCg0KdGhhbmtzIHRoaXMgbWFrZXMgaXQgbXVjaCBjbGVhcmVyIHRvIG1lLiAgDQpJ IHdvdWxkIGJlIGhhcHB5IHRvIHNlZSB0aGlzIHN1bW1hcnkgc29tZXdoZXJlIGluIHRoZSBkcmFm dCwgZWl0aGVyIGEgcGFyYWdyYXBoIG9yIHNlY3Rpb24gb24gc2ltaWxhcml0aWVzIG9yIGRpZmZl cmVuY2VzICh5b3UgY2hvb3NlKSB3aXRoIElFRUUgMTYwOS4zLg0KDQpTb21lIGFuc3dlcnMgaW4g dGhlIHRleHQgYmVsb3cNClJlZ2FyZHMgSmFzamENCg0KDQotLS0tLVVyc3Byw7xuZ2xpY2hlIE5h Y2hyaWNodC0tLS0tDQpWb246IEFsZXhhbmRyZSBQZXRyZXNjdSBbbWFpbHRvOmFsZXhhbmRyZS5w ZXRyZXNjdUBnbWFpbC5jb21dIA0KR2VzZW5kZXQ6IE1pdHR3b2NoLCAyMS4gTcOkcnogMjAxOCAx MzoxOA0KQW46IFRpamluayBKYXNqYSA8SmFzamEuVGlqaW5rQGthcHNjaC5uZXQ+OyBKw6lyw7Rt ZSBIw6RycmkgPGplcm9tZS5oYWVycmlAZXVyZWNvbS5mcj47ICdBYmR1c3NhbGFtIEJhcnl1bicg PGFiZHVzc2FsYW1iYXJ5dW5AZ21haWwuY29tPjsgJ0ZyYW7Dp29pcyBTaW1vbicgPGZ5Z3NpbW9u QGdtYWlsLmNvbT4NCkNjOiAnS2V2aW4gU21pdGgnIDxrZXZpbi5zLnNtaXRoQGNveC5uZXQ+OyAn aXRzJyA8aXRzQGlldGYub3JnPg0KQmV0cmVmZjogUmU6IFtpcHdhdmVdIElQdjYtb3Zlci1PQ0Ig YXMgYSBwcm9maWxlIG9mIDE2MDkgV0FWRQ0KDQpKYXNqYSwNCg0KTGUgMjEvMDMvMjAxOCDDoCAx MTo1OCwgVGlqaW5rIEphc2phIGEgw6ljcml0IDoNCj4gSGVsbG8sDQo+IA0KPiB0aGFuayB5b3Ug YWxsIGZvciB0aGUgZmVlZGJhY2ssIGF0IGxlYXN0IEkga25vdyB3aGF0DQo+IGRyYWZ0LWlldGYt aXB3YXZlLWlwdjYtb3Zlci04MDIxMW9jYi0yMiBpcyBub3QuIFRoYXQgaXMgaGVscGZ1bCBhdCAN Cj4gbGVhc3QgcGFydGx54oCmDQo+IA0KPiBJIHN0aWxsIHdvbmRlciBpZiBzb21lYm9keSBjYW4g ZXhwbGFpbiB0byBtZSB3aGF0DQo+IGRyYWZ0LWlldGYtaXB3YXZlLWlwdjYtb3Zlci04MDIxMW9j Yi0yMiByZWFsbHkgaXMgaW50ZW5kZWQgdG8gYmUgYW5kICANCj4gc3RhdGUgdGhpcyBjbGVhcmx5 IGluIHRoZSBkb2N1bWVudC4NCj4gDQo+IEkgYW0gbm90IHRyeWluZyB0byBiZSBwcm92b2NhdGl2 ZSBvciBvYnN0cnVjdGl2ZSwgSSBqdXN0IHdvdWxkIGxpa2UgdG8gDQo+IHNlZSBjbGFyaXR5LiBJ IHNlZSBtYW55ICDigJxzaW1pbGFyaXRpZXPigJ0gb2YNCj4gZHJhZnQtaWV0Zi1pcHdhdmUtaXB2 Ni1vdmVyLTgwMjExb2NiLTIyIHdpdGggMTYwOS4zLCBidXQgc3RpbGwgaXQgaXMgDQo+IG5vdCBh IHByb2ZpbGUsIGl0IGlzIG5vdCBpbnRlcm9wZXJhYmxlIHdpdGggaXQsIGFuZCBpdCBpcyBvdXQg b2Ygc2NvcGUgDQo+ICh3aGF0ZXZlciB0aGF0IG1lYW5zKS4gVGhhdCBpcyBjb25mdXNpbmcgaWYg eW91IHdvdWxkIGxpa2UgdG8gYmUgDQo+IGNvbXBsaWFudCB0byBib3RoIHN0YW5kYXJkcy4NCj4g DQo+IEkgc2VlIGF0IGxlYXN0IHRocmVlIGVsZW1lbnRzIGluDQo+IGRyYWZ0LWlldGYtaXB3YXZl LWlwdjYtb3Zlci04MDIxMW9jYi0yMi4gUGxlYXNlIGFkZCBtb3JlIGlmIHlvdQ0KPiB3aXNoOg0K PiANCj4gMS4gT3ZlciB0aGUgYWlyIGZvcm1hdCBvZiBpcHY2IG92ZXIgT0NCLg0KPiANCj4gVG8g bWUgaXQgc2VlbXMgdGhhdCBkcmFmdC1pZXRmLWlwd2F2ZS1pcHY2LW92ZXItODAyMTFvY2ItMjIg aXMgDQo+IGNvbXBsaWFudCB3aXRoIG9yIGNvcnJlc3BvbmRpbmcgdG8gdGhlIElFRUUgMTYwOS4z IElQdjYgbW9kZSwNCg0KTm90ZWQuDQoNCj4gYnV0IHJlc3RyaWN0cyB0aGUgZnJhbWUgb3B0aW9u cyB0byBRb1MgRGF0YSB3aXRoIEFDX0JLICh0aGlzIHNvdW5kcyANCj4gbGlrZSBhIHByb2ZpbGUg dG8gbWUpLg0KDQoxLiBpZiBvbmUgd2FudHMgdG8gY2hhbmdlIHRoYXQsIG9uZSBuZWVkcyB0byBw ZXJzdWFkZSBKb2huIEtlbm5leSwgYW5kDQogICAgVG9ueSBMaSwgZmlyc3QuDQoNCjIuIElmIDE2 MDkuMyBXQVZFIElQdjYgdXNlcyBzb21ldGhpbmcgZWxzZSB0aGFuIFFvU0RhdGEgd2l0aCBBQ19C SyAoZS5nLg0KICAgIERhdGEsIG9yIFFvU0RhdGEgd2l0aCBBQ19CRSkgdGhlbiB0aGUgbG9jYWwg cmVndWxhdGlvbiBpbiBBbWVyaWNhIGFuZA0KICAgIEV1cm9wZSBtaWdodCBkaXNsaWtlIGl0LiAg SSBhbSBub3Qgc3VyZSwgYnV0IG9uZSBzaG91bGQgZG91YmxlIGNoZWNrLg0KDQo+IDIuIENvbmZp Z3VyYXRpb24gb2YgSVB2Ng0KPiANCj4gTGV04oCZcyBjb25zaWRlciB0aGUgY291bnRlcnByb3Bv c2FsOiDigJx0aGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhbiANCj4gYWx0ZXJuYXRpdmUgbWVjaGFu aXNtIHRvIHRoZSBJUHY2IGNvbmZpZ3VyYXRpb24gZGVzY3JpYmVkIGluIDE2MDkuM+KAnS4NCj4g SSBhbSBub3Qgc3VyZSB3aHkgaXQgaXMg4oCcYWx0ZXJuYXRpdmXigJ0gKGJ1dCBpdCBkZXBlbmRz IG9uIGhvdyB5b3UgDQo+IGludGVycHJldCB0aGUgd29yZCkgLg0KDQpUaGUgLTIyIGRvZXMgbm90 IHNheSB0aGF0Lg0KDQpbSlRdOiBpIGtub3cgYnV0IGl0IHdhcyBhIHByb3Bvc2FsIG9uIHRoZSBs aXN0DQoNCj4gSUVFRSAxNjA5LjMgYWxsb3dzIFNMQUFDIHVzaW5nIFJBIG9yIFdSQSwgc28gdGhl cmUgaXMgbm90aGluZyANCj4gYWx0ZXJuYXRpdmUgaW4gZHJhZnQtaWV0Zi1pcHdhdmUtaXB2Ni1v dmVyLTgwMjExb2NiLTIyLCBpdCBpcyBqdXN0IA0KPiBtb3JlIHJlc3RyaWN0aXZlIHNpbmNlIGl0 IGRvZXMgbm90IHN1cHBvcnQgV1JBLiAodGhpcyBzb3VuZHMgbGlrZSBhIA0KPiBwcm9maWxlIHRv IG1lKQ0KDQpJdCBpcyBub3JtYWwgdGhhdCBkcmFmdC1pZXRmLWlwd2F2ZS1pcHY2LW92ZXItODAy MTFvY2ItMjIgZG9lcyBub3Qgc3VwcG9ydCBXUkEsIGJlY2F1c2UgV1JBIGlzIG5vdCBhbiBJUCBt ZXNzYWdlLg0KDQpbSlRdOiBub3RlZA0KDQpJZiBvbmUgd2FudHMgMTYwOS4zLVNMQUFDIHRvIHdv cmsgd2l0aCBXUkEgKHJhdGhlciB0aGFuIFJBKSB0aGVuIHRoZXJlIGFyZSBhIGZldyBxdWVzdGlv bnMgSU1ITyAoSW4gTXkgSHVtYmxlIE9wcGluaW9uKS4gIE5vbmUgb2YgdGhlc2UgaW1wYWN0cyBk cmFmdC1pZXRmLWlwd2F2ZS1pcHY2LW92ZXItODAyMTFvY2ItMjIuDQoNCi0gZGVjaWRlIHdoZXRo ZXIgb25seSB0aGUgcHJlZml4LCBvciBvdGhlciBwYXJ0cyBmcm9tIFJBIHRvbyBuZWVkIHRvIGJl DQogICByZWZsZWN0ZWQgaW4gdGhlIFdSQS4gKGxpZmV0aW1lcywgb3RoZXJzLCBjaGVjayBSRkM0 ODYyKQ0KLSBkZWNpZGUgd2hldGhlciBpbiBJRUVFIDE2MDkuMyB0aGUgZGVmYXVsdCByb3V0ZSBj b21lcyBmcm9tIHRoZSBXUkEgYXMNCiAgIHdlbGwgKG5vdCBqdXN0IHRoZSBwcmVmaXgpLiAgSWYg eWVzLCBkZWNpZGUgd2hldGhlciB0aGUgYWRkcmVzcyBvZiB0aGUNCiAgIGRlZmF1bHQgcm91dGVy IGNvbWVzIGZyb20gdGhlIHNyYyBhZGRyZXNzIG9mIHRoZSBXUkEgb3IgZnJvbSBhbiBTTExBTw0K ICAgY2FycmllZCBieSB0aGUgV1JBLg0KLSBkZWNpZGUgd2hldGhlciB5b3Ugd2FudCBhIHN5c3Rl bSB0byB3b3JrIGNvcnJlY3RseSB3aGlsZSBvbmx5IFdSQSBpcw0KICAgcHJlc2VudCwgYm90aCBX UkEgYW5kIFJBLCBvciBqdXN0IFJBLg0KLSBkZWNpZGUgd2hldGhlciB0aGUgcHJlZml4IGxlbmd0 aCBpbiB0aGUgV1JBIG11c3QgYmUgcHJlY2lzZWx5IDY0LCBvcg0KICAgY2FuIGJlIG9mIGFub3Ro ZXIgbGVuZ3RoLg0KLSBkZWNpZGUgd2hldGhlciB0aGUgSW50ZXJmYWNlIElEIGRlZmluaXRpb24g aW4gdGhpcyBkcmFmdCBjYW4gYmUgdXNlZA0KICAgZm9yIHRoZSBJRUVFIDE2MDkuMy1TTEFBQy4g IEkgaG9wZSB5ZXMuDQotIG90aGVycy4NCg0KQWxsIHRoZXNlIGhhdmUgbm8gaW1wYWN0IG9uIGRy YWZ0LWlldGYtaXB3YXZlLWlwdjYtb3Zlci04MDIxMW9jYi0yMi4NCg0KW0pUXTogaW50ZXJlc3Rp bmcgcXVlc3Rpb25zLCBub3RlZA0KDQo+IDMuIEVBTC4gVGhpcyBpcyBub3Qgc3BlY2lmaWVkIGJ5 IElFRUUgMTYwOS4zIGFuZCB0byBtZSBpcyBhbiANCj4gaW1wbGVtZW50YXRpb24gZGV0YWlsLCBu b3QgYW4gb3Zlci10aGUtYWlyIGZ1bmN0aW9uYWxpdHkuDQoNClllcywgRUFMIGlzIGFuIGltcGxl bWVudGF0aW9uIGRldGFpbCwgYW5kIG5vdCBvdmVyLXRoZS1haXIgZnVuY3Rpb25hbGl0eS4NCg0K RG8geW91IHRoaW5rIHRoYXQgdGhlIGltcGxlbWVudGF0aW9uIGRldGFpbCBvZiBJRUVFIDE2MDku MyBwdXRzIHRoZSBJUHY2IHBhY2tldHMgZGlyZWN0bHkgb24gODAyLjExLCByYXRoZXIgdGhhbiBv biBhbiBhZGFwdGF0aW9uIGxheWVyPw0KDQpbSlRdOiBpIHRoaW5rIHRoaXMgaXMganVzdCBvdXQg b2Ygc2NvcGUgb2YgMTYwOS4zIA0KDQpBbGV4DQpbLi4uXQ0K From nobody Wed Mar 21 06:58: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 9CE0A12DA27 for ; Wed, 21 Mar 2018 06:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 Hxvmj_yA6HYG for ; Wed, 21 Mar 2018 06:58:16 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c: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 4794412D956 for ; Wed, 21 Mar 2018 06:58:15 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id t7so9912373wmh.5 for ; Wed, 21 Mar 2018 06:58:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=AuvQuvFNGoDqJsN8bRUTjdnvQ4BkTEKIlJCD0DxjOjs=; b=nWCpO2oKp/b7Yc5tqCRExR2A5tFVmgvW4nGO4GSRQXmhKdslK3B+8bS2Q8WuJK5Ycr QGienK9g3bhDv2XUZ5nOWZXbIVhCK3OTeclSU/Iz47V9EcEaq1u9A14+SXRoYSfB/97C MkVF/f9CPLQvf4mVOc6+/8wCOU9GYQ7I5U7IWpA0c0Doby8fA06VWynGueCbbmJgHnXi B+/MjI16LSBZB/Fhe6Dr0QvFT5wpJ5Y2lkINJxJBHQOv0O170APxxQ8gf+xhBTgGNuTK 8epWKSbD8lLkh55+3tqa0XP8cbAVsX2dg2QXvz4zwZrQ1KvngZSwYMrxMwXGs0K2bnuP qkXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=AuvQuvFNGoDqJsN8bRUTjdnvQ4BkTEKIlJCD0DxjOjs=; b=YtW/u8jdG673FiOhj1rTetNi+T4Reg4lFTsYnOcy0xlRpe5wRFfulxX3aUkKBBvd7j DNrPA++pOXILawc9XXYJHdaD2C/OAVpD4GkNei3wg5wyyVJ3YMM9mUxCJphU759zfb/u I3fP8kjSU6wlcgySOGMdySjpzg5nZlHUZqb1OvmgjDi1mAqYvrmsBkWLo/sLZ1gO2oEc lclY8KNQR5+z+WQZArPxkp5VR9mO5HaExF8OvuXfQ6TKTC+vjgZarmjzAHdaLuYKaVAQ d8j3MAiyqYWmEaKxgZcrtykiYYCvet8jVF85+8ArmPhGbBExmWBrYISRqiC8cCJbxNG/ Y73Q== X-Gm-Message-State: AElRT7HKs1o3KjAqhV+8HdKQ0tiv+rGbuhy+llEnMAHHajLL8ped4Nxq zSj7UTDvgtrXwuB1iEPqtEw= X-Google-Smtp-Source: AG47ELvzRg/zmJ3hOEH8V4rg8dN8vgxowj0qbZKqx3XLTlx85qsKr390X02hbMid2HBNtEcWar2oug== X-Received: by 10.28.131.140 with SMTP id f134mr2878040wmd.117.1521640693871; Wed, 21 Mar 2018 06:58:13 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:7ced:ae79:d2a1:1a73? ([2001:67c:370:128:7ced:ae79:d2a1:1a73]) by smtp.gmail.com with ESMTPSA id 43sm4720703wru.40.2018.03.21.06.58.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Mar 2018 06:58:13 -0700 (PDT) Sender: Tony Li From: tony.li@tony.li Message-Id: <3934D4DC-F53C-47CF-8E47-FF70A07BC099@tony.li> Content-Type: multipart/alternative; boundary="Apple-Mail=_94F04DF3-8108-4B7E-8EFC-BEFF8E5611E3" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 21 Mar 2018 13:58:12 +0000 In-Reply-To: Cc: Alexandre Petrescu , its , =?utf-8?Q?Fran=C3=A7ois_Simon?= , =?utf-8?B?SsOpcsO0bWUgSMOkcnJp?= , Tijink Jasja , Kevin Smith , Abdussalam Baryun To: William Whyte References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <5cc6bd32-0812-288a-2db0-b0de53626f1e@gmail.com> <009c01d3c052$f0a78cc0$d1f6a640$@gmail.com> <007b01d3c0fe$15ad9540$4108bfc0$@eurecom.fr> <8daedb8d-8da1-aa02-33dd-ad81cf1a178e@gmail.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [ipwave] IPv6-over-OCB as a profile of 1609 WAVE X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 13:58:19 -0000 --Apple-Mail=_94F04DF3-8108-4B7E-8EFC-BEFF8E5611E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 21, 2018, at 1:48 PM, William Whyte = wrote: >=20 > WRA is there and WAVE devices already support it; I don't see a reason = to rule it out, though I don't see a problem with specifying additional = mechanisms. >=20 As I mumbled previously, protocols to do with IP should be endorsed by = the IETF. Unless this WG chooses to endorse WRA, we should preclude it. Letting 1609 propose protocols for IP and not responding is worse than = not responding to Liaison statements.=20 Tony --Apple-Mail=_94F04DF3-8108-4B7E-8EFC-BEFF8E5611E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Mar 21, 2018, at 1:48 PM, William Whyte <wwhyte@onboardsecurity.com> wrote:

WRA is there = and WAVE devices already support it; I don't see a reason to rule it = out, though I don't see a problem with specifying additional = mechanisms.


As I mumbled previously, protocols to do with = IP should be endorsed by the IETF. Unless this WG chooses to endorse = WRA, we should preclude it.

Letting 1609 propose protocols for IP and not responding is = worse than not responding to Liaison statements. 

Tony


= --Apple-Mail=_94F04DF3-8108-4B7E-8EFC-BEFF8E5611E3-- From nobody Wed Mar 21 07:10: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 9474A12DA29 for ; Wed, 21 Mar 2018 07:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=onboardsecurity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vkr25itWSW4E for ; Wed, 21 Mar 2018 07:10:53 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::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 87C6112D956 for ; Wed, 21 Mar 2018 07:10:52 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id j2so2006380pff.10 for ; Wed, 21 Mar 2018 07:10:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onboardsecurity.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ul6zm4Q88ZSefXR9kYgznigao2rVgPBDFLCqb/clvQI=; b=FuBNr/x/OCN8ctMLCqV+dkKLm0vJE4cDU/XlkM2Xxi8NdqiHFDSaHYKxfq31p2cTvQ pff3N7w7eQZsjSwPZIlJVR8ubmPCFHxPTstWi9PwSvxHkOW7bjN1L877+oQ9AQpx9o1j M4XooLz5pC7cUj2acVqRe7ktbuhWSYkWFtZaM= 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=ul6zm4Q88ZSefXR9kYgznigao2rVgPBDFLCqb/clvQI=; b=SfagrPe9yzYMC6ORdw+mUvEbfAmLN94vBoiJi4cCqjV9uyiywtUm+FYsizLxbEnvt5 eZe35y4oLT5TS/PXBuhCTTxY/0wyLIFwe0/BciiDYhTj9SYSKs4ZiLLonsoF3Me/yGkS xztQVC4zABXOoCicKX8bWlEro9ChApVr+aaSdGusCH62XvTy2t1sdgTCTzY6B3LKeQsX JabLfonSuYdfm56iRP4kxNRrAG0LbkiSGRPH60K3PBUi8j75JARNsf24kWyz6j14YXjN qX9/l0XK5dVaL6febOd+vuJ7ZDLJvq4HFx20WWEAaKLJvlvpkAKq0rGUgkdGcVKOYA0D fSiQ== X-Gm-Message-State: AElRT7FnD+71sl01Nqk8xyi9SVHMpEA+7NwBQ8aI6MfltjLReoaaR41J E4vf4gQrfDDc17wYbZoUy+2HbdfU0j3F0StKhoLiRA== X-Google-Smtp-Source: AG47ELsRva55zNq+PbdJKn82m/0s5pQI7DZcVxLyhIHfqMC4AXzBUtaCMuzdQ6LLUFZhwFFZB1wgfUTyimB7c5EGaxs= X-Received: by 10.98.97.1 with SMTP id v1mr17282681pfb.119.1521641451865; Wed, 21 Mar 2018 07:10:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.156.1 with HTTP; Wed, 21 Mar 2018 07:10:30 -0700 (PDT) In-Reply-To: <3934D4DC-F53C-47CF-8E47-FF70A07BC099@tony.li> References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <5cc6bd32-0812-288a-2db0-b0de53626f1e@gmail.com> <009c01d3c052$f0a78cc0$d1f6a640$@gmail.com> <007b01d3c0fe$15ad9540$4108bfc0$@eurecom.fr> <8daedb8d-8da1-aa02-33dd-ad81cf1a178e@gmail.com> <3934D4DC-F53C-47CF-8E47-FF70A07BC099@tony.li> From: William Whyte Date: Wed, 21 Mar 2018 10:10:30 -0400 Message-ID: To: Tony Li Cc: Alexandre Petrescu , its , =?UTF-8?Q?Fran=C3=A7ois_Simon?= , =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , Tijink Jasja , Kevin Smith , Abdussalam Baryun Content-Type: multipart/alternative; boundary="94eb2c04f22a36eb670567ecc25a" Archived-At: Subject: Re: [ipwave] IPv6-over-OCB as a profile of 1609 WAVE X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 14:10:55 -0000 --94eb2c04f22a36eb670567ecc25a Content-Type: text/plain; charset="UTF-8" > Unless this WG chooses to endorse WRA, we should preclude it. I would suggest endorsing it then :-) William On Wed, Mar 21, 2018 at 9:58 AM, wrote: > > > On Mar 21, 2018, at 1:48 PM, William Whyte > wrote: > > WRA is there and WAVE devices already support it; I don't see a reason to > rule it out, though I don't see a problem with specifying additional > mechanisms. > > > As I mumbled previously, protocols to do with IP should be endorsed by the > IETF. Unless this WG chooses to endorse WRA, we should preclude it. > > Letting 1609 propose protocols for IP and not responding is worse than not > responding to Liaison statements. > > Tony > > > -- PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS: wwhyte@onboardsecurity.com --94eb2c04f22a36eb670567ecc25a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0Unless this WG choose= s to endorse WRA, we should preclude it.

I would suggest endors= ing it then :-)

William

On Wed, Mar 21, 2018 at 9:58 AM,= <tony.li@tony.li> wrote:
<= div style=3D"word-wrap:break-word;line-break:after-white-space">

On Mar 21, 2018, at 1:48 = PM, William Whyte <wwhyte@onboardsecurity.com> wrote:

WRA is there and WAVE devices already support it; I don't see = a reason to rule it out, though I don't see a problem with specifying a= dditional mechanisms.


As I mumbled = previously, protocols to do with IP should be endorsed by the IETF. Unless = this WG chooses to endorse WRA, we should preclude it.

=
Letting 1609 propose protocols for IP and not responding is worse than= not responding to Liaison statements.=C2=A0

Tony



--


PLEASE UPDATE YOUR ADD= RESS BOOKS WITH MY NEW ADDRESS: wwhyte@onboardsecurity.com
--94eb2c04f22a36eb670567ecc25a-- From nobody Wed Mar 21 10:18: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 A9BF512E05C for ; Wed, 21 Mar 2018 10:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 EFWdNn0Qnxuk for ; Wed, 21 Mar 2018 10:18:37 -0700 (PDT) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0226412751F for ; Wed, 21 Mar 2018 10:18:37 -0700 (PDT) Received: by mail-wr0-x22c.google.com with SMTP id d10so5980983wrf.3 for ; Wed, 21 Mar 2018 10:18:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=HNKCy3FmdrA5J/NiNRvunaIHraarb65xqLdqJu4GcHE=; b=FwDx2Ze0kdfZcukPHz7cO1cIi61pp/LV01erC3fERfUg1hvqfidrzvmuwK3Be0ARSR F0s0TaFch6foy/krtgf3G10eYbFHUDS9qU570jA3fypc6KwwPwQLCeJa0xVM84OPDop9 HuA04C2ZCZYf9T6IXXjRE85rrPbMh3v65mAYfrguQwFdr77W+i7iuB4szzal6e/xA/Aj heLwCAulofzYGF9FtSLzq+erybxXXEGwPRDH0dYDdAweSpKYqSyNrVb3trhuL0DaltTF yPHuc2AH3r6vkMFP1+/wVG5hyK8PTw+zm1RT9WGw3cwRNAlS1TljvdVje8ZTEM8csqrK LS/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=HNKCy3FmdrA5J/NiNRvunaIHraarb65xqLdqJu4GcHE=; b=KP4tP8psG7yJkdt7CAUL/pL3bq6wjHcfksmD5eUYrpmt9inqvDKnDrGyM8kaH46Pao x+3AxfYy1dMWxEVq/6kPBz8z08+wIeI1vrkVh7R8Et/NPuMyrzZmegBHPD2E8UnAAKey dp3Yvp3fYttYAJiI8BtJw/Q6QAmRvGIBeKwtczHjQQNEUADAeIkm3jpoolf2XXh6xi8m sdyu3O/ZonTcV4cp0PTvzUA+JEomgf+VThIc8j/MrFN5oAIQ3EDEHyu8F4kDpp66S8+x V3XJN5y8GaN9JV4PtWcGfbIY8DoxkXbYuG7g+SUYPdnqFPSS9/AEvX/6mS8w7g7Gtesx dsYQ== X-Gm-Message-State: AElRT7EaiiGiQ7vVKsBFlGorl4YPAnmZep9HeVVTThLXOOb6YUnbl9qw OwEuj4Fa/HLuHjRKcg/uATg= X-Google-Smtp-Source: AG47ELtgpNBDbB0hMz0JkOmCY/Yxo4NJkHLF3oTXgrQgGN3Ln8Pl3c2RXOzLy0Klc8Q5yH6znQGusA== X-Received: by 10.223.133.6 with SMTP id 6mr13232848wrh.53.1521652715507; Wed, 21 Mar 2018 10:18:35 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:6062:6ad0:209:238d? ([2001:67c:370:128:6062:6ad0:209:238d]) by smtp.gmail.com with ESMTPSA id x18sm4355206wmc.2.2018.03.21.10.18.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Mar 2018 10:18:34 -0700 (PDT) Sender: Tony Li From: tony.li@tony.li Message-Id: <0D822C86-92FD-4F06-B072-C9227EAD720F@tony.li> Content-Type: multipart/alternative; boundary="Apple-Mail=_3FC5DE9D-CD7B-4716-9601-9B968212E45A" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 21 Mar 2018 17:18:33 +0000 In-Reply-To: Cc: William Whyte , its , =?utf-8?Q?Fran=C3=A7ois_Simon?= , =?utf-8?B?SsOpcsO0bWUgSMOkcnJp?= , Tijink Jasja , Alexandre Petrescu , Kevin Smith , Abdussalam Baryun To: dickroy@alum.mit.edu References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <5cc6bd32-0812-288a-2db0-b0de53626f1e@gmail.com> <009c01d3c052$f0a78cc0$d1f6a640$@gmail.com> <007b01d3c0fe$15ad9540$4108bfc0$@eurecom.fr> <8daedb8d-8da1-aa02-33dd-ad81cf1a178e@gmail.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [ipwave] IPv6-over-OCB as a profile of 1609 WAVE X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 17:18:39 -0000 --Apple-Mail=_3FC5DE9D-CD7B-4716-9601-9B968212E45A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >=20 > You absolutely should NOT rule out the use of WRA, because it makes no = sense to do so, and if you do, such statements will be ignored by those = who see the value and choose to use the WRA. For the IP networking = people to be telling system deployers how they MUST deploy their = services is simply wrong. Stick to IP networking protocols; stay in = layer 3; do not over step those boundaries =E2=80=A6 please =E2=80=A6 = for the benefit of all of us!=20 Perhaps you should start by asking 1609 to stay in Layer 2. ;-) Tony --Apple-Mail=_3FC5DE9D-CD7B-4716-9601-9B968212E45A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8


You absolutely should NOT rule out the use of WRA, because it = makes no sense to do so, and if you do, such statements will be ignored = by those who see the value and choose to use the WRA.  For the IP = networking people to be telling system deployers how they MUST deploy = their services is simply wrong.  Stick to IP networking protocols; = stay in layer 3; do not over step those boundaries =E2=80=A6 please =E2=80= =A6 for the benefit of all of us! 


Perhaps = you should start by asking 1609 to stay in Layer 2. ;-)

Tony

= --Apple-Mail=_3FC5DE9D-CD7B-4716-9601-9B968212E45A-- From nobody Wed Mar 21 10:42: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 781B2127863 for ; Wed, 21 Mar 2018 10:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXcWcAW17FfA for ; Wed, 21 Mar 2018 10:42:49 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D78812762F for ; Wed, 21 Mar 2018 10:42:48 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w2LHgRB7040063; Wed, 21 Mar 2018 18:42:27 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0F4C7206F55; Wed, 21 Mar 2018 18:42: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 E0E00201715; Wed, 21 Mar 2018 18:42:26 +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 w2LHgQYS013136; Wed, 21 Mar 2018 18:42:26 +0100 To: dickroy@alum.mit.edu, "'Tijink Jasja'" , =?UTF-8?B?J0rDqXLDtG1lIEjDpHJyaSc=?= , "'Abdussalam Baryun'" , "=?UTF-8?Q?'Fran=c3=a7ois_Simon'?=" Cc: "'Kevin Smith'" , "'its'" References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <5cc6bd32-0812-288a-2db0-b0de53626f1e@gmail.com> <009c01d3c052$f0a78cc0$d1f6a640$@gmail.com> <007b01d3c0fe$15ad9540$4108bfc0$@eurecom.fr> <809DC8CFA3564BC58531C82B2C576602@SRA6> From: Alexandre Petrescu Message-ID: <3ad8db38-cf22-2703-ab14-9bf05d2d5860@gmail.com> Date: Wed, 21 Mar 2018 18:42: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: <809DC8CFA3564BC58531C82B2C576602@SRA6> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] =?utf-8?q?=5Bipwave=C3=AE=5D_IPv6-over-OCB_as_a_profile?= =?utf-8?q?_of_1609_WAVE?= X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 17:42:50 -0000 Le 21/03/2018 18:26, Dick Roy a crit: [...] > */[RR] 1609.3 clearly says implement IPv6 according to the RFCs. There > is NO alternative at present!/* But RFC4862 says SLAAC uses RA, not WRA. Other RFCs say that the only means to obtain a default route is from an RA (not from DHCP, not from something else like WRA). Alex From nobody Wed Mar 21 10:52: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 922E412E8C9 for ; Wed, 21 Mar 2018 10:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vB1u1Q1SG7Ge for ; Wed, 21 Mar 2018 10:52:50 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7586F12762F for ; Wed, 21 Mar 2018 10:52:48 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w2LHqdl3029476; Wed, 21 Mar 2018 18:52:39 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3060F206F06; Wed, 21 Mar 2018 18:52: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 1664520405C; Wed, 21 Mar 2018 18:52:39 +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 w2LHqcHR022580; Wed, 21 Mar 2018 18:52:38 +0100 To: dickroy@alum.mit.edu, "'Tijink Jasja'" , =?UTF-8?B?J0rDqXLDtG1lIEjDpHJyaSc=?= , "'Abdussalam Baryun'" , "=?UTF-8?Q?'Fran=c3=a7ois_Simon'?=" Cc: "'Kevin Smith'" , "'its'" References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <5cc6bd32-0812-288a-2db0-b0de53626f1e@gmail.com> <009c01d3c052$f0a78cc0$d1f6a640$@gmail.com> <007b01d3c0fe$15ad9540$4108bfc0$@eurecom.fr> <8daedb8d-8da1-aa02-33dd-ad81cf1a178e@gmail.com> From: Alexandre Petrescu Message-ID: <366e0035-3230-4020-a3c3-5f5c525f3061@gmail.com> Date: Wed, 21 Mar 2018 18:52: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: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] IPv6-over-OCB as a profile of 1609 WAVE X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 17:52:54 -0000 Le 21/03/2018 18:42, Dick Roy a crit: > Do you think that the implementation detail of IEEE 1609.3 puts the > IPv6 packets directly on 802.11, rather than on an adaptation layer? > > 1609.3 takes ALL NPDUs and through a UNITDATA.request sends them ALL to > the DLL for handling on transmission. There is NEVER an adaptation layer > of ANY KIND! In 5.9GHz operation in the US, the LLC sublayer simply > appends an ethertype, the one for IPv6 in this case, and sends it to the > MAC for transmission. AGAIN, NO ADAPTATION LAYER! Since the ONLY > MAC&PHY 1609.3 has chosen to recognize is 802.11, the MAC&PHY is 802.11, > and consequently 802.11 headers will are added. There is NOTHING TO ADAPT! That is the theory. I asked about the implementation. Alex > > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Tijink Jasja > Sent: Wednesday, March 21, 2018 2:50 PM > To: Alexandre Petrescu; Jrme Hrri; 'Abdussalam Baryun'; 'Franois Simon' > Cc: 'Kevin Smith'; 'its' > Subject: Re: [ipwave] IPv6-over-OCB as a profile of 1609 WAVE > > Hi Alex, > > thanks this makes it much clearer to me. > > I would be happy to see this summary somewhere in the draft, either a > paragraph or section on similarities or differences (you choose) with > IEEE 1609.3. > > Some answers in the text below > > Regards Jasja > > -----Ursprngliche Nachricht----- > > Von: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] > > Gesendet: Mittwoch, 21. Mrz 2018 13:18 > > An: Tijink Jasja ; Jrme Hrri > ; 'Abdussalam Baryun' > ; 'Franois Simon' > > Cc: 'Kevin Smith' ; 'its' > > Betreff: Re: [ipwave] IPv6-over-OCB as a profile of 1609 WAVE > > Jasja, > > Le 21/03/2018 11:58, Tijink Jasja a crit : > >> Hello, > >> > >> thank you all for the feedback, at least I know what > >> draft-ietf-ipwave-ipv6-over-80211ocb-22 is not. That is helpful at > >> least partly > >> > >> I still wonder if somebody can explain to me what > >> draft-ietf-ipwave-ipv6-over-80211ocb-22 really is intended to be and > >> state this clearly in the document. > >> > >> I am not trying to be provocative or obstructive, I just would like to > >> see clarity. I see many similarities of > >> draft-ietf-ipwave-ipv6-over-80211ocb-22 with 1609.3, but still it is > >> not a profile, it is not interoperable with it, and it is out of scope > >> (whatever that means). That is confusing if you would like to be > >> compliant to both standards. > >> > >> I see at least three elements in > >> draft-ietf-ipwave-ipv6-over-80211ocb-22. Please add more if you > >> wish: > >> > >> 1. Over the air format of ipv6 over OCB. > >> > >> To me it seems that draft-ietf-ipwave-ipv6-over-80211ocb-22 is > >> compliant with or corresponding to the IEEE 1609.3 IPv6 mode, > > Noted. > >> but restricts the frame options to QoS Data with AC_BK (this sounds > >> like a profile to me). > > 1. if one wants to change that, one needs to persuade John Kenney, and > > Tony Li, first. > > 2. If 1609.3 WAVE IPv6 uses something else than QoSData with AC_BK (e.g. > > Data, or QoSData with AC_BE) then the local regulation in America and > > Europe might dislike it. I am not sure, but one should double check. > >> 2. Configuration of IPv6 > >> > >> Lets consider the counterproposal: this document describes an > >> alternative mechanism to the IPv6 configuration described in 1609.3. > >> I am not sure why it is alternative (but it depends on how you > >> interpret the word) . > > The -22 does not say that. > > [JT]: i know but it was a proposal on the list > >> IEEE 1609.3 allows SLAAC using RA or WRA, so there is nothing > >> alternative in draft-ietf-ipwave-ipv6-over-80211ocb-22, it is just > >> more restrictive since it does not support WRA. (this sounds like a > >> profile to me) > > It is normal that draft-ietf-ipwave-ipv6-over-80211ocb-22 does not > support WRA, because WRA is not an IP message. > > [JT]: noted > > If one wants 1609.3-SLAAC to work with WRA (rather than RA) then there > are a few questions IMHO (In My Humble Oppinion). None of these impacts > draft-ietf-ipwave-ipv6-over-80211ocb-22. > > - decide whether only the prefix, or other parts from RA too need to be > > reflected in the WRA. (lifetimes, others, check RFC4862) > > - decide whether in IEEE 1609.3 the default route comes from the WRA as > > well (not just the prefix). If yes, decide whether the address of the > > default router comes from the src address of the WRA or from an SLLAO > > carried by the WRA. > > - decide whether you want a system to work correctly while only WRA is > > present, both WRA and RA, or just RA. > > - decide whether the prefix length in the WRA must be precisely 64, or > > can be of another length. > > - decide whether the Interface ID definition in this draft can be used > > for the IEEE 1609.3-SLAAC. I hope yes. > > - others. > > All these have no impact on draft-ietf-ipwave-ipv6-over-80211ocb-22. > > [JT]: interesting questions, noted > >> 3. EAL. This is not specified by IEEE 1609.3 and to me is an > >> implementation detail, not an over-the-air functionality. > > Yes, EAL is an implementation detail, and not over-the-air functionality. > > Do you think that the implementation detail of IEEE 1609.3 puts the IPv6 > packets directly on 802.11, rather than on an adaptation layer? > > [JT]: i think this is just out of scope of 1609.3 > > Alex > > [...] > > _______________________________________________ > > its mailing list > > its@ietf.org > > https://www.ietf.org/mailman/listinfo/its > From nobody Wed Mar 21 11:01: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 5F709126E01 for ; Wed, 21 Mar 2018 11:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 5Yuq2tNjQJkK for ; Wed, 21 Mar 2018 11:01:07 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c: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 46C73126CB6 for ; Wed, 21 Mar 2018 11:01:07 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id f125so11434292wme.4 for ; Wed, 21 Mar 2018 11:01:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=GWq/z6B6RuYDuDVhMARX3ir3nleZhwEGh0KERECcV1Y=; b=YreFhI0kDmhvLyf50UP3yOvIvM239gsK7Mp3mTWnFTh+7CKEjLvAZvnd4DpZfillCu U6nV8ccr5DjpW+1jmfwd9cwvLNHwDIq3tycnA0xLRHlEJiRLvjUkbs/Ox4gJYmFKURWJ FfH8KkIyV2yxg21Buylp0GD1FSiJcFEPVC8ZaymG/1Mu19fPF+aYNGTdvQQvvSVRkr0B N6gdJgxkXZb6bPU4QXYttilmkvzyb5Ukm8CXxPmjwJVrpsNYXnojTdEeqv3WTd41UA1l 1NuRHP3W/DYNXcpFaZHmapWmOQolfboqIb9WGIOVUE+619QeBBxj6cFziRVM1tbDMs/j OA/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=GWq/z6B6RuYDuDVhMARX3ir3nleZhwEGh0KERECcV1Y=; b=b+z7yWA6sXZi2YnkSjoeTfrONzmF3q2fKSCtOVca56k6ni0/Xa6zEAsGOQVW2SsS7t lFbfQOONINU9FR4ggDeFU9EOVUq7Cjo985EzOhWdM9uvIvU9II/A/8vv5gFYms++sUe2 02AeZjslBsgbPZKplGDL1/GWH8+j/E/ioArYo3BVJZwE8e3dAYC7ZrbQ0+Oe+rrLsG/5 EcNqJWCvkT6tpqVjNRYe+0PKXlUXGBHXySd9yjo36pQG/2/vbI2h41qkWVw7nSj6fhV2 nLpdbU6ctYg2vVvpGB5Dos/+yPoe9+zaf3c+X+zQXWFiwrFrqphttOnlQ0u87mJIf/Nu pL7w== X-Gm-Message-State: AElRT7Fu4XhCrCCH+k8DZuyV/Ef43lyhi3B4g4k66zO7npoGWLaedqr9 kBTxEJmY1e3MOf83Ibysups= X-Google-Smtp-Source: AG47ELv9gwYnd28OKyMC7nZnoV2U1BaOpTw4gqlhDkvkEBB6AeZaHNakxgLy/oJOX4kBDxdca698Uw== X-Received: by 10.28.111.200 with SMTP id c69mr3449294wmi.14.1521655265845; Wed, 21 Mar 2018 11:01:05 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:6062:6ad0:209:238d? ([2001:67c:370:128:6062:6ad0:209:238d]) by smtp.gmail.com with ESMTPSA id l10sm4318318wrf.37.2018.03.21.11.01.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Mar 2018 11:01:04 -0700 (PDT) Sender: Tony Li From: tony.li@tony.li Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_942D3304-049A-4A95-8F27-09B523E53023" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 21 Mar 2018 18:01:02 +0000 In-Reply-To: <0067F8CCF2F5491381D304C26AA83A02@SRA6> Cc: William Whyte , its , =?utf-8?Q?Fran=C3=A7ois_Simon?= , =?utf-8?B?SsOpcsO0bWUgSMOkcnJp?= , Tijink Jasja , Alexandre Petrescu , Kevin Smith , Abdussalam Baryun To: dickroy@alum.mit.edu References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <5cc6bd32-0812-288a-2db0-b0de53626f1e@gmail.com> <009c01d3c052$f0a78cc0$d1f6a640$@gmail.com> <007b01d3c0fe$15ad9540$4108bfc0$@eurecom.fr> <8daedb8d-8da1-aa02-33dd-ad81cf1a178e@gmail.com> <3934D4DC-F53C-47CF-8E47-FF70A07BC099@tony.li> <0067F8CCF2F5491381D304C26AA83A02@SRA6> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [ipwave] IPv6-over-OCB as a profile of 1609 WAVE X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 18:01:09 -0000 --Apple-Mail=_942D3304-049A-4A95-8F27-09B523E53023 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > The problem ism1609 is NOT endorsing any protocols, even it=E2=80=99s = own. 1609 simply says if you want to implement IP(v6), then you shall = follow the IETF RFCs that specify how to do it! 1609 is proposing a protocol that happens to carry several IPish things. = As previously mentioned, that oversteps our SDO gentlepeople=E2=80=99s = agreement on division of responsibilities. That is an issue that I=E2=80=99= d like to see addressed. In addition, the WRA description that I=E2=80=99ve been able to find is = just plain broken. Now, that=E2=80=99s probably not current, but it does = bear us looking at. If it=E2=80=99s going to exist, let=E2=80=99s get = it right. > Now, if there is a side channel for getting a local prefix, that is = out of scope of the IETF, and the IETF should not care! How the = information to perform SLAAC is obtained, as long as it is correct, is = of NO CONSEQUENCE to the SLAAC procedure. Telling someone they MUST = receive an RA before they can do SLACC is simply a bad idea. Providing = them with a means for getting that information, via an RA, is a good = idea, but NOT THE ONLY WAY! The IETF cares. Trust me, the IEEE cares when the IETF wants to play at = layer 2. Ask me offline about jumbo frames. Tony --Apple-Mail=_942D3304-049A-4A95-8F27-09B523E53023 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
The problem = ism1609 is NOT endorsing any protocols, even it=E2=80=99s own.  = 1609 simply says if you want to implement IP(v6), then you shall follow = the IETF RFCs that specify how to do it!


1609 is proposing a = protocol that happens to carry several IPish things. As previously = mentioned, that oversteps our SDO gentlepeople=E2=80=99s agreement on = division of responsibilities.  That is an issue that I=E2=80=99d = like to see addressed.

In addition, = the WRA description that I=E2=80=99ve been able to find is just plain = broken. Now, that=E2=80=99s probably not current, but it does bear us = looking at.  If it=E2=80=99s going to exist, let=E2=80=99s get it = right.


Now, if there is a side = channel for getting a local prefix, that is out of scope of the IETF, = and the IETF should not care!  How the information to perform SLAAC = is obtained, as long as it is correct, is of NO CONSEQUENCE to the SLAAC = procedure.  Telling someone they MUST receive an RA before they can = do SLACC is simply a bad idea.  Providing them with a means for = getting that information, via an RA, is a good idea, but NOT THE ONLY = WAY!


The IETF cares. Trust = me, the IEEE cares when the IETF wants to play at layer 2.  Ask me = offline about jumbo frames.

Tony

= --Apple-Mail=_942D3304-049A-4A95-8F27-09B523E53023-- From nobody Wed Mar 21 11:28: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 9C38212E888 for ; Wed, 21 Mar 2018 11:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 TYgEPKW8ZBXV for ; Wed, 21 Mar 2018 11:28:11 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C84112E8C1 for ; Wed, 21 Mar 2018 11:28:11 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id t6so11656561wmt.5 for ; Wed, 21 Mar 2018 11:28:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=fbwZc+MqQccuNYVE4kXImGHBKxsdvVkWk6xzj6APW/I=; b=VrL34BrzWU1cKDOIib0F5/gg4ita19jhRX7AC0Mn7PCPqJacnAvD9nGCRfyBg3+2NC 8J9bZtglUeDcc2WxxNeD2uHBdxBPj8l0EdUd5EtM2gAL50E6hpo3hqyEY/CEvcAC9vWg Ih8QGynnw/8BKGNQCtO9SC5kSh3mL2s8xZPgvzW2qEV3/OWInev4BCxVgxnq3bMF+2F4 i9S9Has0qxl5TB1aZVV22ZhPTwUXIAfzDHrLdI0ndh5PAWjvjV/lzTVxzHnc0zyirZhg pwDpBTJG7R/gOcSvHDf2EXFzVo3nuvstCvuCdcNKeDbhNfLrG3coQc1uhES0KsJGn15f beJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=fbwZc+MqQccuNYVE4kXImGHBKxsdvVkWk6xzj6APW/I=; b=p1pAsjpf4Nwu5OeGVAD5GW0Tu87RR/yNx6e/C3/CmafCJbe7roFumKCHYAqClzg0wJ ckK+ESKG1iy/kVexsoAZweG4SjlbXsO2qICFjHQoDOvG9X+ZIa3g0qcPpX70xOnwIej2 cNBJRHwpjpoPo9ro/EE/xlmS+pFIIGWB5ebPgaxwzwIEb+iea+XTh5VbhfnCsdt+Zc2C CVIMpp0zEkz2KBEGp35w8HrG9VqOpD38foQc9+jI9wt8bnR+WKExO+R6zQIh2HLgFM2V MwvtYTk8gCYExrUSYdfeCJWHuXrnlNq2tZtiSvnEOLSGoNA10IYnQrP40Sd3B04jqfPO XMzg== X-Gm-Message-State: AElRT7FOJvipqV0oXC9BKvpHFmQNpzapL2kBCQC0WxNltu5z5gy5tvNe 7OJWeBZ0/ggleh7MMYhrsFQ= X-Google-Smtp-Source: AG47ELu0/DpXgiGzAo1COlWaZWC9Hq7HdeG4X2gFDoPscr1sBrr4wQekClEw9g84X0l4XK5wqz6Yog== X-Received: by 10.28.197.205 with SMTP id v196mr3403859wmf.37.1521656890011; Wed, 21 Mar 2018 11:28:10 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:6062:6ad0:209:238d? ([2001:67c:370:128:6062:6ad0:209:238d]) by smtp.gmail.com with ESMTPSA id z73sm8200337wrb.88.2018.03.21.11.28.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Mar 2018 11:28:08 -0700 (PDT) Sender: Tony Li From: tony.li@tony.li Message-Id: <56C5C069-A77B-41CD-B8F0-1A8B00416A60@tony.li> Content-Type: multipart/alternative; boundary="Apple-Mail=_44B088A8-6571-4BE1-B15A-A808C7D95FBF" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 21 Mar 2018 18:28:05 +0000 In-Reply-To: <288486D24C7E44BEBCB997B0483FE75B@SRA6> Cc: its , =?utf-8?Q?Fran=C3=A7ois_Simon?= , William Whyte , =?utf-8?B?SsOpcsO0bWUgSMOkcnJp?= , Tijink Jasja , Alexandre Petrescu , Kevin Smith , Abdussalam Baryun To: dickroy@alum.mit.edu References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <5cc6bd32-0812-288a-2db0-b0de53626f1e@gmail.com> <009c01d3c052$f0a78cc0$d1f6a640$@gmail.com> <007b01d3c0fe$15ad9540$4108bfc0$@eurecom.fr> <8daedb8d-8da1-aa02-33dd-ad81cf1a178e@gmail.com> <0D822C86-92FD-4F06-B072-C9227EAD720F@tony.li> <288486D24C7E44BEBCB997B0483FE75B@SRA6> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [ipwave] IPv6-over-OCB as a profile of 1609 WAVE X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 18:28:14 -0000 --Apple-Mail=_44B088A8-6571-4BE1-B15A-A808C7D95FBF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > [RR] 1609.3 is a network (and transport layer) set of protocols. It = would be inappropriate and simply wrong to say well =E2=80=A6 you must = stick to layer two.=20 I see. Well, that being the case, you=E2=80=99ll pardon me if reject = the double standard. > It added the WRA for efficiency purposes, and vetted its contents with = IETF experts for what that=E2=80=99s worth:^))) =20 Good to know. Was this vetting done officially? Documented? Or = unofficially? Who looked at it? If it wasn=E2=80=99t documented before, it should be=E2=80=A6 Tony --Apple-Mail=_44B088A8-6571-4BE1-B15A-A808C7D95FBF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
[RR] 1609.3 is a network (and transport layer) set of = protocols. It would be inappropriate and simply wrong to say well =E2=80=A6=  you must stick to layer = two. 
<= /blockquote>


I = see.  Well, that being the case, you=E2=80=99ll pardon me if reject = the double standard.


It = added the WRA for efficiency purposes, and vetted its contents with IETF = experts for what that=E2=80=99s worth:^))) =  


Good to know.  Was this vetting done officially? =  Documented? Or unofficially? Who looked at it?

If it wasn=E2=80=99t = documented before, it should be=E2=80=A6

Tony


= --Apple-Mail=_44B088A8-6571-4BE1-B15A-A808C7D95FBF-- From nobody Wed Mar 21 11:43: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 405E4127871 for ; Wed, 21 Mar 2018 11:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOaJME7edb_L for ; Wed, 21 Mar 2018 11:43:46 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5D0B12E8D6 for ; Wed, 21 Mar 2018 11:43:17 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id h76so11595341wme.4 for ; Wed, 21 Mar 2018 11:43:17 -0700 (PDT) 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=9wc/ZFpY5HzXDqpbyEtBE39/N3iRkSq7hRXeDF85KD4=; b=o/bZpZccSxzRd4Ff6oAbmx0aCSUVsx4AvVz+WdpT3X5P92XhuLN7mdTwWPJG8Ji+Lz HlEbtc3RE1ytCwSD2RZA7vcDoEIWGWYEHFpHPo+KH/LXMs6do3QB9fWDZNBX6sjhbhhu zM0sRpnPjErgt3AiTcn8EfxOdtR64sfvLE6GXEBH63FxpTJNETNWOPE2Y+Sd/yAQYt0y Y7+Cmu9vS3XPR+Ceh7RtJROSf/UYyPekG6krLbY3WqlRZ8y8+JBN5ig0SuLI9qCsoKc7 73gMjO5MtxQ82evS2Q7SwhCpBhGObazPZ+kmURDE6J6vZRuG+fS45CsULxBt5Lf4vGaf VAEg== 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=9wc/ZFpY5HzXDqpbyEtBE39/N3iRkSq7hRXeDF85KD4=; b=XCPPHfMz7p7ftSZ+YeVyVWVjQJkwznXCoaNwselmKNCHiMmdJEIFv+/lOZJEQvfSTI 7HKTJK7T7m1qQolY2u2E3lBr1dmTSTG0PyLcMxYRhAXnRu6U/sb4RVnflpbJ6tOqQE8t Q60ejb9UWQVvniwfiYYHOqPfgBVio8bOWC7IXopQYJT3GYCkeoR1Je42j0a+1HaYbouN tNQpip3XDKib1HaOoaH/32iF1GQ0cvbHa2cDSbJrwR9rndNe0QL+XaudiOZRE7aSZaNx Rk4T9uriXyAmee0kNgpFy7wUDNPa/HbtH14h6AAFjuRD1r7EjEcXbAc905YZNn6hUs39 khGQ== X-Gm-Message-State: AElRT7FMkSvJiWWkhCPHhuaX1ZUD/2xvZZ6wpeVfBObErj6avKuaJZdk 5v8KhjyPBTdEkwsBgI5vJFVAQ8s7lMo= X-Google-Smtp-Source: AG47ELtk27eZKW3S+riqLmEaxKMp2J6c+qDVbxHNB0AZIQzsPt7WBMGADrgYBqgg1ME4lVaVFuLpcQ== X-Received: by 10.28.174.80 with SMTP id x77mr3656274wme.130.1521657796503; Wed, 21 Mar 2018 11:43:16 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:6062:6ad0:209:238d? ([2001:67c:370:128:6062:6ad0:209:238d]) by smtp.gmail.com with ESMTPSA id 11sm4735092wmd.1.2018.03.21.11.43.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Mar 2018 11:43:15 -0700 (PDT) From: Tony Li Message-Id: <680BF133-F714-4005-A96F-9D58876D5EF8@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_795E6DC9-345D-4A7E-B1C9-02702007E4EC" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 21 Mar 2018 18:43:14 +0000 In-Reply-To: Cc: Alexandre Petrescu , its , =?utf-8?Q?Fran=C3=A7ois_Simon?= , =?utf-8?B?SsOpcsO0bWUgSMOkcnJp?= , Tijink Jasja , Kevin Smith , Abdussalam Baryun To: dickroy@alum.mit.edu References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <5cc6bd32-0812-288a-2db0-b0de53626f1e@gmail.com> <009c01d3c052$f0a78cc0$d1f6a640$@gmail.com> <007b01d3c0fe$15ad9540$4108bfc0$@eurecom.fr> <8daedb8d-8da1-aa02-33dd-ad81cf1a178e@gmail.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [ipwave] IPv6-over-OCB as a profile of 1609 WAVE X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 18:43:48 -0000 --Apple-Mail=_795E6DC9-345D-4A7E-B1C9-02702007E4EC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Can the current IPv6 protocols handle rapidly varying network = topologies (such as those in vehicular environments)? Well, that depends on your definition of =E2=80=98handle=E2=80=99. In my = experience, they certainly work, but to my level of expectations. If = you=E2=80=99re expecting something else (and you probably are), the the = answer may vary. > Would the IETF be willing to develop new protocols or modify already = existing ones to handle the situation? That would be a =E2=80=98maybe'. Depends on what needs changing. If = you want a change to the base IPv6 spec, that=E2=80=99s pretty much a = no. [Yes, I=E2=80=99ve tried=E2=80=A6]. If you want to change BGP or = DNS, that=E2=80=99s probably a no. If you want to do something local to OCB, that=E2=80=99s more = manageable. So far, when I ask questions about what _doesn=E2=80=99t_ work already, = I don=E2=80=99t seem to get specific use cases and problem statements. = So the only problems that I see us needing to solve are encapsulation = and MTU, as addressed by the draft. > NOTICE: Nowhere did we mention ANYTHING about layers below the = network layer and we sure as heck didn=E2=80=99t mention = 1609.anything!!!! Well, it=E2=80=99s kinda hard to make progress without those. > Instead, we got this! Somehow, someway, the whole thing got WAY OFF = TRACK. It has now evolved into a useless and fruitless exercise of the = IETF trying to tell implementers how to do their jobs. This is a = COMPLETE WASTE OF TIME. They are not listening to any of your shalls or = musts. =20 > =20 > I am retiring from this discussion until such time as you are prepared = to answer the question posed above. Anything else is again a complete = waste of everyone=E2=80=99s time. Standardization requires cooperation, which requires rough consensus, = which requires discussion. Sorry to see you go, =20 Implementer Tony --Apple-Mail=_795E6DC9-345D-4A7E-B1C9-02702007E4EC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Can the current IPv6 protocols handle rapidly varying = network topologies (such as those in vehicular = environments)?

Well, that depends on your definition of = =E2=80=98handle=E2=80=99. In my experience, they certainly work, but to = my level of expectations. If you=E2=80=99re expecting something else = (and you probably are), the the answer may vary.


Would the IETF be willing to develop new = protocols or modify already existing ones to handle the = situation?


That would be a = =E2=80=98maybe'.  Depends on what needs changing.  If you want = a change to the base IPv6 spec, that=E2=80=99s pretty much a no. =  [Yes, I=E2=80=99ve tried=E2=80=A6]. If you want to change BGP or = DNS, that=E2=80=99s probably a no.

If = you want to do something local to OCB, that=E2=80=99s more = manageable.


So far, when I ask questions about what = _doesn=E2=80=99t_ work already, I don=E2=80=99t seem to get specific use = cases and problem statements. So the only problems that I see us needing = to solve are encapsulation and MTU, as addressed by the = draft.


NOTICE:  Nowhere did we mention ANYTHING about = layers below the network layer and we sure as heck didn=E2=80=99t = mention 1609.anything!!!!


Well, it=E2=80=99s kinda = hard to make progress without those.


Instead, we got this!  Somehow, someway, the = whole thing got WAY OFF TRACK.  It has now evolved into a useless = and fruitless exercise of the IETF trying to tell implementers how to do = their jobs.  This is a COMPLETE WASTE OF TIME.  They are not = listening to any of your shalls or musts. =  
 
I = am retiring from this discussion until such time as you are prepared to = answer the question posed above.  Anything else is again a complete = waste of everyone=E2=80=99s time.


Standardization requires = cooperation, which requires rough consensus, which requires = discussion.

Sorry to see you go, =  

Implementer = Tony


= --Apple-Mail=_795E6DC9-345D-4A7E-B1C9-02702007E4EC-- From nobody Wed Mar 21 11: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 0DB3F127909 for ; Wed, 21 Mar 2018 11:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 FjpHitJBbrRJ for ; Wed, 21 Mar 2018 11:51:02 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A696127978 for ; Wed, 21 Mar 2018 11:51:02 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id 139so11783563wmn.2 for ; Wed, 21 Mar 2018 11:51:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=oK/LjNivKIzZfCWdvD9r8e8wDy1zXHFBjVsZrwdgo0I=; b=RJNxoF3XAEcSpRA8Er6/mzGAXKbNJL+fgWybfL+Iho79F3gzg1EcDLzSmi+5T/W9h3 R4iMX23MlrsHG/p6tCwFm13wRnGlMW1+6D0pryRw3A5bDD0t81i3qh8wLFJu3wIszR/p OpMetn8sIWQTOhIJ3BdZv0b96vVz7QAby+REXo7ecyoAgSuOXtV97BglxynBerjN3Vfl 9mxcAC18+xuBrf+KXh7bXWuUJOPty8ZLw8Fq/E3WlIUL/fLmiSo4p8Z4oYoaN6/OMddp LS5gG8nhRU9kIDXLEdt+K+M94+5LdAYYNOcE8kosQSjZ9rgxoDeE5o7c5eNnm0a96bFm 5O/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=oK/LjNivKIzZfCWdvD9r8e8wDy1zXHFBjVsZrwdgo0I=; b=RyXQ1MsJIzXqSoos3nYRlMbDr6bnTkb/RUgfo4N5pdZkqS2urvzueWuzwlRn2r57wr dPQ3HDVpz6f50STu8YntX/Q5+KCBIvbGS+sObHhqhMvxD9mB/WQabVKxUVDlXTSdOtLE tdj8r2UsEwz1f0c98+W3pCMsFeiBQuWbk8T++eAKEU3hkRlATKbom5jXwBLEg+RkfZKT 7MX5fvl6I7wHH5nH69dJyCiJkNEElAUCTOrrxQYBrsFVFW6vl9VZCfXNraSIkoFr7Ub8 iA9ZX+pX/4INAmfexn99NUfJHYS7WCIduvUL0YJ3x0DUTLvTsyBr9wdS7pjFNG9kmX9k ZUhA== X-Gm-Message-State: AElRT7FfgTA7fhIQUauwCo37p8+JWOAhtRoiHHLVrF2ooIUuCiFKQgA+ dsbPSd9ABpR2xHrylL4j5Kc= X-Google-Smtp-Source: AG47ELun11V2WDrVV1wQ3ZqklN6ijvUTSKgYmJpF6/nu2gVJU62jhk1SXSa5VDDsaw1g6DIqbdR5QA== X-Received: by 10.28.105.78 with SMTP id e75mr3336738wmc.7.1521658260744; Wed, 21 Mar 2018 11:51:00 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:6062:6ad0:209:238d? ([2001:67c:370:128:6062:6ad0:209:238d]) by smtp.gmail.com with ESMTPSA id y145sm4335229wmd.43.2018.03.21.11.50.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Mar 2018 11:50:59 -0700 (PDT) Sender: Tony Li From: tony.li@tony.li Message-Id: <875DFF71-9443-4405-BC4F-8DC4B6F58F33@tony.li> Content-Type: multipart/alternative; boundary="Apple-Mail=_ACE8746C-5872-45F2-8B7A-53451E7DED31" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 21 Mar 2018 18:50:54 +0000 In-Reply-To: Cc: its , =?utf-8?Q?Fran=C3=A7ois_Simon?= , William Whyte , =?utf-8?B?SsOpcsO0bWUgSMOkcnJp?= , Tijink Jasja , Alexandre Petrescu , Kevin Smith , Abdussalam Baryun To: dickroy@alum.mit.edu References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <5cc6bd32-0812-288a-2db0-b0de53626f1e@gmail.com> <009c01d3c052$f0a78cc0$d1f6a640$@gmail.com> <007b01d3c0fe$15ad9540$4108bfc0$@eurecom.fr> <8daedb8d-8da1-aa02-33dd-ad81cf1a178e@gmail.com> <0D822C86-92FD-4F06-B072-C9227EAD720F@tony.li> <288486D24C7E44BEBCB997B0483FE75B@SRA6> <56C5C069-A77B-41CD-B8F0-1A8B00416A60@tony.li> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [ipwave] IPv6-over-OCB as a profile of 1609 WAVE X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 18:51:04 -0000 --Apple-Mail=_ACE8746C-5872-45F2-8B7A-53451E7DED31 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 21, 2018, at 6:35 PM, Dick Roy wrote: >=20 > =E2=80=9CGood to know. Was this vetting done officially? Documented? = Or unofficially? Who looked at it?=E2=80=9D > =20 > You may know him? His name is THIERRY ERNST. If you don=E2=80=99t = know him, allow me to introduce you to him. He=E2=80=99s a really nice = guy!:^))) and very knowledgeable in all matter IP-related! > :^))) Cool. Unofficially then. =20 How about an upgrade to a broader audience? More eyes catch more = bugs... Tony --Apple-Mail=_ACE8746C-5872-45F2-8B7A-53451E7DED31 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Mar 21, 2018, at 6:35 PM, Dick Roy <dickroy@alum.mit.edu> wrote:

=E2=80=9CGood to know. =  Was this vetting done officially?  Documented? Or = unofficially? Who looked at it?=E2=80=9D
 
You may know him?  His = name is THIERRY ERNST.  If you don=E2=80=99t know him, allow me to = introduce you to him.  He=E2=80=99s a really nice guy!:^))) and = very knowledgeable in all matter IP-related!
:^)))


Cool. = Unofficially then.  

How about an upgrade to a broader audience?  More eyes = catch more bugs...

Tony

= --Apple-Mail=_ACE8746C-5872-45F2-8B7A-53451E7DED31-- From nobody Wed Mar 21 11:54: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 325C512EA8F for ; Wed, 21 Mar 2018 11:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 KRJnnG3wqT2a for ; Wed, 21 Mar 2018 11:54:43 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E45BA12EAF0 for ; Wed, 21 Mar 2018 11:54:28 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id a20so23257345wmd.1 for ; Wed, 21 Mar 2018 11:54:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=iDQIo+oRjxfcHlNiGftJZAzNeOS8QNUlJvgvkDTY21s=; b=HkK5x9ryEG9xiwwt0YaYjd4FxKJH/eGhu5YeX6PFgs6dGJJeZU29XDocg+l0SFzTVJ k+E76HmjVru+bZJNc3zzB9W0PtgjENeJUyYpygKoxyXerqTybqDZyuFmFIMTqfNR5I8h R4vfJbv8blA6zEATMAi2rUeH00Uk20uc2GOaFqBLEzzucnjSFgbF1hJJy4Ez0LB5ORq4 AU4nXRRQ1CR+kOhV+Z7HfEL8ApJ5yldThaTC4Sh5qz8BYEETV9I91cAhVOu3CE1LzWlU 5hh/hzmgc9eaypd7SyFlSWUXtCZw+xZZWjDtU4b0iGPBcXyu+yM4cLQ+YP5QGZ4GZgC+ Mw6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=iDQIo+oRjxfcHlNiGftJZAzNeOS8QNUlJvgvkDTY21s=; b=LVkVf6fJQzWHTt/8r5g67NpBSbL/dDZ9Gc5hekiIV47QXs5xvz9qlM4DPnsJGp8sm4 AArg/G/IERyA+jqtZTvK4pl4RiaJnYfquPwA6oFPU+BbMlkmSKikNUCdepEKt12DOF0k 2rX7x6zncTOF36q+fiUwEpF0Gl4I4CnxwSk+ufoocv0q0cYLjIHU2dPE/QIw/QyWE1rV tfuOs8jbbCwfMRY9CU+b0T1ycy5bj4rxVzCKWZyF623aJdq9mQerJ6D1M/Www6nqDjoD 2+t7tYQqa4ewheVqI99krEsiSIysSpbEwLhvS8uoVuvAohF16y3odMl+KjgvfA/ThjAs cBPQ== X-Gm-Message-State: AElRT7EZ3L/hNiu1My8I6NBcfSvo8x99gw5wLHBMYi3udYSl3qg4hopr lZObVJPnI9wzhiMBpmYyzvA= X-Google-Smtp-Source: AG47ELvwez+1ORrCYb14VYvLQdYe/3Xn7WVs9dPHzOdAf+VbK+eG5BwiiCXyDe4/0Eglyid2hfVTVA== X-Received: by 10.28.178.136 with SMTP id b130mr3776262wmf.68.1521658467494; Wed, 21 Mar 2018 11:54:27 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:6062:6ad0:209:238d? ([2001:67c:370:128:6062:6ad0:209:238d]) by smtp.gmail.com with ESMTPSA id k11sm1963219wmi.35.2018.03.21.11.54.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Mar 2018 11:54:26 -0700 (PDT) Sender: Tony Li From: tony.li@tony.li Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_3D74DC62-9579-4B87-A3A9-D05DF1CAE6C9" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 21 Mar 2018 18:54:24 +0000 In-Reply-To: <85E00484BDE54001902719F4AE9193A2@SRA6> Cc: its , =?utf-8?Q?Fran=C3=A7ois_Simon?= , William Whyte , =?utf-8?B?SsOpcsO0bWUgSMOkcnJp?= , Tijink Jasja , Alexandre Petrescu , Kevin Smith , Abdussalam Baryun To: dickroy@alum.mit.edu References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <5cc6bd32-0812-288a-2db0-b0de53626f1e@gmail.com> <009c01d3c052$f0a78cc0$d1f6a640$@gmail.com> <007b01d3c0fe$15ad9540$4108bfc0$@eurecom.fr> <8daedb8d-8da1-aa02-33dd-ad81cf1a178e@gmail.com> <3934D4DC-F53C-47CF-8E47-FF70A07BC099@tony.li> <0067F8CCF2F5491381D304C26AA83A02@SRA6> <85E00484BDE54001902719F4AE9193A2@SRA6> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [ipwave] IPv6-over-OCB as a profile of 1609 WAVE X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 18:54:49 -0000 --Apple-Mail=_3D74DC62-9579-4B87-A3A9-D05DF1CAE6C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > 1609 is proposing a protocol that happens to carry several IPish = things.=20 > [RR] You are confused. It is NOT!=20 I see a packet with a prefix, prefix length, default gateway, and = primary DNS server. I=E2=80=99d say that qualifies. > As previously mentioned, that oversteps our SDO gentlepeople=E2=80=99s = agreement on division of responsibilities. That is an issue that I=E2=80=99= d like to see addressed. > [RR] THERE IS NOTHING TO ADDRESS other than the misunderstanding = within the IETF of what 1609 really is. To fix that, guess what, IETF = people have to READ IT! I know that=E2=80=99s a tough pill to swallow, = but c=E2=80=99est la vie! Kinda hard to read when it=E2=80=99s behind a paywall. Now I think I have a secret copy on backups at home, but I can=E2=80=99t = get to it right now. > In addition, the WRA description that I=E2=80=99ve been able to find = is just plain broken. Now, that=E2=80=99s probably not current, but it = does bear us looking at. If it=E2=80=99s going to exist, let=E2=80=99s = get it right. > [RR] Clearly indicates you and probably all the others as well have = not read the spec. My point is made. I=E2=80=99d love to. Please put a copy on the table. > The IETF cares. Trust me, the IEEE cares when the IETF wants to play = at layer 2. Ask me offline about jumbo frames. > [RR] People want to overstep their bounds all the time; that doesn=E2=80= =99t make it right, nor does it make it a good idea necessarily. There = are times when it is called for; THIS IS NOT ONE OF THEM!=20 And 1609 has overstepped its bounds. That doesn=E2=80=99t make it right. = And yelling louder at me isn=E2=80=99t going to change that. Tony --Apple-Mail=_3D74DC62-9579-4B87-A3A9-D05DF1CAE6C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

1609 is proposing a protocol that happens to = carry several IPish things. 
[RR] You are confused.  It is = NOT! 
<= /div>


I see a packet with a = prefix, prefix length, default gateway, and primary DNS server. =  I=E2=80=99d say that qualifies.


As previously = mentioned, that oversteps our SDO gentlepeople=E2=80=99s agreement on = division of responsibilities.  That is an issue that I=E2=80=99d = like to see addressed.
[RR] THERE IS NOTHING TO ADDRESS = other than the misunderstanding within the IETF of what 1609 really is. =  To fix that, guess what, IETF people have to READ IT! I know = that=E2=80=99s a tough pill to swallow, but c=E2=80=99est la = vie!


Kinda hard = to read when it=E2=80=99s behind a paywall.

Now I think I have a secret copy on backups at = home, but I can=E2=80=99t get to it right now.


In = addition, the WRA description that I=E2=80=99ve been able to find is = just plain broken. Now, that=E2=80=99s probably not current, but it does = bear us looking at.  If it=E2=80=99s going to exist, let=E2=80=99s = get it right.
[RR] Clearly indicates you and = probably all the others as well have not read the spec.  My point = is made.


I=E2=80=99d = love to.  Please put a copy on the table.


The IETF cares. = Trust me, the IEEE cares when the IETF wants to play at layer 2. =  Ask me offline about jumbo frames.
[RR] People want to overstep their = bounds all the time; that doesn=E2=80=99t make it right, nor does it = make it a good idea necessarily. There are times when it is called for; = THIS IS NOT ONE OF THEM! 


And 1609 has = overstepped its bounds. That doesn=E2=80=99t make it right.  And = yelling louder at me isn=E2=80=99t going to change that.

Tony


= --Apple-Mail=_3D74DC62-9579-4B87-A3A9-D05DF1CAE6C9-- From nobody Wed Mar 21 13:11: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 94CED126DFF for ; Wed, 21 Mar 2018 13:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4NZ8icXHNWMt for ; Wed, 21 Mar 2018 13:11:49 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7946112785F for ; Wed, 21 Mar 2018 13:11:49 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w2LKBeOS026589; Wed, 21 Mar 2018 21:11:40 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id BF23D206F4C; Wed, 21 Mar 2018 21:11: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 A3ABC206F22; Wed, 21 Mar 2018 21:11:40 +0100 (CET) Received: from [132.166.84.91] ([132.166.84.91]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w2LKBdS0015717; Wed, 21 Mar 2018 21:11:39 +0100 To: dickroy@alum.mit.edu, "'Tony Li'" Cc: "'its'" , "=?UTF-8?Q?'Fran=c3=a7ois_Simon'?=" , =?UTF-8?B?J0rDqXLDtG1lIEjDpHJyaSc=?= , "'Tijink Jasja'" , "'Kevin Smith'" , "'Abdussalam Baryun'" References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <5cc6bd32-0812-288a-2db0-b0de53626f1e@gmail.com> <009c01d3c052$f0a78cc0$d1f6a640$@gmail.com> <007b01d3c0fe$15ad9540$4108bfc0$@eurecom.fr> <8daedb8d-8da1-aa02-33dd-ad81cf1a178e@gmail.com> From: Alexandre Petrescu Message-ID: Date: Wed, 21 Mar 2018 21:11:39 +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] IPv6-over-OCB as a profile of 1609 WAVE X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 20:11:52 -0000 Le 21/03/2018 19:33, Dick Roy a crit: > When Thierry and I (and a few others) first decided to approach the IETF > years ago now, the goals were VERY SIMPLE. Get the IETF to answer the > following very simple question: > > Can the current IPv6 protocols handle rapidly varying network topologies > (such as those in vehicular environments)? YEs, and we went through the questions many times during several BoFs. If you want a simple answer to that simple question, it is something like this: use MANET, Babel, Mobile IP, optimistic DAD, fast RAs (RFCs exist for each) - it should work. Why would one think they would not work? > If the answer were NO, then the question was: > > Would the IETF be willing to develop new protocols or modify already > existing ones to handle the situation? > > And we were hoping the answer would be yes! > > NOTICE: Nowhere did we mention ANYTHING about layers below the network > layer and we sure as heck didnt mention 1609.anything!!!! > > Instead, we got this! I think IPv6-over-OCB is the right thing ISO TC204 should refer to, at this time. For other things, we should ask ISO TC204 what kind of developments it sees. > Somehow, someway, the whole thing got WAY OFF > TRACK. It has now evolved into a useless and fruitless exercise of the > IETF trying to tell implementers how to do their jobs. This is a > COMPLETE WASTE OF TIME. They are not listening to any of your shalls or > musts. I dont know why you say so. MTU 1500, QoSData AC_BK and Opaque IIDs are highly likely to be implemented as we speak. MAC-based IIDs (as opposed to Opaque IIDs) are wrong for privacy. MTU 2300 is not respected by the IP stack (it starts fragmenting at 1500 by default). Alex > > I am retiring from this discussion until such time as you are prepared > to answer the question posed above. Anything else is again a complete > waste of everyones time. > > RR > > ------------------------------------------------------------------------ > > *From:*its [mailto:its-bounces@ietf.org] *On Behalf Of *Tony Li > *Sent:* Wednesday, March 21, 2018 2:43 PM > *To:* Alexandre Petrescu > *Cc:* its; Franois Simon; Jrme Hrri; Tijink Jasja; Kevin Smith; > Abdussalam Baryun > *Subject:* Re: [ipwave] IPv6-over-OCB as a profile of 1609 WAVE > > > > On Mar 21, 2018, at 12:18 PM, Alexandre Petrescu > > wrote: > > It is normal that draft-ietf-ipwave-ipv6-over-80211ocb-22 does not > support WRA, because WRA is not an IP message. > > If one wants 1609.3-SLAAC to work with WRA (rather than RA) then there > are a few questions IMHO (In My Humble Oppinion). None of these impacts > draft-ietf-ipwave-ipv6-over-80211ocb-22. > > - decide whether only the prefix, or other parts from RA too need to be > reflected in the WRA. (lifetimes, others, check RFC4862) > - decide whether in IEEE 1609.3 the default route comes from the WRA as > well (not just the prefix). If yes, decide whether the address of the > default router comes from the src address of the WRA or from an SLLAO > carried by the WRA. > - decide whether you want a system to work correctly while only WRA is > present, both WRA and RA, or just RA. > - decide whether the prefix length in the WRA must be precisely 64, or > can be of another length. > - decide whether the Interface ID definition in this draft can be used > for the IEEE 1609.3-SLAAC. I hope yes. > - others. > > Our draft really should say something about WRA, one way or another. > > Lacking any compelling reason to use WRA, I would propose that we say > that WRA should NOT be used. > > Tony > From nobody Wed Mar 21 13:28: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 72553128896 for ; Wed, 21 Mar 2018 13:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhE3htRw9FLP for ; Wed, 21 Mar 2018 13:28:09 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BF1C127AD4 for ; Wed, 21 Mar 2018 13:28:08 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w2LKRx38039566; Wed, 21 Mar 2018 21:27:59 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id AFE7F206F4C; Wed, 21 Mar 2018 21:27:59 +0100 (CET) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 96460202923; Wed, 21 Mar 2018 21:27:59 +0100 (CET) Received: from [132.166.84.91] ([132.166.84.91]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w2LKRwvZ007602; Wed, 21 Mar 2018 21:27:58 +0100 To: dickroy@alum.mit.edu, "'Tijink Jasja'" , =?UTF-8?B?J0rDqXLDtG1lIEjDpHJyaSc=?= , "'Abdussalam Baryun'" , "=?UTF-8?Q?'Fran=c3=a7ois_Simon'?=" Cc: "'Kevin Smith'" , "'its'" References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <5cc6bd32-0812-288a-2db0-b0de53626f1e@gmail.com> <009c01d3c052$f0a78cc0$d1f6a640$@gmail.com> <007b01d3c0fe$15ad9540$4108bfc0$@eurecom.fr> <809DC8CFA3564BC58531C82B2C576602@SRA6> <3ad8db38-cf22-2703-ab14-9bf05d2d5860@gmail.com> From: Alexandre Petrescu Message-ID: Date: Wed, 21 Mar 2018 21:27: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] =?utf-8?q?=5Bipwave=C3=AE=5D_IPv6-over-OCB_as_a_profile?= =?utf-8?q?_of_1609_WAVE?= X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 20:28:11 -0000 Le 21/03/2018 à 18:52, Dick Roy a écrit : [...] > */[RR] So what? If I get a default route from divine intervention, > and it is correct, who the heck cares? For the RFCs to say that > something MUST be done in a particular way is simply bad standards > writing when it does not involve interoperability. If I get valid > information I need from some other means, that should be allowed, > full stop! /* Dick - I invite you to join the 6man and v6ops WGs and state there that the default route might arrive correctly by other means than by RA. You will hit opposition from many people of large companies considering themselves to somehow know better what is best for Internet. People trust them. For my part, if you can persuade them, and consequently the IETF, that the default route can come by something else, I might have a draft and 'running code' ready proposing to do it with DHCPv6 rather than with RA. Two or three other groups of people proposed same. Still it cant approach any measure of 'rough consensus' at IETF. I dont know why WRA to deliver the default route can get any more acceptance than what was proposed with DHCPv6. Finally, the delivery of default route is not a matter that typical IPv6-over-doo documents deal with. As such, no need to write about it in this draft. (I gave presentations several times during IETF BoFs and IETF telcos about what a typical IPv6-over-foo document does, and the audiences ranged between 10 to 100: nobody complained, which is rare at IETF; the presentations are available online). Alex > > Other RFCs say that the only means to obtain a default route is from > an > > RA (not from DHCP, not from something else like WRA). > > */[RR] Same as above!/* > > Alex > > _______________________________________________ > > its mailing list > > its@ietf.org > > https://www.ietf.org/mailman/listinfo/its > From nobody Wed Mar 21 16:01: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 C34C212E059 for ; Wed, 21 Mar 2018 16:00:54 -0700 (PDT) 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 mIvz-vf72gYY for ; Wed, 21 Mar 2018 16:00:52 -0700 (PDT) Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E23412E03D for ; Wed, 21 Mar 2018 16:00:52 -0700 (PDT) Received: by mail-yb0-x232.google.com with SMTP id v8-v6so2310892ybm.11 for ; Wed, 21 Mar 2018 16:00:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Rk7pqrJAzOTv2WoRYzMKf+qNTpFi2V8P7wACQ///PuI=; b=VDhVj2JGkojfE1eyGSKqIVQ42FZkJKpBGAkhyBGvbcNtZfCE2kTx6MJpLtJALAUsj+ t9vQaoJIWsc4mjUg2405HRpNSjOFBYDxNk9owSn46GilajTaC3a2JZYknsX1j6J/ymeC Tp21uD0g8z4mSet2hjVE7WNwHXKuu46cOmgwvf28JbYGq8vepEWaX99zY0adxrEb4Jrz 3crmhc8BB12PxHEWGacoXf+ItTS4NCw5hvBJa7RGaCRDwr4UjAmTvlaPS7yv469ZPHE4 tehYqefvO0ulrRoTWSabi/4BLDPflmYEgoxM56eij164ui/Ze0BKQp2wHVn0SBobYqGO NenA== 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=Rk7pqrJAzOTv2WoRYzMKf+qNTpFi2V8P7wACQ///PuI=; b=GDzQde+mCxaZT93V/Za84d2TPgru0iNq4eGuAb0ToLD5Pn0vdk4AixkIk/i0N5eyCE IOwuUGAFgjvuWTZOKrLEv2WCzvvMz5uUHRKgnZdqqnnl7CrkljnnWR3uDyedWVrckQDW y2Fqdm8YsFUqrOMqFFAa9Lg5138X+vp3q7nm2yaaIkZ1ivyZFyHfQWEVwJG8Yq6CWzwC x8ZBVnjgDZdx0YyD9UORkSV991RTSnAh7++G6Kyn2KjcpXI+uGJcpyqnN8+0OjeRFhC/ ut45wQOVw30Ux/wimtxnrXQkrOQqDv5nHnhtCX4qh//OY94i6lVe9m8/Xj8240VJtA4M bnMQ== X-Gm-Message-State: AElRT7G+rw9RmabpECugztON4x8LVG/tsQoAnTwwcA0psUg5XXmDJkT0 GcXgaaM2U/gSybdVL4YOc6fMbuxc+g/O78OTI/o= X-Google-Smtp-Source: AG47ELtx0XAAYpOWgA4gy2oMVUheGthFus7ZSGrmsGbxq9H9KhtyElXJyaIaWgBVZxTqvHYUafGUjaOQ3XpTHirpEEU= X-Received: by 2002:a25:c245:: with SMTP id s66-v6mr13794519ybf.240.1521673251368; Wed, 21 Mar 2018 16:00:51 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:6b4e:0:0:0:0:0 with HTTP; Wed, 21 Mar 2018 16:00:50 -0700 (PDT) In-Reply-To: References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <5cc6bd32-0812-288a-2db0-b0de53626f1e@gmail.com> <009c01d3c052$f0a78cc0$d1f6a640$@gmail.com> <007b01d3c0fe$15ad9540$4108bfc0$@eurecom.fr> <809DC8CFA3564BC58531C82B2C576602@SRA6> <3ad8db38-cf22-2703-ab14-9bf05d2d5860@gmail.com> From: Michelle Wetterwald Date: Thu, 22 Mar 2018 00:00:50 +0100 Message-ID: To: Alexandre Petrescu Cc: Richard Roy , Tijink Jasja , =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , Abdussalam Baryun , =?UTF-8?Q?Fran=C3=A7ois_Simon?= , Kevin Smith , its Content-Type: multipart/alternative; boundary="0000000000009cb3b70567f42963" Archived-At: Subject: Re: [ipwave] =?utf-8?q?=5Bipwave=C3=AE=5D_IPv6-over-OCB_as_a_profile?= =?utf-8?q?_of_1609_WAVE?= X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 23:00:55 -0000 --0000000000009cb3b70567f42963 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I would like to come back on the initial topic of this discussion, i.e. IPv6-over-OCB as a profile of 1609 WAVE . I would say that I agree with Jerome, Fran=C3=A7ois, etc.. and don't see the reason why 1609 WAVE should = be mentioned as a basis for the present draft. 1609.3 has been referenced in the state of the art (SoA) draft "IP-based Vehicular Networking: Use Cases, Survey and Problem Statement" (draft-ietf-ipwave-vehicular-networking-02) as one standard that describes how to use IPv6 in the 1609 WAVE environment. This standard is part of the 1609 set of standards. Other similar standards exist which are also listed in that section of the SoA draft. I cannot see why implementers who are willing to work in other frameworks should have to use the 1609 WAVE as a basis when implementing this draft. This draft references the SoA draft, which references the IEEE 1609.3 standard (section 5.2 + sections 4.1.1, 4.1.2) as one possible way to implement vehicular networks. This is where it should stay, and we should only make sure that no frontal contradiction exists that may confuse implementers. From what I read in the past days, this is not the case. BTW, as editor of the text in section 5.2 the SoA draft, I encourage people from 1609 WAVE to check that is adequately summarizes the content of the standard and to comment as necessary. We received the request for more reviews of the SoA draft during the meeting on Monday morning. BR, Michelle 2018-03-21 21:27 GMT+01:00 Alexandre Petrescu : > > > Le 21/03/2018 =C3=A0 18:52, Dick Roy a =C3=A9crit : > [...] > >> */[RR] So what? If I get a default route from divine intervention, and >> it is correct, who the heck cares? For the RFCs to say that something MU= ST >> be done in a particular way is simply bad standards writing when it does >> not involve interoperability. If I get valid information I need from so= me >> other means, that should be allowed, full stop! /* >> > > Dick - I invite you to join the 6man and v6ops WGs and state there that > the default route might arrive correctly by other means than by RA. You > will hit opposition from many people of large companies considering > themselves to somehow know better what is best for Internet. People > trust them. > > For my part, if you can persuade them, and consequently the IETF, that > the default route can come by something else, I might have a draft and > 'running code' ready proposing to do it with DHCPv6 rather than with RA. > Two or three other groups of people proposed same. Still it cant > approach any measure of 'rough consensus' at IETF. > > I dont know why WRA to deliver the default route can get any more > acceptance than what was proposed with DHCPv6. > > Finally, the delivery of default route is not a matter that typical > IPv6-over-doo documents deal with. As such, no need to write about it > in this draft. > > (I gave presentations several times during IETF BoFs and IETF telcos > about what a typical IPv6-over-foo document does, and the audiences > ranged between 10 to 100: nobody complained, which is rare at IETF; the > presentations are available online). > > Alex > > >> Other RFCs say that the only means to obtain a default route is from an >> >> RA (not from DHCP, not from something else like WRA). >> >> */[RR] Same as above!/* >> >> Alex >> >> _______________________________________________ >> >> its mailing list >> >> its@ietf.org >> >> https://www.ietf.org/mailman/listinfo/its >> >> > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > --=20 Michelle Wetterwald michelle.wetterwald@gmail.com --0000000000009cb3b70567f42963 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I would like to come back on the initial topic of this = discussion, i.e. IPv6-over-OCB as a profile of 1609 WAVE . I would say that= I agree with Jerome, Fran=C3=A7ois, etc.. and=C2=A0don't see the reaso= n why 1609 WAVE should=C2=A0be mentioned=C2=A0as a basis for the present dr= aft.

1609.3 has been referenced in the state of the art (SoA) draft &= quot;IP-based Vehicular Networking: Use Cases, Survey and Problem Statement= " (draft-ietf-ipwave-vehicular-networking-02) as one standard that des= cribes how to use IPv6 in the 1609 WAVE environment. This standard is part = of the 1609 set of standards. Other similar standards exist which are also = listed in that section of the SoA draft. I cannot see why implementers who = are willing to work in other frameworks should have to use the 1609 WAVE=C2= =A0as a basis when implementing this draft.

This=C2=A0draft refere= nces the SoA draft, which references the IEEE 1609.3 standard (section=C2= =A05.2 + sections 4.1.1, 4.1.2) as one possible way to implement vehicular = networks. This is where it should stay, and we should only make sure that n= o frontal contradiction exists that may confuse implementers. From what I r= ead in the past days, this is not the case.=C2=A0

BTW, as ed= itor of the text in section 5.2 the SoA draft, I encourage people from 1609= WAVE to check that is adequately summarizes the content of the standard an= d to comment as necessary. We received the request for more reviews of the = SoA draft during the meeting on Monday morning.

BR= , Michelle

2= 018-03-21 21:27 GMT+01:00 Alexandre Petrescu <alexandre.petres= cu@gmail.com>:


Le 21/03/2018 =C3=A0 18:52, Dick Roy a =C3=A9crit :
[...]
*/[RR] So what?=C2=A0 If I get a default route from divine intervention, an= d it is correct, who the heck cares? For the RFCs to say that something MUS= T be done in a particular way is simply bad standards writing when it does = not involve interoperability.=C2=A0 If I get valid information I need from = some other means, that should be allowed, full stop! /*

Dick - I invite you to join the 6man and v6ops WGs and state there that
the default route might arrive correctly by other means than by RA. You
will hit opposition from many people of large companies considering
themselves to somehow know better what is best for Internet. People
trust them.

For my part, if you can persuade them, and consequently the IETF, that
the default route can come by something else, I might have a draft and
'running code' ready proposing to do it with DHCPv6 rather than wit= h RA.
=C2=A0Two or three other groups of people proposed same.=C2=A0 Still it can= t
approach any measure of 'rough consensus' at IETF.

I dont know why WRA to deliver the default route can get any more
acceptance than what was proposed with DHCPv6.

Finally, the delivery of default route is not a matter that typical
IPv6-over-doo documents deal with.=C2=A0 As such, no need to write about it=
in this draft.

(I gave presentations several times during IETF BoFs and IETF telcos
about what a typical IPv6-over-foo document does, and the audiences
ranged between 10 to 100: nobody complained, which is rare at IETF; the
presentations are available online).

Alex


Other RFCs say that the only means to obtain a default route is from an

RA (not from DHCP, not from something else like WRA).

 */[RR] Same as above!/*

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



--
Michelle Wetterwald
michelle.w= etterwald@gmail.com
--0000000000009cb3b70567f42963-- From nobody Wed Mar 21 16:07: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 4C22B12D574 for ; Wed, 21 Mar 2018 16:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sotCrCO5jA9w for ; Wed, 21 Mar 2018 16:07:09 -0700 (PDT) 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 A478D124D37 for ; Wed, 21 Mar 2018 16:07:09 -0700 (PDT) Received: by mail-ot0-x230.google.com with SMTP id v23-v6so7483374oth.9 for ; Wed, 21 Mar 2018 16:07:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VIHSpvZ8ymXB5jrPiM6DSU0XK7lFcpqtGNdlHUPH2Ns=; b=Y/VlX9UaqD4Blg4fGTYftFS11oxAfJj5jG6LNKQhkFOuRSirBcbVjopyIenR42nBNB bEnxzC3cU6OlbOrnrI79y4Zd4AMmS9VPVWcSL+hVc3PfcU5xZLwxJb4OEYd8auiGJYdn Xr5ktNjI243dq8wyF+BKRsJr4eiQHSOrxgRGnob8BejiSG4wFHAwpwf6WahE0v9L57mL 1sdMnTCp+LZ/URMkWr+TWOJv8cmRLNeM/0gGq+gPpzdHgmIVMeSFsxfa2yRPnHWss++X P7Mnl5V9ucx1b5aKUlOh0+SO/ZEwS10hyQ5dh9Yiyz7pbyZ8IoQixqeN+Kk4gPD96USk 61YA== 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=VIHSpvZ8ymXB5jrPiM6DSU0XK7lFcpqtGNdlHUPH2Ns=; b=O9IsDcu9KRByiXuPkdMxgsl+sbCEEU7p3MKo9DObLsoLPZYnO+ylvK3rZEjzEfcMK1 nXI2EnyHhk+dQbEFeQJlkE8L7KztpsUnr3EG1gRdbmGxmgolN0YapwnNzPSKOnbRHQMC j1iEnt0yTiR2+8V2ncZxqcSUvsGz/TQ7fd5AJs+8Q+tga2cPQmAdErW/Z0jZh7HxicUY bnFhyCrL9lGSaoXGl3JqTQqcRSbTys0TL1my7I/VDMYyIUPnL2vpdbYzOR4QHF5GoLLN ZyZ/PKJKQaXdyaGb9g0gOThUBxRaYvEu+xTLM7CiUU2bIhRfjNESMVk69h57K0roUTn0 HEtQ== X-Gm-Message-State: AElRT7EUf01R/uoqZZJJ6FpCHBPf9Z6MKZwvem5kug+whfZpQGvbYgn6 LeuQ2F+a1HUdpt3Tt/o+h4NbRoLQ8y1VSbcnYZQ= X-Google-Smtp-Source: AG47ELtkv0BtS/zHJJZespWmLYGu9H3JL79s6omLk/kQJT2Vw1dd2EPQhqErcAetZgWVMBlH+laCvaaGRBzctX96s7Q= X-Received: by 2002:a9d:26c2:: with SMTP id i2-v6mr11098514otd.132.1521673628968; Wed, 21 Mar 2018 16:07:08 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:1442:0:0:0:0:0 with HTTP; Wed, 21 Mar 2018 16:07:08 -0700 (PDT) In-Reply-To: References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <5cc6bd32-0812-288a-2db0-b0de53626f1e@gmail.com> <009c01d3c052$f0a78cc0$d1f6a640$@gmail.com> <007b01d3c0fe$15ad9540$4108bfc0$@eurecom.fr> <483EE910-B566-4760-B36B-91575C07F6D9@tony.li> From: Abdussalam Baryun Date: Thu, 22 Mar 2018 01:07:08 +0200 Message-ID: To: William Whyte Cc: Tony Li , =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , its , =?UTF-8?Q?Fran=C3=A7ois_Simon?= , Tijink Jasja , Alexandre Petrescu , Kevin Smith Content-Type: multipart/alternative; boundary="0000000000001e6bd90567f440fb" Archived-At: Subject: Re: [ipwave] =?utf-8?q?=5Bipwave=C3=AE=5D_IPv6-over-OCB_as_a_profile?= =?utf-8?q?_of_1609_WAVE?= X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 23:07:11 -0000 --0000000000001e6bd90567f440fb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 AB On Wed, Mar 21, 2018 at 12:26 PM, William Whyte wrote: > Hi Tony -- it's an alternative mechanism for configuration, not for > encapsulation, so I think "alternative" is better than "replacement" here= . > > William > > On Wed, Mar 21, 2018 at 6:22 AM, wrote: > >> >> >> However, we could add something like: =E2=80=9Cthis document describes a= n >> alternative mechanism to the IPv6 configuration described in 1609.3=E2= =80=9D, if >> people really want to see 1609.3 stated in this work. >> >> >> >> I=E2=80=99m fine with this and would suggest that we use the word =E2=80= =9Creplacement=E2=80=9D >> rather than =E2=80=9Calternative=E2=80=9D. We should not endorse two IP= v6 encapsulations. >> >> Tony >> >> >> >> _______________________________________________ >> 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 > --0000000000001e6bd90567f440fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1
AB

On Wed, Mar 21, 2018 at 12:26 PM, William W= hyte <wwhyte@onboardsecurity.com> wrote:
Hi Tony -- it's an alternative= mechanism for configuration, not for encapsulation, so I think "alter= native" is better than "replacement" here.

William

On Wed, Mar 21, 2018 at 6:22 AM, <tony.li@tony.l= i> wrote:


However, we could add something like: =E2=80= =9Cthis document describes an alternative mechanism to the IPv6 configurati= on described in 1609.3=E2=80=9D, if people really want to see 1609.3 stated= in this work.


I=E2=80=99m fine with this and would suggest that we use the word =E2=80= =9Creplacement=E2=80=9D rather than =E2=80=9Calternative=E2=80=9D.=C2=A0 We= should not endorse two IPv6 encapsulations.

Tony



________________= _______________________________
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
--0000000000001e6bd90567f440fb-- From nobody Wed Mar 21 16:15: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 5DE7612E858 for ; Wed, 21 Mar 2018 16:15:44 -0700 (PDT) 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 hyuqrSNC-Sna for ; Wed, 21 Mar 2018 16:15:42 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 670D2129C6E for ; Wed, 21 Mar 2018 16:15:42 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id f186-v6so5801945oig.4 for ; Wed, 21 Mar 2018 16:15:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cDrKXkzTAm5hIZK+DZ/KfzDH+9fSbL8PgopLqlahE7Q=; b=ihD+LHW/hypZbaBZtNx47BTI+VzKIl1XXpuaFVZ7DF/M0khXU/y3HKJjAP4xZ4C75O gp/mnzC0VBdUChwZI93gwnq9JjZskSSQVNLUnl6QPH1B1fQjm0ZRqM6MeBi8sLOt79NZ hsZ2PobvsgShUKuwEQmq5to8Gl7B332x/rYpbDkXxQix4SgkT4MfpPmRy6AJ3HRbH+VF tzZYlmKc+LqowMlBkXjTOtSEPp3or0LE08ay9PYb7hwdaumOBmAUYrvs4nMjCX8e0eBw N6vupZmsq1ETgheum9flyTySZ/D0+WUmdoSJRuTz6RkdATBHSkDhokeBRRQ7q0dH4RkP Hbkg== 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=cDrKXkzTAm5hIZK+DZ/KfzDH+9fSbL8PgopLqlahE7Q=; b=b8po37TrinqxAh6+scBjmHxGCrZzCnMlyayp7jG3Hl9zGtELKOySGbHsptuOrnlVCS /7K8B25vXR/ZIDDuN6GhVHreVEa0wDQWfwmoNcH5lDZDv7vm7eyKVCw58n+PRPSer+xV kYfwq/yx2G1l2gqDqcEvpoFeqFOvCG7nEQC4V9u2UjzmWUqEEtyhkDL57OSpnuFbRew0 4NdsZrj5EmQ7Lm134DoXODfMoZUWUFMYfVQ8yRxgvMAtwkQPxgZpbB2Tcv0Iyg2u3wM4 7t24Z4Yg36Ehu+albOqrtfngIBNY+X61c9czv9l8TPSbG/6uVpsqR5d2qLN3kTwQrzAg TNEw== X-Gm-Message-State: AElRT7HC3j9dJkUmST9osHlvahjUq3pb3bvFxCEXWvPvDEV46QqWLhAh 1aNqpaiQV9JANdokQbKPqxwhBAG9HWI38LuRsy0= X-Google-Smtp-Source: AG47ELsYd32tZEGZZZKLQb2PNLWHnuOBOUmT50uQsqGf31tUO7dVwvAXbPoMh5nzuRiavVoAP+PPPPfboOIcVjI/me8= X-Received: by 10.202.48.198 with SMTP id w189mr10373798oiw.29.1521674141435; Wed, 21 Mar 2018 16:15:41 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:1442:0:0:0:0:0 with HTTP; Wed, 21 Mar 2018 16:15:40 -0700 (PDT) In-Reply-To: References: <660BFCF2CF184B2C8ACA0743EA9BBB54@SRA6> From: Abdussalam Baryun Date: Thu, 22 Mar 2018 01:15:40 +0200 Message-ID: To: Russ Housley Cc: "its@ietf.org" Content-Type: multipart/alternative; boundary="001a113cc5b8aa0ebc0567f45e50" Archived-At: Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 23:15:44 -0000 --001a113cc5b8aa0ebc0567f45e50 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Mar 19, 2018 at 5:13 PM, Russ Housley wrote: > In the session earlier today, Alex offered text to resolve this topic. H= e > said: > > The IPv6 packet transmitted on 802.11-OCB MUST be immediately preceded > by a Logical Link Control (LLC) header and an 802.11 header. In the > LLC header, and in accordance with the EtherType Protocol > Discrimination (EPD), the value of the Type field MUST be set to > 0x86DD (IPv6). In the 802.11 header, the value of the Subtype > sub-field in the Frame Control field MUST be set to 8 (i.e. 'QoS > Data'); the value of the Traffic Identifier (TID) sub-field of the QoS > Control field of the 802.11 header MUST be set to binary 001 (i.e. > User Priority 'Background', QoS Access Category 'AC_BK'). > > No one in the room raised any concern with this text. If you have a > concern, please speak on the list now. > Suggest using SHOULD instead of MUST, > > In a another part of the meeting, J=C3=A9r=C3=B4me talked about Mapping I= P to Access > Category in 802.11-OCB. It was pointed out that RFC 8325 was recently > published on the standards track. Tony Li pointed out that there is no > integrity protection for these bits. > I support Jerome's comment. Regarding protections, it should be discussed in the last section of security, not in the draft body, all RFCs do that. > > As an individual, I wonder if it would be better to say something like: > If DiffServ is being used, set the QoS Access Category as described in RF= C > 8325, otherwise set the QoS Access Category of 'AC_BK'. > Yes that is correct, IMHO we need that in this draft. > > AB > > Russ > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > --001a113cc5b8aa0ebc0567f45e50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Mar 19, 2018 at 5:13 PM, Russ Housley <housley@vigilsec.com= > wrote:
In the session earlier today, Al= ex offered text to resolve this topic.=C2=A0 He said:

=C2=A0 =C2=A0The IPv6 packet transmitted on 802.11-OCB MUST be immediately = preceded
=C2=A0 =C2=A0by a Logical Link Control (LLC) header and an 802.11 header.= =C2=A0 In the
=C2=A0 =C2=A0LLC header, and in accordance with the EtherType Protocol
=C2=A0 =C2=A0Discrimination (EPD), the value of the Type field MUST be set = to
=C2=A0 =C2=A00x86DD (IPv6).=C2=A0 In the 802.11 header, the value of the Su= btype
=C2=A0 =C2=A0sub-field in the Frame Control field MUST be set to 8 (i.e. &#= 39;QoS
=C2=A0 =C2=A0Data'); the value of the Traffic Identifier (TID) sub-fiel= d of the QoS
=C2=A0 =C2=A0Control field of the 802.11 header MUST be set to binary 001 (= i.e.
=C2=A0 =C2=A0User Priority 'Background', QoS Access Category 'A= C_BK').

No one in the room raised any concern with this text.=C2=A0 If you have a c= oncern, please speak on the list now.

S= uggest using SHOULD instead of MUST,
=C2=A0

In a another part of the meeting, J=C3=A9r=C3=B4me talked about Mapping IP = to Access Category in 802.11-OCB.=C2=A0 It was pointed out that RFC 8325 wa= s recently published on the standards track.=C2=A0 Tony Li pointed out that= there is no integrity protection for these bits.

=
I support Jerome's comment. Regarding=C2=A0protections, it= =C2=A0should be discussed in the last section of security, not in the draft= body, all RFCs do that.=C2=A0

As an individual, I wonder if it would be better to say something like:=C2= =A0 If DiffServ is being used, set the QoS Access Category as described in = RFC 8325, otherwise set the QoS Access Category of 'AC_BK'.

Yes that=C2=A0is correct, IMHO we need that in= this draft.

=C2=A0


AB=C2=A0=C2=A0

Russ

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

--001a113cc5b8aa0ebc0567f45e50-- From nobody Thu Mar 22 00:54: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 DA42A120454 for ; Thu, 22 Mar 2018 00:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UwcUIXY3kAxI for ; Thu, 22 Mar 2018 00:54:32 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E17111201F8 for ; Thu, 22 Mar 2018 00:54:31 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w2M7sCqC019715; Thu, 22 Mar 2018 08:54:12 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 21F2A2014BD; Thu, 22 Mar 2018 08:54:12 +0100 (CET) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 068A5200C44; Thu, 22 Mar 2018 08:54:12 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w2M7sBlY022182; Thu, 22 Mar 2018 08:54:11 +0100 To: dickroy@alum.mit.edu, "'Tony Li'" Cc: "'its'" , "=?UTF-8?Q?'Fran=c3=a7ois_Simon'?=" , =?UTF-8?B?J0rDqXLDtG1lIEjDpHJyaSc=?= , "'Tijink Jasja'" , "'Kevin Smith'" , "'Abdussalam Baryun'" References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <5cc6bd32-0812-288a-2db0-b0de53626f1e@gmail.com> <009c01d3c052$f0a78cc0$d1f6a640$@gmail.com> <007b01d3c0fe$15ad9540$4108bfc0$@eurecom.fr> <8daedb8d-8da1-aa02-33dd-ad81cf1a178e@gmail.com> <3331663254C7446187323740ABCC0390@SRA6> From: Alexandre Petrescu Message-ID: Date: Thu, 22 Mar 2018 08:54: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: <3331663254C7446187323740ABCC0390@SRA6> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] IPv6-over-OCB as a profile of 1609 WAVE X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 07:54:35 -0000 Dick, Le 22/03/2018 à 00:01, Dick Roy a écrit : > " Why would one think they would not work?" > > Simply because our expert (Thierry Ernst) suggested they might not and it > would be worth looking in to. That's why we asked the question. If you > "believe" they will work, fine. We will try them out (or not because WE > know they won't work). If that's the best response we can get from the I am not saying that is the best response. It is an _initial_ response from me as a participant to IETF, not representing IETF overaell. Technically speaking, I have many reasons to believe why many existing IETF protocols dont work in _some_ particular use-cases. We could discuss them, if you see it open minded. > IETF, please STOP doing anything with the ITS effort. The what that has > been produced is of NO value to the ITS community. You are wasting my time, > your time, and everyone else's time. "NO value" to the ITS community... The ITS community has no Internet-scale interoperable way at this time about networking the automobiles. There are very many closed settings, interoperating locally, but nothing to the scale of Internet. For my part, up to now, I benefitted from these many things: open source availability for many specific use-cases, detailed IPR status, the making of distinct ethertypes for IPv6-vs-others, the AC_* distinctions, and more. You may have not found benefit. Then please express what would have been beneficial to you. More detail than just dynamic network environments of vehicular networks. Do you think the IPv6 ND protocol must satisfy some requirements on dynamicity? > " I think IPv6-over-OCB is the right thing ISO TC204 should refer to, at > this time." > > You may think so, and you have every right to think it. It's simply NOT > GOING TO HAPPEN, PERIOD! It would be strange ISO TC204 talks about IPv6, about 802.11 (expired), and not about IPv6-over-802.11-OCB. > I have already stated so many reasons why your > philosophy is wrong from our perspective, however you refuse to believe it > and continue to try to tell us what to do WITHOUT HAVING READ any of our > documents/standards. No system designer is even going to read these RFCs. > They know what they want and they know how to deploy it. That's what will > happen in spite of all your best efforts to the contrary. I REPEAT, we did > not come to the IETF asking for you to do OUR jobs, we came asking for you > to do YOURS. Unfortunately, that is not was has happened and as a > consequence, to date, the IETF ITS effort has produced NOTHING of value for > the ITS community. If there is ANYONE on this thread that believes > otherwise, I am all ears. > > " I dont know why you say so. MTU 1500, QoSData AC_BK and Opaque IIDs are > highly likely to be implemented as we speak." > > Perhaps, however I can guarantee you it is NOT because the IETF mandated > it!!!!! Who mandated QoSData AC_BK for IP? (as opposed to Data for IP). > " MAC-based IIDs (as opposed to Opaque IIDs) are wrong for privacy. MTU > 2300 is not respected by the IP stack (it starts fragmenting at 1500 by > default)." > > None of this is relevant to what we wanted from the IETF. We can handle ALL > THIS without your help! This is NOTHING NEW! Yes, you can handle. But to obtain interoperability of Internet scale it's best to come to IETF. Alex > > > > > > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu > Sent: Wednesday, March 21, 2018 9:12 PM > To: dickroy@alum.mit.edu; 'Tony Li' > Cc: 'its'; 'François Simon'; 'Jérôme Härri'; 'Tijink Jasja'; 'Kevin Smith'; > 'Abdussalam Baryun' > Subject: Re: [ipwave] IPv6-over-OCB as a profile of 1609 WAVE > > > > Le 21/03/2018 à 19:33, Dick Roy a écrit : >> When Thierry and I (and a few others) first decided to approach the IETF >> years ago now, the goals were VERY SIMPLE.  Get the IETF to answer the >> following very simple question: >> >> Can the current IPv6 protocols handle rapidly varying network topologies >> (such as those in vehicular environments)? > > YEs, and we went through the questions many times during several BoFs. > > If you want a simple answer to that simple question, it is something > like this: use MANET, Babel, Mobile IP, optimistic DAD, fast RAs (RFCs > exist for each) - it should work. > > Why would one think they would not work? > >> If the answer were NO, then the question was: >> >> Would the IETF be willing to develop new protocols or modify already >> existing ones to handle the situation? >> >> And we were hoping the answer would be "yes"! >> >> NOTICE:  Nowhere did we mention ANYTHING about layers below the network >> layer and we sure as heck didn't mention 1609.anything!!!! >> >> Instead, we got this! > > I think IPv6-over-OCB is the right thing ISO TC204 should refer to, at > this time. > > For other things, we should ask ISO TC204 what kind of developments it sees. > > >>   Somehow, someway, the whole thing got WAY OFF >> TRACK.  It has now evolved into a useless and fruitless exercise of the >> IETF trying to tell implementers how to do their jobs.  This is a >> COMPLETE WASTE OF TIME.  They are not listening to any of your shalls or >> musts. > > I dont know why you say so. MTU 1500, QoSData AC_BK and Opaque IIDs are > highly likely to be implemented as we speak. > > MAC-based IIDs (as opposed to Opaque IIDs) are wrong for privacy. MTU > 2300 is not respected by the IP stack (it starts fragmenting at 1500 by > default). > > Alex > >> >> I am retiring from this discussion until such time as you are prepared >> to answer the question posed above.  Anything else is again a complete >> waste of everyone's time. >> >> RR >> >> ------------------------------------------------------------------------ >> >> *From:*its [mailto:its-bounces@ietf.org] *On Behalf Of *Tony Li >> *Sent:* Wednesday, March 21, 2018 2:43 PM >> *To:* Alexandre Petrescu >> *Cc:* its; François Simon; Jérôme Härri; Tijink Jasja; Kevin Smith; >> Abdussalam Baryun >> *Subject:* Re: [ipwave] IPv6-over-OCB as a profile of 1609 WAVE >> >> >> >> On Mar 21, 2018, at 12:18 PM, Alexandre Petrescu >> > > wrote: >> >> It is normal that draft-ietf-ipwave-ipv6-over-80211ocb-22 does not >> support WRA, because WRA is not an IP message. >> >> If one wants 1609.3-SLAAC to work with WRA (rather than RA) then there >> are a few questions IMHO (In My Humble Oppinion).  None of these impacts >> draft-ietf-ipwave-ipv6-over-80211ocb-22. >> >> - decide whether only the prefix, or other parts from RA too need to be >>  reflected in the WRA. (lifetimes, others, check RFC4862) >> - decide whether in IEEE 1609.3 the default route comes from the WRA as >>  well (not just the prefix).  If yes, decide whether the address of the >>  default router comes from the src address of the WRA or from an SLLAO >>  carried by the WRA. >> - decide whether you want a system to work correctly while only WRA is >>  present, both WRA and RA, or just RA. >> - decide whether the prefix length in the WRA must be precisely 64, or >>  can be of another length. >> - decide whether the Interface ID definition in this draft can be used >>  for the IEEE 1609.3-SLAAC.  I hope yes. >> - others. >> >> Our draft really should say something about WRA, one way or another. >> >> Lacking any compelling reason to use WRA, I would propose that we say >> that WRA should NOT be used. >> >> Tony >> > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > From nobody Thu Mar 22 02:59: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 18F46126C89 for ; Thu, 22 Mar 2018 02:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYi3CIVbsSEI for ; Thu, 22 Mar 2018 02:59:12 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c: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 41FC61205D3 for ; Thu, 22 Mar 2018 02:59:12 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id f19so14795249wmc.0 for ; Thu, 22 Mar 2018 02:59:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:reply-to:to:cc:date:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=CTJz0OR+nkg3X2OG/ZFwF4YgyrSRbMztmzl2YQnwTU4=; b=RuczQb4e73bHPco5joiUa2dcUbKvrXpeIQ1J+RTg2kL1BSBscU0EIowKkMrilL3qXE ZRbEuqLccPribVDQkZe3JPZJCHqwwKboDNkV2actUH0boaCCjh/57e6ntd4PVM8h6bZs +Yse3wox9yp3bLzXRJiQoRPHDX5f81XDTHKrY65I1t7upZws37WNFutrCLPWFHkijUlU m6IVUkO14cupLjlJMbXBq9HTgtNbQTK2FguAgoskvpGY20raIK3upyNyDpTKfx1KjCuo P9zW/Yv0YOb8kMWasA2kg1PaWqMe9WzkJhEIa/4ApG5019Jz46gKEZQohsb+3wDB3vtQ fqng== 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=CTJz0OR+nkg3X2OG/ZFwF4YgyrSRbMztmzl2YQnwTU4=; b=s982vOpNVmaBkaUF5hCtZpVq7BQzCydMS0g/7xxBtY+ySnV8N56ErM1SpoQ5oIZwKB SvJ48rtARzZtRjI4O2W9zEhTmC60ohEUv5Mi2xeh29OOixYkyySgJflfuH/Bar4Wj3bQ 5vKTpa/eNnliZPM/RPOY0GFWwI1IHzGPlpBKW1MobQQ3sW2J23iDi+E7B5sb7cXbE3bL VYLyEH89uVdXzZ5JnbMkfe8ioQ+LczIYNy2r9Pc1Tu2sx0t5MDxoLNPUPmGVRZHSi+j+ mK7pUBk6vWexPkM20kQ1z4Vi/JUxKs70RI4lEDQs5xWmR6WJS0azD8tujo6It6vSG3pM czFg== X-Gm-Message-State: AElRT7HwP7nGIZD8cmjIwAFxVpb8u88guqwhDRrhv8VOD0elFATYs709 N8PBIESc3DUmoU+MNP3GoKQgAQ== X-Google-Smtp-Source: AG47ELsXu24ty/MehwEZyHg4Hs1SRixP54wZBFW8RQrowtxtfZYWr9HnMCpRuVRn7MYTm47ftUZShA== X-Received: by 10.28.213.209 with SMTP id m200mr554857wmg.83.1521712750571; Thu, 22 Mar 2018 02:59:10 -0700 (PDT) Received: from acorde ([2001:67c:370:128:3383:f67d:1f33:6674]) by smtp.gmail.com with ESMTPSA id j6sm7982336wmg.14.2018.03.22.02.59.09 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 22 Mar 2018 02:59:09 -0700 (PDT) Message-ID: <1521712748.10488.72.camel@it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano Reply-To: cjbc@it.uc3m.es To: Alexandre Petrescu , dickroy@alum.mit.edu, 'Tijink Jasja' , =?ISO-8859-1?Q?=27J=E9r=F4me_H=E4rri=27?= , 'Abdussalam Baryun' , =?ISO-8859-1?Q?=27Fran=E7ois?= Simon' Cc: 'Kevin Smith' , 'its' Date: Thu, 22 Mar 2018 10:59:08 +0100 In-Reply-To: References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <5cc6bd32-0812-288a-2db0-b0de53626f1e@gmail.com> <009c01d3c052$f0a78cc0$d1f6a640$@gmail.com> <007b01d3c0fe$15ad9540$4108bfc0$@eurecom.fr> <809DC8CFA3564BC58531C82B2C576602@SRA6> <3ad8db38-cf22-2703-ab14-9bf05d2d5860@gmail.com> 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] =?iso-8859-1?q?=5Bipwave=EE=5D_IPv6-over-OCB_as_a_profi?= =?iso-8859-1?q?le_of_1609_WAVE?= X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 09:59:15 -0000 Hi, The charter of IPWAVE is clear: "This group's primary deliverable (and the only Standards track item) will be a document that will specify the mechanisms for transmission of IPv6 datagrams over IEEE 802.11-OCB mode." So questions about "IPv6 protocols handling rapidly varying network topologies (such as those in vehicular environments)" are out of the scope. Regarding the use of WRA, that is a mechanism defined outside IETF, it is not an IP protocol and, unless proved to solve a problem that current mechanisms defined by the IETF cannot cope with, I think the document in our charter should not consider. I can only echo here what Alex mentioned, 6man will not approve an IPv6-over-foo document relying on WRA. In relation to 1609, the charter says "Some aspects of the IPv6 over 802.11-OCB work have been already defined at IEEE 1609 and the specification produced by this working group is expected be compatible with these aspects". Our document is not a profile of IEEE 1609, it is expected that what the WG defines is compatible (though is not a mandate). IETF is the responsible of defining IPv6-over-foo. The decision of what technical solution to adopt has to be based on the limits of the charter and the rough consensus of the WG. And the consensus of the WG is on what Alex presented this Monday. Thanks, Carlos On Wed, 2018-03-21 at 21:27 +0100, Alexandre Petrescu wrote: > > Le 21/03/2018 à 18:52, Dick Roy a écrit : > [...] > > */[RR] So what? If I get a default route from divine > > intervention, > > and it is correct, who the heck cares? For the RFCs to say that > > something MUST be done in a particular way is simply bad standards > > writing when it does not involve interoperability. If I get valid > > information I need from some other means, that should be allowed, > > full stop! /* > > Dick - I invite you to join the 6man and v6ops WGs and state there > that > the default route might arrive correctly by other means than by RA. > You > will hit opposition from many people of large companies considering > themselves to somehow know better what is best for Internet. People > trust them. > > For my part, if you can persuade them, and consequently the IETF, > that > the default route can come by something else, I might have a draft > and > 'running code' ready proposing to do it with DHCPv6 rather than with > RA. > Two or three other groups of people proposed same. Still it cant > approach any measure of 'rough consensus' at IETF. > > I dont know why WRA to deliver the default route can get any more > acceptance than what was proposed with DHCPv6. > > Finally, the delivery of default route is not a matter that typical > IPv6-over-doo documents deal with. As such, no need to write about > it > in this draft. > > (I gave presentations several times during IETF BoFs and IETF telcos > about what a typical IPv6-over-foo document does, and the audiences > ranged between 10 to 100: nobody complained, which is rare at IETF; > the > presentations are available online). > > Alex > > > > > Other RFCs say that the only means to obtain a default route is > > from > > an > > > > RA (not from DHCP, not from something else like WRA). > > > > */[RR] Same as above!/* > > > > 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 Thu Mar 22 03:44: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 1193E127873 for ; Thu, 22 Mar 2018 03:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 bBEedFwORd8U for ; Thu, 22 Mar 2018 03:44:18 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D08CB12E8A5 for ; Thu, 22 Mar 2018 03:44:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id BCC39300A10 for ; Thu, 22 Mar 2018 06:44:14 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id uNDCkNvvuzvM for ; Thu, 22 Mar 2018 06:44:13 -0400 (EDT) Received: from dhcp-8e33.meeting.ietf.org (dhcp-8e33.meeting.ietf.org [31.133.142.51]) by mail.smeinc.net (Postfix) with ESMTPSA id 928B33002C6 for ; Thu, 22 Mar 2018 06:44:13 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Thu, 22 Mar 2018 06:44:13 -0400 To: its X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [ipwave] DRAFT IPWAVE Minutes X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 10:44:25 -0000 https://datatracker.ietf.org/meeting/101/materials/minutes-101-ipwave-00 Please send comments and corrections to the list. Russ From nobody Thu Mar 22 04:06: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 10B06120721 for ; Thu, 22 Mar 2018 04:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXqkeoCQpPDu for ; Thu, 22 Mar 2018 04:06:16 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE5B91200C1 for ; Thu, 22 Mar 2018 04:06:15 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w2MB5uGB088371; Thu, 22 Mar 2018 12:05:56 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 749AA203E64; Thu, 22 Mar 2018 12:05:56 +0100 (CET) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 5C0DA2026E0; Thu, 22 Mar 2018 12:05:56 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w2MB5uDn031084; Thu, 22 Mar 2018 12:05:56 +0100 To: dickroy@alum.mit.edu, "'Tijink Jasja'" , =?UTF-8?B?J0rDqXLDtG1lIEjDpHJyaSc=?= , "'Abdussalam Baryun'" , "=?UTF-8?Q?'Fran=c3=a7ois_Simon'?=" Cc: "'Kevin Smith'" , "'its'" References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <5cc6bd32-0812-288a-2db0-b0de53626f1e@gmail.com> <009c01d3c052$f0a78cc0$d1f6a640$@gmail.com> <007b01d3c0fe$15ad9540$4108bfc0$@eurecom.fr> <809DC8CFA3564BC58531C82B2C576602@SRA6> <3ad8db38-cf22-2703-ab14-9bf05d2d5860@gmail.com> <40710E47B2CA41BC830A9394B69FE19C@SRA6> From: Alexandre Petrescu Message-ID: <9ce2f821-5742-e806-d389-34ceadcf40f8@gmail.com> Date: Thu, 22 Mar 2018 12:05:56 +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: <40710E47B2CA41BC830A9394B69FE19C@SRA6> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] off-topic OCB-to-Ethernet bridging X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 11:06:18 -0000 Le 22/03/2018 à 08:48, Dick Roy a écrit : > For all you IETFer's who are experts in what you call EAL, and have been > itching to explain to all those layer 2 guys how it's really to be done, > here's your chance! Join the following ballot pool at the IEEE. I know, > it's not a "real" standards organization like the IETF, but what the heck! > It's all about helping out, right? > > ================================= > > You have new myProject notifications - please log onto > https://development.standards.ieee.org/my-site to read them. > > ----Message Boundary---- > > > To: undisclosed-recipients:; > Cc: "C/LM/WG802.1 Project Staff Liaison" > Subject: Sponsor Ballot Opening, P802.1AC-2016-Cor_1 > > > Dear IEEE P802.1AC-2016-Cor_1 Balloting Group Member: > > This e-mail is to advise you of the opening of the IEEE Standards Sponsor > Ballot for: > > P802.1AC-2016-Cor_1 > > Title: Standard for Local and Metropolitan Area Networks -- Media Access > Control (MAC) Service Definition - Corrigendum 1: Logical Link Control (LLC) > Encapsulation EtherType > > Scope: The scope of this standard is to define the Media Access Control > (MAC) Service provided by all IEEE 802(R) MACs, and the Internal Sublayer > Service (ISS) provided within MAC Bridges, in abstract terms of the > following: a) Their semantics, primitive actions, and events; and b) The > parameters of, interrelationship between, and valid sequences of these > actions and events. Maybe here is not the right place to ask because what follows is not an IP question: why is it not possible to bridge an 802.11 interface ran in OCB mode to an Ethernet interface on the same computer? (in linux the 'brctl' command fails when bridging OCB to Ethernet, I checked recently; in my recollection it worked when bridging WiFi to Ethernet, or WiFi to WiFi, or Ethernet to Ethernet). _If_ this bridging worked it would save a lot of computing cycles converting between the ASN.1 XER format of CAM-on-UDP-on-IP-on-Ethernet inside the car and the ASN.1 UPER format of CAM-on-BTP-on-GeoNetworking-on-802.11-OCB outside the car. With this bridging, it would be possible to just use UPER CAM-on-BTP-on-GeoNetworking both inside and outside the car. (this 'bridging' is something else than what EAL does). [...] > ***** ACCESS THE DOCUMENT, SUBMIT YOUR VOTE, AND SUBMIT YOUR COMMENTS ***** > > Go directly to: > > https://development.standards.ieee.org/my-site/ballot-activity > (Note: You may be prompted for your password if not already logged in). What is the password? Alex [...] From nobody Thu Mar 22 11:16: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 95F2C126D85 for ; Thu, 22 Mar 2018 11:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scNvVxQtN34x for ; Thu, 22 Mar 2018 11:16:52 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C5901242EA for ; Thu, 22 Mar 2018 11:16:52 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w2MIGobm061528; Thu, 22 Mar 2018 19:16:50 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 16449200C35; Thu, 22 Mar 2018 19:16:50 +0100 (CET) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id F3CD4200C26; Thu, 22 Mar 2018 19:16:49 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w2MIGnUj017802; Thu, 22 Mar 2018 19:16:49 +0100 To: Russ Housley References: Cc: its From: Alexandre Petrescu Message-ID: <602ddf32-57cb-ce33-6c8e-e992d740b571@gmail.com> Date: Thu, 22 Mar 2018 19:16: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] DRAFT IPWAVE Minutes X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 18:16:55 -0000 Le 22/03/2018 à 11:44, Russ Housley a écrit : > https://datatracker.ietf.org/meeting/101/materials/minutes-101-ipwave-00 > > Please send comments and corrections to the list. > > Comment: OCB support all identified use cases today. New IEEE 802.11 > PHY work for longer range, higher throughput – Study Group started. Comment to the comment: it is 802.11-NGV for Next Generation V2X. Alex From nobody Thu Mar 22 12:17: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 D3E0F126E01 for ; Thu, 22 Mar 2018 12:17:36 -0700 (PDT) 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 2JEM7Tjwm7D5 for ; Thu, 22 Mar 2018 12:17:32 -0700 (PDT) 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 BAB5C12708C for ; Thu, 22 Mar 2018 12:17:31 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id x205-v6so14847133lfa.0 for ; Thu, 22 Mar 2018 12:17:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=L9V+w90rBcUq7Z0R/O1PhIzW1Qdr9gPuBAZuOEovD0U=; b=nXIORlnF44Aemi6UxTNrq8y6N87aONhKaIa2yymdEB5HXy9fgJJHY99tGODCuAI5+y zJ4ac7tvVdaG/8lLW0M2Z8ULlpPxfKu9wxE348mqcn/e/OjU4zDxQosv2MXkQxQ0eXVj 7ODYGWm536OC+1VA5vcO1C0Rr0qvN+Q1iOlzfqeBGbED3Dze/mg21yr+7P8BqLfRiJFA KqEB8mMJURei4+iRlmLmQd26cyBzjbGgLdQixNXKJLuCjAlkkvyUUBLgYep/+Z2mEHng XW0tb9SHF4vqvhHRf2TCHX2RK/9t1OpUK5568P8wTa+D5pNXNLrDbRSl+EdGPHch2fZP 7K+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=L9V+w90rBcUq7Z0R/O1PhIzW1Qdr9gPuBAZuOEovD0U=; b=illvZzvd2EF8Wall593+tctNiCuMYR6KfAciX1fZIBMP56ih83ouIGfO8cwGbV37vP xNlM9kT1U+p1XN1eCoQWi/pq/Sm3CtkCVU64qvTNXhE2dvSNGYlYeChMXTnWCjiwdsZE WE9j7o6krnydx0S1IZ0PJkOG7zvm0K8S84+XE7PTQYta6VQEkmPl1a5nVRn6BZGME7Vc gP1QcMhHJhcaUAAl//n9RMiAKgiM7gN+YXNr2DBNbCFM//SOVbtxUxWE2lOaTE3D84gM BeUocODNscHNcSt5zdu50eDjnp8BLz7EyjwtCMz0zrj641QesROTflrZGY8/zQvDM0N9 WsnQ== X-Gm-Message-State: AElRT7H6dJhi97kAGZLm7EpytqedAEBRDY90tJeSMPrwnAJyVlqAQo79 q3b2Sps78VXwoWuoYlqnJ3qA+OW9cbeCyCdKN/M= X-Google-Smtp-Source: AG47ELvvBXiUVmaUENARkfontAweTD6g63EIhahV+SEEeamY3kgxXnpJuKFKX+kqhEnaaOMGpFCoXuiXTeCZ6cqxCf4= X-Received: by 10.46.25.83 with SMTP id p80mr16974323lje.142.1521746249901; Thu, 22 Mar 2018 12:17:29 -0700 (PDT) MIME-Version: 1.0 References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <5cc6bd32-0812-288a-2db0-b0de53626f1e@gmail.com> <009c01d3c052$f0a78cc0$d1f6a640$@gmail.com> <007b01d3c0fe$15ad9540$4108bfc0$@eurecom.fr> <809DC8CFA3564BC58531C82B2C576602@SRA6> <3ad8db38-cf22-2703-ab14-9bf05d2d5860@gmail.com> <1521712748.10488.72.camel@it.uc3m.es> In-Reply-To: <1521712748.10488.72.camel@it.uc3m.es> From: Nabil Benamar Date: Thu, 22 Mar 2018 19:17:18 +0000 Message-ID: To: =?UTF-8?Q?Carlos_Jes=C3=BAs_Bernardos_Cano?= Cc: Alexandre Petrescu , Richard Roy , Tijink Jasja , =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , Abdussalam Baryun , =?UTF-8?Q?Fran=C3=A7ois_Simon?= , Kevin Smith , its Content-Type: multipart/alternative; boundary="94eb2c1c0c0aa9ea6d0568052804" Archived-At: Subject: Re: [ipwave] =?utf-8?q?=5Bipwave=C3=AE=5D_IPv6-over-OCB_as_a_profile?= =?utf-8?q?_of_1609_WAVE?= X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 19:17:37 -0000 --94eb2c1c0c0aa9ea6d0568052804 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 Carlos Best regards Nabil On Thu, Mar 22, 2018, 09:59 Carlos Jes=C3=BAs Bernardos Cano wrote: > Hi, > > The charter of IPWAVE is clear: > > "This group's primary deliverable (and the only Standards track > item) will be a document that will specify the mechanisms for > transmission of IPv6 datagrams over IEEE 802.11-OCB mode." > > So questions about "IPv6 protocols handling rapidly varying network > topologies (such as those in vehicular environments)" are out of the > scope. > > Regarding the use of WRA, that is a mechanism defined outside IETF, it > is not an IP protocol and, unless proved to solve a problem that > current mechanisms defined by the IETF cannot cope with, I think the > document in our charter should not consider. I can only echo here what > Alex mentioned, 6man will not approve an IPv6-over-foo document relying > on WRA. > > In relation to 1609, the charter says "Some aspects of the IPv6 > over 802.11-OCB work have been already defined at IEEE 1609 and > the specification produced by this working group is expected be > compatible with these aspects". Our document is not a profile of IEEE > 1609, it is expected that what the WG defines is compatible (though is > not a mandate). IETF is the responsible of defining IPv6-over-foo. The > decision of what technical solution to adopt has to be based on the > limits of the charter and the rough consensus of the WG. And the > consensus of the WG is on what Alex presented this Monday. > > Thanks, > > Carlos > > On Wed, 2018-03-21 at 21:27 +0100, Alexandre Petrescu wrote: > > > > Le 21/03/2018 =C3=A0 18:52, Dick Roy a =C3=A9crit : > > [...] > > > */[RR] So what? If I get a default route from divine > > > intervention, > > > and it is correct, who the heck cares? For the RFCs to say that > > > something MUST be done in a particular way is simply bad standards > > > writing when it does not involve interoperability. If I get valid > > > information I need from some other means, that should be allowed, > > > full stop! /* > > > > Dick - I invite you to join the 6man and v6ops WGs and state there > > that > > the default route might arrive correctly by other means than by RA. > > You > > will hit opposition from many people of large companies considering > > themselves to somehow know better what is best for Internet. People > > trust them. > > > > For my part, if you can persuade them, and consequently the IETF, > > that > > the default route can come by something else, I might have a draft > > and > > 'running code' ready proposing to do it with DHCPv6 rather than with > > RA. > > Two or three other groups of people proposed same. Still it cant > > approach any measure of 'rough consensus' at IETF. > > > > I dont know why WRA to deliver the default route can get any more > > acceptance than what was proposed with DHCPv6. > > > > Finally, the delivery of default route is not a matter that typical > > IPv6-over-doo documents deal with. As such, no need to write about > > it > > in this draft. > > > > (I gave presentations several times during IETF BoFs and IETF telcos > > about what a typical IPv6-over-foo document does, and the audiences > > ranged between 10 to 100: nobody complained, which is rare at IETF; > > the > > presentations are available online). > > > > Alex > > > > > > > > Other RFCs say that the only means to obtain a default route is > > > from > > > an > > > > > > RA (not from DHCP, not from something else like WRA). > > > > > > */[RR] Same as above!/* > > > > > > 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 > --94eb2c1c0c0aa9ea6d0568052804 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 Carlos

= Best regards
Nabil

=C2=A0=C2=A0=C2=A0

On Thu, Mar 22, 2018, 09:59 Carlos Jes=C3= =BAs Bernardos Cano <cjbc@it.uc3m.es<= /a>> wrote:
Hi,

The charter of IPWAVE is clear:

"This group's primary deliverable (and the only Standards track item) will be a document that will specify the mechanisms for
transmission of IPv6 datagrams over IEEE 802.11-OCB mode."

So questions about "IPv6 protocols handling rapidly varying network topologies (such as those in vehicular environments)" are out of the scope.

Regarding the use of WRA, that is a mechanism defined outside IETF, it
is not an IP protocol and, unless proved to solve a problem that
current mechanisms defined by the IETF cannot cope with, I think the
document in our charter should not consider. I can only echo here what
Alex mentioned, 6man will not approve an IPv6-over-foo document relying
on WRA.

In relation to 1609, the charter says "Some aspects of the IPv6
over 802.11-OCB work have been already defined at IEEE 1609 and
the specification produced by this working group is expected be
compatible with these aspects". Our document is not a profile of IEEE<= br> 1609, it is expected that what the WG defines is compatible (though is
not a mandate). IETF is the responsible of defining IPv6-over-foo. The
decision of what technical solution to adopt has to be based on the
limits of the charter and the rough consensus of the WG. And the
consensus of the WG is on what Alex presented this Monday.

Thanks,

Carlos

On Wed, 2018-03-21 at 21:27 +0100, Alexandre Petrescu wrote:
>
> Le 21/03/2018 =C3=A0 18:52, Dick Roy a =C3=A9crit :
> [...]
> > */[RR] So what?=C2=A0 If I get a default route from divine
> > intervention,
> > and it is correct, who the heck cares? For the RFCs to say that > > something MUST be done in a particular way is simply bad standard= s
> > writing when it does not involve interoperability.=C2=A0 If I get= valid
> > information I need from some other means, that should be allowed,=
> > full stop! /*
>
> Dick - I invite you to join the 6man and v6ops WGs and state there
> that
> the default route might arrive correctly by other means than by RA. > You
> will hit opposition from many people of large companies considering > themselves to somehow know better what is best for Internet. People > trust them.
>
> For my part, if you can persuade them, and consequently the IETF,
> that
> the default route can come by something else, I might have a draft
> and
> 'running code' ready proposing to do it with DHCPv6 rather tha= n with
> RA.
>=C2=A0 =C2=A0Two or three other groups of people proposed same.=C2=A0 S= till it cant
> approach any measure of 'rough consensus' at IETF.
>
> I dont know why WRA to deliver the default route can get any more
> acceptance than what was proposed with DHCPv6.
>
> Finally, the delivery of default route is not a matter that typical > IPv6-over-doo documents deal with.=C2=A0 As such, no need to write abo= ut
> it
> in this draft.
>
> (I gave presentations several times during IETF BoFs and IETF telcos > about what a typical IPv6-over-foo document does, and the audiences > ranged between 10 to 100: nobody complained, which is rare at IETF; > the
> presentations are available online).
>
> Alex
>
> >
> > Other RFCs say that the only means to obtain a default route is > > from
> > an
> >
> > RA (not from DHCP, not from something else like WRA).
> >
> > */[RR] Same as above!/*
> >
> > Alex
> >
> > _______________________________________________
> >
> > its mailing list
> >
> > its@ietf.org
> >
> > https://www.ietf.org/mailman/listinfo/= its
> >
>
> _______________________________________________
> its mailing list
> i= ts@ietf.org
> https://www.ietf.org/mailman/listinfo/its

_______________________________________________
its mailing list
its@ie= tf.org
https://www.ietf.org/mailman/listinfo/its
--94eb2c1c0c0aa9ea6d0568052804-- From nobody Fri Mar 23 02:51: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 2A57412D7E6 for ; Fri, 23 Mar 2018 02:51:26 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_HK_NAME_FM_MR_MRS=0.01, 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 nTN06lm17kBy for ; Fri, 23 Mar 2018 02:51:24 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001: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 65BFF12D7E5 for ; Fri, 23 Mar 2018 02:51:24 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id b20so14457476iof.5 for ; Fri, 23 Mar 2018 02:51:24 -0700 (PDT) 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=YOXkyEiha0TmOQ5n3OIRcmxuB6i2gwom5ChC4panQ1s=; b=CQ/rJjM9k+wjyMtpnupjcx4TfcsoaB9wjmjsOMRtzNDmFnU2RYKB5S3tVQhZ6Nns13 lUv7HOj2YKSEp2m77F78ycpe8vxwKZ+BtOXJ9xtZ5MbJOIuf+5Bo8kgja8NHSCCotQOj 3nNZBrdFOih7p+XUwgFRVNA/8I6XYGblPksAcFbgg05I7+zSsMngLqApO46PuN4uCoeK NOo2SWK4HP4LtNdsCHm2IP9YXncTLYmb0EuL9KaDzi3lKRhoD+Ov/LDy27kTQoADyLpX DnsanGAP0noVAJFcIw5iiLMC+BZfoPLaWNsOQ3DzcOUEmsmLfu83gcL6YnaT5h1INhNX Rm4A== 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=YOXkyEiha0TmOQ5n3OIRcmxuB6i2gwom5ChC4panQ1s=; b=KC/XEQja9u3RTKukr5Ttwv63fd7WFp3nXuhBa865DXOIejBwooK38rKhB2uHkaJtg6 dn19o2igfF7tQWWFbVzVNsvRxVHl2Sutm4mJfbQ9LJ2uau54vuieZvSAO/bIKRRbtXfm D4pHfRXekazVNrZSziS6viFE+umIz1IwFzBVHmFURcgrahvzft+nUC5qZvVvAZ+A3ZhS yLaIaiIhUsNAhEh081QMoQJ4U0Tr5qgQaknrjZp+AKtV/zT+eTs1ZcJm+9BJVKBD49f9 eW2FVRdMnQKw9GdCpCE9YxJ/qAQv5bg52yp5bxKatd6jtfGwgTRad94aoQ3hxebWNoDZ dA+w== X-Gm-Message-State: AElRT7Gb56taCaYdB6AmtjD8ZLHWhkobPoQhUOfFAIlfBPdD9GD4OHG9 Xrk11cNSOvQdq+7iSiXDo/SyEldmMu8nRlSes3Eaeg== X-Google-Smtp-Source: AG47ELsRviKnLa6TFho2Djq+vE9VYE/42rsuauNNBdmYRqD/gRBq/9yxy9F8Z5XTzPfVmtVr9p/SPsRZUzo0KGaL0+Y= X-Received: by 10.107.182.67 with SMTP id g64mr30692762iof.58.1521798683357; Fri, 23 Mar 2018 02:51:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.147.194 with HTTP; Fri, 23 Mar 2018 02:50:52 -0700 (PDT) From: "Mr. Jaehoon Paul Jeong" Date: Fri, 23 Mar 2018 09:50:52 +0000 Message-ID: To: its@ietf.org Cc: Sri Gundavelli , "Mr. Jaehoon Paul Jeong" , skku_iotlab_seminar@googlegroups.com Content-Type: multipart/alternative; boundary="001a114aca02f1018c0568115df5" Archived-At: Subject: [ipwave] Restructuring of the Problem Statement Document X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 09:51:26 -0000 --001a114aca02f1018c0568115df5 Content-Type: text/plain; charset="UTF-8" Hi IPWAVEers, Here is a proposed restructuring of the Problem Statement Document: https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-02 Sri and I discussed the current structure of the document. We thought the current document is too big with unnecessary content (i.e., 52 pages). We think we should reduce it to around 10 pages with concise content with key problems for our IPWAVE WG. We come with the following structure with the revised title. ------------------------------------------------------------------------------------------------------------ Title: IP Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases Abstract 1. Introduction 2. Terminology //each item: at most 4 lines 3. Use Cases: V2V, V2I, V2X 4. Current Architectures and Protocols - General Problems: Latency, No security, No pseudonym handling, No IP support, ... 5. Problem Exploration - IPv6 over IEEE 802.11-OCB - Neighbor Discovery . Link Model . MAC Address Pseudonym . Prefix Dissemination/Exchange . Routing - Mobility Management . E2E Connectivity over V2I - Vehicle Identity Management - Multihop V2X - Service Discovery - Security and Privacy - Others 6. Security Considerations ------------------------------------------------------------------------------------------------------------ Please give us your comments on it. With the agreed content, we authors will move forward for the documentation. Thanks. Best Regards, Paul -- =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php --001a114aca02f1018c0568115df5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi IPWAVEers,
Here is a proposed restructuring of the = Problem Statement Document:

Sr= i and I discussed the current structure of the document.=C2=A0
We= thought the current document is too big with unnecessary content (i.e., 52= pages).
We think we should reduce it to around 10 pages with con= cise content with
key problems for our IPWAVE WG.
We come with the following structur= e with the revised title.

-----------------------------= ---------------------------------------------------------------------------= ----
Title: IP Wireless Access in Vehicular Environments (IP= WAVE): Problem Statement and Use Cases

= Abstract
1. Introduction
2. Terminology
=C2= =A0 =C2=A0//each item: at most 4 lines
3. Use Cases: V2V, V2I, V2= X
4. Current Architectures and Protocols
=C2=A0- Genera= l Problems: Latency, No security, No pseudonym handling, No IP support, ...= =C2=A0
5. Problem Exploration
=C2=A0- IPv6 over IEEE 80= 2.11-OCB
=C2=A0- Neighbor Discovery
=C2=A0 =C2=A0. Link= Model
=C2=A0 =C2=A0. MAC Address Pseudonym
=C2=A0 =C2= =A0. Prefix Dissemination/Exchange
=C2=A0 =C2=A0. Routing
=C2=A0- Mobility Management
=C2=A0 =C2=A0. E2E Connectivity ov= er V2I
=C2=A0- Vehicle Identity Management=C2=A0=C2=A0
= =C2=A0- Multihop V2X
=C2=A0- Service Discovery
=C2=A0- = Security and Privacy
=C2=A0- Others
=C2=A06. Security C= onsiderations
---------------------------------------------= ---------------------------------------------------------------
<= br>
Please give us your comments on it.

= With the agreed content, we authors will move forward for the documentation= .

Thanks.

Best Regards,
Paul
--
=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul= ) Jeong, Ph.D.
Assistant Professor
Department of Software
Sungkyun= kwan University
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com,=C2=A0pauljeong@skku.edu
Personal Homepage: http://iotlab.skku.edu/= people-jaehoon-jeong.php
--001a114aca02f1018c0568115df5-- From nobody Fri Mar 23 04:32: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 41D3612D7E5 for ; Fri, 23 Mar 2018 04:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 8LTDVu2Q7Wzo for ; Fri, 23 Mar 2018 04:32:50 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9F64120227 for ; Fri, 23 Mar 2018 04:32:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 601E1300A19 for ; Fri, 23 Mar 2018 07:32:48 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id WA1aqdaS9F9U for ; Fri, 23 Mar 2018 07:32:47 -0400 (EDT) Received: from dhcp-8e33.meeting.ietf.org (dhcp-8e33.meeting.ietf.org [31.133.142.51]) by mail.smeinc.net (Postfix) with ESMTPSA id 13582300433; Fri, 23 Mar 2018 07:32:46 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <602ddf32-57cb-ce33-6c8e-e992d740b571@gmail.com> Date: Fri, 23 Mar 2018 07:32:48 -0400 Cc: its Content-Transfer-Encoding: quoted-printable Message-Id: <5E9B370A-A7D3-4E50-B1AB-8303054BDF0B@vigilsec.com> References: <602ddf32-57cb-ce33-6c8e-e992d740b571@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [ipwave] DRAFT IPWAVE Minutes X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 11:32:52 -0000 > On Mar 22, 2018, at 2:16 PM, Alexandre Petrescu = wrote: >=20 > Le 22/03/2018 =C3=A0 11:44, Russ Housley a =C3=A9crit : >> = https://datatracker.ietf.org/meeting/101/materials/minutes-101-ipwave-00 >> Please send comments and corrections to the list. >=20 >> Comment: OCB support all identified use cases today. New IEEE 802.11 >> PHY work for longer range, higher throughput =E2=80=93 Study Group = started. >=20 > Comment to the comment: it is 802.11-NGV for Next Generation V2X. Thanks. I updated that paragraph to capture the information, Russ From nobody Fri Mar 23 13:20: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 87F2A12DA3E for ; Fri, 23 Mar 2018 13:20:57 -0700 (PDT) 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 McTrKQUtLqAm for ; Fri, 23 Mar 2018 13:20:55 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A31E12DA2C for ; Fri, 23 Mar 2018 13:20:55 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id e123-v6so9161700oih.13 for ; Fri, 23 Mar 2018 13:20:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=s+gJfQkcpU/1v9r+lNEdi/cffZ9fGV/SVsU1jXwFFzM=; b=JIpSIq6wq0BzhMfoRUeBtMLnDVO9a5PKqrf4zx80J9ggUpV27BH/UL0FMyrYIcC5Mb ZNzJMOgOj4d5sBew2evHkURt5sTbJ9/CAU5Sca7brz9b8eByxiUFopgcwHxHQuFANYxX Wk46XKzS6R9Gl+HwVIYdwjF70htES2wvSu1VsxVJBUejDTpyuoPnn3DMVHHvJHWf/RY1 AYdGC6h3ncFhfWK4hfsHv9wAm3VfZ1lsvtXGqNNRwTXvQPipEKEehItuyIhA3Q3JHZoC QvVLsNKFgGQT07TQwzIvp4onyYUJlzfTlkD4DI8V1a0FE/ClGc6B2RI3hguaiK/a9CAT TbYA== 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=s+gJfQkcpU/1v9r+lNEdi/cffZ9fGV/SVsU1jXwFFzM=; b=LDUlfy0OhKaZTz18Q7pYoiLxu9+23fg6IXHDZ9NNTJpFXhctjauMB6iorvDXE4EUzo nUhHdCYsAsewDY+41gfHRjxtXsBGYgXU8wm5nAkaSHxYGLsEMQGaaKDI3D7f4GWtiVSO /Zw3co32gCIlP49aZvDWKGYi5P7gyW9kYc513gLxL4FgpQkyfCPwIkppg6E4vNYybzch RVudFgnO48WX6T+K+ypn/4FU3kOaj7GXTyRHCHGKEv2apOIoYdjSK5kbURvqUegIk5ka rkgRQjrpkpYZtpikhQ45JMj8svfoxtbtM20D85W1eNthLgL6n+5vZcyy/InJpAr/mcEA 6jWQ== X-Gm-Message-State: AElRT7Fjdydc/rsV/ayAqdhATDJg4mUi51shz8aC2mgjb44QvqRE2fHR chp33MsoXAdlAzW5uCnTnQbE+9MGMi+Tt7nikOE= X-Google-Smtp-Source: AG47ELsb56EEDwRt+Nh6ylTfm3Vu+ns0LrKrNq5a3ffnBfD1IfY8dcnrzb2pzJ18gVgULTq9hWStI3eZK6nE1zcm4Zw= X-Received: by 10.202.212.146 with SMTP id l140mr9286501oig.325.1521836454491; Fri, 23 Mar 2018 13:20:54 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:1442:0:0:0:0:0 with HTTP; Fri, 23 Mar 2018 13:20:53 -0700 (PDT) In-Reply-To: References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <5cc6bd32-0812-288a-2db0-b0de53626f1e@gmail.com> <009c01d3c052$f0a78cc0$d1f6a640$@gmail.com> <007b01d3c0fe$15ad9540$4108bfc0$@eurecom.fr> <8daedb8d-8da1-aa02-33dd-ad81cf1a178e@gmail.com> From: Abdussalam Baryun Date: Fri, 23 Mar 2018 22:20:53 +0200 Message-ID: To: Richard Roy Cc: Alexandre Petrescu , its , Justin Dean Content-Type: multipart/alternative; boundary="001a113d2b3646bcb505681a29da" Archived-At: Subject: Re: [ipwave] IPv6-over-OCB as a profile of 1609 WAVE X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 20:20:57 -0000 --001a113d2b3646bcb505681a29da Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Mar 21, 2018 at 8:33 PM, Dick Roy wrote: > When Thierry and I (and a few others) first decided to approach the IETF > years ago now, the goals were VERY SIMPLE. Get the IETF to answer the > following very simple question: > > * Can the current IPv6 protocols handle rapidly varying network > topologies (such as those in vehicular environments)? If the answer wer= e > NO, then the question was:* > *Yes, check RFC6130, RFC5444, RFC5498, RFC7181, RFC7188, RFC7722,... etc.* * Would the IETF be willing to develop new protocols or modify already > existing ones to handle the situation? And we were hoping the answer > would be =E2=80=9Cyes=E2=80=9D! * > *Yes the MANET WG is doing such work and they developed OLSRv2 RFC7181 (you may interested to check RFC7722 for multi-topology) and if it is not good performance for your cases, then you may propose in that WG a new work/draft. The expert in IETF for ''IPv6 protocols handle rapidly varying network topologies'' is Chris Dearlove, please contact him or discuss. * * I hope you discuss also at IETF MANET WG, or contact WG Chair: Justin Dean and Stan Ratliff both I think are US participants like you. This message is CC to one WG chair.* *Check the MANET WG: **https://datatracker.ietf.org/wg/manet/about/ * * NOTICE: Nowhere did we mention ANYTHING about layers below the network > layer and we sure as heck didn=E2=80=99t mention 1609.anything!!!!* > In IETF MANET we are doing now DLEP RFC8175, which is protocol between the Mobile-PHY layer and Mobile-Routing layer, Yes we tell system designer what to do, and they do listen. You need to understand that in dynamic environment we need to have cross layering and any smart designer of any system for ITS he/she needs to look into many layers up and down, > * Instead, we got this! Somehow, someway, the whole thing got WAY OFF > TRACK. It has now evolved into a useless and fruitless exercise of the > IETF trying to tell implementers how to do their jobs. This is a COMPLET= E > WASTE OF TIME. They are not listening to any of your shalls or musts. * > we cannot separate layers in the mobile networks, each layers exchanges with others, so they need to work together. We do have cooperation with IEEE and other SDOs, so we all listen to each other and some ietf participants done efforts at other SDOs. > * I am retiring from this discussion until such time as you are prepared > to answer the question posed above. Anything else is again a complete > waste of everyone=E2=80=99s time.* > Please don't retire participating, I get that feeling but there are nice people in IETF. I suggest you discuss into MANET WG the email is manet@ietf.org, they will respond to you and to Mr.Thierry. Take care, AB CC: MANET WG Chair > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --001a113d2b3646bcb505681a29da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Mar 21, 2018 at 8:33 PM, Dick Roy <dickroy@alum.mit.edu= > wrote:

When Thierry and I (= and a few others) first decided to approach the IETF years ago now, the goals were VERY SIMPL= E.=C2=A0 Get the IETF to answer the following very simple question:=

<= span style=3D"color:navy;font-family:Arial;font-size:10pt">=C2=A0

<= span style=3D"color:navy;font-family:Arial;font-size:10pt">Can the curre= nt IPv6 protocols handle rapidly varying network topologies (such as those in vehicular environments= )?

<= span style=3D"color:navy;font-family:Arial;font-size:10pt">=C2=A0

<= span style=3D"color:navy;font-family:Arial;font-size:10pt">If the answer= were NO, then the question was:


=
Yes, check RFC6130, RFC5444, RFC5498, RFC7181, RFC7188, RFC77= 22,...=C2=A0etc.

<= span style=3D"color:navy;font-family:Arial;font-size:10pt">=C2=A0

<= span style=3D"color:navy;font-family:Arial;font-size:10pt">Would the IET= F be willing to develop new protocols or modify already existing ones to handle the situation?

<= span style=3D"color:navy;font-family:Arial;font-size:10pt">=C2=A0

<= span style=3D"color:navy;font-family:Arial;font-size:10pt">And we were h= oping the answer would be =E2=80=9Cyes=E2=80=9D!

<= span style=3D"color:navy;font-family:Arial;font-size:10pt">=C2=A0

<= span style=3D"color:navy;font-family:Arial;font-size:10pt">



Yes the MANET WG is doin= g such work and they developed OLSRv2 RFC7181 (you may interested to check = RFC7722 for multi-topology) and if it is not good performance for your case= s, then=C2=A0you may propose in that WG a new work/draft. The expert in IET= F for ''IPv6 protocols handle rapidly v= arying network topologies'' is Chris Dearlove, please contact him o= r discuss.=C2=A0

<= /u>
=C2=A0I hope you discuss also at IETF MANET WG, = or contact WG=C2=A0Chair: Justin Dean and Stan Ratliff=C2=A0 both I think a= re US participants like you. This message is CC to one WG chair.


<= /u>

=C2=A0

<= p class=3D"MsoNormal">NOTICE:=C2=A0 Nowhere= did we mention ANYTHING about layers below the network layer and we sure a= s heck didn=E2=80=99t mention 1609.anything!!!!


= In IETF MANET we are doing now DLEP RFC8175, which is=C2=A0protocol between= the=C2=A0Mobile-PHY layer and Mobile-Routing layer, Yes we tell system des= igner what to do, and they do listen. You need to understand that in dynami= c environment we need to have cross layering and any smart designer of any = system for ITS=C2=A0he/she needs to look into=C2=A0many layers up and down,=

=C2=A0

=C2=A0

Instead, we got this!=C2=A0 Somehow, someway, the whole thing got WA= Y OFF TRACK.=C2=A0 It has now evolved into a useless and fruitless exercise= of the IETF trying to tell implementers how to do their jobs.=C2=A0 This i= s a COMPLETE WASTE OF TIME.=C2=A0 They are not listening to any of your sha= lls or musts. =C2=A0

<= /u>

we cannot separate layers in the mobile networks, each layers exch= anges with others, so they need to work together. We do have cooperation wi= th IEEE and other SDOs, so we all listen to each other and some ietf partic= ipants done efforts at other SDOs.
=C2=A0
=

<= u>=C2=A0

I am retiring from this discussion un= til such time as you are prepared to answer the question posed above.=C2=A0= Anything else is again a complete waste of everyone=E2=80=99s time.=

=

Pl= ease don't retire participating, I get that feeling but there are nice = people in IETF. I suggest you discuss into MANET WG the email is manet@ietf.org, they will respond to you and to= Mr.Thierry.

Take = care,

AB


C= C: MANET WG Chair
=C2=A0





=







=



<= /u>







<= br>


















=

--001a113d2b3646bcb505681a29da-- From nobody Fri Mar 23 13:24: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 7E4D8127023 for ; Fri, 23 Mar 2018 13:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TidQ4H31GfMk for ; Fri, 23 Mar 2018 13:24:30 -0700 (PDT) Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::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 E3EDF126DCA for ; Fri, 23 Mar 2018 13:24:29 -0700 (PDT) Received: by mail-ot0-x234.google.com with SMTP id r30-v6so14605761otr.2 for ; Fri, 23 Mar 2018 13:24:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nWMR2coKtGJ0h26d+x/xL3C49gFZf3bsWhENtDO0Zbo=; b=lW3I9fzy5L4Qy/vBsYNIrW0pG1adz5+jjxXUO2un5ugbCe4qFKwtRlqup/A0t8Ck+F ASiMbe4noAWkTBfqfoJogBhOo51ZRHGP0pVDaBppsycgP30/VhOxTl9EpxJteMSYbpht YGWmNRpVywBVx0UcXkpDREv6tUqGqXgNWGBGtOHXr8a+RU9kq/SDzNMhUw3D/FJpd58O 6yvOEmNjkdR05rVZTiix9E2gfQoNMfVHk9Ou5RVWEdIUsyx7rH9Ql0VJ/amxUzIZznwm SSWGXJlkpRXRTIFTBY2TVDx+23tAGV5/FuVIhjJIESxtgTUVpiLwjgxh+cDwRhsIna1B 4D9A== 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=nWMR2coKtGJ0h26d+x/xL3C49gFZf3bsWhENtDO0Zbo=; b=CKLtFNPgLe7u73RpgYbI4gm2pC2uxaErOBB9+dlLiAFzzA3trWfG5K9eIl+xIEPqcM G/G0RJmHVUHbLadPrlOba7TPD5/B3QLjXbyZMToFg/y3PLoyUpMHqx1KbeMe3ftD9LBq uXAWGAkqNPGby3qlzCJhuAdLarhjYNpvs5VpekKk+rqZm1BbUgkVRhbCNWQ7g6ee8/tG XQxb+YHh6WuoIZgUmD5I3ql8SCoQfLAt9QxG8Z6GarvU90toQ/nyOXCXB1/lDAUgZ117 HEJI5RNVj5FRv9T7Cgc0+d8vecpYvFAQC1/h4upa6Qmndi9wSGo8HY3VubeTXmpu67Rz 827g== X-Gm-Message-State: AElRT7G5FCdJYtrMw6PgTrGbM5DBPSCVd/UUKrcUEHO1v8NmqdPXqmPx 0K9qZsVNzADN63vygaiT1JV8q8qKOy9mJgLZxk4= X-Google-Smtp-Source: AG47ELuJo/r6h0xDa+VHVDuzGL+e5AAcJ7aDiemX5T8rbduJR3eAEPl2v+AEwD0H1jtAh9IvzaeX5gz4kthfM3WgTqI= X-Received: by 2002:a9d:419a:: with SMTP id p26-v6mr13469226ote.350.1521836669276; Fri, 23 Mar 2018 13:24:29 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:1442:0:0:0:0:0 with HTTP; Fri, 23 Mar 2018 13:24:28 -0700 (PDT) In-Reply-To: References: <029701d3bd4d$0aa47d80$1fed7880$@cox.net> <5cc6bd32-0812-288a-2db0-b0de53626f1e@gmail.com> <009c01d3c052$f0a78cc0$d1f6a640$@gmail.com> <007b01d3c0fe$15ad9540$4108bfc0$@eurecom.fr> <809DC8CFA3564BC58531C82B2C576602@SRA6> <3ad8db38-cf22-2703-ab14-9bf05d2d5860@gmail.com> <1521712748.10488.72.camel@it.uc3m.es> From: Abdussalam Baryun Date: Fri, 23 Mar 2018 22:24:28 +0200 Message-ID: To: Nabil Benamar Cc: =?UTF-8?Q?Carlos_Jes=C3=BAs_Bernardos_Cano?= , Alexandre Petrescu , Richard Roy , Tijink Jasja , =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , =?UTF-8?Q?Fran=C3=A7ois_Simon?= , Kevin Smith , its Content-Type: multipart/alternative; boundary="0000000000001418cd05681a360d" Archived-At: Subject: Re: [ipwave] =?utf-8?q?=5Bipwave=C3=AE=5D_IPv6-over-OCB_as_a_profile?= =?utf-8?q?_of_1609_WAVE?= X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 20:24:33 -0000 --0000000000001418cd05681a360d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 AB On Thu, Mar 22, 2018 at 9:17 PM, Nabil Benamar wrote: > +1 Carlos > > Best regards > Nabil > > > > On Thu, Mar 22, 2018, 09:59 Carlos Jes=C3=BAs Bernardos Cano > wrote: > >> Hi, >> >> The charter of IPWAVE is clear: >> >> "This group's primary deliverable (and the only Standards track >> item) will be a document that will specify the mechanisms for >> transmission of IPv6 datagrams over IEEE 802.11-OCB mode." >> >> So questions about "IPv6 protocols handling rapidly varying network >> topologies (such as those in vehicular environments)" are out of the >> scope. >> >> Regarding the use of WRA, that is a mechanism defined outside IETF, it >> is not an IP protocol and, unless proved to solve a problem that >> current mechanisms defined by the IETF cannot cope with, I think the >> document in our charter should not consider. I can only echo here what >> Alex mentioned, 6man will not approve an IPv6-over-foo document relying >> on WRA. >> >> In relation to 1609, the charter says "Some aspects of the IPv6 >> over 802.11-OCB work have been already defined at IEEE 1609 and >> the specification produced by this working group is expected be >> compatible with these aspects". Our document is not a profile of IEEE >> 1609, it is expected that what the WG defines is compatible (though is >> not a mandate). IETF is the responsible of defining IPv6-over-foo. The >> decision of what technical solution to adopt has to be based on the >> limits of the charter and the rough consensus of the WG. And the >> consensus of the WG is on what Alex presented this Monday. >> >> Thanks, >> >> Carlos >> >> On Wed, 2018-03-21 at 21:27 +0100, Alexandre Petrescu wrote: >> > >> > Le 21/03/2018 =C3=A0 18:52, Dick Roy a =C3=A9crit : >> > [...] >> > > */[RR] So what? If I get a default route from divine >> > > intervention, >> > > and it is correct, who the heck cares? For the RFCs to say that >> > > something MUST be done in a particular way is simply bad standards >> > > writing when it does not involve interoperability. If I get valid >> > > information I need from some other means, that should be allowed, >> > > full stop! /* >> > >> > Dick - I invite you to join the 6man and v6ops WGs and state there >> > that >> > the default route might arrive correctly by other means than by RA. >> > You >> > will hit opposition from many people of large companies considering >> > themselves to somehow know better what is best for Internet. People >> > trust them. >> > >> > For my part, if you can persuade them, and consequently the IETF, >> > that >> > the default route can come by something else, I might have a draft >> > and >> > 'running code' ready proposing to do it with DHCPv6 rather than with >> > RA. >> > Two or three other groups of people proposed same. Still it cant >> > approach any measure of 'rough consensus' at IETF. >> > >> > I dont know why WRA to deliver the default route can get any more >> > acceptance than what was proposed with DHCPv6. >> > >> > Finally, the delivery of default route is not a matter that typical >> > IPv6-over-doo documents deal with. As such, no need to write about >> > it >> > in this draft. >> > >> > (I gave presentations several times during IETF BoFs and IETF telcos >> > about what a typical IPv6-over-foo document does, and the audiences >> > ranged between 10 to 100: nobody complained, which is rare at IETF; >> > the >> > presentations are available online). >> > >> > Alex >> > >> > > >> > > Other RFCs say that the only means to obtain a default route is >> > > from >> > > an >> > > >> > > RA (not from DHCP, not from something else like WRA). >> > > >> > > */[RR] Same as above!/* >> > > >> > > 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 >> > --0000000000001418cd05681a360d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1

AB

On Thu, Mar 22, 2018 at 9:1= 7 PM, Nabil Benamar <benamar73@gmail.com> wrote:
+1 Carlos

Best regards
Nabil

=C2=A0=C2=A0=C2=A0

On Thu, Mar 22, 2018, 09:59 Carlos Jes=C3=BAs Bernardos Cano <<= a href=3D"mailto:cjbc@it.uc3m.es" target=3D"_blank">cjbc@it.uc3m.es>= wrote:
Hi,

The charter of IPWAVE is clear:

"This group's primary deliverable (and the only Standards track item) will be a document that will specify the mechanisms for
transmission of IPv6 datagrams over IEEE 802.11-OCB mode."

So questions about "IPv6 protocols handling rapidly varying network topologies (such as those in vehicular environments)" are out of the scope.

Regarding the use of WRA, that is a mechanism defined outside IETF, it
is not an IP protocol and, unless proved to solve a problem that
current mechanisms defined by the IETF cannot cope with, I think the
document in our charter should not consider. I can only echo here what
Alex mentioned, 6man will not approve an IPv6-over-foo document relying
on WRA.

In relation to 1609, the charter says "Some aspects of the IPv6
over 802.11-OCB work have been already defined at IEEE 1609 and
the specification produced by this working group is expected be
compatible with these aspects". Our document is not a profile of IEEE<= br> 1609, it is expected that what the WG defines is compatible (though is
not a mandate). IETF is the responsible of defining IPv6-over-foo. The
decision of what technical solution to adopt has to be based on the
limits of the charter and the rough consensus of the WG. And the
consensus of the WG is on what Alex presented this Monday.

Thanks,

Carlos

On Wed, 2018-03-21 at 21:27 +0100, Alexandre Petrescu wrote:
>
> Le 21/03/2018 =C3=A0 18:52, Dick Roy a =C3=A9crit :
> [...]
> > */[RR] So what?=C2=A0 If I get a default route from divine
> > intervention,
> > and it is correct, who the heck cares? For the RFCs to say that > > something MUST be done in a particular way is simply bad standard= s
> > writing when it does not involve interoperability.=C2=A0 If I get= valid
> > information I need from some other means, that should be allowed,=
> > full stop! /*
>
> Dick - I invite you to join the 6man and v6ops WGs and state there
> that
> the default route might arrive correctly by other means than by RA. > You
> will hit opposition from many people of large companies considering > themselves to somehow know better what is best for Internet. People > trust them.
>
> For my part, if you can persuade them, and consequently the IETF,
> that
> the default route can come by something else, I might have a draft
> and
> 'running code' ready proposing to do it with DHCPv6 rather tha= n with
> RA.
>=C2=A0 =C2=A0Two or three other groups of people proposed same.=C2=A0 S= till it cant
> approach any measure of 'rough consensus' at IETF.
>
> I dont know why WRA to deliver the default route can get any more
> acceptance than what was proposed with DHCPv6.
>
> Finally, the delivery of default route is not a matter that typical > IPv6-over-doo documents deal with.=C2=A0 As such, no need to write abo= ut
> it
> in this draft.
>
> (I gave presentations several times during IETF BoFs and IETF telcos > about what a typical IPv6-over-foo document does, and the audiences > ranged between 10 to 100: nobody complained, which is rare at IETF; > the
> presentations are available online).
>
> Alex
>
> >
> > Other RFCs say that the only means to obtain a default route is > > from
> > an
> >
> > RA (not from DHCP, not from something else like WRA).
> >
> > */[RR] Same as above!/*
> >
> > Alex
> >
> > _______________________________________________
> >
> > its mailing list
> >
> > its@ietf.org
> >
> > https://www.ietf.org/mailman/list= info/its
> >
>
> _______________________________________________
> its mailing list
> i= ts@ietf.org
> https://www.ietf.org/mailman/listinfo/= its

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

--0000000000001418cd05681a360d-- From nobody Fri Mar 23 13:55: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 47E2912DA3D for ; Fri, 23 Mar 2018 13:55:26 -0700 (PDT) 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 qYFhaUc8vwpz for ; Fri, 23 Mar 2018 13:55:24 -0700 (PDT) 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 B53C9126DFF for ; Fri, 23 Mar 2018 13:55:24 -0700 (PDT) Received: by mail-ot0-x236.google.com with SMTP id 108-v6so14686934otv.3 for ; Fri, 23 Mar 2018 13:55:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=k8gBGOtLXsQk9L2WPX34Rgkh/8hNHEpyGmjGmu1uHlE=; b=u7QnGAyx1CnvXtw/uP1LI7tlIlW5LJwLWAckTlomb0KKSPfOno6DIBtbfA2b/sKbl9 XY1xaah8GkZXuWAwBg3S14L0q5bXozah0jCQb31hTwBABFhDt+h9o8hMJ2ButdraKqDP 0NhDVh8vPJgdZ1QBoWim1D6YCqqZyXhAOyJR7fz2h78kd4kaTO2H8t8VkxP7qYvZETah PgFHuDwhOlhU7ULkfT/eogJ8mtvs96YAe9AisVbNLOnuHIhPRI4s7ySmqz4R0eFmlt/2 reVkaVOj7iXDPQKpEDq618SPsALRW9bqIkMreLNzYnE48XZKymFZ3OSD6jMfve3cRmpp N8EQ== 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=k8gBGOtLXsQk9L2WPX34Rgkh/8hNHEpyGmjGmu1uHlE=; b=kYoQMc9onNZMAoyBihkQaMF/n5Rk0WujlgkSaaODqPZRqlmMUhsYzKDcWw2k798Xys n1Y7w2phkJvroSv8fcOHkjKu0kKPLywp6ypX4+2pUYjCNB7CGjjmNu7ixU4IoxuKEe7F J9hKA14mLZwf/qHBik2I6GWbPUSzaeVHXrRkN+ecPEqFh+rvqkelzW6rKp6mbfyua/LN mssubvrFhpRyctw0MNO/VXyzgXxh/wfthUHXGfEZFQlZfT09hbTn5/ADut8chaPCn/yA iI57f0ak8mSbN4UmoWy+tAouAcw/WKxyX11VB7Lp+w5tIJvGfP6l+g49bksNDCt5JJlj CgnA== X-Gm-Message-State: AElRT7HQTt27lVLblz7VHB6+VenmVS4IOFHi4m9m1XKB2Cbz3jl/AjyV CXkLcs84kUB0+X+PlCWsf3wMbWvEGVYxIw51V3U= X-Google-Smtp-Source: AG47ELsbQ/RzkUyTtKr6QPw5lWyWvDmZRq8SkwzCFAQc9TLLmFcxOj5AgxzVyYHKStmIlsJXVT+IRpq9bIKc5h6uRcs= X-Received: by 2002:a9d:419a:: with SMTP id p26-v6mr13518250ote.350.1521838524105; Fri, 23 Mar 2018 13:55:24 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:1442:0:0:0:0:0 with HTTP; Fri, 23 Mar 2018 13:55:23 -0700 (PDT) In-Reply-To: References: From: Abdussalam Baryun Date: Fri, 23 Mar 2018 22:55:23 +0200 Message-ID: To: "Mr. Jaehoon Paul Jeong" Cc: its , skku_iotlab_seminar@googlegroups.com, Sri Gundavelli Content-Type: multipart/alternative; boundary="000000000000a2876d05681aa4dd" Archived-At: Subject: Re: [ipwave] Restructuring of the Problem Statement Document X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 20:55:26 -0000 --000000000000a2876d05681aa4dd Content-Type: text/plain; charset="UTF-8" On Fri, Mar 23, 2018 at 11:50 AM, Mr. Jaehoon Paul Jeong < jaehoon.paul@gmail.com> wrote: > Hi IPWAVEers, > Here is a proposed restructuring of the Problem Statement Document: > https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-02 > > Sri and I discussed the current structure of the document. > We thought the current document is too big with unnecessary content (i.e., > 52 pages). > We think we should reduce it to around 10 pages with concise content with > even if it gets to 20p it can be ok, > key problems for our IPWAVE WG. > We come with the following structure with the revised title. > > ------------------------------------------------------------ > ------------------------------------------------ > Title: IP Wireless Access in Vehicular Environments (IPWAVE): Problem > Statement and Use Cases > I prefer we start with use cases then problems, so title: Title: IP Wireless Access in Vehicular Environments (IPWAVE): Use Cases and Problem Statements > > Abstract > 1. Introduction > 2. Terminology > //each item: at most 4 lines > 3. Use Cases: V2V, V2I, V2X > 4. Current Architectures and Protocols > - General Problems: Latency, No security, No pseudonym handling, No IP > support, ... > why architecture in this draft, I suggest take this out, it is better in another draft, just focus on the aim an objectives of the draft, the architecture needs another draft so if we update in future we just update architecture or update use cases, > 5. Problem Exploration > - IPv6 over IEEE 802.11-OCB > - Neighbor Discovery > . Link Model > . MAC Address Pseudonym > . Prefix Dissemination/Exchange > . Routing > - Mobility Management > . E2E Connectivity over V2I > - Vehicle Identity Management > - Multihop V2X > - Service Discovery > - Security and Privacy > - Others > please make them as problem statements sections so 5.1, 5.2, ..... also they need to cover our available charter only, > 6. Security Considerations > ------------------------------------------------------------ > ------------------------------------------------ > > Please give us your comments on it. > > With the agreed content, we authors will move forward for the > documentation.. > > thanks AB > Thanks. > > Best Regards, > Paul > -- > =========================== > Mr. Jaehoon (Paul) Jeong, Ph.D. > Assistant Professor > Department of Software > Sungkyunkwan University > Office: +82-31-299-4957 <+82%2031-299-4957> > Email: jaehoon.paul@gmail.com, pauljeong@skku.edu > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > --000000000000a2876d05681aa4dd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Mar 23, 2018 at 11:50 AM, Mr. Jaehoon Paul Jeong <jaehoon= .paul@gmail.com> wrote:
= Hi IPWAVEers,
Here is a proposed restructuring of the Problem Statement= Document:

Sri and I discussed the current structure of the document.=C2=A0
We thought the current document is too big with unnecessary conten= t (i.e., 52 pages).
We think we should reduce it to around 10 pag= es with concise content with

ev= en if it gets to 20p it can be ok,
=C2=A0
=
key problems for our IPWAVE WG.
We come with the = following structure with the revised title.

-----------= -----------------------------------------------------------------= --------------------------------
Title: IP Wireless Acc= ess in Vehicular Environments (IPWAVE): Problem Statement and Use Cases

I prefer we start with use c= ases then problems, so title:

=C2=A0Title: IP Wire= less Access in Vehicular Environments (IPWAVE): Use Cases and Problem State= ments
=C2=A0

Abstract
1. In= troduction
2. Terminology
=C2=A0 =C2=A0//each item: at = most 4 lines
3. Use Cases: V2V, V2I, V2X
4. Current Arc= hitectures and Protocols
=C2=A0- General Problems: Latency, No se= curity, No pseudonym handling, No IP support, ...=C2=A0

why architecture in this draft, I suggest ta= ke this out, it is better in another draft, just focus on the aim an object= ives of the draft, the architecture needs another draft so if we update in = future we just update architecture or update use cases,

=C2=A0
5. Problem Ex= ploration
=C2=A0- IPv6 over IEEE 802.11-OCB
=C2=A0- Nei= ghbor Discovery
=C2=A0 =C2=A0. Link Model
=C2=A0 =C2=A0= . MAC Address Pseudonym
=C2=A0 =C2=A0. Prefix Dissemination/Excha= nge
=C2=A0 =C2=A0. Routing
=C2=A0- Mobility Management<= /div>
=C2=A0 =C2=A0. E2E Connectivity over V2I
=C2=A0- Vehicl= e Identity Management=C2=A0=C2=A0
=C2=A0- Multihop V2X
= =C2=A0- Service Discovery
=C2=A0- Security and Privacy
= =C2=A0- Others

please mak= e them as problem statements sections so 5.1, 5.2, .....
also the= y need to cover our available charter only,
=C2=A0
=C2=A06. Security Considerations
------------------------------------------------------------<= wbr>------------------------------------------------

Please give us your comments on it.

With t= he agreed content, we authors will move forward for the documentation..


thanks
AB

=C2=A0
Thanks.

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

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


--000000000000a2876d05681aa4dd-- From nobody Fri Mar 23 17:23: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 5CBCC12E048 for ; Fri, 23 Mar 2018 17:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 LSe2jMu4UhXG for ; Fri, 23 Mar 2018 17:23:14 -0700 (PDT) Received: from mail.cec.uchile.cl (mail1.cec.uchile.cl [200.9.100.12]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D2481270AB for ; Fri, 23 Mar 2018 17:23:12 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.cec.uchile.cl (Postfix) with ESMTP id 3B864347326 for ; Fri, 23 Mar 2018 21:23:09 -0300 (-03) X-Virus-Scanned: by amavisd-new at ing.uchile.cl Received: from mail.cec.uchile.cl ([127.0.0.1]) by localhost (mail1.cec.uchile.cl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uD3SAb6wKi5L for ; Fri, 23 Mar 2018 21:23:08 -0300 (-03) Received: from [192.168.1.7] (host-92-24-106-61.ppp.as43234.net [92.24.106.61]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.cec.uchile.cl (Postfix) with ESMTP id 2E7A3347316 for ; Fri, 23 Mar 2018 21:23:06 -0300 (-03) To: its@ietf.org References: From: =?UTF-8?Q?Sandra_C=c3=a9spedes?= Message-ID: Date: Fri, 23 Mar 2018 21:23:08 -0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:59.0) Gecko/20100101 Thunderbird/59.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------BF327A255E8D2D8A7142EEC3" Content-Language: en-US X-Antivirus: Avast (VPS 180323-4, 23-03-2018), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: Re: [ipwave] Restructuring of the Problem Statement Document X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 00:23:17 -0000 This is a multi-part message in MIME format. --------------BF327A255E8D2D8A7142EEC3 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 3/23/2018 5:55 PM, Abdussalam Baryun wrote: > > > On Fri, Mar 23, 2018 at 11:50 AM, Mr. Jaehoon Paul Jeong > > wrote: > > Hi IPWAVEers, > Here is a proposed restructuring of the Problem Statement Document: > https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-02 > > > Sri and I discussed the current structure of the document. > We thought the current document is too big with unnecessary > content (i.e., 52 pages). > We think we should reduce it to around 10 pages with concise > content with > > > even if it gets to 20p it can be ok, > > key problems for our IPWAVE WG. > We come with the following structure with the revised title. > > ------------------------------------------------------------------------------------------------------------ > Title: IP Wireless Access in Vehicular Environments (IPWAVE): > Problem Statement and Use Cases > > > I prefer we start with use cases then problems, so title: > >  Title: IP Wireless Access in Vehicular Environments (IPWAVE): Use > Cases and Problem Statements > > > Abstract > 1. Introduction > 2. Terminology >    //each item: at most 4 lines > 3. Use Cases: V2V, V2I, V2X > 4. Current Architectures and Protocols >  - General Problems: Latency, No security, No pseudonym handling, > No IP support, ... > > > why architecture in this draft, I suggest take this out, it is better > in another draft, just focus on the aim an objectives of the draft, > the architecture needs another draft so if we update in future we just > update architecture or update use cases, > > 5. Problem Exploration >  - IPv6 over IEEE 802.11-OCB >  - Neighbor Discovery >    . Link Model >    .. MAC Address Pseudonym >    . Prefix Dissemination/Exchange >    . Routing >  - Mobility Management >    . E2E Connectivity over V2I >  - Vehicle Identity Management >  - Multihop V2X >  - Service Discovery >  - Security and Privacy >  - Others > > > please make them as problem statements sections so 5.1, 5.2, ..... > also they need to cover our available charter only, During the meeting in London the suggestion was to consider not only the current charter but also other aspects/problems of interest/future scope for this group. > >  6. Security Considerations > ------------------------------------------------------------------------------------------------------------ > > Please give us your comments on it. > > With the agreed content, we authors will move forward for the > documentation.. > > > thanks > > AB > > Thanks. > > Best Regards, > Paul > -- > =========================== > Mr. Jaehoon (Paul) Jeong, Ph.D. > Assistant Professor > Department of Software > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.paul@gmail.com , > pauljeong@skku.edu > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its --- El software de antivirus Avast ha analizado este correo electrónico en busca de virus. https://www.avast.com/antivirus --------------BF327A255E8D2D8A7142EEC3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

 
On 3/23/2018 5:55 PM, Abdussalam Baryun wrote:


On Fri, Mar 23, 2018 at 11:50 AM, Mr. Jaehoon Paul Jeong <jaehoon..paul@gmail.com> wrote:
Hi IPWAVEers,
Here is a proposed restructuring of the Problem Statement Document:

Sri and I discussed the current structure of the document. 
We thought the current document is too big with unnecessary content (i.e., 52 pages).
We think we should reduce it to around 10 pages with concise content with

even if it gets to 20p it can be ok,
 
key problems for our IPWAVE WG.
We come with the following structure with the revised title.

------------------------------------------------------------------------------------------------------------
Title: IP Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases

I prefer we start with use cases then problems, so title:

 Title: IP Wireless Access in Vehicular Environments (IPWAVE): Use Cases and Problem Statements
 

Abstract
1. Introduction
2. Terminology
   //each item: at most 4 lines
3. Use Cases: V2V, V2I, V2X
4. Current Architectures and Protocols
 - General Problems: Latency, No security, No pseudonym handling, No IP support, ... 

why architecture in this draft, I suggest take this out, it is better in another draft, just focus on the aim an objectives of the draft, the architecture needs another draft so if we update in future we just update architecture or update use cases,

 
5. Problem Exploration
 - IPv6 over IEEE 802.11-OCB
 - Neighbor Discovery
   . Link Model
   .. MAC Address Pseudonym
   . Prefix Dissemination/Exchange
   . Routing
 - Mobility Management
   . E2E Connectivity over V2I
 - Vehicle Identity Management  
 - Multihop V2X
 - Service Discovery
 - Security and Privacy
 - Others

please make them as problem statements sections so 5.1, 5.2, .....
also they need to cover our available charter only,
During the meeting in London the suggestion was to consider not only the current charter but also other aspects/problems of interest/future scope for this group.
 
 6. Security Considerations
------------------------------------------------------------------------------------------------------------

Please give us your comments on it.

With the agreed content, we authors will move forward for the documentation..


thanks

AB

 
Thanks.

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

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



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

Libre de virus. www.avast.com
--------------BF327A255E8D2D8A7142EEC3-- From nobody Sun Mar 25 13:45: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 01E6A129515 for ; Sun, 25 Mar 2018 13:45:48 -0700 (PDT) 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, 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 dQAWEXqhjvcU for ; Sun, 25 Mar 2018 13:45:46 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::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 EE9D4126D85 for ; Sun, 25 Mar 2018 13:45:45 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id l27so6729857pfk.12 for ; Sun, 25 Mar 2018 13:45:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:subject:from:to:date:in-reply-to:references:mime-version :content-transfer-encoding; bh=SgfsiIfVoQlPwRReSob0o5H2+igXEi2CnutZIA/QRIk=; b=KpdPA558Cgp+Xx1z7MDFtRK99p9dtbzQxbQC6WSQdhV6mYjR5XzGsRE2eBLufNRLUs KEEUUT9zmAjcUbyZ2Vn3F4ojsJL0y7uBs2N2mweyhwuBCkMCpV+pEGsie1rhZvwRmq13 ewG/ek0uah0KiGYrLra5Nfkz+DHTObcqyrLLbllKO0khAPCqYQ/EkNNCM1/Ep/JCEngC IlOCINubzwXs2FszPnH5DMCHNzuow6ZPIDgh33/a6VnQyQHUKBe6HGf0qEyJ0t+eqJCc ytbIRDU9icKyn8VMLMOZQVeU3ICukeGgeiKtWVQKwlsVttss5YRSoWCRl4U1paRPV8Iw F4HQ== 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:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=SgfsiIfVoQlPwRReSob0o5H2+igXEi2CnutZIA/QRIk=; b=dGwR65YAHY1tFCpZDRgBPDbfVNm5pGgchh7BBnEejvaEC028xO+4G6gh6IMKmdNSw+ D3pcTVXHcHYPiZT6Q8LCbXn6pCfDXmLm6H13S4Ck7TnGLRgpAaWzwVmZSZ48UMSnIqyc y17FTFYk+RZ9TD/Jdyg6Mx7aIe5bx9OudwAsvGeUcT/wg2mOVkxq5aGJ8nYj6bac6WBy yUVXjjjs1NHKR4KIXn0WrzsuldoCqUtyr+koLtAFt4K4lwwQnxeB9z0LUDfR05c42Eua BVQt/Ka8ol8sQmHJMe6q4/2kx+K0mGStnj1Lie4h2BuAykp1RdnQ9EJQbMqfiULFTBBu E6Tw== X-Gm-Message-State: AElRT7FgK3zhUaX8l+TQzuc6cJVc157ArezovfSSv71T6ecZ2RjXD9md ahKMlOuiqtrIR0ix/pmzFHL9Zg== X-Google-Smtp-Source: AG47ELt/yQVoZHY6S+gPZLH5PcdhVWbACLsZBCHm1dWo6mbDHQ98AL1FFK5UWrmQQN0ymV2kJV/ysA== X-Received: by 10.101.77.198 with SMTP id q6mr20688394pgt.61.1522010745528; Sun, 25 Mar 2018 13:45:45 -0700 (PDT) Received: from localhost.localdomain (c-71-198-163-21.hsd1.ca.comcast.net. [71.198.163.21]) by smtp.gmail.com with ESMTPSA id w27sm22869458pge.20.2018.03.25.13.45.44 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 25 Mar 2018 13:45:44 -0700 (PDT) Message-ID: <1522010744.2694.42.camel@gmail.com> From: Rex Buddenberg To: Sandra =?ISO-8859-1?Q?C=E9spedes?= , its@ietf.org Date: Sun, 25 Mar 2018 13:45:44 -0700 In-Reply-To: References: 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] Restructuring of the Problem Statement Document X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 20:45:48 -0000 Agree with Sandra's observation.  Recommend specifically include multicast within the charter. On Fri, 2018-03-23 at 21:23 -0300, Sandra Céspedes wrote: > >   > On 3/23/2018 5:55 PM, Abdussalam Baryun wrote: > > > > > > On Fri, Mar 23, 2018 at 11:50 AM, Mr. Jaehoon Paul Jeong > paul@gmail.com> wrote: > > > Hi IPWAVEers, > > > Here is a proposed restructuring of the Problem Statement > > > Document: > > > https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networkin > > > g-02 > > > > > > Sri and I discussed the current structure of the document.  > > > We thought the current document is too big with unnecessary > > > content (i.e., 52 pages). > > > We think we should reduce it to around 10 pages with concise > > > content with > > > > > even if it gets to 20p it can be ok, > >   > > > key problems for our IPWAVE WG. > > > We come with the following structure with the revised title. > > > > > > --------------------------------------------------------------- > > > --------------------------------------------- > > > Title: IP Wireless Access in Vehicular Environments (IPWAVE): > > > Problem Statement and Use Cases > > > > > I prefer we start with use cases then problems, so title: > > > >  Title: IP Wireless Access in Vehicular Environments (IPWAVE): Use > > Cases and Problem Statements > >   > > > > > > Abstract > > > 1. Introduction > > > 2. Terminology > > >    //each item: at most 4 lines > > > 3. Use Cases: V2V, V2I, V2X > > > 4. Current Architectures and Protocols > > >  - General Problems: Latency, No security, No pseudonym handling, > > > No IP support, ...  > > > > > why architecture in this draft, I suggest take this out, it is > > better in another draft, just focus on the aim an objectives of the > > draft, the architecture needs another draft so if we update in > > future we just update architecture or update use cases, > > > >   > > > 5. Problem Exploration > > >  - IPv6 over IEEE 802.11-OCB > > >  - Neighbor Discovery > > >    . Link Model > > >    .. MAC Address Pseudonym > > >    . Prefix Dissemination/Exchange > > >    . Routing > > >  - Mobility Management > > >    . E2E Connectivity over V2I > > >  - Vehicle Identity Management   > > >  - Multihop V2X > > >  - Service Discovery > > >  - Security and Privacy > > >  - Others > > > > > please make them as problem statements sections so 5.1, 5.2, ..... > > also they need to cover our available charter only, >  During the meeting in London the suggestion was to consider not only > the current charter but also other aspects/problems of > interest/future scope for this group.  > >   > > >  6. Security Considerations > > > --------------------------------------------------------------- > > > --------------------------------------------- > > > > > > Please give us your comments on it. > > > > > > With the agreed content, we authors will move forward for the > > > documentation.. > > > > > > > > thanks > > > > AB > > > >   > > > Thanks. > > > > > > Best Regards, > > > Paul > > > --  > > > =========================== > > > Mr. Jaehoon (Paul) Jeong, Ph.D. > > > Assistant Professor > > > Department of Software > > > Sungkyunkwan University > > > Office: +82-31-299-4957 > > > Email: jaehoon.paul@gmail.com, pauljeong@skku.edu > > > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.ph > > > p > > > > > > _______________________________________________ > > > 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 > Libre de virus. www.avast.com >  _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Mon Mar 26 09:09: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 28613124B17 for ; Mon, 26 Mar 2018 09:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.33 X-Spam-Level: X-Spam-Status: No, score=-4.33 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, T_RP_MATCHES_RCVD=-0.01] 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 2mQG5uFkIYBi for ; Mon, 26 Mar 2018 09:09:36 -0700 (PDT) Received: from mailout34.telekom.de (MAILOUT34.telekom.de [194.25.225.146]) (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 0706F126CC4 for ; Mon, 26 Mar 2018 09:09:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1522080576; x=1553616576; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=T0JEXT5YhIY01AnntWCZVqr5btn5ddvp0VVmNaI+3tk=; b=zm21iffcQj9DqjR1v6z63vDyvo7dsqoGiOI8n4hQur/igIh0cNwgNI1a mVgEc8LYmTmB8kRlnPEu+nkZwcaCS20Pg4cEYIl+rZs5aIFBSmDpvQpZZ PCQ+0Knyi2Eey1yJZIAsO3WvAVZhKFsXF4ski3gXGTjFkDBPxrmjFXVXP QBQs5fAzZLLjO3shCPPMHHbXyUr3/0gVrEnCCXXjjmgkoAK6YH+Dztp6j kKmWjsRQrsqmSgqn9zsD3SWeZ+Bv1sjXFsNDw31D3bysvMpmF/NOOHlA/ S9BCY33Jl98Tu2MAXoAUJDbYwauUMHYrVSHUj/G4i+sw5M2eePVSc1k0b A==; Received: from q4de8psa04t.blf.telekom.de ([10.151.13.130]) by MAILOUT31.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Mar 2018 18:08:33 +0200 X-IronPort-AV: E=Sophos;i="5.48,365,1517871600"; d="scan'208";a="842033354" Received: from he105715.emea1.cds.t-internal.com ([10.169.118.51]) by Q4DE8PSA04V.blf.telekom.de with ESMTP/TLS/AES256-SHA; 26 Mar 2018 18:08:32 +0200 Received: from HE105715.EMEA1.cds.t-internal.com (10.169.118.51) by HE105715.emea1.cds.t-internal.com (10.169.118.51) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Mon, 26 Mar 2018 18:08:31 +0200 Received: from HE105715.EMEA1.cds.t-internal.com ([fe80::e4a0:cc4:20d4:3019]) by HE105715.emea1.cds.t-internal.com ([fe80::e4a0:cc4:20d4:3019%26]) with mapi id 15.00.1365.000; Mon, 26 Mar 2018 18:08:31 +0200 From: To: , , Thread-Topic: [ipwave] Restructuring of the Problem Statement Document Thread-Index: AQHTwoyIVK+C+CQKxEyFxBkkkaRsRKPePKmAgAA6CwCAAtcpAIAA9dfA Date: Mon, 26 Mar 2018 16:08:31 +0000 Message-ID: <05afff15f1c94cedabaa20212e3385b1@HE105715.emea1.cds.t-internal.com> References: <1522010744.2694.42.camel@gmail.com> In-Reply-To: <1522010744.2694.42.camel@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.15] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [ipwave] Restructuring of the Problem Statement Document X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: 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 Mar 2018 16:09:39 -0000 RGVhciBhbGwsDQpyZWdhcmRpbmcgdGhlIG1lbnRpb25lZCAnb3RoZXIgYXNwZWN0cy9wcm9ibGVt cyBvZiBpbnRlcmVzdC9mdXR1cmUgc2NvcGUnIEkgdGhpbmsgaXQgd291bGQgYmUgd29ydGggdG8g YWRkIGEgc2VjdGlvbiBmb3IgNUcgLyBDLVYyWCAoYWxzbyByZXZlYWxlZCBhcyBhbiBpbXBvcnRh bnQgdGVjaG5vbG9neSkgYWxzbyB3aXRoIHJlc3BlY3QgdG8gaW50ZXJvcGVyYWJpbGl0eSBhbmQg YWNjZXNzIGhldGVyb2dlbmVpdHkgKGFuZCBzaW5jZSBJRUVFIDgwMi4xMXdoYXRzb2V2ZXIgbWF5 IGJlIHdpZGVseSBzZWVuIGFzIHBhcnQgb2YgNUcgYWNjZXNzIHZhcmlhbnRzKSBhbmQgaW5jbHVk ZSBpdCBpbiB0aGUgY2hhcnRlciBkaXNjdXNzaW9uLg0KVGhhbmtzIQ0KQmVzdCBSZWdhcmRzDQpE aXJrIA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaXRzIFttYWlsdG86aXRz LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSZXggQnVkZGVuYmVyZw0KU2VudDogU29u bnRhZywgMjUuIE3DpHJ6IDIwMTggMjI6NDYNClRvOiBTYW5kcmEgQ8Opc3BlZGVzIDxzY2VzcGVk ZXNAaW5nLnVjaGlsZS5jbD47IGl0c0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtpcHdhdmVdIFJl c3RydWN0dXJpbmcgb2YgdGhlIFByb2JsZW0gU3RhdGVtZW50IERvY3VtZW50DQoNCkFncmVlIHdp dGggU2FuZHJhJ3Mgb2JzZXJ2YXRpb24uIMKgUmVjb21tZW5kIHNwZWNpZmljYWxseSBpbmNsdWRl IG11bHRpY2FzdCB3aXRoaW4gdGhlIGNoYXJ0ZXIuDQoNCg0KT24gRnJpLCAyMDE4LTAzLTIzIGF0 IDIxOjIzIC0wMzAwLCBTYW5kcmEgQ8Opc3BlZGVzIHdyb3RlOg0KPiANCj4gwqANCj4gT24gMy8y My8yMDE4IDU6NTUgUE0sIEFiZHVzc2FsYW0gQmFyeXVuIHdyb3RlOg0KPiA+IA0KPiA+IA0KPiA+ IE9uIEZyaSwgTWFyIDIzLCAyMDE4IGF0IDExOjUwIEFNLCBNci4gSmFlaG9vbiBQYXVsIEplb25n IDxqYWVob29uLi4NCj4gPiBwYXVsQGdtYWlsLmNvbT4gd3JvdGU6DQo+ID4gPiBIaSBJUFdBVkVl cnMsDQo+ID4gPiBIZXJlIGlzIGEgcHJvcG9zZWQgcmVzdHJ1Y3R1cmluZyBvZiB0aGUgUHJvYmxl bSBTdGF0ZW1lbnQNCj4gPiA+IERvY3VtZW50Og0KPiA+ID4gaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtaXB3YXZlLXZlaGljdWxhci1uZXR3b3JraW4NCj4gPiA+IGctMDIN Cj4gPiA+IA0KPiA+ID4gU3JpIGFuZCBJIGRpc2N1c3NlZCB0aGUgY3VycmVudCBzdHJ1Y3R1cmUg b2YgdGhlIGRvY3VtZW50LiBXZSANCj4gPiA+IHRob3VnaHQgdGhlIGN1cnJlbnQgZG9jdW1lbnQg aXMgdG9vIGJpZyB3aXRoIHVubmVjZXNzYXJ5IGNvbnRlbnQgDQo+ID4gPiAoaS5lLiwgNTIgcGFn ZXMpLg0KPiA+ID4gV2UgdGhpbmsgd2Ugc2hvdWxkIHJlZHVjZSBpdCB0byBhcm91bmQgMTAgcGFn ZXMgd2l0aCBjb25jaXNlIA0KPiA+ID4gY29udGVudCB3aXRoDQo+ID4gPiANCj4gPiBldmVuIGlm IGl0IGdldHMgdG8gMjBwIGl0IGNhbiBiZSBvaywNCj4gPiDCoA0KPiA+ID4ga2V5IHByb2JsZW1z IGZvciBvdXIgSVBXQVZFIFdHLg0KPiA+ID4gV2UgY29tZSB3aXRoIHRoZSBmb2xsb3dpbmcgc3Ry dWN0dXJlIHdpdGggdGhlIHJldmlzZWQgdGl0bGUuDQo+ID4gPiANCj4gPiA+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gPiBU aXRsZTogSVAgV2lyZWxlc3MgQWNjZXNzIGluIFZlaGljdWxhciBFbnZpcm9ubWVudHMgKElQV0FW RSk6DQo+ID4gPiBQcm9ibGVtIFN0YXRlbWVudCBhbmQgVXNlIENhc2VzDQo+ID4gPiANCj4gPiBJ IHByZWZlciB3ZSBzdGFydCB3aXRoIHVzZSBjYXNlcyB0aGVuIHByb2JsZW1zLCBzbyB0aXRsZToN Cj4gPiANCj4gPiDCoFRpdGxlOiBJUCBXaXJlbGVzcyBBY2Nlc3MgaW4gVmVoaWN1bGFyIEVudmly b25tZW50cyAoSVBXQVZFKTogVXNlIA0KPiA+IENhc2VzIGFuZCBQcm9ibGVtIFN0YXRlbWVudHMN Cj4gPiDCoA0KPiA+ID4gDQo+ID4gPiBBYnN0cmFjdA0KPiA+ID4gMS4gSW50cm9kdWN0aW9uDQo+ ID4gPiAyLiBUZXJtaW5vbG9neQ0KPiA+ID4gwqAgwqAvL2VhY2ggaXRlbTogYXQgbW9zdCA0IGxp bmVzDQo+ID4gPiAzLiBVc2UgQ2FzZXM6IFYyViwgVjJJLCBWMlgNCj4gPiA+IDQuIEN1cnJlbnQg QXJjaGl0ZWN0dXJlcyBhbmQgUHJvdG9jb2xzDQo+ID4gPiDCoC0gR2VuZXJhbCBQcm9ibGVtczog TGF0ZW5jeSwgTm8gc2VjdXJpdHksIE5vIHBzZXVkb255bSBoYW5kbGluZywgDQo+ID4gPiBObyBJ UCBzdXBwb3J0LCAuLi4NCj4gPiA+IA0KPiA+IHdoeSBhcmNoaXRlY3R1cmUgaW4gdGhpcyBkcmFm dCwgSSBzdWdnZXN0IHRha2UgdGhpcyBvdXQsIGl0IGlzIA0KPiA+IGJldHRlciBpbiBhbm90aGVy IGRyYWZ0LCBqdXN0IGZvY3VzIG9uIHRoZSBhaW0gYW4gb2JqZWN0aXZlcyBvZiB0aGUgDQo+ID4g ZHJhZnQsIHRoZSBhcmNoaXRlY3R1cmUgbmVlZHMgYW5vdGhlciBkcmFmdCBzbyBpZiB3ZSB1cGRh dGUgaW4gDQo+ID4gZnV0dXJlIHdlIGp1c3QgdXBkYXRlIGFyY2hpdGVjdHVyZSBvciB1cGRhdGUg dXNlIGNhc2VzLA0KPiA+IA0KPiA+IMKgDQo+ID4gPiA1LiBQcm9ibGVtIEV4cGxvcmF0aW9uDQo+ ID4gPiDCoC0gSVB2NiBvdmVyIElFRUUgODAyLjExLU9DQg0KPiA+ID4gwqAtIE5laWdoYm9yIERp c2NvdmVyeQ0KPiA+ID4gwqAgwqAuIExpbmsgTW9kZWwNCj4gPiA+IMKgIMKgLi4gTUFDIEFkZHJl c3MgUHNldWRvbnltDQo+ID4gPiDCoCDCoC4gUHJlZml4IERpc3NlbWluYXRpb24vRXhjaGFuZ2UN Cj4gPiA+IMKgIMKgLiBSb3V0aW5nDQo+ID4gPiDCoC0gTW9iaWxpdHkgTWFuYWdlbWVudA0KPiA+ ID4gwqAgwqAuIEUyRSBDb25uZWN0aXZpdHkgb3ZlciBWMkkNCj4gPiA+IMKgLSBWZWhpY2xlIElk ZW50aXR5IE1hbmFnZW1lbnQNCj4gPiA+IMKgLSBNdWx0aWhvcCBWMlgNCj4gPiA+IMKgLSBTZXJ2 aWNlIERpc2NvdmVyeQ0KPiA+ID4gwqAtIFNlY3VyaXR5IGFuZCBQcml2YWN5DQo+ID4gPiDCoC0g T3RoZXJzDQo+ID4gPiANCj4gPiBwbGVhc2UgbWFrZSB0aGVtIGFzIHByb2JsZW0gc3RhdGVtZW50 cyBzZWN0aW9ucyBzbyA1LjEsIDUuMiwgLi4uLi4NCj4gPiBhbHNvIHRoZXkgbmVlZCB0byBjb3Zl ciBvdXIgYXZhaWxhYmxlIGNoYXJ0ZXIgb25seSwNCj4gwqBEdXJpbmcgdGhlIG1lZXRpbmcgaW4g TG9uZG9uIHRoZSBzdWdnZXN0aW9uIHdhcyB0byBjb25zaWRlciBub3Qgb25seSANCj4gdGhlIGN1 cnJlbnQgY2hhcnRlciBidXQgYWxzbyBvdGhlciBhc3BlY3RzL3Byb2JsZW1zIG9mIGludGVyZXN0 L2Z1dHVyZSANCj4gc2NvcGUgZm9yIHRoaXMgZ3JvdXAuDQo+ID4gwqANCj4gPiA+IMKgNi4gU2Vj dXJpdHkgQ29uc2lkZXJhdGlvbnMNCj4gPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ID4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gPiANCj4gPiA+IFBsZWFzZSBnaXZl IHVzIHlvdXIgY29tbWVudHMgb24gaXQuDQo+ID4gPiANCj4gPiA+IFdpdGggdGhlIGFncmVlZCBj b250ZW50LCB3ZSBhdXRob3JzIHdpbGwgbW92ZSBmb3J3YXJkIGZvciB0aGUgDQo+ID4gPiBkb2N1 bWVudGF0aW9uLi4NCj4gPiA+IA0KPiA+ID4gDQo+ID4gdGhhbmtzDQo+ID4gDQo+ID4gQUINCj4g PiANCj4gPiDCoA0KPiA+ID4gVGhhbmtzLg0KPiA+ID4gDQo+ID4gPiBCZXN0IFJlZ2FyZHMsDQo+ ID4gPiBQYXVsDQo+ID4gPiAtLQ0KPiA+ID4gPT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+ ID4gPiBNci4gSmFlaG9vbiAoUGF1bCkgSmVvbmcsIFBoLkQuDQo+ID4gPiBBc3Npc3RhbnQgUHJv ZmVzc29yDQo+ID4gPiBEZXBhcnRtZW50IG9mIFNvZnR3YXJlDQo+ID4gPiBTdW5na3l1bmt3YW4g VW5pdmVyc2l0eQ0KPiA+ID4gT2ZmaWNlOiArODItMzEtMjk5LTQ5NTcNCj4gPiA+IEVtYWlsOiBq YWVob29uLnBhdWxAZ21haWwuY29tLMKgcGF1bGplb25nQHNra3UuZWR1IFBlcnNvbmFsIA0KPiA+ ID4gSG9tZXBhZ2U6IGh0dHA6Ly9pb3RsYWIuc2trdS5lZHUvcGVvcGxlLWphZWhvb24tamVvbmcu cGgNCj4gPiA+IHANCj4gPiA+IA0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gPiA+IGl0cyBtYWlsaW5nIGxpc3QNCj4gPiA+IGl0c0BpZXRm Lm9yZw0KPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pdHMNCj4g PiA+IA0KPiA+ID4gDQo+ID4gDQo+ID4gDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gPiBpdHMgbWFpbGluZyBsaXN0DQo+ID4gaXRzQGlldGYu b3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pdHMNCj4gCUxp YnJlIGRlIHZpcnVzLiB3d3cuYXZhc3QuY29tDQo+IMKgX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gaXRzIG1haWxpbmcgbGlzdA0KPiBpdHNAaWV0Zi5v cmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pdHMNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCml0cyBtYWlsaW5nIGxp c3QNCml0c0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p dHMNCg==