The Data Model MUST support means that the data blob must be able to encode it, 
but it doesn't say anything about whether the db has to send it or not.
In FCC case, I'd say that the data model would encode the shortest available 
duration and the allowed power level.

- Gabor

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of ext 
Peter Stanforth
Sent: Thursday, August 09, 2012 3:38 PM
To: Rosen, Brian; Peter McCann
Cc: [email protected]
Subject: Re: [paws] use cases and requirements document

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

Reply via email to