Comments: - The proposal for long-integer seconds was to gauge preference from the device folks
- If we use ISO 8601, could we restrict it to be only in UTC? :) On Fri, Aug 17, 2012 at 6:08 AM, Rosen, Brian <[email protected]>wrote: > Uh, the difference is representation of start/stop times. We both propose > to send start/stop times. Vincent proposes that the representation of > time be a long integer seconds since an epoch. He would send two such > long integers. I propose it be an ISO 8601 time string. Specifically, I > would propose an ISO 8601 interval limited to start/end, e.g. > 2011-03-01T13:00:00Z/2012-05-11T15:30:00Z. > > On 8/16/12 6:45 PM, "[email protected]" <[email protected]> wrote: > > >It seems we have an agreement on the requirement to identify the > >spectrum, by using the start/stop frequencies, with optional channel > >identifiers. > > > >Wrt to the schedule, we have so far two proposals, one from Brian > >proposing the use of start/stop times for each spectrum unit available, > >and one from Vincent proposing to use of Unix Epoch time in seconds. We > >need to decide on this, so please send your preference on this topic to > >the list. > > > >- Gabor > > > >-----Original Message----- > >From: [email protected] [mailto:[email protected]] On Behalf Of > >Probasco Scott (Nokia-CIC/Dallas) > >Sent: Monday, August 13, 2012 10:12 AM > >To: [email protected] > >Subject: Re: [paws] use cases and requirements document > > > >Hi All, > > > >Given that we have completed two Working Group Last Call cycles and this > >next version will go to the IESG, I hope we could agree on minimal > >changes to the document, i.e. changes only to D.7 for this topic. This > >will ensure the proper requirements are established for the developing > >PAWS protocol. > >I believe Brian's proposed text captures the essential requirements. > > > >Kind Regards, > >Scott > > > > > >On 8/13/12 8:24 AM, "ext Rosen, Brian" <[email protected]> wrote: > > > >><as individual> > >>I would prefer to not use the word "channel" in our documents at all > >>except for the term "channel identifier". I proposed "spectrum unit", > >>although any other term will do. "Channel" has too much baggage, A > >>simple editorial change like this is simple, and it's much better to do > >>it now. > >> > >>I think we need power in both the query and the response. In some > >>domains, it may be that you specify what power you want to use and the > >>DB tells you what spectrum you can use at that power. In other, a > >>US-like rule may be in place. Also in either the query or the > >>registration, we need a device type, which should be an entry from an > >>IANA registry. This is how you get the US "Mode II" information. > >> > >>With regard to schedule, I would like to see two mechanisms > >>1) a time by which the database should be queried again (which could > >>represent the next change in schedule) > >>2) start/stop times for each spectrum unit available > >> > >>Both these should be optional in the response. > >> > >>My text > >> > >>The data model must support specifying spectrum availability. Spectrum > >>units are specified by low and high frequencies and may have an > >>optional channel identifier. > >> > >>The data model must support a schedule for spectrum unit availability. > >>Two mechanisms must be supported. The response to spectrum > >>availability query may include a time by which the database must be > >>requeried. Each spectrum unit mentioned in the response may be > >>annotated with start and stop time/date. > >> > >> > >> > >> -----Original Message----- > >>From: Eric Chu [mailto:[email protected]] > >>Sent: Saturday, August 11, 2012 11:43 AM Eastern Standard Time > >>To: Teco Boot > >>Cc: Rosen, Brian; [email protected] > >>Subject: Re: [paws] use cases and requirements document > >> > >> > >>Hi everyone, > >> > >>Gathering all the shared points from everyone... I believe below is the > >>complete list so far: > >> > >> > >> > >>* What's the best consistent representation of the words "channel > >>numbers" for non-TV spectrum > >>* Should we update the entire doc on the topic of ³channel² or > >>³channel numbers² > >>* What¹s the best way to reduce vagueness in whether/how to include > >>"channel numbers" > >>* Is the reference to variable power required > >>* What does channel availability schedule mean > >> > >> > >>Brian's suggestion of replacing every instance of "channel" is > >>technically correctly. However, it is important for us to focus moving > >>forward. I would suggest we only work on the normative part of the spec. > >> The section Gabor is proposing for us to modify... > >> > >>On what's the best generic label for the words "channel numbers", > >>channel identifier might be the most accurate and neutral "label". > >>Thoughts? > >> > >>On the question whether variable power is required, based on FCC > >>adjacent-channel rules, the database may limit the Mode II devices to > >>100mW for some channels and 40mW for others. Therefore, the data model > >>needs to support specification of maximum power levels. > >> > >>Lastly, with regards to "schedule", the intent is to have a way of > >>informing devices when to operate for each frequency range. As long as > >>the data model supports, for example, a list of time ranges, it does > >>not prevent an implementation from providing a list with 1 entry which > >>corresponds to the "shortest available". The word "schedule" should be > >>sufficient to capture this intent? > >> > >>We would like to propose the following text to address these points: > >> > >>"The Data Model MUST support specifying available spectrum. The Data > >>Model MUST support specification of this information by start and stop > >>frequencies and MAY also support specification of this information by > >>channel identifiers. The Data Model MUST support a > >>spectrum-availability schedule and maximum power levels for each > >>frequency range." > >> > >> > >>Thoughts? > >>Eric > >> > >> > >> > >>On 8/10/12 5:48 AM, Teco Boot wrote: > >> > >> > >> What about this: > >> > >> ³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, or equivalents such as center > >>frequencies with channel width or channel numbers with channel nummer > >>allocation scheme . The Data Model MUST support a channel availability > >>schedule and maximum power level for each channel in the list.² > >> > >> More thoughts on channel numbers: we likely run into problems in > >>bands without a channel numbering scheme, or for example sub channels > >>in TV bands. > >> > >> Teco > >> > >> > >> Op 10 aug. 2012, om 13:57 heeft Rosen, Brian het volgende geschreven: > >> > >> > >> <as individual> > >> While I don't care if it's center and width or upper/lower, I > >>do think we will define the format in the protocol for interoperability > >>reasons, but don't need to do that in requirements. It wouldn't hurt > >>to decide now and use consistent terms, but we don't need to. > >> > >> I think "band" won't work, as it usually implies a much wider > >>piece of spectrum that has a common purpose. The TV Band is all the > >>channels. > >> > >> > >> On Aug 10, 2012, at 2:37 AM, Teco Boot <[email protected]> wrote: > >> > >> > >> (somewhat late response) > >> > >> A center frequency and channel width is functional > >>equivalent to start/stop frequencies. So is channel number, with ref to > >>channel number assignment scheme. For a requirements document, we just > >>need to specify what is needed. How it is encoded (Hz, wave length, > >>channel ID) is solution space. > >> > >> Seen our goal to make PAWS somewhat universal (not limited > >>to US TVWS), I do not prefer using channel numbers. > >> > >> Teco > >> > >> > >> Op 9 aug. 2012, om 21:55 heeft <[email protected]> > >><[email protected]> het volgende geschreven: > >> > >> > >> 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.t > >>xt, 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 > > > >_______________________________________________ > >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 > -- -vince
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
