Re: wireless-regdb: flaw in general functionality

["Luis R. Rodriguez" <lrodriguez@atheros.com>]

On Tue, Nov 25, 2008 at 04:35:54PM -0800, Pavel Roskin wrote:
> On Tue, 2008-11-25 at 16:19 -0800, Luis R. Rodriguez wrote:
> 
> > This is documented here:
> >
> > http://wireless.kernel.org/en/developers/Regulatory#Changingthedatabasefileformat
> 
> I mean, I don't know how painful it can be.  Perhaps it's better to
> anticipate some requirements earlier than to change them later.

Its painful to add anything new. To understand this better it helps to
understand why some flags were added in the first place to regulatory rules.
The short and sweet answer is DFS. And the general rule of thumb goes like this:

When in a DFS freq, if you don't support DFS in your mode of operation,
then you cannot TX.

So if you don't support DFS in IBSS, you get NO-IBSS. If your AP doesn't
support DFS then you can't use DFS channels. If you don't support DFS
then you better not use active scanning on a STA, hence the passive scan
flag (I guess this should be renamed to NO-ACTIVE-SCAN to be more
consistent).

The NO-HT20 is historical, we're not aware of countries disallowing
this. No-HT40 is also a bit historical as it seems the countries which
do not allow this will soon allow for it.

The NO-OFDM and NO-CCK flag is unused and purely historical.

So before adding a flag I think its *really* good to think about it
thrice and see if there is a need of it, otherwise the answer should
usually be that its not a good idea to add it.

If anything we can consolidate flags or remove flags, that would be nicer
if possible.

> I think
> both "don't transmit" and "don't transmit unless permitted by the AP"
> could be useful in some jurisdictions.

Don't transmit is implicit, CRDA just "allows", so the flags we have now
are all negative for special considerations on "allowing", such as NO
IBSS, etc.

  Luis