Hi Peter, See my answers inline: From: ext Peter Stanforth [mailto:[email protected]] Sent: Wednesday, May 16, 2012 12:33 PM To: Bajko Gabor (Nokia-CIC/SiliconValley); [email protected] Subject: Re: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts
Gabor, The latest version has updates that seem inconsistent and I do not see how to comply with current FCC rules based on the modification. The following operational requirement appears to enable both FCC and Ofcom approaches : O.3 The master device MUST identify a database to which it will register, make channel requests, etc... The master device MAY select a database for service by discovery at runtime or the master device MAY select a database for service by means of a pre-programmed URI address. However in the requirements it seems that the ability to support the FCC model has been removed. Specifically: It appears that the data model requirements that supported hardcoded URI addresses for WSDBs have been removed <GB> pre-configuration is always possible. We don't need a separate requirement for it. D.2 The Data Model MUST support specifying the URI address of a white space database. <GB> after the discovery process, which results in the master device learning the URI of the DB (which can be pre-configured in some environments), the protocol itself is going to need that URI, not the data model. The above D.2 suggested me that the URI would be included in the channel request and channel response data itself, which I don't think is necessary. D.3 The Data Model MUST support specifying the URI address of a national listing service. <GB> same as above. In addition changes have been made to the discovery requirement (P.1), and the direct access (P.2) has been removed. <GB> P.1 and P.2 have been combined. The requirement to have direct access to an entity is redundant with the basic operating principle of the internet, so that redundant sentence was removed. Which is how I get to the concern that I can no longer support the FCC rule that requires a specific relationship between a radio and DB (or DBs) <GB> Pre-configuration is always possible, we do not need an explicit requirement for it. Involving the discovery process is only necessary when one needs to find the entity it wants to talk to. If that is preconfigured, then the client skips the discovery and contacts directly the entity. Are you suggesting that including the DB URI into the channel request/response is a requirement of FCC? If not, then I do not see how the above changes affect the FCC operation. As a minor editorial comment. The preamble and some of the descriptive text is a little dated. For instance the FCC has issued a 3rd Report and Order since this was originally written. Regards, Peter S. From: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts Since there were quite a few changes made to the new version -04, let's have another WGLC for this document. Therefore, I'd like to initiate a 2nd WG Last Call for comments on http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-rqmts-04.txt Please review the draft and send your comments to the list by June 1st, 2012. If you review the draft and have no comments, send a note to the list that the draft is good as it is, we need these notes as much as we need the actual comments. Thanks, Gabor From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Probasco Scott (Nokia-CIC/Dallas) Sent: Friday, May 11, 2012 11:51 AM To: [email protected]<mailto:[email protected]> Subject: [paws] UC&R document Hello All, A new version of the Use Cases & Requirements draft has been uploaded. This version of the Internet Draft has addressed all of the issues raised during Working Group Last Call, including discussion from IETF #83, and is ready to be forwarded to IESG. Kind Regards, Raj & Scott Draft: http://www.ietf.org/id/draft-ietf-paws-problem-stmt-usecases-rqmts-04.txt Diff: http://tools.ietf.org/rfcdiff?url2=draft-ietf-paws-problem-stmt-usecases-rqmts-04 Abstract: Portions of the radio spectrum that are assigned to a particular use but are unused or unoccupied at specific locations and times are defined as "white space". The concept of allowing additional transmissions (which may or may not be licensed) in white space is a technique to "unlock" existing spectrum for new use. An obvious requirement is that these additional transmissions do not interfere with the assigned use of the spectrum. One approach to using the white space spectrum at a given time and location is to verify with a database for available channels. This document describes the concept of TV White Spaces. It also describes the problems that need to be addressed to enable white space spectrum for additional uses, without causing interference to currently assigned use, by querying a database which stores information about the channel availability at any given location and time. A number of possible use cases of white space spectrum and technology as well as a set of requirements for the database query protocol are also described.
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
