Date:	Thu, 6 Mar 2008 20:55:24 -0500
From:	"Luis R. Rodriguez" <mcgrof@...il.com>
To:	"bruno randolf" <bruno@...nktube.com>
Cc:	linux-wireless <linux-wireless@...r.kernel.org>,
	"linux kernel" <linux-kernel@...r.kernel.org>,
	"Johannes Berg" <johannes@...solutions.net>,
	"John W. Linville" <linville@...driver.com>,
	"Jouni Malinen" <j@...fi>,
	"Larry Finger" <Larry.Finger@...inger.net>,
	"Sam Leffler" <sam@...no.com>, "Dan Williams" <dcbw@...hat.com>,
	"Ivan Seskar" <Seskar@...lab.rutgers.edu>,
	"Kishore Ramachandran" <kishore@...lab.rutgers.edu>,
	"Perez-Gonzalez, Inaky" <inaky.perez-gonzalez@...el.com>,
	"Marcel Holtmann" <marcel@...tmann.org>,
	"Tim Gardner" <tim.gardner@...onical.com>,
	"Jean Tourrilhes" <jt@....hp.com>
Subject: Re: [RFC] Linux central regulatory domain agent - next stage

On Tue, Mar 4, 2008 at 9:32 PM, bruno randolf <bruno@...nktube.com> wrote:

>  > My preference is to keep the real database on a development box which
>  > has some web interface which people can use to view. Ideally users can
>  > then send updates to the database to provide updates to rules. The
>  > database can then be dumped and an application used to generate some
>  > flat file. Distributions can then pick this flat file up and propagate
>  > it to users. A user's host would have the CRDA userspace daemon
>  > running, and once a new file is downloaded the regulatory daemon is
>  > informed about it. The reg daemon would then parse the flat file and
>  > update its internal database and new regulatory rules would become
>  > available to the kernel. What I am not sure on is the best format to
>  > use for the flat file.
>
>  if at all, i'd suggest a simple binary format for that file. it's not that we
>  would have to do a lot of searching thru it, so i think something
>  database-like is not necessary. also it has to be included in embedded
>  systems so it should be quite small. a text-based approach would make it too
>  easy for users to change and override regulatory settings. i know the basic
>  idea is to put the liability to the user, but at the same time i think we
>  should not make it too easy to alter the regulatory rules.

I second a binary file format but not for security purposes -- instead
I second it to reduce the size and make it easily readable to the
regulatory daemon. Although I acknowledge the importance of obeying
local regulatory laws by no means do I think this should interfere
with us coming up with the best possible solution to the problem. I
also envision that down the road we'd want to make it easy to
automatically change current restrictions not due to regulatory rules
but instead to enhance communication dynamically based on currently
read wireless trends in your local environment. We don't want to lock
users but enable them and assist them in obeying local regulatory
laws. Hardware vendors, on the other hand, are currently legally tied
to strictly obeying local regulatory restrictions or at least their
attorney's interpretation of such laws but that doesn't mean that its
right too or that their attorney's interpretation is right. Security
through obscurity simply does not work for restricting devices and
having laws that stick to this philosophy and supporting it deters
technology and communication in the end instead of enhancing them
which IMHO *is* the purpose of regulatory agencies.

>  actually i think the best way to keep and update the regulatory table is as
>  part of a source tree! instead of building a huge new infrastructure - a
>  server with a db which users can upload regulatory changes to, a review
>  process for these changes, a file export for downloading the latest db, a
>  file format for keeping the db on the host and then parsing them into the
>  application - why not just maintain the regulatory rules as part of the
>  source tree and use the processes (version management, peer review) we
>  already have in place there?

Well the whole notion of using a db was for the purpose of
presentation and for easy review. I'd like to make it easy for
non-developers to contribute changes to the regulatory db. My v2
patches kept regulatory domains in C files in structs which basically
were tables with some sort of shared key. I have to say that while
trying to update them even I found it difficult and sometimes made
easy mistakes. To easily view regulatory domain restrictions I think
what's easiest is some sort of HTML table online for each regulatory
domain.

For patching purposes I think you're right and that its easiest
through patches as that is what we're used to. But I can also see SQL
statements for modifications working or plain English proposals which
maintainers can then translate to SQL or just alter through a DB admin
interface. I guess either way its easy to make mistakes. One way or
another we do need a way to make the db easily visible and we also
need that binary end file. A db seems nice as you can easily query
data and do whatever you want with it. If we keep it in C files a db
database would need to be drop'd and created each time changes are
made. If you don't use a DB I don't know how you can make the
regulatory db easily visible.

>  well, which source tree? i don't really know. iw maybe?

Hm, was actually thinking of splitting up some stuff for licensing
purposes. More on this below.

> or would'nt it make
>  sense to make a library which can be used by iw, wpa_supplicant, hostapd and
>  other applications alike to access the wireless settings, including
>  regulatory domains?

Definitely, although I'd like to separate our own tools and the
central reg daemon/libs to reading/parsing reg domains on a binary
file. This is because I'd like to work together with the BSD family on
a decent reg db. I think we can both benefit by working on this
together, just like with radiotap. Operating System-wise the parsing
of the file can remain the same but what we would differ in is what we
do with the info we parse. For example I expect a regdaemon to sit
there and have at its disposal all available regulatory info. Should
we need to change country/regdomain manually we can use iw. iw will
query the regulatory daemon for its desired regulatory domain, return
it to iw and then iw can use nl80211 to upload it to the kernel.
Another example, should an 802.11d frame arrive and the wireless
subsystem accepts it to change regdomain the kernel can query the
regulatory daemon using nl80211 to get its regulatory domain. I would
want the regulatory daemon licensed under the ISC/BSD and our tools
can simply keep with the GPL tradition.

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists