I agree with Brian's suggestion to use ISO 8601 interval format. This plain text representation makes it easier to debug messages, and it includes timezone information.
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Rosen, Brian Sent: Friday, August 17, 2012 9:09 AM To: [email protected]; [email protected]; [email protected] Subject: Re: [paws] use cases and requirements document 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 _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
