While responses have time windows, as far as I know, requests do not
specify when the response will be acted upon, if ever, or for how long.
As such, this seems to imply either that we add significantly more
information to requests, or that any change in anything that has ever
been asked for gets pushed?
That does not sound like a good design.
Yours,
Joel
On 1/17/2012 6:08 PM, [email protected] wrote:
Hi Gabor,
On 1/12/12 8:26 PM, "ext [email protected]"<[email protected]>
wrote:
P.3 currently says: The protocol between the master device and the WS
Database MUST support pushing updates in channel availability changes
to subjects.
There were comments that this requirement involves a mechanism, we should
reformulate to be mechanism agnostic.
There was a suggestion to "make the requirement "quick way to change
availability" rather than imply a mechanism.".
The use case is that if the channel availability changes in the DB, the
client has to be able to detect it and get the new availability list
within a time period set by the regulator.
Can someone send suggested text on how to reformulate this requirement?
The requirement to enable Push notifications to be sent to a white space
device which has registered with a database is important especially in the
context of Ofcom requirements (I believe). The reasons for such push
notifications could be for purposes that go beyond just channel
availability updates. A proposal for the requirement is as follows:
Requirement: A white space database should be able to send unsolicited
messages to a master device which has registered with it. The protocol
between the WS database and master device MUST allow for push
notifications to be sent from the database to the master device.
-Raj
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
