I don't know which path I would prefer.
But, given the charter, and the discussion around the charter for the
need for focus in the working group, I believe that if the working group
wants to work on something akin to the stated ofcom usage reporting
requirement then it needs to
1) ask the IESG if that is acceptable
2) if the IESG agrees in principle, then work with the IESG on a
revision to the charter.
Yours,
Joel
On 3/10/2012 2:44 AM, [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
