Re: [paws] use cases and requirements document

[Benjamin A. Rolfe]

One "device folk" persons opinion: Comments: - The proposal for long-integer seconds was to gauge preference from the device folks For some TVWS devices bandwidth will be scarce and compact representations will be essential. In such cases over the air protocols will be developed with this optimization focus and we won't see IP and PAWS all the way to the device. In such cases there will be a compression and conversion process in between. Either representation is easily parsed. The device doing this process will typically have the resources to run a full PAWS/HTTP/TCP/IP stack so the extra processing to go from ISO date time to binary form is not a major impact, so either works as well. For the case where bandwidth is less scarce and all devices are capable of running PAWS end to end, is there actual complexity savings from one over the other? Will ISO 8601 be required as part of the HTTP/TCP stack and/or for security anyway?   - If we use ISO 8601, could we restrict it to be only in UTC? :) That seems like a good idea to me.  And more easily implemented than flattening the earth to put everyone in the same timezone (though the latter would simplify my teleconference scheduling problem  ;-). On Fri, Aug 17, 2012 at 6:08 AM, Rosen, Brian <brian.ro...@neustar.biz> 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, "gabor.ba...@nokia.com" <gabor.ba...@nokia.com> 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: paws-boun...@ietf.org [mailto:paws-boun...@ietf.org] On Behalf Of >Probasco Scott (Nokia-CIC/Dallas) >Sent: Monday, August 13, 2012 10:12 AM >To: paws@ietf.org >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" <brian.ro...@neustar.biz> 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:eric...@google.com] >>Sent:    Saturday, August 11, 2012 11:43 AM Eastern Standard Time >>To:    Teco Boot >>Cc:    Rosen, Brian; paws@ietf.org >>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 <t...@inf-net.nl> 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 <gabor.ba...@nokia.com> >><gabor.ba...@nokia.com> 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 >>                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 > >_______________________________________________ >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 -- -vince _______________________________________________ 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