When we started this paws effort not that long ago, the whole purpose was to define a protocol which can help devices make use of white spaces, according to rules set by the regulators. The charter we came up with covered the regulatory requirements available at the time of writing, and we did not anticipate requirements like the one Ofcom came up with recently. That is why we do not have, as Pete pointed out, explicitly listed an item for the client devices to report back anything to the server. We do have, however, the following sentence in the charter: " In order to ensure that the WG takes into account a broad range of possible use cases and requirements, the group should also reach out to other potential "customers" for a white space database access method and consider input from regulatory entities that are involved in the specification of the rules " It just does not say how the inputs from regulatory entities are to be considered ...
I would put aside the solution proposals on whether the client should use an acknowledgement message or a separate transaction for reporting back, what exactly to report, etc, and consider for the time being that we have a requirements document and this whole thread started with Andy proposing new requirements the be added there to meet Ofcom requirements. I see the following possibilities: 1. ignore the Ofcom requirements on channel reporting back to the db. I believe, if we choose this path, then the protocol we'll design will not meet the original goals, and we may just as well go home and play soccer instead 2. try to fit the Ofcom requirements into the charter. One could argue this is possible, as the Ofcom requirements do not specify what the db is supposed to do with that data, we could consider it is just for informational purposes. We've seen both pro and con opinions on this on the list, so we could continue to argue. But since both the outgoing and incoming AD thinks this is not the way to go, I do not see much hope we can succeed on this path. 3. go back to iesg and modify the charter to include the channel reporting back to the db aspect. If we do this, we can then include the relevant requirements into the reqs draft, issue a new wglc and start the work on the protocol itself. I see this the fastest and least controversial (at least from the ADs pow) path. So what do folks, who believe they know the ietf process well enough, prefer? I am just trying to get the wg out of this deadlock situation, so please be constructive. - Gabor -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of ext Pete Resnick Sent: Friday, March 09, 2012 7:57 AM To: Gerald Chouinard Cc: [email protected] Subject: Re: [paws] WGLC fordraft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting Folks, Fair warning as your incoming AD, but also as a current AD who thought he understood what work this group was chartered to do: The group is chartered to do (1) database discovery, (2) database access, (3) data formats for that database access, and (4) security for that database access. The charter also describes what that database access is like: (a) provide geolocation and other info to query the database, and (b) receive the whitespace that can be used. Insofar as what this charter only allows for protocol that is about database discovery and database access, the so-called "acknowledgment" you all are talking is either writing back to the database (if the "acknowledgment" data gets saved into the same database) or is non-database-access protocol to talk to a third party. In either case, I, as an AD, would be extremely surprised to find out either that the database was writeable by the client (that was not my understanding of the query described in the "rough outline of the protocol" section of the charter) or that there was to be additional protocol that sent data from the client to a third party. There is a whole new set of considerations on such protocol (e.g., Does the information sent back from the client need TTL values? Is there a renewal process on the data after some time? What if there are multiple clients accessing at the same time and they choose the same value? Can the response get back an error and the client has to choose something different?). If you wish to take on this work, you need to go back to the IESG and re-charter. That's fine: If the WG feels that this piece of protocol is required in order to make the rest of the protocol at all useful, now is the time to tell the IESG that and figure out how to write it into the charter. But doing this work without a charter change is going to cause heartache later. pr -- Pete Resnick<http://www.qualcomm.com/~presnick/> Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
