I don't prefer any delay in getting out a first release of a PAWS protocol. We already know the protocol must be extendable and new requirements from regulators will be on the horizon. So I suggest to continue with our work, based on current charter. Meanwhile, we can discuss extensions.
On 1: I don't play soccer. Let's continue fulfilling our current task. On 2: We can work on new documents for additional requirements and protocol extensions. No WG adoption yet. On 3: Let's do this in parallel. When having candidate documents and a new charter, it shouldn't take much time to get this published. Thanks, Teco Op 10 mrt. 2012, om 08:44 heeft <[email protected]> <[email protected]> het volgende geschreven: > 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
