Usually when we use the words "MUST support" we imply options. If we didn't, we would usually say MUST specify or MUST require" or something like it. So I would say, yes, the protocol must allow no schedule and no power limits, but it must also allow one or both of them.
Brian On Aug 9, 2012, at 6:37 PM, Peter Stanforth <[email protected]> wrote: > I suggest we take a look at the work MITRE has been doing on Model-Based > Spectrum Management (MBSM). A lot of this is related to defining a > spectrum commodity which is, I think, the basis of what we are trying to > do here. > http://www.mitre.org/work/tech_papers/2011/11_2071/ > > On the same text I have a question, Where it says "The Data Model MUST > support a channel availability schedule and maximum power level for each > channel in the list." What does this mean? The reason I ask is the FCC > does not allow for variable power and some Regulators are suggesting > channel allocation duration only be as long as the shortest available, > negating the need for an availability map. Does the current wording allow > for these two cases? > Peter S. > > > > On ThuAug/9/12 Thu Aug 9, 6:24 PM, "Rosen, Brian" > <[email protected]> wrote: > >> <as individual> >> I would like to suggest a more radical change >> >> I would like to define the term: spectrum unit as a unit of spectrum >> defined by a low and high frequency and optionally a channel identifier. >> Then I would like to use "spectrum unit" wherever the word "channel" >> would occur throughout the document. In the definition, I would observe >> that while it is common to have "channels" that are defined with some >> identifier, the protocol does not depend on such an arrangement, but can >> manage any swath of spectrum defined by an upper and lower frequency. >> >> I'm not attached to the specific term "spectrum unit" but I don't want to >> use "channel" as that implies something that we are not limited by. >> >> Brian >> >> On Aug 9, 2012, at 3:57 PM, Peter McCann <[email protected]> wrote: >> >>> I think "MAY include channel numbers" is somewhat ambiguous. I would >>> prefer "MAY support specification of this information by channel >>> number". >>> >>> -Pete >>> >>> [email protected] wrote: >>>> Folks, >>>> >>>> >>>> >>>> During the last F2F meeting, there was an agreement to make a slight >>>> update to requirement D.7 in http://www.ietf.org/id/draft-ietf-paws- >>>> problem-stmt-usecases-rqmts-06.txt <http://www.ietf.org/id/draft-ietf- >>>> paws-problem-stmt-usecases-rqmts-06.txt> , to make channel numbers >>>> optional to be supported. Ie, change the current D.7 >>>> >>>> "The Data Model MUST support specifying a list of available channels. >>>> The Data Model MUST support specification of this information by >>>> channel numbers and by start and stop frequencies. The Data Model MUST >>>> support a channel availability schedule and maximum power level for >>>> each channel in the list." >>>> >>>> to >>>> >>>> "The Data Model MUST support specifying a list of available channels. >>>> The Data Model MUST support specification of this information by start >>>> and stop frequencies and MAY include channel numbers. The Data Model >>>> MUST support a channel availability schedule and maximum power level >>>> for each channel in the list." >>>> >>>> >>>> >>>> I'd like to confirm this change on the list. If anyone has any >>>> objections, let me know. Otherwise I'll plan to send the document to >>>> the iesg after this change is implemented. >>>> >>>> >>>> >>>> - Gabor >>> >>> >>> >>> _______________________________________________ >>> 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
