Re: [paws] A couple of clarifications to requirement doc?

[Benjamin A. Rolfe]

Hi Andy, Your responses confuse me a bit, sorry if it's just me being daft again... 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. I'm not sure I see the point of doing both. For every regulatory domain I've studied so far, each TV channel is be defined by either a start and end frequency or center frequency and width.   Seems the frequency method is more generally useful for an exchange format.  I'm somewhat confused as to how PAWS will accommodate different database content and formats as they change, which seems inevitable.     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. The FCC has specified that the distribution of channel availability information must be secure.  This is in addition to the requirement that the device receiving channel information has been verified as authorized to operate as a white-space device.  Simple is definitely better as some of the devices I envision will be very low cost/low power. I think the term "master" is rather limiting. There are devices that have access to the internet and so can access a database independently, and those that depend on some other source of channel availability information  There seems to be an assumption in the term "master" that the device accessing the database is also the network master for any devices depending on it as the data source. There is no reason to tie these roles together. It is quite possible that the device with database access is "just any peer" and network master.   I think when labeling a device that does not have access to the database (i.e. not internet infrastructure tied) the term "dependent" is more accurate.  I would think PAWS would not want to constrain the topology or architecture of the underlying network layers that may carry the protocol...am I missing some basis assumption? Thanks in advance for patience with someone new to the discussion!   Regards   Andy     From: paws-boun...@ietf.org [mailto:paws-boun...@ietf.org] On Behalf Of Eric Chu Sent: 30 July 2012 01:48 To: gabor.ba...@nokia.com Cc: paws@ietf.org 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 paws@ietf.org https://www.ietf.org/mailman/listinfo/paws

_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws