From nobody Tue Jun 4 04:05:21 2019 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4301200D6 for ; Tue, 4 Jun 2019 04:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.231 X-Spam-Level: X-Spam-Status: No, score=-1.231 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkLc1tLdI5Qt for ; Tue, 4 Jun 2019 04:05:18 -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 DD3E5120018 for ; Tue, 4 Jun 2019 04:05:17 -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 x54B5Fid029231 for ; Tue, 4 Jun 2019 13:05:15 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D974E2056C1 for ; Tue, 4 Jun 2019 13:05:15 +0200 (CEST) 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 CE6C320557E for ; Tue, 4 Jun 2019 13:05:15 +0200 (CEST) Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x54B5FWd024558 for ; Tue, 4 Jun 2019 13:05:15 +0200 To: "its@ietf.org" From: Alexandre Petrescu Message-ID: Date: Tue, 4 Jun 2019 13:05:15 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------53AA84352C37BB2679027D53" Content-Language: fr Archived-At: Subject: [ipwave] IPv6-over-OCB - channel width 20MHz? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: 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, 04 Jun 2019 11:05:21 -0000 This is a multi-part message in MIME format. --------------53AA84352C37BB2679027D53 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi IPWAVErs, I wonder whether someone has already tried 20MHz channel widths on OCB with IPv6? (instead of 10MHz classical). I am asking because our convoy trial requests now even more data between cars on IPv6; we seem to hit bandwidth limits. We are trying to accommodate this increased amount of data by grouping together two channels.  This could be accomplished with the 'iw' command, I believe, because it is the one that sets the channel width to 10MHz typically. Some already tried 20MHz channel width on OCB with IPv6? Alex PS: to augment bandwidth we also try increases on MTU and related tweaks, but that is easy to perform. --------------53AA84352C37BB2679027D53 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi IPWAVErs,

I wonder whether someone has already tried 20MHz channel widths on OCB with IPv6? (instead of 10MHz classical).

I am asking because our convoy trial requests now even more data between cars on IPv6; we seem to hit bandwidth limits.

We are trying to accommodate this increased amount of data by grouping together two channels.  This could be accomplished with the 'iw' command, I believe, because it is the one that sets the channel width to 10MHz typically.

Some already tried 20MHz channel width on OCB with IPv6?

Alex

PS: to augment bandwidth we also try increases on MTU and related tweaks, but that is easy to perform.

--------------53AA84352C37BB2679027D53-- From nobody Wed Jun 5 20:13:27 2019 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80CCD1200C5 for ; Wed, 5 Jun 2019 20:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 UBQt7PNP0cRZ for ; Wed, 5 Jun 2019 20:13:23 -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 24FA7120043 for ; Wed, 5 Jun 2019 20:13:22 -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 x563DKQR010965 for ; Thu, 6 Jun 2019 05:13:20 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9F32620102E for ; Thu, 6 Jun 2019 05:13:20 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 92A4C200F6C for ; Thu, 6 Jun 2019 05:13:20 +0200 (CEST) Received: from [10.8.68.8] ([10.8.68.8]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x563DKL6004781 for ; Thu, 6 Jun 2019 05:13:20 +0200 To: its@ietf.org References: <61452b20-9cd1-c9ce-1eb2-ebb090efb8c4@gmail.com> From: Alexandre Petrescu Message-ID: <936d2cd6-5381-8387-cd2d-e8b33cb5dd7a@gmail.com> Date: Thu, 6 Jun 2019 05:13:19 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <61452b20-9cd1-c9ce-1eb2-ebb090efb8c4@gmail.com> Content-Type: multipart/alternative; boundary="------------E8933616D3D87C7C3A4D4AA0" Content-Language: fr Archived-At: Subject: Re: [ipwave] Protocols and Architectures for Traffic Lights X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: 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, 06 Jun 2019 03:13:25 -0000 This is a multi-part message in MIME format. --------------E8933616D3D87C7C3A4D4AA0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit For completeness, The complete list of protocols to communication to Traffic Lights Controllers is: DIASER, IVERA, OCIT. Because I learn in Germany and the Czech Republic, the OCIT protocol (not DIASER) may be used for communication to Traffic Lights Controller, with some implementations from Siemens and from Cross.  Not known whether OCIT works on IP, and on IPv6. DIASER is known to work on RS232, TCP and UDP.  Seen on IPv4; not known on IPv6.  SEA is a traffic lights controller manufacturer in France that produces some, implements DIASER too.  There are about 10 manufacturers in France (Aximum of Colas, Fareco of Fayat, Lacroix, SEA, others?), all doing DIASER. Basically, if one wants a car to talk to traffic lights controllers with low latenccy, one wants to put 3 protocols in that car. Le 29/01/2019 à 15:04, Alexandre Petrescu a écrit : > >   Protocols and Architectures for Traffic Lights >               Januay 29th, 2019 > > > DIASER: a protocol used to communicate to Traffic Lights controllers. > Used in France.  Specified by AFNOR.  Closed and paying specification. > Works on hardware platforms from Lacroix (model Traffy) and Aximum > (model Maestro), and probably others.  Works on serial and on UDP/IP. > Example queries are: "DZ" to reset, "Ck" and "CJ" to query the current > color of lights, C# and CU to get the time spent in a color. > > API WIM 7101, RSGC2: proprietary API interfaces used by organisation > NEAVIA of organisation Lacroix in France; it is used to provide access > to data of traffic lights controllers.  It can be used with DIASER in > a sequence way: a gateway converts from one to another. > > ISO PRESTO 22951: a protocol to communicate with traffic lights > controller, to obtain priority for special vehicles. > > SPAT/SSM/SRM: protocols used by future traffic lights controllers; > specified by SAE in J2735.  The 2009 version is freely available, > whereas the 2016 (non retro-compatible) is paying 100 USD, > approximative.  SPAT is Signal Phase and Timing, whereas SRM is Signal > Request Message. > > SPAT-EM: an European version of SPAT, specified by ETSI, which > encapsulates SPAT.  Free access, but SPAT still paying (free > encapsulated paying). > > IVERA: a protocol used in Netherlands to communicate with Traffic > Lights controllers.  Potentially VLOG is also such a protocol. > > 3G Segnaletica: an organisation in Italy that provides hardware for > controllers for traffic  lights.  Also has models carried in 'mobile' > traffic lights.  It provides a Raspberry Pi to access the traffic > lights data.  The Raspberry Pi uses an API to access the controller > status.  That API uses HTTP. > > Siemens: is an organisation that probably provides hardware for > traffic lights controllers to be used in America (USA). > > Architectures: sketches drawing controller, tri-light bulbs, Internet, > 802.11-OCB, car, API, SPAT. > > Acknowledgements: Daniele Brevi, Bart Netten, Stephane Goeuriot, Sri > Gundavelli, Bruno Cabon, Paul Thorpe. > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its --------------E8933616D3D87C7C3A4D4AA0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

For completeness,


The complete list of protocols to communication to Traffic Lights Controllers is: DIASER, IVERA, OCIT.

Because I learn in Germany and the Czech Republic, the OCIT protocol (not DIASER) may be used for communication to Traffic Lights Controller, with some implementations from Siemens and from Cross.  Not known whether OCIT works on IP, and on IPv6.

DIASER is known to work on RS232, TCP and UDP.  Seen on IPv4; not known on IPv6.  SEA is a traffic lights controller manufacturer in France that produces some, implements DIASER too.  There are about 10 manufacturers in France (Aximum of Colas, Fareco of Fayat, Lacroix, SEA, others?), all doing DIASER.

Basically, if one wants a car to talk to traffic lights controllers with low latenccy, one wants to put 3 protocols in that car.


Le 29/01/2019 à 15:04, Alexandre Petrescu a écrit :

  Protocols and Architectures for Traffic Lights
              Januay 29th, 2019


DIASER: a protocol used to communicate to Traffic Lights controllers.
Used in France.  Specified by AFNOR.  Closed and paying specification.
Works on hardware platforms from Lacroix (model Traffy) and Aximum
(model Maestro), and probably others.  Works on serial and on UDP/IP.
Example queries are: "DZ" to reset, "Ck" and "CJ" to query the current
color of lights, C# and CU to get the time spent in a color.

API WIM 7101, RSGC2: proprietary API interfaces used by organisation
NEAVIA of organisation Lacroix in France; it is used to provide access
to data of traffic lights controllers.  It can be used with DIASER in
a sequence way: a gateway converts from one to another.

ISO PRESTO 22951: a protocol to communicate with traffic lights
controller, to obtain priority for special vehicles.

SPAT/SSM/SRM: protocols used by future traffic lights controllers;
specified by SAE in J2735.  The 2009 version is freely available,
whereas the 2016 (non retro-compatible) is paying 100 USD,
approximative.  SPAT is Signal Phase and Timing, whereas SRM is Signal
Request Message.

SPAT-EM: an European version of SPAT, specified by ETSI, which
encapsulates SPAT.  Free access, but SPAT still paying (free
encapsulated paying).

IVERA: a protocol used in Netherlands to communicate with Traffic
Lights controllers.  Potentially VLOG is also such a protocol.

3G Segnaletica: an organisation in Italy that provides hardware for
controllers for traffic  lights.  Also has models carried in 'mobile'
traffic lights.  It provides a Raspberry Pi to access the traffic
lights data.  The Raspberry Pi uses an API to access the controller
status.  That API uses HTTP.

Siemens: is an organisation that probably provides hardware for
traffic lights controllers to be used in America (USA).

Architectures: sketches drawing controller, tri-light bulbs, Internet,
802.11-OCB, car, API, SPAT.

Acknowledgements: Daniele Brevi, Bart Netten, Stephane Goeuriot, Sri
Gundavelli, Bruno Cabon, Paul Thorpe.


_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its
--------------E8933616D3D87C7C3A4D4AA0-- From nobody Thu Jun 6 08:18:47 2019 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FEAB120124 for ; Thu, 6 Jun 2019 08:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 T_Tl0WITTj3Q for ; Thu, 6 Jun 2019 08:18:44 -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 9620312011A for ; Thu, 6 Jun 2019 08:18:43 -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 x56FIfiR008377 for ; Thu, 6 Jun 2019 17:18:41 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7917620655C for ; Thu, 6 Jun 2019 17:18:41 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 6D31E20604E for ; Thu, 6 Jun 2019 17:18:41 +0200 (CEST) Received: from [10.8.68.52] ([10.8.68.52]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x56FIfde031061 for ; Thu, 6 Jun 2019 17:18:41 +0200 To: its@ietf.org References: <61452b20-9cd1-c9ce-1eb2-ebb090efb8c4@gmail.com> <936d2cd6-5381-8387-cd2d-e8b33cb5dd7a@gmail.com> From: Alexandre Petrescu Message-ID: Date: Thu, 6 Jun 2019 17:18:40 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <936d2cd6-5381-8387-cd2d-e8b33cb5dd7a@gmail.com> Content-Type: multipart/alternative; boundary="------------30ADC621E3CB11D41A3E91F7" Content-Language: fr Archived-At: Subject: Re: [ipwave] Protocols and Architectures for Traffic Lights X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: 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, 06 Jun 2019 15:18:46 -0000 This is a multi-part message in MIME format. --------------30ADC621E3CB11D41A3E91F7 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit For further completeness... The Dutch version of protocols for Traffic Lights Controllers, in addition to IVERA also include iVRI, on the web at https://www.crow.nl/thema-s/verkeersmanagement/landelijke-ivri-standaarden The German OCIT protocol is on the web at www.ocit.org I continue to wonder what is the protocol used for communicating with Traffic Lights Controllers in Italy, and in America? Alex Le 06/06/2019 à 05:13, Alexandre Petrescu a écrit : > > For completeness, > > > The complete list of protocols to communication to Traffic Lights > Controllers is: DIASER, IVERA, OCIT. > > Because I learn in Germany and the Czech Republic, the OCIT protocol > (not DIASER) may be used for communication to Traffic Lights > Controller, with some implementations from Siemens and from Cross.  > Not known whether OCIT works on IP, and on IPv6. > > DIASER is known to work on RS232, TCP and UDP.  Seen on IPv4; not > known on IPv6.  SEA is a traffic lights controller manufacturer in > France that produces some, implements DIASER too.  There are about 10 > manufacturers in France (Aximum of Colas, Fareco of Fayat, Lacroix, > SEA, others?), all doing DIASER. > > Basically, if one wants a car to talk to traffic lights controllers > with low latenccy, one wants to put 3 protocols in that car. > > > Le 29/01/2019 à 15:04, Alexandre Petrescu a écrit : >> >>   Protocols and Architectures for Traffic Lights >>               Januay 29th, 2019 >> >> >> DIASER: a protocol used to communicate to Traffic Lights controllers. >> Used in France.  Specified by AFNOR.  Closed and paying specification. >> Works on hardware platforms from Lacroix (model Traffy) and Aximum >> (model Maestro), and probably others.  Works on serial and on UDP/IP. >> Example queries are: "DZ" to reset, "Ck" and "CJ" to query the current >> color of lights, C# and CU to get the time spent in a color. >> >> API WIM 7101, RSGC2: proprietary API interfaces used by organisation >> NEAVIA of organisation Lacroix in France; it is used to provide access >> to data of traffic lights controllers.  It can be used with DIASER in >> a sequence way: a gateway converts from one to another. >> >> ISO PRESTO 22951: a protocol to communicate with traffic lights >> controller, to obtain priority for special vehicles. >> >> SPAT/SSM/SRM: protocols used by future traffic lights controllers; >> specified by SAE in J2735.  The 2009 version is freely available, >> whereas the 2016 (non retro-compatible) is paying 100 USD, >> approximative.  SPAT is Signal Phase and Timing, whereas SRM is Signal >> Request Message. >> >> SPAT-EM: an European version of SPAT, specified by ETSI, which >> encapsulates SPAT.  Free access, but SPAT still paying (free >> encapsulated paying). >> >> IVERA: a protocol used in Netherlands to communicate with Traffic >> Lights controllers.  Potentially VLOG is also such a protocol. >> >> 3G Segnaletica: an organisation in Italy that provides hardware for >> controllers for traffic  lights.  Also has models carried in 'mobile' >> traffic lights.  It provides a Raspberry Pi to access the traffic >> lights data.  The Raspberry Pi uses an API to access the controller >> status.  That API uses HTTP. >> >> Siemens: is an organisation that probably provides hardware for >> traffic lights controllers to be used in America (USA). >> >> Architectures: sketches drawing controller, tri-light bulbs, Internet, >> 802.11-OCB, car, API, SPAT. >> >> Acknowledgements: Daniele Brevi, Bart Netten, Stephane Goeuriot, Sri >> Gundavelli, Bruno Cabon, Paul Thorpe. >> >> >> _______________________________________________ >> 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 --------------30ADC621E3CB11D41A3E91F7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

For further completeness...

The Dutch version of protocols for Traffic Lights Controllers, in addition to IVERA also include iVRI, on the web at https://www.crow.nl/thema-s/verkeersmanagement/landelijke-ivri-standaarden

The German OCIT protocol is on the web at www.ocit.org

I continue to wonder what is the protocol used for communicating with Traffic Lights Controllers in Italy, and in America?

Alex

Le 06/06/2019 à 05:13, Alexandre Petrescu a écrit :

For completeness,


The complete list of protocols to communication to Traffic Lights Controllers is: DIASER, IVERA, OCIT.

Because I learn in Germany and the Czech Republic, the OCIT protocol (not DIASER) may be used for communication to Traffic Lights Controller, with some implementations from Siemens and from Cross.  Not known whether OCIT works on IP, and on IPv6.

DIASER is known to work on RS232, TCP and UDP.  Seen on IPv4; not known on IPv6.  SEA is a traffic lights controller manufacturer in France that produces some, implements DIASER too.  There are about 10 manufacturers in France (Aximum of Colas, Fareco of Fayat, Lacroix, SEA, others?), all doing DIASER.

Basically, if one wants a car to talk to traffic lights controllers with low latenccy, one wants to put 3 protocols in that car.


Le 29/01/2019 à 15:04, Alexandre Petrescu a écrit :

  Protocols and Architectures for Traffic Lights
              Januay 29th, 2019


DIASER: a protocol used to communicate to Traffic Lights controllers.
Used in France.  Specified by AFNOR.  Closed and paying specification.
Works on hardware platforms from Lacroix (model Traffy) and Aximum
(model Maestro), and probably others.  Works on serial and on UDP/IP.
Example queries are: "DZ" to reset, "Ck" and "CJ" to query the current
color of lights, C# and CU to get the time spent in a color.

API WIM 7101, RSGC2: proprietary API interfaces used by organisation
NEAVIA of organisation Lacroix in France; it is used to provide access
to data of traffic lights controllers.  It can be used with DIASER in
a sequence way: a gateway converts from one to another.

ISO PRESTO 22951: a protocol to communicate with traffic lights
controller, to obtain priority for special vehicles.

SPAT/SSM/SRM: protocols used by future traffic lights controllers;
specified by SAE in J2735.  The 2009 version is freely available,
whereas the 2016 (non retro-compatible) is paying 100 USD,
approximative.  SPAT is Signal Phase and Timing, whereas SRM is Signal
Request Message.

SPAT-EM: an European version of SPAT, specified by ETSI, which
encapsulates SPAT.  Free access, but SPAT still paying (free
encapsulated paying).

IVERA: a protocol used in Netherlands to communicate with Traffic
Lights controllers.  Potentially VLOG is also such a protocol.

3G Segnaletica: an organisation in Italy that provides hardware for
controllers for traffic  lights.  Also has models carried in 'mobile'
traffic lights.  It provides a Raspberry Pi to access the traffic
lights data.  The Raspberry Pi uses an API to access the controller
status.  That API uses HTTP.

Siemens: is an organisation that probably provides hardware for
traffic lights controllers to be used in America (USA).

Architectures: sketches drawing controller, tri-light bulbs, Internet,
802.11-OCB, car, API, SPAT.

Acknowledgements: Daniele Brevi, Bart Netten, Stephane Goeuriot, Sri
Gundavelli, Bruno Cabon, Paul Thorpe.


_______________________________________________
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
--------------30ADC621E3CB11D41A3E91F7-- From nobody Thu Jun 6 10:26:49 2019 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF4F1200B2 for ; Thu, 6 Jun 2019 10:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 HNZiP8_N_C7o for ; Thu, 6 Jun 2019 10:26:45 -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 27650120092 for ; Thu, 6 Jun 2019 10:26:44 -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 x56HQhK6006339 for ; Thu, 6 Jun 2019 19:26:43 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 511092065ED for ; Thu, 6 Jun 2019 19:26:43 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 442BE206594 for ; Thu, 6 Jun 2019 19:26:43 +0200 (CEST) Received: from [10.8.68.52] ([10.8.68.52]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x56HQg8G014337 for ; Thu, 6 Jun 2019 19:26:42 +0200 To: its@ietf.org References: <61452b20-9cd1-c9ce-1eb2-ebb090efb8c4@gmail.com> <936d2cd6-5381-8387-cd2d-e8b33cb5dd7a@gmail.com> From: Alexandre Petrescu Message-ID: <837d0035-9afa-dc24-f527-55b92f1a9ce2@gmail.com> Date: Thu, 6 Jun 2019 19:26:42 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9E76F7760E92C1B32B8F1F82" Content-Language: fr Archived-At: Subject: Re: [ipwave] Protocols and Architectures for Traffic Light Controllers X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: 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, 06 Jun 2019 17:26:47 -0000 This is a multi-part message in MIME format. --------------9E76F7760E92C1B32B8F1F82 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sorry, I forgot, we already discussed.  I am in told in private that: In the US the protocol to communicate with Traffic Lights Controllers is NTCIP.  It is on the web at https://www.ntcip.org/document-numbers-and-status/ It has Internet specifically (it has profile for it, dated 2001). I dont see IPv6 mentioned though. Not only a car would need to implement IVERA, DIASER, NTCIP and OCIT to talk to Traffic Lights Controllers, but it would not need IPv6 at all.  Because none runs on IPv6. I disagree with this lack of IPv6 support in these protocols. Le 06/06/2019 à 17:18, Alexandre Petrescu a écrit : > > For further completeness... > > The Dutch version of protocols for Traffic Lights Controllers, in > addition to IVERA also include iVRI, on the web at > https://www.crow.nl/thema-s/verkeersmanagement/landelijke-ivri-standaarden > > The German OCIT protocol is on the web at www.ocit.org > > I continue to wonder what is the protocol used for communicating with > Traffic Lights Controllers in Italy, and in America? > > Alex > > Le 06/06/2019 à 05:13, Alexandre Petrescu a écrit : >> >> For completeness, >> >> >> The complete list of protocols to communication to Traffic Lights >> Controllers is: DIASER, IVERA, OCIT. >> >> Because I learn in Germany and the Czech Republic, the OCIT protocol >> (not DIASER) may be used for communication to Traffic Lights >> Controller, with some implementations from Siemens and from Cross.  >> Not known whether OCIT works on IP, and on IPv6. >> >> DIASER is known to work on RS232, TCP and UDP.  Seen on IPv4; not >> known on IPv6.  SEA is a traffic lights controller manufacturer in >> France that produces some, implements DIASER too.  There are about 10 >> manufacturers in France (Aximum of Colas, Fareco of Fayat, Lacroix, >> SEA, others?), all doing DIASER. >> >> Basically, if one wants a car to talk to traffic lights controllers >> with low latenccy, one wants to put 3 protocols in that car. >> >> >> Le 29/01/2019 à 15:04, Alexandre Petrescu a écrit : >>> >>>   Protocols and Architectures for Traffic Lights >>>               Januay 29th, 2019 >>> >>> >>> DIASER: a protocol used to communicate to Traffic Lights controllers. >>> Used in France.  Specified by AFNOR.  Closed and paying specification. >>> Works on hardware platforms from Lacroix (model Traffy) and Aximum >>> (model Maestro), and probably others.  Works on serial and on UDP/IP. >>> Example queries are: "DZ" to reset, "Ck" and "CJ" to query the current >>> color of lights, C# and CU to get the time spent in a color. >>> >>> API WIM 7101, RSGC2: proprietary API interfaces used by organisation >>> NEAVIA of organisation Lacroix in France; it is used to provide access >>> to data of traffic lights controllers.  It can be used with DIASER in >>> a sequence way: a gateway converts from one to another. >>> >>> ISO PRESTO 22951: a protocol to communicate with traffic lights >>> controller, to obtain priority for special vehicles. >>> >>> SPAT/SSM/SRM: protocols used by future traffic lights controllers; >>> specified by SAE in J2735.  The 2009 version is freely available, >>> whereas the 2016 (non retro-compatible) is paying 100 USD, >>> approximative.  SPAT is Signal Phase and Timing, whereas SRM is Signal >>> Request Message. >>> >>> SPAT-EM: an European version of SPAT, specified by ETSI, which >>> encapsulates SPAT.  Free access, but SPAT still paying (free >>> encapsulated paying). >>> >>> IVERA: a protocol used in Netherlands to communicate with Traffic >>> Lights controllers.  Potentially VLOG is also such a protocol. >>> >>> 3G Segnaletica: an organisation in Italy that provides hardware for >>> controllers for traffic  lights.  Also has models carried in 'mobile' >>> traffic lights.  It provides a Raspberry Pi to access the traffic >>> lights data.  The Raspberry Pi uses an API to access the controller >>> status.  That API uses HTTP. >>> >>> Siemens: is an organisation that probably provides hardware for >>> traffic lights controllers to be used in America (USA). >>> >>> Architectures: sketches drawing controller, tri-light bulbs, Internet, >>> 802.11-OCB, car, API, SPAT. >>> >>> Acknowledgements: Daniele Brevi, Bart Netten, Stephane Goeuriot, Sri >>> Gundavelli, Bruno Cabon, Paul Thorpe. >>> >>> >>> _______________________________________________ >>> 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 --------------9E76F7760E92C1B32B8F1F82 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Sorry, I forgot, we already discussed.  I am in told in private that:

In the US the protocol to communicate with Traffic Lights Controllers is NTCIP.  It is on the web at https://www.ntcip.org/document-numbers-and-status/ It has Internet specifically (it has profile for it, dated 2001).

I dont see IPv6 mentioned though.

Not only a car would need to implement IVERA, DIASER, NTCIP and OCIT to talk to Traffic Lights Controllers, but it would not need IPv6 at all.  Because none runs on IPv6.

I disagree with this lack of IPv6 support in these protocols.


Le 06/06/2019 à 17:18, Alexandre Petrescu a écrit :

For further completeness...

The Dutch version of protocols for Traffic Lights Controllers, in addition to IVERA also include iVRI, on the web at https://www.crow.nl/thema-s/verkeersmanagement/landelijke-ivri-standaarden

The German OCIT protocol is on the web at www.ocit.org

I continue to wonder what is the protocol used for communicating with Traffic Lights Controllers in Italy, and in America?

Alex

Le 06/06/2019 à 05:13, Alexandre Petrescu a écrit :

For completeness,


The complete list of protocols to communication to Traffic Lights Controllers is: DIASER, IVERA, OCIT.

Because I learn in Germany and the Czech Republic, the OCIT protocol (not DIASER) may be used for communication to Traffic Lights Controller, with some implementations from Siemens and from Cross.  Not known whether OCIT works on IP, and on IPv6.

DIASER is known to work on RS232, TCP and UDP.  Seen on IPv4; not known on IPv6.  SEA is a traffic lights controller manufacturer in France that produces some, implements DIASER too.  There are about 10 manufacturers in France (Aximum of Colas, Fareco of Fayat, Lacroix, SEA, others?), all doing DIASER.

Basically, if one wants a car to talk to traffic lights controllers with low latenccy, one wants to put 3 protocols in that car.


Le 29/01/2019 à 15:04, Alexandre Petrescu a écrit :

  Protocols and Architectures for Traffic Lights
              Januay 29th, 2019


DIASER: a protocol used to communicate to Traffic Lights controllers.
Used in France.  Specified by AFNOR.  Closed and paying specification.
Works on hardware platforms from Lacroix (model Traffy) and Aximum
(model Maestro), and probably others.  Works on serial and on UDP/IP.
Example queries are: "DZ" to reset, "Ck" and "CJ" to query the current
color of lights, C# and CU to get the time spent in a color.

API WIM 7101, RSGC2: proprietary API interfaces used by organisation
NEAVIA of organisation Lacroix in France; it is used to provide access
to data of traffic lights controllers.  It can be used with DIASER in
a sequence way: a gateway converts from one to another.

ISO PRESTO 22951: a protocol to communicate with traffic lights
controller, to obtain priority for special vehicles.

SPAT/SSM/SRM: protocols used by future traffic lights controllers;
specified by SAE in J2735.  The 2009 version is freely available,
whereas the 2016 (non retro-compatible) is paying 100 USD,
approximative.  SPAT is Signal Phase and Timing, whereas SRM is Signal
Request Message.

SPAT-EM: an European version of SPAT, specified by ETSI, which
encapsulates SPAT.  Free access, but SPAT still paying (free
encapsulated paying).

IVERA: a protocol used in Netherlands to communicate with Traffic
Lights controllers.  Potentially VLOG is also such a protocol.

3G Segnaletica: an organisation in Italy that provides hardware for
controllers for traffic  lights.  Also has models carried in 'mobile'
traffic lights.  It provides a Raspberry Pi to access the traffic
lights data.  The Raspberry Pi uses an API to access the controller
status.  That API uses HTTP.

Siemens: is an organisation that probably provides hardware for
traffic lights controllers to be used in America (USA).

Architectures: sketches drawing controller, tri-light bulbs, Internet,
802.11-OCB, car, API, SPAT.

Acknowledgements: Daniele Brevi, Bart Netten, Stephane Goeuriot, Sri
Gundavelli, Bruno Cabon, Paul Thorpe.


_______________________________________________
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
--------------9E76F7760E92C1B32B8F1F82-- From nobody Fri Jun 7 05:34:11 2019 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 5182B120105; Fri, 7 Jun 2019 05:34:09 -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.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: its@ietf.org Message-ID: <155991084927.19960.6812267268348799305@ietfa.amsl.com> Date: Fri, 07 Jun 2019 05:34:09 -0700 Archived-At: Subject: [ipwave] I-D Action: draft-ietf-ipwave-ipv6-over-80211ocb-46.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 List-Id: 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, 07 Jun 2019 12:34:09 -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 : Basic support for IPv6 over IEEE Std 802.11 Networks operating Outside the Context of a Basic Service Set (IPv6-over-80211-OCB) Authors : Nabil Benamar Jerome Haerri Jong-Hyouk Lee Thierry Ernst Filename : draft-ietf-ipwave-ipv6-over-80211ocb-46.txt Pages : 32 Date : 2019-06-07 Abstract: This document provides methods and settings, and describes limitations, for using IPv6 to communicate among nodes in range of one another over a single IEEE 802.11-OCB link with minimal change to existing stacks. Optimizations and usage of IPv6 over more complex scenarios is not covered and is subject of future work. 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-46 https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-46 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-46 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 Jun 7 05:38:28 2019 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68AA3120137 for ; Fri, 7 Jun 2019 05:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=est-umi-ac-ma.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 nr-pNX5HgDAm for ; Fri, 7 Jun 2019 05:38:24 -0700 (PDT) Received: from mail-it1-x129.google.com (mail-it1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (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 7357B12003F for ; Fri, 7 Jun 2019 05:38:24 -0700 (PDT) Received: by mail-it1-x129.google.com with SMTP id m138so796616ita.4 for ; Fri, 07 Jun 2019 05:38:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=est-umi-ac-ma.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=nsfiVrXPrsJ/wFoT7EYdwbWzXgQaaTInEHXcO3YWmTE=; b=rPYihEUnb56W10Zwxt4tTN9ejkc6nO3jWUM3dqnQoL8Vn+/+8ldVmkPfx7ZZ8gf31Z /erbTpPnbZShZen689r5+NKVdcFuscb5N3pFFnsoBAxyzragZgCryeSIaLxnSZVRRXzh R+P6IbPGTzqulLngeRK9tcQ5alN79HJRv+AM1kKOBV/4EmWE3E8DG4nLujdHxOQSEJqG 4uJ2QpFuxom6X8pzRXwLQul8rS/fgE5J4vIJqiRiGczhc6QHhhcfE6693jOKfmK6llyT KwEYS8QxjL0kA3Z85HwZvNnsCwVBkXl6qddwQajHVFVwaVeJ5BGwLpNc9Z7YYtbj/t8b 2qTg== 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; bh=nsfiVrXPrsJ/wFoT7EYdwbWzXgQaaTInEHXcO3YWmTE=; b=jkC5wOvVw5QSYUE3Qq2/WKJ6oE66C4t8vDnGsWj2kwfgHvrcYsRKLWbHvspTY8W5ZB 4OBxEFuoEnN8ZpZFQWEZJ4gZtCtTdA5qbVXvvRi1ltgIYM0LwLMH/4uPG1iXotKDzBiD CMcLGiEY1T/BptVuU4UrO9kMaC8hH/kWPfneFGrhRvvAkQ4OhJ6vps2DRIVzHPHXB4tb s6z3tF9eesU01oL+nKaQTM+5LyJwTqi/AnzA3ZjkumIIushAKHJDVJo/0a1CqgmUWAjF sH6TyOg9z6iZgAxCCsY1HZrICZwS0LAXIhyFKWZ14PjGkJ9tyX2jyMCWv93CAt+SNlvY +3tQ== X-Gm-Message-State: APjAAAWG8Nzw91VQdSqnRHKrzOEzVC77UJxsKaIHoUYG5i5NpGZTjq39 sNKvgqhMHTdstszR4L4AiftosdQVrkvFm+qcg+u8J5f2XIHw1g== X-Google-Smtp-Source: APXvYqyNMAI7lQkzD1GDdcMmW2HZsN36KdV0LW0fqXlrXwiyRNwekPpj41U0orFJZqBIELeYsgZtGy3h8GnC76Ldie8= X-Received: by 2002:a24:1416:: with SMTP id 22mr3835824itg.144.1559911103455; Fri, 07 Jun 2019 05:38:23 -0700 (PDT) MIME-Version: 1.0 References: <155991084952.19960.17374914723142087501.idtracker@ietfa.amsl.com> In-Reply-To: <155991084952.19960.17374914723142087501.idtracker@ietfa.amsl.com> From: NABIL BENAMAR Date: Fri, 7 Jun 2019 12:38:12 +0000 Message-ID: To: its@ietf.org Content-Type: multipart/alternative; boundary="00000000000033eca1058abb1bf4" Archived-At: Subject: [ipwave] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-46.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: 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, 07 Jun 2019 12:38:27 -0000 --00000000000033eca1058abb1bf4 Content-Type: text/plain; charset="UTF-8" Dear IPWAVEs, I have just submitted version 46 of the draft-ietf-ipwave-ipv6-over-8 0211ocb. This version includes the modifications that were discussed with the reviewer (Pascal Thubert) on the ML. ---------- Forwarded message --------- From: Date: Fri, Jun 7, 2019 at 12:34 PM Subject: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-46.txt To: Jerome Haerri , , Jerome Haerri , Nabil Benamar < n.benamar@est.umi.ac.ma>, Thierry Ernst , Jong-Hyouk Lee A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-46.txt has been successfully submitted by Nabil Benamar and posted to the IETF repository. Name: draft-ietf-ipwave-ipv6-over-80211ocb Revision: 46 Title: Basic support for IPv6 over IEEE Std 802.11 Networks operating Outside the Context of a Basic Service Set (IPv6-over-80211-OCB) Document date: 2019-06-07 Group: ipwave Pages: 32 URL: https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-46.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-46 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-46 Abstract: This document provides methods and settings, and describes limitations, for using IPv6 to communicate among nodes in range of one another over a single IEEE 802.11-OCB link with minimal change to existing stacks. Optimizations and usage of IPv6 over more complex scenarios is not covered and is subject of future work. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- Best Regards Nabil Benamar Associate Professor Department of Computer Sciences School of Technology Moulay Ismail University Meknes. Morocco --00000000000033eca1058abb1bf4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear = IPWAVEs,

I have just submitte= d version 46 of the=C2=A0draft-ietf-ipw= ave-ipv6-over-80211ocb.

This version includes the modifications that were discussed wi= th the reviewer (Pascal Thubert) on the ML.

---------- Forwarded message ---= ------
From: <internet-drafts@ietf.org>
Date: Fri, Jun 7, 2019 a= t 12:34 PM
Subject: New Version Notification for draft-ietf-ipwave-ipv6-= over-80211ocb-46.txt
To: Jerome Haerri <Jerome.Haerri@eurecom.fr>, <ipwave-chairs@ietf.org>, Jerome Haerri <jerome.haerri@eurecom.fr>, N= abil Benamar <n.benamar@est.u= mi.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-46.txt
has been successfully submitted by Nabil Benamar and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-ipwave-ipv6-over-8= 0211ocb
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A046
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Basic support for IPv6 over IEEE S= td 802.11 Networks operating Outside the Context of a Basic Service Set (IP= v6-over-80211-OCB)
Document date:=C2=A0 2019-06-07
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ipwave
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 32
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ietf-i= pwave-ipv6-over-80211ocb-46.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80= 211ocb/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-46<= br> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-ov= er-80211ocb
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipwave-= ipv6-over-80211ocb-46

Abstract:
=C2=A0 =C2=A0This document provides methods and settings, and describes
=C2=A0 =C2=A0limitations, for using IPv6 to communicate among nodes in rang= e of
=C2=A0 =C2=A0one another over a single IEEE 802.11-OCB link with minimal ch= ange to
=C2=A0 =C2=A0existing stacks.=C2=A0 Optimizations and usage of IPv6 over mo= re complex
=C2=A0 =C2=A0scenarios is not covered and is subject of future work.




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

The IETF Secretariat



--

<= font color=3D"#0b5394" style=3D"font-size:12.8px">Best Regards

Nabil Benamar
<= div style=3D"font-size:12.8px">Associate Professor<= /font>
Departm= ent of Computer Sciences
School of Technology
Moulay Ismail=C2=A0University=C2=A0
Meknes. Morocco


--00000000000033eca1058abb1bf4-- From nobody Wed Jun 12 11:05:33 2019 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D248120075 for ; Wed, 12 Jun 2019 11:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2V72OTq--FJx for ; Wed, 12 Jun 2019 11:05:30 -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 5B44A120025 for ; Wed, 12 Jun 2019 11:05:30 -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 x5CI5SCP175389 for ; Wed, 12 Jun 2019 20:05:28 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 106952045CA for ; Wed, 12 Jun 2019 20:05:28 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 054982037EF for ; Wed, 12 Jun 2019 20:05:28 +0200 (CEST) Received: from [10.8.68.66] ([10.8.68.66]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x5CI5Rgd010862 for ; Wed, 12 Jun 2019 20:05:27 +0200 To: "its@ietf.org" From: Alexandre Petrescu Message-ID: <24309460-0172-60f1-f2e8-7cc57d152167@gmail.com> Date: Wed, 12 Jun 2019 20:05:27 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------FB2DB0FAB8B41B2AC62CAF7D" Content-Language: fr Archived-At: Subject: [ipwave] Higher bandwidth is a requirement, not a number to avoid X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: 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, 12 Jun 2019 18:05:33 -0000 This is a multi-part message in MIME format. --------------FB2DB0FAB8B41B2AC62CAF7D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi, With respect to the channel width 20MHz capability, which would probably offer higher bandwidth and less latency. I received in private several replies from at least 4 people.  I also had a face to face meeting with our partners. I want to say something so I am better understood: it is a _requirement_ to get higher bandwidth; it is not a number to avoid. If the app people send 10000 RTMAPS 1480byte sized IP messages per second then it is so because they need it.  Yes, that is 10KHz messages, and not 20Hz; yes, that is 1428byte IP message and not CAM/BSM 633byte.  And yes, that must be satisfied.  We should not tell these people to reduce their outputs.  Reducing their outputs will indeed guarantee better latency for ping, but they will be less able to transmit valuable data. We should not tell app people to throttle (reduce) their output down to 20 messages per second (20Hz).  That is nonsense out of standard documents.  The 20Hz/10Hz/1Hz is data relevant out of GPS chipsets - GPS has nothing to do with OCB. If in the first platooning tests it worked with less data transmitted, also the convoy was less performing.  We need rich data transmitted, not poor data.  We need lidar data out of the lidar directly on OCB, and similar other things. Alex --------------FB2DB0FAB8B41B2AC62CAF7D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi,

With respect to the channel width 20MHz capability, which would probably offer higher bandwidth and less latency.

I received in private several replies from at least 4 people.  I also had a face to face meeting with our partners.

I want to say something so I am better understood: it is a _requirement_ to get higher bandwidth; it is not a number to avoid.

If the app people send 10000 RTMAPS 1480byte sized IP messages per second then it is so because they need it.  Yes, that is 10KHz messages, and not 20Hz; yes, that is 1428byte IP message and not CAM/BSM 633byte.  And yes, that must be satisfied.  We should not tell these people to reduce their outputs.  Reducing their outputs will indeed guarantee better latency for ping, but they will be less able to transmit valuable data.

We should not tell app people to throttle (reduce) their output down to 20 messages per second (20Hz).  That is nonsense out of standard documents.  The 20Hz/10Hz/1Hz is data relevant out of GPS chipsets - GPS has nothing to do with OCB.

If in the first platooning tests it worked with less data transmitted, also the convoy was less performing.  We need rich data transmitted, not poor data.  We need lidar data out of the lidar directly on OCB, and similar other things.

Alex

--------------FB2DB0FAB8B41B2AC62CAF7D-- From nobody Wed Jun 12 12:16:39 2019 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 4806A1201C6; Wed, 12 Jun 2019 12:16:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Sender: CC: its@ietf.org, Carlos Bernardos , draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org, cjbc@it.uc3m.es, suresh@kaloom.com, ipwave-chairs@ietf.org Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <156036699018.14103.3418388853567464610.idtracker@ietfa.amsl.com> Date: Wed, 12 Jun 2019 12:16:30 -0700 Archived-At: Subject: [ipwave] Last Call: (Basic support for IPv6 over IEEE Std 802.11 Networks operating Outside the Context of a Basic Service Set (IPv6-over-80211-OCB)) to Proposed Standard X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 List-Id: 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, 12 Jun 2019 19:16:31 -0000 The IESG has received a request from the IP Wireless Access in Vehicular Environments WG (ipwave) to consider the following document: - 'Basic support for IPv6 over IEEE Std 802.11 Networks operating Outside the Context of a Basic Service Set (IPv6-over-80211-OCB)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-06-26. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document provides methods and settings, and describes limitations, for using IPv6 to communicate among nodes in range of one another over a single IEEE 802.11-OCB link with minimal change to existing stacks. Optimizations and usage of IPv6 over more complex scenarios is not covered and is subject of future work. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc3753: Mobility Related Terminology (Informational - IETF stream) rfc7721: Security and Privacy Considerations for IPv6 Address Generation Mechanisms (Informational - IETF stream) rfc5889: IP Addressing Model in Ad Hoc Networks (Informational - IETF stream) rfc6959: Source Address Validation Improvement (SAVI) Threat Scope (Informational - IETF stream) From nobody Thu Jun 13 02:00:33 2019 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB19A12028F for ; Thu, 13 Jun 2019 02:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.909 X-Spam-Level: X-Spam-Status: No, score=-0.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 rfEoRz1VODZS for ; Thu, 13 Jun 2019 02:00:28 -0700 (PDT) Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210]) by ietfa.amsl.com (Postfix) with ESMTP id C4E1812028C for ; Thu, 13 Jun 2019 02:00:26 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.63,369,1557180000"; d="scan'208,217"; a="10364037" Received: from monza.eurecom.fr ([192.168.106.15]) by drago1i.eurecom.fr with ESMTP; 13 Jun 2019 11:00:24 +0200 Received: from xerus29 (xerus29.eurecom.fr [172.17.31.38]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by monza.eurecom.fr (Postfix) with ESMTPSA id B0C5D372A; Thu, 13 Jun 2019 11:00:24 +0200 (CEST) From: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= To: "'Alexandre Petrescu'" , References: <24309460-0172-60f1-f2e8-7cc57d152167@gmail.com> In-Reply-To: <24309460-0172-60f1-f2e8-7cc57d152167@gmail.com> Date: Thu, 13 Jun 2019 11:00:24 +0200 Organization: EURECOM Message-ID: <00b601d521c6$7038a7a0$50a9f6e0$@eurecom.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B7_01D521D7.33C3E8A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF+1vl0RfDsEMZ1Vzq2OEkJOQ5i2KdF0lOw Content-Language: en-us Archived-At: Subject: Re: [ipwave] Higher bandwidth is a requirement, not a number to avoid X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: 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, 13 Jun 2019 09:00:32 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00B7_01D521D7.33C3E8A0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Alex, =20 You are totally right=E2=80=A6applications have increased needs and it = is not the right wat to tell an application to send less because of = finite capacity of a given technology. One thing to keep in mind though = is that the ITS-G5/DSRC has been designed for the needs of so called = =E2=80=98day one=E2=80=99 applications (e.g. intersection collision = avoidance, lane change warning etc..) and it is quite clear that the = technology is not adapted to other applications, which would require = more capacity (say it is not the fault of the technology, as it has been = designed for something and not for something else).=20 =20 The applications you are working on fall within the =E2=80=98Day = two=E2=80=99 or =E2=80=98Day two and half=E2=80=99 (sorry, I am not the = one giving these names=E2=80=A6just referring to them..) and for these = new applications there is absolutely a need for more capacity. In short, = we need to find better and more efficient ways to transmit much more = data for ITS applications, and indeed not say that people should = transmit less J =20 And this is very clear in ETSI, C2C-CC, SAE, even 5GAA=E2=80=A6there are = specific WG discussing new spectrum usage (10Mhz vs. 20Mhz, = multi-channels, etc..) and the current direction to fulfill the capacity = requirements of these news applications are either IEEE 802.11bd (the = next generation wifi-based V2X) or 5G-V2X (the next generation C-V2X = technology), as frequency rechannelization is complex in terms of = coexistence and using multi-channels require multi transmitters=E2=80=A6 =20 In this perspective, your proposed modification might be seen as a = temporary patch but if it works for your case, that is good, as there is = nothing else available at that time=E2=80=A6And if you propose a simpler = way of getting more capacity to match day two applications with day one = technology, well this is what I would call research J=E2=80=A6 =20 The point in my previous e-mail was that putting 20MHz in = =E2=80=98iw=E2=80=99 on an ocb firmware will change a few things at the = physical layers that will affect the performance (in good or bad) of = your system..for instance, the OFDM guard period will be halved, which = will make your link more sensitive to delay long spreads, or will lose = 3dB in receiver sensitivity, which would impact your Tx range. As I said = in my previous e-mails, there are various teams that have been = questioning the 10Mhz channel since a =E2=80=98very=E2=80=99 long time = now=E2=80=A6so, there is no scientific reasons for not trying at 20Mhz = and see how it goes=E2=80=A6yet, it will not be compatible with the = current standards/regulations at that time=E2=80=A6(but does not mean it = would not change in the future J) =20 Please have a look at some of the work from Prof. Eric Str=C3=B6m of = Chalmers (a nice summary is available here: = https://pdfs.semanticscholar.org/78ef/e53d238ae75837f5817997f27c74f151969= 8.pdf). In short, there are clearly performance gains in = perspective=E2=80=A6but it =E2=80=98really=E2=80=99 depends on some = parameters of the channel that you will face during your tests. The most = important one is the delay spread. Eric mentions that a 4nSec is usually = agreed, but there are other studies indicating delay spreads up to 8nsec = (also acknowledged by Eric)=E2=80=A6so, it would simply be interesting = to test and see how it works in your case=E2=80=A6it would be good if = you could have in your team or project partners expect in PHY/Channel = sounding to double check the PHY impact of your strategy in your = environment=E2=80=A6=20 =20 To conclude, although not fitting to current spectrum regulations, = trying 20Mhz is good as it gets and there are many people believing that = this could actually help=E2=80=A6but it might not be sufficient for your = applications (you might not double capacity by doubling the = bandwidth)=E2=80=A6There will be much more benefits from the next = generation V2X technologies in the very near future (also indicated by = Eric in its slides, page 24) , which will fulfill your required = performance=E2=80=A6that is why I mentioned that for your required = applications, you should follow what IEEE 802.11bd or 5G-V2X will are = actively being developed as we speak. =20 Best Regards, =20 J=C3=A9r=C3=B4me =20 =20 From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu Sent: Wednesday 12 June 2019 20:05 To: its@ietf.org Subject: [ipwave] Higher bandwidth is a requirement, not a number to = avoid =20 Hi, With respect to the channel width 20MHz capability, which would probably = offer higher bandwidth and less latency. I received in private several replies from at least 4 people. I also = had a face to face meeting with our partners. I want to say something so I am better understood: it is a _requirement_ = to get higher bandwidth; it is not a number to avoid. If the app people send 10000 RTMAPS 1480byte sized IP messages per = second then it is so because they need it. Yes, that is 10KHz messages, = and not 20Hz; yes, that is 1428byte IP message and not CAM/BSM 633byte. = And yes, that must be satisfied. We should not tell these people to = reduce their outputs. Reducing their outputs will indeed guarantee = better latency for ping, but they will be less able to transmit valuable = data. We should not tell app people to throttle (reduce) their output down to = 20 messages per second (20Hz). That is nonsense out of standard = documents. The 20Hz/10Hz/1Hz is data relevant out of GPS chipsets - GPS = has nothing to do with OCB.=20 If in the first platooning tests it worked with less data transmitted, = also the convoy was less performing. We need rich data transmitted, not = poor data. We need lidar data out of the lidar directly on OCB, and = similar other things. Alex ------=_NextPart_000_00B7_01D521D7.33C3E8A0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Dear Alex,

 

You are totally right=E2=80=A6applications have increased needs and = it is not the right wat to tell an application to send less because of = finite capacity of a given technology. One thing to keep in mind though = is that the ITS-G5/DSRC has been designed for the needs of so called = =E2=80=98day one=E2=80=99 applications (e.g. intersection collision = avoidance, lane change warning etc..) and it is quite clear that the = technology is not adapted to other applications, which would require = more capacity (say it is not the fault of the technology, as it has been = designed for something and not for something else). =

 

The applications you are working on fall within the =E2=80=98Day = two=E2=80=99 or =E2=80=98Day two and half=E2=80=99=C2=A0 (sorry, I am = not the one giving these names=E2=80=A6just referring to them..) and for = these new applications there is absolutely a need for more capacity. In = short, we need to find better and more efficient ways to transmit much = more data for ITS applications, and indeed not say that people should = transmit less J

 

And this is very clear in ETSI, C2C-CC, SAE, even 5GAA=E2=80=A6there = are specific WG discussing new spectrum usage (10Mhz vs. 20Mhz, = multi-channels, etc..) and the current direction to fulfill the capacity = requirements of these news applications are either IEEE 802.11bd (the = next generation wifi-based V2X) or 5G-V2X (the next generation C-V2X = technology), as frequency rechannelization is complex in terms of = coexistence and using multi-channels require multi = transmitters=E2=80=A6

 

In this perspective, your proposed modification might be seen as a = temporary patch but if it works for your case, that is good, as there is = nothing else available at that time=E2=80=A6And if you propose a simpler = way of getting more capacity to match day two applications with day one = technology, well this is what I would call research J=E2=80=A6

 

The point in my previous e-mail was that putting 20MHz in = =E2=80=98iw=E2=80=99 on an ocb firmware will change a few things at the = physical layers that will affect the performance (in good or bad) of = your system..for instance, the OFDM guard period will be halved, which = will make your link more sensitive to delay long spreads, or will lose = 3dB in receiver sensitivity, which would impact your Tx range. As I said = in my previous e-mails, there are various teams that have been = questioning the 10Mhz channel since a =E2=80=98very=E2=80=99 long time = now=E2=80=A6so, there is no scientific reasons for not trying at 20Mhz = and see how it goes=E2=80=A6yet, it will not be compatible with the = current standards/regulations at that time=E2=80=A6(but does not mean it = would not change in the future J)

 

Please have a look at some of the work from Prof. Eric Str=C3=B6m of = Chalmers (a nice summary is available here: https://pdfs.semanticscholar.org/78ef/e53d238ae75837f58179= 97f27c74f1519698.pdf). =C2=A0In short, there are clearly performance = gains in perspective=E2=80=A6but it =E2=80=98really=E2=80=99 depends on = some parameters of the channel that you will face during your tests. The = most important one is the delay spread. Eric mentions that a 4nSec is = usually agreed, but there are other studies indicating delay spreads up = to 8nsec (also acknowledged by Eric)=E2=80=A6so, it would simply be = interesting to test and see how it works in your case=E2=80=A6it would = be good if you could have in your team or project partners expect in = PHY/Channel sounding to double check the PHY impact of your strategy in = your environment=E2=80=A6

 

To conclude, although not fitting to current spectrum regulations, = trying 20Mhz is good as it gets and there are many people believing that = this could actually help=E2=80=A6but it might not be sufficient for your = applications (you might not double capacity by doubling the = bandwidth)=E2=80=A6There will be much more benefits from the next = generation V2X technologies in the very near future (also indicated by = Eric in its slides, page 24) , which will fulfill your required = performance=E2=80=A6that is why I mentioned that for your required = applications, you should follow what IEEE 802.11bd or 5G-V2X will are = actively being developed as we speak.

 

Best Regards,

 

J=C3=A9r=C3=B4me =C2=A0

 

From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre = Petrescu
Sent: Wednesday 12 June 2019 20:05
To: = its@ietf.org
Subject: [ipwave] Higher bandwidth is a = requirement, not a number to avoid

 

Hi,

With respect to the = channel width 20MHz capability, which would probably offer higher = bandwidth and less latency.

I received in = private several replies from at least 4 people.  I also had a face = to face meeting with our partners.

I want to say = something so I am better understood: it is a _requirement_ to get higher = bandwidth; it is not a number to avoid.

If the app people = send 10000 RTMAPS 1480byte sized IP messages per second then it is so = because they need it.  Yes, that is 10KHz messages, and not 20Hz; = yes, that is 1428byte IP message and not CAM/BSM 633byte.  And yes, = that must be satisfied.  We should not tell these people to reduce = their outputs.  Reducing their outputs will indeed guarantee better = latency for ping, but they will be less able to transmit valuable = data.

We should not tell = app people to throttle (reduce) their output down to 20 messages per = second (20Hz).  That is nonsense out of standard documents.  = The 20Hz/10Hz/1Hz is data relevant out of GPS chipsets - GPS has nothing = to do with OCB.

If in the first = platooning tests it worked with less data transmitted, also the convoy = was less performing.  We need rich data transmitted, not poor = data.  We need lidar data out of the lidar directly on OCB, and = similar other things.

Alex

------=_NextPart_000_00B7_01D521D7.33C3E8A0-- From nobody Thu Jun 13 11:51:08 2019 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB5FC1201F8; Thu, 13 Jun 2019 11:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 B5ZCywjhDWO1; Thu, 13 Jun 2019 11:50:54 -0700 (PDT) Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com [209.85.128.42]) (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 E0E2E12010C; Thu, 13 Jun 2019 11:50:50 -0700 (PDT) Received: by mail-wm1-f42.google.com with SMTP id 22so11190848wmg.2; Thu, 13 Jun 2019 11:50:50 -0700 (PDT) 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=F6iwU148sdvBbz2jmKhh30S694qhtXvsSIlnBH9YBTw=; b=NvX8XcrLrSDBk8mJVKvr8ua1YoIW5+VJGEP9Tp/+94yMkLi5Pu93Z+9DMZYQSNy25d JiEnICxNpldNBE1FSQnFTyL2gIXKSIgpysYVjA3MXNln5oNNAtOD0UJOacy/u/wFxzkp da3ZbpNx0ZQ2+XAO6IGKuxamKlqfcBjXZa7aJXSGUWrOu00gLkBcJY2FnECL4dhvDq11 bNe6EsR14FspmiYd/QQ+vqbnNdtSx8PFBNFugNvIf/cnC9U5h4ND4mFOURmKx2fr+lFY eNq0FrIGsVEfMRpfqnR4/fyDqrcVuN7FNzoPPE5nls/Vnkgrh8mr+/wzFXuj09hJtTum 57JA== X-Gm-Message-State: APjAAAVcISxBiDiK6szdjkzgaC1rfNCipsIj9S38MlDPxvEnfq5TRyN6 6TxJtHO6KO/g1X/NHvhmpwz2/rk7tEIguTNzYoLc7ma7 X-Google-Smtp-Source: APXvYqx8Md5gJzKR3jmz2eJjM9k1+lirZiALL7vPUfvmXKY5U54mnuOQYR72CuX1tNJJNx2jfdZODOtFpLRMtGbkd78= X-Received: by 2002:a1c:9a05:: with SMTP id c5mr4549011wme.36.1560451848662; Thu, 13 Jun 2019 11:50:48 -0700 (PDT) MIME-Version: 1.0 References: <156036699018.14103.3418388853567464610.idtracker@ietfa.amsl.com> In-Reply-To: <156036699018.14103.3418388853567464610.idtracker@ietfa.amsl.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Thu, 13 Jun 2019 11:50:37 -0700 Message-ID: To: IETF Discussion Cc: draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org, ipwave-chairs@ietf.org, =?UTF-8?Q?Carlos_Jes=C3=BAs_Bernardos_Cano?= , its@ietf.org, suresh@kaloom.com Content-Type: multipart/alternative; boundary="00000000000020f8c8058b390242" Archived-At: Subject: Re: [ipwave] Last Call: (Basic support for IPv6 over IEEE Std 802.11 Networks operating Outside the Context of a Basic Service Set (IPv6-over-80211-OCB)) to Proposed Standard X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: 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, 13 Jun 2019 18:50:57 -0000 --00000000000020f8c8058b390242 Content-Type: text/plain; charset="UTF-8" On Wed, Jun 12, 2019 at 12:16 PM The IESG wrote: > The IESG has received a request from the IP Wireless Access in > Vehicular Environments WG (ipwave) to consider the following > document: - 'Basic support for IPv6 over IEEE Std 802.11 Networks > operating Outside the Context of a Basic Service Set > (IPv6-over-80211-OCB)' > as Proposed Standard > The IESG plans to make a decision in the next few weeks, and > solicits final comments on this action. Please send substantive > comments to the ietf@ietf.org mailing lists by 2019-06-26. Version 46 of this draft doesn't seem to specify the exact length of the interface identifier. RFC4862 expects it to be specified in this kind of "link-type specific document": interface identifier - [...] The exact length of an interface identifier and the way it is created is defined in a separate link-type specific document that covers issues related to the transmission of IP over a particular link type (e.g., [RFC2464]). Note that the address architecture [RFC4291] also defines the length of the interface identifiers for some set of addresses, but the two sets of definitions must be consistent. Specifying the length is critical since (for example) otherwise an implementation can't perform the validation described in Section 5.5.3 of RFC4862. I suggest Section 4.4 (and probably also 4.3 for link-local) of this draft explicitly specifies the length of the interface identifier. And then I'd note that the length can (in practice) only be 64 bits because of the assumption about the consistency with the address architecture (the "Note that..." part of the above citation) and because of the fact that the current address architecture states the length is 64 bits for link-local and practically all global IPv6 addresses in use. I'm aware of the (in)famous tussle on the use of the fixed value of 64, but I'm not making this comment for advocating for the fixed value; I'm just pointing out a logical consequence of the assumption of the current SLAAC standard and the constants used in the current standards. -- JINMEI, Tatuya On Wed, Jun 12, 2019 at 12:16 PM The IESG wrote: > > The IESG has received a request from the IP Wireless Access in Vehicular > Environments WG (ipwave) to consider the following document: - 'Basic > support > for IPv6 over IEEE Std 802.11 Networks operating Outside > the Context of a Basic Service Set (IPv6-over-80211-OCB)' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2019-06-26. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of > the Subject line to allow automated sorting. > > Abstract > > > This document provides methods and settings, and describes > limitations, for using IPv6 to communicate among nodes in range of > one another over a single IEEE 802.11-OCB link with minimal change to > existing stacks. Optimizations and usage of IPv6 over more complex > scenarios is not covered and is subject of future work. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ > > IESG discussion can be tracked via > > https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > The document contains these normative downward references. > See RFC 3967 for additional information: > rfc3753: Mobility Related Terminology (Informational - IETF stream) > rfc7721: Security and Privacy Considerations for IPv6 Address > Generation Mechanisms (Informational - IETF stream) > rfc5889: IP Addressing Model in Ad Hoc Networks (Informational - IETF > stream) > rfc6959: Source Address Validation Improvement (SAVI) Threat Scope > (Informational - IETF stream) > > > > > --00000000000020f8c8058b390242 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jun 12, 2019 at 12:16 PM The IESG <iesg-secretary@ietf.org> wrote:
> The IESG has received a request from the IP Wireless Access in
&g= t; Vehicular Environments WG (ipwave) to consider the following
> doc= ument: - 'Basic support for IPv6 over IEEE Std 802.11 Networks
> = operating Outside the Context of a Basic Service Set
> (IPv6-over-802= 11-OCB)' <draft-ietf-ipwave-ipv6-over-80211ocb-46.txt>
> as= Proposed Standard

> The IESG plans to make a decision in the nex= t few weeks, and
> solicits final comments on this action. Please sen= d substantive
> comments to the ietf= @ietf.org mailing lists by 2019-06-26.

Version 46 of this draft = doesn't seem to specify the exact length
of the interface identifier= .=C2=A0 RFC4862 expects it to be specified in
this kind of "link-ty= pe specific document":

=C2=A0 =C2=A0interface identifier - [...= ] The
=C2=A0 =C2=A0 =C2=A0 exact length of an interface identifier and t= he way it is created
=C2=A0 =C2=A0 =C2=A0 is defined in a separate link-= type specific document that covers
=C2=A0 =C2=A0 =C2=A0 issues related t= o the transmission of IP over a particular link
=C2=A0 =C2=A0 =C2=A0 typ= e (e.g., [RFC2464]).=C2=A0 Note that the address architecture
=C2=A0 =C2= =A0 =C2=A0 [RFC4291] also defines the length of the interface identifiers f= or
=C2=A0 =C2=A0 =C2=A0 some set of addresses, but the two sets of defin= itions must be
=C2=A0 =C2=A0 =C2=A0 consistent.

Specifying the le= ngth is critical since (for example) otherwise an
implementation can'= ;t perform the validation described in Section 5.5.3 of
RFC4862.

= I suggest Section 4.4 (and probably also 4.3 for link-local) of this
dra= ft explicitly specifies the length of the interface identifier.
And then= I'd note that the length can (in practice) only be 64 bits
because = of the assumption about the consistency with the address
architecture (t= he "Note that..." part of the above citation) and
because of t= he fact that the current address architecture states the
length is 64 bi= ts for link-local and practically all global IPv6
addresses in use.=C2= =A0 I'm aware of the (in)famous tussle on the use of
the fixed value= of 64, but I'm not making this comment for advocating
for the fixed= value; I'm just pointing out a logical consequence of
the assumptio= n of the current SLAAC standard and the constants used in
the current st= andards.

--
JINMEI, Tatuya

On Wed, Jun 12, 2019 at 12:16 PM The IE= SG <iesg-secretary@ietf.org> wrote:
The IESG has received a request from the IP Wireless Access in Vehicular Environments WG (ipwave) to consider the following document: - 'Basic s= upport
for IPv6 over IEEE Std 802.11 Networks operating Outside
=C2=A0 =C2=A0the Context of a Basic Service Set (IPv6-over-80211-OCB)'<= br> =C2=A0 <draft-ietf-ipwave-ipv6-over-80211ocb-46.txt> as Proposed Stan= dard

The IESG plans to make a decision in the next few weeks, and solicits final=
comments on this action. Please send substantive comments to the
ietf@ietf.org mailin= g lists by 2019-06-26. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


=C2=A0 =C2=A0This document provides methods and settings, and describes
=C2=A0 =C2=A0limitations, for using IPv6 to communicate among nodes in rang= e of
=C2=A0 =C2=A0one another over a single IEEE 802.11-OCB link with minimal ch= ange to
=C2=A0 =C2=A0existing stacks.=C2=A0 Optimizations and usage of IPv6 over mo= re complex
=C2=A0 =C2=A0scenarios is not covered and is subject of future work.




The file can be obtained via
https://datatracker.ietf.org/d= oc/draft-ietf-ipwave-ipv6-over-80211ocb/

IESG discussion can be tracked via
https://datatracker.iet= f.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
=C2=A0 =C2=A0 rfc3753: Mobility Related Terminology (Informational - IETF s= tream)
=C2=A0 =C2=A0 rfc7721: Security and Privacy Considerations for IPv6 Address= Generation Mechanisms (Informational - IETF stream)
=C2=A0 =C2=A0 rfc5889: IP Addressing Model in Ad Hoc Networks (Informationa= l - IETF stream)
=C2=A0 =C2=A0 rfc6959: Source Address Validation Improvement (SAVI) Threat = Scope (Informational - IETF stream)




--00000000000020f8c8058b390242-- From nobody Thu Jun 13 19:25:41 2019 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8819120075; Thu, 13 Jun 2019 19:25:31 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 XdCabrTjmmP6; Thu, 13 Jun 2019 19:25:29 -0700 (PDT) Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (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 9CA761200F9; Thu, 13 Jun 2019 19:25:29 -0700 (PDT) Received: by mail-pf1-x42e.google.com with SMTP id d126so436581pfd.2; Thu, 13 Jun 2019 19:25:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ZjjgvGA1pIQtujssOVf205y6JVNnufQ/o4u7jMhP07s=; b=rw13ojtXNMfPlBaDQnr81f5CwqAkV7JkcRYf3fIPfbfZb2Av2EBJlVLGTdbK2wYEhA bD6t+JEX6M04YQTe4biy3hWnj0id3PbGG+mLOoL58oIDeJjYCaMvCuh8ZQwAL6y9IZJH WK2ElOwgnqJIGUYmb+f1zwwhE7xAVVkM7FAvUhOs/gDvSFKgq+UXlyBqAYEvt693nZHc BBI4pRy3q00AdYiaU8UganSDvcOOOlniW9IdlW7Rf6fsmr9q8ETxU7BZL8m7jLIy5tNH YIBWTwtSkJtLebtsmt6f7Jyf4ArkpUVfsE5NwaG67I9MUCj37rpBefP2mPESoJE6owax F0tQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ZjjgvGA1pIQtujssOVf205y6JVNnufQ/o4u7jMhP07s=; b=FUdWwjRmoZKiFLljsSUL2XrTU+IVmlccFBUQLZZIEHotgoPJLDjlPwO5G/q+/QeCH9 ktoATDRqEZpO18D8EZDFzS/ErzxYw4NYyEUZJqUFE2VUMduqe45Ix379t0DDUX6DDsQo 62MLY+VbD5k2dhqPEtyDTldMS879TgaA/ipuZtj43aWEwf9ZVrBEAIdu4s+QaMt0C/eo 3Kj3zA1zWln/6hxvShkv7aOEqUQE9Nccikqdg6yq7yDubeNov1Y4ZY9FOD0D69LhcXzM lFMQXJ+UMYMuA+GUMuZgPR7AAW3GW//lDjXtKk3Rvb0JEs4x48z0HWRUC0CmwB/TbfZt pPJA== X-Gm-Message-State: APjAAAXg9hXHYBzJe9UAA2wmWVBsApb/aeGplFqAplLVv89/Xeza0AB6 uVe2XWwc6v2xupaAlVxwBOC5XZ4D X-Google-Smtp-Source: APXvYqyObj6WOoETMN6H5NZytk7vn6BU56lfNgdVhz1AjEdM2LSv3kRGUBblyNVi8HBWCP0pdXph3A== X-Received: by 2002:a62:6143:: with SMTP id v64mr59402002pfb.42.1560479128844; Thu, 13 Jun 2019 19:25:28 -0700 (PDT) Received: from [192.168.178.30] (32.23.255.123.dynamic.snap.net.nz. [123.255.23.32]) by smtp.gmail.com with ESMTPSA id x7sm944577pfm.82.2019.06.13.19.25.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Jun 2019 19:25:28 -0700 (PDT) To: =?UTF-8?B?56We5piO6YGU5ZOJ?= , IETF Discussion Cc: draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org, suresh@kaloom.com, its@ietf.org, ipwave-chairs@ietf.org References: <156036699018.14103.3418388853567464610.idtracker@ietfa.amsl.com> From: Brian E Carpenter Message-ID: Date: Fri, 14 Jun 2019 14:25:23 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [ipwave] Last Call: (Basic support for IPv6 over IEEE Std 802.11 Networks operating Outside the Context of a Basic Service Set (IPv6-over-80211-OCB)) to Proposed Standard X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: 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, 14 Jun 2019 02:25:32 -0000 I fully agree with Jinmei-san's comment. Regards Brian Carpenter On 14-Jun-19 06:50, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > On Wed, Jun 12, 2019 at 12:16 PM The IESG > wrote: >=20 >> The IESG has received a request from the IP Wireless Access in >> Vehicular Environments WG (ipwave) to consider the following >> document: - 'Basic support for IPv6 over IEEE Std 802.11 Networks >> operating Outside the Context of a Basic Service Set >> (IPv6-over-80211-OCB)' >> as Proposed Standard >=20 >> The IESG plans to make a decision in the next few weeks, and >> solicits final comments on this action. Please send substantive >> comments to the ietf@ietf.org mailing lists by = 2019-06-26. >=20 > Version 46 of this draft doesn't seem to specify the exact length > of the interface identifier..=C2=A0 RFC4862 expects it to be specified = in > this kind of "link-type specific document": >=20 > =C2=A0 =C2=A0interface identifier - [...] The > =C2=A0 =C2=A0 =C2=A0 exact length of an interface identifier and the wa= y it is created > =C2=A0 =C2=A0 =C2=A0 is defined in a separate link-type specific docume= nt that covers > =C2=A0 =C2=A0 =C2=A0 issues related to the transmission of IP over a pa= rticular link > =C2=A0 =C2=A0 =C2=A0 type (e.g., [RFC2464]).=C2=A0 Note that the addres= s architecture > =C2=A0 =C2=A0 =C2=A0 [RFC4291] also defines the length of the interface= identifiers for > =C2=A0 =C2=A0 =C2=A0 some set of addresses, but the two sets of definit= ions must be > =C2=A0 =C2=A0 =C2=A0 consistent. >=20 > Specifying the length is critical since (for example) otherwise an > implementation can't perform the validation described in Section 5.5.3 = of > RFC4862. >=20 > I suggest Section 4.4 (and probably also 4.3 for link-local) of this > draft explicitly specifies the length of the interface identifier. > And then I'd note that the length can (in practice) only be 64 bits > because of the assumption about the consistency with the address > architecture (the "Note that..." part of the above citation) and > because of the fact that the current address architecture states the > length is 64 bits for link-local and practically all global IPv6 > addresses in use.=C2=A0 I'm aware of the (in)famous tussle on the use o= f > the fixed value of 64, but I'm not making this comment for advocating > for the fixed value; I'm just pointing out a logical consequence of > the assumption of the current SLAAC standard and the constants used in > the current standards. >=20 > -- > JINMEI, Tatuya >=20 > On Wed, Jun 12, 2019 at 12:16 PM The IESG > wrote: >=20 >=20 > The IESG has received a request from the IP Wireless Access in Vehi= cular > Environments WG (ipwave) to consider the following document: - 'Bas= ic support > for IPv6 over IEEE Std 802.11 Networks operating Outside > =C2=A0 =C2=A0the Context of a Basic Service Set (IPv6-over-80211-OC= B)' > =C2=A0 as Proposed St= andard >=20 > The IESG plans to make a decision in the next few weeks, and solici= ts final > comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2019-06-26. E= xceptionally, comments may be > sent to iesg@ietf.org instead. In either cas= e, please retain the beginning of > the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > =C2=A0 =C2=A0This document provides methods and settings, and descr= ibes > =C2=A0 =C2=A0limitations, for using IPv6 to communicate among nodes= in range of > =C2=A0 =C2=A0one another over a single IEEE 802.11-OCB link with mi= nimal change to > =C2=A0 =C2=A0existing stacks.=C2=A0 Optimizations and usage of IPv6= over more complex > =C2=A0 =C2=A0scenarios is not covered and is subject of future work= =2E >=20 >=20 >=20 >=20 > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211o= cb/ >=20 > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211o= cb/ballot/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 >=20 > The document contains these normative downward references. > See RFC 3967 for additional information: > =C2=A0 =C2=A0 rfc3753: Mobility Related Terminology (Informational = - IETF stream) > =C2=A0 =C2=A0 rfc7721: Security and Privacy Considerations for IPv6= Address Generation Mechanisms (Informational - IETF stream) > =C2=A0 =C2=A0 rfc5889: IP Addressing Model in Ad Hoc Networks (Info= rmational - IETF stream) > =C2=A0 =C2=A0 rfc6959: Source Address Validation Improvement (SAVI)= Threat Scope (Informational - IETF stream) >=20 >=20 >=20 >=20 From nobody Fri Jun 14 11:13:52 2019 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B090412019B for ; Fri, 14 Jun 2019 11:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=est-umi-ac-ma.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 Pm5eBswLFN-e for ; Fri, 14 Jun 2019 11:13:47 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 5D6CA120127 for ; Fri, 14 Jun 2019 11:13:46 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id u19so7691186ior.9 for ; Fri, 14 Jun 2019 11:13:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=est-umi-ac-ma.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4W+QLBOPgtrYAdSJdZCHEiiHrP8x1Pf57nr+GkgOPUY=; b=rOv3lS98GCfUY5wqhXNMU9a5ZyCzmb7m1Gnh5AOIIVSHn+l1VtqFOEsLcl/vHMwQe1 mjRxU6+ASRz2HYxbsmZDM5FC+GtfGMkAqraI6PeWrPa/e+LdRyTr0F0qlwb1L6931s+M jCRUQEZ+VEeI7e/tTzjAH1MEPOKZ8AiLFLvTol+5NpGf6+RbbltF05xKkpIo1i/Af58p KDVpQIJuPwn7aF8QESHNAA+vWCzondUHUosKaOK68rktRIb6P1B0KehqdBnHb+/yvoHb lMY5Xseoh/w8eqBqa2yaWyrPb54ROTHU+mKFUTz91QBdliPOlsgjywp0ihe5RaMpKUxW ZUEg== 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=4W+QLBOPgtrYAdSJdZCHEiiHrP8x1Pf57nr+GkgOPUY=; b=GFFYJC0QYTawqy5V7lLoXCrN+F9JtS4M8qjU26SKt25CrpY0StKmBE3r1NzZ1MSlmL CCMiMNnow1d2YWvQmgrZdy07yKrrQ+odAvET83j8EUHsVqfyftUcHMvJ7fgMHvIpZBhr aPaFgNTD/W19GI7IqieV9ncjN4M2dyo3F+vt7/OnHppy6SM0mpm+z/35KG0EH5INfGxt RztUgH0EJD0GZcIfW67By4DGZFBobXwYN0L5rZWU3XXPVe5S777uvXwCaAm4t5YBW+kR SOY3/Q00fEwFcY9TRXkdtxzBFmPkw0bsTc1I3pi1ClHvpOamS2Q0qFqaV3oMYXnYwOEr exyg== X-Gm-Message-State: APjAAAUA35ePuFxaPrZJLYl2OLLGiCYhaYsHLspoCspbSSUltr4RPXpv 6uvviZSnZP2tAfOrKnrAh4AbyqleU6WKz1HEmMHQPQ== X-Google-Smtp-Source: APXvYqw+1HmtxhXHUmPCEfPTTY+ful6SFlSaFzsi8WWiY/bM6iOjVFYGqxJILiIoIZh2EWEPF8TnKPD0eytKgpTbM9E= X-Received: by 2002:a05:6638:149:: with SMTP id y9mr42956529jao.76.1560536025986; Fri, 14 Jun 2019 11:13:45 -0700 (PDT) MIME-Version: 1.0 References: <156036699018.14103.3418388853567464610.idtracker@ietfa.amsl.com> In-Reply-To: From: NABIL BENAMAR Date: Fri, 14 Jun 2019 19:13:34 +0100 Message-ID: To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Cc: IETF Discussion , draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org, ipwave-chairs@ietf.org, =?UTF-8?Q?Carlos_Jes=C3=BAs_Bernardos_Cano?= , its@ietf.org, Suresh Krishnan Content-Type: multipart/alternative; boundary="0000000000007d0cf2058b4c9ba8" Archived-At: Subject: Re: [ipwave] Last Call: (Basic support for IPv6 over IEEE Std 802.11 Networks operating Outside the Context of a Basic Service Set (IPv6-over-80211-OCB)) to Proposed Standard X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: 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, 14 Jun 2019 18:13:51 -0000 --0000000000007d0cf2058b4c9ba8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jinmei, Thank you for your comment. What do you think of the following changes: OLD In the Introduction =E2=80=9C "....The resulting stack operates over 802.11-OCB and provides at least P2P connectivity using IPv6 ND and link-local addresses." =E2=80=9C NEW =E2=80=9C "......The resulting stack inherits from IPv6 over Ethernet [RFC 2464] and operates over 802.11-OCB providing at least P2P connectivity using IPv6 ND and link-local address= es. In section 4.3 I will add the following sentence The best practices for forming IPv6 addresses are inherited from Ethernet. In particular, the IID is 64 bits long [RFC2464 ]. On Thu, Jun 13, 2019 at 7:50 PM =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > On Wed, Jun 12, 2019 at 12:16 PM The IESG wrote= : > > > The IESG has received a request from the IP Wireless Access in > > Vehicular Environments WG (ipwave) to consider the following > > document: - 'Basic support for IPv6 over IEEE Std 802.11 Networks > > operating Outside the Context of a Basic Service Set > > (IPv6-over-80211-OCB)' > > as Proposed Standard > > > The IESG plans to make a decision in the next few weeks, and > > solicits final comments on this action. Please send substantive > > comments to the ietf@ietf.org mailing lists by 2019-06-26. > > Version 46 of this draft doesn't seem to specify the exact length > of the interface identifier. RFC4862 expects it to be specified in > this kind of "link-type specific document": > > interface identifier - [...] The > exact length of an interface identifier and the way it is created > is defined in a separate link-type specific document that covers > issues related to the transmission of IP over a particular link > type (e.g., [RFC2464]). Note that the address architecture > [RFC4291] also defines the length of the interface identifiers for > some set of addresses, but the two sets of definitions must be > consistent. > > Specifying the length is critical since (for example) otherwise an > implementation can't perform the validation described in Section 5.5.3 of > RFC4862. > > I suggest Section 4.4 (and probably also 4.3 for link-local) of this > draft explicitly specifies the length of the interface identifier. > And then I'd note that the length can (in practice) only be 64 bits > because of the assumption about the consistency with the address > architecture (the "Note that..." part of the above citation) and > because of the fact that the current address architecture states the > length is 64 bits for link-local and practically all global IPv6 > addresses in use. I'm aware of the (in)famous tussle on the use of > the fixed value of 64, but I'm not making this comment for advocating > for the fixed value; I'm just pointing out a logical consequence of > the assumption of the current SLAAC standard and the constants used in > the current standards. > > -- > JINMEI, Tatuya > > On Wed, Jun 12, 2019 at 12:16 PM The IESG wrote= : > >> >> The IESG has received a request from the IP Wireless Access in Vehicular >> Environments WG (ipwave) to consider the following document: - 'Basic >> support >> for IPv6 over IEEE Std 802.11 Networks operating Outside >> the Context of a Basic Service Set (IPv6-over-80211-OCB)' >> as Proposed Standard >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final >> comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2019-06-26. Exceptionally, comments may b= e >> sent to iesg@ietf.org instead. In either case, please retain the >> beginning of >> the Subject line to allow automated sorting. >> >> Abstract >> >> >> This document provides methods and settings, and describes >> limitations, for using IPv6 to communicate among nodes in range of >> one another over a single IEEE 802.11-OCB link with minimal change to >> existing stacks. Optimizations and usage of IPv6 over more complex >> scenarios is not covered and is subject of future work. >> >> >> >> >> The file can be obtained via >> https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ >> >> IESG discussion can be tracked via >> >> https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ba= llot/ >> >> >> No IPR declarations have been submitted directly on this I-D. >> >> >> The document contains these normative downward references. >> See RFC 3967 for additional information: >> rfc3753: Mobility Related Terminology (Informational - IETF stream) >> rfc7721: Security and Privacy Considerations for IPv6 Address >> Generation Mechanisms (Informational - IETF stream) >> rfc5889: IP Addressing Model in Ad Hoc Networks (Informational - IET= F >> stream) >> rfc6959: Source Address Validation Improvement (SAVI) Threat Scope >> (Informational - IETF stream) >> >> >> >> >> --=20 Best Regards Nabil Benamar Associate Professor Department of Computer Sciences School of Technology Moulay Ismail University Meknes. Morocco --0000000000007d0cf2058b4c9ba8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ji= nmei,

<= div class=3D"gmail_default" style=3D"color:#0b5394">Thank you for your comm= ent.

What do you think of the= following changes:

OLD
=

In the Introduction

=E2=80=9C

=C2=A0 =C2=A0"....The resulting stack oper= ates over 802.11-OCB

=C2=A0=C2=A0 and provides at least P2P connectivity using = IPv6 ND and link-local

=C2=A0=C2=A0 addresses."

=C2=A0

=E2=80=9C<= /p>NEW

=E2=80=9C

=C2=A0=C2=A0 "......The resulting stack inherits from IPv6 over Ethernet [RFC 2464] =
and operates over 802.11-OCB
=C2=A0=C2=A0 providing at least P2P connectivity using IPv6=
 ND and link-local addresses.

=C2=A0


In section 4.3


I will add the following sentence

= =C2=A0

<= span style=3D"font-family:"Courier New"">=C2=A0=C2=A0 =C2=A0The b= est practices for forming IPv6 addresses are inherited from Ethernet.

=C2=A0=C2=A0=C2=A0 In part= icular, the IID is 64 bits = long [RFC= 2464].


=




On Thu, Jun 13, 2019 at 7:= 50 PM =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 <jinmei@wide.ad.jp> wrote:
On Wed, Jun 12, 2019 at 12:16 PM= The IESG <= iesg-secretary@ietf.org> wrote:

> The IESG has received a = request from the IP Wireless Access in
> Vehicular Environments WG (i= pwave) to consider the following
> document: - 'Basic support for= IPv6 over IEEE Std 802.11 Networks
> operating Outside the Context o= f a Basic Service Set
> (IPv6-over-80211-OCB)' <draft-ietf-ipw= ave-ipv6-over-80211ocb-46.txt>
> as Proposed Standard

> = The IESG plans to make a decision in the next few weeks, and
> solici= ts final comments on this action. Please send substantive
> comments = to the ietf@ietf.org= mailing lists by 2019-06-26.

Version 46 of this draft doesn't s= eem to specify the exact length
of the interface identifier.=C2=A0 RFC48= 62 expects it to be specified in
this kind of "link-type specific d= ocument":

=C2=A0 =C2=A0interface identifier - [...] The
=C2= =A0 =C2=A0 =C2=A0 exact length of an interface identifier and the way it is= created
=C2=A0 =C2=A0 =C2=A0 is defined in a separate link-type specifi= c document that covers
=C2=A0 =C2=A0 =C2=A0 issues related to the transm= ission of IP over a particular link
=C2=A0 =C2=A0 =C2=A0 type (e.g., [RF= C2464]).=C2=A0 Note that the address architecture
=C2=A0 =C2=A0 =C2=A0 [= RFC4291] also defines the length of the interface identifiers for
=C2=A0= =C2=A0 =C2=A0 some set of addresses, but the two sets of definitions must = be
=C2=A0 =C2=A0 =C2=A0 consistent.

Specifying the length is crit= ical since (for example) otherwise an
implementation can't perform t= he validation described in Section 5.5.3 of
RFC4862.

I suggest Se= ction 4.4 (and probably also 4.3 for link-local) of this
draft explicitl= y specifies the length of the interface identifier.
And then I'd not= e that the length can (in practice) only be 64 bits
because of the assum= ption about the consistency with the address
architecture (the "Not= e that..." part of the above citation) and
because of the fact that= the current address architecture states the
length is 64 bits for link-= local and practically all global IPv6
addresses in use.=C2=A0 I'm aw= are of the (in)famous tussle on the use of
the fixed value of 64, but I&= #39;m not making this comment for advocating
for the fixed value; I'= m just pointing out a logical consequence of
the assumption of the curre= nt SLAAC standard and the constants used in
the current standards.
--
JINMEI, Tatuya

On Wed, Jun 12, 2019 at 12:16 PM The IESG <iesg-secretary@ietf.o= rg> wrote:
ietf@ietf.org mailin= g lists by 2019-06-26. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


=C2=A0 =C2=A0This document provides methods and settings, and describes
=C2=A0 =C2=A0limitations, for using IPv6 to communicate among nodes in rang= e of
=C2=A0 =C2=A0one another over a single IEEE 802.11-OCB link with minimal ch= ange to
=C2=A0 =C2=A0existing stacks.=C2=A0 Optimizations and usage of IPv6 over mo= re complex
=C2=A0 =C2=A0scenarios is not covered and is subject of future work.




The file can be obtained via
https://datatracker.ietf.org/d= oc/draft-ietf-ipwave-ipv6-over-80211ocb/

IESG discussion can be tracked via
https://datatracker.iet= f.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
=C2=A0 =C2=A0 rfc3753: Mobility Related Terminology (Informational - IETF s= tream)
=C2=A0 =C2=A0 rfc7721: Security and Privacy Considerations for IPv6 Address= Generation Mechanisms (Informational - IETF stream)
=C2=A0 =C2=A0 rfc5889: IP Addressing Model in Ad Hoc Networks (Informationa= l - IETF stream)
=C2=A0 =C2=A0 rfc6959: Source Address Validation Improvement (SAVI) Threat = Scope (Informational - IETF stream)






--

Best Regards

Nabil Benamar
Associate Professor
Department of Computer Scienc= es
Scho= ol of Technology
Moulay Ismail=C2=A0University=C2=A0
Meknes. Morocco


--0000000000007d0cf2058b4c9ba8-- From nobody Fri Jun 14 11:58:14 2019 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 026F91201CC; Fri, 14 Jun 2019 11:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 0y6Toaa_LoMN; Fri, 14 Jun 2019 11:58:00 -0700 (PDT) Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com [209.85.221.45]) (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 58213120154; Fri, 14 Jun 2019 11:57:58 -0700 (PDT) Received: by mail-wr1-f45.google.com with SMTP id p11so3591408wre.7; Fri, 14 Jun 2019 11:57:57 -0700 (PDT) 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=kzAQJ8KajlzecPo4jiV1DHGFo0S2vlSz9tFeqGl8Ys8=; b=Yh4zhWeaR5JvDYf7+ji3NNNSBCLsJv3a+xPL6CTFKpRsGcEEmsp5lVol3sN2YE2zDs jFIpZzBbzVf7pBK/zC0HX6kXkGivhsqB1v6yVfk1sqmwcC5CgyrXyWzgnXEi/TMWlYKE b7chFIdaIr3N6CoqJR28b0U2eUboO2uZATdveUCNyBbt+dzCgo3stdOtgen0W8TSvKmC Fa02wE7YjcqAhcUHMMnc0gm2nCcYvnxlYtSiViZp1qS2hulnGPoKalynhky/SD/Qaus/ +cVETfID4nFHVxqZpXSx0MLRZOp3T9Q5WA4kGVjwSWAvM9LNRfteAC3O/El420cG/Gxg ND1Q== X-Gm-Message-State: APjAAAVKL0DQu4LRXn7abjlMLNzkb04XR6cPlCPmOXrYYlwJjNh7mFTF /FSszYXkUdf9GHrKKXJEyc5YldghItgchK+Wry8= X-Google-Smtp-Source: APXvYqy27gF5k985TmB92YYLW5rZRlmbJe7eF0+Awd/ub1PQwwWmTen5Z/jxQ5RXJajieCBFM/i8eyymk/eX78g6gEQ= X-Received: by 2002:a5d:5089:: with SMTP id a9mr8295389wrt.290.1560538676292; Fri, 14 Jun 2019 11:57:56 -0700 (PDT) MIME-Version: 1.0 References: <156036699018.14103.3418388853567464610.idtracker@ietfa.amsl.com> In-Reply-To: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Fri, 14 Jun 2019 11:57:44 -0700 Message-ID: To: NABIL BENAMAR Cc: IETF Discussion , draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org, ipwave-chairs@ietf.org, =?UTF-8?Q?Carlos_Jes=C3=BAs_Bernardos_Cano?= , its@ietf.org, Suresh Krishnan Content-Type: multipart/alternative; boundary="000000000000756fd5058b4d3962" Archived-At: Subject: Re: [ipwave] Last Call: (Basic support for IPv6 over IEEE Std 802.11 Networks operating Outside the Context of a Basic Service Set (IPv6-over-80211-OCB)) to Proposed Standard X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: 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, 14 Jun 2019 18:58:02 -0000 --000000000000756fd5058b4d3962 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable At Fri, 14 Jun 2019 19:13:34 +0100, NABIL BENAMAR wrote: > Thank you for your comment. > > What do you think of the following changes: > > OLD > > In the Introduction > > =E2=80=9C > > "....The resulting stack operates over 802.11-OCB > and provides at least P2P connectivity using IPv6 ND and link-local > addresses." > =E2=80=9C > NEW > =E2=80=9C > "......The resulting stack inherits from IPv6 over Ethernet [RFC > 2464] and operates over 802.11-OCB > providing at least P2P connectivity using IPv6 ND and link-local addresses. I don't have a strong opinion on this addition, but it wouldn't do harm. > In section 4.3 > > > I will add the following sentence > > The best practices for forming IPv6 addresses are inherited from > Ethernet. > In particular, the IID is 64 bits long [RFC2464 > ]. This doesn't seem to be very consistent with the tone of the other part of the section, in particular: Among these types of addresses only the IPv6 link-local addresses MAY be formed using an EUI-64 identifier, in particular during transition time. and If the IPv6 link-local address is formed using an EUI-64 identifier,... In that RFC2464 only specifies EUI-64 based identifier while this draft states it's a MAY. If I were to edit the section, I'd simply specify the IID length at the end of the section like this: Whether or not the interface identifier is derived from the EUI-64 identifier, its length is 64 bits as is the case for Ethernet [RFC2464]. And for section 4.4, I'd add, for example, the following sentence at the end of the second paragraph: Regardless of how to form the Interface Identifier, its length is 64 bits, as is the case of the IPv6 over Ethernet specification [RFC2464]. -- JINMEI, Tatuya --000000000000756fd5058b4d3962 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
At Fri, 14 Jun 2019 19:13:34 +0100,
NABIL BENAMAR <<= a href=3D"mailto:n.benamar@est.umi.ac.ma">n.benamar@est.umi.ac.ma> w= rote:

> Thank you for your comment.
>
> What do you = think of the following changes:
>
> OLD
>
> In th= e Introduction
>
> =E2=80=9C
>
> =C2=A0 =C2=A0&qu= ot;....The resulting stack operates over 802.11-OCB
> =C2=A0 =C2=A0an= d provides at least P2P connectivity using IPv6 ND and link-local
> = =C2=A0 =C2=A0addresses."
> =E2=80=9C
> NEW
> =E2=80= =9C
> =C2=A0 =C2=A0"......The resulting stack inherits from IPv6= over Ethernet [RFC
> 2464] and operates over 802.11-OCB
> =C2= =A0 =C2=A0providing at least P2P connectivity using IPv6 ND and link-local = addresses.

I don't have a strong opinion on this addition, but i= t wouldn't do
harm.

> In section 4.3
>
>
= > I will add the following sentence
>
> =C2=A0 =C2=A0 The be= st practices for forming IPv6 addresses are inherited from
> Ethernet= .
> =C2=A0 =C2=A0 In particular, the IID is 64 bits long [RFC2464
= > <https://tools.ietf= .org/html/rfc2464>].

This doesn't seem to be very consist= ent with the tone of the other
part of the section, in particular:
=C2=A0 =C2=A0Among these types of
=C2=A0 =C2=A0addresses only the IPv6= link-local addresses MAY be formed using an
=C2=A0 =C2=A0EUI-64 identif= ier, in particular during transition time.
and
=C2=A0 =C2=A0If the IP= v6 link-local address is formed using an EUI-64 identifier,...

In th= at RFC2464 only specifies EUI-64 based identifier while this
draft state= s it's a MAY.=C2=A0 If I were to edit the section, I'd simply
sp= ecify the IID length at the end of the section like this:

=C2=A0 Whe= ther or not the interface identifier is derived from the EUI-64
=C2=A0 i= dentifier, its length is 64 bits as is the case for Ethernet
=C2=A0 [RFC= 2464].

And for section 4.4, I'd add, for example, the following = sentence at
the end of the second paragraph:

=C2=A0 Regardless of= how to form the Interface Identifier, its length is 64
=C2=A0 bits, as = is the case of the IPv6 over Ethernet specification
=C2=A0 [RFC2464].
--
JINMEI, Tatuya
--000000000000756fd5058b4d3962-- From nobody Fri Jun 14 17:25:46 2019 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B53B81200E5 for ; Fri, 14 Jun 2019 17:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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=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 26l4prm3m41p for ; Fri, 14 Jun 2019 17:25:41 -0700 (PDT) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 580A8120047 for ; Fri, 14 Jun 2019 17:25:41 -0700 (PDT) Received: by mail-wr1-x42a.google.com with SMTP id v14so4204481wrr.4 for ; Fri, 14 Jun 2019 17:25:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=us-toyota-itc-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SgE4tdHcbde6o+XYdRWpdH9gOnB9hdQMLey/SJRJ4e8=; b=lQ5fuWjFLwLq9hmi2H3GrUYYMc+UeDKF3PkKHjOdBpr+p4z3LOSHzXYCAeMXp4ptTz BNYh1jwBvtBlVB2X2yGNgap0USjYxt9BdBHRLGaygHt9uWwDCWtLSeKd4vSqnLKfh9qD DNFibG16HCPfHIG5yyspFeRBFa1hsFvqUZwCBOPMVehbl6qa3Hdh6ITmRDWDOe2RETuf 3pCDeJipHMwq6CcO4/N7AXGUR3Yr60T6ouG81At5ClmiQgKp9NOae1kFeVNIpfimrpus r7cBe4NuPlXW3ilb8YQ0WvmRvDH2r/gZ+LVqj54DL/ji53It9/MX1PD51HVf2E26sO9V OAlA== 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=SgE4tdHcbde6o+XYdRWpdH9gOnB9hdQMLey/SJRJ4e8=; b=J+XGNPjDlsWrXRCwKx3/qi4BA29zeR+POiyjDNaFKfcDcrmWVLtX4vhAOCX5h6PQBP 0mmxpPsDtO2rNk8Uj6bhsxChVuiRtRrIPuXNl0fk4SgtFEf9tPPtVaqwkEydZrT+xCHn kEpX5StO2JJhFckfed6naiyffm8bxk3vz5amErPkZSOjXEEMAA2G0A4amRRhDBtLpQBr dsf+MKMC7x7BExxkCypgQCDtBeZNNDMLmPqIN8AcEE8NGwnTqKroeYqji6+lqyIUiALE 4yH1MdaPnDhk/JY4U7jD+g27Qdqd72k+OER+6YqEGoKkYEenXwyCOmBf6kWTAelLxffB asxA== X-Gm-Message-State: APjAAAUYkpHatv5g1rq9YLStFknbGYFsGfwxw15fiDb3RC+GKoURckOx Loz9BUE6HodRu5DEGdCobSsT1QGnFwBPdfWP6pW+Xg== X-Google-Smtp-Source: APXvYqwqSCIgRTJTjtIxehvTlEUB8H672IZmak9nMePz3edBYSN/sU+VjMDQ54iX5V0zH/bPwW0wlAw9CLNZUAT7GVw= X-Received: by 2002:a5d:428d:: with SMTP id k13mr3989094wrq.142.1560558339428; Fri, 14 Jun 2019 17:25:39 -0700 (PDT) MIME-Version: 1.0 References: <24309460-0172-60f1-f2e8-7cc57d152167@gmail.com> <00b601d521c6$7038a7a0$50a9f6e0$@eurecom.fr> In-Reply-To: <00b601d521c6$7038a7a0$50a9f6e0$@eurecom.fr> From: John Kenney Date: Fri, 14 Jun 2019 17:25:28 -0700 Message-ID: To: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= Cc: Alexandre Petrescu , its Content-Type: multipart/alternative; boundary="000000000000792ba3058b51cd36" Archived-At: Subject: Re: [ipwave] Higher bandwidth is a requirement, not a number to avoid X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: 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, 15 Jun 2019 00:25:46 -0000 --000000000000792ba3058b51cd36 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi J=C3=A9r=C3=B4me and Alex, Sorry I have not followed this discussion in detail. If any of my comments are off base, I apologize. Having read J=C3=A9r=C3=B4me's comments, I want to agree with them. I espe= cially want to emphasize that if we are considering operating in public spectrum (5.9 GHz in most regions) we have to be cognizant of how our channel use may impact other users whose applications are equally important from a public safety perspective, perhaps even more important. This is one reason why so many resources have been devoted to researching and testing channel scalability protocols (congestion control). In the US, the FCC bandplan and the SAE J2945/0 standard channel usage plan specify that every channel will be available for use by safety applications. One additional note about channel bandwidth. IEEE 802.11 specifies channel width options of 20 MHz, 10 MHz, and 5 MHz in the 5.9 GHz bands of the US and Europe. Spectrum regulations further limit those to 20 MHz and 10 MHz in the US and only 10 MHz in Europe. However, while 20 MHz channels are in the FCC regulations for the US, we do not expect overlapping 20 MHz and 10 MHz to be used in the same time and place. CSMA/CA will not work well in such an overlapping case because the devices will not natively detect each other's preambles. In fact, 10 MHz usage is the norm, and we do not expect to see 20 MHz usage in the US. This may change with the development of IEEE 802.11bd (Next Generation V2X), which J=C3=A9r=C3=B4me mentioned. That task group is considering way= s to specify a 20 MHz channel that coexists well with constituent 10 MHz users (both 802.11bd and 802.11p). One final point. Some V2X researchers are quite interested in using 60 GHz mmWave spectrum for dissemination of information requiring bit rates on the order of 100s Mbps or 1 Gpbs. This is an active area of research. This may be a better option for high bit rate V2X communication than 5.9 GHz, though of course it has different characteristics and constraints. Best Regards, John On Thu, Jun 13, 2019 at 2:00 AM J=C3=A9r=C3=B4me H=C3=A4rri wrote: > Dear Alex, > > > > You are totally right=E2=80=A6applications have increased needs and it is= not the > right wat to tell an application to send less because of finite capacity = of > a given technology. One thing to keep in mind though is that the > ITS-G5/DSRC has been designed for the needs of so called =E2=80=98day one= =E2=80=99 > applications (e.g. intersection collision avoidance, lane change warning > etc..) and it is quite clear that the technology is not adapted to other > applications, which would require more capacity (say it is not the fault = of > the technology, as it has been designed for something and not for somethi= ng > else). > > > > The applications you are working on fall within the =E2=80=98Day two=E2= =80=99 or =E2=80=98Day two > and half=E2=80=99 (sorry, I am not the one giving these names=E2=80=A6ju= st referring to > them..) and for these new applications there is absolutely a need for mor= e > capacity. In short, we need to find better and more efficient ways to > transmit much more data for ITS applications, and indeed not say that > people should transmit less J > > > > And this is very clear in ETSI, C2C-CC, SAE, even 5GAA=E2=80=A6there are = specific > WG discussing new spectrum usage (10Mhz vs. 20Mhz, multi-channels, etc..) > and the current direction to fulfill the capacity requirements of these > news applications are either IEEE 802.11bd (the next generation wifi-base= d > V2X) or 5G-V2X (the next generation C-V2X technology), as frequency > rechannelization is complex in terms of coexistence and using > multi-channels require multi transmitters=E2=80=A6 > > > > In this perspective, your proposed modification might be seen as a > temporary patch but if it works for your case, that is good, as there is > nothing else available at that time=E2=80=A6And if you propose a simpler = way of > getting more capacity to match day two applications with day one > technology, well this is what I would call research J=E2=80=A6 > > > > The point in my previous e-mail was that putting 20MHz in =E2=80=98iw=E2= =80=99 on an ocb > firmware will change a few things at the physical layers that will affect > the performance (in good or bad) of your system..for instance, the OFDM > guard period will be halved, which will make your link more sensitive to > delay long spreads, or will lose 3dB in receiver sensitivity, which would > impact your Tx range. As I said in my previous e-mails, there are various > teams that have been questioning the 10Mhz channel since a =E2=80=98very= =E2=80=99 long time > now=E2=80=A6so, there is no scientific reasons for not trying at 20Mhz an= d see how > it goes=E2=80=A6yet, it will not be compatible with the current > standards/regulations at that time=E2=80=A6(but does not mean it would no= t change > in the future J) > > > > Please have a look at some of the work from Prof. Eric Str=C3=B6m of Chal= mers > (a nice summary is available here: > https://pdfs.semanticscholar.org/78ef/e53d238ae75837f5817997f27c74f151969= 8.pdf). > In short, there are clearly performance gains in perspective=E2=80=A6but = it > =E2=80=98really=E2=80=99 depends on some parameters of the channel that y= ou will face > during your tests. The most important one is the delay spread. Eric > mentions that a 4nSec is usually agreed, but there are other studies > indicating delay spreads up to 8nsec (also acknowledged by Eric)=E2=80=A6= so, it > would simply be interesting to test and see how it works in your case=E2= =80=A6it > would be good if you could have in your team or project partners expect i= n > PHY/Channel sounding to double check the PHY impact of your strategy in > your environment=E2=80=A6 > > > > To conclude, although not fitting to current spectrum regulations, trying > 20Mhz is good as it gets and there are many people believing that this > could actually help=E2=80=A6but it might not be sufficient for your appli= cations > (you might not double capacity by doubling the bandwidth)=E2=80=A6There w= ill be > much more benefits from the next generation V2X technologies in the very > near future (also indicated by Eric in its slides, page 24) , which will > fulfill your required performance=E2=80=A6that is why I mentioned that fo= r your > required applications, you should follow what IEEE 802.11bd or 5G-V2X wil= l > are actively being developed as we speak. > > > > Best Regards, > > > > J=C3=A9r=C3=B4me > > > > *From:* its [mailto:its-bounces@ietf.org] *On Behalf Of *Alexandre > Petrescu > *Sent:* Wednesday 12 June 2019 20:05 > *To:* its@ietf.org > *Subject:* [ipwave] Higher bandwidth is a requirement, not a number to > avoid > > > > Hi, > > With respect to the channel width 20MHz capability, which would probably > offer higher bandwidth and less latency. > > I received in private several replies from at least 4 people. I also had > a face to face meeting with our partners. > > I want to say something so I am better understood: it is a _requirement_ > to get higher bandwidth; it is not a number to avoid. > > If the app people send 10000 RTMAPS 1480byte sized IP messages per second > then it is so because they need it. Yes, that is 10KHz messages, and not > 20Hz; yes, that is 1428byte IP message and not CAM/BSM 633byte. And yes, > that must be satisfied. We should not tell these people to reduce their > outputs. Reducing their outputs will indeed guarantee better latency for > ping, but they will be less able to transmit valuable data. > > We should not tell app people to throttle (reduce) their output down to 2= 0 > messages per second (20Hz). That is nonsense out of standard documents. > The 20Hz/10Hz/1Hz is data relevant out of GPS chipsets - GPS has nothing = to > do with OCB. > > If in the first platooning tests it worked with less data transmitted, > also the convoy was less performing. We need rich data transmitted, not > poor data. We need lidar data out of the lidar directly on OCB, and > similar other things. > > Alex > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > --=20 John Kenney Director and Sr. Principal Researcher Toyota InfoTech Labs 465 Bernardo Avenue Mountain View, CA 94043 Tel: 650-694-4160. Mobile: 650-224-6644 --000000000000792ba3058b51cd36 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


--

Best Regards

Nabil Benamar
Associate Professor
Department of Computer Scienc= es
Scho= ol of Technology
Moulay Ismail=C2=A0University=C2=A0
Meknes. Morocco


--000000000000ffa612058b887415-- From nobody Tue Jun 18 01:41:13 2019 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4DD12011B; Tue, 18 Jun 2019 01:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBWH0M2yOo01; Tue, 18 Jun 2019 01:40:54 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DB4F120074; Tue, 18 Jun 2019 01:40:54 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id BD1807173DE09D39FEB7; Tue, 18 Jun 2019 09:40:52 +0100 (IST) Received: from DGGEMM403-HUB.china.huawei.com (10.3.20.211) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 18 Jun 2019 09:40:52 +0100 Received: from DGGEMM526-MBX.china.huawei.com ([169.254.8.116]) by DGGEMM403-HUB.china.huawei.com ([10.3.20.211]) with mapi id 14.03.0439.000; Tue, 18 Jun 2019 16:40:38 +0800 From: "Roni Even (A)" To: "dickroy@alum.mit.edu" , 'NABIL BENAMAR' , 'Roni Even' CC: "gen-art@ietf.org" , 'IETF Discussion' , "its@ietf.org" , "draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org" Thread-Topic: [ipwave] [Gen-art] Genart last call review of draft-ietf-ipwave-ipv6-over-80211ocb-46 Thread-Index: AQHVJPHkCSGcS63Kz0uKZOTqzhsmtaafz9OQgABwi3CAANcpgA== Date: Tue, 18 Jun 2019 08:40:38 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD18D37922@dggemm526-mbx.china.huawei.com> References: <156067514313.12185.6559961431451739070@ietfa.amsl.com> <6E58094ECC8D8344914996DAD28F1CCD18D37579@dggemm526-mbx.china.huawei.com> <9B1442B71BF74C83924B8C818D014A95@SRA6> In-Reply-To: <9B1442B71BF74C83924B8C818D014A95@SRA6> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.60] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD18D37922dggemm526mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [ipwave] [Gen-art] Genart last call review of draft-ietf-ipwave-ipv6-over-80211ocb-46 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: 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, 18 Jun 2019 08:40:58 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD18D37922dggemm526mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I am not a security expert, I was just trying to reflect that when reading = the document I got the impression that privacy is a major concern since the= IP-OBU is moving and its location can be traced by sniffing the MAC addres= ses. Maybe it will be good to have a security review of the document. I also not= iced that there is support in IEEE SA - 1609.4-2016 for MAC address change. Roni Even From: Dick Roy [mailto:dickroy@alum.mit.edu] Sent: Monday, June 17, 2019 10:48 PM To: Roni Even (A); 'NABIL BENAMAR'; 'Roni Even' Cc: gen-art@ietf.org; 'IETF Discussion'; its@ietf.org; draft-ietf-ipwave-ip= v6-over-80211ocb.all@ietf.org Subject: RE: [ipwave] [Gen-art] Genart last call review of draft-ietf-ipwav= e-ipv6-over-80211ocb-46 ________________________________ From: its [mailto:its-bounces@ietf.org] On Behalf Of Roni Even (A) Sent: Monday, June 17, 2019 6:26 AM To: NABIL BENAMAR; Roni Even Cc: gen-art@ietf.org; IETF Discussion; its@ietf.or= g; draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org Subject: Re: [ipwave] [Gen-art] Genart last call review of draft-ietf-ipwav= e-ipv6-over-80211ocb-46 Thanks, The only comment left is: 2. In section 5.2 "The policy dictating when the MAC address is changed on = the 802.11-OCB interface is to-be-determined.". Reading the next sentence it lo= oks to me that this is needed as part of the solution and should not be left fo= r the unknown future. Should we reformulate here? I was expecting some recommendation since the changing of MAC address is im= portant to address privacy issues (discussed in section 5). Currently it is= left open with no recommendation , only saying that dynamic change of MAC = address is needed. Maybe the document should have some normative language for example in secti= on 5.1 that will say that IP-OBU MUST dynamic change their MAC addresses [RR] I highly recommend AGAINST this! There will be a number OBU and RSU i= mplementations that DO NOT require anonymity, and don't want it either. Fu= rthermore, immutable identifier change must be coordinated with all other i= nterfaces and protocols otherwise changing them is useless. Did the document go through security area review? [RR] If it did, and the above was not mentioned, then something was missed. Roni From: Gen-art [mailto:gen-art-bounces@ietf.org] On Behalf Of NABIL BENAMAR Sent: Monday, June 17, 2019 12:48 PM To: Roni Even Cc: gen-art@ietf.org; IETF Discussion; its@ietf.or= g; draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org Subject: Re: [Gen-art] Genart last call review of draft-ietf-ipwave-ipv6-ov= er-80211ocb-46 Dear Roni, Thank you for your review. Please, see my answers below. On Sun, Jun 16, 2019, 09:52 Roni Even via Datatracker > wrote: Reviewer: Roni Even Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-ipwave-ipv6-over-80211ocb-?? Reviewer: Roni Even Review Date: 2019-06-16 IETF LC End Date: 2019-06-26 IESG Telechat date: Not scheduled for a telechat Summary: The document is almost ready for publication as a standard track RFC Major issues: Minor issues: 1. Section 4.2 says "IP packets MUST be transmitted over 802.11-OCB media = as QoS Data" while appendix F say "The STA may send data frames of subtype Dat= a, Null, QoS Data, and QoS Null. I will update the appendix to reflect the text in section 4.2. 2. In section 5.2 "The policy dictating when the MAC address is changed on = the 802.11-OCB interface is to-be-determined.". Reading the next sentence it lo= oks to me that this is needed as part of the solution and should not be left fo= r the unknown future. Should we reformulate here? 3. In Appendix I 4th paragraph " However, this does not apply if TBD TBD TB= D. " .. What are the TBDs? The whole sentence will be removed. Nits/editorial comments: 1. In appendix I last paragraph "Support of RFC 8505 is may be implemented = on OCB." should be "Support of RFC 8505 may be implemented on OCB." 2. In Appe= ndix I "OCB nodes that support RFC 8505 would support the 6LN operation in order= to act as a host". I think that instead of "would" it should be "should" als= o if this is a recommendation why not have this paragraph not in an appendix wit= h "MAY" and "SHOULD Agreed. --_000_6E58094ECC8D8344914996DAD28F1CCD18D37922dggemm526mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I am not a security exper= t, I was just trying to reflect that when reading the document I got the im= pression that privacy is a major concern since the IP-OBU is moving and its location can be traced by sniffing the MAC addresses.

Maybe it will be good to have a security re=
view of the document. I also noticed that there is support in IEEE SA - 1609.4-2016 for MAC address change.=
 
Roni Even

 <= /p>

From: Dick Roy= [mailto:dickroy@alum.mit.edu]
Sent: Monday, June 17, 2019 10:48 PM
To: Roni Even (A); 'NABIL BENAMAR'; 'Roni Even'
Cc: gen-art@ietf.org; 'IETF Discussion'; its@ietf.org; draft-ietf-ip= wave-ipv6-over-80211ocb.all@ietf.org
Subject: RE: [ipwave] [Gen-art] Genart last call review of draft-iet= f-ipwave-ipv6-over-80211ocb-46

 

 

 


From: its [mailto:its-bounces@ietf.org] On Behalf Of Roni Even (A)
Sent: Monday, June 17, 2019 6:26 AM
To: NABIL BENAMAR; Roni Even
Cc: gen-art@ietf.org; IETF D= iscussion; its@ietf.org; draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org
Subject: Re: [ipwave] [Gen-art] Genart last call review of draft-iet= f-ipwave-ipv6-over-80211ocb-46

 

Thanks,=

The only comment left is:=


2. In section 5.2 "The policy dictating when the MAC address is change= d on the
802.11-OCB interface is to-be-determined.". Reading the next sentence = it looks
to me that this is needed as part of the solution and should not be left fo= r
the unknown future.

 

Should we reformulate here?

 

I was expecting some recommendation since the changi= ng of MAC address is important to address privacy issues (discussed in sect= ion 5). Currently it is left open with no recommendation , only saying that= dynamic change of MAC address is needed.

Maybe the document should have some normative langua= ge for example in section 5.1 that will say that IP-OBU MUST dynamic change= their MAC addresses  

[RR] I highly recommend = AGAINST this!  There will be a number OBU and RSU implementations that= DO NOT require anonymity, and don’t want it either.  Furthermor= e, immutable identifier change must be coordinated with all other interfaces = and protocols otherwise changing them is useless.

 

Did the document go through security area review?

[RR] If it did, and the = above was not mentioned, then something was missed.

 

Roni

 <= /p>

 <= /p>

From: Gen-art = [mailto:gen-art-bounces@ietf.or= g] On Behalf Of NABIL BENAMAR
Sent: Monday, June 17, 2019 12:48 PM
To: Roni Even
Cc: gen-art@ietf.org; IETF D= iscussion; its@ietf.org; draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org
Subject: Re: [Gen-art] Genart last call review of draft-ietf-ipwave-= ipv6-over-80211ocb-46

 

Dear Roni,

 

Thank you for your review.

Please, see my answers below.

 

 

 

 

 

On Sun, Jun 16, 2019, 09:52 Roni Even via Datatracke= r <noreply@ietf.org> wrote:

Reviewer: Roni Even
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-ipwave-ipv6-over-80211ocb-??
Reviewer: Roni Even
Review Date: 2019-06-16
IETF LC End Date: 2019-06-26
IESG Telechat date: Not scheduled for a telechat

Summary:
The document is almost ready for publication as a standard track RFC

Major issues:

Minor issues:

1. Section 4.2  says "IP packets MUST be transmitted over 802.11-= OCB media as
QoS Data" while appendix F say "The STA may send data frames of s= ubtype Data,
Null, QoS Data, and
      QoS Null.

 

I will update the appendix to reflect the text in se= ction 4.2.


2. In section 5.2 "The policy dictating when the MAC address is change= d on the
802.11-OCB interface is to-be-determined.". Reading the next sentence = it looks
to me that this is needed as part of the solution and should not be left fo= r
the unknown future.

 

Should we reformulate here?


3. In Appendix I 4th paragraph " However, this does not apply if TBD T= BD TBD. "
.. What are the TBDs?

 

The whole sentence will be removed.


Nits/editorial comments:
1. In appendix I last paragraph "Support of RFC 8505 is may be impleme= nted on
OCB." should be "Support of RFC 8505 may be implemented on OCB.&q= uot; 2. In Appendix
I "OCB nodes that support RFC 8505 would support the 6LN operation in = order to
act as a host".  I think that instead of "would" it sho= uld be "should"  also if
this is a recommendation why not have this paragraph not in an appendix wit= h
"MAY" and "SHOULD

 

 

Agreed.

 

--_000_6E58094ECC8D8344914996DAD28F1CCD18D37922dggemm526mbxchi_-- From nobody Tue Jun 18 03:19:34 2019 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BFE01201DB for ; Tue, 18 Jun 2019 03:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfOU9PXXYswJ for ; Tue, 18 Jun 2019 03:19:30 -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 D990F120094 for ; Tue, 18 Jun 2019 03:19:29 -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 x5IAJSso017126 for ; Tue, 18 Jun 2019 12:19:28 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 30080205029 for ; Tue, 18 Jun 2019 12:19:28 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 24083203694 for ; Tue, 18 Jun 2019 12:19:28 +0200 (CEST) Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x5IAJSXx020844 for ; Tue, 18 Jun 2019 12:19:28 +0200 To: "its@ietf.org" From: Alexandre Petrescu Message-ID: <4f9bf5f0-2924-fe5c-0a43-b49ccdc194a1@gmail.com> Date: Tue, 18 Jun 2019 12:19:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------287F99DBF9B1D6100A4AAD4B" Content-Language: fr Archived-At: Subject: [ipwave] Small lidars, high bandwidth X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: 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, 18 Jun 2019 10:19:32 -0000 This is a multi-part message in MIME format. --------------287F99DBF9B1D6100A4AAD4B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Lidars are extensively used in self-driving cars, trucks and recently on fixed poles along the roads. There is a strong need to transmit the lidar data, be it abbreviated or in full raw. The need comes mainly from the fact that they are very expensive.  One cant equip each car with a lidar, and some cars need at least 4 of them to see everywhere. These small lidars are pertinent: Velodyne Puck - has Ethernet port, cand send data on IPv4, but is reluctant to put it on IPv6. Robosence RS-LIDAR - has Etherent, can send on IPv4, is cheap. Quanergy M8 - maybe has Ethernet. Alex --------------287F99DBF9B1D6100A4AAD4B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Lidars are extensively used in self-driving cars, trucks and recently on fixed poles along the roads.

There is a strong need to transmit the lidar data, be it abbreviated or in full raw.  The need comes mainly from the fact that they are very expensive.  One cant equip each car with a lidar, and some cars need at least 4 of them to see everywhere.

These small lidars are pertinent:

Velodyne Puck - has Ethernet port, cand send data on IPv4, but is reluctant to put it on IPv6.
Robosence RS-LIDAR - has Etherent, can send on IPv4, is cheap.
Quanergy M8 - maybe has Ethernet.

Alex

--------------287F99DBF9B1D6100A4AAD4B-- From nobody Tue Jun 18 03:24:32 2019 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2C712012C; Tue, 18 Jun 2019 03:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gvp9kvDdR93U; Tue, 18 Jun 2019 03:24:29 -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 E34E31200B1; Tue, 18 Jun 2019 03:24:28 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x5IAOIFv018492; Tue, 18 Jun 2019 12:24:18 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A77B0204FB0; Tue, 18 Jun 2019 12:24:18 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 96E33204F13; Tue, 18 Jun 2019 12:24:18 +0200 (CEST) Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x5IAOI9s022756; Tue, 18 Jun 2019 12:24:18 +0200 To: "Roni Even (A)" References: <156067514313.12185.6559961431451739070@ietfa.amsl.com> <6E58094ECC8D8344914996DAD28F1CCD18D37579@dggemm526-mbx.china.huawei.com> <9B1442B71BF74C83924B8C818D014A95@SRA6> <6E58094ECC8D8344914996DAD28F1CCD18D37922@dggemm526-mbx.china.huawei.com> <599d5cec-b8d8-af50-008e-492de02e66f4@gmail.com> <6E58094ECC8D8344914996DAD28F1CCD18D379D7@dggemm526-mbx.china.huawei.com> Cc: "ietf@ietf.org" , "its@ietf.org" From: Alexandre Petrescu Message-ID: <74f63a52-41c0-0d37-6da0-fc26819abac4@gmail.com> Date: Tue, 18 Jun 2019 12:24:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD18D379D7@dggemm526-mbx.china.huawei.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] [Gen-art] Genart last call review of draft-ietf-ipwave-ipv6-over-80211ocb-46 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: 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, 18 Jun 2019 10:24:32 -0000 It is a good idea. It would unlock an important issue in the IPWAVE WG. Le 18/06/2019 à 11:26, Roni Even (A) a écrit : > Hi, Maybe use similar language as in > https://tools.ietf.org/id/draft-ietf-ipwave-vehicular-networking-09.txt > > For the protection of drivers' privacy, the pseudonym of a MAC > address of a vehicle's network interface should be used, with the > help of which the MAC address can be changed periodically. YEs, and use 'MAY' instead of 'should'. > I only found the sentence " The policy dictating when the MAC address > is changed on the 802.11-OCB interface is to-be-determined" as too > weak. I agree, it begs for clarification. Alex > > > Roni > > -----Original Message----- From: ietf [mailto:ietf-bounces@ietf.org] > On Behalf Of Alexandre Petrescu Sent: Tuesday, June 18, 2019 12:10 > PM To: ietf@ietf.org Subject: Re: [ipwave] [Gen-art] Genart last call > review of draft-ietf-ipwave-ipv6-over-80211ocb-46 > > Hi, I understand the text makes one think the way you do. > > Privacy is indeed a major issue in vehicular networks. > > I dont know how to better formulate this MAC address change such as > to be ready for the future, and also be compatible with the present. > > 1609.4 is not implemented in all places. Those who implement 1609.4 > do not implement IPv6-over-OCB. 1609.4 implementations, such as all > 1609 implementations, come with a high cost in software, hardware and > necessary skillset. > > IPv6-over-OCB comes at significantly lower cost in the three. > > Alex > > Le 18/06/2019 à 10:40, Roni Even (A) a écrit : >> Hi, >> >> I am not a security expert, I was just trying to reflect that when >> reading the document I got the impression that privacy is a major >> concern since the IP-OBU is moving and its location can be traced >> by sniffing the MAC addresses. >> >> Maybe it will be good to have a security review of the document. I >> also noticed that there is support in IEEE SA - 1609.4-2016 for >> MAC address change. >> >> Roni Even >> >> *From:*Dick Roy [mailto:dickroy@alum.mit.edu] *Sent:* Monday, June >> 17, 2019 10:48 PM *To:* Roni Even (A); 'NABIL BENAMAR'; 'Roni >> Even' *Cc:* gen-art@ietf.org; 'IETF Discussion'; its@ietf.org; >> draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org *Subject:* RE: >> [ipwave] [Gen-art] Genart last call review of >> draft-ietf-ipwave-ipv6-over-80211ocb-46 >> >> ---------------------------------------------------------------------- >> >> -- >> >> *From:*its [mailto:its-bounces@ietf.org] *On Behalf Of *Roni Even >> (A) *Sent:* Monday, June 17, 2019 6:26 AM *To:* NABIL BENAMAR; Roni >> Even *Cc:* gen-art@ietf.org ; IETF >> Discussion; its@ietf.org ; >> draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org >> >> *Subject:* Re: [ipwave] [Gen-art] Genart last call review of >> draft-ietf-ipwave-ipv6-over-80211ocb-46 >> >> Thanks, >> >> The only comment left is: >> >> >> 2. In section 5.2 "The policy dictating when the MAC address is >> changed on the 802.11-OCB interface is to-be-determined.". Reading >> the next sentence it looks to me that this is needed as part of >> the solution and should not be left for the unknown future. >> >> Should we reformulate here? >> >> I was expecting some recommendation since the changing of MAC >> address is important to address privacy issues (discussed in >> section 5). Currently it is left open with no recommendation , only >> saying that dynamic change of MAC address is needed. >> >> Maybe the document should have some normative language for example >> in section 5.1 that will say that IP-OBU MUST dynamic change their >> MAC addresses >> >> */[RR] I highly recommend AGAINST this! There will be a number >> OBU and RSU implementations that DO NOT require anonymity, and >> don't want it either. Furthermore, immutable identifier change >> must be coordinated with all other interfaces and protocols >> otherwise changing them is useless./* >> >> Did the document go through security area review? >> >> */[RR] If it did, and the above was not mentioned, then something >> was missed./* >> >> Roni >> >> *From:*Gen-art [mailto:gen-art-bounces@ietf.org] *On Behalf Of >> *NABIL BENAMAR *Sent:* Monday, June 17, 2019 12:48 PM *To:* Roni >> Even *Cc:* gen-art@ietf.org ; IETF >> Discussion; its@ietf.org ; >> draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org >> >> *Subject:* Re: [Gen-art] Genart last call review of >> draft-ietf-ipwave-ipv6-over-80211ocb-46 >> >> Dear Roni, >> >> Thank you for your review. >> >> Please, see my answers below. >> >> On Sun, Jun 16, 2019, 09:52 Roni Even via Datatracker >> > wrote: >> >> Reviewer: Roni Even Review result: Almost Ready >> >> I am the assigned Gen-ART reviewer for this draft. The General >> Area Review Team (Gen-ART) reviews all IETF documents being >> processed by the IESG for the IETF Chair. Please treat these >> comments just like any other last call comments. >> >> For more information, please see the FAQ at >> >> . >> >> Document: draft-ietf-ipwave-ipv6-over-80211ocb-?? Reviewer: Roni >> Even Review Date: 2019-06-16 IETF LC End Date: 2019-06-26 IESG >> Telechat date: Not scheduled for a telechat >> >> Summary: The document is almost ready for publication as a standard >> track RFC >> >> Major issues: >> >> Minor issues: >> >> 1. Section 4.2 says "IP packets MUST be transmitted over >> 802.11-OCB media as QoS Data" while appendix F say "The STA may >> send data frames of subtype Data, Null, QoS Data, and QoS Null. >> >> I will update the appendix to reflect the text in section 4.2. >> >> >> 2. In section 5.2 "The policy dictating when the MAC address is >> changed on the 802.11-OCB interface is to-be-determined.". Reading >> the next sentence it looks to me that this is needed as part of the >> solution and should not be left for the unknown future. >> >> Should we reformulate here? >> >> >> 3. In Appendix I 4th paragraph " However, this does not apply if >> TBD TBD TBD. " ... What are the TBDs? >> >> The whole sentence will be removed. >> >> >> Nits/editorial comments: 1. In appendix I last paragraph "Support >> of RFC 8505 is may be implemented on OCB." should be "Support of >> RFC 8505 may be implemented on OCB." 2. In Appendix I "OCB nodes >> that support RFC 8505 would support the 6LN operation in order to >> act as a host". I think that instead of "would" it should be >> "should" also if this is a recommendation why not have this >> paragraph not in an appendix with "MAY" and "SHOULD >> >> Agreed. >> > > From nobody Tue Jun 18 05:05:45 2019 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED8731205EC for ; Tue, 18 Jun 2019 05:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=est-umi-ac-ma.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 JAN7wvZ8IQxz for ; Tue, 18 Jun 2019 05:05:34 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 C140C120479 for ; Tue, 18 Jun 2019 05:05:30 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id r185so23160599iod.6 for ; Tue, 18 Jun 2019 05:05:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=est-umi-ac-ma.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CrlB19rXW3bwEl+fDy5dv+Zz7d6liR0N7fmNs4UJHlg=; b=m2djzVhFLz3oIMbb1nyZH5ZpKZaPVP+TxsZE/l3IisD3QnIgtHS2r8zKuypm2t9VJw lEB354CDPManEYL5wB842fEUVQbnzeT9cwnlijpIuOGth5b7umhsfSyJW6np9GkNfOwc RuPkzX1Bqh4bTYD6syS4+y2CQt0PbXmQ1SrTKaDmLQWfLxDIiSOj67BqZAnU2+Oqk+9u KiNHFSkYMhp2Cv+tkXX91/TclyLfCULrnAyj/+RfLxbphjv73dWiaPpreq0ca8UMFl5l Yr7Ff/Cc194a3jVaVKPTjYdxmWopgt9iOafCqUWWNL2F8F8+ZtqmSsJv0TuTTenoOMPG USKQ== 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=CrlB19rXW3bwEl+fDy5dv+Zz7d6liR0N7fmNs4UJHlg=; b=tUCo0cR8WQ5OclhWKAyssY8y0i0MwkeSmvJbWsh/UwdS/fJFoOrP6rLcZs/4D9kdrs oGQoXzBQEZuZCkvsEUovb+ytxKCkvY5xSXdNMAqm+STlMQKuUePAkBxf9k1O1F4xcFOL GXejvS5DI3gGsY7T596HSxgK7VFvcTocpFkmWJJeKhSYQ+JeuxAVsRGyqJz9CV7j9YsS LhMILtwdh4j86qDQqTSazm/HpN7TEB5aSUNdUmRe2Euw/np1/a9gNgnLpxIFVHRgaAC5 cSnX3z+P8RDsra+Bt77Q0syEHZFq6qiOAl3Cxn0tjtIhhr7D8kSeDDPoL/8mzGJ+zpXv ei9w== X-Gm-Message-State: APjAAAUVwajR8kHEL15RxikZqp8hleLD5xOSE0azbtziQEQyAzYNSF0P iJ40ozu79yXjNkqUHvkQbYNphNWq/GkMZH91+T9xRA== X-Google-Smtp-Source: APXvYqz+vzkCFRBKbp64j5wn4Od6eNm3HCEpgIVQ4v88BXcvaobbesVYNwWar/Zt9+SZy7HRt61akOth/Wc7uPoGsag= X-Received: by 2002:a6b:2c8:: with SMTP id 191mr1978962ioc.191.1560859529673; Tue, 18 Jun 2019 05:05:29 -0700 (PDT) MIME-Version: 1.0 References: <156067514313.12185.6559961431451739070@ietfa.amsl.com> <6E58094ECC8D8344914996DAD28F1CCD18D37579@dggemm526-mbx.china.huawei.com> <9B1442B71BF74C83924B8C818D014A95@SRA6> <6E58094ECC8D8344914996DAD28F1CCD18D37922@dggemm526-mbx.china.huawei.com> In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD18D37922@dggemm526-mbx.china.huawei.com> From: NABIL BENAMAR Date: Tue, 18 Jun 2019 13:05:19 +0100 Message-ID: To: "Roni Even (A)" Cc: "dickroy@alum.mit.edu" , Roni Even , "gen-art@ietf.org" , IETF Discussion , "its@ietf.org" , "draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org" Content-Type: multipart/alternative; boundary="000000000000cf97f8058b97ed09" Archived-At: Subject: Re: [ipwave] [Gen-art] Genart last call review of draft-ietf-ipwave-ipv6-over-80211ocb-46 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: 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, 18 Jun 2019 12:05:38 -0000 --000000000000cf97f8058b97ed09 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you Roni, There was a privacy review of the draft and I think we have reflected all concerns. In MHO, the security review will be done as part of the process. On Tue, Jun 18, 2019, 11:40 Roni Even (A) wrote: > Hi, > > I am not a security expert, I was just trying to reflect that when readin= g > the document I got the impression that privacy is a major concern since t= he > IP-OBU is moving and its location can be traced by sniffing the MAC > addresses. > > Maybe it will be good to have a security review of the document. I also n= oticed that there is support in IEEE SA - 1609.4-2016 for MAC address chang= e. > > > > Roni Even > > > > *From:* Dick Roy [mailto:dickroy@alum.mit.edu] > *Sent:* Monday, June 17, 2019 10:48 PM > *To:* Roni Even (A); 'NABIL BENAMAR'; 'Roni Even' > *Cc:* gen-art@ietf.org; 'IETF Discussion'; its@ietf.org; > draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org > *Subject:* RE: [ipwave] [Gen-art] Genart last call review of > draft-ietf-ipwave-ipv6-over-80211ocb-46 > > > > > > > ------------------------------ > > *From:* its [mailto:its-bounces@ietf.org ] *On > Behalf Of *Roni Even (A) > *Sent:* Monday, June 17, 2019 6:26 AM > *To:* NABIL BENAMAR; Roni Even > *Cc:* gen-art@ietf.org; IETF Discussion; its@ietf.org; > draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org > *Subject:* Re: [ipwave] [Gen-art] Genart last call review of > draft-ietf-ipwave-ipv6-over-80211ocb-46 > > > > Thanks, > > The only comment left is: > > > 2. In section 5.2 "The policy dictating when the MAC address is changed o= n > the > 802.11-OCB interface is to-be-determined.". Reading the next sentence it > looks > to me that this is needed as part of the solution and should not be left > for > the unknown future. > > > > Should we reformulate here? > > > > I was expecting some recommendation since the changing of MAC address is > important to address privacy issues (discussed in section 5). Currently i= t > is left open with no recommendation , only saying that dynamic change of > MAC address is needed. > > Maybe the document should have some normative language for example in > section 5.1 that will say that IP-OBU MUST dynamic change their MAC > addresses > > *[RR] I highly recommend AGAINST this! There will be a number OBU and RS= U > implementations that DO NOT require anonymity, and don=E2=80=99t want it = either. > Furthermore, immutable identifier change must be coordinated with all oth= er > interfaces and protocols otherwise changing them is useless.* > > > > Did the document go through security area review? > > *[RR] If it did, and the above was not mentioned, then something was > missed.* > > > > Roni > > > > > > *From:* Gen-art [mailto:gen-art-bounces@ietf.org > ] *On Behalf Of *NABIL BENAMAR > *Sent:* Monday, June 17, 2019 12:48 PM > *To:* Roni Even > *Cc:* gen-art@ietf.org; IETF Discussion; its@ietf.org; > draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org > *Subject:* Re: [Gen-art] Genart last call review of > draft-ietf-ipwave-ipv6-over-80211ocb-46 > > > > Dear Roni, > > > > Thank you for your review. > > Please, see my answers below. > > > > > > > > > > > > On Sun, Jun 16, 2019, 09:52 Roni Even via Datatracker > wrote: > > Reviewer: Roni Even > Review result: Almost Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-ipwave-ipv6-over-80211ocb-?? > Reviewer: Roni Even > Review Date: 2019-06-16 > IETF LC End Date: 2019-06-26 > IESG Telechat date: Not scheduled for a telechat > > Summary: > The document is almost ready for publication as a standard track RFC > > Major issues: > > Minor issues: > > 1. Section 4.2 says "IP packets MUST be transmitted over 802.11-OCB medi= a > as > QoS Data" while appendix F say "The STA may send data frames of subtype > Data, > Null, QoS Data, and > QoS Null. > > > > I will update the appendix to reflect the text in section 4.2. > > > 2. In section 5.2 "The policy dictating when the MAC address is changed o= n > the > 802.11-OCB interface is to-be-determined.". Reading the next sentence it > looks > to me that this is needed as part of the solution and should not be left > for > the unknown future. > > > > Should we reformulate here? > > > 3. In Appendix I 4th paragraph " However, this does not apply if TBD TBD > TBD. " > .. What are the TBDs? > > > > The whole sentence will be removed. > > > Nits/editorial comments: > 1. In appendix I last paragraph "Support of RFC 8505 is may be implemente= d > on > OCB." should be "Support of RFC 8505 may be implemented on OCB." 2. In > Appendix > I "OCB nodes that support RFC 8505 would support the 6LN operation in > order to > act as a host". I think that instead of "would" it should be "should" > also if > this is a recommendation why not have this paragraph not in an appendix > with > "MAY" and "SHOULD > > > > > > Agreed. > > > > --000000000000cf97f8058b97ed09 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you Roni,

There was a privacy review of the draft and I think we have reflected a= ll concerns.

In MHO, the= security review will be done as part of the process.=C2=A0

=
On Tue, Ju= n 18, 2019, 11:40 Roni Even (A) <roni.even@huawei.com> wrote:

Hi,<= /p>

I am not a security exper= t, I was just trying to reflect that when reading the document I got the im= pression that privacy is a major concern since the IP-OBU is moving and its location can be traced by sniffing the MAC addresses.=

Maybe it will be good to have a security re=
view of the document. I also noticed that there is support in IEEE SA - 1609.4-2016 for MAC address change.<=
/u>
=C2=A0
Roni Even

=C2=A0

From: Dick Roy= [mailto:dickroy@alum.mit.edu]
Sent: Monday, June 17, 2019 10:48 PM
To: Roni Even (A); 'NABIL BENAMAR'; 'Roni Even'
Cc: gen-art@ietf.org; 'IETF Discussion'; its@ietf.org; draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org=
Subject: RE: [ipwave] [Gen-art] Genart last call review of draft-iet= f-ipwave-ipv6-over-80211ocb-46

=C2=A0

=C2=A0

=C2=A0


From: its [m= ailto:its-bounces@ietf.org] On Behalf Of Roni Even (A)
Sent: Monday, June 17, 2019 6:26 AM
To: NABIL BENAMAR; Roni Even
Cc: gen-art@ietf.org; IETF Discussion; its@ie= tf.org; draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org
Subject: Re: [ipwave] [Gen-art] Genart last call review of draft-iet= f-ipwave-ipv6-over-80211ocb-46

=C2=A0

Thanks,

The only comment left is:=


2. In section 5.2 "The policy dictating when the MAC address is change= d on the
802.11-OCB interface is to-be-determined.". Reading the next sentence = it looks
to me that this is needed as part of the solution and should not be left fo= r
the unknown future.

=C2=A0

Should we reformulate here?

=C2=A0

I was expecting some recommendation since the changi= ng of MAC address is important to address privacy issues (discussed in sect= ion 5). Currently it is left open with no recommendation , only saying that= dynamic change of MAC address is needed.

Maybe the document should have some normative langua= ge for example in section 5.1 that will say that IP-OBU MUST dynamic change= their MAC addresses =C2=A0

[RR] I highly recommend = AGAINST this!=C2=A0 There will be a number OBU and RSU implementations that= DO NOT require anonymity, and don=E2=80=99t want it either.=C2=A0 Furtherm= ore, immutable identifier change must be coordinated with all other interfaces = and protocols otherwise changing them is useless.

=C2=A0

Did the document go through security area review?=

[RR] If it did, and the = above was not mentioned, then something was missed.

=C2=A0

Roni=

=C2=A0

=C2=A0

From: Gen-art = [mailto:gen-art-bounces@ietf.org] On Behalf Of NABIL BENAMAR
Sent: Monday, June 17, 2019 12:48 PM
To: Roni Even
Cc: gen-art@ietf.org; IETF Discussion; its@ie= tf.org; draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org
Subject: Re: [Gen-art] Genart last call review of draft-ietf-ipwave-= ipv6-over-80211ocb-46

=C2=A0

Dear Roni,

=C2=A0

Thank you for your review.

Please, see my answers below.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0<= /p>

On Sun, Jun 16, 2019, 09:52 Roni Even via Datatracke= r <noreply@ietf.org> wrote:

Reviewer: Roni Even
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.=C2=A0 Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq&g= t;.

Document: draft-ietf-ipwave-ipv6-over-80211ocb-??
Reviewer: Roni Even
Review Date: 2019-06-16
IETF LC End Date: 2019-06-26
IESG Telechat date: Not scheduled for a telechat

Summary:
The document is almost ready for publication as a standard track RFC

Major issues:

Minor issues:

1. Section 4.2=C2=A0 says "IP packets MUST be transmitted over 802.11-= OCB media as
QoS Data" while appendix F say "The STA may send data frames of s= ubtype Data,
Null, QoS Data, and
=C2=A0 =C2=A0 =C2=A0 QoS Null.

=C2=A0

I will update the appendix to reflect the text in se= ction 4.2.


2. In section 5.2 "The policy dictating when the MAC address is change= d on the
802.11-OCB interface is to-be-determined.". Reading the next sentence = it looks
to me that this is needed as part of the solution and should not be left fo= r
the unknown future.

=C2=A0

Should we reformulate here?


3. In Appendix I 4th paragraph " However, this does not apply if TBD T= BD TBD. "
.. What are the TBDs?

=C2=A0

The whole sentence will be removed.


Nits/editorial comments:
1. In appendix I last paragraph "Support of RFC 8505 is may be impleme= nted on
OCB." should be "Support of RFC 8505 may be implemented on OCB.&q= uot; 2. In Appendix
I "OCB nodes that support RFC 8505 would support the 6LN operation in = order to
act as a host".=C2=A0 I think that instead of "would" it sho= uld be "should"=C2=A0 also if
this is a recommendation why not have this paragraph not in an appendix wit= h
"MAY" and "SHOULD

=C2=A0

=C2=A0

Agreed.

=C2=A0<= /p>

--000000000000cf97f8058b97ed09-- From nobody Thu Jun 20 06:25:18 2019 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A458120047 for ; Thu, 20 Jun 2019 06:25:16 -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_HELO_NONE=0.001, 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 uwOiFxKAkw47 for ; Thu, 20 Jun 2019 06:25:14 -0700 (PDT) Received: from mail-qk1-x741.google.com (mail-qk1-x741.google.com [IPv6:2607:f8b0:4864:20::741]) (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 7BCF512000E for ; Thu, 20 Jun 2019 06:25:14 -0700 (PDT) Received: by mail-qk1-x741.google.com with SMTP id b18so1852266qkc.9 for ; Thu, 20 Jun 2019 06:25:14 -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; bh=AN4zU/yhyBC71AISjPWQQG0jScN+91YYuYFd68suFNs=; b=MziDFnCZoxY0yqKjYPVRW69d6uZEBVxEaGAg3sTnsAEa66jAMnGnKDTbMxlP2IjlFJ ktkz+WtDf7Th+XuJ/4149E2FiaTpRF+4AjPFKboM/ghqcGB7yEJmq2+Q2cK0fddtTXMQ o14D8uQ/0WrUT5n/UJk5Ac9asjV0D/SlS2ATXeeXoUW8lJXmDNvvAAQ7lICfLYVrBVKJ +JASjdJbbMZEIPkqveOkvphF3CRTpn0bHU3DXv6GdrbUEaJGlraUJqKZ2I5kXseDKho6 P6pPq2VLqTXbojKy7BB9+0s9ruZUNn7oX2EhBDPsHzxXInPPumjrbVDf4xIjpEUcIpFX ChjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=AN4zU/yhyBC71AISjPWQQG0jScN+91YYuYFd68suFNs=; b=WCFYPG92I5TOyzUzB56dy8tUHURCwZ3LCelbGaYHcMzvVlVqZPIkYLncStk6neuz0H liFH6Bdi3jB1tTRv1gTdbjk7nDjHZ2s+6HH++0IyNVlnqIUZLretNel515pfFs5fpWpS EV/m7mKPZ0CXemlqtqs1MkF9+j6VFjH5R9IGhnnAQ3XId/XTBOK66NiVPwWrEJ/8Sg/v AUH2GSFSG7leNJdm9fDm78Rs/5jwOIMii12K3ZssMENWNJRb9xU7lJM5S9PUwmB7WqrL lPoeC3JU/LrmgyfbGGCQBbjynTN2qYNhMsNZnsTvEBQUyZWwxXiYXcxS//J+RbTvpS40 XtDQ== X-Gm-Message-State: APjAAAWuRxG4rxdu7H4KOhknzuS/p3C+x74ijpOQxXuHqtwEBBONR6Q/ KFvKS0nKKW3eueRO9zBTEHI0XrfSq3WcokypuF4Uwo12rCpwqA== X-Google-Smtp-Source: APXvYqzVe3KDAjfH4WTA1Ss6i+2ZvCuN+rkr7TTyYQZYwv+dJweu1k9H4UBu0p6O1ZsGR0DySD+hDOsv4zJpOC26n6I= X-Received: by 2002:a37:a9c9:: with SMTP id s192mr105094747qke.335.1561037113329; Thu, 20 Jun 2019 06:25:13 -0700 (PDT) MIME-Version: 1.0 From: John Seur Date: Thu, 20 Jun 2019 16:25:01 +0300 Message-ID: To: its@ietf.org Content-Type: multipart/alternative; boundary="0000000000009f0f19058bc146ce" Archived-At: Subject: [ipwave] Patching Linux Kernel with OCB X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: 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, 20 Jun 2019 13:25:16 -0000 --0000000000009f0f19058bc146ce Content-Type: text/plain; charset="UTF-8" Hello IPWavers, During the Hackathon@AIS2019 (https://hackathon.internetsummitafrica.org/), the team in IPWave track (led by Nabil Benamar) was patching the Linux kernel 4.9.61 with OCB mode and discovered the following bugs in the patch file (https://drive.google.com/file/d/0BxK6WTQZ97QVWF9tRURjOGhBU2c/view). drivers/net/wireless/ath/ath9k/main.c:961:2: error: duplicate case value case NL80211_IFTYPE_OCB: drivers/net/wireless/ath/ath9k/hw.c:1241:2: error: duplicate case value case NL80211_IFTYPE_OCB: The duplicated lines of code were commented out and the patch file works! --0000000000009f0f19058bc146ce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello IPWavers,

During the Hackathon@AIS2019 (https://hackathon.intern= etsummitafrica.org/), the team in IPWave track (led by Nabil Benamar) w= as patching the Linux kernel 4.9.61 with OCB mode and discovered the follow= ing bugs in the patch file (https://drive.google.com/file/d/0BxK6WTQZ97Q= VWF9tRURjOGhBU2c/view).
=C2=A0 drivers/net/wireless/ath/ath9k/main.c= :961:2: error: duplicate case value
=C2=A0 case NL80211_IFTYPE_OCB:
= =C2=A0 drivers/net/wireless/ath/ath9k/hw.c:1241:2: error: duplicate case va= lue
=C2=A0 case NL80211_IFTYPE_OCB:
=C2=A0
The duplicated lines o= f code were commented out and the patch file works!
--0000000000009f0f19058bc146ce-- From nobody Thu Jun 20 06:49:45 2019 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5DB12000F for ; Thu, 20 Jun 2019 06:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.92 X-Spam-Level: X-Spam-Status: No, score=-0.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 iYVE7RADTrdc for ; Thu, 20 Jun 2019 06:49:40 -0700 (PDT) Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDFD120045 for ; Thu, 20 Jun 2019 06:49:39 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.63,397,1557180000"; d="scan'208,217"; a="10415172" Received: from monza.eurecom.fr ([192.168.106.15]) by drago1i.eurecom.fr with ESMTP; 20 Jun 2019 15:49:38 +0200 Received: from xerus29 (xerus29.eurecom.fr [172.17.31.38]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by monza.eurecom.fr (Postfix) with ESMTPSA id 28E663088; Thu, 20 Jun 2019 15:49:38 +0200 (CEST) From: =?utf-8?B?SsOpcsO0bWUgSMOkcnJp?= To: "'John Kenney'" , "'Alexandre Petrescu'" Cc: "'its'" References: <24309460-0172-60f1-f2e8-7cc57d152167@gmail.com> <00b601d521c6$7038a7a0$50a9f6e0$@eurecom.fr> In-Reply-To: Date: Thu, 20 Jun 2019 15:49:38 +0200 Organization: EURECOM Message-ID: <01de01d5276f$00911960$01b34c20$@eurecom.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01DF_01D5277F.C41C3350" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF+1vl0RfDsEMZ1Vzq2OEkJOQ5i2AFr3yz6AQ+2glenPVBGgA== Content-Language: en-us Archived-At: Subject: Re: [ipwave] Higher bandwidth is a requirement, not a number to avoid X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: 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, 20 Jun 2019 13:49:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01DF_01D5277F.C41C3350 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi John, Alex, =20 Thanks for the details. =20 I would also like to add another point that I forgot to mentioned. @Alex = did not mention if the DOT11p radio is an automotive-grade or a = DOT11a/10Mhz patch=E2=80=A6 =20 Of course, both are valid OCB devices BUT=E2=80=A6it has been shown on = many occasions that the performance of a DOT11a patched for OCB/10Mhz = show significantly lower performance compared to the state-of-art = automotive grade ITS-G5 devices.=20 =20 If the tests have been done with a DOT11a patched OCB, then this could = also be a reason for the limited capacity. Generally speaking, the = current automotive-grade ITS-G5 devices are not DOT11a/10Mhz patched = devices anymore and have enhanced PHY features that make around 3-5 dB = gain in BER/SNR curves compared to normal patched DOT11a. This is = significant !! =20 But indeed, these devices are more expensive than a normal wifi chip and = if a normal wifi board is patched for OCB/10Mhz, then it is an IEEE = 802.11p device. They can clearly be used for networking (ip, ad-hoc, = etc..) test, but I would suggest not to use these patched devices as a = reference for link-layer/capacity tests, as they do not really represent = what an automotive-grade ITS-G5/DSRC is really capable of doing. =20 BR, =20 J=C3=A9r=C3=B4me =20 =20 From: John Kenney [mailto:jkenney@us.toyota-itc.com]=20 Sent: Saturday 15 June 2019 02:25 To: J=C3=A9r=C3=B4me H=C3=A4rri Cc: Alexandre Petrescu; its Subject: Re: [ipwave] Higher bandwidth is a requirement, not a number to = avoid =20 Hi J=C3=A9r=C3=B4me and Alex, =20 Sorry I have not followed this discussion in detail. If any of my = comments are off base, I apologize. =20 Having read J=C3=A9r=C3=B4me's comments, I want to agree with them. I = especially want to emphasize that if we are considering operating in = public spectrum (5.9 GHz in most regions) we have to be cognizant of how = our channel use may impact other users whose applications are equally = important from a public safety perspective, perhaps even more important. = This is one reason why so many resources have been devoted to = researching and testing channel scalability protocols (congestion = control). In the US, the FCC bandplan and the SAE J2945/0 standard = channel usage plan specify that every channel will be available for use = by safety applications. =20 One additional note about channel bandwidth. IEEE 802.11 specifies = channel width options of 20 MHz, 10 MHz, and 5 MHz in the 5.9 GHz bands = of the US and Europe. Spectrum regulations further limit those to 20 = MHz and 10 MHz in the US and only 10 MHz in Europe. However, while 20 = MHz channels are in the FCC regulations for the US, we do not expect = overlapping 20 MHz and 10 MHz to be used in the same time and place. = CSMA/CA will not work well in such an overlapping case because the = devices will not natively detect each other's preambles. In fact, 10 = MHz usage is the norm, and we do not expect to see 20 MHz usage in the = US.=20 =20 This may change with the development of IEEE 802.11bd (Next Generation = V2X), which J=C3=A9r=C3=B4me mentioned. That task group is considering = ways to specify a 20 MHz channel that coexists well with constituent 10 = MHz users (both 802.11bd and 802.11p). =20 One final point. Some V2X researchers are quite interested in using 60 = GHz mmWave spectrum for dissemination of information requiring bit rates = on the order of 100s Mbps or 1 Gpbs. This is an active area of = research. This may be a better option for high bit rate V2X = communication than 5.9 GHz, though of course it has different = characteristics and constraints. =20 Best Regards, John =20 =20 =20 =20 On Thu, Jun 13, 2019 at 2:00 AM J=C3=A9r=C3=B4me H=C3=A4rri = wrote: Dear Alex, =20 You are totally right=E2=80=A6applications have increased needs and it = is not the right wat to tell an application to send less because of = finite capacity of a given technology. One thing to keep in mind though = is that the ITS-G5/DSRC has been designed for the needs of so called = =E2=80=98day one=E2=80=99 applications (e.g. intersection collision = avoidance, lane change warning etc..) and it is quite clear that the = technology is not adapted to other applications, which would require = more capacity (say it is not the fault of the technology, as it has been = designed for something and not for something else).=20 =20 The applications you are working on fall within the =E2=80=98Day = two=E2=80=99 or =E2=80=98Day two and half=E2=80=99 (sorry, I am not the = one giving these names=E2=80=A6just referring to them..) and for these = new applications there is absolutely a need for more capacity. In short, = we need to find better and more efficient ways to transmit much more = data for ITS applications, and indeed not say that people should = transmit less J =20 And this is very clear in ETSI, C2C-CC, SAE, even 5GAA=E2=80=A6there are = specific WG discussing new spectrum usage (10Mhz vs. 20Mhz, = multi-channels, etc..) and the current direction to fulfill the capacity = requirements of these news applications are either IEEE 802.11bd (the = next generation wifi-based V2X) or 5G-V2X (the next generation C-V2X = technology), as frequency rechannelization is complex in terms of = coexistence and using multi-channels require multi transmitters=E2=80=A6 =20 In this perspective, your proposed modification might be seen as a = temporary patch but if it works for your case, that is good, as there is = nothing else available at that time=E2=80=A6And if you propose a simpler = way of getting more capacity to match day two applications with day one = technology, well this is what I would call research J=E2=80=A6 =20 The point in my previous e-mail was that putting 20MHz in = =E2=80=98iw=E2=80=99 on an ocb firmware will change a few things at the = physical layers that will affect the performance (in good or bad) of = your system..for instance, the OFDM guard period will be halved, which = will make your link more sensitive to delay long spreads, or will lose = 3dB in receiver sensitivity, which would impact your Tx range. As I said = in my previous e-mails, there are various teams that have been = questioning the 10Mhz channel since a =E2=80=98very=E2=80=99 long time = now=E2=80=A6so, there is no scientific reasons for not trying at 20Mhz = and see how it goes=E2=80=A6yet, it will not be compatible with the = current standards/regulations at that time=E2=80=A6(but does not mean it = would not change in the future J) =20 Please have a look at some of the work from Prof. Eric Str=C3=B6m of = Chalmers (a nice summary is available here: = https://pdfs.semanticscholar.org/78ef/e53d238ae75837f5817997f27c74f151969= 8.pdf). In short, there are clearly performance gains in = perspective=E2=80=A6but it =E2=80=98really=E2=80=99 depends on some = parameters of the channel that you will face during your tests. The most = important one is the delay spread. Eric mentions that a 4nSec is usually = agreed, but there are other studies indicating delay spreads up to 8nsec = (also acknowledged by Eric)=E2=80=A6so, it would simply be interesting = to test and see how it works in your case=E2=80=A6it would be good if = you could have in your team or project partners expect in PHY/Channel = sounding to double check the PHY impact of your strategy in your = environment=E2=80=A6=20 =20 To conclude, although not fitting to current spectrum regulations, = trying 20Mhz is good as it gets and there are many people believing that = this could actually help=E2=80=A6but it might not be sufficient for your = applications (you might not double capacity by doubling the = bandwidth)=E2=80=A6There will be much more benefits from the next = generation V2X technologies in the very near future (also indicated by = Eric in its slides, page 24) , which will fulfill your required = performance=E2=80=A6that is why I mentioned that for your required = applications, you should follow what IEEE 802.11bd or 5G-V2X will are = actively being developed as we speak. =20 Best Regards, =20 J=C3=A9r=C3=B4me =20 =20 From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu Sent: Wednesday 12 June 2019 20:05 To: its@ietf.org Subject: [ipwave] Higher bandwidth is a requirement, not a number to = avoid =20 Hi, With respect to the channel width 20MHz capability, which would probably = offer higher bandwidth and less latency. I received in private several replies from at least 4 people. I also = had a face to face meeting with our partners. I want to say something so I am better understood: it is a _requirement_ = to get higher bandwidth; it is not a number to avoid. If the app people send 10000 RTMAPS 1480byte sized IP messages per = second then it is so because they need it. Yes, that is 10KHz messages, = and not 20Hz; yes, that is 1428byte IP message and not CAM/BSM 633byte. = And yes, that must be satisfied. We should not tell these people to = reduce their outputs. Reducing their outputs will indeed guarantee = better latency for ping, but they will be less able to transmit valuable = data. We should not tell app people to throttle (reduce) their output down to = 20 messages per second (20Hz). That is nonsense out of standard = documents. The 20Hz/10Hz/1Hz is data relevant out of GPS chipsets - GPS = has nothing to do with OCB.=20 If in the first platooning tests it worked with less data transmitted, = also the convoy was less performing. We need rich data transmitted, not = poor data. We need lidar data out of the lidar directly on OCB, and = similar other things. Alex _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its =20 --=20 John Kenney Director and Sr. Principal Researcher Toyota InfoTech Labs 465 Bernardo Avenue Mountain View, CA 94043 Tel: 650-694-4160. Mobile: 650-224-6644 ------=_NextPart_000_01DF_01D5277F.C41C3350 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi John, Alex,

 

Thanks for the details.

 

I would also like to add another point that I forgot to mentioned. = @Alex did not mention if the DOT11p radio is an automotive-grade or a = DOT11a/10Mhz patch=E2=80=A6

 

Of course, both are valid OCB devices BUT=E2=80=A6it has been shown = on many occasions that the performance of a DOT11a patched for OCB/10Mhz = show significantly lower performance compared to the state-of-art = automotive grade ITS-G5 devices.

 

If the tests have been done with a DOT11a patched OCB, then this = could also be a reason for the limited capacity. Generally speaking, the = current automotive-grade ITS-G5 devices are not DOT11a/10Mhz patched = devices anymore and have enhanced PHY features that make around 3-5 dB = gain in BER/SNR curves compared to normal patched DOT11a. This is = significant !!

 

But indeed, these devices are more expensive than a normal wifi chip = and if a normal wifi board is patched for OCB/10Mhz, then it is an IEEE = 802.11p device. They can clearly be used for networking (ip, ad-hoc, = etc..) test, but I would suggest not to use these patched devices as a = reference for link-layer/capacity tests, as they do not really represent = what an automotive-grade ITS-G5/DSRC is really capable of = doing.

 

BR,

 

J=C3=A9r=C3=B4me =C2=A0=C2=A0

 

From:= = John Kenney [mailto:jkenney@us.toyota-itc.com]
Sent: Saturday = 15 June 2019 02:25
To: J=C3=A9r=C3=B4me = H=C3=A4rri
Cc: Alexandre Petrescu; its
Subject: Re: = [ipwave] Higher bandwidth is a requirement, not a number to = avoid

 

Hi J=C3=A9r=C3=B4me and = Alex,

 

Sorry I have not followed this discussion in = detail.  If any of my comments are off base, I = apologize.

 

Having read J=C3=A9r=C3=B4me's comments, I want to = agree with them.  I especially want to emphasize that if we are = considering operating in public spectrum (5.9 GHz in most regions) we = have to be cognizant of how our channel use may impact other users whose = applications are equally important from a public safety perspective, = perhaps even more important.  This is one reason why so many = resources have been devoted to researching and testing channel = scalability protocols (congestion control).  In the US, the FCC = bandplan and the SAE J2945/0 standard channel usage plan specify that = every channel will be available for use by safety = applications.

 

One additional note about channel bandwidth.  = IEEE 802.11 specifies channel width options of 20 MHz, 10 MHz, and 5 MHz = in the 5.9 GHz bands of the US and Europe.  Spectrum regulations = further limit those to 20 MHz and 10 MHz in the US and only 10 MHz in = Europe.  However, while 20 MHz channels are in the FCC regulations = for the US, we do not expect overlapping 20 MHz and 10 MHz to be used in = the same time and place. CSMA/CA will not work well in such an = overlapping case because the devices will not natively detect each = other's preambles.  In fact, 10 MHz usage is the norm, and we do = not expect to see 20 MHz usage in the = US. 

 

This may change with the development of IEEE 802.11bd = (Next Generation V2X), which J=C3=A9r=C3=B4me mentioned.  That task = group is considering ways to specify a 20 MHz channel that coexists well = with constituent 10 MHz users (both 802.11bd and = 802.11p).

 

One final point.  Some V2X researchers are quite = interested in using 60 GHz mmWave spectrum for dissemination of = information requiring bit rates on the order of 100s Mbps or 1 = Gpbs.  This is an active area of research.  This may be a = better option for high bit rate V2X communication than 5.9 GHz, though = of course it has different characteristics and = constraints.

 

Best Regards,

John

 

 

 

 

On = Thu, Jun 13, 2019 at 2:00 AM J=C3=A9r=C3=B4me H=C3=A4rri <jerome.haerri@eurecom.fr>= wrote:

Dear Alex,

 

You are totally right=E2=80=A6applications have increased needs and = it is not the right wat to tell an application to send less because of = finite capacity of a given technology. One thing to keep in mind though = is that the ITS-G5/DSRC has been designed for the needs of so called = =E2=80=98day one=E2=80=99 applications (e.g. intersection collision = avoidance, lane change warning etc..) and it is quite clear that the = technology is not adapted to other applications, which would require = more capacity (say it is not the fault of the technology, as it has been = designed for something and not for something else). =

 

The applications you are working on fall within the =E2=80=98Day = two=E2=80=99 or =E2=80=98Day two and half=E2=80=99  (sorry, I am = not the one giving these names=E2=80=A6just referring to them..) and for = these new applications there is absolutely a need for more capacity. In = short, we need to find better and more efficient ways to transmit much = more data for ITS applications, and indeed not say that people should = transmit less J

 

And this is very clear in ETSI, C2C-CC, SAE, even 5GAA=E2=80=A6there = are specific WG discussing new spectrum usage (10Mhz vs. 20Mhz, = multi-channels, etc..) and the current direction to fulfill the capacity = requirements of these news applications are either IEEE 802.11bd (the = next generation wifi-based V2X) or 5G-V2X (the next generation C-V2X = technology), as frequency rechannelization is complex in terms of = coexistence and using multi-channels require multi = transmitters=E2=80=A6

 

In this perspective, your proposed modification might be seen as a = temporary patch but if it works for your case, that is good, as there is = nothing else available at that time=E2=80=A6And if you propose a simpler = way of getting more capacity to match day two applications with day one = technology, well this is what I would call research J=E2=80=A6

 

The point in my previous e-mail was that putting 20MHz in = =E2=80=98iw=E2=80=99 on an ocb firmware will change a few things at the = physical layers that will affect the performance (in good or bad) of = your system..for instance, the OFDM guard period will be halved, which = will make your link more sensitive to delay long spreads, or will lose = 3dB in receiver sensitivity, which would impact your Tx range. As I said = in my previous e-mails, there are various teams that have been = questioning the 10Mhz channel since a =E2=80=98very=E2=80=99 long time = now=E2=80=A6so, there is no scientific reasons for not trying at 20Mhz = and see how it goes=E2=80=A6yet, it will not be compatible with the = current standards/regulations at that time=E2=80=A6(but does not mean it = would not change in the future J)

 

Please have a look at some of the work from Prof. Eric Str=C3=B6m of = Chalmers (a nice summary is available here: https://pdfs.semanticscholar.org/78ef/e53d238ae75837f58= 17997f27c74f1519698.pdf).  In short, there are clearly = performance gains in perspective=E2=80=A6but it =E2=80=98really=E2=80=99 = depends on some parameters of the channel that you will face during your = tests. The most important one is the delay spread. Eric mentions that a = 4nSec is usually agreed, but there are other studies indicating delay = spreads up to 8nsec (also acknowledged by Eric)=E2=80=A6so, it would = simply be interesting to test and see how it works in your = case=E2=80=A6it would be good if you could have in your team or project = partners expect in PHY/Channel sounding to double check the PHY impact = of your strategy in your environment=E2=80=A6

 

To conclude, although not fitting to current spectrum regulations, = trying 20Mhz is good as it gets and there are many people believing that = this could actually help=E2=80=A6but it might not be sufficient for your = applications (you might not double capacity by doubling the = bandwidth)=E2=80=A6There will be much more benefits from the next = generation V2X technologies in the very near future (also indicated by = Eric in its slides, page 24) , which will fulfill your required = performance=E2=80=A6that is why I mentioned that for your required = applications, you should follow what IEEE 802.11bd or 5G-V2X will are = actively being developed as we speak.

 

Best Regards,

 

J=C3=A9r=C3=B4me  

 

From:= = its [mailto:its-bounces@ietf.org] On Behalf Of = Alexandre Petrescu
Sent: Wednesday 12 June 2019 = 20:05
To: its@ietf.org
Subject: [ipwave] Higher = bandwidth is a requirement, not a number to = avoid

 <= /o:p>

Hi,

With respect to the = channel width 20MHz capability, which would probably offer higher = bandwidth and less latency.

I received in = private several replies from at least 4 people.  I also had a face = to face meeting with our partners.

I want to say = something so I am better understood: it is a _requirement_ to get higher = bandwidth; it is not a number to avoid.

If the app people = send 10000 RTMAPS 1480byte sized IP messages per second then it is so = because they need it.  Yes, that is 10KHz messages, and not 20Hz; = yes, that is 1428byte IP message and not CAM/BSM 633byte.  And yes, = that must be satisfied.  We should not tell these people to reduce = their outputs.  Reducing their outputs will indeed guarantee better = latency for ping, but they will be less able to transmit valuable = data.

We should not tell = app people to throttle (reduce) their output down to 20 messages per = second (20Hz).  That is nonsense out of standard documents.  = The 20Hz/10Hz/1Hz is data relevant out of GPS chipsets - GPS has nothing = to do with OCB.

If in the first = platooning tests it worked with less data transmitted, also the convoy = was less performing.  We need rich data transmitted, not poor = data.  We need lidar data out of the lidar directly on OCB, and = similar other things.

Alex

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


 

-- =

John Kenney

Director and Sr. Principal = Researcher

Toyota InfoTech = Labs

465 Bernardo = Avenue

Mountain View, CA = 94043

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

------=_NextPart_000_01DF_01D5277F.C41C3350-- From nobody Thu Jun 20 07:11:53 2019 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4616312004A for ; Thu, 20 Jun 2019 07:11: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_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UM4QPbPhHlS6 for ; Thu, 20 Jun 2019 07:11:48 -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 A35BB120077 for ; Thu, 20 Jun 2019 07:11:47 -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 x5KEBhmK025386; Thu, 20 Jun 2019 16:11:44 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C52EA2030B3; Thu, 20 Jun 2019 16:11:44 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id B4D28200DD8; Thu, 20 Jun 2019 16:11:44 +0200 (CEST) Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x5KEBixR007865; Thu, 20 Jun 2019 16:11:44 +0200 To: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , "'John Kenney'" Cc: "'its'" References: <24309460-0172-60f1-f2e8-7cc57d152167@gmail.com> <00b601d521c6$7038a7a0$50a9f6e0$@eurecom.fr> <01de01d5276f$00911960$01b34c20$@eurecom.fr> From: Alexandre Petrescu Message-ID: <933a52e6-c0e1-f5d6-6443-ddb189be958c@gmail.com> Date: Thu, 20 Jun 2019 16:11:44 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: <01de01d5276f$00911960$01b34c20$@eurecom.fr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Higher bandwidth is a requirement, not a number to avoid X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: 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, 20 Jun 2019 14:11:52 -0000 I think all I am talking about is what you call a DOT11a/10MHz patch. IT is actually no longer a patch, because OCB is now integrated in the linux mainline kernel. I am talking linux, because BSD does not support OCB. Whereas I agree with you that the 'automotive grade' qualifier is commonly used to indicate higher quality, on my side I think it is used to justify more expensive OCB devices than others. I can not say I understand what the quality is about. It may be that what is meant by quality for some, is less quality for others. It may be that what is meant by 'quality' in laboratory, is something that never sees the light in the streets. It may be that a higher quality product acts excellent when everybody is in a single channel, but less well when multiple channels are used. Since this spectrum is not under the control of authority, it is hard to define what is quality. But it is easy to experiment. That, said, I can tell the numbers in my trials. It is with linux, cheap WiFi 'a' cards, and OCB open source in mainline kernel. Between two cars, the IPv6 bandwidth with iperf TCP packets peaks at around 7mbit/s. During that flow, the RTT of ping is about 50ms. On an empty channel (no iperf traffic), the RTT of ping is on average 1.4ms. What I need is to be able to allow the RTMAPS programmers to send their packets with a frequency of 20kHz. (20.000 TCP/IPv6 packets per second). When they try that, the latency they get is around 500ms. It is way too much. It means the distance between platooned cars is way too much. 20kHz may appear as a programmer error, but it is not. The programmer should not be told to reduce their output. It is the network that must accommodate it. If in my OCB deployment I get a bandwidth at around 1Gbit/s (vs. current 7Mbit/s), then I can share the lidar data between cars. That translates to huge reduction in cost. The cheapest lidar is around 7Keur, but most expensive can be 30Keur. A cheap car is cheaper than a lidar. Some of the lidars are connected on Gbit Ethernet. A higher than current 7Mbit/s on OCB can be obtained by several means: - try the iw command to use 20MHz width, instead of 10. It would theoretically increase the bandwidth to 14Mbit/s. It's not 1Gbpbs, but it's more. - other linux commands? - make the OCB patch apply to ath10k, not the ath9k currently. That is something that nobody tried. Even if one does not have an ath10k card (802.11ac) one could still try to adapt the OCB patch for the C code, and see whether it compiles. If it compiles, it is already a good step forward. We'll see later about the execution. Maybe you know other means by which to achieve higher bandwidth on OCB? Alex Le 20/06/2019 à 15:49, Jérôme Härri a écrit : > Hi John, Alex, > > Thanks for the details. > > I would also like to add another point that I forgot to mentioned. @Alex > did not mention if the DOT11p radio is an automotive-grade or a > DOT11a/10Mhz patch… > > Of course, both are valid OCB devices BUT…it has been shown on many > occasions that the performance of a DOT11a patched for OCB/10Mhz show > significantly lower performance compared to the state-of-art automotive > grade ITS-G5 devices. > > If the tests have been done with a DOT11a patched OCB, then this could > also be a reason for the limited capacity. Generally speaking, the > current automotive-grade ITS-G5 devices are not DOT11a/10Mhz patched > devices anymore and have enhanced PHY features that make around 3-5 dB > gain in BER/SNR curves compared to normal patched DOT11a. This is > significant !! > > But indeed, these devices are more expensive than a normal wifi chip and > if a normal wifi board is patched for OCB/10Mhz, then it is an IEEE > 802.11p device. They can clearly be used for networking (ip, ad-hoc, > etc..) test, but I would suggest not to use these patched devices as a > reference for link-layer/capacity tests, as they do not really represent > what an automotive-grade ITS-G5/DSRC is really capable of doing. > > BR, > > Jérôme > > *From:*John Kenney [mailto:jkenney@us.toyota-itc.com] > *Sent:* Saturday 15 June 2019 02:25 > *To:* Jérôme Härri > *Cc:* Alexandre Petrescu; its > *Subject:* Re: [ipwave] Higher bandwidth is a requirement, not a number > to avoid > > Hi Jérôme and Alex, > > Sorry I have not followed this discussion in detail.  If any of my > comments are off base, I apologize. > > Having read Jérôme's comments, I want to agree with them.  I especially > want to emphasize that if we are considering operating in public > spectrum (5.9 GHz in most regions) we have to be cognizant of how our > channel use may impact other users whose applications are equally > important from a public safety perspective, perhaps even more > important.  This is one reason why so many resources have been devoted > to researching and testing channel scalability protocols (congestion > control).  In the US, the FCC bandplan and the SAE J2945/0 standard > channel usage plan specify that every channel will be available for use > by safety applications. > > One additional note about channel bandwidth.  IEEE 802.11 specifies > channel width options of 20 MHz, 10 MHz, and 5 MHz in the 5.9 GHz bands > of the US and Europe.  Spectrum regulations further limit those to 20 > MHz and 10 MHz in the US and only 10 MHz in Europe.  However, while 20 > MHz channels are in the FCC regulations for the US, we do not expect > overlapping 20 MHz and 10 MHz to be used in the same time and place. > CSMA/CA will not work well in such an overlapping case because the > devices will not natively detect each other's preambles.  In fact, 10 > MHz usage is the norm, and we do not expect to see 20 MHz usage in the US. > > This may change with the development of IEEE 802.11bd (Next Generation > V2X), which Jérôme mentioned.  That task group is considering ways to > specify a 20 MHz channel that coexists well with constituent 10 MHz > users (both 802.11bd and 802.11p). > > One final point.  Some V2X researchers are quite interested in using 60 > GHz mmWave spectrum for dissemination of information requiring bit rates > on the order of 100s Mbps or 1 Gpbs.  This is an active area of > research.  This may be a better option for high bit rate V2X > communication than 5.9 GHz, though of course it has different > characteristics and constraints. > > Best Regards, > > John > > On Thu, Jun 13, 2019 at 2:00 AM Jérôme Härri > wrote: > > Dear Alex, > > You are totally right…applications have increased needs and it is > not the right wat to tell an application to send less because of > finite capacity of a given technology. One thing to keep in mind > though is that the ITS-G5/DSRC has been designed for the needs of so > called ‘day one’ applications (e.g. intersection collision > avoidance, lane change warning etc..) and it is quite clear that the > technology is not adapted to other applications, which would require > more capacity (say it is not the fault of the technology, as it has > been designed for something and not for something else). > > The applications you are working on fall within the ‘Day two’ or > ‘Day two and half’  (sorry, I am not the one giving these names…just > referring to them..) and for these new applications there is > absolutely a need for more capacity. In short, we need to find > better and more efficient ways to transmit much more data for ITS > applications, and indeed not say that people should transmit less J > > And this is very clear in ETSI, C2C-CC, SAE, even 5GAA…there are > specific WG discussing new spectrum usage (10Mhz vs. 20Mhz, > multi-channels, etc..) and the current direction to fulfill the > capacity requirements of these news applications are either IEEE > 802.11bd (the next generation wifi-based V2X) or 5G-V2X (the next > generation C-V2X technology), as frequency rechannelization is > complex in terms of coexistence and using multi-channels require > multi transmitters… > > In this perspective, your proposed modification might be seen as a > temporary patch but if it works for your case, that is good, as > there is nothing else available at that time…And if you propose a > simpler way of getting more capacity to match day two applications > with day one technology, well this is what I would call research J… > > The point in my previous e-mail was that putting 20MHz in ‘iw’ on an > ocb firmware will change a few things at the physical layers that > will affect the performance (in good or bad) of your system..for > instance, the OFDM guard period will be halved, which will make your > link more sensitive to delay long spreads, or will lose 3dB in > receiver sensitivity, which would impact your Tx range. As I said in > my previous e-mails, there are various teams that have been > questioning the 10Mhz channel since a ‘very’ long time now…so, there > is no scientific reasons for not trying at 20Mhz and see how it > goes…yet, it will not be compatible with the current > standards/regulations at that time…(but does not mean it would not > change in the future J) > > Please have a look at some of the work from Prof. Eric Ström of > Chalmers (a nice summary is available here: > https://pdfs.semanticscholar.org/78ef/e53d238ae75837f5817997f27c74f1519698.pdf). > In short, there are clearly performance gains in perspective…but it > ‘really’ depends on some parameters of the channel that you will > face during your tests. The most important one is the delay spread. > Eric mentions that a 4nSec is usually agreed, but there are other > studies indicating delay spreads up to 8nsec (also acknowledged by > Eric)…so, it would simply be interesting to test and see how it > works in your case…it would be good if you could have in your team > or project partners expect in PHY/Channel sounding to double check > the PHY impact of your strategy in your environment… > > To conclude, although not fitting to current spectrum regulations, > trying 20Mhz is good as it gets and there are many people believing > that this could actually help…but it might not be sufficient for > your applications (you might not double capacity by doubling the > bandwidth)…There will be much more benefits from the next generation > V2X technologies in the very near future (also indicated by Eric in > its slides, page 24) , which will fulfill your required > performance…that is why I mentioned that for your required > applications, you should follow what IEEE 802.11bd or 5G-V2X will > are actively being developed as we speak. > > Best Regards, > > Jérôme > > *From:*its [mailto:its-bounces@ietf.org > ] *On Behalf Of *Alexandre Petrescu > *Sent:* Wednesday 12 June 2019 20:05 > *To:* its@ietf.org > *Subject:* [ipwave] Higher bandwidth is a requirement, not a number > to avoid > > Hi, > > With respect to the channel width 20MHz capability, which would > probably offer higher bandwidth and less latency. > > I received in private several replies from at least 4 people.  I > also had a face to face meeting with our partners. > > I want to say something so I am better understood: it is a > _requirement_ to get higher bandwidth; it is not a number to avoid. > > If the app people send 10000 RTMAPS 1480byte sized IP messages per > second then it is so because they need it.  Yes, that is 10KHz > messages, and not 20Hz; yes, that is 1428byte IP message and not > CAM/BSM 633byte.  And yes, that must be satisfied.  We should not > tell these people to reduce their outputs.  Reducing their outputs > will indeed guarantee better latency for ping, but they will be less > able to transmit valuable data. > > We should not tell app people to throttle (reduce) their output down > to 20 messages per second (20Hz).  That is nonsense out of standard > documents.  The 20Hz/10Hz/1Hz is data relevant out of GPS chipsets - > GPS has nothing to do with OCB. > > If in the first platooning tests it worked with less data > transmitted, also the convoy was less performing.  We need rich data > transmitted, not poor data.  We need lidar data out of the lidar > directly on OCB, and similar other things. > > Alex > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > > -- > > John Kenney > > Director and Sr. Principal Researcher > > Toyota InfoTech Labs > > 465 Bernardo Avenue > > Mountain View, CA 94043 > > Tel: 650-694-4160. Mobile: 650-224-6644 > From nobody Thu Jun 20 07:12:45 2019 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 003AF120089 for ; Thu, 20 Jun 2019 07:12:45 -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_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9ok9P62t32B for ; Thu, 20 Jun 2019 07:12:42 -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 2F2FD12004A for ; Thu, 20 Jun 2019 07:12:39 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x5KECaMG008968; Thu, 20 Jun 2019 16:12:36 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9E2E1205FA6; Thu, 20 Jun 2019 16:12:36 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 83D0A205FD1; Thu, 20 Jun 2019 16:12:36 +0200 (CEST) Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x5KECarK008533; Thu, 20 Jun 2019 16:12:36 +0200 To: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , "'John Kenney'" Cc: "'its'" References: <24309460-0172-60f1-f2e8-7cc57d152167@gmail.com> <00b601d521c6$7038a7a0$50a9f6e0$@eurecom.fr> <01de01d5276f$00911960$01b34c20$@eurecom.fr> From: Alexandre Petrescu Message-ID: Date: Thu, 20 Jun 2019 16:12:36 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: <01de01d5276f$00911960$01b34c20$@eurecom.fr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Higher bandwidth is a requirement, not a number to avoid X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: 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, 20 Jun 2019 14:12:45 -0000 Le 20/06/2019 à 15:49, Jérôme Härri a écrit : [...] > as they do not really represent > what an automotive-grade ITS-G5/DSRC is really capable of doing. What is the bandwidth of IPv6 demonstrated on ITS-G5/DSRC? Alex From nobody Thu Jun 20 08:15:01 2019 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 947D1120092 for ; Thu, 20 Jun 2019 08:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.921 X-Spam-Level: X-Spam-Status: No, score=-0.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 wYxRmynK0goO for ; Thu, 20 Jun 2019 08:14:56 -0700 (PDT) Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210]) by ietfa.amsl.com (Postfix) with ESMTP id 1173B1200CE for ; Thu, 20 Jun 2019 08:14:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.63,397,1557180000"; d="scan'208";a="10415886" Received: from monza.eurecom.fr ([192.168.106.15]) by drago1i.eurecom.fr with ESMTP; 20 Jun 2019 17:14:54 +0200 Received: from xerus29 (xerus29.eurecom.fr [172.17.31.38]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by monza.eurecom.fr (Postfix) with ESMTPSA id AB83E3953; Thu, 20 Jun 2019 17:14:54 +0200 (CEST) From: =?utf-8?B?SsOpcsO0bWUgSMOkcnJp?= To: "'Alexandre Petrescu'" Cc: "'its'" , "'John Kenney'" References: <24309460-0172-60f1-f2e8-7cc57d152167@gmail.com> <00b601d521c6$7038a7a0$50a9f6e0$@eurecom.fr> <01de01d5276f$00911960$01b34c20$@eurecom.fr> <933a52e6-c0e1-f5d6-6443-ddb189be958c@gmail.com> In-Reply-To: <933a52e6-c0e1-f5d6-6443-ddb189be958c@gmail.com> Date: Thu, 20 Jun 2019 17:14:54 +0200 Organization: EURECOM Message-ID: <021b01d5277a$ea45bd30$bed13790$@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: AQF+1vl0RfDsEMZ1Vzq2OEkJOQ5i2AFr3yz6AQ+2glcCAvPtEAHrgDsHpx3xaMA= Content-Language: en-us Archived-At: Subject: Re: [ipwave] Higher bandwidth is a requirement, not a number to avoid X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: 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, 20 Jun 2019 15:14:59 -0000 Hi Alex, The automotive-grade ITS-G5/DSRC devices have an enhanced PHY (something = called channel tracking, among other things that I am most likely not = aware...). If you are interested, this is a nice paper illustrating the = issues of regular DOT11p devices confronted to fast time varying = channels..."Andre Bourdoux, Hans Cappelle, Antoine Dejonghe, Channel = Tracking for Fast Time-Varying Channels in IEEE802.11p Systems, IEEE = globecome 2011" Such enhanced PHY is located in the wifi modem, not in a driver (that is = the 'closed/protected' part of the wifi stack in linux)...I am not aware = of a way to be able to add this on a linux wifi driver. But such = enhancement really adds more reliability to the ITS-G5/DSRC system = (increased range, improved PDR).. But you are correct...using the wifi DOTa with OCB at 10Mhz follows the = standard...it is a valid DOT11p device...but it is not the best an = Wifi-V2X system can do...My point is to say that all WiFi OCB/10Mhz are = WiFi-V2X but not all WiFi-V2X are WiFi OCB/10MHz..and as in any field, = there are better products than others (thus the business behind it :-) = )... So, using an 'automotive-grade' (I use brackets as indeed this usually = refer to more than just performance...) could be one option to get = closer to the performance you need...but of course, and as I mentioned = in my early e-mail, it might not be enough for the very reason that = DOT11p (generic and automotive-grade) have been designed with the = performance requirements identified for Day One applications, not Day = Two... So indeed, increasing bandwidth (20Mhz) or dynamically adapting = modulation or replacing DOT11p with DOT11bd are other potential = strategies...and stakeholders are very aware of this...there is a need = for more capacity, thus we need to do something to get it :-) =20 Best Regards, J=C3=A9r=C3=B4me =20 -----Original Message----- From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com]=20 Sent: Thursday 20 June 2019 16:12 To: J=C3=A9r=C3=B4me H=C3=A4rri; 'John Kenney' Cc: 'its' Subject: Re: [ipwave] Higher bandwidth is a requirement, not a number to = avoid I think all I am talking about is what you call a DOT11a/10MHz patch.=20 IT is actually no longer a patch, because OCB is now integrated in the=20 linux mainline kernel. I am talking linux, because BSD does not support OCB. Whereas I agree with you that the 'automotive grade' qualifier is=20 commonly used to indicate higher quality, on my side I think it is used=20 to justify more expensive OCB devices than others. I can not say I=20 understand what the quality is about. It may be that what is meant by quality for some, is less quality for=20 others. It may be that what is meant by 'quality' in laboratory, is something=20 that never sees the light in the streets. It may be that a higher quality product acts excellent when everybody is = in a single channel, but less well when multiple channels are used. Since this spectrum is not under the control of authority, it is hard to = define what is quality. But it is easy to experiment. That, said, I can tell the numbers in my trials. It is with linux,=20 cheap WiFi 'a' cards, and OCB open source in mainline kernel. Between two cars, the IPv6 bandwidth with iperf TCP packets peaks at=20 around 7mbit/s. During that flow, the RTT of ping is about 50ms. On an = empty channel (no iperf traffic), the RTT of ping is on average 1.4ms. What I need is to be able to allow the RTMAPS programmers to send their=20 packets with a frequency of 20kHz. (20.000 TCP/IPv6 packets per=20 second). When they try that, the latency they get is around 500ms. It=20 is way too much. It means the distance between platooned cars is way=20 too much. 20kHz may appear as a programmer error, but it is not. The programmer=20 should not be told to reduce their output. It is the network that must=20 accommodate it. If in my OCB deployment I get a bandwidth at around 1Gbit/s (vs.=20 current 7Mbit/s), then I can share the lidar data between cars. That=20 translates to huge reduction in cost. The cheapest lidar is around=20 7Keur, but most expensive can be 30Keur. A cheap car is cheaper than a=20 lidar. Some of the lidars are connected on Gbit Ethernet. A higher than current 7Mbit/s on OCB can be obtained by several means: - try the iw command to use 20MHz width, instead of 10. It would theoretically increase the bandwidth to 14Mbit/s. It's not 1Gbpbs, but it's more. - other linux commands? - make the OCB patch apply to ath10k, not the ath9k currently. That is something that nobody tried. Even if one does not have an ath10k=20 card (802.11ac) one could still try to adapt the OCB patch for the C=20 code, and see whether it compiles. If it compiles, it is already a good = step forward. We'll see later about the execution. Maybe you know other means by which to achieve higher bandwidth on OCB? Alex Le 20/06/2019 =C3=A0 15:49, J=C3=A9r=C3=B4me H=C3=A4rri a =C3=A9crit : > Hi John, Alex, >=20 > Thanks for the details. >=20 > I would also like to add another point that I forgot to mentioned. = @Alex=20 > did not mention if the DOT11p radio is an automotive-grade or a=20 > DOT11a/10Mhz patch=E2=80=A6 >=20 > Of course, both are valid OCB devices BUT=E2=80=A6it has been shown on = many=20 > occasions that the performance of a DOT11a patched for OCB/10Mhz show=20 > significantly lower performance compared to the state-of-art = automotive=20 > grade ITS-G5 devices. >=20 > If the tests have been done with a DOT11a patched OCB, then this could = > also be a reason for the limited capacity. Generally speaking, the=20 > current automotive-grade ITS-G5 devices are not DOT11a/10Mhz patched=20 > devices anymore and have enhanced PHY features that make around 3-5 dB = > gain in BER/SNR curves compared to normal patched DOT11a. This is=20 > significant !! >=20 > But indeed, these devices are more expensive than a normal wifi chip = and=20 > if a normal wifi board is patched for OCB/10Mhz, then it is an IEEE=20 > 802.11p device. They can clearly be used for networking (ip, ad-hoc,=20 > etc..) test, but I would suggest not to use these patched devices as a = > reference for link-layer/capacity tests, as they do not really = represent=20 > what an automotive-grade ITS-G5/DSRC is really capable of doing. >=20 > BR, >=20 > J=C3=A9r=C3=B4me >=20 > *From:*John Kenney [mailto:jkenney@us.toyota-itc.com] > *Sent:* Saturday 15 June 2019 02:25 > *To:* J=C3=A9r=C3=B4me H=C3=A4rri > *Cc:* Alexandre Petrescu; its > *Subject:* Re: [ipwave] Higher bandwidth is a requirement, not a = number=20 > to avoid >=20 > Hi J=C3=A9r=C3=B4me and Alex, >=20 > Sorry I have not followed this discussion in detail. If any of my=20 > comments are off base, I apologize. >=20 > Having read J=C3=A9r=C3=B4me's comments, I want to agree with them. I = especially=20 > want to emphasize that if we are considering operating in public=20 > spectrum (5.9 GHz in most regions) we have to be cognizant of how our=20 > channel use may impact other users whose applications are equally=20 > important from a public safety perspective, perhaps even more=20 > important. This is one reason why so many resources have been devoted = > to researching and testing channel scalability protocols (congestion=20 > control). In the US, the FCC bandplan and the SAE J2945/0 standard=20 > channel usage plan specify that every channel will be available for = use=20 > by safety applications. >=20 > One additional note about channel bandwidth. IEEE 802.11 specifies=20 > channel width options of 20 MHz, 10 MHz, and 5 MHz in the 5.9 GHz = bands=20 > of the US and Europe. Spectrum regulations further limit those to 20=20 > MHz and 10 MHz in the US and only 10 MHz in Europe. However, while 20 = > MHz channels are in the FCC regulations for the US, we do not expect=20 > overlapping 20 MHz and 10 MHz to be used in the same time and place.=20 > CSMA/CA will not work well in such an overlapping case because the=20 > devices will not natively detect each other's preambles. In fact, 10=20 > MHz usage is the norm, and we do not expect to see 20 MHz usage in the = US. >=20 > This may change with the development of IEEE 802.11bd (Next Generation = > V2X), which J=C3=A9r=C3=B4me mentioned. That task group is = considering ways to=20 > specify a 20 MHz channel that coexists well with constituent 10 MHz=20 > users (both 802.11bd and 802.11p). >=20 > One final point. Some V2X researchers are quite interested in using = 60=20 > GHz mmWave spectrum for dissemination of information requiring bit = rates=20 > on the order of 100s Mbps or 1 Gpbs. This is an active area of=20 > research. This may be a better option for high bit rate V2X=20 > communication than 5.9 GHz, though of course it has different=20 > characteristics and constraints. >=20 > Best Regards, >=20 > John >=20 > On Thu, Jun 13, 2019 at 2:00 AM J=C3=A9r=C3=B4me H=C3=A4rri = > wrote: >=20 > Dear Alex, >=20 > You are totally right=E2=80=A6applications have increased needs = and it is > not the right wat to tell an application to send less because of > finite capacity of a given technology. One thing to keep in mind > though is that the ITS-G5/DSRC has been designed for the needs of = so > called =E2=80=98day one=E2=80=99 applications (e.g. intersection = collision > avoidance, lane change warning etc..) and it is quite clear that = the > technology is not adapted to other applications, which would = require > more capacity (say it is not the fault of the technology, as it = has > been designed for something and not for something else). >=20 > The applications you are working on fall within the =E2=80=98Day = two=E2=80=99 or > =E2=80=98Day two and half=E2=80=99 (sorry, I am not the one = giving these names=E2=80=A6just > referring to them..) and for these new applications there is > absolutely a need for more capacity. In short, we need to find > better and more efficient ways to transmit much more data for ITS > applications, and indeed not say that people should transmit less = J >=20 > And this is very clear in ETSI, C2C-CC, SAE, even = 5GAA=E2=80=A6there are > specific WG discussing new spectrum usage (10Mhz vs. 20Mhz, > multi-channels, etc..) and the current direction to fulfill the > capacity requirements of these news applications are either IEEE > 802.11bd (the next generation wifi-based V2X) or 5G-V2X (the next > generation C-V2X technology), as frequency rechannelization is > complex in terms of coexistence and using multi-channels require > multi transmitters=E2=80=A6 >=20 > In this perspective, your proposed modification might be seen as a > temporary patch but if it works for your case, that is good, as > there is nothing else available at that time=E2=80=A6And if you = propose a > simpler way of getting more capacity to match day two applications > with day one technology, well this is what I would call research = J=E2=80=A6 >=20 > The point in my previous e-mail was that putting 20MHz in = =E2=80=98iw=E2=80=99 on an > ocb firmware will change a few things at the physical layers that > will affect the performance (in good or bad) of your system..for > instance, the OFDM guard period will be halved, which will make = your > link more sensitive to delay long spreads, or will lose 3dB in > receiver sensitivity, which would impact your Tx range. As I said = in > my previous e-mails, there are various teams that have been > questioning the 10Mhz channel since a =E2=80=98very=E2=80=99 long = time now=E2=80=A6so, there > is no scientific reasons for not trying at 20Mhz and see how it > goes=E2=80=A6yet, it will not be compatible with the current > standards/regulations at that time=E2=80=A6(but does not mean it = would not > change in the future J) >=20 > Please have a look at some of the work from Prof. Eric Str=C3=B6m = of > Chalmers (a nice summary is available here: > = https://pdfs.semanticscholar.org/78ef/e53d238ae75837f5817997f27c74f151969= 8.pdf).=20 > In short, there are clearly performance gains in = perspective=E2=80=A6but it > =E2=80=98really=E2=80=99 depends on some parameters of the channel = that you will > face during your tests. The most important one is the delay = spread. > Eric mentions that a 4nSec is usually agreed, but there are other > studies indicating delay spreads up to 8nsec (also acknowledged by > Eric)=E2=80=A6so, it would simply be interesting to test and see = how it > works in your case=E2=80=A6it would be good if you could have in = your team > or project partners expect in PHY/Channel sounding to double check > the PHY impact of your strategy in your environment=E2=80=A6 >=20 > To conclude, although not fitting to current spectrum regulations, > trying 20Mhz is good as it gets and there are many people = believing > that this could actually help=E2=80=A6but it might not be = sufficient for > your applications (you might not double capacity by doubling the > bandwidth)=E2=80=A6There will be much more benefits from the next = generation > V2X technologies in the very near future (also indicated by Eric = in > its slides, page 24) , which will fulfill your required > performance=E2=80=A6that is why I mentioned that for your required > applications, you should follow what IEEE 802.11bd or 5G-V2X will > are actively being developed as we speak. >=20 > Best Regards, >=20 > J=C3=A9r=C3=B4me >=20 > *From:*its [mailto:its-bounces@ietf.org > ] *On Behalf Of *Alexandre Petrescu > *Sent:* Wednesday 12 June 2019 20:05 > *To:* its@ietf.org > *Subject:* [ipwave] Higher bandwidth is a requirement, not a = number > to avoid >=20 > Hi, >=20 > With respect to the channel width 20MHz capability, which would > probably offer higher bandwidth and less latency. >=20 > I received in private several replies from at least 4 people. I > also had a face to face meeting with our partners. >=20 > I want to say something so I am better understood: it is a > _requirement_ to get higher bandwidth; it is not a number to = avoid. >=20 > If the app people send 10000 RTMAPS 1480byte sized IP messages per > second then it is so because they need it. Yes, that is 10KHz > messages, and not 20Hz; yes, that is 1428byte IP message and not > CAM/BSM 633byte. And yes, that must be satisfied. We should not > tell these people to reduce their outputs. Reducing their outputs > will indeed guarantee better latency for ping, but they will be = less > able to transmit valuable data. >=20 > We should not tell app people to throttle (reduce) their output = down > to 20 messages per second (20Hz). That is nonsense out of = standard > documents. The 20Hz/10Hz/1Hz is data relevant out of GPS chipsets = - > GPS has nothing to do with OCB. >=20 > If in the first platooning tests it worked with less data > transmitted, also the convoy was less performing. We need rich = data > transmitted, not poor data. We need lidar data out of the lidar > directly on OCB, and similar other things. >=20 > Alex >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its >=20 >=20 > --=20 >=20 > John Kenney >=20 > Director and Sr. Principal Researcher >=20 > Toyota InfoTech Labs >=20 > 465 Bernardo Avenue >=20 > Mountain View, CA 94043 >=20 > Tel: 650-694-4160. Mobile: 650-224-6644 >=20 From nobody Thu Jun 20 08:22:41 2019 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D22E1200A3 for ; Thu, 20 Jun 2019 08:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 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_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=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 H9E0fe9qjXAB for ; Thu, 20 Jun 2019 08:22:36 -0700 (PDT) Received: from mail-yw1-xc41.google.com (mail-yw1-xc41.google.com [IPv6:2607:f8b0:4864:20::c41]) (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 A48D7120086 for ; Thu, 20 Jun 2019 08:22:36 -0700 (PDT) Received: by mail-yw1-xc41.google.com with SMTP id z197so1316283ywd.13 for ; Thu, 20 Jun 2019 08:22:36 -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=/W8mezUxv5xiGWRMuop6F76r8wCq5IDcTQHG6AuYEN4=; b=HJx3M9fcXtW5zOACZX3pmuEvdNWvvtSbfAoM6dn+wppRI9Vaf86tL9O9AbkRvEB3s4 n1Ytb312re7tZFHz3b0Uoaa4jVUfGSEwm1jN9pmTAYFjyIa1R2pGnLywuvVAvqYJsXZX 28jEU3/02jq9gybDVT4hENph5ckJY/+DKYuJuWVaXG/pHmdYzoeHjU/+EQH+xBsmfUuP zAR7JMch9eskDA3v2/tFhiJbPhJzN7y16uFIGpHqMvXjTm8JBHuZLnc81Uiy91dDaB6H flgufq0iIN8rBtY6CEd/WTgEIOm3lBwgUKHJ8pUU61KQ5VHOFaVk7A/SwxvXmI2oxMu2 SvlA== 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=/W8mezUxv5xiGWRMuop6F76r8wCq5IDcTQHG6AuYEN4=; b=UckSHIgtXzbl0QXnNHCJ2y8gAI78gy0uzD7jxZAN50NmIaNoBt/3/F20B4McQtu+Kr AyBHMtx3nsIRwHhPW+7Sg4jzXUhP143QiGtM8vkI07/uSZnDb5jnyTouyJTo4j380oHz lngxM/uKmfHyY0fnkoRLMfAOIbEof5jLa7amZW+Bny9iZfpltd1pfT7DMDwOZyAZWteu dCVwoKjOqJ0R13hT667Gp5p1nNpb9tGLvw1+qLYTvHG0S+T/6zBt+yKB5RGw+mx9Qysn 90C+7xAz0lbPHaNSWqIAIjtUMIvRCbTBuOHfqRSuQ39veRV9K63urqHhto+X85nJTrwR IW2Q== X-Gm-Message-State: APjAAAW95YMuN2QzlifRfR971DduF1dtC03FyDodTLoUi990qy7jQ88M zgleubPbeN+aBh34yaGaVMZhst4AeCOHFqOI2/E= X-Google-Smtp-Source: APXvYqy+OllgLEl52rKrW/1fkHZqorSrlhwZnMN3HAQbD1/9f0gooCbmtgHRFuCPFSaOZBfBmoV8mo6+1BZ/IiO9mNg= X-Received: by 2002:a0d:e003:: with SMTP id j3mr31110660ywe.216.1561044155766; Thu, 20 Jun 2019 08:22:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Sara el hamdani Date: Thu, 20 Jun 2019 17:22:23 +0200 Message-ID: To: John Seur Cc: its@ietf.org Content-Type: multipart/alternative; boundary="000000000000621e19058bc2ea7f" Archived-At: Subject: Re: [ipwave] Patching Linux Kernel with OCB X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: 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, 20 Jun 2019 15:22:39 -0000 --000000000000621e19058bc2ea7f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi IPWAVERs, I am in the same team in IPWave track with mister John on Hackathon@AIS201= 9 (https://hackathon.internetsummitafrica.org/). I would like to refer that we have tested the patch proposed by Alex in the mailing list, but it just did not work for us. Instead, we have used the old patch in the link ( https://drive.google.com/file/d/0BxK6WTQZ97QVWF9tRURjOGhBU2c/view ), so we have discovered the bugs described above. I recommand anybody who needs to pach the kernel 4.9.61 with OCB mode to us= e the old pach after fixing the bugs. ___ Sara El Hamdani Garanti sans virus. www.avast.com <#m_1966153803618386632_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> Le jeu. 20 juin 2019 =C3=A0 15:25, John Seur a =C3=A9= crit : > Hello IPWavers, > > During the Hackathon@AIS2019 (https://hackathon.internetsummitafrica.org/= ), > the team in IPWave track (led by Nabil Benamar) was patching the Linux > kernel 4.9.61 with OCB mode and discovered the following bugs in the patc= h > file (https://drive.google.com/file/d/0BxK6WTQZ97QVWF9tRURjOGhBU2c/view). > drivers/net/wireless/ath/ath9k/main.c:961:2: error: duplicate case valu= e > case NL80211_IFTYPE_OCB: > drivers/net/wireless/ath/ath9k/hw.c:1241:2: error: duplicate case value > case NL80211_IFTYPE_OCB: > > The duplicated lines of code were commented out and the patch file works! > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > --=20 *Best regards* *Sara EL HAMDANI* *Phd student -Umi University.* Garanti sans virus. www.avast.com <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> --000000000000621e19058bc2ea7f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi IPWAVERs,

I am in the same team in I= PWave track with mister John on=C2=A0 Hackathon@AIS2019 (https://hackathon.i= nternetsummitafrica.org/). I would like to refer that we have tested th= e patch proposed by Alex in the mailing list, but it just did not work for = us. Instead, we have used the old patch in the link (https://drive.google.com/file/d/0BxK6WTQZ97QVWF9tRURjOGhBU2c/= view), so we have discovered the bugs described above.
I reco= mmand anybody who needs to pach the kernel=C2=A04.9.61 with OCB mode to=C2=A0use the old pach after fixing the b= ugs.

___
Sara El Hamdani

<= /div>
=
3D"" Garanti sans virus. = www.avast.com

Le=C2=A0jeu. 20 juin 2019 =C3=A0=C2=A015:25= , John Seur <jo= hn.seur@gmail.com> a =C3=A9crit=C2=A0:
Hello IPWavers,

Durin= g the Hackathon@AIS2019 (https://hackathon.internetsummitafrica.org/), t= he team in IPWave track (led by Nabil Benamar) was patching the Linux kerne= l 4.9.61 with OCB mode and discovered the following bugs in the patch file = (https://drive.google.com/file/d/0BxK6WTQZ97QVWF9tRURj= OGhBU2c/view).
=C2=A0 drivers/net/wireless/ath/ath9k/main.c:961:2: e= rror: duplicate case value
=C2=A0 case NL80211_IFTYPE_OCB:
=C2=A0 dri= vers/net/wireless/ath/ath9k/hw.c:1241:2: error: duplicate case value
=C2= =A0 case NL80211_IFTYPE_OCB:
=C2=A0
The duplicated lines of code wer= e commented out and the patch file works!
_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its


--
= Best regards

Sara EL HAMDANI
Phd student=C2=A0-Umi University.

3D"" Garanti sans virus. = www.avast.com
=
--000000000000621e19058bc2ea7f-- From nobody Fri Jun 21 02:30:27 2019 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9F01201CE for ; Fri, 21 Jun 2019 02:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NoDKnBF2qs1U for ; Fri, 21 Jun 2019 02:30: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 791DE1201C7 for ; Fri, 21 Jun 2019 02:30:22 -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 x5L9UHmR012265; Fri, 21 Jun 2019 11:30:17 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A4D45203387; Fri, 21 Jun 2019 11:30:17 +0200 (CEST) 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 92D2420330E; Fri, 21 Jun 2019 11:30:17 +0200 (CEST) Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x5L9UH5r012928; Fri, 21 Jun 2019 11:30:17 +0200 To: dickroy@alum.mit.edu, =?UTF-8?B?J0rDqXLDtG1lIEjDpHJyaSc=?= , "'John Kenney'" Cc: "'its'" References: <24309460-0172-60f1-f2e8-7cc57d152167@gmail.com> <00b601d521c6$7038a7a0$50a9f6e0$@eurecom.fr> <01de01d5276f$00911960$01b34c20$@eurecom.fr> From: Alexandre Petrescu Message-ID: <5776cb65-4194-60bf-ab6c-14d458f15c08@gmail.com> Date: Fri, 21 Jun 2019 11:30:17 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 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] Higher bandwidth is a requirement, not a number to avoid X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: 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, 21 Jun 2019 09:30:26 -0000 Le 20/06/2019 16:49, Dick Roy a crit: > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu > Sent: Thursday, June 20, 2019 7:13 AM > To: Jrme Hrri; 'John Kenney' > Cc: 'its' > Subject: Re: [ipwave] Higher bandwidth is a requirement, not a number to > avoid > > Le 20/06/2019 15:49, Jrme Hrri a crit: > > [...] > >> as they do not really represent > >> what an automotive-grade ITS-G5/DSRC is really capable of doing. > > What is the bandwidth of IPv6 demonstrated on ITS-G5/DSRC? > > */[RR] IPV6 does not have a bandwidth. The ITS-G5/DSRC access layers > currently have 10MHz (and 20MHz in the US)bandwidth channels specified > if thats your question./* What is the bandwidth afforded by an application using TCP/IPv6 on ITS-G5/DSRC? Alex > > Alex > > _______________________________________________ > > its mailing list > > its@ietf.org > > https://www.ietf.org/mailman/listinfo/its > From nobody Fri Jun 21 03:59:19 2019 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9B1120227 for ; Fri, 21 Jun 2019 03:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.631 X-Spam-Level: X-Spam-Status: No, score=-1.631 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_HELO_NONE=0.001, 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 0PpJW7ESaMyJ for ; Fri, 21 Jun 2019 03:59:14 -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 42200120228 for ; Fri, 21 Jun 2019 03:59:14 -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 x5LAxBmI028524 for ; Fri, 21 Jun 2019 12:59:11 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C3BA3206133 for ; Fri, 21 Jun 2019 12:59:11 +0200 (CEST) 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 B880C206097 for ; Fri, 21 Jun 2019 12:59:11 +0200 (CEST) Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x5LAxBYh021777 for ; Fri, 21 Jun 2019 12:59:11 +0200 To: its@ietf.org References: From: Alexandre Petrescu Message-ID: <55d53f81-7746-2be2-e882-28e7712951a5@gmail.com> Date: Fri, 21 Jun 2019 12:59:11 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 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] Patching Linux Kernel with OCB X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: 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, 21 Jun 2019 10:59:17 -0000 Le 20/06/2019 à 17:22, Sara el hamdani a écrit : > Hi IPWAVERs, > > I am in the same team in IPWave track with mister John on > Hackathon@AIS2019 (https://hackathon.internetsummitafrica.org/). I would > like to refer that we have tested the patch proposed by Alex in the > mailing list, but it just did not work for us. Instead, we have used the > old patch in the link > (https://drive.google.com/file/d/0BxK6WTQZ97QVWF9tRURjOGhBU2c/view > ), > so we have discovered the bugs described above. > I recommand anybody who needs to pach the kernel 4.9.61 with OCB mode > to use the old pach after fixing the bugs. Hi Sara, I thank you very much for the report. It is good that you patch OCB for kernel 4.9.61. It is a very recent kernel, although the most recent seems to be 5.1.12. For information, I have been patching around the kernels since kernel version 3.x. Before that, some people did it for kernels 2.x if I remember correctly. A few patches existed in public and in private. At my organisation we currently work with a private patch for kernel version 4.something. It relies on the OCB options in the mainline kernel There are other organisations on this email list that work with some other patches for 4.something. There are also a few patches on github.com. Some of them were originated by a Grand Challenge contest in Europe. You now mention the patch at https://drive.google.com/file/d/0BxK6WTQZ97QVWF9tRURjOGhBU2c/view I would like to ask you who created it? (organisation, or group, or person name). I would also like to ask you whether, in addition of the OCB patch, you also used the OCB options in the normal kernel configuration? (did you do make menuconfig and checked 'OCB' in some option, or not at all?) This OCB patch is worth setting aside somewhere on a fixed web page, so that everybody can use it. There are many people who created OCB patches. They seem to have a temporary interest in the matter: most of them no longer maintain their patches. Each person starts from an earlier version, upgrade to most recent linux and then move on work on other topic. Alex > > ___ > Sara El Hamdani > > > Garanti sans virus. www.avast.com > > > > <#m_1966153803618386632_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > Le jeu. 20 juin 2019 à 15:25, John Seur > a écrit : > > Hello IPWavers, > > During the Hackathon@AIS2019 > (https://hackathon.internetsummitafrica.org/), the team in IPWave > track (led by Nabil Benamar) was patching the Linux kernel 4.9.61 > with OCB mode and discovered the following bugs in the patch file > (https://drive.google.com/file/d/0BxK6WTQZ97QVWF9tRURjOGhBU2c/view). >   drivers/net/wireless/ath/ath9k/main.c:961:2: error: duplicate > case value >   case NL80211_IFTYPE_OCB: >   drivers/net/wireless/ath/ath9k/hw.c:1241:2: error: duplicate case > value >   case NL80211_IFTYPE_OCB: > > The duplicated lines of code were commented out and the patch file > works! > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > > > -- > *Best regards* > * > * > /Sara EL HAMDANI > / > /Phd student -Umi University./ > > > Garanti sans virus. www.avast.com > > > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > From nobody Fri Jun 21 04:00:59 2019 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5098120228 for ; Fri, 21 Jun 2019 04:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ei3v7n00fOQm for ; Fri, 21 Jun 2019 04:00:54 -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 2222C120227 for ; Fri, 21 Jun 2019 04:00:53 -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 x5LB0pNC044757 for ; Fri, 21 Jun 2019 13:00:51 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id CB3CE2060E7 for ; Fri, 21 Jun 2019 13:00:51 +0200 (CEST) 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 C1A54206097 for ; Fri, 21 Jun 2019 13:00:51 +0200 (CEST) Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x5LB0pCI022977 for ; Fri, 21 Jun 2019 13:00:51 +0200 To: its@ietf.org References: From: Alexandre Petrescu Message-ID: Date: Fri, 21 Jun 2019 13:00:51 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 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] Patching Linux Kernel with OCB X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: 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, 21 Jun 2019 11:00:57 -0000 Hello Mr. Seur, I would like to ask you whether you can apply that patch to ath10k also? (instead of ath9k). If you do, you risk being the first to achieve 1Gbps on OCB, hopefully with IPv6. Alex Le 20/06/2019 à 15:25, John Seur a écrit : > Hello IPWavers, > > During the Hackathon@AIS2019 > (https://hackathon.internetsummitafrica.org/), the team in IPWave track > (led by Nabil Benamar) was patching the Linux kernel 4.9.61 with OCB > mode and discovered the following bugs in the patch file > (https://drive.google.com/file/d/0BxK6WTQZ97QVWF9tRURjOGhBU2c/view). >   drivers/net/wireless/ath/ath9k/main.c:961:2: error: duplicate case value >   case NL80211_IFTYPE_OCB: >   drivers/net/wireless/ath/ath9k/hw.c:1241:2: error: duplicate case value >   case NL80211_IFTYPE_OCB: > > The duplicated lines of code were commented out and the patch file works! > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > From nobody Fri Jun 21 04:12:43 2019 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D45812022B for ; Fri, 21 Jun 2019 04:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ssrn66aVDEC7 for ; Fri, 21 Jun 2019 04:12:36 -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 0CE8F120226 for ; Fri, 21 Jun 2019 04:12:35 -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 x5LBCWns047664; Fri, 21 Jun 2019 13:12:32 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 97CF820612E; Fri, 21 Jun 2019 13:12:32 +0200 (CEST) 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 8584420610B; Fri, 21 Jun 2019 13:12:32 +0200 (CEST) Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x5LBCWZn030528; Fri, 21 Jun 2019 13:12:32 +0200 To: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= Cc: "'its'" , "'John Kenney'" References: <24309460-0172-60f1-f2e8-7cc57d152167@gmail.com> <00b601d521c6$7038a7a0$50a9f6e0$@eurecom.fr> <01de01d5276f$00911960$01b34c20$@eurecom.fr> <933a52e6-c0e1-f5d6-6443-ddb189be958c@gmail.com> <021b01d5277a$ea45bd30$bed13790$@eurecom.fr> From: Alexandre Petrescu Message-ID: <5b88f2ea-5a3d-7f1f-c374-afbebb40b6e2@gmail.com> Date: Fri, 21 Jun 2019 13:12:32 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: <021b01d5277a$ea45bd30$bed13790$@eurecom.fr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Higher bandwidth is a requirement, not a number to avoid X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: 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, 21 Jun 2019 11:12:40 -0000 Le 20/06/2019 à 17:14, Jérôme Härri a écrit : > Hi Alex, > > The automotive-grade ITS-G5/DSRC devices have an enhanced PHY > (something called channel tracking, among other things that I am most > likely not aware...). If you are interested, this is a nice paper > illustrating the issues of regular DOT11p devices confronted to fast > time varying channels..."Andre Bourdoux, Hans Cappelle, Antoine > Dejonghe, Channel Tracking for Fast Time-Varying Channels in > IEEE802.11p Systems, IEEE globecome 2011" Such enhanced PHY is > located in the wifi modem, not in a driver (that is the > 'closed/protected' part of the wifi stack in linux)...I am not aware > of a way to be able to add this on a linux wifi driver. But such > enhancement really adds more reliability to the ITS-G5/DSRC system > (increased range, improved PDR).. > > But you are correct...using the wifi DOTa with OCB at 10Mhz follows > the standard...it is a valid DOT11p device...but it is not the best > an Wifi-V2X system can do...My point is to say that all WiFi > OCB/10Mhz are WiFi-V2X but not all WiFi-V2X are WiFi OCB/10MHz..and > as in any field, there are better products than others (thus the > business behind it :-) )... I agree we should distinguish the two terms. To that end, we would need to agree on the names of the terms. On my side, I will use 'open-source' OCB vs 'proprietary' OCB. You seem to be used DOTa/10MHz vs 'automotive-grade'. You used other terms as well. Other people I heard also saying to me that I just use an 'a' driver modified. I did not know that, but I agree to them. > So, using an 'automotive-grade' (I use brackets as indeed this > usually refer to more than just performance...) could be one option > to get closer to the performance you need...but of course, and as I > mentioned in my early e-mail, it might not be enough for the very > reason that DOT11p (generic and automotive-grade) have been designed > with the performance requirements identified for Day One > applications, not Day Two... The 'automotive-grade' is thus not a DOTa/10MHz. I think the 'automotive-grade' OCB is something like Autotalks chips. That is closed source, not open source. That is something much more expensive than DOTa/10MHz. I thank you for the recommendation to use 'automotive-grade' OCB. I consider it, but I am not likely to use it, because of cost. It is for this reason that I think I will skip the use of 'automotive-grade' OCB towards increasing the bandwidth. Others may do differently. (try first 'automotive-grade' OCB to obtain higher bandwidth than DOTa/10MHz). I would rather look at trying the DOTa/10MHz with a 20MHz channel width. Also try the OCB patch on ath10k driver. Maybe I will get as much bandwidth, or even more, than the automotive-grade OCB, and at a lower cost. > So indeed, increasing bandwidth (20Mhz) or dynamically adapting > modulation or replacing DOT11p with DOT11bd are other potential > strategies...and stakeholders are very aware of this...there is a > need for more capacity, thus we need to do something to get it :-) I agree with you. What do you mean by 'dynamically adapting the modulation'? Do you mean it is possible to use an 'iw' command to select a modulator like 'ofdm' vs 'something-else-dm'? Alex > > Best Regards, > > Jérôme > > -----Original Message----- From: Alexandre Petrescu > [mailto:alexandre.petrescu@gmail.com] Sent: Thursday 20 June 2019 > 16:12 To: Jérôme Härri; 'John Kenney' Cc: 'its' Subject: Re: [ipwave] > Higher bandwidth is a requirement, not a number to avoid > > I think all I am talking about is what you call a DOT11a/10MHz > patch. IT is actually no longer a patch, because OCB is now > integrated in the linux mainline kernel. > > I am talking linux, because BSD does not support OCB. > > Whereas I agree with you that the 'automotive grade' qualifier is > commonly used to indicate higher quality, on my side I think it is > used to justify more expensive OCB devices than others. I can not > say I understand what the quality is about. > > It may be that what is meant by quality for some, is less quality > for others. > > It may be that what is meant by 'quality' in laboratory, is > something that never sees the light in the streets. > > It may be that a higher quality product acts excellent when everybody > is in a single channel, but less well when multiple channels are > used. > > Since this spectrum is not under the control of authority, it is hard > to define what is quality. But it is easy to experiment. > > That, said, I can tell the numbers in my trials. It is with linux, > cheap WiFi 'a' cards, and OCB open source in mainline kernel. > > Between two cars, the IPv6 bandwidth with iperf TCP packets peaks at > around 7mbit/s. During that flow, the RTT of ping is about 50ms. On > an empty channel (no iperf traffic), the RTT of ping is on average > 1.4ms. > > What I need is to be able to allow the RTMAPS programmers to send > their packets with a frequency of 20kHz. (20.000 TCP/IPv6 packets > per second). When they try that, the latency they get is around > 500ms. It is way too much. It means the distance between platooned > cars is way too much. > > 20kHz may appear as a programmer error, but it is not. The > programmer should not be told to reduce their output. It is the > network that must accommodate it. > > If in my OCB deployment I get a bandwidth at around 1Gbit/s (vs. > current 7Mbit/s), then I can share the lidar data between cars. > That translates to huge reduction in cost. The cheapest lidar is > around 7Keur, but most expensive can be 30Keur. A cheap car is > cheaper than a lidar. > > Some of the lidars are connected on Gbit Ethernet. > > A higher than current 7Mbit/s on OCB can be obtained by several > means: - try the iw command to use 20MHz width, instead of 10. It > would theoretically increase the bandwidth to 14Mbit/s. It's not > 1Gbpbs, but it's more. - other linux commands? - make the OCB patch > apply to ath10k, not the ath9k currently. That is something that > nobody tried. Even if one does not have an ath10k card (802.11ac) > one could still try to adapt the OCB patch for the C code, and see > whether it compiles. If it compiles, it is already a good step > forward. We'll see later about the execution. > > Maybe you know other means by which to achieve higher bandwidth on > OCB? > > Alex > > Le 20/06/2019 à 15:49, Jérôme Härri a écrit : >> Hi John, Alex, >> >> Thanks for the details. >> >> I would also like to add another point that I forgot to mentioned. >> @Alex did not mention if the DOT11p radio is an automotive-grade or >> a DOT11a/10Mhz patch… >> >> Of course, both are valid OCB devices BUT…it has been shown on >> many occasions that the performance of a DOT11a patched for >> OCB/10Mhz show significantly lower performance compared to the >> state-of-art automotive grade ITS-G5 devices. >> >> If the tests have been done with a DOT11a patched OCB, then this >> could also be a reason for the limited capacity. Generally >> speaking, the current automotive-grade ITS-G5 devices are not >> DOT11a/10Mhz patched devices anymore and have enhanced PHY features >> that make around 3-5 dB gain in BER/SNR curves compared to normal >> patched DOT11a. This is significant !! >> >> But indeed, these devices are more expensive than a normal wifi >> chip and if a normal wifi board is patched for OCB/10Mhz, then it >> is an IEEE 802.11p device. They can clearly be used for networking >> (ip, ad-hoc, etc..) test, but I would suggest not to use these >> patched devices as a reference for link-layer/capacity tests, as >> they do not really represent what an automotive-grade ITS-G5/DSRC >> is really capable of doing. >> >> BR, >> >> Jérôme >> >> *From:*John Kenney [mailto:jkenney@us.toyota-itc.com] *Sent:* >> Saturday 15 June 2019 02:25 *To:* Jérôme Härri *Cc:* Alexandre >> Petrescu; its *Subject:* Re: [ipwave] Higher bandwidth is a >> requirement, not a number to avoid >> >> Hi Jérôme and Alex, >> >> Sorry I have not followed this discussion in detail. If any of my >> comments are off base, I apologize. >> >> Having read Jérôme's comments, I want to agree with them. I >> especially want to emphasize that if we are considering operating >> in public spectrum (5.9 GHz in most regions) we have to be >> cognizant of how our channel use may impact other users whose >> applications are equally important from a public safety >> perspective, perhaps even more important. This is one reason why >> so many resources have been devoted to researching and testing >> channel scalability protocols (congestion control). In the US, the >> FCC bandplan and the SAE J2945/0 standard channel usage plan >> specify that every channel will be available for use by safety >> applications. >> >> One additional note about channel bandwidth. IEEE 802.11 >> specifies channel width options of 20 MHz, 10 MHz, and 5 MHz in the >> 5.9 GHz bands of the US and Europe. Spectrum regulations further >> limit those to 20 MHz and 10 MHz in the US and only 10 MHz in >> Europe. However, while 20 MHz channels are in the FCC regulations >> for the US, we do not expect overlapping 20 MHz and 10 MHz to be >> used in the same time and place. CSMA/CA will not work well in such >> an overlapping case because the devices will not natively detect >> each other's preambles. In fact, 10 MHz usage is the norm, and we >> do not expect to see 20 MHz usage in the US. >> >> This may change with the development of IEEE 802.11bd (Next >> Generation V2X), which Jérôme mentioned. That task group is >> considering ways to specify a 20 MHz channel that coexists well >> with constituent 10 MHz users (both 802.11bd and 802.11p). >> >> One final point. Some V2X researchers are quite interested in >> using 60 GHz mmWave spectrum for dissemination of information >> requiring bit rates on the order of 100s Mbps or 1 Gpbs. This is >> an active area of research. This may be a better option for high >> bit rate V2X communication than 5.9 GHz, though of course it has >> different characteristics and constraints. >> >> Best Regards, >> >> John >> >> On Thu, Jun 13, 2019 at 2:00 AM Jérôme Härri >> > >> wrote: >> >> Dear Alex, >> >> You are totally right…applications have increased needs and it is >> not the right wat to tell an application to send less because of >> finite capacity of a given technology. One thing to keep in mind >> though is that the ITS-G5/DSRC has been designed for the needs of >> so called ‘day one’ applications (e.g. intersection collision >> avoidance, lane change warning etc..) and it is quite clear that >> the technology is not adapted to other applications, which would >> require more capacity (say it is not the fault of the technology, >> as it has been designed for something and not for something else). >> >> The applications you are working on fall within the ‘Day two’ or >> ‘Day two and half’ (sorry, I am not the one giving these >> names…just referring to them..) and for these new applications >> there is absolutely a need for more capacity. In short, we need to >> find better and more efficient ways to transmit much more data for >> ITS applications, and indeed not say that people should transmit >> less J >> >> And this is very clear in ETSI, C2C-CC, SAE, even 5GAA…there are >> specific WG discussing new spectrum usage (10Mhz vs. 20Mhz, >> multi-channels, etc..) and the current direction to fulfill the >> capacity requirements of these news applications are either IEEE >> 802.11bd (the next generation wifi-based V2X) or 5G-V2X (the next >> generation C-V2X technology), as frequency rechannelization is >> complex in terms of coexistence and using multi-channels require >> multi transmitters… >> >> In this perspective, your proposed modification might be seen as a >> temporary patch but if it works for your case, that is good, as >> there is nothing else available at that time…And if you propose a >> simpler way of getting more capacity to match day two applications >> with day one technology, well this is what I would call research >> J… >> >> The point in my previous e-mail was that putting 20MHz in ‘iw’ on >> an ocb firmware will change a few things at the physical layers >> that will affect the performance (in good or bad) of your >> system..for instance, the OFDM guard period will be halved, which >> will make your link more sensitive to delay long spreads, or will >> lose 3dB in receiver sensitivity, which would impact your Tx range. >> As I said in my previous e-mails, there are various teams that have >> been questioning the 10Mhz channel since a ‘very’ long time now…so, >> there is no scientific reasons for not trying at 20Mhz and see how >> it goes…yet, it will not be compatible with the current >> standards/regulations at that time…(but does not mean it would not >> change in the future J) >> >> Please have a look at some of the work from Prof. Eric Ström of >> Chalmers (a nice summary is available here: >> https://pdfs.semanticscholar.org/78ef/e53d238ae75837f5817997f27c74f1519698.pdf). >> >> In short, there are clearly performance gains in perspective…but it >> ‘really’ depends on some parameters of the channel that you will >> face during your tests. The most important one is the delay >> spread. Eric mentions that a 4nSec is usually agreed, but there are >> other studies indicating delay spreads up to 8nsec (also >> acknowledged by Eric)…so, it would simply be interesting to test >> and see how it works in your case…it would be good if you could >> have in your team or project partners expect in PHY/Channel >> sounding to double check the PHY impact of your strategy in your >> environment… >> >> To conclude, although not fitting to current spectrum regulations, >> trying 20Mhz is good as it gets and there are many people >> believing that this could actually help…but it might not be >> sufficient for your applications (you might not double capacity by >> doubling the bandwidth)…There will be much more benefits from the >> next generation V2X technologies in the very near future (also >> indicated by Eric in its slides, page 24) , which will fulfill your >> required performance…that is why I mentioned that for your >> required applications, you should follow what IEEE 802.11bd or >> 5G-V2X will are actively being developed as we speak. >> >> Best Regards, >> >> Jérôme >> >> *From:*its [mailto:its-bounces@ietf.org >> ] *On Behalf Of *Alexandre Petrescu >> *Sent:* Wednesday 12 June 2019 20:05 *To:* its@ietf.org >> *Subject:* [ipwave] Higher bandwidth is a >> requirement, not a number to avoid >> >> Hi, >> >> With respect to the channel width 20MHz capability, which would >> probably offer higher bandwidth and less latency. >> >> I received in private several replies from at least 4 people. I >> also had a face to face meeting with our partners. >> >> I want to say something so I am better understood: it is a >> _requirement_ to get higher bandwidth; it is not a number to >> avoid. >> >> If the app people send 10000 RTMAPS 1480byte sized IP messages per >> second then it is so because they need it. Yes, that is 10KHz >> messages, and not 20Hz; yes, that is 1428byte IP message and not >> CAM/BSM 633byte. And yes, that must be satisfied. We should not >> tell these people to reduce their outputs. Reducing their outputs >> will indeed guarantee better latency for ping, but they will be >> less able to transmit valuable data. >> >> We should not tell app people to throttle (reduce) their output >> down to 20 messages per second (20Hz). That is nonsense out of >> standard documents. The 20Hz/10Hz/1Hz is data relevant out of GPS >> chipsets - GPS has nothing to do with OCB. >> >> If in the first platooning tests it worked with less data >> transmitted, also the convoy was less performing. We need rich >> data transmitted, not poor data. We need lidar data out of the >> lidar directly on OCB, and similar other things. >> >> Alex >> >> _______________________________________________ its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >> >> >> -- >> >> John Kenney >> >> Director and Sr. Principal Researcher >> >> Toyota InfoTech Labs >> >> 465 Bernardo Avenue >> >> Mountain View, CA 94043 >> >> Tel: 650-694-4160. Mobile: 650-224-6644 >> > > From nobody Fri Jun 21 04:41:46 2019 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDFAC120229 for ; Fri, 21 Jun 2019 04:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 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_HELO_NONE=0.001, 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 zSQG5CltNTUX for ; Fri, 21 Jun 2019 04:41:43 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C34B1200D8 for ; Fri, 21 Jun 2019 04:41:42 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id i21so5679253ljj.3 for ; Fri, 21 Jun 2019 04:41:42 -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=dgBtRQQ3+90xTHB023XlcOn3f1JsqSSt5NEBlFWq0rk=; b=iujL4jsQ6si4ZU5KI5it0hcSoBpYlQIpKKsxAd0Gtmcj02DHqIztLX44CaV9PQbAqW bBRWTdFFT8vRIHyMu5sRCrCN1EcFyULxh8nQ7jK5loRXAp2FUmwgRBpHrVyOIYqMKSug G2IKsWUV8+lF3Kx6WDAKyGP+Y0ao9M/WIlM2hH7ZuuFzI23Ujb2avBVRdcjEzAjOyr0f iFw+X8sUaPF82p7UadZ/5K8M0U4H3Lzbwc6TOgrWerV7Ds8/JqNDpgmYr+fO0s9ethCT zKgEKKmyQZ5IVSjDFPMQagMbIsIzFCQEXxmhtNStwXvHY1y/RXWS0vbGS1VASY5k2VIk K3aw== 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=dgBtRQQ3+90xTHB023XlcOn3f1JsqSSt5NEBlFWq0rk=; b=StrjQQ/7eViG2yD9r9AZjShhPMFjCNgPEtdvPa8S8eQJ0liSWUDiicX/WvH1iQbXCa ZNXiZbQyerSdJ+palVgbZTCBBd3Yn3wnm+CmvQUkn6Kopct0HRgX0zekrcAZzW2ouyk4 ZjmIpsHSYFxknE0FgnuDrRQUVhHLp9hN/RKl4l9HcHwmaozwx35ahcZYGF55V54FPMTX 4/MjneaITASjbDO/XH+EprmM2eJ6IPM2rlMz2Qa3wkjQZ/Lbd4MowF3ANv2BE8HeBHwl sNgOqqa9iowDJKF5vb7NGCOKEYxVHL9cLAZqa4wH8P7Pzked6TjIYWvV9eqbtEpU6igy T97A== X-Gm-Message-State: APjAAAX/ET7bdJIrR9mLO1fKtVUQoRRUL/Qn6b8gz32oT2ylNpO9Ybne 3mwA653GcC1Pza4jo+QM/bT8LbndNnCxAva45CM= X-Google-Smtp-Source: APXvYqwxHOU/uFPAEd2eymvapvl9/wq44rxoBKVqI53ReLNyxg1omuWAYWjnrFew85jJ0tBu53KQNT1dBjEQkqxh9OY= X-Received: by 2002:a05:651c:150:: with SMTP id c16mr30822747ljd.193.1561117300215; Fri, 21 Jun 2019 04:41:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Nabil Benamar Date: Fri, 21 Jun 2019 14:41:35 +0300 Message-ID: To: Alexandre Petrescu Cc: its@ietf.org Content-Type: multipart/alternative; boundary="00000000000021d2dc058bd3f27a" Archived-At: Subject: Re: [ipwave] Patching Linux Kernel with OCB X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: 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, 21 Jun 2019 11:41:45 -0000 --00000000000021d2dc058bd3f27a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alex, Thank you for your comments. This is exactly what the hackathon participants put in future work! 2 days were not enough to build the testbed and test different drivers and parameters... On Fri, Jun 21, 2019, 14:01 Alexandre Petrescu wrote: > Hello Mr. Seur, > > I would like to ask you whether you can apply that patch to ath10k also? > (instead of ath9k). > > If you do, you risk being the first to achieve 1Gbps on OCB, hopefully > with IPv6. > > Alex > > Le 20/06/2019 =C3=A0 15:25, John Seur a =C3=A9crit : > > Hello IPWavers, > > > > During the Hackathon@AIS2019 > > (https://hackathon.internetsummitafrica.org/), the team in IPWave track > > (led by Nabil Benamar) was patching the Linux kernel 4.9.61 with OCB > > mode and discovered the following bugs in the patch file > > (https://drive.google.com/file/d/0BxK6WTQZ97QVWF9tRURjOGhBU2c/view). > > drivers/net/wireless/ath/ath9k/main.c:961:2: error: duplicate case > value > > case NL80211_IFTYPE_OCB: > > drivers/net/wireless/ath/ath9k/hw.c:1241:2: error: duplicate case > value > > case NL80211_IFTYPE_OCB: > > > > The duplicated lines of code were commented out and the patch file work= 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 > --00000000000021d2dc058bd3f27a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alex,

Tha= nk you for your comments.
This is exactly what the h= ackathon participants put in future work!

=
2 days were not enough to build the testbed and test diff= erent drivers and parameters...

<= div dir=3D"ltr" class=3D"gmail_attr">On Fri, Jun 21, 2019, 14:01 Alexandre = Petrescu <alexandre.petr= escu@gmail.com> wrote:
Hello= Mr. Seur,

I would like to ask you whether you can apply that patch to ath10k also? (instead of ath9k).

If you do, you risk being the first to achieve 1Gbps on OCB, hopefully
with IPv6.

Alex

Le 20/06/2019 =C3=A0 15:25, John Seur a =C3=A9crit=C2=A0:
> Hello IPWavers,
>
> During the Hackathon@AIS2019
> (https://hackathon.internetsummitafrica.o= rg/), the team in IPWave track
> (led by Nabil Benamar) was patching the Linux kernel 4.9.61 with OCB <= br> > mode and discovered the following bugs in the patch file
> (https://drive.goog= le.com/file/d/0BxK6WTQZ97QVWF9tRURjOGhBU2c/view).
>=C2=A0 =C2=A0 drivers/net/wireless/ath/ath9k/main.c:961:2: error: dupli= cate case value
>=C2=A0 =C2=A0 case NL80211_IFTYPE_OCB:
>=C2=A0 =C2=A0 drivers/net/wireless/ath/ath9k/hw.c:1241:2: error: duplic= ate case value
>=C2=A0 =C2=A0 case NL80211_IFTYPE_OCB:
>
> The duplicated lines of code were commented out and the patch file wor= ks!
>
> _______________________________________________
> 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
--00000000000021d2dc058bd3f27a-- From nobody Sat Jun 22 08:37:02 2019 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 899FC120058 for ; Sat, 22 Jun 2019 08:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgHo52KW1keP for ; Sat, 22 Jun 2019 08:36:58 -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 63FD212004F for ; Sat, 22 Jun 2019 08:36:57 -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 x5MFaoQX040689; Sat, 22 Jun 2019 17:36:50 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C72FD20183C; Sat, 22 Jun 2019 17:36:50 +0200 (CEST) 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 B1D1D200D12; Sat, 22 Jun 2019 17:36:50 +0200 (CEST) Received: from [132.166.86.2] ([132.166.86.2]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x5MFanYL003688; Sat, 22 Jun 2019 17:36:49 +0200 To: dickroy@alum.mit.edu, =?UTF-8?B?J0rDqXLDtG1lIEjDpHJyaSc=?= , "'John Kenney'" Cc: "'its'" References: <24309460-0172-60f1-f2e8-7cc57d152167@gmail.com> <00b601d521c6$7038a7a0$50a9f6e0$@eurecom.fr> <01de01d5276f$00911960$01b34c20$@eurecom.fr> <5776cb65-4194-60bf-ab6c-14d458f15c08@gmail.com> From: Alexandre Petrescu Message-ID: Date: Sat, 22 Jun 2019 17:36:49 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D425D01557DCB588D4647DB5" Content-Language: fr Archived-At: Subject: Re: [ipwave] Higher bandwidth is a requirement, not a number to avoid X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: 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, 22 Jun 2019 15:37:01 -0000 This is a multi-part message in MIME format. --------------D425D01557DCB588D4647DB5 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit When people write apps they need to know the bandwidth they could afford. E.g. I could be brave and try write skype with HD video and 192KHz audio but that would never work on 56Kbit/s bandwidth modem. Remark I am saying HD video, and people understand approximately what kind of bandwidth is needed, assuming a certain encoder ranging from no compression to high performance H. something. I am also saying 192KHz which is a sampling rate (not bandwidth) but people understand what kind od bandwidth that would request, depending on the encoder used ranging from RAW (no compression) to high quality open source compression in Ogg. Avoiding numbers of bandwidth available for IPv6 on ITS-G5 for high-quality chipsets means that probably the high quality chipsets never tried to send IPv6 on it. OTherwise they could have seen the bandwidth. On another hand, the bandwidth afforded by IPv6 iperf command on an open source DOT11a/10MHz driver is approximately 7mbit/s. This is why there is where the focus of a standard should be: on the open source DOT11a/10MHz basis, not on the high-quality chipsets. Of course, there are also the theoretical numbers (1Mbit/s, 2, 5, 16, 48, etc). They are obtained from calculations on numbers, not from experimenting. These numbers are theoretical upper limits of actual banwidth. It is well known these limits are never reached. Le 21/06/2019 22:09, Dick Roy a crit: > > What is the bandwidth afforded by an application using TCP/IPv6 on > > ITS-G5/DSRC? > > Applications dont have bandwidths. They may have information (aka > data) rate requirements often specified in [G/M/K]bits per second, not > in Hertz. Whether or not any particular network and transport layer > technology is used is irrelevant. Not sure what you are asking. > > RR > > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu > Sent: Friday, June 21, 2019 2:30 AM > To: dickroy@alum.mit.edu; 'Jrme Hrri'; 'John Kenney' > Cc: 'its' > Subject: Re: [ipwave] Higher bandwidth is a requirement, not a number > to avoid > > Le 20/06/2019 16:49, Dick Roy a crit: > > > -----Original Message----- > > > From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu > > > Sent: Thursday, June 20, 2019 7:13 AM > > > To: Jrme Hrri; 'John Kenney' > > > Cc: 'its' > > > Subject: Re: [ipwave] Higher bandwidth is a requirement, not a number to > > > avoid > > > > > > Le 20/06/2019 15:49, Jrme Hrri a crit: > > > > > > [...] > > > > > >> as they do not really represent > > > > > >> what an automotive-grade ITS-G5/DSRC is really capable of doing. > > > > > > What is the bandwidth of IPv6 demonstrated on ITS-G5/DSRC? > > > > > > */[RR] IPV6 does not have a bandwidth. The ITS-G5/DSRC access layers > > > currently have 10MHz (and 20MHz in the US)bandwidth channels specified > > > if thats your question./* > > What is the bandwidth afforded by an application using TCP/IPv6 on > > ITS-G5/DSRC? > > Alex > > > > > > 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 > --------------D425D01557DCB588D4647DB5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

When people write apps they need to know the bandwidth they could afford. E.g. I could be brave and try write skype with HD video and 192KHz audio but that would never work on 56Kbit/s bandwidth modem.

Remark I am saying HD video, and people understand approximately what kind of bandwidth is needed, assuming a certain encoder ranging from no compression to high performance H. something. I am also saying 192KHz which is a sampling rate (not bandwidth) but people understand what kind od bandwidth that would request, depending on the encoder used ranging from RAW (no compression) to high quality open source compression in Ogg.

Avoiding numbers of bandwidth available for IPv6 on ITS-G5 for high-quality chipsets means that probably the high quality chipsets never tried to send IPv6 on it. OTherwise they could have seen the bandwidth.

On another hand, the bandwidth afforded by IPv6 iperf command on an open source DOT11a/10MHz driver is approximately 7mbit/s. This is why there is where the focus of a standard should be: on the open source DOT11a/10MHz basis, not on the high-quality chipsets.

Of course, there are also the theoretical numbers (1Mbit/s, 2, 5, 16, 48, etc). They are obtained from calculations on numbers, not from experimenting. These numbers are theoretical upper limits of actual banwidth. It is well known these limits are never reached.

Le 21/06/2019 22:09, Dick Roy a crit:

What is the bandwidth afforded by an application using TCP/IPv6 on

ITS-G5/DSRC?

Applications dont have bandwidths. They may have information (aka data) rate requirements often specified in [G/M/K]bits per second, not in Hertz. Whether or not any particular network and transport layer technology is used is irrelevant. Not sure what you are asking.

RR

-----Original Message-----
From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu
Sent: Friday, June 21, 2019 2:30 AM
To: dickroy@alum.mit.edu; 'Jrme Hrri'; 'John Kenney'
Cc: 'its'
Subject: Re: [ipwave] Higher bandwidth is a requirement, not a number to avoid

Le 20/06/2019 16:49, Dick Roy a crit:

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

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

> Sent: Thursday, June 20, 2019 7:13 AM

> To: Jrme Hrri; 'John Kenney'

> Cc: 'its'

> Subject: Re: [ipwave] Higher bandwidth is a requirement, not a number to

> avoid

>

> Le 20/06/2019 15:49, Jrme Hrri a crit:

>

> [...]

>

>> as they do not really represent

>

>> what an automotive-grade ITS-G5/DSRC is really capable of doing.

>

> What is the bandwidth of IPv6 demonstrated on ITS-G5/DSRC?

>

> */[RR] IPV6 does not have a bandwidth. The ITS-G5/DSRC access layers

> currently have 10MHz (and 20MHz in the US)bandwidth channels specified

> if thats your question./*

What is the bandwidth afforded by an application using TCP/IPv6 on

ITS-G5/DSRC?

Alex

>

> 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

--------------D425D01557DCB588D4647DB5-- From nobody Sat Jun 22 23:18:22 2019 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 939161200FA; Sat, 22 Jun 2019 23:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMcsdfKmB-pI; Sat, 22 Jun 2019 23:18:16 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98A931200C4; Sat, 22 Jun 2019 23:18:15 -0700 (PDT) Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 52268CC55AF15311B72C; Sun, 23 Jun 2019 07:18:13 +0100 (IST) Received: from lhreml710-chm.china.huawei.com (10.201.108.61) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sun, 23 Jun 2019 07:18:12 +0100 Received: from lhreml710-chm.china.huawei.com (10.201.108.61) by lhreml710-chm.china.huawei.com (10.201.108.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Sun, 23 Jun 2019 07:18:12 +0100 Received: from DGGEMM421-HUB.china.huawei.com (10.1.198.38) by lhreml710-chm.china.huawei.com (10.201.108.61) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Sun, 23 Jun 2019 07:18:12 +0100 Received: from DGGEMM526-MBX.china.huawei.com ([169.254.8.116]) by dggemm421-hub.china.huawei.com ([10.1.198.38]) with mapi id 14.03.0439.000; Sun, 23 Jun 2019 14:18:09 +0800 From: "Roni Even (A)" To: "dickroy@alum.mit.edu" , 'NABIL BENAMAR' , 'Roni Even' CC: "gen-art@ietf.org" , 'IETF Discussion' , "its@ietf.org" , "draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org" Thread-Topic: [ipwave] [Gen-art] Genart last call review of draft-ietf-ipwave-ipv6-over-80211ocb-46 Thread-Index: AQHVJPHkCSGcS63Kz0uKZOTqzhsmtaafz9OQgABwi3CAANcpgIAAgm6wgAcygKA= Date: Sun, 23 Jun 2019 06:18:08 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD18D39376@dggemm526-mbx.china.huawei.com> References: <156067514313.12185.6559961431451739070@ietfa.amsl.com> <6E58094ECC8D8344914996DAD28F1CCD18D37579@dggemm526-mbx.china.huawei.com> <9B1442B71BF74C83924B8C818D014A95@SRA6> <6E58094ECC8D8344914996DAD28F1CCD18D37922@dggemm526-mbx.china.huawei.com> <33F9CD4AECD240EE9E0DE94D4C081501@SRA6> In-Reply-To: <33F9CD4AECD240EE9E0DE94D4C081501@SRA6> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.60] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD18D39376dggemm526mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [ipwave] [Gen-art] Genart last call review of draft-ietf-ipwave-ipv6-over-80211ocb-46 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: 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, 23 Jun 2019 06:18:20 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD18D39376dggemm526mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Inline ________________________________ From: Roni Even (A) [mailto:roni.even@huawei.com] Sent: Tuesday, June 18, 2019 1:41 AM To: dickroy@alum.mit.edu; 'NABIL BENAMAR'; 'Ro= ni Even' Cc: gen-art@ietf.org; 'IETF Discussion'; its@ietf.= org; draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org= Subject: RE: [ipwave] [Gen-art] Genart last call review of draft-ietf-ipwav= e-ipv6-over-80211ocb-46 Hi, I am not a security expert, I was just trying to reflect that when reading = the document I got the impression that privacy is a major concern since the= IP-OBU is moving and its location can be traced by sniffing the MAC addres= ses. [RR] FYI ... there is no such thing as an IP-OBU unless this group chooses = to define one. I highly recommend against it for a variety of reasons incl= uding adding a network protocol identifier in front of a device identifier = makes no sense. [RE] IP-OBU is defined in section 2 and is used in 5.1 when discussing priv= acy Maybe it will be good to have a security review of the document. I also not= iced that there is support in IEEE SA - 1609.4-2016 for MAC address change. [RR] Yes, but it does NOT make such changes mandatory! I made sure of tha= t for the same reasons stated below. Roni Even From: Dick Roy [mailto:dickroy@alum.mit.edu] Sent: Monday, June 17, 2019 10:48 PM To: Roni Even (A); 'NABIL BENAMAR'; 'Roni Even' Cc: gen-art@ietf.org; 'IETF Discussion'; its@ietf.= org; draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org= Subject: RE: [ipwave] [Gen-art] Genart last call review of draft-ietf-ipwav= e-ipv6-over-80211ocb-46 ________________________________ From: its [mailto:its-bounces@ietf.org] On Behalf Of Roni Even (A) Sent: Monday, June 17, 2019 6:26 AM To: NABIL BENAMAR; Roni Even Cc: gen-art@ietf.org; IETF Discussion; its@ietf.or= g; draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org Subject: Re: [ipwave] [Gen-art] Genart last call review of draft-ietf-ipwav= e-ipv6-over-80211ocb-46 Thanks, The only comment left is: 2. In section 5.2 "The policy dictating when the MAC address is changed on = the 802.11-OCB interface is to-be-determined.". Reading the next sentence it lo= oks to me that this is needed as part of the solution and should not be left fo= r the unknown future. Should we reformulate here? I was expecting some recommendation since the changing of MAC address is im= portant to address privacy issues (discussed in section 5). Currently it is= left open with no recommendation , only saying that dynamic change of MAC = address is needed. Maybe the document should have some normative language for example in secti= on 5.1 that will say that IP-OBU MUST dynamic change their MAC addresses [RR] I highly recommend AGAINST this! There will be a number OBU and RSU i= mplementations that DO NOT require anonymity, and don't want it either. Fu= rthermore, immutable identifier change must be coordinated with all other i= nterfaces and protocols otherwise changing them is useless. Did the document go through security area review? [RR] If it did, and the above was not mentioned, then something was missed. Roni From: Gen-art [mailto:gen-art-bounces@ietf.org] On Behalf Of NABIL BENAMAR Sent: Monday, June 17, 2019 12:48 PM To: Roni Even Cc: gen-art@ietf.org; IETF Discussion; its@ietf.or= g; draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org Subject: Re: [Gen-art] Genart last call review of draft-ietf-ipwave-ipv6-ov= er-80211ocb-46 Dear Roni, Thank you for your review. Please, see my answers below. On Sun, Jun 16, 2019, 09:52 Roni Even via Datatracker > wrote: Reviewer: Roni Even Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-ipwave-ipv6-over-80211ocb-?? Reviewer: Roni Even Review Date: 2019-06-16 IETF LC End Date: 2019-06-26 IESG Telechat date: Not scheduled for a telechat Summary: The document is almost ready for publication as a standard track RFC Major issues: Minor issues: 1. Section 4.2 says "IP packets MUST be transmitted over 802.11-OCB media = as QoS Data" while appendix F say "The STA may send data frames of subtype Dat= a, Null, QoS Data, and QoS Null. I will update the appendix to reflect the text in section 4.2. 2. In section 5.2 "The policy dictating when the MAC address is changed on = the 802.11-OCB interface is to-be-determined.". Reading the next sentence it lo= oks to me that this is needed as part of the solution and should not be left fo= r the unknown future. Should we reformulate here? 3. In Appendix I 4th paragraph " However, this does not apply if TBD TBD TB= D. " .. What are the TBDs? The whole sentence will be removed. Nits/editorial comments: 1. In appendix I last paragraph "Support of RFC 8505 is may be implemented = on OCB." should be "Support of RFC 8505 may be implemented on OCB." 2. In Appe= ndix I "OCB nodes that support RFC 8505 would support the 6LN operation in order= to act as a host". I think that instead of "would" it should be "should" als= o if this is a recommendation why not have this paragraph not in an appendix wit= h "MAY" and "SHOULD Agreed. --_000_6E58094ECC8D8344914996DAD28F1CCD18D39376dggemm526mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 <= /p>

Inline<= /p>

 


From: Roni Eve= n (A) [mailto:roni.even@huawei.com<= /a>]
Sent: Tuesday, June 18, 2019 1:41 AM
To:
dickroy@alum.mit.edu= ; 'NABIL BENAMAR'; 'Roni Even'
Cc: gen-art@ietf.org; 'IETF = Discussion'; its@ietf.org; draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org
Subject: RE: [ipwave] [Gen-art] Genart last call review of draft-iet= f-ipwave-ipv6-over-80211ocb-46

 

Hi,

I am not a security exper= t, I was just trying to reflect that when reading the document I got the im= pression that privacy is a major concern since the IP-OBU is moving and its location can be traced by sniffing the MAC addresses.

[RR] FYI … there i= s no such thing as an IP-OBU unless this group chooses to define one.  = ;I highly recommend against it for a variety of reasons including adding a network protocol identifier in front of a device identifier makes no sen= se.

 <= /p>

[RE] IP-OBU is defined in= section 2 and is used in 5.1 when discussing privacy

 <= /p>

Maybe it will be good to have a security re=
view of the document. I also noticed that there is support in IEEE SA - 1609.4-2016 for MAC address change.=
[RR] Yes, but it does NOT make such changes mandatory! &nbs=
p; I made sure of that for the same reasons stated below.
 
Roni Even

 <= /p>

From: Dick Roy= [mailto:dickroy@alum.mit.edu]
Sent: Monday, June 17, 2019 10:48 PM
To: Roni Even (A); 'NABIL BENAMAR'; 'Roni Even'
Cc: gen-art@ietf.org; 'IETF = Discussion'; its@ietf.org; draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org
Subject: RE: [ipwave] [Gen-art] Genart last call review of draft-iet= f-ipwave-ipv6-over-80211ocb-46

 

 

 


From: its [mailto:its-bounces@ietf.org] On Behalf Of Roni Even (A)
Sent: Monday, June 17, 2019 6:26 AM
To: NABIL BENAMAR; Roni Even
Cc: gen-art@ietf.org; IETF D= iscussion; its@ietf.org; draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org
Subject: Re: [ipwave] [Gen-art] Genart last call review of draft-iet= f-ipwave-ipv6-over-80211ocb-46

 

Thanks,=

The only comment left is:=


2. In section 5.2 "The policy dictating when the MAC address is change= d on the
802.11-OCB interface is to-be-determined.". Reading the next sentence = it looks
to me that this is needed as part of the solution and should not be left fo= r
the unknown future.

 

Should we reformulate here?

 

I was expecting some recommendation since the changi= ng of MAC address is important to address privacy issues (discussed in sect= ion 5). Currently it is left open with no recommendation , only saying that= dynamic change of MAC address is needed.

Maybe the document should have some normative langua= ge for example in section 5.1 that will say that IP-OBU MUST dynamic change= their MAC addresses  

[RR] I highly recommend = AGAINST this!  There will be a number OBU and RSU implementations that= DO NOT require anonymity, and don’t want it either.  Furthermor= e, immutable identifier change must be coordinated with all other interfaces = and protocols otherwise changing them is useless.

 

Did the document go through security area review?

[RR] If it did, and the = above was not mentioned, then something was missed.

 

Roni

 <= /p>

 <= /p>

From: Gen-art = [mailto:gen-art-bounces@ietf.or= g] On Behalf Of NABIL BENAMAR
Sent: Monday, June 17, 2019 12:48 PM
To: Roni Even
Cc: gen-art@ietf.org; IETF D= iscussion; its@ietf.org; draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org
Subject: Re: [Gen-art] Genart last call review of draft-ietf-ipwave-= ipv6-over-80211ocb-46

 

Dear Roni,

 

Thank you for your review.

Please, see my answers below.

 

 

 

 

 

On Sun, Jun 16, 2019, 09:52 Roni Even via Datatracke= r <noreply@ietf.org> wrote:

Reviewer: Roni Even
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-ipwave-ipv6-over-80211ocb-??
Reviewer: Roni Even
Review Date: 2019-06-16
IETF LC End Date: 2019-06-26
IESG Telechat date: Not scheduled for a telechat

Summary:
The document is almost ready for publication as a standard track RFC

Major issues:

Minor issues:

1. Section 4.2  says "IP packets MUST be transmitted over 802.11-= OCB media as
QoS Data" while appendix F say "The STA may send data frames of s= ubtype Data,
Null, QoS Data, and
      QoS Null.

 

I will update the appendix to reflect the text in se= ction 4.2.


2. In section 5.2 "The policy dictating when the MAC address is change= d on the
802.11-OCB interface is to-be-determined.". Reading the next sentence = it looks
to me that this is needed as part of the solution and should not be left fo= r
the unknown future.

 

Should we reformulate here?


3. In Appendix I 4th paragraph " However, this does not apply if TBD T= BD TBD. "
.. What are the TBDs?

 

The whole sentence will be removed.


Nits/editorial comments:
1. In appendix I last paragraph "Support of RFC 8505 is may be impleme= nted on
OCB." should be "Support of RFC 8505 may be implemented on OCB.&q= uot; 2. In Appendix
I "OCB nodes that support RFC 8505 would support the 6LN operation in = order to
act as a host".  I think that instead of "would" it sho= uld be "should"  also if
this is a recommendation why not have this paragraph not in an appendix wit= h
"MAY" and "SHOULD

 

 

Agreed.

 

--_000_6E58094ECC8D8344914996DAD28F1CCD18D39376dggemm526mbxchi_-- From nobody Sun Jun 23 13:36:00 2019 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A777120092; Sun, 23 Jun 2019 13:35:43 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 uayDRY0Mwaq8; Sun, 23 Jun 2019 13:35:40 -0700 (PDT) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (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 D31A512016C; Sun, 23 Jun 2019 13:35:40 -0700 (PDT) Received: by mail-pg1-x531.google.com with SMTP id f25so5927551pgv.10; Sun, 23 Jun 2019 13:35:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=qc/UnKG56H0yIAAYMQCgQDRo5AUm0/jFsFXG0w95G8s=; b=mEk+QyNu1hYpbuF67bkKu7kNkp3aqPc0GzBFbL3s4tNgsBOwufGIklyUzIkP7RIrkI v95syKgmwx/DbjX3AOger7nfd//YCyyj78nv078MgFsXUdbhl6sO4SpcjLfS00wo0u/M 8DiECxI3p2O8mD/1Dlll5wBZEMJ1ax51W52WTCy+AzMFL2As2SB0AtJ05UgQoThIaHZe KVn0uepeu6tcQbgsGfBPS/+7Jyehzl54vFYNrCeTsLhfRe49uy1qMyFGizEt87SCOZey dktb/wCaBcUncwQoay79B0ObPWvGxygHlCyES0PU3F3WZRUrjRYXZr4U0CSlCBPiOhHV Dt+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=qc/UnKG56H0yIAAYMQCgQDRo5AUm0/jFsFXG0w95G8s=; b=eu8qKCdD22LYjfK+eT1okKqR2oBnQ/x5rUicl9YBD0Y3ZpazBDGmDf3UInKZexfN41 Ems+eneJgpuXQRzBTbYeO420ZXToX1LDIIaTr5LVSAHQ4461Hi2PCmBJAyOJqiR4Fz5s iLpR1UlVpO7WEbPW2MpbcRfRUqXSeYmhNzMs1NyzymmTxj/c50+zhrhIKj9ckbWlePzw QjuN0vEDtE1rl8Uoq5OO1UHhwpxaOa7PkWeBaRe5XkQhB9/J7MhYWavlL6qfoYtexFZD a5mOSoz9oEoXG4uvn5GPlLJxsrpGUi9m4pzbCi9G0a+sCWmxYksOy8iXw7+XmnDCfo48 rruQ== X-Gm-Message-State: APjAAAU30KY/lwWcBPMA3k0FniPCiHCcYIMK9LiTXdhRvtj01MU12I5e VDarCRBrrzu8BJHL2hoLQh8mr0CI X-Google-Smtp-Source: APXvYqw1kFrQpPoarye5cvg6DDnOsO5OSfYieoYLLBdWb0pyUbc4C9xqZQdy//Y04L0iYZhlYvSm4Q== X-Received: by 2002:a63:a1f:: with SMTP id 31mr10082614pgk.66.1561322139777; Sun, 23 Jun 2019 13:35:39 -0700 (PDT) Received: from [192.168.178.30] (32.23.255.123.dynamic.snap.net.nz. [123.255.23.32]) by smtp.gmail.com with ESMTPSA id t2sm9252433pfh.166.2019.06.23.13.35.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 23 Jun 2019 13:35:38 -0700 (PDT) To: "Roni Even (A)" , "dickroy@alum.mit.edu" , 'NABIL BENAMAR' , 'Roni Even' Cc: "gen-art@ietf.org" , 'IETF Discussion' , "its@ietf.org" , "draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org" References: <156067514313.12185.6559961431451739070@ietfa.amsl.com> <6E58094ECC8D8344914996DAD28F1CCD18D37579@dggemm526-mbx.china.huawei.com> <9B1442B71BF74C83924B8C818D014A95@SRA6> <6E58094ECC8D8344914996DAD28F1CCD18D37922@dggemm526-mbx.china.huawei.com> <33F9CD4AECD240EE9E0DE94D4C081501@SRA6> <6E58094ECC8D8344914996DAD28F1CCD18D39376@dggemm526-mbx.china.huawei.com> From: Brian E Carpenter Message-ID: <143b4540-d1e6-1219-ca20-0dd41ace42dd@gmail.com> Date: Mon, 24 Jun 2019 08:35:34 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD18D39376@dggemm526-mbx.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [ipwave] [Gen-art] Genart last call review of draft-ietf-ipwave-ipv6-over-80211ocb-46 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: 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, 23 Jun 2019 20:35:43 -0000 Because of the non-plain text and the commenting styles used, I am unclear who wrote what below, but please see my comment in line: On 23-Jun-19 18:18, Roni Even (A) wrote: > > Inline > > ________________________________ > From: Roni Even (A) [mailto:roni.even@huawei.com] > Sent: Tuesday, June 18, 2019 1:41 AM > To: dickroy@alum.mit.edu; 'NABIL BENAMAR'; 'Roni Even' > Cc: gen-art@ietf.org; 'IETF Discussion'; its@ietf.org; draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org > Subject: RE: [ipwave] [Gen-art] Genart last call review of draft-ietf-ipwave-ipv6-over-80211ocb-46 > > Hi, > I am not a security expert, I was just trying to reflect that when reading the document I got the impression that privacy is a major concern since the IP-OBU is moving and its location can be traced by sniffing the MAC addresses. > [RR] FYI ... there is no such thing as an IP-OBU unless this group chooses to define one. I highly recommend against it for a variety of reasons including adding a network protocol identifier in front of a device identifier makes no sense. > > [RE] IP-OBU is defined in section 2 and is used in 5.1 when discussing privacy > > > Maybe it will be good to have a security review of the document. I also noticed that there is support in IEEE SA - 1609.4-2016 for MAC address change. > > [RR] Yes, but it does NOT make such changes mandatory! I made sure of that for the same reasons stated below. The draft says, in section 5: For this reason, in the 802.11-OCB deployments, there is a strong necessity to use protection tools such as dynamically changing MAC addresses Section 5.2, semantically opaque Interface Identifiers and stable Interface Identifiers Section 4.4. This may help mitigate privacy risks to a certain level. I'm not quite sure how "strong necessity" relates to RFC2119 terminology, but the current text seems to say that changing MAC addresses is at least RECOMMENDED. Also the quoted text is very hard to parse. Does "semantically opaque" qualify "Interface Identifiers" or "Interface Identifiers and stable "Interface Identifiers"? And how do stable Interface Identifiers help to protect privacy? (FYI, the data tracker does show that a SECDIR review has been requested.) Regards Brian Carpenter > > > > Roni Even > > From: Dick Roy [mailto:dickroy@alum.mit.edu] > Sent: Monday, June 17, 2019 10:48 PM > To: Roni Even (A); 'NABIL BENAMAR'; 'Roni Even' > Cc: gen-art@ietf.org; 'IETF Discussion'; its@ietf.org; draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org > Subject: RE: [ipwave] [Gen-art] Genart last call review of draft-ietf-ipwave-ipv6-over-80211ocb-46 > > > > ________________________________ > From: its [mailto:its-bounces@ietf.org] On Behalf Of Roni Even (A) > Sent: Monday, June 17, 2019 6:26 AM > To: NABIL BENAMAR; Roni Even > Cc: gen-art@ietf.org; IETF Discussion; its@ietf.org; draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org > Subject: Re: [ipwave] [Gen-art] Genart last call review of draft-ietf-ipwave-ipv6-over-80211ocb-46 > > Thanks, > The only comment left is: > > 2. In section 5.2 "The policy dictating when the MAC address is changed on the > 802.11-OCB interface is to-be-determined.". Reading the next sentence it looks > to me that this is needed as part of the solution and should not be left for > the unknown future. > > Should we reformulate here? > > I was expecting some recommendation since the changing of MAC address is important to address privacy issues (discussed in section 5). Currently it is left open with no recommendation , only saying that dynamic change of MAC address is needed. > Maybe the document should have some normative language for example in section 5.1 that will say that IP-OBU MUST dynamic change their MAC addresses > [RR] I highly recommend AGAINST this! There will be a number OBU and RSU implementations that DO NOT require anonymity, and don't want it either. Furthermore, immutable identifier change must be coordinated with all other interfaces and protocols otherwise changing them is useless. > > Did the document go through security area review? > [RR] If it did, and the above was not mentioned, then something was missed. > > Roni > > > From: Gen-art [mailto:gen-art-bounces@ietf.org] On Behalf Of NABIL BENAMAR > Sent: Monday, June 17, 2019 12:48 PM > To: Roni Even > Cc: gen-art@ietf.org; IETF Discussion; its@ietf.org; draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org > Subject: Re: [Gen-art] Genart last call review of draft-ietf-ipwave-ipv6-over-80211ocb-46 > > Dear Roni, > > Thank you for your review. > Please, see my answers below. > > > > > > On Sun, Jun 16, 2019, 09:52 Roni Even via Datatracker > wrote: > Reviewer: Roni Even > Review result: Almost Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-ipwave-ipv6-over-80211ocb-?? > Reviewer: Roni Even > Review Date: 2019-06-16 > IETF LC End Date: 2019-06-26 > IESG Telechat date: Not scheduled for a telechat > > Summary: > The document is almost ready for publication as a standard track RFC > > Major issues: > > Minor issues: > > 1. Section 4.2 says "IP packets MUST be transmitted over 802.11-OCB media as > QoS Data" while appendix F say "The STA may send data frames of subtype Data, > Null, QoS Data, and > QoS Null. > > I will update the appendix to reflect the text in section 4.2. > > 2. In section 5.2 "The policy dictating when the MAC address is changed on the > 802.11-OCB interface is to-be-determined.". Reading the next sentence it looks > to me that this is needed as part of the solution and should not be left for > the unknown future. > > Should we reformulate here? > > 3. In Appendix I 4th paragraph " However, this does not apply if TBD TBD TBD. " > ... What are the TBDs? > > The whole sentence will be removed. > > Nits/editorial comments: > 1. In appendix I last paragraph "Support of RFC 8505 is may be implemented on > OCB." should be "Support of RFC 8505 may be implemented on OCB." 2. In Appendix > I "OCB nodes that support RFC 8505 would support the 6LN operation in order to > act as a host". I think that instead of "would" it should be "should" also if > this is a recommendation why not have this paragraph not in an appendix with > "MAY" and "SHOULD > > > Agreed. > > > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art > From nobody Sun Jun 23 16:33:13 2019 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32D11120165 for ; Sun, 23 Jun 2019 16:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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 hxhhHBHA60j7 for ; Sun, 23 Jun 2019 16:33:09 -0700 (PDT) Received: from mail-yw1-xc2b.google.com (mail-yw1-xc2b.google.com [IPv6:2607:f8b0:4864:20::c2b]) (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 3AC1B12001A for ; Sun, 23 Jun 2019 16:33:09 -0700 (PDT) Received: by mail-yw1-xc2b.google.com with SMTP id b143so5129638ywb.7 for ; Sun, 23 Jun 2019 16:33:09 -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=Yg2ZmD09c8ilfnBfmKYF6h8CDXkF1LdOpU9gk30NCbA=; b=abMsXDvGtyM0XheTlSrr5LixT649jrUEolsQ++JsgAu9ckJ7CLWfneraXJBUG+zcrl Oh7pWOt+DtfW0AHQK97jcjUO/0xehln3nzWsUkqeHBmTMdm2zj6VB+62/O671xDsqter f1n1Zff213tA6dQ4BFqqC8oKiLZX+dI8tCvy5XB7fs2kp07CtD9KvIwagkGZI+W8r9V0 ir/zf2oFbhehtB/cFUjMw4/rvgk4sj0jxpdpOost+NrFHlZNo4aNOyptXqYMjX+rtl3/ GKckcxXkr4GiacoMcVknmPlcyKmaewvDHjH3zJuZGWqsy9HUxfImpVxyJhWDDiXQ2VHP x5bw== 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=Yg2ZmD09c8ilfnBfmKYF6h8CDXkF1LdOpU9gk30NCbA=; b=q5eZe2Se2WkUrQQ2z4TDhtPXk0hN63p4qooXhe62E34r9wl1+JddiyBqD9ZurbNUEn K17Q1tgCIhex+M/qHwNiaX8EPxoKTLCU1X+bxc+b1sKnYzlLpkVghDYN2+v0dIDwUMn7 kGayTmbsi1LMEV0i9pPWdjcAVjJk4gviS7ZOZvd4Blv5XxNAwd/JfBJOEq0e0eGRaedf 7s9UPys90lWv5Jrgcfj91yEhMTKVKl61J74eBwtKDfVqfOx3qhNaFw9f4+EE0jaxQdhQ 3GzOa71qxnokNazNIK1QBRha3ztZEXQ4O4GgZH7ZcyBm8KET+QH18LOmfdMuUl15/P+T 4yfg== X-Gm-Message-State: APjAAAUEdn6EO0HgX4+TOQfbLiVSt2zf7HJlFR8BAUpOJQYNk/Mldw+G Z+a3hMgxE2VWljX79v56MPOBAUHabS7PIaWh8LeuxDQE X-Google-Smtp-Source: APXvYqylKRdmcoXmzOARJ7djuLfZNMTQxAMkViyBiPok/5qAv/6run3M/K/7zjMBhQMx7FbZtSQ1n8AfS20ZlEW6Puc= X-Received: by 2002:a81:838d:: with SMTP id t135mr70658846ywf.56.1561332786872; Sun, 23 Jun 2019 16:33:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Sara el hamdani Date: Mon, 24 Jun 2019 00:32:28 +0100 Message-ID: To: its@ietf.org Cc: Alexandre Petrescu , Nabil Benamar Content-Type: multipart/alternative; boundary="000000000000234592058c061e79" Archived-At: Subject: Re: [ipwave] Patching Linux Kernel with OCB X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: 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, 23 Jun 2019 23:33:12 -0000 --000000000000234592058c061e79 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Alex, Many thanks for sharing your insights. Indeed, we knew during the hackathon that we should better patch the kernel in its newest version 5.1.12. However, we couldn't create a new patch because of the lack of time as mentioned Mr, Nabil. In fact, we didn't have the right adapter for the physical OCBcard we had. So, we whole first day spent the the first day trying to install the card on the desktop including creating manually the adequate antenas. Then, we had only six hours in the next day to capture IPv6 packets patching and recompiling the kernel ect. We have recommended to the organizers the reserve more time to this truck in future hackathons. We think also that creating a new patch for the current linux of the kernel is worth to be the object of an independent truck in the hackathon. Concerning the parameters, we have tested the connectivity using ath9k driver successfully, and we were about to do the same for ath10k but it was the already presentation time (as we aforementioned a lack of time). For the patch creator, we don't know honestly who he is, but we have found the link mentioned on a previous email of you in the link: https://drive.google.com/file/d/0BxK6WTQZ97QVWF9tRURjOGhBU2c/view. Thus, we decided to fix it and to make it work. Besides, even if we arrived to patch the kernel with ath9k, the report in the terminal showed that it was not completely successful (not 100%) and it seems that this is what happens usually. So based on your big in you experience, Mr. Alex, on creating and patching the kernel, we would know if it is common for you to patch the kernel successfully 100%? Sara Le ven. 21 juin 2019 =C3=A0 12:41, Nabil Benamar a = =C3=A9crit : > Hi Alex, > > Thank you for your comments. > This is exactly what the hackathon participants put in future work! > > 2 days were not enough to build the testbed and test different drivers an= d > parameters... > > On Fri, Jun 21, 2019, 14:01 Alexandre Petrescu < > alexandre.petrescu@gmail.com> wrote: > >> Hello Mr. Seur, >> >> I would like to ask you whether you can apply that patch to ath10k also? >> (instead of ath9k). >> >> If you do, you risk being the first to achieve 1Gbps on OCB, hopefully >> with IPv6. >> >> Alex >> >> Le 20/06/2019 =C3=A0 15:25, John Seur a =C3=A9crit : >> > Hello IPWavers, >> > >> > During the Hackathon@AIS2019 >> > (https://hackathon.internetsummitafrica.org/), the team in IPWave >> track >> > (led by Nabil Benamar) was patching the Linux kernel 4.9.61 with OCB >> > mode and discovered the following bugs in the patch file >> > (https://drive.google.com/file/d/0BxK6WTQZ97QVWF9tRURjOGhBU2c/view). >> > drivers/net/wireless/ath/ath9k/main.c:961:2: error: duplicate case >> value >> > case NL80211_IFTYPE_OCB: >> > drivers/net/wireless/ath/ath9k/hw.c:1241:2: error: duplicate case >> value >> > case NL80211_IFTYPE_OCB: >> > >> > The duplicated lines of code were commented out and the patch file >> works! >> > >> > _______________________________________________ >> > 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.* --000000000000234592058c061e79 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Alex,

Many thanks for sharing you= r insights.=C2=A0

Indeed, we knew during the hacka= thon that we should better patch the=C2=A0 kernel in its newest version 5.1= .12. However, we couldn't create a new patch because of the lack of tim= e as mentioned Mr, Nabil. In fact, we didn't have the right adapter for= the physical OCBcard we had. So, we whole first day spent the the first da= y trying to install the card on the desktop including creating manually the= adequate antenas.=C2=A0 Then, we had=C2=A0 only six hours in the next day = to capture IPv6 packets patching and recompiling the kernel ect.=C2=A0

We have recommended to the organizers the reserve more= time to this truck in future hackathons. We think also that creating a new= patch for the current linux of the kernel is worth to be the object of an = independent truck in the hackathon.

Concerning the= parameters, we have tested the connectivity using ath9k driver successfull= y, and we were about to do the same for ath10k but it was the already prese= ntation time (as we aforementioned a lack of time).

For the patch creator, we don't know honestly who he is, but we have = found the link mentioned on a previous email of you in the link:=C2=A0ht= tps://drive.google.com/file/d/0BxK6WTQZ97QVWF9tRURjOGhBU2c/view. Thus, = we decided to fix it and to make it work.=C2=A0=C2=A0

Besides, even if we arrived to patch the kernel with ath9k, the rep= ort in the terminal showed that it was not completely successful (not 100%)= and it seems that this is what happens usually. So based on your big in yo= u experience, Mr. Alex, on creating and patching the kernel, we would know = if it is common for you to patch the kernel successfully 100%?

Sara

=
Le=C2=A0ven. 21 juin 2019 =C3=A0=C2= =A012:41, Nabil Benamar <benamar7= 3@gmail.com> a =C3=A9crit=C2=A0:
Hi Alex,

Thank you for your comments.
Th= is is exactly what the hackathon participants put in future work!

2 days were not enough to build t= he testbed and test different drivers and parameters...

On Fri, Jun 21= , 2019, 14:01 Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:
=
Hello Mr. Seur,

I would like to ask you whether you can apply that patch to ath10k also? (instead of ath9k).

If you do, you risk being the first to achieve 1Gbps on OCB, hopefully
with IPv6.

Alex

Le 20/06/2019 =C3=A0 15:25, John Seur a =C3=A9crit=C2=A0:
> Hello IPWavers,
>
> During the Hackathon@AIS2019
> (https://hackathon.internetsummitafrica.o= rg/), the team in IPWave track
> (led by Nabil Benamar) was patching the Linux kernel 4.9.61 with OCB <= br> > mode and discovered the following bugs in the patch file
> (https://drive.goog= le.com/file/d/0BxK6WTQZ97QVWF9tRURjOGhBU2c/view).
>=C2=A0 =C2=A0 drivers/net/wireless/ath/ath9k/main.c:961:2: error: dupli= cate case value
>=C2=A0 =C2=A0 case NL80211_IFTYPE_OCB:
>=C2=A0 =C2=A0 drivers/net/wireless/ath/ath9k/hw.c:1241:2: error: duplic= ate case value
>=C2=A0 =C2=A0 case NL80211_IFTYPE_OCB:
>
> The duplicated lines of code were commented out and the patch file wor= ks!
>
> _______________________________________________
> 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
_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its


--
Best regards

Sara EL HAMDANI
<= i>Phd student=C2=A0-Umi University.
--000000000000234592058c061e79-- From nobody Sun Jun 23 17:06:48 2019 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 236B5120105 for ; Sun, 23 Jun 2019 17:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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 QYrCgwVOsBVk for ; Sun, 23 Jun 2019 17:06:42 -0700 (PDT) Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) (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 8E55412001A for ; Sun, 23 Jun 2019 17:06:42 -0700 (PDT) Received: by mail-yb1-xb30.google.com with SMTP id w9so473670ybe.9 for ; Sun, 23 Jun 2019 17:06:42 -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=CJc8Vc5wYzBwDJ/NkJ0hm1C0RtWGvOebRXib+XwzEi8=; b=Zv5WzmwZhN70kRdfAM6ClTQpULA9GQMf2V4mC4Y9FyF15L8mm9jFLxVBRDjQIOJ4AW viVqF4oj8hATThU1f285hOo9QY/TuvB8Ob9WGcl9oNw64dsdLO2w+VXvDyQNxei7NwFp kDM9Vxn2bVNWdAs7ZOqtDQDgPXvDFSMuBaT0Tzt31cA0pPoiBMxOFDS6kX3YNlEga77Z 8EskMrPVyrQgOGSQW0NOT+jvXrEpupY4AaxkRXcMiwyFKdAVAB+noB2Peg/IhqRFsXYk LBbcwBLw0N3FRJsMtdzRqrgFLZYTCOPCXBOSW+9/t4cH2Ah6cyTYF1E7oKobdQ4acMNt 3alQ== 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=CJc8Vc5wYzBwDJ/NkJ0hm1C0RtWGvOebRXib+XwzEi8=; b=oYjNGS/9TrsBQF/BrHhgq9QkY4bOIUd+KN0rSPuORKK41aa6EM7lnaSq5NBYEuxzij lOLQRD4zLyR+fI2ZYSL37NRM1gz7h4We4Azd/TMPf628gLVxEOPwKGSweIiWUYt8/rpI xkJUUEoXP3qRrI75xMeFckwhzUy4Be5mU18Vl4E2n6vi3XpJL0UDpdYg9+IrKWmMXVw8 l/bhzaqUSCbqXACTp6F7tfEzJfPzGLBHqDLRBwaLhpcb+QxcDQpt78wnb2nUUSz8gE07 5/KCv1TGXB6UBJLi7G+HLft9LsXKsj8wVFFV7huCFsG88lVzIW2BbRcwARzU33mQ+ASr u/Pg== X-Gm-Message-State: APjAAAU2Z2Vip95pQXI3jT7leXVEkbwP1vJ4kr2X97uV7mWo+OmmzOcw 7mR02RLnMIqfPGzwtq2JysAPi4yUdUZkoSHpXeY8arOh X-Google-Smtp-Source: APXvYqzVqaGPxBWXqb4h5jRhlNt4EzTjNnL0M34bpa7hXczva3gcoAVmkdtM/ZccpObvqU7CoDOJI+nX+EpKO1DrFlk= X-Received: by 2002:a25:1854:: with SMTP id 81mr77111741yby.152.1561334801380; Sun, 23 Jun 2019 17:06:41 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Sara el hamdani Date: Mon, 24 Jun 2019 01:06:01 +0100 Message-ID: To: its@ietf.org Cc: Alexandre Petrescu , Nabil Benamar Content-Type: multipart/alternative; boundary="000000000000363a34058c0696f5" Archived-At: Subject: Re: [ipwave] Patching Linux Kernel with OCB X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: 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, 24 Jun 2019 00:06:45 -0000 --000000000000363a34058c0696f5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Alex, Many thanks for sharing your insights. Indeed, we knew during the hackathon that we should better patch the kernel in its newest version 5.1.12. However, we couldn't create a new patch because of the lack of time as mentioned Mr, Nabil. In fact, we did not have the right adapter for the physical OCB Card we had. So, we spent the whole first day trying to install the card on the desktop including creating the adequate antenas manually . Then, we had in the next day only six hours to capture IPv6 packets, patch and recompile the kernel ... We have recommended to the organizers to reserve more time to this truck in future hackathons. We think also that creating a new patch for the current linux of the kernel is worth to be the object of an independent truck in the hackathon. Concerning the parameters, we have tested the connectivity using ath9k driver successfully, and we were about to do the same for ath10k but it was already the presentation time (as we aforementioned, a lack of time). For the patch creator, we don't know honestly who he is, but we have found the link mentioned on a previous email of you in the link: https://drive.google.com/file/d/0BxK6WTQZ97QVWF9tRURjOGhBU2c/view. Thus, we decided to fix it and to make it work. Besides, even if we arrived to patch the kernel with ath9k, the report in the terminal showed that it was not completely successful (not 100%) and it seems that this is what happens usually. So based on your big experience, Mr. Alex, in creating and patching the kernel, we would like to know if it is common for you to patch the kernel successfully 100%? Le lun. 24 juin 2019 =C3=A0 00:32, Sara el hamdani a =C3=A9crit : > Hello Alex, > > Many thanks for sharing your insights. > > Indeed, we knew during the hackathon that we should better patch the > kernel in its newest version 5.1.12. However, we couldn't create a new > patch because of the lack of time as mentioned Mr, Nabil. In fact, we > didn't have the right adapter for the physical OCBcard we had. So, we who= le > first day spent the the first day trying to install the card on the deskt= op > including creating manually the adequate antenas. Then, we had only six > hours in the next day to capture IPv6 packets patching and recompiling th= e > kernel ect. > > We have recommended to the organizers the reserve more time to this truck > in future hackathons. We think also that creating a new patch for the > current linux of the kernel is worth to be the object of an independent > truck in the hackathon. > > Concerning the parameters, we have tested the connectivity using ath9k > driver successfully, and we were about to do the same for ath10k but it w= as > the already presentation time (as we aforementioned a lack of time). > > For the patch creator, we don't know honestly who he is, but we have foun= d > the link mentioned on a previous email of you in the link: > https://drive.google.com/file/d/0BxK6WTQZ97QVWF9tRURjOGhBU2c/view. Thus, > we decided to fix it and to make it work. > > Besides, even if we arrived to patch the kernel with ath9k, the report in > the terminal showed that it was not completely successful (not 100%) and = it > seems that this is what happens usually. So based on your big in you > experience, Mr. Alex, on creating and patching the kernel, we would know = if > it is common for you to patch the kernel successfully 100%? > > Sara > > > Le ven. 21 juin 2019 =C3=A0 12:41, Nabil Benamar a > =C3=A9crit : > >> Hi Alex, >> >> Thank you for your comments. >> This is exactly what the hackathon participants put in future work! >> >> 2 days were not enough to build the testbed and test different drivers >> and parameters... >> >> On Fri, Jun 21, 2019, 14:01 Alexandre Petrescu < >> alexandre.petrescu@gmail.com> wrote: >> >>> Hello Mr. Seur, >>> >>> I would like to ask you whether you can apply that patch to ath10k also= ? >>> (instead of ath9k). >>> >>> If you do, you risk being the first to achieve 1Gbps on OCB, hopefully >>> with IPv6. >>> >>> Alex >>> >>> Le 20/06/2019 =C3=A0 15:25, John Seur a =C3=A9crit : >>> > Hello IPWavers, >>> > >>> > During the Hackathon@AIS2019 >>> > (https://hackathon.internetsummitafrica.org/), the team in IPWave >>> track >>> > (led by Nabil Benamar) was patching the Linux kernel 4.9.61 with OCB >>> > mode and discovered the following bugs in the patch file >>> > (https://drive.google.com/file/d/0BxK6WTQZ97QVWF9tRURjOGhBU2c/view). >>> > drivers/net/wireless/ath/ath9k/main.c:961:2: error: duplicate case >>> value >>> > case NL80211_IFTYPE_OCB: >>> > drivers/net/wireless/ath/ath9k/hw.c:1241:2: error: duplicate case >>> value >>> > case NL80211_IFTYPE_OCB: >>> > >>> > The duplicated lines of code were commented out and the patch file >>> works! >>> > >>> > _______________________________________________ >>> > 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.* > --=20 *Best regards* *Sara EL HAMDANI* *Phd student -Umi University.* --000000000000363a34058c0696f5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Alex,

Many thank= s for sharing your insights.=C2=A0

Indeed, we knew= during the hackathon that we should better patch the=C2=A0 kernel in its n= ewest version 5.1.12. However, we couldn't create a new patch because o= f the lack of time as mentioned Mr, Nabil. In fact, we did not have the rig= ht adapter for the physical OCB Card we had. So, we spent the whole first d= ay trying to install the card on the desktop including creating the adequat= e antenas manually=C2=A0. Then, we had=C2=A0 in the next day=C2=A0only six = hours to capture IPv6 packets, patch and recompile the kernel ...=C2=A0

We have recommended to the organizers to reserve more= time to this truck in future hackathons. We think also that creating a new= patch for the current linux of the kernel is worth to be the object of an = independent truck in the hackathon.

Concerning the= parameters, we have tested the connectivity using ath9k driver successfull= y, and we were about to do the same for ath10k but it was already the=C2=A0= presentation time (as we aforementioned, a lack of time).

For the patch creator, we don't know honestly who he is, but we= have found the link mentioned on a previous email of you in the link:=C2= =A0https://drive.google.com/file/d/0BxK6WTQZ97QVWF9tRU= RjOGhBU2c/view. Thus, we decided to fix it and to make it work.=C2=A0= =C2=A0

Besides, even if we arrived to patch th= e kernel with ath9k, the report in the terminal showed that it was not comp= letely successful (not 100%) and it seems that this is what happens usually= . So based on your big experience, Mr. Alex, in creating and patching the k= ernel, we would like to know if it is common for you to patch the kernel su= ccessfully 100%?

Le=C2=A0lun. 24 juin 2019 =C3=A0=C2=A000:32, Sara el = hamdani <saraelhamdani@gmail.= com> a =C3=A9crit=C2=A0:
Hello Alex,

Many thanks= for sharing your insights.=C2=A0

Indeed, we knew = during the hackathon that we should better patch the=C2=A0 kernel in its ne= west version 5.1.12. However, we couldn't create a new patch because of= the lack of time as mentioned Mr, Nabil. In fact, we didn't have the r= ight adapter for the physical OCBcard we had. So, we whole first day spent = the the first day trying to install the card on the desktop including creat= ing manually the adequate antenas.=C2=A0 Then, we had=C2=A0 only six hours = in the next day to capture IPv6 packets patching and recompiling the kernel= ect.=C2=A0

We have recommended to the organizers = the reserve more time to this truck in future hackathons. We think also tha= t creating a new patch for the current linux of the kernel is worth to be t= he object of an independent truck in the hackathon.

Concerning the parameters, we have tested the connectivity using ath9k dr= iver successfully, and we were about to do the same for ath10k but it was t= he already presentation time (as we aforementioned a lack of time).

For the patch creator, we don't know honestly who he = is, but we have found the link mentioned on a previous email of you in the = link:=C2=A0https://drive.google.com/file/d/0BxK6WTQZ97= QVWF9tRURjOGhBU2c/view. Thus, we decided to fix it and to make it work.= =C2=A0=C2=A0

Besides, even if we arrived to pa= tch the kernel with ath9k, the report in the terminal showed that it was no= t completely successful (not 100%) and it seems that this is what happens u= sually. So based on your big in you experience, Mr. Alex, on creating and p= atching the kernel, we would know if it is common for you to patch the kern= el successfully 100%?

Sara


=C2=A0
Le=C2=A0ven. 21 juin 2019 =C3=A0=C2=A012:41, Nabil Benamar <benamar73@gmail.com> = a =C3=A9crit=C2=A0:
Hi Alex,

Thank you for your comments.
This is exactly what t= he hackathon participants put in future work!

2 days were not enough to build the testbed and test = different drivers and parameters...

On Fri, Jun 21, 2019, 14:01 Alexan= dre Petrescu <alexandre.petrescu@gmail.com> wrote:
Hello Mr. Seur,

I would like to ask you whether you can apply that patch to ath10k also? (instead of ath9k).

If you do, you risk being the first to achieve 1Gbps on OCB, hopefully
with IPv6.

Alex

Le 20/06/2019 =C3=A0 15:25, John Seur a =C3=A9crit=C2=A0:
> Hello IPWavers,
>
> During the Hackathon@AIS2019
> (https://hackathon.internetsummitafrica.o= rg/), the team in IPWave track
> (led by Nabil Benamar) was patching the Linux kernel 4.9.61 with OCB <= br> > mode and discovered the following bugs in the patch file
> (https://drive.goog= le.com/file/d/0BxK6WTQZ97QVWF9tRURjOGhBU2c/view).
>=C2=A0 =C2=A0 drivers/net/wireless/ath/ath9k/main.c:961:2: error: dupli= cate case value
>=C2=A0 =C2=A0 case NL80211_IFTYPE_OCB:
>=C2=A0 =C2=A0 drivers/net/wireless/ath/ath9k/hw.c:1241:2: error: duplic= ate case value
>=C2=A0 =C2=A0 case NL80211_IFTYPE_OCB:
>
> The duplicated lines of code were commented out and the patch file wor= ks!
>
> _______________________________________________
> 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
_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its


--
Best regards
<= div dir=3D"ltr">
Sara EL HA= MDANI
Phd student=C2=A0-Umi University.


--
Best regards

Sara EL HAMDANI
<= i>Phd student=C2=A0-Umi University.
--000000000000363a34058c0696f5-- From nobody Mon Jun 24 19:13:25 2019 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5C7E12001A for ; Mon, 24 Jun 2019 19:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.497 X-Spam-Level: X-Spam-Status: No, score=-0.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_NAME_FM_MR_MRS=1.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 J5F6aScvmDm5 for ; Mon, 24 Jun 2019 19:13:22 -0700 (PDT) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 E586112000F for ; Mon, 24 Jun 2019 19:13:21 -0700 (PDT) Received: by mail-wm1-x32a.google.com with SMTP id v19so1171293wmj.5 for ; Mon, 24 Jun 2019 19:13:21 -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=2eCbtRHgpgycj3bdI8kcoTIumxtZkstJmNPXpIhzCaQ=; b=JyBGj2Z0gpa6EBGytiwSMHzv9sAR4cjSe1G5fIUTb7+dJjT6ro7P9za1o97zfqms8w O0FWSbN2w0wKWiYs9lG5WcH1Ir65rl2irIqCsT4DmGB9HRl88i8DSGTIm9Uo5dutIBnI S/oMgXanwmH3pZl2BpmimCTvdOzI6vD89nHLy8nhLT9LF+ut0LWzbV1fh6T3iDOzhtIQ eunO8Rp0m+Oq7Cf0K+2vWewP9uUZ2isW9xJj8pNk4StM/bUZQLLTEGwtl/LxmyYjM94x RGyZ2IHyhniJ9EdyVf8dr4HU6yJv57frqtkyQfwgqehbnOfsSNR5pB2DHS18cS/iq3x2 daxw== 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=2eCbtRHgpgycj3bdI8kcoTIumxtZkstJmNPXpIhzCaQ=; b=fOThie+GVl8CC81m1Gh97t69sMIG+qXvVCry8VTDSqd93hX88xq+kjtFwKhfel/VjQ Abe92Vo14uAF13N3Se2874VuZ2oWtIDiLfmqhC+/tNCBe8tAWJn8AltxzpKFnql7bmrp ccERLiJJw0w7fH/gCEou+jpAMX4Cp24ENIBWpaN8sMssSPUNvuo5eSnuztrzh1z/B1tj 3rYhZtQxJKr2I9baEiXNKA+LEqeeU1oKxyYHihpi10gWt51NkPK1CVcBGm4+cCYjn9ok vGyWeSahI5rAdcM4Cytx61hpDveJHnKDJfWuA6Bz5rfnyA+nzDoeN8UppzUeAkAabNYr jtgw== X-Gm-Message-State: APjAAAVUdewvNB9TEEkse9+pNZ3Bg5HdsHJe/24QhBqzovM9Lea7GLSk 4dglrQZvdQujB1mqCGr6BMQazFFvTHura9nTU6Q= X-Google-Smtp-Source: APXvYqxaE45Y4nDnkzGCOMe+dnlsFxehcjVGY1y03sJuRybv1JMSg6EFyHLHNvUnERT+qihdHIFbYpp0ZCBaZPmh3lQ= X-Received: by 2002:a1c:9813:: with SMTP id a19mr17218215wme.11.1561428800186; Mon, 24 Jun 2019 19:13:20 -0700 (PDT) MIME-Version: 1.0 From: "Mr. Jaehoon Paul Jeong" Date: Tue, 25 Jun 2019 11:13:08 +0900 Message-ID: To: Russ Housley , CARLOS JESUS BERNARDOS CANO Cc: its@ietf.org, Jaehoon Paul Jeong Content-Type: multipart/alternative; boundary="000000000000fa2fa3058c1c7880" Archived-At: Subject: [ipwave] IETF-103 IPWAVE WG Session X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: 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, 25 Jun 2019 02:13:24 -0000 --000000000000fa2fa3058c1c7880 Content-Type: text/plain; charset="UTF-8" ,Hi Russ and Carlos, as you know, the revised IPWAVE PS draft was posted. During this IETF-105 meeting, IPWAVE WG need to discuss the rechartering. The current assigned time of 30 minutes seems short. https://datatracker.ietf.org/meeting/105/agenda/ lp My SKKU team will lead the IPWAVE ND Hackathon p --000000000000fa2fa3058c1c7880 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=C2=A0,Hi Russ and Carlos,
as you know, = the revised IPWAVE PS draft was posted.
During this = IETF-105 meeting, IPWAVE WG need to discuss the rechartering.
The current assigned time of 30 minutes seems short.
lp
My SKKU team will lead the IPWAVE ND Hackathon = p


--000000000000fa2fa3058c1c7880-- From nobody Mon Jun 24 19:16:40 2019 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 235BF12022B for ; Mon, 24 Jun 2019 19:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.497 X-Spam-Level: X-Spam-Status: No, score=-0.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_NAME_FM_MR_MRS=1.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 eTsj11mqUeRx for ; Mon, 24 Jun 2019 19:16:36 -0700 (PDT) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 6872512001A for ; Mon, 24 Jun 2019 19:16:36 -0700 (PDT) Received: by mail-wm1-x333.google.com with SMTP id c6so1210114wml.0 for ; Mon, 24 Jun 2019 19:16:36 -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=B5/tB2ByUHpp0807vQzTaSXjDI14SLwGimZcL5JiR88=; b=EXwkBcmpIgaIvaK/d0TXPcwIJ/rtqKcks5Pw6DVxu230pnIIR83ijH5y8Z5cCgx6T0 R6e291LGAkJWiCEA+o6RqBaPGr7IH0QeyfnQJV9xOd63WSiCGxlXNLMjEV6+1drhMu9p LWnRwRfXEIZJH+40GYL9cfxl+ETlC5kZweVUa6x2WQSTSg5LNehxLnOBR5p9tnpueMCx 7LN8cNeVG+8dJBprkG5q9cbWemO1yvgp2dAQSa2M5qNXgf4mCkFh9SPtLC7JyHk+Bj61 YnKNdCu1EZcUqgg1XzmiqCIkzqyrst7T/9wsWCWXmqyAiFXLjmjBjTheiU0dd4BazNA3 XK9Q== 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=B5/tB2ByUHpp0807vQzTaSXjDI14SLwGimZcL5JiR88=; b=WyOH3e6t/hnoIMSUCCKXZQGMsR2/eVxPFK5kS8nWFMG8wKErOHdi1+rtnpfkCzqtXw bNHYdn1ZouO8kyTdMb1hJyDiVad54v61bSwMJ2fm8rIX2wi6GPM04Z0xxIVI1eC3SdPr YNk96DlVBJo8VvMXtDA1crhxu4fOsEv5A4pd3BpUZrDglgnyfaDkOw7IPR3uwmfzw+BT 33DUzgPmyC59/36gX2UQeFvyEI58x+oQpnlrhhcLLWIoXzPE5xZLhwPWhaUTWkv7/1Db l/CXZBqF3Z/hVa8f/EIi0OsPF+7kDF32U6qjb9gE96lsnDqbKsUPOatROhIVrGf3a+fV oisA== X-Gm-Message-State: APjAAAVQfeAnYDK30t5yaufu0Qd+iujkb5JC2y+U7ApU2DDkvYyeU4tq cHknSzScYd8RVDzytgY7s5Oqp/9InRXHRCTYUpc= X-Google-Smtp-Source: APXvYqy56fA6wPesvniFdAWXvf2XP1oB1pn/bvUDNWsumyn9LBBtgNZ11S1Q22UiO+YEzF8GHl7ny0PPMd+osDpz24M= X-Received: by 2002:a1c:f512:: with SMTP id t18mr17441624wmh.47.1561428994710; Mon, 24 Jun 2019 19:16:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Mr. Jaehoon Paul Jeong" Date: Tue, 25 Jun 2019 11:16:23 +0900 Message-ID: To: Russ Housley , CARLOS JESUS BERNARDOS CANO Cc: its@ietf.org Content-Type: multipart/alternative; boundary="0000000000009263a6058c1c8478" Archived-At: Subject: Re: [ipwave] IETF-103 IPWAVE WG Session X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: 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, 25 Jun 2019 02:16:38 -0000 --0000000000009263a6058c1c8478 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Russ and Carlos, as you know, the revised IPWAVE PS draft was posted. During this IETF-105 meeting, I think IPWAVE WG need to discuss the rechartering. The current assigned time of 30 minutes seems short. https://datatracker.ietf.org/meeting/105/agenda/ My SKKU team will lead the IPWAVE ND Hackathon project. Do you have any plan for this meeting? Thanks. Best Regards, Paul 2019=EB=85=84 6=EC=9B=94 25=EC=9D=BC (=ED=99=94) =EC=98=A4=EC=A0=84 11:13, = Mr. Jaehoon Paul Jeong =EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1: > ,Hi Russ and Carlos, > as you know, the revised IPWAVE PS draft was posted. > During this IETF-105 meeting, IPWAVE WG need to discuss the rechartering. > The current assigned time of 30 minutes seems short. > https://datatracker.ietf.org/meeting/105/agenda/ > lp > My SKKU team will lead the IPWAVE ND Hackathon p > > > --0000000000009263a6058c1c8478 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Russ and Carlos= ,
as you know, the= revised IPWAVE PS draft was posted.
During this IETF-105 meeting, I think IPWAVE WG need to d= iscuss the rechartering.
The current assigned time of 30 minutes seems short.

<= div dir=3D"auto" style=3D"font-family:sans-serif">My SKKU team will lead th= e IPWAVE ND Hackathon project.





=
=C2=A0,Hi Russ and Carlos,
as you know, the revi= sed IPWAVE PS draft was posted.
During this IETF-105= meeting, IPWAVE WG need to discuss the rechartering.
The current assigned time of 30 minutes seems short.


--0000000000009263a6058c1c8478-- From nobody Tue Jun 25 06:50:00 2019 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6BBF12003F for ; Tue, 25 Jun 2019 06:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUmNqhOULuq8 for ; Tue, 25 Jun 2019 06:49: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 09A6D12008D for ; Tue, 25 Jun 2019 06:49:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C1FD4300AB1 for ; Tue, 25 Jun 2019 09:30:38 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id JdnwWUbKC2gs for ; Tue, 25 Jun 2019 09:30:37 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 0CAA23000D7; Tue, 25 Jun 2019 09:30:37 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_B4825E48-51E1-4768-B9A5-993D80B7443C" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 25 Jun 2019 09:49:53 -0400 In-Reply-To: Cc: =?utf-8?Q?Carlos_Jes=C3=BAs_Bernardos_Cano?= , its To: "Mr. Jaehoon Paul Jeong" References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [ipwave] IETF-103 IPWAVE WG Session X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: 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, 25 Jun 2019 13:49:59 -0000 --Apple-Mail=_B4825E48-51E1-4768-B9A5-993D80B7443C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Paul: As we said in Prague, we will not be discussing the recartering until = the two documents on the existing charter are with the IESG. One of = them has made it, but the other one has not. Russ > On Jun 24, 2019, at 10:13 PM, Mr. Jaehoon Paul Jeong = wrote: >=20 > ,Hi Russ and Carlos, > as you know, the revised IPWAVE PS draft was posted. > During this IETF-105 meeting, IPWAVE WG need to discuss the = rechartering. > The current assigned time of 30 minutes seems short. > https://datatracker.ietf.org/meeting/105/agenda/ = > lp > My SKKU team will lead the IPWAVE ND Hackathon p >=20 >=20 --Apple-Mail=_B4825E48-51E1-4768-B9A5-993D80B7443C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Paul:

As = we said in Prague, we will not be discussing the recartering until the = two documents on the existing charter are with the IESG.  One of = them has made it, but the other one has not.

Russ



 ,Hi Russ and Carlos,
as you = know, the revised IPWAVE PS draft was posted.
During this IETF-105 meeting, IPWAVE WG need to discuss the = rechartering.
The current assigned = time of 30 minutes seems short.
lp
My SKKU team will lead the IPWAVE ND Hackathon p



= --Apple-Mail=_B4825E48-51E1-4768-B9A5-993D80B7443C-- From nobody Tue Jun 25 09:16:03 2019 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3AB120788 for ; Tue, 25 Jun 2019 09:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.63 X-Spam-Level: X-Spam-Status: No, score=-1.63 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 GW7ZytGI0EU8 for ; Tue, 25 Jun 2019 09:15: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 8E52012076E for ; Tue, 25 Jun 2019 09:15:51 -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 x5PGFl6Y056066; Tue, 25 Jun 2019 18:15:47 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9DBCD208FAF; Tue, 25 Jun 2019 18:15:47 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 86A4E208E30; Tue, 25 Jun 2019 18:15:47 +0200 (CEST) Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x5PGFlMn000898; Tue, 25 Jun 2019 18:15:47 +0200 To: Sara el hamdani , its@ietf.org Cc: Nabil Benamar References: From: Alexandre Petrescu Message-ID: <7c3d7458-2246-7efb-50e0-7bfb6c4389e2@gmail.com> Date: Tue, 25 Jun 2019 18:15:47 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------49E4902E1A465E5E20582278" Content-Language: fr Archived-At: Subject: Re: [ipwave] Patching Linux Kernel with OCB - how to howto X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: 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, 25 Jun 2019 16:16:01 -0000 This is a multi-part message in MIME format. --------------49E4902E1A465E5E20582278 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sara, You are asking me about how to patch the kernel successfully 100%. Frankly speaking I dont remember.  The last time I did was several years ago.  Since then I tell others how to.  It is them who know, the programmers.  But each time they do then they move to something else and forget, or no longer care, or their new employer forbids them from telling it to others.  I can remember: Pierre Pfister, Giorgio Campo, Mariama Sarr, Artiol Kalca.  But there were more, including those that I can not talk about. This is the thing I remember most recently: in kernel series 4.x (x is unknown) the OCB is no longer a patch - it is included.  What is needed is to do 'make menuconfig' and check a few options.  There is a 2nd need in the 'iw' command: one needs recent iw commands (v4.9 at the time) because only they have this 'ocb' parameter which turns it on. The only little patch that is needed is about the Regulatory Domain.  The Regulatory Domain tells on which frequencies to work. I hope in kernel 5.y (y is another unknown) there is no longer a need even for that little patch in Regulatory Domain.  I do not know.  You could tell me: is kernel 5.y still in need for a patch for Regulatory Domain for OCB to work? You and John Seur also provided a patch to correct a duplicate definition of 'NL80211_IFTYPE_OCB'.  I never saw that error myself. Maybe all this should be put into one single document, easy to ready for others. Below you can find the OCB howto me and programmers wrote more than a year ago: --------------------------------------------------------------------------------------------------------- - 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 Le 24/06/2019 à 01:32, Sara el hamdani a écrit : > Hello Alex, > > Many thanks for sharing your insights. > > Indeed, we knew during the hackathon that we should better patch the  > kernel in its newest version 5.1.12. However, we couldn't create a new > patch because of the lack of time as mentioned Mr, Nabil. In fact, we > didn't have the right adapter for the physical OCBcard we had. So, we > whole first day spent the the first day trying to install the card on > the desktop including creating manually the adequate antenas.  Then, > we had  only six hours in the next day to capture IPv6 packets > patching and recompiling the kernel ect. > > We have recommended to the organizers the reserve more time to this > truck in future hackathons. We think also that creating a new patch > for the current linux of the kernel is worth to be the object of an > independent truck in the hackathon. > > Concerning the parameters, we have tested the connectivity using ath9k > driver successfully, and we were about to do the same for ath10k but > it was the already presentation time (as we aforementioned a lack of > time). > > For the patch creator, we don't know honestly who he is, but we have > found the link mentioned on a previous email of you in the link: > https://drive.google.com/file/d/0BxK6WTQZ97QVWF9tRURjOGhBU2c/view. > Thus, we decided to fix it and to make it work. > > Besides, even if we arrived to patch the kernel with ath9k, the report > in the terminal showed that it was not completely successful (not > 100%) and it seems that this is what happens usually. So based on your > big in you experience, Mr. Alex, on creating and patching the kernel, > we would know if it is common for you to patch the kernel successfully > 100%? > > > Sara > > Le ven. 21 juin 2019 à 12:41, Nabil Benamar > a écrit : > > Hi Alex, > > Thank you for your comments. > This is exactly what the hackathon participants put in future work! > > 2 days were not enough to build the testbed and test different > drivers and parameters... > > On Fri, Jun 21, 2019, 14:01 Alexandre Petrescu > > wrote: > > Hello Mr. Seur, > > I would like to ask you whether you can apply that patch to > ath10k also? > (instead of ath9k). > > If you do, you risk being the first to achieve 1Gbps on OCB, > hopefully > with IPv6. > > Alex > > Le 20/06/2019 à 15:25, John Seur a écrit : > > Hello IPWavers, > > > > During the Hackathon@AIS2019 > > (https://hackathon.internetsummitafrica.org/), the team in > IPWave track > > (led by Nabil Benamar) was patching the Linux kernel 4.9.61 > with OCB > > mode and discovered the following bugs in the patch file > > > (https://drive.google.com/file/d/0BxK6WTQZ97QVWF9tRURjOGhBU2c/view). > >    drivers/net/wireless/ath/ath9k/main.c:961:2: error: > duplicate case value > >    case NL80211_IFTYPE_OCB: > >    drivers/net/wireless/ath/ath9k/hw.c:1241:2: error: > duplicate case value > >    case NL80211_IFTYPE_OCB: > > > > The duplicated lines of code were commented out and the > patch file works! > > > > _______________________________________________ > > 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./ --------------49E4902E1A465E5E20582278 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Sara,

You are asking me about how to patch the kernel successfully 100%.

Frankly speaking I dont remember.  The last time I did was several years ago.  Since then I tell others how to.  It is them who know, the programmers.  But each time they do then they move to something else and forget, or no longer care, or their new employer forbids them from telling it to others.  I can remember: Pierre Pfister, Giorgio Campo, Mariama Sarr, Artiol Kalca.  But there were more, including those that I can not talk about.

This is the thing I remember most recently: in kernel series 4.x (x is unknown) the OCB is no longer a patch - it is included.  What is needed is to do 'make menuconfig' and check a few options.  There is a 2nd need in the 'iw' command: one needs recent iw commands (v4.9 at the time) because only they have this 'ocb' parameter which turns it on. 

The only little patch that is needed is about the Regulatory Domain.  The Regulatory Domain tells on which frequencies to work.

I hope in kernel 5.y (y is another unknown) there is no longer a need even for that little patch in Regulatory Domain.  I do not know.  You could tell me: is kernel 5.y still in need for a patch for Regulatory Domain for OCB to work?

You and John Seur also  provided a patch to correct a duplicate definition of 'NL80211_IFTYPE_OCB'.  I never saw that error myself.

Maybe all this should be put into one single document, easy to ready for others.

Below you can find the OCB howto me and programmers wrote more than a year ago:

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

- 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

Le 24/06/2019 à 01:32, Sara el hamdani a écrit :
Hello Alex,

Many thanks for sharing your insights. 

Indeed, we knew during the hackathon that we should better patch the  kernel in its newest version 5.1.12. However, we couldn't create a new patch because of the lack of time as mentioned Mr, Nabil. In fact, we didn't have the right adapter for the physical OCBcard we had. So, we whole first day spent the the first day trying to install the card on the desktop including creating manually the adequate antenas.  Then, we had  only six hours in the next day to capture IPv6 packets patching and recompiling the kernel ect. 

We have recommended to the organizers the reserve more time to this truck in future hackathons. We think also that creating a new patch for the current linux of the kernel is worth to be the object of an independent truck in the hackathon.

Concerning the parameters, we have tested the connectivity using ath9k driver successfully, and we were about to do the same for ath10k but it was the already presentation time (as we aforementioned a lack of time).

For the patch creator, we don't know honestly who he is, but we have found the link mentioned on a previous email of you in the link: https://drive.google.com/file/d/0BxK6WTQZ97QVWF9tRURjOGhBU2c/view. Thus, we decided to fix it and to make it work.  

Besides, even if we arrived to patch the kernel with ath9k, the report in the terminal showed that it was not completely successful (not 100%) and it seems that this is what happens usually. So based on your big in you experience, Mr. Alex, on creating and patching the kernel, we would know if it is common for you to patch the kernel successfully 100%?


Sara

Le ven. 21 juin 2019 à 12:41, Nabil Benamar <benamar73@gmail.com> a écrit :
Hi Alex,

Thank you for your comments.
This is exactly what the hackathon participants put in future work!

2 days were not enough to build the testbed and test different drivers and parameters...

On Fri, Jun 21, 2019, 14:01 Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:
Hello Mr. Seur,

I would like to ask you whether you can apply that patch to ath10k also?
(instead of ath9k).

If you do, you risk being the first to achieve 1Gbps on OCB, hopefully
with IPv6.

Alex

Le 20/06/2019 à 15:25, John Seur a écrit :
> Hello IPWavers,
>
> During the Hackathon@AIS2019
> (https://hackathon.internetsummitafrica.org/), the team in IPWave track
> (led by Nabil Benamar) was patching the Linux kernel 4.9.61 with OCB
> mode and discovered the following bugs in the patch file
> (https://drive.google.com/file/d/0BxK6WTQZ97QVWF9tRURjOGhBU2c/view).
>    drivers/net/wireless/ath/ath9k/main.c:961:2: error: duplicate case value
>    case NL80211_IFTYPE_OCB:
>    drivers/net/wireless/ath/ath9k/hw.c:1241:2: error: duplicate case value
>    case NL80211_IFTYPE_OCB:
>
> The duplicated lines of code were commented out and the patch file works!
>
> _______________________________________________
> 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.
--------------49E4902E1A465E5E20582278-- From nobody Tue Jun 25 09:23:22 2019 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 857141207CB for ; Tue, 25 Jun 2019 09:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.217 X-Spam-Level: X-Spam-Status: No, score=-3.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M_DIhJFCmnEY for ; Tue, 25 Jun 2019 09:23: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 BDE671203ED for ; Tue, 25 Jun 2019 09:22:58 -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 x5PGMttX058469; Tue, 25 Jun 2019 18:22:55 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 86A49208F77; Tue, 25 Jun 2019 18:22:55 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 74337207142; Tue, 25 Jun 2019 18:22:55 +0200 (CEST) Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x5PGMtDj003407; Tue, 25 Jun 2019 18:22:55 +0200 To: Alexandre Petrescu , its@ietf.org References: <61452b20-9cd1-c9ce-1eb2-ebb090efb8c4@gmail.com> <936d2cd6-5381-8387-cd2d-e8b33cb5dd7a@gmail.com> From: Alexandre PETRESCU Organization: CEA Message-ID: <460b369c-3d22-34f1-3734-355bba40dff3@cea.fr> Date: Tue, 25 Jun 2019 18:22:54 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060104090902070003010309" Archived-At: Subject: Re: [ipwave] Protocols and Architectures for Traffic Lights X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: 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, 25 Jun 2019 16:23:20 -0000 This is a cryptographically signed message in MIME format. --------------ms060104090902070003010309 Content-Type: multipart/alternative; boundary="------------C25A2BCD0366EA1ABF9248FF" Content-Language: fr This is a multi-part message in MIME format. --------------C25A2BCD0366EA1ABF9248FF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable I got more enlightenment from a recognised expert. In France, in addition to DIASER there is also LCR protocol for Traffic=20 Lights. In UK there is UTMC protocol. NTCIP is acknowledged as a protocol in USA.=C2=A0 Further, it may be=20 implemented by Thales, a French company. -- Alexandre Petrescu alexandre.petrescu@cea.fr, t=C3=A9l 0169089223 Le 06/06/2019 =C3=A0 17:18, Alexandre Petrescu a =C3=A9crit=C2=A0: > > For further completeness... > > The Dutch version of protocols for Traffic Lights Controllers, in=20 > addition to IVERA also include iVRI, on the web at=20 > https://www.crow.nl/thema-s/verkeersmanagement/landelijke-ivri-standaar= den > > The German OCIT protocol is on the web at www.ocit.org > > I continue to wonder what is the protocol used for communicating with=20 > Traffic Lights Controllers in Italy, and in America? > > Alex > > Le 06/06/2019 =C3=A0 05:13, Alexandre Petrescu a =C3=A9crit=C2=A0: >> >> For completeness, >> >> >> The complete list of protocols to communication to Traffic Lights=20 >> Controllers is: DIASER, IVERA, OCIT. >> >> Because I learn in Germany and the Czech Republic, the OCIT protocol=20 >> (not DIASER) may be used for communication to Traffic Lights=20 >> Controller, with some implementations from Siemens and from Cross.=C2=A0= =20 >> Not known whether OCIT works on IP, and on IPv6. >> >> DIASER is known to work on RS232, TCP and UDP.=C2=A0 Seen on IPv4; not= =20 >> known on IPv6.=C2=A0 SEA is a traffic lights controller manufacturer i= n=20 >> France that produces some, implements DIASER too.=C2=A0 There are abou= t 10=20 >> manufacturers in France (Aximum of Colas, Fareco of Fayat, Lacroix,=20 >> SEA, others?), all doing DIASER. >> >> Basically, if one wants a car to talk to traffic lights controllers=20 >> with low latenccy, one wants to put 3 protocols in that car. >> >> >> Le 29/01/2019 =C3=A0 15:04, Alexandre Petrescu a =C3=A9crit=C2=A0: >>> >>> =C2=A0 Protocols and Architectures for Traffic Lights >>> =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0 Janua= y 29th, 2019 >>> >>> >>> DIASER: a protocol used to communicate to Traffic Lights controllers.= >>> Used in France.=C2=A0 Specified by AFNOR.=C2=A0 Closed and paying spe= cification. >>> Works on hardware platforms from Lacroix (model Traffy) and Aximum >>> (model Maestro), and probably others.=C2=A0 Works on serial and on UD= P/IP. >>> Example queries are: "DZ" to reset, "Ck" and "CJ" to query the curren= t >>> color of lights, C# and CU to get the time spent in a color. >>> >>> API WIM 7101, RSGC2: proprietary API interfaces used by organisation >>> NEAVIA of organisation Lacroix in France; it is used to provide acces= s >>> to data of traffic lights controllers.=C2=A0 It can be used with DIAS= ER in >>> a sequence way: a gateway converts from one to another. >>> >>> ISO PRESTO 22951: a protocol to communicate with traffic lights >>> controller, to obtain priority for special vehicles. >>> >>> SPAT/SSM/SRM: protocols used by future traffic lights controllers; >>> specified by SAE in J2735.=C2=A0 The 2009 version is freely available= , >>> whereas the 2016 (non retro-compatible) is paying 100 USD, >>> approximative.=C2=A0 SPAT is Signal Phase and Timing, whereas SRM is = Signal >>> Request Message. >>> >>> SPAT-EM: an European version of SPAT, specified by ETSI, which >>> encapsulates SPAT.=C2=A0 Free access, but SPAT still paying (free >>> encapsulated paying). >>> >>> IVERA: a protocol used in Netherlands to communicate with Traffic >>> Lights controllers.=C2=A0 Potentially VLOG is also such a protocol. >>> >>> 3G Segnaletica: an organisation in Italy that provides hardware for >>> controllers for traffic=C2=A0 lights.=C2=A0 Also has models carried i= n 'mobile' >>> traffic lights.=C2=A0 It provides a Raspberry Pi to access the traffi= c >>> lights data.=C2=A0 The Raspberry Pi uses an API to access the control= ler >>> status.=C2=A0 That API uses HTTP. >>> >>> Siemens: is an organisation that probably provides hardware for >>> traffic lights controllers to be used in America (USA). >>> >>> Architectures: sketches drawing controller, tri-light bulbs, Internet= , >>> 802.11-OCB, car, API, SPAT. >>> >>> Acknowledgements: Daniele Brevi, Bart Netten, Stephane Goeuriot, Sri >>> Gundavelli, Bruno Cabon, Paul Thorpe. >>> >>> >>> _______________________________________________ >>> 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 --------------C25A2BCD0366EA1ABF9248FF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

I got more enlightenm= ent from a recognised expert.

In France, in additio= n to DIASER there is also LCR protocol for Traffic Lights.=

In UK there is UTMC protocol.

NTCIP is acknowledged= as a protocol in USA.=C2=A0 Further, it may be implemented by Thal= es, a French company.

--
Alexandre Petrescu
alexandre.petrescu@cea.fr, t=C3=A9l 0169089223

Le 06/06/2019 =C3=A0 17:18, Alexandre Petrescu a =C3=A9crit=C2=A0:

For further completeness...

The Dutch version o= f protocols for Traffic Lights Controllers, in addition to IVERA also include iVRI, on the web at https://www.crow.nl/thema-s/verkee= rsmanagement/landelijke-ivri-standaarden

The German OCIT protocol is on the web at www.o= cit.org

I continue to wonde= r what is the protocol used for communicating with Traffic Lights Controllers in Italy, and in America?

Alex<= br>

Le 06/06/2019 =C3=A0 05:13, Alexandr= e Petrescu a =C3=A9crit=C2=A0:

For completeness,=


= The complete list of protocols to communication to Traffic Lights Controllers is: DIASER, IVERA, OCIT.

Because I learn i= n Germany and the Czech Republic, the OCIT protocol (not DIASER) may be used for communication to Traffic Lights Controller, with some implementations from Siemens and from Cross.=C2=A0 Not known whether OCIT works on IP, and o= n IPv6.

DIASER is known t= o work on RS232, TCP and UDP.=C2=A0 Seen on IPv4; not known o= n IPv6.=C2=A0 SEA is a traffic lights controller manufacturer= in France that produces some, implements DIASER too.=C2=A0 The= re are about 10 manufacturers in France (Aximum of Colas, Fareco of Fayat, Lacroix, SEA, others?), all doing DIASER.<= /font>

Basically, if one= wants a car to talk to traffic lights controllers with low latenccy, one wants to put 3 protocols in that car.


Le 29/01/2019 =C3=A0 15:04, Alexan= dre Petrescu a =C3=A9crit=C2=A0:

=C2=A0 Protocol= s and Architectures for Traffic Lights
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 = =C2=A0 Januay 29th, 2019


DIASER: a protocol used to communicate to Traffic Lights controllers.
Used in France.=C2=A0 Specified by AFNOR.=C2=A0 Closed an= d paying specification.
Works on hardware platforms from Lacroix (model Traffy) and Aximum
(model Maestro), and probably others.=C2=A0 Works on seri= al and on UDP/IP.
Example queries are: "DZ" to reset, "Ck" and "CJ" to query the current
color of lights, C# and CU to get the time spent in a color.

API WIM 7101, RSGC2: proprietary API interfaces used by organisation
NEAVIA of organisation Lacroix in France; it is used to provide access
to data of traffic lights controllers.=C2=A0 It can be us= ed with DIASER in
a sequence way: a gateway converts from one to another.
ISO PRESTO 22951: a protocol to communicate with traffic lights
controller, to obtain priority for special vehicles.

SPAT/SSM/SRM: protocols used by future traffic lights controllers;
specified by SAE in J2735.=C2=A0 The 2009 version is free= ly available,
whereas the 2016 (non retro-compatible) is paying 100 USD,
approximative.=C2=A0 SPAT is Signal Phase and Timing, whe= reas SRM is Signal
Request Message.

SPAT-EM: an European version of SPAT, specified by ETSI, which
encapsulates SPAT.=C2=A0 Free access, but SPAT still payi= ng (free
encapsulated paying).

IVERA: a protocol used in Netherlands to communicate with Traffic
Lights controllers.=C2=A0 Potentially VLOG is also such a= protocol.

3G Segnaletica: an organisation in Italy that provides hardware for
controllers for traffic=C2=A0 lights.=C2=A0 Also has mode= ls carried in 'mobile'
traffic lights.=C2=A0 It provides a Raspberry Pi to acces= s the traffic
lights data.=C2=A0 The Raspberry Pi uses an API to access= the controller
status.=C2=A0 That API uses HTTP.

Siemens: is an organisation that probably provides hardware for
traffic lights controllers to be used in America (USA).
Architectures: sketches drawing controller, tri-light bulbs, Internet,
802.11-OCB, car, API, SPAT.

Acknowledgements: Daniele Brevi, Bart Netten, Stephane Goeuriot, Sri
Gundavelli, Bruno Cabon, Paul Thorpe.


________________________=
_______________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listin=
fo/its

__________________________=
_____________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listin=
fo/its
--------------C25A2BCD0366EA1ABF9248FF-- --------------ms060104090902070003010309 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 CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xOTA2MjUxNjIyNTVaMC8GCSqGSIb3 DQEJBDEiBCD8ueOXhlY6rbwEFZ+8tCcvcCx+BVHFGUnMvEwAeaylKjBSBgkrBgEEAYI3EAQx RTBDMD0xCzAJBgNVBAYTAkZSMQwwCgYDVQQKDANDRUExIDAeBgNVBAMMF0NFQSBBQyBVdGls aXNhdGV1ciAyMDMxAgIYEjBUBgsqhkiG9w0BCRACCzFFoEMwPTELMAkGA1UEBhMCRlIxDDAK BgNVBAoMA0NFQTEgMB4GA1UEAwwXQ0VBIEFDIFV0aWxpc2F0ZXVyIDIwMzECAhgSMGwGCSqG SIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJ KoZIhvcNAQEBBQAEggEAv+jYXVnmass3w9w/WpfGnowgFfMfQ3v+IivI2fVgE3eGuzgK/v1b 094dQyGDHpdfWDF1fFSshvUwBGHFWf4YJdN9LI6qJzOX9IeCOBHas/UShKg7FQ9nxbNoHBRn I05a8JMvBPn88RJD5pxCmUrjuvwlFo1pCvpJEf5x+LOb3sa6VgIowrn6dKEFKp+3OQSTrET4 80RbwGrcRO4GkKcG5rsKSK0ez6T1rlT81XG3pWRcV0a3muNWF+Tb3VgHW/YYxYJOExhe21Xb HuWb/LIR5a9ClIdJcj1Pd72TV9V2uwJeQ2S5Mgv25HZFsCL8NyRTBY/K7jFnWXaIpMJWC5UX AAAAAAAAAA== --------------ms060104090902070003010309-- From nobody Tue Jun 25 17:50:05 2019 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 810EB120130 for ; Tue, 25 Jun 2019 17:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.497 X-Spam-Level: X-Spam-Status: No, score=-0.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_NAME_FM_MR_MRS=1.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 wFam-7ve-1dh for ; Tue, 25 Jun 2019 17:50:03 -0700 (PDT) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 E8A74120041 for ; Tue, 25 Jun 2019 17:50:02 -0700 (PDT) Received: by mail-wm1-x32c.google.com with SMTP id z23so296111wma.4 for ; Tue, 25 Jun 2019 17:50:02 -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=sOUAGHyt4NYy/di3eyBlmGXzbvj/DzgyoPrvNaaH7N4=; b=vFOKvIBD54RB4pKwaTplFauq2L/3YYvdINPmw8KyPgi0K/R9/CwW/JcqCrlJ/HNsJe iANV5dueVLXrG1Kgpx0IQIdG8rCr+yzW1nHBv56beMYlbC8DgPEKVz0Ydfo8/+Cdvkt1 j8LJdyo6k71jyqC8jEuZfRn9tHmSJHK/hcJiRhFvlPeZJ5miln5N2hTyde4vApl/fEpt BShJo0/VWuScUa5/Q3fO+uw7FQDvvx64YB35U27maVkExqyHwVKxXFvkNZe87wXjwVqk PN/tuH+OtZY/LM6WS4kqEI5nDUFcfCYULTMBOHh2wfKoXqAnjGWQCaRnWjRexLWklI04 K5NQ== 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=sOUAGHyt4NYy/di3eyBlmGXzbvj/DzgyoPrvNaaH7N4=; b=jEdTp31gWaVKcU0fPRDSYnJl2531XY6V751qJPCoRJ626p3kU7WVCaQCVT+9M6S+zY yE+AFAGBigQmA0kHtMV0CnUXo7Bbx8WcE1M+0ZQKTm42mQpT7EOCHiBi9X5/gnvoEuy+ iD4EFWV9bv2n2D52THOFlHyH9fKWLldLCg6QhvMay6PGX1ZbUf0GfXexx+rFGW/XaXm6 dEvVD9WfSDf5efArGjULG/b6Rcay+s6jo3LT081vxmtFtAeQQfA2vsIsN4L8CAhkvBG3 J08tag84ggFFrBNUbWy6yzYik2MocPYD7kfU5S8agUjfyJADNflz7z8twBijxUedX8HW IT9A== X-Gm-Message-State: APjAAAWSkRVvvvvfdFQJgGHxIHWAc/UJp/DmAlgvqTk9igHx60jsnbTF GC4fK9xA29yt3PgREHt3oWL/OqRRQY5Mt6J61W0= X-Google-Smtp-Source: APXvYqw8KxREupQ0biERcaS8MaUGWe4q7VkDtNKqx0vwT6XJbURe8ooQvu3VCEmpFEM7EP/TGNkPr1HvxSioLB4L7mg= X-Received: by 2002:a1c:f512:: with SMTP id t18mr318893wmh.47.1561510201200; Tue, 25 Jun 2019 17:50:01 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Mr. Jaehoon Paul Jeong" Date: Wed, 26 Jun 2019 09:55:05 +0900 Message-ID: To: Russ Housley Cc: =?UTF-8?Q?Carlos_Jes=C3=BAs_Bernardos_Cano?= , its , skku_iotlab_seminar@googlegroups.com, "Mr. Jaehoon Paul Jeong" Content-Type: multipart/alternative; boundary="000000000000db1775058c2f6cf5" Archived-At: Subject: Re: [ipwave] IETF-103 IPWAVE WG Session X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: 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, 26 Jun 2019 00:50:04 -0000 --000000000000db1775058c2f6cf5 Content-Type: text/plain; charset="UTF-8" Russ, I see. Thanks. Best Regards, Paul On Tue, Jun 25, 2019 at 10:49 PM Russ Housley wrote: > Paul: > > As we said in Prague, we will not be discussing the recartering until the > two documents on the existing charter are with the IESG. One of them has > made it, but the other one has not. > > Russ > > > On Jun 24, 2019, at 10:13 PM, Mr. Jaehoon Paul Jeong < > jaehoon.paul@gmail.com> wrote: > > ,Hi Russ and Carlos, > as you know, the revised IPWAVE PS draft was posted. > During this IETF-105 meeting, IPWAVE WG need to discuss the rechartering. > The current assigned time of 30 minutes seems short. > https://datatracker.ietf.org/meeting/105/agenda/ > lp > My SKKU team will lead the IPWAVE ND Hackathon p > > > > -- =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Associate 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 --000000000000db1775058c2f6cf5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Russ,
I see.

Thanks.

Best Regards,
Paul

On Tue, Jun 25, 2019 at = 10:49 PM Russ Housley <housley@v= igilsec.com> wrote:
Paul:

As we said in Prague, we will not be discussing the recartering until th= e two documents on the existing charter are with the IESG.=C2=A0 One of the= m has made it, but the other one has not.

Russ


On Jun 24, 2019, at 10:1= 3 PM, Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com> wrote:

=C2=A0,Hi Russ and Carlos,
as you know, the revised IPWAV= E PS draft was posted.
During this IETF-105 meeting,= IPWAVE WG need to discuss the rechartering.
The cur= rent assigned time of 30 minutes seems short.
lp
My SKKU team will lead the IPWAVE ND Hackathon= p





--
=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.
Associate Professor
Depa= rtment of Software
Sungkyunkwan University
Office: +82-31-299-4957Email: jaehoon= .paul@gmail.com,=C2=A0pauljeong@skku.edu
Personal Homepa= ge: http://iotlab.skku.edu/people-jaehoon-jeong.php
<= /div>
--000000000000db1775058c2f6cf5-- From nobody Wed Jun 26 07:12:59 2019 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E22A8120045 for ; Wed, 26 Jun 2019 07:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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 Ft18eNyovIzZ for ; Wed, 26 Jun 2019 07:12:47 -0700 (PDT) Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) (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 592EB120128 for ; Wed, 26 Jun 2019 07:12:47 -0700 (PDT) Received: by mail-yb1-xb2e.google.com with SMTP id 5so1409470ybj.10 for ; Wed, 26 Jun 2019 07:12:47 -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=ZO6wgCXu2a2daMUB5Lpzn1Jf82aI+VJKbBB8EGAsqQc=; b=MsUqvuON5+r6OmU68+jo9tiPrzF+wE02yNjuMr2jf0/Z/lZelYQz538IZXlPMYtDpg eH+8bugwF29AwW20/u2PHiUy9Chfj+dLZDQl0pL+v6hpK/87Sfy24CkF+8xONIXjcDNW THp6rPzq6kTGLw2BTflPmD28DgTQAYVMa3iz3dQpRCPo5KcwZPTTuwCKZi5nFk/DeaUH VxRn3gk8TuCazDOEz29Wcw5NmbA/jwBmT/pzzTvpRWqWn0NKIhzfxyVTh4AzktpbHWgs r2cpiwJiM3b8M3V9Z5PALAS+cuVsXUwFH/Jh1wr65X4Rl8db2tygCv9iTdjGQftinqq/ NKhw== 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=ZO6wgCXu2a2daMUB5Lpzn1Jf82aI+VJKbBB8EGAsqQc=; b=t2w3S9LBGG2Vt/2Tx3PfFDrOlOtzfAgE05KkaT/QhjevFrQGo+6rSD2iGRwzgn4zPI YWJaK+aYieIW+6mvk8cZWDS691M//DUU2eX+jEHj7TYX+kedoGAHLEnYmkLefpSev8gZ j0uPNh2OBJqr5pAJw6VFn8tSiVhixV6GIX1FcUyPpwgyA2B8Adp+hlyWaym5QBSIjMh1 R6DrQu43R6zxY45MXTJtS/ypBjurEK6F4AYn2530ek7mdyi3lZe/lJ6Jw7arGqVUaNgM Vx1ZTMHb0UL2aBoM55/rT7nVlcW5TOyZ2AOQACqBctHxzE0mTh7BVGAwUKntN//lLhRu v/2Q== X-Gm-Message-State: APjAAAVtvTIo0jr2hTV3t1nxU2Zm2MPhgs4zuEV6wRXCAOveXn0wt3O7 lHCMOg22S46NiXorthMbW0a6Yx+3JHsiMwSsc+PlPcsc8WQlPQ== X-Google-Smtp-Source: APXvYqxGiXtEpdyPREHumPWEVAr66SoMHvc6gAiBDNXc+uSaX+RqhL8W3qqpygCkSp7Gyikn/bwZK8xtiiiTrE0/je8= X-Received: by 2002:a25:6b52:: with SMTP id o18mr2989682ybm.74.1561558365445; Wed, 26 Jun 2019 07:12:45 -0700 (PDT) MIME-Version: 1.0 References: <7c3d7458-2246-7efb-50e0-7bfb6c4389e2@gmail.com> In-Reply-To: <7c3d7458-2246-7efb-50e0-7bfb6c4389e2@gmail.com> From: Sara el hamdani Date: Wed, 26 Jun 2019 15:12:14 +0100 Message-ID: To: Alexandre Petrescu Cc: its@ietf.org, Nabil Benamar Content-Type: multipart/alternative; boundary="000000000000ab20c1058c3aa34c" Archived-At: Subject: Re: [ipwave] Patching Linux Kernel with OCB - how to howto X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: 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, 26 Jun 2019 14:12:57 -0000 --000000000000ab20c1058c3aa34c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Alex, Thank you very much for giving us all this information including the name of programmers. It is more clear to me now, since I know the little parameters that need modification. For the newest version of the kernel (5.Y), I have not yet tested it myself to know if it is still in need for a patch in Regulatory Domain or not. But, when I will do I will surely give you my feedback. Regards Le mar. 25 juin 2019 =C3=A0 17:15, Alexandre Petrescu < alexandre.petrescu@gmail.com> a =C3=A9crit : > Sara, > > You are asking me about how to patch the kernel successfully 100%. > > Frankly speaking I dont remember. The last time I did was several years > ago. Since then I tell others how to. It is them who know, the > programmers. But each time they do then they move to something else and > forget, or no longer care, or their new employer forbids them from tellin= g > it to others. I can remember: Pierre Pfister, Giorgio Campo, Mariama Sar= r, > Artiol Kalca. But there were more, including those that I can not talk > about. > > This is the thing I remember most recently: in kernel series 4.x (x is > unknown) the OCB is no longer a patch - it is included. What is needed i= s > to do 'make menuconfig' and check a few options. There is a 2nd need in > the 'iw' command: one needs recent iw commands (v4.9 at the time) because > only they have this 'ocb' parameter which turns it on. > > The only little patch that is needed is about the Regulatory Domain. The > Regulatory Domain tells on which frequencies to work. > > I hope in kernel 5.y (y is another unknown) there is no longer a need eve= n > for that little patch in Regulatory Domain. I do not know. You could te= ll > me: is kernel 5.y still in need for a patch for Regulatory Domain for OCB > to work? > > You and John Seur also provided a patch to correct a duplicate definitio= n > of 'NL80211_IFTYPE_OCB'. I never saw that error myself. > > Maybe all this should be put into one single document, easy to ready for > others. > > Below you can find the OCB howto me and programmers wrote more than a yea= r > ago: > > > -------------------------------------------------------------------------= -------------------------------- > > - 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 Networkin= g > 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/vie= w; > 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%20Allo= cations.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/publication= File/2659/Frequenznutzungsplan2008_Id17448pdf.pdf > +# For the 5GHz range also see > +# > http://www.bundesnetzagentur.de/cae/servlet/contentblob/38216/publication= File/6579/WLAN5GHzVfg7_2010_28042010pdf.pdf > +# The values have been reduced by a factor of 2 (3db) for non TPC device= s > +# (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=3Dcom_content&view=3Dcategory&lay= out=3Dblog&id=3D10&Itemid=3D55 > +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=C3=83=C2=B3n de frecuencias. > +#http://www.boe.es/diario_boe/txt.php?id=3DBOE-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 i= t > -# 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=C3=83=C2=B3n 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=3D7 > +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=3Dsec&id=3D117&l=3Den > +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%20Fr= equency%20Information%20System/National%20frequency%20tables/Montenegro%20N= AFT%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 =C3=A2=E2=82=AC=E2= =80=9C 5850 MHz can > +# be doubled if TPC is implemented. > +# Up to 2W (or 4W with TPC) is allowed in the 5725 =C3=A2=E2=82=AC=E2=80= =9C 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.p= df > +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=C3=82=C2=B0 2004-005 ART/DG/DRC/D.R=C3=83=C2=A9g > +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=3D40dBm(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.pd= f > +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 us= e > +# (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_Radiocomm= unication_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 > Le 24/06/2019 =C3=A0 01:32, Sara el hamdani a =C3=A9crit : > > Hello Alex, > > Many thanks for sharing your insights. > > Indeed, we knew during the hackathon that we should better patch the > kernel in its newest version 5.1.12. However, we couldn't create a new > patch because of the lack of time as mentioned Mr, Nabil. In fact, we > didn't have the right adapter for the physical OCBcard we had. So, we who= le > first day spent the the first day trying to install the card on the deskt= op > including creating manually the adequate antenas. Then, we had only six > hours in the next day to capture IPv6 packets patching and recompiling th= e > kernel ect. > > We have recommended to the organizers the reserve more time to this truck > in future hackathons. We think also that creating a new patch for the > current linux of the kernel is worth to be the object of an independent > truck in the hackathon. > > Concerning the parameters, we have tested the connectivity using ath9k > driver successfully, and we were about to do the same for ath10k but it w= as > the already presentation time (as we aforementioned a lack of time). > > For the patch creator, we don't know honestly who he is, but we have foun= d > the link mentioned on a previous email of you in the link: > https://drive.google.com/file/d/0BxK6WTQZ97QVWF9tRURjOGhBU2c/view. Thus, > we decided to fix it and to make it work. > > Besides, even if we arrived to patch the kernel with ath9k, the report in > the terminal showed that it was not completely successful (not 100%) and = it > seems that this is what happens usually. So based on your big in you > experience, Mr. Alex, on creating and patching the kernel, we would know = if > it is common for you to patch the kernel successfully 100%? > > > Sara > > Le ven. 21 juin 2019 =C3=A0 12:41, Nabil Benamar a > =C3=A9crit : > >> Hi Alex, >> >> Thank you for your comments. >> This is exactly what the hackathon participants put in future work! >> >> 2 days were not enough to build the testbed and test different drivers >> and parameters... >> >> On Fri, Jun 21, 2019, 14:01 Alexandre Petrescu < >> alexandre.petrescu@gmail.com> wrote: >> >>> Hello Mr. Seur, >>> >>> I would like to ask you whether you can apply that patch to ath10k also= ? >>> (instead of ath9k). >>> >>> If you do, you risk being the first to achieve 1Gbps on OCB, hopefully >>> with IPv6. >>> >>> Alex >>> >>> Le 20/06/2019 =C3=A0 15:25, John Seur a =C3=A9crit : >>> > Hello IPWavers, >>> > >>> > During the Hackathon@AIS2019 >>> > (https://hackathon.internetsummitafrica.org/), the team in IPWave >>> track >>> > (led by Nabil Benamar) was patching the Linux kernel 4.9.61 with OCB >>> > mode and discovered the following bugs in the patch file >>> > (https://drive.google.com/file/d/0BxK6WTQZ97QVWF9tRURjOGhBU2c/view). >>> > drivers/net/wireless/ath/ath9k/main.c:961:2: error: duplicate case >>> value >>> > case NL80211_IFTYPE_OCB: >>> > drivers/net/wireless/ath/ath9k/hw.c:1241:2: error: duplicate case >>> value >>> > case NL80211_IFTYPE_OCB: >>> > >>> > The duplicated lines of code were commented out and the patch file >>> works! >>> > >>> > _______________________________________________ >>> > 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.* > > --=20 *Best regards* *Sara EL HAMDANI* *Phd student -Umi University.* --000000000000ab20c1058c3aa34c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Dear Alex,

Thank you very much for giving us all this information including the name of programmers. =C2=A0

It is more clear to me now, since I know the little parameters that need modification.

For the newest version of the kernel (5.Y), I have not yet tested it myself to know if it is still in need for a patch in Regulatory Domain or not. But, when I will do I will su= rely give you my feedback.

Regards


Le=C2=A0mar. 25 juin 2019 =C3=A0=C2=A01= 7:15, Alexandre Petrescu <alexandre.petrescu@gmail.com> a =C3=A9crit=C2=A0:
=20 =20 =20

Sara,

You are asking me about how to patch the kernel successfully 100%.

Frankly speaking I dont remember.=C2=A0 The last time I did was several years ago.=C2=A0 = Since then I tell others how to.=C2=A0 It is them who know, the programmers.=C2=A0 But each time they do then they move to something else and forget, or no longer care, or their new employer forbids them from telling it to others.=C2=A0 I can remember: Pierre Pfister, Giorgio Campo, Mariama Sarr, Artiol Kalca.=C2=A0 But there were more, including those that I can not talk about.

This is the thing I remember most recently: in kernel series 4.x (x is unknown) the OCB is no longer a patch - it is included.=C2=A0 What is need= ed is to do 'make menuconfig' and check a few options.=C2=A0= There is a 2nd need in the 'iw' command: one needs recent iw comma= nds (v4.9 at the time) because only they have this 'ocb' para= meter which turns it on.=C2=A0

The only little patch that is needed is about the Regulatory Domain.=C2=A0 The Regulato= ry Domain tells on which frequencies to work.

I hope in kernel 5.y (y is another unknown) there is no longer a need even for that little patch in Regulatory Domain.=C2=A0 I do not know.=C2=A0 You= could tell me: is kernel 5.y still in need for a patch for Regulatory Domain for OCB to work?

You and John Seur also= =C2=A0 provided a patch to correct a duplicate definition of 'NL80211_IFTYPE_OCB'.=C2=A0 I never saw that error myself= .

Maybe all this should b= e put into one single document, easy to ready for others.

Below you can find the OCB howto me and programmers wrote more than a year ago:

-----------------------= ---------------------------------------------------------------------------= -------

- 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:
=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 > Networking support &= gt; Wireless ->=C2=A0 cfg80211 - wireless configuration API
=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 > Networking support &= gt; Wireless ->=C2=A0 use statically compiled regulatory rules database
=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 > Networking support &= gt; Wireless -> support CRDA
=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 > Networking support &= gt; Wireless -> Generic IEEE 802.11 Networking Stack (mac80211)
=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 > Device Drivers > = Network device support -> Wireless LAN -> Atheros 802.11n wireless cards support
=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 > Device Drivers > = Network device support -> Wireless LAN -> Atheros ath9k PCI/PCIe bus support
- Patch the kernel using the command "patch -p1 < patch.file&= quot;
- 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/0BxK6WTQZ97QVWF9tRURjOG= hBU2c/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=C2=A0= =C2=A0=C2=A0 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 @@
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CHAN5G(5785, 35), /* Channel 157 */
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CHAN5G(5805, 36), /* Channel 161 */
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CHAN5G(5825, 37), /* Channel 165 */
+
+=C2=A0=C2=A0=C2=A0 CHAN5G(5850, 38), /* Channel 170 */
+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /* ITA-G5B */
+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CHAN5G(5855, 39), /* Chan= nel 171 */
+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CHAN5G(5860, 40), /* Chan= nel 172 */
+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CHAN5G(5865, 41), /* Chan= nel 173 */
+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CHAN5G(5870, 42), /* Chan= nel 174 */
+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /* ITS-G5A */
+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CHAN5G(5875, 43), /* Chan= nel 175 */
+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CHAN5G(5880, 44), /* Chan= nel 176 */
+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CHAN5G(5885, 45), /* Chan= nel 177 */
+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CHAN5G(5890, 46), /* Chan= nel 178 */
+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CHAN5G(5895, 47), /* Chan= nel 179 */
+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CHAN5G(5900, 48), /* Chan= nel 180 */
+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CHAN5G(5905, 49), /* Chan= nel 181 */
+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /* ITS-G5D */
+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CHAN5G(5910, 50), /* Chan= nel 182 */
+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CHAN5G(5915, 51), /* Chan= nel 183 */
+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CHAN5G(5920, 52), /* Chan= nel 184 */
+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CHAN5G(5925, 53), /* Chan= nel 185 */
+
=C2=A0 };
=C2=A0=C2=A0=C2=A0 /* Atheros hardware rate code addition for short p= remble */
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=C2=A0=C2=A0=C2= =A0 2017-11-08 03:08:37.000000000 -0600
+++ linux-4.9.61-pat/drivers/net/wireless/ath/ath9k/hw.h=C2=A0=C2=A0= =C2=A0 2017-11-17 04:34:18.781260652 -0600
@@ -73,7 +73,7 @@
=C2=A0=C2=A0=C2=A0 #define ATH9K_RSSI_BAD=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -128
=C2=A0 -#define ATH9K_NUM_CHANNELS=C2=A0=C2=A0=C2=A0 38
+#define ATH9K_NUM_CHANNELS=C2=A0=C2=A0=C2=A0 54
=C2=A0=C2=A0=C2=A0 /* Register read/write primitives */
=C2=A0 #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=C2=A0=C2=A0=C2=A0 20= 17-11-08 03:08:37.000000000 -0600
+++ linux-4.9.61-pat/drivers/net/wireless/ath/regd.c=C2=A0=C2=A0=C2= =A0 2017-11-17 04:37:11.684613511 -0600
@@ -45,9 +45,9 @@
=C2=A0 /* We allow IBSS on these on a case by case basis by regulator= y domain */
=C2=A0 #define ATH9K_5GHZ_5150_5350=C2=A0=C2=A0=C2=A0 REG_RULE(5150-1= 0, 5350+10, 80, 0, 30,\
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 NL80211_RRF= _NO_IR)
-#define ATH9K_5GHZ_5470_5850=C2=A0=C2=A0=C2=A0 REG_RULE(5470-10, 585= 0+10, 80, 0, 30,\
+#define ATH9K_5GHZ_5470_5925=C2=A0=C2=A0=C2=A0 REG_RULE(5470-10, 592= 5+10, 80, 0, 30,\
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 NL80211_RRF= _NO_IR)
-#define ATH9K_5GHZ_5725_5850=C2=A0=C2=A0=C2=A0 REG_RULE(5725-10, 585= 0+10, 80, 0, 30,\
+#define ATH9K_5GHZ_5725_5925=C2=A0=C2=A0=C2=A0 REG_RULE(5725-10, 592= 5+10, 80, 0, 30,\
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 NL80211_RRF= _NO_IR)
=C2=A0=C2=A0=C2=A0 #define ATH9K_2GHZ_ALL=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 ATH9K_2GHZ_CH01_11, \
@@ -55,11 +55,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=C2=A0=C2=A0=C2=A0=C2=A0 ATH9K_2GHZ_CH14
=C2=A0=C2=A0=C2=A0 #define ATH9K_5GHZ_ALL=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 ATH9K_5GHZ_5150_5350, \
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 ATH9K_5GHZ_5470_5850
+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 ATH9K_5GHZ_5470_5925
=C2=A0=C2=A0=C2=A0 /* This one skips what we call "mid band"= ; */
=C2=A0 #define ATH9K_5GHZ_NO_MIDBAND=C2=A0=C2=A0=C2=A0 ATH9K_5GHZ_515= 0_5350, \
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 ATH9K_5GHZ_5725_5850
+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 ATH9K_5GHZ_5725_5925
=C2=A0=C2=A0=C2=A0 /* Can be used for:
=C2=A0=C2=A0 * 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=C2=A0=C2=A0=C2=A0 2017-11-08 03:08:37.000000000 -0600
+++ linux-4.9.61-pat/net/wireless/db.txt=C2=A0=C2=A0=C2=A0 2017-11-17 04:38:44.958417939 -0600
@@ -1,17 +1,1220 @@
+# This is the world regulatory domain
+country 00:
+=C2=A0=C2=A0=C2=A0 (2402 - 2472 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 # Channel 12 - 13.
+=C2=A0=C2=A0=C2=A0 (2457 - 2482 @ 40), (20), NO-IR
+=C2=A0=C2=A0=C2=A0 # Channel 14. Only JP enables this and for 802.11= b only
+=C2=A0=C2=A0=C2=A0 (2474 - 2494 @ 20), (20), NO-IR, NO-OFDM
+=C2=A0=C2=A0=C2=A0 # Channel 36 - 48
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), NO-IR, AUTO-BW
+=C2=A0=C2=A0=C2=A0 # Channel 52 - 64
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), NO-IR, DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 # Channel 100 - 144
+=C2=A0=C2=A0=C2=A0 (5490 - 5730 @ 160), (20), NO-IR, DFS
+=C2=A0=C2=A0=C2=A0 # Channel 149 - 165
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (20), NO-IR
+=C2=A0=C2=A0=C2=A0 # IEEE 802.11ad (60GHz), channels 1..3
+=C2=A0=C2=A0=C2=A0 (57240 - 63720 @ 2160), (0)
+=C2=A0=C2=A0=C2=A0
+=C2=A0=C2=A0=C2=A0 #channel 172 184=C2=A0=C2=A0=C2=A0
+=C2=A0=C2=A0=C2=A0 (5860 - 5920 @ 80), (10), NO-IR
+
+country AD:
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20)
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 80), (27), DFS
+=C2=A0=C2=A0=C2=A0 # 60 gHz band channels 1-4, ref: Etsi En 302 567
+=C2=A0=C2=A0=C2=A0 (57000 - 66000 @ 2160), (40)
+
+country AE: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (17), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (24), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5730 @ 160), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country AF: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+
+# Source:
+#http://pucanguilla.org/Downloads/January20= 05-Anguilla%20Table%20of%20Allocations.pdf
+country AI: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+
+country AL: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20.00), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20.00), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27.00), DFS
+
+country AM: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (18)
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (18), DFS
+
+country AN: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+
+country AR: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (17), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (24), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5730 @ 160), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country AS: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2472 @ 40), (30)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (24), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (24), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5730 @ 160), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country AT: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+=C2=A0=C2=A0=C2=A0 # 60 gHz band channels 1-4, ref: Etsi En 302 567
+=C2=A0=C2=A0=C2=A0 (57000 - 66000 @ 2160), (40)
+
+country AU:
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (17), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (24), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country AW: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+
+country AZ: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (18), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (18), DFS, AUTO-BW
+
+country BA: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+=C2=A0=C2=A0=C2=A0 # 60 gHz band channels 1-4, ref: Etsi En 302 567
+=C2=A0=C2=A0=C2=A0 (57000 - 66000 @ 2160), (40)
+
+country BB: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (23), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (23), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country BD: DFS-JP
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country BE: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+=C2=A0=C2=A0=C2=A0 # 60 gHz band channels 1-4, ref: Etsi En 302 567
+=C2=A0=C2=A0=C2=A0 (57000 - 66000 @ 2160), (40)
+
+country BF: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (17), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (24), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5730 @ 160), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country BG: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+=C2=A0=C2=A0=C2=A0 # 60 gHz band channels 1-4, ref: Etsi En 302 567
+=C2=A0=C2=A0=C2=A0 (57000 - 66000 @ 2160), (40)
+
+country BH: DFS-JP
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20)
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (20)
+
+country BL: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+
+country BM: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2472 @ 40), (30)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (24), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (24), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5730 @ 160), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country BN: DFS-JP
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (20)
+
+country BO: DFS-JP
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (30), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country BR: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (17), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (24), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5730 @ 160), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country BS: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (24), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (24), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5730 @ 160), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+# Source:
+#http://www.bicma.gov.bt/paper/publication/nrrpart4.pdf
+country BT: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+
+country BY: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+
+country BZ: DFS-JP
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (30)
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country CA: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2472 @ 40), (30)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (17), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (24), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5730 @ 160), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+# Source:
+#http://www.art-rca.org
+country CF: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 40), (17)
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 40), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5490 - 5730 @ 40), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 40), (30)
+
+country CH: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+=C2=A0=C2=A0=C2=A0 # 60 gHz band channels 1-4, ref: Etsi En 302 567
+=C2=A0=C2=A0=C2=A0 (57000 - 66000 @ 2160), (40)
+
+country CI: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (17), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (24), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5730 @ 160), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country CL: DFS-JP
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (20)
+
+country CN: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (23), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (23), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+=C2=A0=C2=A0=C2=A0 # 60 gHz band channels 1,4: 28dBm, channels 2,3: = 44dBm
+=C2=A0=C2=A0=C2=A0 # ref:http://www.miit.gov.cn/n11293472/n11505629/n11506593/n11960250/n11= 960606/n11960700/n12330791.files/n12330790.pdf
+=C2=A0=C2=A0=C2=A0 (57240 - 59400 @ 2160), (28)
+=C2=A0=C2=A0=C2=A0 (59400 - 63720 @ 2160), (44)
+=C2=A0=C2=A0=C2=A0 (63720 - 65880 @ 2160), (28)
+
+country CO: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (17), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (24), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5730 @ 160), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country CR: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (17)
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5490 - 5730 @ 80), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country CX: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (24), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (24), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5730 @ 160), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country CY: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+=C2=A0=C2=A0=C2=A0 # 60 gHz band channels 1-4, ref: Etsi En 302 567
+=C2=A0=C2=A0=C2=A0 (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
+=C2=A0=C2=A0=C2=A0 (2400 - 2483.5 @ 40), (100 mW)
+=C2=A0=C2=A0=C2=A0 (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AU= TO-BW
+=C2=A0=C2=A0=C2=A0 (5470 - 5725 @ 160), (500 mW), DFS
+=C2=A0=C2=A0=C2=A0 # 60 gHz band channels 1-4, ref: Etsi En 302 567
+=C2=A0=C2=A0=C2=A0 (57000 - 66000 @ 2160), (40)
+
+# Data from "Frequenznutzungsplan" (as published in April = 2008), downloaded from
+#http= ://www.bundesnetzagentur.de/cae/servlet/contentblob/38448/publicationFile/2= 659/Frequenznutzungsplan2008_Id17448pdf.pdf
+# For the 5GHz range also see
+#http://www= .bundesnetzagentur.de/cae/servlet/contentblob/38216/publicationFile/6579/WL= AN5GHzVfg7_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
+=C2=A0=C2=A0=C2=A0 # entries 279004 and 280006
+=C2=A0=C2=A0=C2=A0 (2400 - 2483.5 @ 40), (100 mW)
+=C2=A0=C2=A0=C2=A0 # entry 303005
+=C2=A0=C2=A0=C2=A0 (5150 - 5250 @ 80), (100 mW), NO-OUTDOOR, AUTO-BW
+=C2=A0=C2=A0=C2=A0 # entries 304002 and 305002
+=C2=A0=C2=A0=C2=A0 (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AU= TO-BW
+=C2=A0=C2=A0=C2=A0 # entries 308002, 309001 and 310003
+=C2=A0=C2=A0=C2=A0 (5470 - 5725 @ 160), (500 mW), DFS
+=C2=A0=C2=A0=C2=A0 # 60 gHz band channels 1-4, ref: Etsi En 302 567
+=C2=A0=C2=A0=C2=A0 (57000 - 66000 @ 2160), (40)
+
+country DK: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+=C2=A0=C2=A0=C2=A0 # 60 gHz band channels 1-4, ref: Etsi En 302 567
+=C2=A0=C2=A0=C2=A0 (57000 - 66000 @ 2160), (40)
+
+# Source:
+#http://= www.ntrcdom.org/index.php?option=3Dcom_content&view=3Dcategory&layo= ut=3Dblog&id=3D10&Itemid=3D55
+country DM: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2472 @ 40), (30)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (17), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (23), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country DO: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2472 @ 40), (30)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (17), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (23), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country DZ: DFS-JP
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170.000 - 5250.000 @ 80.000), (23.00), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250.000 - 5330.000 @ 80.000), (23.00), DFS, AUT= O-BW
+=C2=A0=C2=A0=C2=A0 (5490.000 - 5670.000 @ 160.000), (23.00), DFS
+
+country EC: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (17)
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5490 - 5730 @ 80), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country EE: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+=C2=A0=C2=A0=C2=A0 # 60 gHz band channels 1-4, ref: Etsi En 302 567
+=C2=A0=C2=A0=C2=A0 (57000 - 66000 @ 2160), (40)
+
+country EG: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20)
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS
+
+# Orden IET/787/2013, de 25 de abril, por la que se aprueba
+# el cuadro nacional de atribuci=C3=83=C2=B3n de frecuencias.
+#http://www.boe.es/diario_boe/txt.php?id=3DBOE-A-2013-4845
=C2=A0 #
-# This file is a placeholder to prevent accidental build breakage if someone
-# enables CONFIG_CFG80211_INTERNAL_REGDB.=C2=A0 Almost no one actual= ly needs to
-# enable that build option.
-#
-# You should be using CRDA instead.=C2=A0 It is even better if you u= se the CRDA
-# package provided by your distribution, since they will probably keep it
-# up-to-date on your behalf.
-#
-# If you_really_=C2=A0 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.=C2=A0 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=C3=83=C2=B3n de fre= cuencias (CNAF)":
+#http://www.minetur.gob.es/telecomunicaciones/espectro/p= aginas/cnaf.aspx
+
+country ES: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2400 - 2483.5 @ 40), (100 mW)
+=C2=A0=C2=A0=C2=A0 (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AU= TO-BW
+=C2=A0=C2=A0=C2=A0 (5470 - 5725 @ 160), (500 mW), DFS
+=C2=A0=C2=A0=C2=A0 # 60 gHz band channels 1-4, ref: Etsi En 302 567
+=C2=A0=C2=A0=C2=A0 (57000 - 66000 @ 2160), (40)
+
+country ET: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+
+country FI: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+=C2=A0=C2=A0=C2=A0 # 60 gHz band channels 1-4, ref: Etsi En 302 567
+=C2=A0=C2=A0=C2=A0 (57000 - 66000 @ 2160), (40)
+
+country FM: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2472 @ 40), (30)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (24), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (24), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5730 @ 160), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country FR: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+=C2=A0=C2=A0=C2=A0 # 60 gHz band channels 1-4, ref: Etsi En 302 567
+=C2=A0=C2=A0=C2=A0 (57000 - 66000 @ 2160), (40)
+
+country GB: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+=C2=A0=C2=A0=C2=A0 # 60 gHz band channels 1-4, ref: Etsi En 302 567
+=C2=A0=C2=A0=C2=A0 (57000 - 66000 @ 2160), (40)
+
+country GD: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2472 @ 40), (30)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (17), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (24), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5730 @ 160), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country GE: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (18), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (18), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 # 60 gHz band channels 1-4, ref: Etsi En 302 567
+=C2=A0=C2=A0=C2=A0 (57000 - 66000 @ 2160), (40)
+
+country GF: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+
+country GH: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (17), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (24), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5730 @ 160), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country GL: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20)
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 80), (27), DFS
+
+country GP: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+
+country GR: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+=C2=A0=C2=A0=C2=A0 # 60 gHz band channels 1-4, ref: Etsi En 302 567
+=C2=A0=C2=A0=C2=A0 (57000 - 66000 @ 2160), (40)
+
+country GT: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2472 @ 40), (30)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (17), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (23), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country GU: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2472 @ 40), (30)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (17)
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5490 - 5730 @ 80), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country GY:
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (30)
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country HK:
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (17), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (24), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country HN: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (17), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (24), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5730 @ 160), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country HR: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+=C2=A0=C2=A0=C2=A0 # 60 gHz band channels 1-4, ref: Etsi En 302 567
+=C2=A0=C2=A0=C2=A0 (57000 - 66000 @ 2160), (40)
+
+country HT: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2472 @ 40), (30)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (24), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (24), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5730 @ 160), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country HU: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+=C2=A0=C2=A0=C2=A0 # 60 gHz band channels 1-4, ref: Etsi En 302 567
+=C2=A0=C2=A0=C2=A0 (57000 - 66000 @ 2160), (40)
+
+country ID: DFS-JP
+=C2=A0=C2=A0=C2=A0 # ref:http://www.postel.g= o.id/content/ID/regulasi/standardisasi/kepdir/bwa%205,8%20ghz.pdf
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5735 - 5815 @ 80), (23)
+
+country IE: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+=C2=A0=C2=A0=C2=A0 # 60 gHz band channels 1-4, ref: Etsi En 302 567
+=C2=A0=C2=A0=C2=A0 (57000 - 66000 @ 2160), (40)
+
+country IL: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5350 @ 80), (200 mW), NO-OUTDOOR, DFS, AU= TO-BW
+
+country IN: DFS-JP
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (20)
+
+country IR: DFS-JP
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country IS: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+=C2=A0=C2=A0=C2=A0 # 60 gHz band channels 1-4, ref: Etsi En 302 567
+=C2=A0=C2=A0=C2=A0 (57000 - 66000 @ 2160), (40)
+
+country IT: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+=C2=A0=C2=A0=C2=A0 # 60 gHz band channels 1-4, ref: Etsi En 302 567
+=C2=A0=C2=A0=C2=A0 (57000 - 66000 @ 2160), (40)
+
+country JM: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (17), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (24), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5730 @ 160), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country JO: DFS-JP
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (23)
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (23)
+
+country JP: DFS-JP
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (2474 - 2494 @ 20), (20), NO-OFDM
+=C2=A0=C2=A0=C2=A0 (4910 - 4990 @ 40), (23)
+=C2=A0=C2=A0=C2=A0 (5030 - 5090 @ 40), (23)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (23), DFS
+
+country KE: DFS-JP
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (23)
+=C2=A0=C2=A0=C2=A0 (5490 - 5570 @ 80), (30), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5775 @ 40), (23)
+
+country KH: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+
+# Source
+#http://ntrc.kn/?page_id= =3D7
+country KN: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (30), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5815 @ 80), (30)
+
+country KP: DFS-JP
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5630 @ 80), (30), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5815 @ 80), (30)
+
+country KR: DFS-JP
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (30), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country KW: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+
+country KY: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (24), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (24), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5730 @ 160), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country KZ:
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+
+country LB: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (17), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (24), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5730 @ 160), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+# Source:
+#ht= tp://www.ntrc.org.lc/operational_structures.htm
+country LC: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (30), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5815 @ 80), (30)
+
+country LI: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+
+country LK: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (17)
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5490 - 5730 @ 80), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+# Source:
+#http://lca.org.ls/images/documents/lesotho_na= tional_frequency_allocation_plan.pdf
+country LS: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+
+country LT: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+=C2=A0=C2=A0=C2=A0 # 60 gHz band channels 1-4, ref: Etsi En 302 567
+=C2=A0=C2=A0=C2=A0 (57000 - 66000 @ 2160), (40)
+
+country LU: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+=C2=A0=C2=A0=C2=A0 # 60 gHz band channels 1-4, ref: Etsi En 302 567
+=C2=A0=C2=A0=C2=A0 (57000 - 66000 @ 2160), (40)
+
+country LV: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+=C2=A0=C2=A0=C2=A0 # 60 gHz band channels 1-4, ref: Etsi En 302 567
+=C2=A0=C2=A0=C2=A0 (57000 - 66000 @ 2160), (40)
+
+country MA: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+
+country MC: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+
+# Source:
+#http://www.cnfr.md/index.php?pag=3Dsec&id=3D117&l=3Den<= /a>
+country MD: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+
+# Source:
+#
http://www.cept.org/files/1050/Tool= s%20and%20Services/EFIS%20-%20ECO%20Frequency%20Information%20System/Nation= al%20frequency%20tables/Montenegro%20NAFT%20-%202010.pdf
+country ME: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+
+country MF: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+
+country MH: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2472 @ 40), (30)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (24), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (24), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5730 @ 160), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country MK: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+=C2=A0=C2=A0=C2=A0 # 60 gHz band channels 1-4, ref: Etsi En 302 567
+=C2=A0=C2=A0=C2=A0 (57000 - 66000 @ 2160), (40)
+
+country MN: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (24), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (24), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5730 @ 160), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country MO:
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 40), (23)
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 40), (23), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 40), (30)
+
+country MP: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2472 @ 40), (30)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (24), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (24), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5730 @ 160), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country MQ: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+
+# Source:
+#htt= p://www.are.mr/pdfs/telec_freq_TNAbf_2010.pdf
+country MR: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+
+country MT: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+=C2=A0=C2=A0=C2=A0 # 60 gHz band channels 1-4, ref: Etsi En 302 567
+=C2=A0=C2=A0=C2=A0 (57000 - 66000 @ 2160), (40)
+
+country MU: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (24), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (24), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5730 @ 160), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country MW: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+
+country MX: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (17), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (24), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5730 @ 160), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country MY: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (17), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (23), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country NI: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2472 @ 40), (30)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (24), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (24), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5730 @ 160), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country NL: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), NO-OUTDOOR, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), NO-OUTDOOR, DFS, AUTO-B= W
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+=C2=A0=C2=A0=C2=A0 # 60 gHz band channels 1-4, ref: Etsi En 302 567
+=C2=A0=C2=A0=C2=A0 (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 =C3=A2=E2=82=AC= =E2=80=9C 5850 MHz can
+# be doubled if TPC is implemented.
+# Up to 2W (or 4W with TPC) is allowed in the 5725 =C3=A2=E2=82=AC= =E2=80=9C 5795 MHz band
+# which has been merged with 5470 - 5725 MHz to allow wide channels
+country NO: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2400 - 2483.5 @ 40), (100 mW)
+=C2=A0=C2=A0=C2=A0 (5150 - 5250 @ 80), (200 mW), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5350 @ 80), (100 mW), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5470 - 5795 @ 160), (500 mW), DFS
+=C2=A0=C2=A0=C2=A0 (5815 - 5850 @ 35), (2000 mW), DFS
+=C2=A0=C2=A0=C2=A0 (17100 - 17300 @ 200), (100 mW)
+=C2=A0=C2=A0=C2=A0 # 60 gHz band channels 1-4, ref: Etsi En 302 567
+=C2=A0=C2=A0=C2=A0 (57000 - 66000 @ 2160), (40)
+
+country NP: DFS-JP
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (20)
+
+country NZ: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (30)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (17), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (24), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5730 @ 160), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country OM: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+
+country PA: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2472 @ 40), (30)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (17), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (23), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country PE: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (17), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (24), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5730 @ 160), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country PF: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+
+country PG: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (17), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (24), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5730 @ 160), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country PH: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (17), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (24), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5730 @ 160), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country PK: DFS-JP
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country PL: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+=C2=A0=C2=A0=C2=A0 # 60 gHz band channels 1-4, ref: Etsi En 302 567
+=C2=A0=C2=A0=C2=A0 (57000 - 66000 @ 2160), (40)
+
+country PM: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+
+country PR: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2472 @ 40), (30)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (17), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (24), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5730 @ 160), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country PT: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+=C2=A0=C2=A0=C2=A0 # 60 gHz band channels 1-4, ref: Etsi En 302 567
+=C2=A0=C2=A0=C2=A0 (57000 - 66000 @ 2160), (40)
+
+country PW: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2472 @ 40), (30)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (24), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (24), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5730 @ 160), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country PY: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (24), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (24), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5730 @ 160), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country QA: DFS-JP
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country RE: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+
+country RO: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+=C2=A0=C2=A0=C2=A0 # 60 gHz band channels 1-4, ref: Etsi En 302 567
+=C2=A0=C2=A0=C2=A0 (57000 - 66000 @ 2160), (40)
+
+
+# Source:
+#http://www.ratel.rs/upload/documents/Plan_namene/Pl= an_namene-sl_glasnik.pdf
+country RS: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2400 - 2483.5 @ 40), (100 mW)
+=C2=A0=C2=A0=C2=A0 (5150 - 5350 @ 40), (200 mW), NO-OUTDOOR
+=C2=A0=C2=A0=C2=A0 (5470 - 5725 @ 20), (1000 mW), DFS
+=C2=A0=C2=A0=C2=A0 # 60 gHz band channels 1-4, ref: Etsi En 302 567
+=C2=A0=C2=A0=C2=A0 (57000 - 66000 @ 2160), (40)
+
+country RU: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20)
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS
+=C2=A0=C2=A0=C2=A0 (5650 - 5730 @ 80), (30), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country RW: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (17), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (24), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5730 @ 160), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country SA: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+
+country SE: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+=C2=A0=C2=A0=C2=A0 # 60 gHz band channels 1-4, ref: Etsi En 302 567
+=C2=A0=C2=A0=C2=A0 (57000 - 66000 @ 2160), (40)
+
+country SG: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (17), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (24), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5730 @ 160), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country SI: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+=C2=A0=C2=A0=C2=A0 # 60 gHz band channels 1-4, ref: Etsi En 302 567
+=C2=A0=C2=A0=C2=A0 (57000 - 66000 @ 2160), (40)
+
+country SK: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+=C2=A0=C2=A0=C2=A0 # 60 gHz band channels 1-4, ref: Etsi En 302 567
+=C2=A0=C2=A0=C2=A0 (57000 - 66000 @ 2160), (40)
+
+# Source:
+# Regulation N=C3=82=C2=B0 2004-005 ART/DG/DRC/D.R=C3=83=C2=A9g
+country SN: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (17), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (24), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5730 @ 160), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country SR: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+
+country SV: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (17)
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (23), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country SY:
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+
+# Source:
+#http://www.telecommission.tc/Spectrum-plan20110324-101210.html<= /a>
+country TC: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (24), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (24), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5730 @ 160), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country TD: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+
+country TG: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 40), (20), DFS
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 40), (27), DFS
+
+country TH: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (17), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (24), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5730 @ 160), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country TN: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+
+country TR: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+=C2=A0=C2=A0=C2=A0 # 60 gHz band channels 1-4, ref: Etsi En 302 567
+=C2=A0=C2=A0=C2=A0 (57000 - 66000 @ 2160), (40)
+
+country TT: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (17), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (24), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5730 @ 160), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country TW: DFS-JP
+=C2=A0=C2=A0=C2=A0 (2402 - 2472 @ 40), (30)
+=C2=A0=C2=A0=C2=A0 (5270 - 5330 @ 40), (17), DFS
+=C2=A0=C2=A0=C2=A0 (5490 - 5590 @ 80), (30), DFS
+=C2=A0=C2=A0=C2=A0 (5650 - 5710 @ 40), (30), DFS
+=C2=A0=C2=A0=C2=A0 (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/12252693= 61
+# (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
+=C2=A0=C2=A0=C2=A0 (2400 - 2483.5 @ 40), (20), NO-OUTDOOR
+=C2=A0=C2=A0=C2=A0 (5150 - 5350 @ 40), (20), NO-OUTDOOR
+=C2=A0=C2=A0=C2=A0 (5490 - 5670 @ 80), (20), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (20)
+=C2=A0=C2=A0=C2=A0 # 60 gHz band channels 1-4, ref: Etsi En 302 567
+=C2=A0=C2=A0=C2=A0 (57000 - 66000 @ 2160), (40)
+
+country UG: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (24), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (24), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5730 @ 160), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country US: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2472 @ 40), (30)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (17), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (23), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 20), (30)
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+=C2=A0=C2=A0=C2=A0 (5850 - 5935 @ 10), (30)
+=C2=A0=C2=A0=C2=A0 # 60g band
+=C2=A0=C2=A0=C2=A0 # reference:http://cfr.regstoday.com/47cfr15.aspx#47_CFR_1= 5p255
+=C2=A0=C2=A0=C2=A0 # channels 1,2,3, EIRP=3D40dBm(43dBm peak)
+=C2=A0=C2=A0=C2=A0 (57240 - 63720 @ 2160), (40)
+
+country UY: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (17), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (24), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5730 @ 160), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+# Source:
+#http://cemc.uz/article/= 1976/
+country UZ: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+
+# Source:
+#http://www.ntrc.vc/regulations/Jun_2006_Spectrum_Man= agment_Regulations.pdf
+country VC: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (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
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (30)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (23), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (23), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country VI: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2472 @ 40), (30)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (24), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (24), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5730 @ 160), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country VN: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (17)
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5490 - 5730 @ 80), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+# Source:
+#http://www.trr.vu/attachments/c= ategory/130/GURL_for_Short-range_Radiocommunication_Devices2.pdf
+country VU: DFS-FCC
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (17), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (24), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5730 @ 160), (24), DFS
+=C2=A0=C2=A0=C2=A0 (5735 - 5835 @ 80), (30)
+
+country WF: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+
+country YE:
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+
+country YT: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+
+country ZA: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5490 - 5710 @ 160), (27), DFS
+
+country ZW: DFS-ETSI
+=C2=A0=C2=A0=C2=A0 (2402 - 2482 @ 40), (20)
+=C2=A0=C2=A0=C2=A0 (5170 - 5250 @ 80), (20), AUTO-BW
+=C2=A0=C2=A0=C2=A0 (5250 - 5330 @ 80), (20), DFS, AUTO-BW
+=C2=A0=C2=A0=C2=A0 (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

Le 24/06/2019= =C3=A0 01:32, Sara el hamdani a =C3=A9crit=C2=A0:
=20
Hello Alex,

Many thanks for sharing your insights.=C2=A0

Indeed, we knew during the hackathon that we should better patch the=C2=A0 kernel in its newest version 5.1.12. However, we couldn't create a new patch because of the lack of time as mentioned Mr, Nabil. In fact, we didn't have the right adapte= r for the physical OCBcard we had. So, we whole first day spent the the first day trying to install the card on the desktop including creating manually the adequate antenas.=C2=A0 Then, we had=C2=A0 only six hours in the next day to capture IPv6 packets patching and recompiling the kernel ect.=C2=A0

We have recommended to the organizers the reserve more time to this truck in future hackathons. We think also that creating a new patch for the current linux of the kernel is worth to be the object of an independent truck in the hackathon.

Concerning the parameters, we have tested the connectivity using ath9k driver successfully, and we were about to do the same for ath10k but it was the already presentation time (as we aforementioned a lack of time).

For the patch creator, we don't know honestly who he is, but we have found the link mentioned on a previous email of you in the link:=C2=A0https://drive.google.c= om/file/d/0BxK6WTQZ97QVWF9tRURjOGhBU2c/view. Thus, we decided to fix it and to make it work.=C2=A0=C2=A0

Besides, even if we arrived to patch the kernel with ath9k, the report in the terminal showed that it was not completely successful (not 100%) and it seems that this is what happens usually. So based on your big in you experience, Mr. Alex, on creating and patching the kernel, we would know if it is common for you to patch the kernel successfully 100%?


Sara

Le=C2=A0ven. 21 juin 2019 =C3= =A0=C2=A012:41, Nabil Benamar <benamar73@gmail.com> a =C3=A9crit=C2=A0:
Hi Alex,

Thank you for your comments.
This is exactly what the hackathon participants put in future work!

2 days were not enough to build the testbed and test different drivers and parameters...

On Fri, Jun 21, 2019, 14:01 Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:
Hello Mr. Seu= r,

I would like to ask you whether you can apply that patch to ath10k also?
(instead of ath9k).

If you do, you risk being the first to achieve 1Gbps on OCB, hopefully
with IPv6.

Alex

Le 20/06/2019 =C3=A0 15:25, John Seur a =C3=A9crit=C2=A0:
> Hello IPWavers,
>
> During the Hackathon@AIS2019
> (https://hackathon.internet= summitafrica.org/), the team in IPWave track
> (led by Nabil Benamar) was patching the Linux kernel 4.9.61 with OCB
> mode and discovered the following bugs in the patch file
> (http= s://drive.google.com/file/d/0BxK6WTQZ97QVWF9tRURjOGhBU2c/view).
>=C2=A0 =C2=A0 drivers/net/wireless/ath/ath9k/main.c:961:2= : error: duplicate case value
>=C2=A0 =C2=A0 case NL80211_IFTYPE_OCB:
>=C2=A0 =C2=A0 drivers/net/wireless/ath/ath9k/hw.c:1241:2:= error: duplicate case value
>=C2=A0 =C2=A0 case NL80211_IFTYPE_OCB:
>
> The duplicated lines of code were commented out and the patch file works!
>
> _______________________________________________
> its mailing list
> its@ietf.org
> https://www.ietf.org/mailman/= listinfo/its
>

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


--
Best regards=

Sa= ra EL HAMDANI<= br>
P= hd student=C2=A0-U= mi University.


--
Best regards

Sara EL HAMDANI
<= i>Phd student=C2=A0-Umi University.
--000000000000ab20c1058c3aa34c-- From nobody Thu Jun 27 09:38:46 2019 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 D750012016A; Thu, 27 Jun 2019 09:38:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joerg Ott via Datatracker To: Cc: ietf@ietf.org, its@ietf.org, draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Joerg Ott Message-ID: <156165351682.21357.6959207590092474225@ietfa.amsl.com> Date: Thu, 27 Jun 2019 09:38:36 -0700 Archived-At: Subject: [ipwave] Tsvart last call review of draft-ietf-ipwave-ipv6-over-80211ocb-46 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 List-Id: 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, 27 Jun 2019 16:38:37 -0000 Reviewer: Joerg Ott Review result: On the Right Track This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review. The draft discusses the most basic operation of IPv6 over IEEE 802.11-OCB, i.e., a flavour of ad-hoc networks specifically for vehicular connectivity (formerly known as IEEE 802.11p). The document mainly covers question of mapping IPv6 packets to the MAC layer frames, discusses aspects of address assignment and subnets, and neighbour discovery. The core document is rather short but has extensive appendices. There are no clear transport issues in this document. The main relevant aspect would be MTU size, which is in line with standard IPv6. But the document discusses (section 4.2) that all IPv6 packets should be mapped to the same class of service. So, there is no service differentiation expected (diffserv, for example)? However, I do not consider the document to be really ready because of structure and writing clarity. This is surprising for version -46! There is a need for improvement to make the document properly understandable by the reader. I am actually wondering why this document is sent out for last call given the state the text is in. Detailed comments: In several places, the text reminds of patent jargon. Should I worry? There doesn't appear to be any IPR disclosure. p5, 1st line: packet->packets The use of RFC 2026 language needs improvement. sect. 4.4: transition time is not defined "no generic meaning" -- means what? This section is confusing. Please describe a concrete sequence of actions sect. 4.5: external references for standards are surely the right way. But the reader may benefit from some informal self-contained description. sect. 4.5.2: anythings needs to be said about multicast reception? sect 4.6: Clarify "A subnet may be formed over 802.11-OCB interfaces of vehicles that are in close range (not by their in-vehicle interfaces)." further. sect. 5: explain briefly how certificates are supposed to work with variable addresses. App. E: why would high mobility affect encapsulation"? App. G: Ok to show complete packet formats. But then maybe also give specific examples? And why do you describe this as capturing what is received rather than how to construct something to sent out? App. I: reliable multicast used incorrectly "TBD TBD TBD" Nits: "mode.A", "; The", "on another hand", "At application layer" "attacker can therefore just sit in the near range of vehicles" "perform attacks without needing to physically break any wall." "embarking an" "outdoors public environments" "attacker sniffers" "indoor settings" "eventual conflicts" "internet" expand all acronyms, also in the appendices Why has sect. 5.3 bullets? From nobody Thu Jun 27 14:16:23 2019 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 66B50120018; Thu, 27 Jun 2019 14:16:21 -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.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: its@ietf.org Message-ID: <156167018133.21707.14512635817495822603@ietfa.amsl.com> Date: Thu, 27 Jun 2019 14:16:21 -0700 Archived-At: Subject: [ipwave] I-D Action: draft-ietf-ipwave-ipv6-over-80211ocb-47.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 List-Id: 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, 27 Jun 2019 21:16:22 -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 : Basic support for IPv6 over IEEE Std 802.11 Networks operating Outside the Context of a Basic Service Set (IPv6-over-80211-OCB) Authors : Nabil Benamar Jerome Haerri Jong-Hyouk Lee Thierry Ernst Filename : draft-ietf-ipwave-ipv6-over-80211ocb-47.txt Pages : 32 Date : 2019-06-27 Abstract: This document provides methods and settings, and describes limitations, for using IPv6 to communicate among nodes in range of one another over a single IEEE 802.11-OCB link with minimal change to existing stacks. Optimizations and usage of IPv6 over more complex scenarios is not covered and is subject of future work. 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-47 https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-47 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-47 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 Jun 28 16:00:13 2019 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 A28B91208ED; Fri, 28 Jun 2019 15:57:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: suresh@kaloom.com, its@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156176267365.11015.15510654314101865543.idtracker@ietfa.amsl.com> Date: Fri, 28 Jun 2019 15:57:53 -0700 Archived-At: Subject: [ipwave] ipwave - Requested session has been scheduled for IETF 105 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 List-Id: 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, 28 Jun 2019 22:58:00 -0000 Dear Russ Housley, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. ipwave Session 1 (0:30 requested) Tuesday, 23 July 2019, Morning Session I 1000-1200 Room Name: Sainte-Catherine size: 100 --------------------------------------------- Special Note: 1130-1200 iCalendar: https://datatracker.ietf.org/meeting/105/sessions/ipwave.ics Request Information: --------------------------------------------------------- Working Group Name: IP Wireless Access in Vehicular Environments Area Name: Internet Area Session Requester: Russ Housley Number of Sessions: 1 Length of Session(s): 30 Minutes Number of Attendees: 50 Conflicts to Avoid: First Priority: dmm detnet lamps stir intarea 6lo 6man manet rtgarea saag suit tls mls dhc Second Priority: sfc cfrg roll i2nsf secdispatch teep People who must be present: Russ Housley Suresh Krishnan Carlos J. Bernardos Resources Requested: Special Requests: Dur to travel to a family wedding, please do not schedule this session on Friday. ---------------------------------------------------------
Hi=C2=A0J=C3=A9r=C3=B4me and Alex,

Sorr= y I have not followed this discussion in detail.=C2=A0 If any of my comment= s are off base, I apologize.

Having read J=C3=A9r= =C3=B4me's comments, I want to agree with them.=C2=A0 I especially want= to emphasize that if we are considering operating in public spectrum (5.9 = GHz in most regions) we have to be cognizant of how our channel use may imp= act other users whose applications are equally important from a public safe= ty perspective, perhaps even more important.=C2=A0 This is one reason why s= o many resources have been devoted to researching and testing channel scala= bility protocols (congestion control).=C2=A0 In the US, the FCC bandplan an= d the SAE J2945/0 standard channel usage plan specify that every channel wi= ll be available for use by safety applications.

On= e additional note about channel bandwidth.=C2=A0 IEEE 802.11 specifies chan= nel width options of 20 MHz, 10 MHz, and 5 MHz in the 5.9 GHz bands of the = US and Europe.=C2=A0 Spectrum regulations further limit those to 20 MHz and= 10 MHz in the US and only 10 MHz in Europe.=C2=A0 However, while 20 MHz ch= annels are in the FCC regulations for the US, we do not expect overlapping = 20 MHz and 10 MHz to be used in the same time and place. CSMA/CA will not w= ork well in such an overlapping case because the devices will not natively = detect each other's preambles.=C2=A0 In fact, 10 MHz usage is the norm,= and we do not expect to see 20 MHz usage in the US.=C2=A0

This may change with the development of IEEE 802.11bd (Next Genera= tion V2X), which J=C3=A9r=C3=B4me mentioned.=C2=A0 That task group is consi= dering ways to specify a 20 MHz channel that coexists well with constituent= 10 MHz users (both 802.11bd and 802.11p).

One fin= al point.=C2=A0 Some V2X researchers are quite interested in using 60 GHz m= mWave spectrum for dissemination of information requiring bit rates on the = order of 100s Mbps or 1 Gpbs.=C2=A0 This is an active area of research.=C2= =A0 This may be a better option for high bit rate V2X communication than 5.= 9 GHz, though of course it has different characteristics and constraints.

Best Regards,
John




On Thu, Jun 13, 2019 at 2:00 AM J=C3=A9r=C3= =B4me H=C3=A4rri <jerome.hae= rri@eurecom.fr> wrote:

Dear Alex,

=C2=A0<= /span>

You are totally right=E2=80=A6appl= ications have increased needs and it is not the right wat to tell an applic= ation to send less because of finite capacity of a given technology. One th= ing to keep in mind though is that the ITS-G5/DSRC has been designed for th= e needs of so called =E2=80=98day one=E2=80=99 applications (e.g. intersect= ion collision avoidance, lane change warning etc..) and it is quite clear t= hat the technology is not adapted to other applications, which would requir= e more capacity (say it is not the fault of the technology, as it has been = designed for something and not for something else).

=C2=A0

The applications you are working on fall within the =E2= =80=98Day two=E2=80=99 or =E2=80=98Day two and half=E2=80=99=C2=A0 (sorry, = I am not the one giving these names=E2=80=A6just referring to them..) and f= or these new applications there is absolutely a need for more capacity. In = short, we need to find better and more efficient ways to transmit much more= data for ITS applications, and indeed not say that people should transmit = less J

= =C2=A0

And= this is very clear in ETSI, C2C-CC, SAE, even 5GAA=E2=80=A6there are speci= fic WG discussing new spectrum usage (10Mhz vs. 20Mhz, multi-channels, etc.= .) and the current direction to fulfill the capacity requirements of these = news applications are either IEEE 802.11bd (the next generation wifi-based = V2X) or 5G-V2X (the next generation C-V2X technology), as frequency rechann= elization is complex in terms of coexistence and using multi-channels requi= re multi transmitters=E2=80=A6

=C2=A0

In= this perspective, your proposed modification might be seen as a temporary = patch but if it works for your case, that is good, as there is nothing else= available at that time=E2=80=A6And if you propose a simpler way of getting= more capacity to match day two applications with day one technology, well = this is what I would call research J=E2=80=A6

=C2=A0<= /p>

The point in my previous e-mail was that = putting 20MHz in =E2=80=98iw=E2=80=99 on an ocb firmware will change a few = things at the physical layers that will affect the performance (in good or = bad) of your system..for instance, the OFDM guard period will be halved, wh= ich will make your link more sensitive to delay long spreads, or will lose = 3dB in receiver sensitivity, which would impact your Tx range. As I said in= my previous e-mails, there are various teams that have been questioning th= e 10Mhz channel since a =E2=80=98very=E2=80=99 long time now=E2=80=A6so, th= ere is no scientific reasons for not trying at 20Mhz and see how it goes=E2= =80=A6yet, it will not be compatible with the current standards/regulations= at that time=E2=80=A6(but does not mean it would not change in the future = J)

=C2=A0

Please ha= ve a look at some of the work from Prof. Eric Str=C3=B6m of Chalmers (a nic= e summary is available here: https://pdfs= .semanticscholar.org/78ef/e53d238ae75837f5817997f27c74f1519698.pdf).=C2= =A0 In short, there are clearly performance gains in perspective=E2=80=A6bu= t it =E2=80=98really=E2=80=99 depends on some parameters of the channel tha= t you will face during your tests. The most important one is the delay spre= ad. Eric mentions that a 4nSec is usually agreed, but there are other studi= es indicating delay spreads up to 8nsec (also acknowledged by Eric)=E2=80= =A6so, it would simply be interesting to test and see how it works in your = case=E2=80=A6it would be good if you could have in your team or project par= tners expect in PHY/Channel sounding to double check the PHY impact of your= strategy in your environment=E2=80=A6

=C2=A0

<= span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73= ,125)">To conclude, although not fitting to current spectrum regulations, t= rying 20Mhz is good as it gets and there are many people believing that thi= s could actually help=E2=80=A6but it might not be sufficient for your appli= cations (you might not double capacity by doubling the bandwidth)=E2=80=A6T= here will be much more benefits from the next generation V2X technologies i= n the very near future (also indicated by Eric in its slides, page 24) , wh= ich will fulfill your required performance=E2=80=A6that is why I mentioned = that for your required applications, you should follow what IEEE 802.11bd o= r 5G-V2X will are actively being developed as we speak.

=C2=A0

Best Regards,

=C2=A0

J=C3=A9r=C3=B4me =C2=A0

= =C2=A0

From: its [= mailto:its-bounce= s@ietf.org] On Behalf Of Alexandre Petrescu
Sent: Wedn= esday 12 June 2019 20:05
To: its@ietf.org
Subject: [ipwave] Higher bandwidth= is a requirement, not a number to avoid

=C2=A0

Hi,

= With res= pect to the channel width 20MHz capability, which would probably offer high= er bandwidth and less latency.

I received in private sev= eral replies from at least 4 people.=C2=A0 I also had a face to face meetin= g with our partners.

I want to say something so I am bet= ter understood: it is a _requirement_ to get higher bandwidth; it is not a = number to avoid.

If the app people send 10000 RTMAPS 148= 0byte sized IP messages per second then it is so because they need it.=C2= =A0 Yes, that is 10KHz messages, and not 20Hz; yes, that is 1428byte IP mes= sage and not CAM/BSM 633byte.=C2=A0 And yes, that must be satisfied.=C2=A0 = We should not tell these people to reduce their outputs.=C2=A0 Reducing the= ir outputs will indeed guarantee better latency for ping, but they will be = less able to transmit valuable data.

We should not tell = app people to throttle (reduce) their output down to 20 messages per second= (20Hz).=C2=A0 That is nonsense out of standard documents.=C2=A0 The 20Hz/1= 0Hz/1Hz is data relevant out of GPS chipsets - GPS has nothing to do with O= CB.

If in the first platooning tests it worked with les= s data transmitted, also the convoy was less performing.=C2=A0 We need rich= data transmitted, not poor data.=C2=A0 We need lidar data out of the lidar= directly on OCB, and similar other things.

Alex<= u>

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


--
John Kenney
Director and Sr. Principal Researcher
Toyota InfoTech Labs
465 Bernardo Avenue
Mountain View, CA 94043
Tel: 650-694-4160. Mobile: 650-224-6644
<= /div>
--000000000000792ba3058b51cd36-- From nobody Sun Jun 16 01:52:37 2019 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 339CF120151; Sun, 16 Jun 2019 01:52:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Roni Even via Datatracker To: Cc: ietf@ietf.org, its@ietf.org, draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roni Even Message-ID: <156067514313.12185.6559961431451739070@ietfa.amsl.com> Date: Sun, 16 Jun 2019 01:52:23 -0700 Archived-At: Subject: [ipwave] Genart last call review of draft-ietf-ipwave-ipv6-over-80211ocb-46 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 List-Id: 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, 16 Jun 2019 08:52:24 -0000 Reviewer: Roni Even Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-ipwave-ipv6-over-80211ocb-?? Reviewer: Roni Even Review Date: 2019-06-16 IETF LC End Date: 2019-06-26 IESG Telechat date: Not scheduled for a telechat Summary: The document is almost ready for publication as a standard track RFC Major issues: Minor issues: 1. Section 4.2 says "IP packets MUST be transmitted over 802.11-OCB media as QoS Data" while appendix F say "The STA may send data frames of subtype Data, Null, QoS Data, and QoS Null.". 2. In section 5.2 "The policy dictating when the MAC address is changed on the 802.11-OCB interface is to-be-determined.". Reading the next sentence it looks to me that this is needed as part of the solution and should not be left for the unknown future. 3. In Appendix I 4th paragraph " However, this does not apply if TBD TBD TBD. " . What are the TBDs? Nits/editorial comments: 1. In appendix I last paragraph "Support of RFC 8505 is may be implemented on OCB." should be "Support of RFC 8505 may be implemented on OCB." 2. In Appendix I "OCB nodes that support RFC 8505 would support the 6LN operation in order to act as a host". I think that instead of "would" it should be "should" also if this is a recommendation why not have this paragraph not in an appendix with "MAY" and "SHOULD" From nobody Mon Jun 17 02:48:54 2019 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 650C312011C for ; Mon, 17 Jun 2019 02:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=est-umi-ac-ma.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 REywCjLIZYSq for ; Mon, 17 Jun 2019 02:48:35 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 0D13A120119 for ; Mon, 17 Jun 2019 02:48:33 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id u13so19873032iop.0 for ; Mon, 17 Jun 2019 02:48:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=est-umi-ac-ma.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=r/mzHri5/q63Uw4ecIynjWc8SvxpQu9zfLuD3asAvek=; b=fZij5y+4B3puiQt3QrtSKkCHBv1+eUaPF5AGXaeA4zQMhjmd8zaEvvF7w9GCEIQEvJ BQPvF8hYIlW41baMM0xcNcX/Q3mtYYvL9vTrxWre0Zg36WtlmKY2tWANF3XWSUJT5YRi iPMpVayKxBynOhApJpQ8enSXpvz/hRqgamtFiggVqCVmYYrlUMzz7wmKGNZ7FaIaUFEd rNj1uHyN+2GmvrhZKfyJT0c/BqOOM0DPnrtuV77syzKUvDbwdCGnmSjh1SqwbrKHdHaq 2qtkw62xiABjZT0oQ1jyFBftw+t43FSMd2d5n8kXEHcgi5ulKfLeqSt+D9pzGzJnoIKt og6w== 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=r/mzHri5/q63Uw4ecIynjWc8SvxpQu9zfLuD3asAvek=; b=TxNICj33JGfp8vVBwwB23zb6kAJvcJH2K2Bc3CfmB+ogyD2sZf/GHDQqGeCP9PbROc ozXQk5S+pO9Si1Ge8nXeNB7gK7E8DaSN5b62jGM9ajg8AKsT0+vBEM4xyv9ViJ2lGP9E xhALoUwzr4PHbvO7TaSzPtzjlvN/PYvFFyUeQo6z9Nr+DAqmAdFReO/X6YhjYEa6nTJV iaCxZhs7awfASCNiLFAbPLAht0S38S1m+NQ6VKwUsXrlO3AlUSKUysqTfzMOb28z8B77 kdtc3vqAU2ICfiX1/LBOOcfMX06GJWbPYYfLPPrh4eGG/3Gg6NQdL6NfxbZr2X7aeijv 9ijw== X-Gm-Message-State: APjAAAVWFiVSU9lY7pNQ+3PPBBBP7o/ubKM6b4rQaGEHbMftgokP+lXK K0BHm8fS7U/NzA5LWHLRh89dzLbIZi7uhFWMY3dfXw== X-Google-Smtp-Source: APXvYqwxdaILctqwKgZI0fLe/PJbdzX8Bi5hE5E6rwe2WulGtwZrqQy9ZY7Jy6X6hImVr4NBJAkYWdaQ+f4GCG8eEmo= X-Received: by 2002:a5d:8252:: with SMTP id n18mr1744ioo.230.1560764912225; Mon, 17 Jun 2019 02:48:32 -0700 (PDT) MIME-Version: 1.0 References: <156067514313.12185.6559961431451739070@ietfa.amsl.com> In-Reply-To: <156067514313.12185.6559961431451739070@ietfa.amsl.com> From: NABIL BENAMAR Date: Mon, 17 Jun 2019 10:48:21 +0100 Message-ID: To: Roni Even Cc: gen-art@ietf.org, IETF Discussion , its@ietf.org, draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org Content-Type: multipart/alternative; boundary="0000000000002bf215058b81e688" Archived-At: Subject: Re: [ipwave] Genart last call review of draft-ietf-ipwave-ipv6-over-80211ocb-46 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: 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, 17 Jun 2019 09:48:37 -0000 --0000000000002bf215058b81e688 Content-Type: text/plain; charset="UTF-8" Dear Roni, Thank you for your review. Please, see my answers below. On Sun, Jun 16, 2019, 09:52 Roni Even via Datatracker wrote: > Reviewer: Roni Even > Review result: Almost Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-ipwave-ipv6-over-80211ocb-?? > Reviewer: Roni Even > Review Date: 2019-06-16 > IETF LC End Date: 2019-06-26 > IESG Telechat date: Not scheduled for a telechat > > Summary: > The document is almost ready for publication as a standard track RFC > > Major issues: > > Minor issues: > > 1. Section 4.2 says "IP packets MUST be transmitted over 802.11-OCB media > as > QoS Data" while appendix F say "The STA may send data frames of subtype > Data, > Null, QoS Data, and > QoS Null. > I will update the appendix to reflect the text in section 4.2. > > 2. In section 5.2 "The policy dictating when the MAC address is changed on > the > 802.11-OCB interface is to-be-determined.". Reading the next sentence it > looks > to me that this is needed as part of the solution and should not be left > for > the unknown future. > Should we reformulate here? > > 3. In Appendix I 4th paragraph " However, this does not apply if TBD TBD > TBD. " > . What are the TBDs? > The whole sentence will be removed. > > Nits/editorial comments: > 1. In appendix I last paragraph "Support of RFC 8505 is may be implemented > on > OCB." should be "Support of RFC 8505 may be implemented on OCB." 2. In > Appendix > I "OCB nodes that support RFC 8505 would support the 6LN operation in > order to > act as a host". I think that instead of "would" it should be "should" > also if > this is a recommendation why not have this paragraph not in an appendix > with > "MAY" and "SHOULD > Agreed. > > > --0000000000002bf215058b81e688 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Roni,

Thank you for your review.
Please, see my answer= s below.






On Sun, Jun 16, 2019, 09:5= 2 Roni Even via Datatracker <noreply= @ietf.org> wrote:
Reviewer= : Roni Even
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.=C2=A0 Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenA= rtfaq>.

Document: draft-ietf-ipwave-ipv6-over-80211ocb-??
Reviewer: Roni Even
Review Date: 2019-06-16
IETF LC End Date: 2019-06-26
IESG Telechat date: Not scheduled for a telechat

Summary:
The document is almost ready for publication as a standard track RFC

Major issues:

Minor issues:

1. Section 4.2=C2=A0 says "IP packets MUST be transmitted over 802.11-= OCB media as
QoS Data" while appendix F say "The STA may send data frames of s= ubtype Data,
Null, QoS Data, and
=C2=A0 =C2=A0 =C2=A0 QoS Null.

I will update the appendix to reflect the tex= t in section 4.2.

2. In section 5.2 "The policy dictating when the MAC address is change= d on the
802.11-OCB interface is to-be-determined.". Reading the next sentence = it looks
to me that this is needed as part of the solution and should not be left fo= r
the unknown future.

Should we reformulate here?

3. In Appendix I 4th paragraph " However, this does not apply if TBD T= BD TBD. "
. What are the TBDs?

The whole sentence will be removed.

Nits/editorial comments:
1. In appendix I last paragraph "Support of RFC 8505 is may be impleme= nted on
OCB." should be "Support of RFC 8505 may be implemented on OCB.&q= uot; 2. In Appendix
I "OCB nodes that support RFC 8505 would support the 6LN operation in = order to
act as a host".=C2=A0 I think that instead of "would" it sho= uld be "should"=C2=A0 also if
this is a recommendation why not have this paragraph not in an appendix wit= h
"MAY" and "SHOULD


Agreed.


--0000000000002bf215058b81e688-- From nobody Mon Jun 17 06:26:05 2019 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5867A120139; Mon, 17 Jun 2019 06:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vR308f14Iux; Mon, 17 Jun 2019 06:26:00 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60AC91200B2; Mon, 17 Jun 2019 06:26:00 -0700 (PDT) Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 4A2DBC9A9261EB9507FC; Mon, 17 Jun 2019 14:25:57 +0100 (IST) Received: from lhreml706-chm.china.huawei.com (10.201.108.55) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 17 Jun 2019 14:25:53 +0100 Received: from lhreml706-chm.china.huawei.com (10.201.108.55) by lhreml706-chm.china.huawei.com (10.201.108.55) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Mon, 17 Jun 2019 14:25:53 +0100 Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by lhreml706-chm.china.huawei.com (10.201.108.55) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Mon, 17 Jun 2019 14:25:52 +0100 Received: from DGGEMM526-MBX.china.huawei.com ([169.254.8.116]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0439.000; Mon, 17 Jun 2019 21:25:50 +0800 From: "Roni Even (A)" To: NABIL BENAMAR , Roni Even CC: "gen-art@ietf.org" , IETF Discussion , "its@ietf.org" , "draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org" Thread-Topic: [Gen-art] Genart last call review of draft-ietf-ipwave-ipv6-over-80211ocb-46 Thread-Index: AQHVJPHkCSGcS63Kz0uKZOTqzhsmtaafz9OQ Date: Mon, 17 Jun 2019 13:25:49 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD18D37579@dggemm526-mbx.china.huawei.com> References: <156067514313.12185.6559961431451739070@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.60] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD18D37579dggemm526mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [ipwave] [Gen-art] Genart last call review of draft-ietf-ipwave-ipv6-over-80211ocb-46 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: 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, 17 Jun 2019 13:26:04 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD18D37579dggemm526mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzLA0KVGhlIG9ubHkgY29tbWVudCBsZWZ0IGlzOg0KDQoyLiBJbiBzZWN0aW9uIDUuMiAi VGhlIHBvbGljeSBkaWN0YXRpbmcgd2hlbiB0aGUgTUFDIGFkZHJlc3MgaXMgY2hhbmdlZCBvbiB0 aGUNCjgwMi4xMS1PQ0IgaW50ZXJmYWNlIGlzIHRvLWJlLWRldGVybWluZWQuIi4gUmVhZGluZyB0 aGUgbmV4dCBzZW50ZW5jZSBpdCBsb29rcw0KdG8gbWUgdGhhdCB0aGlzIGlzIG5lZWRlZCBhcyBw YXJ0IG9mIHRoZSBzb2x1dGlvbiBhbmQgc2hvdWxkIG5vdCBiZSBsZWZ0IGZvcg0KdGhlIHVua25v d24gZnV0dXJlLg0KDQpTaG91bGQgd2UgcmVmb3JtdWxhdGUgaGVyZT8NCg0KSSB3YXMgZXhwZWN0 aW5nIHNvbWUgcmVjb21tZW5kYXRpb24gc2luY2UgdGhlIGNoYW5naW5nIG9mIE1BQyBhZGRyZXNz IGlzIGltcG9ydGFudCB0byBhZGRyZXNzIHByaXZhY3kgaXNzdWVzIChkaXNjdXNzZWQgaW4gc2Vj dGlvbiA1KS4gQ3VycmVudGx5IGl0IGlzIGxlZnQgb3BlbiB3aXRoIG5vIHJlY29tbWVuZGF0aW9u ICwgb25seSBzYXlpbmcgdGhhdCBkeW5hbWljIGNoYW5nZSBvZiBNQUMgYWRkcmVzcyBpcyBuZWVk ZWQuDQpNYXliZSB0aGUgZG9jdW1lbnQgc2hvdWxkIGhhdmUgc29tZSBub3JtYXRpdmUgbGFuZ3Vh Z2UgZm9yIGV4YW1wbGUgaW4gc2VjdGlvbiA1LjEgdGhhdCB3aWxsIHNheSB0aGF0IElQLU9CVSBN VVNUIGR5bmFtaWMgY2hhbmdlIHRoZWlyIE1BQyBhZGRyZXNzZXMNCg0KRGlkIHRoZSBkb2N1bWVu dCBnbyB0aHJvdWdoIHNlY3VyaXR5IGFyZWEgcmV2aWV3Pw0KDQpSb25pDQoNCg0KRnJvbTogR2Vu LWFydCBbbWFpbHRvOmdlbi1hcnQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE5BQklM IEJFTkFNQVINClNlbnQ6IE1vbmRheSwgSnVuZSAxNywgMjAxOSAxMjo0OCBQTQ0KVG86IFJvbmkg RXZlbg0KQ2M6IGdlbi1hcnRAaWV0Zi5vcmc7IElFVEYgRGlzY3Vzc2lvbjsgaXRzQGlldGYub3Jn OyBkcmFmdC1pZXRmLWlwd2F2ZS1pcHY2LW92ZXItODAyMTFvY2IuYWxsQGlldGYub3JnDQpTdWJq ZWN0OiBSZTogW0dlbi1hcnRdIEdlbmFydCBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYt aXB3YXZlLWlwdjYtb3Zlci04MDIxMW9jYi00Ng0KDQpEZWFyIFJvbmksDQoNClRoYW5rIHlvdSBm b3IgeW91ciByZXZpZXcuDQpQbGVhc2UsIHNlZSBteSBhbnN3ZXJzIGJlbG93Lg0KDQoNCg0KDQoN Ck9uIFN1biwgSnVuIDE2LCAyMDE5LCAwOTo1MiBSb25pIEV2ZW4gdmlhIERhdGF0cmFja2VyIDxu b3JlcGx5QGlldGYub3JnPG1haWx0bzpub3JlcGx5QGlldGYub3JnPj4gd3JvdGU6DQpSZXZpZXdl cjogUm9uaSBFdmVuDQpSZXZpZXcgcmVzdWx0OiBBbG1vc3QgUmVhZHkNCg0KSSBhbSB0aGUgYXNz aWduZWQgR2VuLUFSVCByZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4gVGhlIEdlbmVyYWwgQXJlYQ0K UmV2aWV3IFRlYW0gKEdlbi1BUlQpIHJldmlld3MgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHBy b2Nlc3NlZA0KYnkgdGhlIElFU0cgZm9yIHRoZSBJRVRGIENoYWlyLiAgUGxlYXNlIHRyZWF0IHRo ZXNlIGNvbW1lbnRzIGp1c3QNCmxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy4NCg0K Rm9yIG1vcmUgaW5mb3JtYXRpb24sIHBsZWFzZSBzZWUgdGhlIEZBUSBhdA0KDQo8aHR0cHM6Ly90 cmFjLmlldGYub3JnL3RyYWMvZ2VuL3dpa2kvR2VuQXJ0ZmFxPi4NCg0KRG9jdW1lbnQ6IGRyYWZ0 LWlldGYtaXB3YXZlLWlwdjYtb3Zlci04MDIxMW9jYi0/Pw0KUmV2aWV3ZXI6IFJvbmkgRXZlbg0K UmV2aWV3IERhdGU6IDIwMTktMDYtMTYNCklFVEYgTEMgRW5kIERhdGU6IDIwMTktMDYtMjYNCklF U0cgVGVsZWNoYXQgZGF0ZTogTm90IHNjaGVkdWxlZCBmb3IgYSB0ZWxlY2hhdA0KDQpTdW1tYXJ5 Og0KVGhlIGRvY3VtZW50IGlzIGFsbW9zdCByZWFkeSBmb3IgcHVibGljYXRpb24gYXMgYSBzdGFu ZGFyZCB0cmFjayBSRkMNCg0KTWFqb3IgaXNzdWVzOg0KDQpNaW5vciBpc3N1ZXM6DQoNCjEuIFNl Y3Rpb24gNC4yICBzYXlzICJJUCBwYWNrZXRzIE1VU1QgYmUgdHJhbnNtaXR0ZWQgb3ZlciA4MDIu MTEtT0NCIG1lZGlhIGFzDQpRb1MgRGF0YSIgd2hpbGUgYXBwZW5kaXggRiBzYXkgIlRoZSBTVEEg bWF5IHNlbmQgZGF0YSBmcmFtZXMgb2Ygc3VidHlwZSBEYXRhLA0KTnVsbCwgUW9TIERhdGEsIGFu ZA0KICAgICAgUW9TIE51bGwuDQoNCkkgd2lsbCB1cGRhdGUgdGhlIGFwcGVuZGl4IHRvIHJlZmxl Y3QgdGhlIHRleHQgaW4gc2VjdGlvbiA0LjIuDQoNCjIuIEluIHNlY3Rpb24gNS4yICJUaGUgcG9s aWN5IGRpY3RhdGluZyB3aGVuIHRoZSBNQUMgYWRkcmVzcyBpcyBjaGFuZ2VkIG9uIHRoZQ0KODAy LjExLU9DQiBpbnRlcmZhY2UgaXMgdG8tYmUtZGV0ZXJtaW5lZC4iLiBSZWFkaW5nIHRoZSBuZXh0 IHNlbnRlbmNlIGl0IGxvb2tzDQp0byBtZSB0aGF0IHRoaXMgaXMgbmVlZGVkIGFzIHBhcnQgb2Yg dGhlIHNvbHV0aW9uIGFuZCBzaG91bGQgbm90IGJlIGxlZnQgZm9yDQp0aGUgdW5rbm93biBmdXR1 cmUuDQoNClNob3VsZCB3ZSByZWZvcm11bGF0ZSBoZXJlPw0KDQozLiBJbiBBcHBlbmRpeCBJIDR0 aCBwYXJhZ3JhcGggIiBIb3dldmVyLCB0aGlzIGRvZXMgbm90IGFwcGx5IGlmIFRCRCBUQkQgVEJE LiAiDQouLiBXaGF0IGFyZSB0aGUgVEJEcz8NCg0KVGhlIHdob2xlIHNlbnRlbmNlIHdpbGwgYmUg cmVtb3ZlZC4NCg0KTml0cy9lZGl0b3JpYWwgY29tbWVudHM6DQoxLiBJbiBhcHBlbmRpeCBJIGxh c3QgcGFyYWdyYXBoICJTdXBwb3J0IG9mIFJGQyA4NTA1IGlzIG1heSBiZSBpbXBsZW1lbnRlZCBv bg0KT0NCLiIgc2hvdWxkIGJlICJTdXBwb3J0IG9mIFJGQyA4NTA1IG1heSBiZSBpbXBsZW1lbnRl ZCBvbiBPQ0IuIiAyLiBJbiBBcHBlbmRpeA0KSSAiT0NCIG5vZGVzIHRoYXQgc3VwcG9ydCBSRkMg ODUwNSB3b3VsZCBzdXBwb3J0IHRoZSA2TE4gb3BlcmF0aW9uIGluIG9yZGVyIHRvDQphY3QgYXMg YSBob3N0Ii4gIEkgdGhpbmsgdGhhdCBpbnN0ZWFkIG9mICJ3b3VsZCIgaXQgc2hvdWxkIGJlICJz aG91bGQiICBhbHNvIGlmDQp0aGlzIGlzIGEgcmVjb21tZW5kYXRpb24gd2h5IG5vdCBoYXZlIHRo aXMgcGFyYWdyYXBoIG5vdCBpbiBhbiBhcHBlbmRpeCB3aXRoDQoiTUFZIiBhbmQgIlNIT1VMRA0K DQoNCkFncmVlZC4NCg0K --_000_6E58094ECC8D8344914996DAD28F1CCD18D37579dggemm526mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIG9ubHkgY29tbWVu dCBsZWZ0IGlzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi cj4NCjIuIEluIHNlY3Rpb24gNS4yICZxdW90O1RoZSBwb2xpY3kgZGljdGF0aW5nIHdoZW4gdGhl IE1BQyBhZGRyZXNzIGlzIGNoYW5nZWQgb24gdGhlPGJyPg0KODAyLjExLU9DQiBpbnRlcmZhY2Ug aXMgdG8tYmUtZGV0ZXJtaW5lZC4mcXVvdDsuIFJlYWRpbmcgdGhlIG5leHQgc2VudGVuY2UgaXQg bG9va3M8YnI+DQp0byBtZSB0aGF0IHRoaXMgaXMgbmVlZGVkIGFzIHBhcnQgb2YgdGhlIHNvbHV0 aW9uIGFuZCBzaG91bGQgbm90IGJlIGxlZnQgZm9yPGJyPg0KdGhlIHVua25vd24gZnV0dXJlLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TaG91bGQgd2UgcmVmb3JtdWxhdGUgaGVyZT88bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SSB3YXMgZXhwZWN0aW5nIHNvbWUgcmVjb21tZW5kYXRpb24gc2lu Y2UgdGhlIGNoYW5naW5nIG9mIE1BQyBhZGRyZXNzIGlzIGltcG9ydGFudCB0byBhZGRyZXNzIHBy aXZhY3kgaXNzdWVzIChkaXNjdXNzZWQgaW4gc2VjdGlvbiA1KS4gQ3VycmVudGx5IGl0IGlzIGxl ZnQgb3BlbiB3aXRoIG5vIHJlY29tbWVuZGF0aW9uICwgb25seSBzYXlpbmcgdGhhdCBkeW5hbWlj IGNoYW5nZSBvZiBNQUMgYWRkcmVzcyBpcw0KIG5lZWRlZC4gPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5NYXliZSB0aGUgZG9jdW1lbnQgc2hvdWxkIGhhdmUgc29tZSBub3Jt YXRpdmUgbGFuZ3VhZ2UgZm9yIGV4YW1wbGUgaW4gc2VjdGlvbiA1LjEgdGhhdCB3aWxsIHNheSB0 aGF0IElQLU9CVSBNVVNUIGR5bmFtaWMgY2hhbmdlIHRoZWlyIE1BQyBhZGRyZXNzZXMgJm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRpZCB0aGUgZG9jdW1lbnQgZ28gdGhyb3VnaCBzZWN1 cml0eSBhcmVhIHJldmlldz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Um9uaTxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBH ZW4tYXJ0IFttYWlsdG86Z2VuLWFydC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9m IDwvYj5OQUJJTCBCRU5BTUFSPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgSnVuZSAxNywgMjAx OSAxMjo0OCBQTTxicj4NCjxiPlRvOjwvYj4gUm9uaSBFdmVuPGJyPg0KPGI+Q2M6PC9iPiBnZW4t YXJ0QGlldGYub3JnOyBJRVRGIERpc2N1c3Npb247IGl0c0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1p cHdhdmUtaXB2Ni1vdmVyLTgwMjExb2NiLmFsbEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW0dlbi1hcnRdIEdlbmFydCBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtaXB3 YXZlLWlwdjYtb3Zlci04MDIxMW9jYi00NjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5EZWFyIFJvbmksPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaGFuayB5b3UgZm9yIHlvdXIgcmV2aWV3LjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGxlYXNlLCBzZWUgbXkgYW5zd2Vy cyBiZWxvdy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBTdW4sIEp1biAxNiwgMjAxOSwg MDk6NTIgUm9uaSBFdmVuIHZpYSBEYXRhdHJhY2tlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5vcmVw bHlAaWV0Zi5vcmciPm5vcmVwbHlAaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJldmlld2VyOiBS b25pIEV2ZW48YnI+DQpSZXZpZXcgcmVzdWx0OiBBbG1vc3QgUmVhZHk8YnI+DQo8YnI+DQpJIGFt IHRoZSBhc3NpZ25lZCBHZW4tQVJUIHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgR2VuZXJh bCBBcmVhPGJyPg0KUmV2aWV3IFRlYW0gKEdlbi1BUlQpIHJldmlld3MgYWxsIElFVEYgZG9jdW1l bnRzIGJlaW5nIHByb2Nlc3NlZDxicj4NCmJ5IHRoZSBJRVNHIGZvciB0aGUgSUVURiBDaGFpci4m bmJzcDsgUGxlYXNlIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3Q8YnI+DQpsaWtlIGFueSBvdGhl ciBsYXN0IGNhbGwgY29tbWVudHMuPGJyPg0KPGJyPg0KRm9yIG1vcmUgaW5mb3JtYXRpb24sIHBs ZWFzZSBzZWUgdGhlIEZBUSBhdDxicj4NCjxicj4NCiZsdDs8YSBocmVmPSJodHRwczovL3RyYWMu aWV0Zi5vcmcvdHJhYy9nZW4vd2lraS9HZW5BcnRmYXEiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3RyYWMuaWV0Zi5vcmcvdHJhYy9nZW4vd2lraS9HZW5BcnRmYXE8L2E+Jmd0Oy48YnI+DQo8YnI+ DQpEb2N1bWVudDogZHJhZnQtaWV0Zi1pcHdhdmUtaXB2Ni1vdmVyLTgwMjExb2NiLT8/PGJyPg0K UmV2aWV3ZXI6IFJvbmkgRXZlbjxicj4NClJldmlldyBEYXRlOiAyMDE5LTA2LTE2PGJyPg0KSUVU RiBMQyBFbmQgRGF0ZTogMjAxOS0wNi0yNjxicj4NCklFU0cgVGVsZWNoYXQgZGF0ZTogTm90IHNj aGVkdWxlZCBmb3IgYSB0ZWxlY2hhdDxicj4NCjxicj4NClN1bW1hcnk6PGJyPg0KVGhlIGRvY3Vt ZW50IGlzIGFsbW9zdCByZWFkeSBmb3IgcHVibGljYXRpb24gYXMgYSBzdGFuZGFyZCB0cmFjayBS RkM8YnI+DQo8YnI+DQpNYWpvciBpc3N1ZXM6PGJyPg0KPGJyPg0KTWlub3IgaXNzdWVzOjxicj4N Cjxicj4NCjEuIFNlY3Rpb24gNC4yJm5ic3A7IHNheXMgJnF1b3Q7SVAgcGFja2V0cyBNVVNUIGJl IHRyYW5zbWl0dGVkIG92ZXIgODAyLjExLU9DQiBtZWRpYSBhczxicj4NClFvUyBEYXRhJnF1b3Q7 IHdoaWxlIGFwcGVuZGl4IEYgc2F5ICZxdW90O1RoZSBTVEEgbWF5IHNlbmQgZGF0YSBmcmFtZXMg b2Ygc3VidHlwZSBEYXRhLDxicj4NCk51bGwsIFFvUyBEYXRhLCBhbmQ8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyBRb1MgTnVsbC48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdpbGwgdXBkYXRlIHRo ZSBhcHBlbmRpeCB0byByZWZsZWN0IHRoZSB0ZXh0IGluIHNlY3Rpb24gNC4yLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YnI+DQoyLiBJbiBzZWN0aW9uIDUuMiAmcXVvdDtUaGUgcG9saWN5IGRpY3RhdGluZyB3 aGVuIHRoZSBNQUMgYWRkcmVzcyBpcyBjaGFuZ2VkIG9uIHRoZTxicj4NCjgwMi4xMS1PQ0IgaW50 ZXJmYWNlIGlzIHRvLWJlLWRldGVybWluZWQuJnF1b3Q7LiBSZWFkaW5nIHRoZSBuZXh0IHNlbnRl bmNlIGl0IGxvb2tzPGJyPg0KdG8gbWUgdGhhdCB0aGlzIGlzIG5lZWRlZCBhcyBwYXJ0IG9mIHRo ZSBzb2x1dGlvbiBhbmQgc2hvdWxkIG5vdCBiZSBsZWZ0IGZvcjxicj4NCnRoZSB1bmtub3duIGZ1 dHVyZS48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TaG91bGQgd2UgcmVmb3JtdWxhdGUgaGVyZT88bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGJyPg0KMy4gSW4gQXBwZW5kaXggSSA0dGggcGFyYWdyYXBoICZxdW90OyBI b3dldmVyLCB0aGlzIGRvZXMgbm90IGFwcGx5IGlmIFRCRCBUQkQgVEJELiAmcXVvdDs8YnI+DQou LiBXaGF0IGFyZSB0aGUgVEJEcz88bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgd2hvbGUgc2VudGVu Y2Ugd2lsbCBiZSByZW1vdmVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpOaXRzL2VkaXRvcmlhbCBj b21tZW50czo8YnI+DQoxLiBJbiBhcHBlbmRpeCBJIGxhc3QgcGFyYWdyYXBoICZxdW90O1N1cHBv cnQgb2YgUkZDIDg1MDUgaXMgbWF5IGJlIGltcGxlbWVudGVkIG9uPGJyPg0KT0NCLiZxdW90OyBz aG91bGQgYmUgJnF1b3Q7U3VwcG9ydCBvZiBSRkMgODUwNSBtYXkgYmUgaW1wbGVtZW50ZWQgb24g T0NCLiZxdW90OyAyLiBJbiBBcHBlbmRpeDxicj4NCkkgJnF1b3Q7T0NCIG5vZGVzIHRoYXQgc3Vw cG9ydCBSRkMgODUwNSB3b3VsZCBzdXBwb3J0IHRoZSA2TE4gb3BlcmF0aW9uIGluIG9yZGVyIHRv PGJyPg0KYWN0IGFzIGEgaG9zdCZxdW90Oy4mbmJzcDsgSSB0aGluayB0aGF0IGluc3RlYWQgb2Yg JnF1b3Q7d291bGQmcXVvdDsgaXQgc2hvdWxkIGJlICZxdW90O3Nob3VsZCZxdW90OyZuYnNwOyBh bHNvIGlmPGJyPg0KdGhpcyBpcyBhIHJlY29tbWVuZGF0aW9uIHdoeSBub3QgaGF2ZSB0aGlzIHBh cmFncmFwaCBub3QgaW4gYW4gYXBwZW5kaXggd2l0aDxicj4NCiZxdW90O01BWSZxdW90OyBhbmQg JnF1b3Q7U0hPVUxEPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BZ3JlZWQuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_6E58094ECC8D8344914996DAD28F1CCD18D37579dggemm526mbxchi_-- From nobody Mon Jun 17 07:12:02 2019 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C936120127 for ; Mon, 17 Jun 2019 07:12:00 -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_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUGvCBenz8Oe for ; Mon, 17 Jun 2019 07:11:57 -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 5CDEF12011C for ; Mon, 17 Jun 2019 07:11:57 -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 x5HEBsra125166 for ; Mon, 17 Jun 2019 16:11:54 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id CB80E207AB0 for ; Mon, 17 Jun 2019 16:11:54 +0200 (CEST) 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 C1F3A207AAE for ; Mon, 17 Jun 2019 16:11:54 +0200 (CEST) Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x5HEBsXB008168 for ; Mon, 17 Jun 2019 16:11:54 +0200 To: its@ietf.org References: <156067514313.12185.6559961431451739070@ietfa.amsl.com> <6E58094ECC8D8344914996DAD28F1CCD18D37579@dggemm526-mbx.china.huawei.com> From: Alexandre Petrescu Message-ID: <8cd9eb28-35a6-600f-c3d7-4e61972bacde@gmail.com> Date: Mon, 17 Jun 2019 16:11:54 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD18D37579@dggemm526-mbx.china.huawei.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] [Gen-art] Genart last call review of draft-ietf-ipwave-ipv6-over-80211ocb-46 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: 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, 17 Jun 2019 14:12:00 -0000 I would like to ask for comparison to implementation too. I dont want my implementation to become non-standard because it does not change its MAC address all the time. Le 17/06/2019 à 15:25, Roni Even (A) a écrit : > Thanks, > > The only comment left is: > > > 2. In section 5.2 "The policy dictating when the MAC address is changed > on the > 802.11-OCB interface is to-be-determined.". Reading the next sentence it > looks > to me that this is needed as part of the solution and should not be left for > the unknown future. > > Should we reformulate here? > > I was expecting some recommendation since the changing of MAC address is > important to address privacy issues (discussed in section 5). Currently > it is left open with no recommendation , only saying that dynamic change > of MAC address is needed. > > Maybe the document should have some normative language for example in > section 5.1 that will say that IP-OBU MUST dynamic change their MAC > addresses > > Did the document go through security area review? > > Roni > > *From:*Gen-art [mailto:gen-art-bounces@ietf.org] *On Behalf Of *NABIL > BENAMAR > *Sent:* Monday, June 17, 2019 12:48 PM > *To:* Roni Even > *Cc:* gen-art@ietf.org; IETF Discussion; its@ietf.org; > draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org > *Subject:* Re: [Gen-art] Genart last call review of > draft-ietf-ipwave-ipv6-over-80211ocb-46 > > Dear Roni, > > Thank you for your review. > > Please, see my answers below. > > On Sun, Jun 16, 2019, 09:52 Roni Even via Datatracker > wrote: > > Reviewer: Roni Even > Review result: Almost Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair.  Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-ipwave-ipv6-over-80211ocb-?? > Reviewer: Roni Even > Review Date: 2019-06-16 > IETF LC End Date: 2019-06-26 > IESG Telechat date: Not scheduled for a telechat > > Summary: > The document is almost ready for publication as a standard track RFC > > Major issues: > > Minor issues: > > 1. Section 4.2  says "IP packets MUST be transmitted over 802.11-OCB > media as > QoS Data" while appendix F say "The STA may send data frames of > subtype Data, > Null, QoS Data, and >       QoS Null. > > I will update the appendix to reflect the text in section 4.2. > > > 2. In section 5.2 "The policy dictating when the MAC address is > changed on the > 802.11-OCB interface is to-be-determined.". Reading the next > sentence it looks > to me that this is needed as part of the solution and should not be > left for > the unknown future. > > Should we reformulate here? > > > 3. In Appendix I 4th paragraph " However, this does not apply if TBD > TBD TBD. " > .. What are the TBDs? > > The whole sentence will be removed. > > > Nits/editorial comments: > 1. In appendix I last paragraph "Support of RFC 8505 is may be > implemented on > OCB." should be "Support of RFC 8505 may be implemented on OCB." 2. > In Appendix > I "OCB nodes that support RFC 8505 would support the 6LN operation > in order to > act as a host".  I think that instead of "would" it should be > "should"  also if > this is a recommendation why not have this paragraph not in an > appendix with > "MAY" and "SHOULD > > Agreed. > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > From nobody Mon Jun 17 10:38:48 2019 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86A2A120461 for ; Mon, 17 Jun 2019 10:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=est-umi-ac-ma.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 qR0ABeIM9KtI for ; Mon, 17 Jun 2019 10:38:37 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 C20EF120465 for ; Mon, 17 Jun 2019 10:38:28 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id e5so23108266iok.4 for ; Mon, 17 Jun 2019 10:38:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=est-umi-ac-ma.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mPc53y9HaworHXEjgNi2yj6RS8viQ5bQDziTTV0zen0=; b=v5mBqyAGvS0W+0fdBBb1O3sjkpVUT2HFR8o98Uy9fzCefNbEHsUvuDR1iINsYlNvuc iFsw5ukLwptFDldLZkQVJrlLRipo7NbamUKMn5smuUtD/LSuJ+uWYpj+S+LIZgnaXppO MUpRFc3DoBLoZUMxwRPkW5QuNdqq0H976YnryaYlVDg0KTH0yDaADpla+YrmAok0nZr0 5xXiT55/hvFZGztQABG90qrwZLDe/nLoHvi6oU+S7fCsKmxVsQ1tJ6PjwnQ1JjFJX2pE UjHU90Nc3g7Eq9O/wGGrDVxVf4mr2C4JkC/ZGtbZFaDJy+exckEpCNG81Wl7dW8+qaVN gOfg== 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=mPc53y9HaworHXEjgNi2yj6RS8viQ5bQDziTTV0zen0=; b=gjEjBK+FjYDN8pejT0sUXQkvRfip6qqOmG5tXK128JVUMuUxT6WFFIQntmCnKuRGNA Q79RSM4j/oeIJQMG1CbBfSZfusIzdjDAu0bigzs4x7QdUhV4/B9Yu20if1sFv8l7gakR XpkZTPSZZheU3Kor32hwNrsXFwXLP73kV5SbS4x/6/1qvr8z9AIHNO/iu39G1Di9IZWD NCBzPUg29M4Pl2Y2awVaEd2gCKrsymEDTbv4TUTpTK5ZoK6DTcjVN50clH+Gn70kyrQF IxJYXM/2KqHlnkTvJjAFSowKCK530SKEvqp0C3m8v9AU+80ETshbG+x0uuqQMkmo0Wss vBgg== X-Gm-Message-State: APjAAAW5LwZP2XS2dPZFICe3MqOwglNbA6EVu8c0XOPORtlosTXiQ+qw Mx6B4PQxcvvz6A2hqdGO/VYalJ2CPaIObtsEm8RNLA== X-Google-Smtp-Source: APXvYqwznsfisFC1Eze3VcgmeHk+To7JvdzH80zesASuYDNrht8PdhZCVAQaUrO8fD1B6q2qoHO1MjXlW8GCiiD07QI= X-Received: by 2002:a02:a90a:: with SMTP id n10mr70777840jam.61.1560793077032; Mon, 17 Jun 2019 10:37:57 -0700 (PDT) MIME-Version: 1.0 References: <156067514313.12185.6559961431451739070@ietfa.amsl.com> <6E58094ECC8D8344914996DAD28F1CCD18D37579@dggemm526-mbx.china.huawei.com> In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD18D37579@dggemm526-mbx.china.huawei.com> From: NABIL BENAMAR Date: Mon, 17 Jun 2019 18:37:44 +0100 Message-ID: To: "Roni Even (A)" Cc: Roni Even , "gen-art@ietf.org" , IETF Discussion , "its@ietf.org" , "draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ffa612058b887415" Archived-At: Subject: Re: [ipwave] [Gen-art] Genart last call review of draft-ietf-ipwave-ipv6-over-80211ocb-46 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: 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, 17 Jun 2019 17:38:42 -0000 --000000000000ffa612058b887415 Content-Type: text/plain; charset="UTF-8" Hi Roni, I think we wrote this part some time ago...So what about the following: "an example of change policy is to change the MAC address of the OCB interface each time the system boots up" On Mon, Jun 17, 2019 at 2:25 PM Roni Even (A) wrote: > Thanks, > > The only comment left is: > > > 2. In section 5.2 "The policy dictating when the MAC address is changed on > the > 802.11-OCB interface is to-be-determined.". Reading the next sentence it > looks > to me that this is needed as part of the solution and should not be left > for > the unknown future. > > > > Should we reformulate here? > > > > I was expecting some recommendation since the changing of MAC address is > important to address privacy issues (discussed in section 5). Currently it > is left open with no recommendation , only saying that dynamic change of > MAC address is needed. > > Maybe the document should have some normative language for example in > section 5.1 that will say that IP-OBU MUST dynamic change their MAC > addresses > > > > Did the document go through security area review? > > > > Roni > > > > > > *From:* Gen-art [mailto:gen-art-bounces@ietf.org] *On Behalf Of *NABIL > BENAMAR > *Sent:* Monday, June 17, 2019 12:48 PM > *To:* Roni Even > *Cc:* gen-art@ietf.org; IETF Discussion; its@ietf.org; > draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org > *Subject:* Re: [Gen-art] Genart last call review of > draft-ietf-ipwave-ipv6-over-80211ocb-46 > > > > Dear Roni, > > > > Thank you for your review. > > Please, see my answers below. > > > > > > > > > > > > On Sun, Jun 16, 2019, 09:52 Roni Even via Datatracker > wrote: > > Reviewer: Roni Even > Review result: Almost Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-ipwave-ipv6-over-80211ocb-?? > Reviewer: Roni Even > Review Date: 2019-06-16 > IETF LC End Date: 2019-06-26 > IESG Telechat date: Not scheduled for a telechat > > Summary: > The document is almost ready for publication as a standard track RFC > > Major issues: > > Minor issues: > > 1. Section 4.2 says "IP packets MUST be transmitted over 802.11-OCB media > as > QoS Data" while appendix F say "The STA may send data frames of subtype > Data, > Null, QoS Data, and > QoS Null. > > > > I will update the appendix to reflect the text in section 4.2. > > > 2. In section 5.2 "The policy dictating when the MAC address is changed on > the > 802.11-OCB interface is to-be-determined.". Reading the next sentence it > looks > to me that this is needed as part of the solution and should not be left > for > the unknown future. > > > > Should we reformulate here? > > > 3. In Appendix I 4th paragraph " However, this does not apply if TBD TBD > TBD. " > .. What are the TBDs? > > > > The whole sentence will be removed. > > > Nits/editorial comments: > 1. In appendix I last paragraph "Support of RFC 8505 is may be implemented > on > OCB." should be "Support of RFC 8505 may be implemented on OCB." 2. In > Appendix > I "OCB nodes that support RFC 8505 would support the 6LN operation in > order to > act as a host". I think that instead of "would" it should be "should" > also if > this is a recommendation why not have this paragraph not in an appendix > with > "MAY" and "SHOULD > > > > > > Agreed. > > > > -- Best Regards Nabil Benamar Associate Professor Department of Computer Sciences School of Technology Moulay Ismail University Meknes. Morocco --000000000000ffa612058b887415 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ro= ni,

I think we wrote this par= t some time ago...So what about the following:


"an example of change policy is to change the MAC address of the O= CB interface each time the system boots up"

On Mon, Jun 17= , 2019 at 2:25 PM Roni Even (A) <roni.even@huawei.com> wrote:

Thanks,

The only comment left is:


2. In section 5.2 "The policy dictating when the MAC address is change= d on the
802.11-OCB interface is to-be-determined.". Reading the next sentence = it looks
to me that this is needed as part of the solution and should not be left fo= r
the unknown future.

=C2=A0

Should we reformulate here?

=C2=A0

I was expecting some recommendation since the changi= ng of MAC address is important to address privacy issues (discussed in sect= ion 5). Currently it is left open with no recommendation , only saying that= dynamic change of MAC address is needed.

Maybe the document should have some normative langua= ge for example in section 5.1 that will say that IP-OBU MUST dynamic change= their MAC addresses =C2=A0

=C2=A0

Did the document go through security area review?=

=C2=A0

Roni

=C2=A0

=C2=A0

From: Gen-art [mailto:gen-art-bounces@ietf.org] On Behalf Of NABIL BENAMAR
Sent: Monday, June 17, 2019 12:48 PM
To: Roni Even
Cc: gen-art@ie= tf.org; IETF Discussion; its@ietf.org; draft-ietf-ipwave-ipv6-over-80211ocb.all@= ietf.org
Subject: Re: [Gen-art] Genart last call review of draft-ietf-ipwave-= ipv6-over-80211ocb-46

=C2=A0

Dear Roni,

=C2=A0

Thank you for your review.

Please, see my answers below.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Sun, Jun 16, 2019, 09:52 Roni Even via Datatracke= r <noreply@ietf.or= g> wrote:

Reviewer: Roni Even
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.=C2=A0 Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-ipwave-ipv6-over-80211ocb-??
Reviewer: Roni Even
Review Date: 2019-06-16
IETF LC End Date: 2019-06-26
IESG Telechat date: Not scheduled for a telechat

Summary:
The document is almost ready for publication as a standard track RFC

Major issues:

Minor issues:

1. Section 4.2=C2=A0 says "IP packets MUST be transmitted over 802.11-= OCB media as
QoS Data" while appendix F say "The STA may send data frames of s= ubtype Data,
Null, QoS Data, and
=C2=A0 =C2=A0 =C2=A0 QoS Null.

=C2=A0

I will update the appendix to reflect the text in se= ction 4.2.


2. In section 5.2 "The policy dictating when the MAC address is change= d on the
802.11-OCB interface is to-be-determined.". Reading the next sentence = it looks
to me that this is needed as part of the solution and should not be left fo= r
the unknown future.

=C2=A0

Should we reformulate here?


3. In Appendix I 4th paragraph " However, this does not apply if TBD T= BD TBD. "
.. What are the TBDs?

=C2=A0

The whole sentence will be removed.


Nits/editorial comments:
1. In appendix I last paragraph "Support of RFC 8505 is may be impleme= nted on
OCB." should be "Support of RFC 8505 may be implemented on OCB.&q= uot; 2. In Appendix
I "OCB nodes that support RFC 8505 would support the 6LN operation in = order to
act as a host".=C2=A0 I think that instead of "would" it sho= uld be "should"=C2=A0 also if
this is a recommendation why not have this paragraph not in an appendix wit= h
"MAY" and "SHOULD

=C2=A0

=C2=A0

Agreed.

=C2=A0