Hi Guys So then in the section for terms there will be an explanation of when a Must demands something, or offers one of two solutions, or?
So it will need to be defined as to not be confusing as to when a "MUST" carries no other choices? "Must Support" implies options "Must specify" "Must require" , ETC. Sincerely, Nancy On Aug 9, 2012, at 3:56 PM, Rosen, Brian wrote: > 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 _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
