Folks,
we have 802.11ac and 802.11ad now and I have a few pending patches
that I'd like to submit but unfortunately the requirements that we
have discussed for accepting patches do not meet the criteria we have
set in the community [0] for all the documentation. Additionally
getting all that documentation has proven quite difficult and at this
point I do not think we can easily get these upstream without making
an exception.
I'd like to propose a middle ground to also address another issue I've
noticed. Vendors can disagree and in order to give vendors a warm
fuzzy on ability to ensure their data is interpreted and provide the
ability to offload down to wireless-regdb even more interpretations
I'd like to propose the idea of embracing vendor namespaces within
wireless-regdb / crda / the kernel. The way I'd envision this is
'/sbin/crda US OUI' is passed upon a regulatory hint and in turn CRDA
will read the namespace for the OUI passed in regulatory.bin. Then at
our wireless summit kumbaya and with the development / enhancements of
intersect.c and union.c (not yet developed) we'd work on generalizing
the data. This would also allow vendors to supply their own rules
without the high bar that we are setting which so far has proven very
difficult to met.
In the meantime, while that gets developed, I'd still like to supply
patches to enable VHT80 for a few countries without hopefully such
high bar for documentation as I cannot get this information.
Let me know if this sounds reasonable.
[0] http://marc.info/?l=linux-wireless&m=128414096127554&w=2
Luis
On Fri, Jul 26, 2013 at 12:59 AM, Johannes Berg
<[email protected]> wrote:
> On Tue, 2013-07-02 at 17:38 -0700, Luis R. Rodriguez wrote:
>
>> I'd like to propose a middle ground to also address another issue I've
>> noticed. Vendors can disagree and in order to give vendors a warm
>> fuzzy on ability to ensure their data is interpreted and provide the
>> ability to offload down to wireless-regdb even more interpretations
>> I'd like to propose the idea of embracing vendor namespaces within
>> wireless-regdb / crda / the kernel. The way I'd envision this is
>> '/sbin/crda US OUI' is passed upon a regulatory hint and in turn CRDA
>> will read the namespace for the OUI passed in regulatory.bin. Then at
>> our wireless summit kumbaya and with the development / enhancements of
>> intersect.c and union.c (not yet developed) we'd work on generalizing
>> the data. This would also allow vendors to supply their own rules
>> without the high bar that we are setting which so far has proven very
>> difficult to met.
>
> I'm not really fully convinced, but let's discuss at the summit.
>
> Wasn't the point of the regdb and documentation etc. also that the users
> can trust it? It seems to me that if you're building a generic system
> you wouldn't really want different regulatory interpretations. And if
> you think for some special system (say a tablet) you need a different
> database, you'll probably hand-roll one specifically for that system
> anyway.
I don't think that's the problem. The problem is more -- folks are not
used to and don't wan to engage. What do we do in the meantime where
the alternative is something separate and likely redistributable
elsewhere. I'd personally rather have folks engaged and I figured a
namespace would at least provide a central middle ground. Glad to
discuss at the summit.
Luis
"Luis R. Rodriguez" <[email protected]> writes:
> In the meantime, while that gets developed, I'd still like to supply
> patches to enable VHT80 for a few countries without hopefully such
> high bar for documentation as I cannot get this information.
I believe VHT80 (and VHT160) is allowed by current regulations in a
large number of countries, and that the current db entries are in fact
wrong by stating any upper channel width limits at all in the 5 GHz
bands.
For example, regulations in most CEPT countries are likely based on
"ECC/DEC/(04)08 on the harmonised use of the 5 GHz frequency bands for
the implementation of Wireless Access Systems including Radio Local
Area Networks (WAS/RLANs)"
or a previous version of that decision. Which is available here:
http://www.erodocdb.dk/Docs/doc98/official/pdf/ECCDEC0408.PDF
Quoting:
"considering
..
e. that the systems covered by this ECC Decision operate typically in a 20 MHz channel bandwidth, other
values for the channel bandwidth are also feasible provided they comply with the relevant maximum mean
e.i.r.p. and the corresponding maximum mean e.i.r.p. density limits;
"
and the continues deciding the mentioned power and power density limits
only, without any specific channelization. This document clearly allows
and anticipates both wider and narrower channels, and so does most
likely the national regualations implementing the decision.
The list of CEPT countries implementating this decision is here:
http://www.erodocdb.dk/doks/implement_doc_adm.aspx?docid=2033
Bjørn
On Wed, Jul 3, 2013 at 1:58 AM, Bjørn Mork <[email protected]> wrote:
> "Luis R. Rodriguez" <[email protected]> writes:
>
>> In the meantime, while that gets developed, I'd still like to supply
>> patches to enable VHT80 for a few countries without hopefully such
>> high bar for documentation as I cannot get this information.
>
> I believe VHT80 (and VHT160) is allowed by current regulations in a
> large number of countries, and that the current db entries are in fact
> wrong by stating any upper channel width limits at all in the 5 GHz
> bands.
>
> For example, regulations in most CEPT countries are likely based on
>
> "ECC/DEC/(04)08 on the harmonised use of the 5 GHz frequency bands for
> the implementation of Wireless Access Systems including Radio Local
> Area Networks (WAS/RLANs)"
>
> or a previous version of that decision. Which is available here:
> http://www.erodocdb.dk/Docs/doc98/official/pdf/ECCDEC0408.PDF
>
> Quoting:
>
> "considering
> ..
>
> e. that the systems covered by this ECC Decision operate typically in a 20 MHz channel bandwidth, other
> values for the channel bandwidth are also feasible provided they comply with the relevant maximum mean
> e.i.r.p. and the corresponding maximum mean e.i.r.p. density limits;
> "
>
> and the continues deciding the mentioned power and power density limits
> only, without any specific channelization. This document clearly allows
> and anticipates both wider and narrower channels, and so does most
> likely the national regualations implementing the decision.
>
> The list of CEPT countries implementating this decision is here:
> http://www.erodocdb.dk/doks/implement_doc_adm.aspx?docid=2033
Thanks, this seems to be in agreement with the countries I was
considering update that fall under that group that I had updates for
except for one country alone: Russia.
I'll use the information you provided to update the CEPT ones though.
Luis
On Tue, 2013-07-02 at 17:38 -0700, Luis R. Rodriguez wrote:
> I'd like to propose a middle ground to also address another issue I've
> noticed. Vendors can disagree and in order to give vendors a warm
> fuzzy on ability to ensure their data is interpreted and provide the
> ability to offload down to wireless-regdb even more interpretations
> I'd like to propose the idea of embracing vendor namespaces within
> wireless-regdb / crda / the kernel. The way I'd envision this is
> '/sbin/crda US OUI' is passed upon a regulatory hint and in turn CRDA
> will read the namespace for the OUI passed in regulatory.bin. Then at
> our wireless summit kumbaya and with the development / enhancements of
> intersect.c and union.c (not yet developed) we'd work on generalizing
> the data. This would also allow vendors to supply their own rules
> without the high bar that we are setting which so far has proven very
> difficult to met.
I'm not really fully convinced, but let's discuss at the summit.
Wasn't the point of the regdb and documentation etc. also that the users
can trust it? It seems to me that if you're building a generic system
you wouldn't really want different regulatory interpretations. And if
you think for some special system (say a tablet) you need a different
database, you'll probably hand-roll one specifically for that system
anyway.
> In the meantime, while that gets developed, I'd still like to supply
> patches to enable VHT80 for a few countries without hopefully such
> high bar for documentation as I cannot get this information.
I've also been sitting on the patch "regulatory: enable channels 52-64
and 100-144 for world roaming" ...
johannes