regdomain.xml [was also: - Linux wireless-regdb]

[Bjoern A. Zeeb]

Hi,

I’ll just join in on the last email in the thread not replying to 
anything specific.

Having gone through some of the stuff lately myself in order to put [1] 
out (which is also includes a few things to discuss) I’ll try to 
summarise a few things I’ve learnt and thought of, which confused me 
over the time:

- SKU - what does it actually stand for?   Does it really belong into 
our regdomain?

- why are the freqbands prefixes with “H”, “F”, .. and what do 
these magic letters stand for?

- We have netbands, freqbands, and bands.  None of these are actually 
describing the actual frequency ranges (as the linux-db does).

- The freqbands seems to start and end on the center frequency of the 
first/last chansep spaced channel.  In the old days that was less 
confusing I guess as to now with 4x20 for VHT80.

- I am still unclear as to where we should map channels to frequency 
because we are half-hearted doing that partially for upper and lower 
bounds of freqbands currently.  As such I have different freqbands for 
VHT20 vs. VHT40/80/160 as there are cases where there is an extra 20 
channel not part of 80s.

- I’d love to have the freqbands actually describe the frequency 
limits and have the mappings of channels within them elsewhere;  I have 
no idea how/where Linux is doing that.

- I’d love to have general freqbands and groups of them independent of 
the netbands.

- I do not actually understand what netbands are for given we have the 
IEEE80211_CHAN_ set appropriately.   It’s for simplicity later but 
there is a lot of duplication.  That said, some of these 
IEEE80211_CHAN_* flags do not actually belong to the regulatory limits 
either but are an 802.11 channel description.

- This all leads to confusion currently as to how we setup 
bands/channels/..  I made a mistake by accident and the list of 
combinations we checked in ifconfig exploded to 350.000 for whether a 
channel was valid.  Clearly told me that the organisation does not seem 
to be right.

- I was wondering if for clarity we can break up regdomain.xml into 
multiple files?

- One thing I don’t like on the Linux version is that for, say ETSI, 
the information is basically copied per EU member state.  I love our 
reference model there.  I don’t mind having etsi, etsi1, etsi2 if I 
can then say 20 countries it’s etsi2 and be done.   I think that is 
something essential and good we have.


- I do like our more structured format a lot more than the Linux one.

- We are lacking a few things, DFS and INDOORS and maxpower are not the 
only things which matter these days.  You may notice “wmmrule=ETSI” 
in the Linux reg-db, for example.

- I wonder if what we actually want is a multi-layer thingy inheriting 
one from another or if we want a pure-regdomain (not knowing about 
channels) and more logic elsewhere which deals with putting WiFi things 
into that)?


- I think it’ll need a bit more than simply restructuring 
regdomain.xml;  I think doing it will probably also need a bit more (a) 
documentation on what each bit means and tries to accomplish) and (b) a 
more clear separation between frequencies and restrictions and 802.11 
channels and with that a bit more downward code changes.

- I would really love to see some of these things sorted and I’d love 
if the thread would stay alive.

Just my 5cts,
Bjoern


[1] https://reviews.freebsd.org/D25999