Hi All, Several months ago I pushed adding the goal of using separate business and data models and making them modular (See Section 6.3 of the use cases and requirements). My intent was to address this problem of different ways to define spectrum and different data required by different administrations in the managed sharing of spectrum. Using channel numbers infers that all details of the channel are known a priori, in our case when creating PAWS. I think this is very restrictive. Spectrum definitions should be made part of a data module that can be replaced whole cloth. If it is made too close to the communications specification, i.e. included in the data elements of a message defined in the protocol rather than specified by an optional data module, it will greatly limit the future applicability of the PAWS work.
The recent discussion In the US with the release of the PCAST report "Realizing the Full Potential of Government Held Spectrum to Spur Economic Growth<http://www.whitehouse.gov/sites/default/files/microsites/ostp/pcast_spectrum_report_final_july_20_2012.pdfhttp:/www.whitehouse.gov/sites/default/files/microsites/ostp/pcast_spectrum_report_final_july_20_2012.pdf>" proposes to make database management a tool well beyond the TVWS. In these cases, the data model will need to support arbitrating reuse among any RF technologies. It will need to include the management of coexistence. This management will need to be collaboratively achieved among multiple database administrators. Channel numbers or specifying frequency definitions would both be inadequate. By keeping it modular other standards bodies can worry about how to model spectrum use so that coexistence can be arbitrated. I don't think this is something that PAWS would want to do. The greatest value of PAWS is its definition on how to discover databases and how to obtain and maintain the authorization to use spectrum in a secure way. In the near term, PAWS may need to create data models that match current TVWS regulation so the standard can be made operational sooner. Long term, however, other standards bodies are likely to generate methods to model spectrum use and to arbitrate compatibility of spectrum uses that are more general. Work of this nature is currently being pursued by the IEEE DySPAN SC P1900.5 WG. By emphasizing the modularity of this data in this first go around, it establishes a first release of PAWS that can be expanded upon easily as new regulatory and technical requirements for reuse are defined. These requirements and the means of arbitrating compatibility can be added by choosing the data model. John From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Monday, July 30, 2012 12:15 PM To: [email protected] Subject: Re: [paws] A couple of clarifications to requirement doc? Hi All, In development of the Use Cases & Requirements, as a group we have discussed this many times and always concluded that PAWS is not specific to TV bands, although TV bands will be first taken into use. I believe requirement D.7 is flexible and does not limit PAWS to TV frequencies. By stating that the data model must support channel numbers AND frequency definitions, this does not mean that both must be used at the same time, only that the data model must be flexible enough to allow both to be used. Decision to use channel numbers or to specify frequencies can be made at run-time, e.g. when the regulator domain is determined (see requirement P.3). Requirement P.4 says that PAWS must provide the ABILITY for the database to authenticate the master, it does not say that the master must be authenticated. Authentication of the master is an option. I do notice that both of the proposals submitted to the work group envision HTTPS, or HTTP over TLS, which is fully capable of supporting authentication of the master, but also is in wide use for applications which authenticate only the server-side of the transaction. The comments from Eric I believe are valid, i.e. PAWS not limited to TV bands only and authentication of the master device is not mandatory. However I believe our requirements as written do support these positions. Kind Regards, Scott From: ext com <[email protected]<mailto:[email protected]>> Date: Mon, 30 Jul 2012 10:29:55 +0100 To: <[email protected]<mailto:[email protected]>>, Gabor Bajko <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [paws] A couple of clarifications to requirement doc? Eric Thanks very much for your comments. The intent of the requirements spec is to cover all spectrum, but of course we only have two sets of inputs from regulatory bodies at present and they both relate to TV spectrum. The actual Ofcom language refers to "a list of lower and upper frequency boundaries" which is more flexible than using channels, but this is covered in the requirement D.7 that you quoted, as the next sentence says "The Data Model MUST support specification of this information by channel numbers and by start and stop frequencies.". So, although we could continue to refine the language in the PAWS requirements with regard to channels, personally I'm OK with the document and I don't see this as an area where we need to spend further effort. On your second point, in general I think we demand a lot of our regulators if we expect them to have a full understanding of security threats and remedies, therefore we need to allow the PAWS protocol to include necessary security even if regulators were a bit vague. I interpret "...the protocol MUST provide the ability for..." in P.4 and elsewhere as allowing PAWS to implement best practice with regard to security (authentication/authorisation/encryption/whatever), and I trust the PAWS participants not to make this unnecessarily onerous. Clearly neither will we be writing a protocol that is full of security holes. In this regard I don't have any problem with the requirements as written, as this is all sorted out in the next stage. Regards Andy From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Eric Chu Sent: 30 July 2012 01:48 To: [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> Subject: [paws] A couple of clarifications to requirement doc? Hi Gabor, Apologize for the late "entry" but we would like to suggest a couple of minor but important clarifications to current requirement doc to minimize potential confusions: * The final spec should be general enough to support all spectrum. Not just TV spectrum. In our discussions with several PAWS members, they all agree with this point but they point to the requirement doc as the limiting factor to generalize the spec. For example in the Normative Requirements section 6.1 D7 " The Data Model MUST support specifying a list of available channels. The Data Model MUST support specification of this information by channel numbers and...." * Both FCC and Ofcom do not require "authentication of device". While the FCC requires the DB to check for "authorized" FCCID, device authentication is not required. Current requirement doc requires the database to "authenticate" the master device as stated in the Normative Requirements section 6.1 P.4 " The protocol MUST provide the ability for the database to authenticate the master device.". To be consistent with FCC and Ofcom spec, we believe the spec should allow for the implementation of strong authentication as an option. Appreciate your thoughts on what's the best process to consider these refinements. If there's consensus, Google is more than happy to take on the work of providing specific text changes. Thanks Eric _______________________________________________ paws mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/paws
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
