Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws)

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 03 May 2011 14:36:34 +0200

Folks, at the IESG retreat just now we discussed the PAWS charter. The
basic feedback is as follows:

- it seems appropriate to do this work at the IETF

- the Applications Area seems like the right area within the IETF

- it would be best to prefer re-use of existing IETF protocols

- we need to clean up the charter text here and there

I've provided specific text suggestions below. Discussion is welcome.

On 4/19/11 6:56 PM, IESG Secretary wrote:
> A new IETF working group has been proposed.  The IESG has not made any
> determination as yet. The following draft charter was submitted, and is
> provided for informational purposes only. Please send your comments to the
> IESG mailing list ([email-masked]) by Tuesday, April 26, 2011.            
>   
> 
> Protocol to Access White Space database (paws)
> ------------------------------------------------
> Current Status: Proposed Working Group
> Last updated: 2011-04-14
> 
> Chairs:
> TBD
> 
> Area Directors:
> TBD
> 
> Area Advisor:
> TBD
> 
> Mailing lists:
> Address: [email-masked]
> To Subscribe: https://www.ietf.org/mailman/listinfo/paws
> Archive: http://www.ietf.org/mail-archive/web/paws/
> 
> Description of Working Group:
> 
> Governments around the world continue to search for new pieces of radio
> spectrum which can be used by the expanding wireless communications
> industry to provide more services in the usable spectrum. The concept
> of allowing secondary transmissions (licensed or unlicensed) in
> frequencies allocated to a primary user is a technique to "unlock"
> existing spectrum for new use. An obvious requirement is that these
> secondary transmissions do not interfere with the primary use of the
> spectrum. Often, in a given physical location, the primary user(s) may
> not be using the entire band allocated to them. The available spectrum
> for a secondary use would then depend on the location of the secondary
> user. The primary user may have a schedule when it uses the spectrum,
> which may be available for secondary use outside that schedule. The
> fundamental issue is how to determine for a specific location and
> specific time, if any of the primary spectrum is available for secondary
> use. One simple mechanism is to use a geospatial database that records
> protected contours for primary users, and require the secondary users to
> check the database prior to selecting what part of the spectrum they
> use. Such databases could be available on the Internet for query by
> users.
> 
> In a typical implementation of geolocation and database to access TV
> white space, a radio is configured with, or has the capability to
> determine its location in latitude and longitude. At power-on, before
> the device can transmit or use any of the spectrum set aside for
> secondary use, the device must identify the relevant database to query,
> contact the database, provide its geolocation and receive in return a
> list of unoccupied or "white space" spectrum (for example, in a TV
> White space implementation, the list of available channels at that
> location). The device can then select one of the channels from the list
> and begin to transmit and receive on the selected channel. The device
> must query the database subsequently on a periodic basis for a list of
> unoccupied channels based on certain conditions, e.g. a fixed amount of
> time has passed or the device has changed location beyond a specified
> threshold.
> 
> The databases are expected to be reachable via the Internet and the
> devices querying these databases are expected to have some form of
> Internet connectivity, directly or indirectly. The databases may be
> country specific since the available spectrum and regulations may vary,
> but the fundamental operation of the protocol should be country
> independent, thus extensibility of data structures will be required. The
> solution will not be tied to any specific spectrum, country, or
> phy/mac/air interface but may incorporate relevant aspects of these as
> needed for proper operation.
> 
> The proposed working group will :

Remove "proposed".

Add:

- define the requirements for querying a white space database

> - standardize a protocol for querying the database, which includes a
> location sensitive database discovery mechanism and security for the
> protocol, and application services.
> - Standardize the data structure to be carried by the query
> protocol.
> 
> The protocol must protect both the channel enablement process and the
> privacy of users. Robust security mechanisms are required to prevent:
> device identity spoofing, modification of device requests, modification
> of channel enablement information, impersonation of registered database
> services and unauthorized disclosure of a users location.
> 
> Existing IETF location data structures and privacy mechanisms may be
> considered for use. The WG will also investigate the need for other
> mechanisms and related protocols to the White Space DB.

Change to:

  The working group will prefer to use existing IETF technologies
  and privacy mechanisms where possible.

Some IESG members were concerned about the open-ended nature of this
statement:

  The WG will also investigate the need for other mechanisms and
  related protocols to the White Space DB.

Is that really needed? Can it simply be removed?

> The Working Group will set up and maintain appropriate contact and
> liaison with other relevant standards bodies and groups, including IEEE
> 802.11af and IEEE 802.22 to begin with. The working group may also
> consider input from regulatory entities that are involved in the
> specification of the rules for secondary use of spectrum in specific
> bands.
> 
> Goals and Milestones
> 
> Sep 2011  Submit 'Requirements and Framework' to the IESG for
>           publication as Informational

Change "Requirements and Framework" to "Requirements for Querying a
White Space Database".

> Apr 2012  Submit 'Protocol for Querying a Whitespace Database' to
>           the IESG for publication as Proposed Standard
> 
> Apr 2012  Submit 'Data Model for Whitespace query protocol' to the
>           IESG for publication as Proposed Standard

Change "Model" to "Structure".

(Also change "Whitespace" to "White Space"?)

Other IESG members might have additional comments. I might even have
further comments after the IESG meeting is finished. :)

Peter

--
Peter Saint-Andre
https://stpeter.im/

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 03 May 2011 13:54:56 +0100

I made a comment on the security bit that lead to a thread with
some suggested changes. [1]

I think incorporating that language would be good. Its a bit
scattered over a couple of messages, but I think I was ok with
all the variants. I've tried to reconstitute this below
start from Brian's suggested change.

OLD:

NEW:

   The protocol must protect both the channel enablement process and
   the privacy of users, and prevent unauthorized disclosure of a
   user's location. In some circumstances robust security
   mechanisms will be required to be used to prevent device identity
   spoofing, modification of device requests, modification of channel
   enablement information and impersonation of registered database
   services. Such security requirements may be in the scope of
   regulations which can vary between countries. The WG MUST
   consider these security aspects in the design of the protocol
   with sufficient flexibility to meet the needs of differing
   regulations/deployments.

S.

[1] http://www.ietf.org/mail-archive/web/paws/current/msg00159.html

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 3 May 2011 09:04:26 -0400

I have two comments:

I don't recall ever having been requested to "prefer to use existing IETF technologies" before.  Is there something special about this effort that warrants this language?  Usually, we just consider them.  I suspect we actually do "prefer" in many cases, but this request stands out in my mind and I'm trying to understand why this is needed.

Also, some push back on "Requirements and Framework" to "Requirements".  This implies the IESG sees no need for a framework document.  We thought it might be helpful, but didn't warrant a separate document, so we suggested combining framework and requirements into one document.

In the discussions we have had, there are other needs to build a whitespace ecosystem.  Here in the U.S. for example, we need automated ways to provision the database of protected entities that allows sharing of data among competing database providers.  That is the origin of the "other mechanisms and protocols" part.  We can recharter to get those in AFTER the database discovery and query mechanisms are worked out, so I don't have a problem with deleting that language from the charter now.

Brian

On May 3, 2011, at 8:36 AM, Peter Saint-Andre wrote:

> <smime.p7s><ATT00001..txt>

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 3 May 2011 09:05:25 -0400

I am fine with this language change.

Brian
On May 3, 2011, at 8:54 AM, Stephen Farrell wrote:

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 03 May 2011 15:10:36 +0200

On 5/3/11 3:04 PM, Rosen, Brian wrote:
> I have two comments:
> 
> I don't recall ever having been requested to "prefer to use existing
> IETF technologies" before.  Is there something special about this
> effort that warrants this language?  Usually, we just consider them.
> I suspect we actually do "prefer" in many cases, but this request
> stands out in my mind and I'm trying to understand why this is
> needed.

The concern expressed during the IESG discussion was that the charter as
proposed lets the WG define just about any new application protocol
(e.g., not even to prefer HTTP as a protocol for transferring data)
instead of taking a look at what existing IETF technologies might be
reusable.

> Also, some push back on "Requirements and Framework" to
> "Requirements".  This implies the IESG sees no need for a framework
> document.  We thought it might be helpful, but didn't warrant a
> separate document, so we suggested combining framework and
> requirements into one document.

The rest of the charter text talks about requirements but not the
framework. In this context, what exactly are folks thinking about when
they refer to a framework?

> In the discussions we have had, there are other needs to build a
> whitespace ecosystem.  Here in the U.S. for example, we need
> automated ways to provision the database of protected entities that
> allows sharing of data among competing database providers.  That is
> the origin of the "other mechanisms and protocols" part.  We can
> recharter to get those in AFTER the database discovery and query
> mechanisms are worked out, so I don't have a problem with deleting
> that language from the charter now.

Either way. In general it's probably good for us to complete the core
work first and then look at extensions or additional methods for
accessing the database.

Peter

--
Peter Saint-Andre
https://stpeter.im/

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 3 May 2011 15:14:25 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Rosen, Brian
> Sent: Tuesday, May 03, 2011 4:04 PM
> To: Peter Saint-Andre
> Cc: [email-masked]; [email-masked]
> Subject: Re: [paws] WG Review: Protocol to Access White Space 
> database (paws)
> 
> I have two comments:
> 
> I don't recall ever having been requested to "prefer to use 
> existing IETF technologies" before.  Is there something 
> special about this effort that warrants this language?  
> Usually, we just consider them.  I suspect we actually do 
> "prefer" in many cases, but this request stands out in my 
> mind and I'm trying to understand why this is needed.
> 

Hi, 

'Prefer' means in this context that if some specific combination of IETF
technologies meet the Requirements it should be preferred over inventing
a new protocol. 

Regards,

Dan

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 3 May 2011 09:46:03 -0400

Inline

> instead of taking a look at what existing IETF technologies might be
I don't want to make a big deal out of this.  I don't think it changes anything.  I point out your concern is true of every protocol effort we start these days.   Yet, this language isn't in any charter I've looked at recently.  To cite an example, clue's charter says:
     Reuse of existing protocols and backwards compatibility with
     SIP-compliant audio/video endpoints are important factors for the
     working group to consider.

"Consider" to "prefer to use" is a change in language AFAIK.  Is there something special about paws that warrants this change, or are you going to ask charters generally to use that phrase?  We can make the change, I'm just trying to understand if there is anything we've missed.

> they refer to a framework?
Whenever we start talking with new people, we have to bring them through the deck we present in the BoF, which explains what whitespace is, how it works, what the regulatory situation is, and what role the database plays.  We need to show some use cases.  We were thinking we would put a version of that in the Requirements and Framework document, and then have the protocol document just refer to it, rather than explain it all again there.

> work first and then look at extensions or additional methods for
No problem

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 03 May 2011 15:55:33 +0200

On 5/3/11 3:46 PM, Rosen, Brian wrote:
> Inline On May 3, 2011, at 9:10 AM, Peter Saint-Andre wrote:
> 
>>> existing IETF technologies" before.  Is there something special
>>> about this effort that warrants this language?  Usually, we just
>>> consider them. I suspect we actually do "prefer" in many cases,
>>> but this request stands out in my mind and I'm trying to
>>> understand why this is needed.
>> 
>> The concern expressed during the IESG discussion was that the
>> charter as proposed lets the WG define just about any new
>> application protocol (e.g., not even to prefer HTTP as a protocol
>> for transferring data) instead of taking a look at what existing
>> IETF technologies might be reusable.
> I don't want to make a big deal out of this.  I don't think it
> changes anything.  I point out your concern is true of every protocol
> effort we start these days.   Yet, this language isn't in any charter
> I've looked at recently.  To cite an example, clue's charter says: 
> "Consider" to "prefer to use" is a change in language AFAIK.  Is
> there something special about paws that warrants this change, or are
> you going to ask charters generally to use that phrase?  We can make
> the change, I'm just trying to understand if there is anything we've
> missed.

I don't see a big difference between "consider" and "prefer if
possible", but "should consider" is better than "may consider" in my
opinion because the latter sounds purely optional.

>>> "Requirements".  This implies the IESG sees no need for a
>>> framework document.  We thought it might be helpful, but didn't
>>> warrant a separate document, so we suggested combining framework
>>> and requirements into one document.
>> 
>> framework. In this context, what exactly are folks thinking about
>> when they refer to a framework?
> Whenever we start talking with new people, we have to bring them
> through the deck we present in the BoF, which explains what
> whitespace is, how it works, what the regulatory situation is, and
> what role the database plays.  We need to show some use cases.  We
> were thinking we would put a version of that in the Requirements and
> Framework document, and then have the protocol document just refer to
> it, rather than explain it all again there.

Sounds reasonable to me! By "framework" some folks seem to be thinking
of "technology framework" instead of something more like "problem
statement and use cases".

>>> automated ways to provision the database of protected entities
>>> that allows sharing of data among competing database providers.
>>> That is the origin of the "other mechanisms and protocols" part.
>>> We can recharter to get those in AFTER the database discovery and
>>> query mechanisms are worked out, so I don't have a problem with
>>> deleting that language from the charter now.
>> 
>> Either way. In general it's probably good for us to complete the
>> core work first and then look at extensions or additional methods
>> for accessing the database.
> No problem

Excellent.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Adrian Farrel <[email-masked]>
Date: Tue, 03 May 2011 14:55:20 +0100

Hi Brian,

> I don't want to make a big deal out of this.  I don't think it changes
anything.  I
> point out your concern is true of every protocol effort we start these days.
Yet,
> this language isn't in any charter I've looked at recently.  To cite an
example,
> clue's charter says:

I think you are right to not make a big issue out of this. Recharters can be
quick and painless. They are not to be feared.

As a datapoint, one of our most recently chartered WGs is ARMD
http://datatracker.ietf.org/wg/armd/charter/

Cheers,
Adrian

---

From: Warren Kumari <[email-masked]>
Date: Wed, 4 May 2011 18:01:58 -0400

>> services and unauthorized disclosure of a users location.

My main comment here is on the use of the word "channel" with no real definition. Yes, I know that much / some of the interest from this is the TV whitespace, and that is where the "channel" comes from, but I think that we should actually be discussing frequencies or frequency ranges. I think that this is an important distinction for the chartering discussions to help the WG keep all of the users in mind. 

I have tried to some up with a way to insert something like a definition for a channel (or a way to s/channel/ frequency range/), but all of my attempts ruin the text -- this might be a sign that I'm worrying about nothing...

Other than that I like the charter with the changes -- I'm a little surprised by the explicit "prefer to use existing IETF technologies", but a: have no strong views and b: figure there might be a good reason for is...

W

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 4 May 2011 20:31:49 -0400

How about just "spectrum" instead of "channel"?

Brian

---

From: "Jesse Caulfield" <[email-masked]>
Date: Wed, 4 May 2011 20:49:41 -0400

> My main comment here is on the use of the word "channel" with no real
definition. Yes, I know that much / some of the interest from this is the TV
whitespace, and that is where the "channel" comes from, but I think that we
should actually be discussing frequencies or frequency ranges. I think that
this is an important distinction for the chartering discussions to help the
WG keep all of the users in mind. 

> I have tried to some up with a way to insert something like a definition
for a channel (or a way to s/channel/ frequency range/), but all of my
attempts ruin the text -- this might be a sign that I'm worrying about
nothing...

Agreed. I believe a generalized white space protocol must accommodate the
following at minimum:

 * Multiple frequency bands (e.g. UHF, VHF, S-band, etc.)
 * Variable channel width (e.g. 6 MHz, 8 MHz ...)

For this it seems a reasonable solution to specify either start plus stop
frequencies or center frequency plus channel width. 

"Channel" is an opaque term unless explicitly tied to an objective
definition. For example US TV channels are defined in 47 CFR 73.603. For
internationalization a "channel" number must also reference the regulatory
authority under which a system is operating and which precisely defines the
channel's technical parameters. 
--
Jesse Caulfield, Key Bridge

---

From: Teco Boot <[email-masked]>
Date: Thu, 5 May 2011 08:32:20 +0200

> How about just "spectrum" instead of "channel"?

I prefer channel. We use this term for a (set of) frequency band(s), used for RF communications. Channels are part of the spectrum.

We need to specify used definitions. It is a bit early to discuss this right now.

Teco