I will of course go along with the consensus, however, there is one advantage in going back to the IESG now, because the "sentence" allows for additional Regulatory changes/input it should be a quick decision since Ofcom is probably the most advanced in implementing a DB(s) and WSD's.
The FCC is probably going to have changes but more slowly, Industry Canada also implementing regulations. If one looks at the Ofcom model of licensed, only 4 TV stations, one could assume that what they are doing may be similar to other countries that may have a similar model, or those that have State run TV with limited channels. If we do not are we making ourselves irrelevant to Ofcom now…and will have to play catch up not only with what is already known now, but what will be changing in the future? The next round will assumably start on more detailed work…why not clear that path now? And once cleared we can do both…in parallel? Sincerely, Nancy On Mar 19, 2012, at 9:04 AM, Teco Boot wrote: > 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 _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
