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

From: Eric Chu <[email-masked]>
Date: Sun, 29 Jul 2012 17:48:15 -0700

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 availablechannels.  The Data Model MUST
    support specification of thisinformation 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 toauthenticate 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

---

From: <[email-masked]>
Date: Mon, 30 Jul 2012 10:29:55 +0100

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-masked] [mailto:[email-masked]] On Behalf Of Eric Chu
Sent: 30 July 2012 01:48
To: [email-masked]
Cc: [email-masked]
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

---

From: <[email-masked]>
Date: Mon, 30 Jul 2012 16:15:24 +0000

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-masked]<mailto:[email-masked]>>
Date: Mon, 30 Jul 2012 10:29:55 +0100
To: <[email-masked]<mailto:[email-masked]>>, Gabor Bajko <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Eric Chu
Sent: 30 July 2012 01:48
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [paws] A couple of clarifications to requirement doc?

Hi Gabor,

Thanks
Eric

_______________________________________________ paws mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/paws

---

From: "Stine, John A." <[email-masked]>
Date: Mon, 30 Jul 2012 18:48:24 +0000

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-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, July 30, 2012 12:15 PM
To: [email-masked]
Subject: Re: [paws] A couple of clarifications to requirement doc?

Hi All,

Kind Regards,
Scott

Eric

Regards

Andy

Hi Gabor,

Thanks
Eric

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Mon, 30 Jul 2012 13:50:32 -0700

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: [email-masked]
[mailto:[email-masked]] On Behalf Of Eric
Chu

Sent: 30 July 2012 01:48

Cc: [email-masked]

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-masked]
https://www.ietf.org/mailman/listinfo/paws