Gabor Bajko mentioned: I think we first have to agree whether we need at all to encode an 'unavailable channel'. Current draft section 4.4.2 says: "The response message for the Available Spectrum Query contains a schedule of available spectrum for the Device." To me this means that channels which are not listed are implicitly unavailable and leakage into unavailable spectrum has to conform to the rules.
I agree that "no mention of a segment of spectrum as available" is a possible way to express "it is unavailable". Let's call this "implicit unavailability". However, if I'm a Device, and I received a SPECTRUM_AVAIL_RESP that says "Channel 17 is available until 6pm" (and nothing else is mentioned about Channel 17 for the time period after 6pm)... does that mean "Channel 17 is unavailable after 6pm" or "I have no information about Channel 17 after 6pm (maybe it is available, maybe it's not)"? Thus I propose that we still need some sort of "explicit unavailable" notation, and "no mention" should be reserved to express "there is no information about this piece of spectrum in this time period - ask again later". Stated another way: I propose that PAWS is better off if the Database has some way to express the difference between "channel unavailable" and "no information given about this channel [in this time period]". Perhaps the "implicit unavailability" approach could be made to work by then ADDING more fields to the event structures, like "response valid through" or "response expiration" values... but I find that more convoluted than a "explicit unavailable" notation, which can express "this bit of spectrum is unavailable in this time period". Dan Harasty
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
