Re: [paws] use cases and requirements document

[Benjamin A. Rolfe]

"spectrum unit" if it is precisely defined as suggested has the advantage of being non-obvious enough people may not assume they know what it means  and so may actually read the definition :-).   Specifying a "spectrum unit" by start and end frequency is adequate, as it accommodates the current FCC requirements (TV channels), with flexibility to handle more granular specification which may be needed in the future.   Alternatively I could offer "chunk of spectrum" but I suspect that is less appropriate sounding for a standard ;-). Avoid the word "channel" without further qualification (like "TV channel" as in FCC 15.70x), where ever possible, as it is overloaded so much that people ofte assume a meaning different than what you mean. Regards -Ben   'spectrum unit' is it synonymous to 'band' which is a small section of spectrum? I too support for the change of wording, as current mobile radio technologies use and switch frequencies, and channels in their regular operation.   Best Regards,   Sajeev Manikkoth Mobile: +918792292002 From: "Rosen, Brian" <brian.ro...@neustar.biz> To: Peter McCann <peter.mcc...@huawei.com> Cc: "paws@ietf.org" <paws@ietf.org> Sent: Friday, 10 August 2012, 3:54 Subject: Re: [paws] use cases and requirements document <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 <peter.mcc...@huawei.com> wrote: > I think "MAY include channel numbers" is somewhat ambiguous.  I would > prefer "MAY support specification of this information by channel number". > > -Pete > > gabor.ba...@nokia.com 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 > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws

_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws