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

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 19 Apr 2011 13:50:10 -0400

I think this working group is a good idea.
My inclination would be to place it in the Applications area.  It looks 
like a nice application protocol to me.
There is a reasonable argument for placing it in RAI, as that is where 
the relevant GEOLOC work has been done up till now.

Yours,
Joel M. Halpern

On 4/19/2011 12: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 :
> - 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.
>
> 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
>
> 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
> _______________________________________________
> paws mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/paws
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 19 Apr 2011 14:08:32 -0600

On 4/19/11 1:47 PM, Paul Lambert wrote:
> 
> 
> How does the area that the group is assigned impact the choices of
> technology?
> 
> I'm an advocate for an efficient solution set for PAWS ... it will be
> much like DNS for spectrum in the future and should be viewed as a
> core infrastructural component that needs careful design.  There are
> good reasons that routing protocols don't use XML.
> 
> Applications now days tend to go for the simple, quick to make a web
> application solutions using XML or the like ...  My concern is that
> "Applications" imply that efficiency does not matter.

A quick look at the specifications for the CORE WG in the Applications
Area will show you that we're able to produce protocols that are quite
slim on the wire.

Peter

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

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 19 Apr 2011 22:28:13 +0100

I think this is a good and timely thing for the IETF to do.

One part of this where I think it might be useful to get
some broader input (which may have happened already, I'm not
sure) is the following:

On 19/04/11 17:56, IESG Secretary wrote:
> privacy of users. 

That part is fine but it goes on to say:

> Robust security mechanisms are required to prevent:
> of channel enablement information, ...

I'm told (and believe) this in response to (at least) US
FCC requirements that call for a device ID and sometimes
serial number to be (securely, for some value of securely)
sent with the query.

Those appear to be real regulatory requirements in the
US, presumably so the regulator can stomp on someone who
messes about in the wrong spectrum at the wrong time.
(The link below [1] may be to the right or wrong bit of
those US regulations, I'm not at all sure, not being
from there;-)

So my questions:

Are there may be similar (or conflicting!) requirements
elsewhere?

Does this bit of the charter text need changes to work
well for other regions?

Separately, I'm not sure how to square those kinds of
regulatory requirements with protecting privacy where the
device is carried by a person and has some FCC device ID
(which lots do I guess) and the person might not want
the database operator to know who's asking. But I think
that's ok as something for the WG to figure out since
the charter already calls for respecting privacy.

I'm more concerned in case e.g. some other regional regulation
called for this protocol to be completely anonymous or
something, in which case the current charter text might
be problematic.

Cheers,
Stephen.

[1]
http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfr&sid=3e9c322addf1f7e897d8c84a6c7aca78&rgn=div8&view=text&node=47:1.0.1.1.14.8.243.9&idno=47

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 19 Apr 2011 22:13:13 -0400

Clearly, the discussion about whether the application protocol should be 
XML, plain ASCII/UTF8, binary, or some other encoding needs to take 
place.  But that can take place wherever we place the working group.

There is an argument, which you allude to, which would place this WG in 
the Internet Area as part of "infrastructure."  While that does not 
resonate with me, I do see that there is some merit in that perspective.

I tend to think we need to focus on transactional application experience 
(the apps area) or where we have experience with protocols that need to 
communicate geolocation (RAI).

I would hope, and expect, that the ADs for any area would be receptive 
to a proper evaluation of any candidate protocol and encoding.  (The 
arguments get complex, and it takes care to avoid religious assertions.)

Yours,
Joel

On 4/19/2011 3:47 PM, Paul Lambert wrote:
>
>
> How does the area that the group is assigned impact the choices of technology?
>
> I'm an advocate for an efficient solution set for PAWS ... it will be much like DNS for spectrum in the future and should be viewed as a core infrastructural component that needs careful design.  There are good reasons that routing protocols don't use XML.
>
> Applications now days tend to go for the simple, quick to make a web application solutions using XML or the like ...  My concern is that "Applications" imply that efficiency does not matter.
>
> Paul
>
>
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>> Joel M. Halpern
>> Sent: Tuesday, April 19, 2011 10:50 AM
>> To: [email-masked]
>> Cc: [email-masked]; IETF discussion list
>> Subject: Re: [paws] WG Review: Protocol to Access White Space database
>> (paws)
>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 19 Apr 2011 22:17:42 -0400

Actually, as far as I can tell, there is very little parallel between 
the PAWS problem and SNMP.
SNMP tends to be initiated by the manager, and used to extract 
information from the device in the network, or set information in teh 
device.
This protocol is used by the client.  It extracts basically stable 
information about what frequencies can be used in this geographic region 
at this time.
There is no "network management" going on.  the interaction does not 
look like SNMP.  And the effect does not look like SNMP.  While Radius 
or Diameter are closer, this protocol is not even a policy decision 
protocol.  There is no "policy".

So no, I do not think this looks anything like network management.
The protocols, the transaction drivers and behavior, the problem space, 
and the underlying data behavior are all very different from any of our 
NM work.

Yours,
Joel

On 4/19/2011 5:21 PM, Rex Buddenberg wrote:
> On Tue, 2011-04-19 at 12:47 -0700, Paul Lambert wrote:
>>
> While the DNS analogy works, I was thinking more a parallel -- or
> extension -- of SNMP.
>
> Still remain within 'applications', Joel?
>
>>

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 20 Apr 2011 10:25:57 +0100

>>"Applications" imply that efficiency does not matter.
Absolutely not. There are several counter examples in Apps, both past 
and present. (E.g. Lemonade WG was about optimized use of bandwidth for 
IMAP.)

>Area will show you that we're able to produce protocols that are quite
Exactly.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 20 Apr 2011 07:21:51 -0400

On Tue, Apr 19, 2011 at 10:13:13PM -0400, Joel M. Halpern wrote:

> There is an argument, which you allude to, which would place this WG
> in the Internet Area as part of "infrastructure."  While that does
> not resonate with me, I do see that there is some merit in that
> perspective.

On the other hand (to continue the analogy with the DNS despite
Richard's shuddering), DNS Extensions is also sort of an awkward fit
in the Internet area (perhaps partly because many applications ought
to be able to use DNS data but aren't, and perhaps partly because it
is in fact an application sitting atop all those other things worked
on in the Internet area).

> encoding.  (The arguments get complex, and it takes care to avoid
> religious assertions.)

Indeed -- particularly when history becomes one of those topics of
religious dispute.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 20 Apr 2011 07:55:50 -0700

When I hear the term "device identity spoofing", IEEE 802.1ar comes to mind (see http://standards.ieee.org/getieee802/download/802.1AR.-2009.pdf).  

In addition to the liaisons with IEEE 802.19, 802.22 and IEEE 802.11af, is there a liaison contemplated to IEEE 802.1 relating to "device identity"?

> From: [email-masked]
> To: [email-masked]; [email-masked]
> Subject: RE: [paws] WG Review: Protocol to Access White Space database (paws)
> Date: Wed, 20 Apr 2011 14:41:23 +0000
> CC: [email-masked]; [email-masked]
> 
> Hi Stephen, All,
> 
> I believe the current wording
> is acceptable because "mechanisms are required" means they should be in the protocol, it does not mean they cannot be optional. PAWS should support Regulator requirements globally, and thus I believe there will be procedures or capabilities which are "required" to be in the protocol but will be "optional" during run time. Thus different or conflicting requirements from different regions of the world can be supported. (Several regulatory groups around the world are still developing their views and requirements).
> 
> It's not the time to dig deep into proposed solutions, just my opinion is the current proposed wording is an acceptable definition to allow a Work Group to get started defining the details.
> 
> Regards,
> Scott
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Stephen Farrell
> Sent: Tuesday, April 19, 2011 4:28 PM
> To: IETF-Discussion
> Cc: [email-masked]; [email-masked]
> Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws)
> 
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 20 Apr 2011 11:40:54 -0400

Building from Bernard's note, it strikes me that if we are going to get 
into device identity, we probably need to be communicating with (liaise) 
3GPP/3GPP2, because they have very strong views on that topic.  (Whether 
one agrees or disagrees with their biases, talking to them seems important.)

Yours,
Joel

On 4/20/2011 10:55 AM, Bernard Aboba wrote:
> When I hear the term "device identity spoofing", IEEE 802.1ar comes to
> mind (see http://standards.ieee.org/getieee802/download/802.1AR.-2009.pdf).
>
> In addition to the liaisons with IEEE 802.19, 802.22 and IEEE 802.11af,
> is there a liaison contemplated to IEEE 802.1 relating to "device identity"?
>

---

From: Paul Lambert <[email-masked]>
Date: Tue, 19 Apr 2011 12:47:41 -0700

Paul

---

From: Rex Buddenberg <[email-masked]>
Date: Tue, 19 Apr 2011 14:21:39 -0700

---

From: <[email-masked]>
Date: Wed, 20 Apr 2011 14:41:23 +0000

Hi Stephen, All,

Regards,
Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Stephen Farrell
Sent: Tuesday, April 19, 2011 4:28 PM
To: IETF-Discussion
Cc: [email-masked]; [email-masked]
Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws)

So my questions:

Cheers,
Stephen.

[1]

---

From: "t.petch" <[email-masked]>
Date: Wed, 20 Apr 2011 19:19:26 +0200

----- Original Message -----
From: "Joel M. Halpern" <[email-masked]>
To: "Rex Buddenberg" <[email-masked]>
Cc: "Paul Lambert" <[email-masked]>; <[email-masked]>; <[email-masked]>; "IETF
discussion list" <[email-masked]>
Sent: Wednesday, April 20, 2011 4:17 AM
Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws)

Joel

I see one small parallel with SNMP. All the recent work on SNMP has
been on security, and while setting up a secure channel is easy, TLS or SSH,
knowing that it goes where you want it to as opposed to via a MITM is
more difficult, both when the device calls home to send an alert, or
when home calls the device to solicit information.

And the credentials used by the transport need binding securely to
the identity at a higher layer.  This was troublesome and I will
be interested to see how this is solved.  By comparison  I expect
that the application will fall out in the wash.

Channel binding anyone?  One for the security area?

Tom Petch

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

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 20 Apr 2011 12:23:01 -0600

GEOLOC has been a WG that is somewhat on the edge between Apps and RAI. Much of what geoloc was doing, particularly the location for emergency calling, had real time issues and the interested people largely lined up with the the other RAI groups even though geoloc has uses outside anything to do with SIP. PAWS on the other hand does not seem to have real time application issues so it seems like Apps is probably a more appropriate area for it. 

Cullen

On Apr 19, 2011, at 11:50 AM, Joel M. Halpern wrote:

> My inclination would be to place it in the Applications area.  It looks like a nice application protocol to me.
> There is a reasonable argument for placing it in RAI, as that is where the relevant GEOLOC work has been done up till now.
> 
> Yours,
> Joel M. Halpern
>

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 21 Apr 2011 12:01:23 +0100

> is acceptable because "mechanisms are required" means they should be in the protocol, it does not mean they cannot be optional. PAWS should support Regulator requirements globally, and thus I belie…

Agreed on this point, although I think the charter could make it a little less ambiguous by saying "Development of robust security mechanisms is required . . .," that way it's not indicating that the actual mechanisms themselves will always be required.

Given that device identity will have to be shared in some circumstances, I would also add its protection to the end of the list of mechanisms: 

Development of security mechanisms is 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 user's location and/or device identity.

Alissa

---

From: <[email-masked]>
Date: Thu, 21 Apr 2011 13:05:15 +0000

Hi,

I agree with the concept, just want to be sure the PAWS is not expected to develop these security mechanisms (i.e. the tools) as contrasted to including or using in PAWS the security tools developed by appropriate expert groups.

"Inclusion of robust security mechanisms is required:..."
??

Regards,
Scott

-----Original Message-----
From: ext Alissa Cooper [mailto:[email-masked]] 
Sent: Thursday, April 21, 2011 6:01 AM
To: Probasco Scott (Nokia-CIC/Dallas)
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws)

Alissa

---

From: Glen Zorn <[email-masked]>
Date: Fri, 22 Apr 2011 08:35:27 +0700

> I agree with the concept, just want to be sure the PAWS is not expected to develop these security mechanisms (i.e. the tools) as contrasted to including or using in PAWS the security tools develope…

I agree.