Hi Gabor, The WG charter has been defined with a very narrow focus in order to ensure that a protocol solution for use between white space devices and database(s) can be delivered within a reasonable timeframe. However at the time of the chartering, we did not have ofcom requirements and hence the scope was limited to a request/response protocol for the device-2-database interface. Now that we do have a better view of Ofcom requirements, it would be shortsighted to not consider those. I believe that the scope of the extension to the protocol that is being discussed is not significant enough to cause a major rethink of the charter or the protocol. Hence I would be in favor of option 3. The IETF process allows working groups to recharter at any time. I believe there is enough reason for a minimal extension of the charter scope to accommodate the Ofcom requirement.
-Raj On 3/10/12 1:44 AM, "ext [email protected]" <[email protected]> wrote: >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 _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
