<hat type='AD'/>
On 3/7/12 5:57 PM, Rosen, Brian wrote:
> <as individual> I think that this requirement easily fits in:
>
> In addition, the particular data exchanged between a device and a
> database might depend on the ranges of radio spectrum that are to be
> used, the REQUIREMENTS OF the database operators and their GOVERNING
> REGULATIONS, and other factors.
>
> emphasis added.
As I understood it, the device would query the database for available
white space, and the database would reply. We thought that the query
would contain at least the device's location:
3. Provide its geolocation and perhaps other data to the database
using a well-defined format for querying the database.
We also envisioned that extension points would be provided in the
protocol so that the "other data" could be provided; the two sentences
in the charter right after the one you just quoted are:
Therefore, the database access method and the query/response data
formats that are exchanged using that method need to be designed for
extensibility rather than being tied to any specific spectrum,
country, or phy/mac/air interface. For example, the working group
should define extension points for the database access method and the
query/response formats, so that use cases other than those currently
envisioned can be addressed in the future if a community of interest
wishes to do so.
Correct me if I'm wrong, but what we're discussing here is not a new
field in the database query -- it is a reporting mechanism. I would be
more comfortable if we said something like "to meet Ofcom requirements,
the database query needs to include [FieldX]".
The charter does say:
Once the device learns of the available white space (e.g., in a TV
white space implementation, the list of available channels at that
location), it can then select one of the bands from the list and
begin to transmit and receive on the selected band. If the device's
parameters have changed (e.g., if some amount of time has passed or if
the device has changed location beyond a specified threshold), it
might need to query the database again to determine what white space
is still available.
I suppose one could envision the following flow:
1. Device queries database.
2. Database responds with list of available channels.
3. Device queries database again, providing a new parameter: the actual
channel it wants to use (which it can't know until it receives the
original list of channels or tries to do something with the original
list of channels, such as transmit/receive).
4. Database responds with updated list of available channels (where the
updated list is based on information the device provided in step 3).
That's a bit of a strange way to look at it, though.
> It is data exchanged between the device and the database and It
> doesn't significantly alter the design of the protocol, and
> specifically doesn't tread into areas of concern when the charter was
> written. We didn't have the benefit of the OFCOM rules at the time,
> or we could have explicitly included it.
>
> Again, if the whitespace returned somehow depended on this
> information, then I think we would be out of scope.
But doesn't it? Or is this reporting purely informational?
> I defer to your decision, of course.
I am not a special person to whom one must defer. I'm just a member of
the community who happens to be serving in the AD role for a few years.
Peter
--
Peter Saint-Andre
https://stpeter.im/
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
