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

[Hannes Tschofenig <[e-mail]>]

Hi David, 

let me share my thoughts with you; see inline: 

On Apr 21, 2011, at 2:18 AM, David Harrington wrote:

> 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 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 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.

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.)

> 
> The proposed charter talks about coordinating with other SDOs and
> regulatory agencies:
>>> 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.
> 
> I disagree with chartering a WG to set up yet-to-be-defined liaisons
> with other SDOs.

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. 

> 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.

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. 
 
> 
> 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.

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

"
Sep 2011  Submit 'Requirements and Framework' to the IESG for
         publication as Informational
"

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


> 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.

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. 

> 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.
> 
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

> David Harrington
> Director, IETF Transport Area
> [e-mail] (preferred for ietf)
> [e-mail]
> [phone] (cell)
> 
> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On 
>> Behalf Of [e-mail]
>> Sent: Tuesday, April 19, 2011 3:55 PM
>> To: [e-mail]; [e-mail]
>> Cc: [e-mail]
>> Subject: Re: [paws] WG Review: Protocol to Access White Space 
>> database (paws)
>> 
>> 
>> 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
>> 
>> On 4/19/11 11:56 AM, "ext IESG Secretary" 
>> <[e-mail]> 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 ([e-mail]) 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: [e-mail]
>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/paws
>> 
>> 
>