<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
