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

From: IESG Secretary <[email-masked]>
Date: Tue, 19 Apr 2011 09:56:34 -0700 (PDT)

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

---

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

---

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

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: <[email-masked]>
Date: Tue, 19 Apr 2011 19:55:29 +0000

The IETF has the most relevant expertise to develop a protocol for
accessing white space databases from devices.
Hence forming this WG is essential and will enable white space
technologies to be deployed in many countries that are currently
considering it.

-Basavaraj

---

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:
> 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: Rex Buddenberg <[email-masked]>
Date: Tue, 19 Apr 2011 14:21:39 -0700

> good reasons that routing protocols don't use XML.

While the DNS analogy works, I was thinking more a parallel -- or
extension -- of SNMP.  

Still remain within 'applications', Joel?

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 19 Apr 2011 17:31:06 -0400

Paul the choice of Directorates here is somewhat irrelevant. This work could be successfully done anywhere in the IETF, though APPS is probably the rational choice.  Joel the last thing we need is to clog up RAI any more than it is, though you are right almost all the relevant geolocation stuff will come out of there.

Paul's point is there are two legitimate views of how the WSDB should operate.  You can certainly use the IETF standard tool box of HTTP TLS XML AA etc JSON (maybe) but if you view the world from a chip manufacturer you are looking at cost of implementation of the stack and something that looks more lightweight or binary makes sense.

Given initial time to market issues,  I don’t see that happening at the first pass. 

And as for using DNS like things .. don’t go there.  I've already had my fights with the IAB and IESG on that one.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Saint-Andre
Sent: Tuesday, April 19, 2011 4:09 PM
To: Paul Lambert
Cc: [email-masked]; [email-masked]; IETF discussion list
Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws)

> "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: Paul Lambert <[email-masked]>
Date: Tue, 19 Apr 2011 15:53:52 -0700

> Given initial time to market issues,  I don’t see that happening at the

A poor argument ... XML is actually harder and slower to market for some devices.  There are also very fast-to-market efficient encoding approaches. We should base decisions on agreed requirements versus individual perceptions of implementation schedules.

Paul

> From: Richard Shockey [mailto:[email-masked]]
> Sent: Tuesday, April 19, 2011 2:31 PM
> To: 'Peter Saint-Andre'; Paul Lambert
> Cc: [email-masked]; [email-masked]
> Subject: RE: [paws] WG Review: Protocol to Access White Space database
> (paws)
> 
> Paul the choice of Directorates here is somewhat irrelevant. This work
> could be successfully done anywhere in the IETF, though APPS is
> probably the rational choice.  Joel the last thing we need is to clog
> up RAI any more than it is, though you are right almost all the
> relevant geolocation stuff will come out of there.
> 
> Paul's point is there are two legitimate views of how the WSDB should
> operate.  You can certainly use the IETF standard tool box of HTTP TLS
> XML AA etc JSON (maybe) but if you view the world from a chip
> manufacturer you are looking at cost of implementation of the stack and
> something that looks more lightweight or binary makes sense.
> 
> And as for using DNS like things .. don’t go there.  I've already had
> my fights with the IAB and IESG on that one.
>

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 19 Apr 2011 20:25:12 -0400

Well we certainly hope to see your input to the requirements. I deeply respect your views here.

Paul

---

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

---

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

---

From: <[email-masked]>
Date: Wed, 20 Apr 2011 03:00:30 +0000

I believe we are rushing to conclusions about what the actual protocol itself will be.
Right now the only discussion is about the proposed charter and scope. A case of putting the cart before the horse.

-Basavaraj

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Paul Lambert
Sent: Tuesday, April 19, 2011 5:54 PM
To: Richard Shockey; 'Peter Saint-Andre'
Cc: [email-masked]; [email-masked]
Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws)

Paul

---

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: <[email-masked]>
Date: Wed, 20 Apr 2011 14:41:23 +0000

Hi Stephen, All,

I believe the current wording
>> of channel enablement information, ...
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

-----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: 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: 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,
>

---

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: "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: "David Harrington" <[email-masked]>
Date: Wed, 20 Apr 2011 19:18:43 -0400

Hi,

I question whether IETF is the appropriate forum for this work.
The IETF certainly has protocol-development expertise, especially for
interoperability.

The proposed work has a stated requirement of being available via the
Internet.
The IETF certainly has expertise in applications that run over the
Internet.
PAWS appears to be a proposed application to coordinate secondary use
of spectrum.
If it is done in the IETF, I agree this is applications area work.

I do think there are lessons from the IETF NM protocol designs that
could be applied.
I think the IETF approach of separating the schema language, the
schema, and protocol would benefit the PAWS work.

One of my concerns is that the IETF is not the forum for the content
of this work - secondary use of spectrum.
There are multiple other SDOs that are the forum (forae, fori?) for
spectrum work.
The SDOs that handle primary use of spectrum would seem the logical
place to coordinate secrondary use of spectrum.
A lot of that work seems political, since it has to do with
coordinating country-specific policies and regulations.
The IETF is not a good forum for politically-embroiled work.

The proposed charter talks about coordinating with other SDOs and
> >specification of the rules for secondary use of spectrum in
specific

I disagree with chartering a WG to set up yet-to-be-defined liaisons
with other SDOs.
The IETF community already has a process for inter-SDO liaison
management, handled via the IAB.
If individuals from other SDOs want to be involved in IETF WG work,
they are welcome to join our open process.
But "official" input from other SDOs or regulatory bodies should have
no special weight in the IETF process.
Many other SDOs and regulatory bodies fail to understand the IETF
individual-contribution philosophy.
Inter-SDO communication can be tremendously time-consuming and
contentious due to different working philosophies.
The IAB considers the benefits of a liaison relationship carefully
before approving such a relationship.
I consider it critical that official liaison relationships be
established/overseen by the IAB, not individual WGs.

I think the charter does not reflect a clear understanding of the
***engineering*** requirements for a PAWS solution.
Chartering the WG to standardize a query protocol and data model,
without first clearly understanding the requirements, strikes me as a
bad approach.
Chartering the WG to standardize a query protocol and data model,
without first clearly separating engineering requirements from
potential political/regulatory debate, strikes me as a VERY bad idea.
I would be more willing to approve a charter to develop the
requirements and framework documents, to demonstrate that there is a
clear consensus on the engineering requirements for PAWS, and then
require recharter to develop the resulting protocol standards.

David Harrington
Director, IETF Transport Area
[email-masked] (preferred for ietf)
[email-masked]
+1 603 828 1401 (cell)

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Tuesday, April 19, 2011 3:55 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]

---

From: <[email-masked]>
Date: Thu, 21 Apr 2011 03:58:29 +0000

I really don't understand the premises for your comments. Did you attend the PAWS BoF?
Have you read the I-Ds? I am amazed at your response and questioning whether the IETF is the right forum for this work.

The work being done by the proposed PAWS WG is a component of how spectrum is used for secondary purposes.
It is a protocol that runs over IP between a device and the white space databases.
There are other SDOs such as IEEE defining the Phy/MAC for example and there are regulatory bodies defining how spectrum is used in the context of cognitive radio technologies. But that does not imply the IETF has no role here.

You state: " I think the charter does not reflect a clear understanding of the
***engineering*** requirements for a PAWS solution."

The people involved in the PAWS proposal have a fairly good idea of the problem statement and scope.
Can you please explain what aspect of the charter is not clear?
If a WG is formed the solution will be developed based on discussion within that WG. Suffice it to say that the people interested in this proposal have wider experience of WS technology and understanding resulting from participation and involvement in other forums and SDOs.

Rgds,
-Basavaraj

-----Original Message-----
From: ext David Harrington [mailto:[email-masked]] 
Sent: Wednesday, April 20, 2011 6:19 PM
To: Patil Basavaraj (Nokia-CTO/Dallas); [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [paws] WG Review: Protocol to Access White Space database (paws)

Hi,

David Harrington

---

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: Hannes Tschofenig <[email-masked]>
Date: Thu, 21 Apr 2011 10:36:04 +0300

Hi David, 

let me share my thoughts with you; see inline: 

> There are multiple other SDOs that are the forum (forae, fori?) for

The IETF in this case is about finding out what spectrum is available in a given location. 
This is conceptually very similar to finding out what emergency services are available in a given location. 

The work that happens elsewhere on spectrum regulation is very different. It is not about protocol work but rather negotiating about which spectrum will be given to whom.
This is quite a different aspect!

> The IETF is not a good forum for politically-embroiled work.

Which topic does not have a political angle? 
Just a few things come to my mind: internationalization, email security, routing security/RPKI, Do Not Track headers, location privacy, Web security, identity management, etc. 
In fact, the entire IETF security work is highly relevant for the "cyber security" debates happening everywhere in the world. 
(If you do a s/cyber security/Internet security then this relationship is more obvious.)

> I disagree with chartering a WG to set up yet-to-be-defined liaisons

It is not uncommon for groups to indicate the need to interact with other SDOs. 
In fact, this is done frequently. 

Just to give you a few example: 

The recently announced rtcweb working group charter text even talks about a very close cooperation between the IETF and the W3C.

The Web security working group chartered last summer also says: 
"
This working group will work closely with IETF Apps Area WGs (such as
HYBI, HTTPstate, and HTTPbis), as well as appropriate W3C working
group(s) (e.g. HTML, WebApps).
"

In fact when the Web security working group was established it was envisioned that the W3C is going to create a similar working group as well to work on supporting technology. 

A final example: When Jon and myself worked on the formation of the ECRIT working group we already had envisioned that there will be many other SDOs to work with. 
As SDOs came along we started interacting with them. If you look at the ECRIT charter text you will find the following paragraph: 

"
While this group anticipates a close working relationship with groups
such as NENA and ETSI EMTEL, any solution presented must be useful
regardless of jurisdiction, and it must be possible to use without a
single, central authority.
"

We even organized a series of emergency services standardization coordination workshops to ensure that everyone is aware of the work going on. 
The last one of these workshops actually happened last week in Budapest with 250 people attending!  

The reason why this liaison need is mentioned on the paws charter text writeup is also because a few of us from the IAB / IESG saw the need to point out that this group needs to reach out to other SDOs. 
I still believe it is important to be explicit about this interaction. 

> established/overseen by the IAB, not individual WGs.

My reading of the charter does not give me any impression about an unusual activity. 
The IAB has liaisons shepherds appointed with the IEEE already. 
We maintain a good relationship with the IEEE and this interaction, I believe, will be smooth. 
 
> without first clearly understanding the requirements, strikes me as a

If you look at the milestones then you will find an item that talks about requirements and framework:

"
"

It is also not uncommon for a group to start collecting requirements first and then to develop a technical solution. 

> potential political/regulatory debate, strikes me as a VERY bad idea.

As I argued previously you can find political / regulatory debates in almost every work area we are dealing with in the IETF.

Just to give you another example: The httpstate WG is working on documenting how cookies are used. Cookies are clearly have a regulatory angle. 
You may have heard about the European Commission eCookie directive, which is currently transposed into national law by the European member states. There is also the preliminary FTC privacy report that advocates the "Do Not Track" concept. This FTC report has triggered a couple of technical activities by browser vendors and there will be a workshop next week in Princeton to discuss the broader picture. The httpstate group is also thinking about how cookies could be used more securely and more privacy friendly. There are actual ideas floating around in the IETF.  

Maybe something we can observe is that the increasing attention from the regulatory community in the Internet is an indication of Internet evolving into an infrastructure that is very important for the overall economy. Not a big surprise that politicians and regulators find this topic of interest. 

> require recharter to develop the resulting protocol standards.
Quite practically speaking: In the design of technology protocol engineers take a lot of different factors into consideration.
Some of them are purely technical (like performance characteristics) but there are also aspects that concern the responsibilities of the different parties involved (like who is supposed to be implementing and deploying the entire solution). 
There are also aspects to consider like the human-machine interface (and issue we learned in a painful way in the area of security) or how the larger industry environment looks like (because there is more than just SDOs working group members and chairs need to be aware of). 
In this specific case, the regular had decided that they want to make information about what free spectrum is available at which specific location. This has created the need for a standardized protocol in the first place. 

So, what could be the worst case that this group produces? 
- A protocol that does not work? 
- Does not consider all requirements and then cannot be used? 

I am happy to talk to you in more detail about about cases of IETF protocol work where I see relationships to regulatory efforts in case you need more evidence that this sort of interaction is actually quite common and IMHO will be more common in the future. 

Ciao
Hannes

---

From: Paul Lambert <[email-masked]>
Date: Thu, 21 Apr 2011 11:33:04 -0700

> place to coordinate secrondary use of spectrum.

The IETF is an appropriate forum for the development of protocols for the described charter.  We must work to ensure that devices using spectrum can be made to meet international regulations with common signaling mechanisms (like PAWS).  How is this different from Wi-Fi or GSM where spectrum varies between regulatory domains, but there are common protocols?

One could view these protocols as Digital Right Management (DRM) for spectrum: 
 - PAWS provides protocols for determining a devices spectral rights within a regulatory domain 
 - Regulatory domains run the databases with PAWS interface that distribute and control these rights
    (effectively the content provider)

> The IETF is not a good forum for politically-embroiled work.

Country specific policies and procedures do NOT need to be defined by the working group - only identified.  Manufactures will still have the burden to build devices that are compliant with regulations.  We just need to provide the means to determine the named policies and associated available spectrum.  

Paul

Paul A. Lambert |  Marvell  | +1 650 787 9141

> Sent: Wednesday, April 20, 2011 4:19 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 22 Apr 2011 13:35:16 +0100

>     (effectively the content provider)

DRM? Yuk.

That's a really good way to turn people off what should be an
enabling protocol (paws making it possible to use other spectrum).
DRM is clearly a *dis*abling thing.

If the putative paws wg takes the approach that the user is the
adversary and that the purpose of the system is to control what
the user is able to do then I may need to revise my opinion of
this.

If, OTOH, the putative wg aim to develop a protocol that offers
publicly available information in an efficient and useful and
privacy sensitive manner, with optional additional fields that
are sometimes necessary for local regulatory reasons then that'd
be much better.

I had assumed we were talking about the latter, and hope this
was just a bad analogy but can we confirm that?

S.

---

From: Teco Boot <[email-masked]>
Date: Fri, 22 Apr 2011 14:53:32 +0200

The protocol may provide the knob for an authority to limit usage.
For sure IETF is not the authority. It *en*ables spectrum users 
and authorized bodies to make smart usage of possibilities. It helps
to make the Internet work better.

Thanks, Teco

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 22 Apr 2011 14:14:19 +0100

> The protocol may provide the knob for an authority to limit usage.

Ok now I'm getting more confused. Are you saying the paws protocol
will have some way of telling a user "turn off your 700MHz radio"
or something?

I understood that this protocol would provide the information as
to what's allowed but that any enforcement would be out of scope
for the protocol.

S.

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 22 Apr 2011 09:58:59 -0400

Going off the deep end folks.

All paws does is evaluate interference between existing users and new users, and tells new users which parts of a designated band is available for their use, i.e. non interfering.  While the algorithm the server uses to determine the available spectrum is regulator-specified, the protocol used to get the available spectrum is not.  That's the part paws is working on.

There is no right, it's just avoiding interference.

Brian

---

From: <[email-masked]>
Date: Fri, 22 Apr 2011 14:01:59 +0000

Hi,

The local or regional Regulator (Ofcom in the UK, Ficora in Finland, FCC in the U.S., etc...) are the authority to determine how spectrum may be used in their jurisdiction.

The contents of the database are applicable for a specific region, and are determined by the local regulation, i.e. the decisions made by the local Regulator. PAWS is simply a tool to enable a standardized means for devices to interact with a database. 

Enforcement does not enter into the PAWS picture. Local Regulators make the rules, compliant devices (i.e. the device which include the radio transmitter) will self-enforce the rules by using the information received from the database. PAWS merely is the standard communication mechanism between the device and database.

Regards,
Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Stephen Farrell
Sent: Friday, April 22, 2011 8:14 AM
To: Teco Boot
Cc: [email-masked]; David Harrington; [email-masked]; [email-masked]
Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws)

S.

---

From: Teco Boot <[email-masked]>
Date: Fri, 22 Apr 2011 16:03:15 +0200

> will have some way of telling a user "turn off your 700MHz radio"
The protocol provides some way to tell what frequency can be used on a 
particular location. 700MHz could not be listed. 

> to what's allowed but that any enforcement would be out of scope
Correct.

Teco

---

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.

---

From: Paul Lambert <[email-masked]>
Date: Fri, 22 Apr 2011 10:48:25 -0700

> [email-masked]
...
> 
> Hi,
> 
> The local or regional Regulator (Ofcom in the UK, Ficora in Finland,
> FCC in the U.S., etc...) are the authority to determine how spectrum
> may be used in their jurisdiction.
> 
> The contents of the database are applicable for a specific region, and
> are determined by the local regulation, i.e. the decisions made by the
> local Regulator. PAWS is simply a tool to enable a standardized means
> for devices to interact with a database.
> 
> Enforcement does not enter into the PAWS picture. Local Regulators make
> the rules, compliant devices (i.e. the device which include the radio
> transmitter) will self-enforce the rules by using the information
> received from the database. PAWS merely is the standard communication
> mechanism between the device and database.

Close, but not quite ... for the FCC, enforcement is in several parts:
1) all devices must be certified for operation in the given band (in this case TVWS)
   and are issues a registered model type and have a unique associated serial number.
   The regulatory authorities 
2) The databases provide a specific named device with "available spectrum" 
   within the white space band for the devices location for a time period"
   (e.g. ["TVWS","now till tomorrow",["Channel 33", "Channel 34", ... ] )
3) The database enforces blacklists of "model types" and "model type/serial number"
   tuples and can disable any single device or class of devices

PAWS must carry sufficient information to support regulatory blacklists.  

Paul

> ext Stephen Farrell

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 22 Apr 2011 15:29:03 -0400

I think we are all in agreement here. How the data is implemented through
localized policy is clearly out of scope. That is a national regulatory
issue.  

We're only talking about the "on the airwaves" issue of what has to be
passed between the device and the WSDB. 

Close, but not quite ... for the FCC, enforcement is in several parts:
1) all devices must be certified for operation in the given band (in this
case TVWS)
   and are issues a registered model type and have a unique associated
serial number.
   The regulatory authorities 
2) The databases provide a specific named device with "available spectrum" 
   within the white space band for the devices location for a time period"
   (e.g. ["TVWS","now till tomorrow",["Channel 33", "Channel 34", ... ] )
3) The database enforces blacklists of "model types" and "model type/serial
number"
   tuples and can disable any single device or class of devices

Paul

---

From: Paul Lambert <[email-masked]>
Date: Fri, 22 Apr 2011 14:56:38 -0700

I also dislike the DRM comparison .. but introduced because it is appropriate for our problem domain.  The regulatory authorities "own" the spectrum and provide licenses for it's use.  We are not providing coordination for an ISM (unlicensed) band - we are ng on legal access to controlled spectrum.  The query response is in effect a short term license to use a specific channel set in a particular manner (power, modulation) in a particular region.

PAWS and geolocation databases for spectral allocation are "enabling" because they provide additional licenses to use spectrum beyond just the incumbents (e.g. TV broadcasting).  More licenses and usage are a good thing ... but are still regulatory authority controlled.  

Paul

> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Friday, April 22, 2011 5:35 AM
> To: Paul Lambert
> Cc: David Harrington; [email-masked]; [email-masked]; ietf-
> [email-masked]; [email-masked]

---

From: Paul Lambert <[email-masked]>
Date: Fri, 22 Apr 2011 17:41:56 -0700

>> There is no right, it's just avoiding interference.

And checking that the devices model-type is "ok" and that the serial number is not black-listed.

Paul

> From: Rosen, Brian [mailto:[email-masked]]
> Sent: Friday, April 22, 2011 6:59 AM
> To: Stephen Farrell
> Cc: Paul Lambert; [email-masked]; David Harrington; [email-masked]; ietf-
> [email-masked]
> All paws does is evaluate interference between existing users and new
> users, and tells new users which parts of a designated band is
> available for their use, i.e. non interfering.  While the algorithm the
> server uses to determine the available spectrum is regulator-specified,
> the protocol used to get the available spectrum is not.  That's the
> part paws is working on.
>