Ray, Thanks for considering my input.
I want to make clear that I'm not opposed to the notion of the ability for the Database to "reject" a Device's selection, or somehow "rescind" a channel previously stated as available -- provided if there is a widely accepted use case based on regulatory guidelines. My original proposal is more about nomenclature than use case. Just to be clear about my input: * If SPECTRUM_USE_NOTIFY is a "true notification", let's use the JSONRPC "notification" message type for SPECTRUM_USE_NOTIFY, and strike the [empty] SPECTRUM_USE_RESP from PAWS. * If there is a bonafide use case for the Database to "reject" or "rescind", let's define an appropriate pair of messages, such as SPECTRUM_USE_REQ and [a non-empty] SPECTRUM_USE_RESP. * If necessary, update ruleset definitions to clarify which is used when/where. Kindest regards, Dan From: Ray Bellis [mailto:[email protected]] Sent: Friday, July 26, 2013 8:59 AM To: Harasty, Daniel J Cc: [email protected] Subject: Re: [paws] SPECTRUM_USE_NOTIFY: nomenclature and response > If the Device is willing to conform to the "rejection", why did it pick - > and report - a non-conforming value to start with? Well, quite :) In theory of course a device shouldn't do that, but this is in effect the OFCOM requirement. I'll suggest to the OFCOM folks that the SPECTRUM_USE_NOTIFY should become "informational only", and not require any positive action other than logging those values. kind regards, Ray
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
