From dromasca@avaya.com Fri Apr 1 00:32:20 2011 Return-Path: X-Original-To: paws@core3.amsl.com Delivered-To: paws@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FE373A6A87 for ; Fri, 1 Apr 2011 00:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.177 X-Spam-Level: X-Spam-Status: No, score=-103.177 tagged_above=-999 required=5 tests=[AWL=0.421, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLzJaiG+kyLp for ; Fri, 1 Apr 2011 00:32:11 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id E018C3A6BD7 for ; Fri, 1 Apr 2011 00:32:10 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYAAFMtcU2HCzI1/2dsb2JhbACCT5Vbjjt0pHkCmRaCfoJjBJAM X-IronPort-AV: E=Sophos;i="4.63,281,1299474000"; d="scan'208,217";a="272510116" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 01 Apr 2011 03:33:50 -0400 X-IronPort-AV: E=Sophos;i="4.63,281,1299474000"; d="scan'208,217";a="633868139" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 01 Apr 2011 03:33:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBF03F.24080BAB" Date: Fri, 1 Apr 2011 09:33:47 +0200 Message-ID: In-Reply-To: <7DDB35B005136A4DB9FF33E7E286EF00066340@008-AM1MPN1-037.mgdnok.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [paws] updated charter proposal Thread-Index: Acvpp7RYjKt+gGFGREWtx/nICrQjPAGlqm/w References: <7DDB35B005136A4DB9FF33E7E286EF00066340@008-AM1MPN1-037.mgdnok.nokia.com> From: "Romascanu, Dan (Dan)" To: , Subject: Re: [paws] updated charter proposal X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 07:32:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBF03F.24080BAB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 Hi, I reported in the IESG and IAB meeting this morning about the PAWS BOF, which in my opinion went quite well. My recommendation to continue the process with the chartering of a PAWS WG was well received. The WG (if approved after the review process) will be in the OPS area with a Technical Advisor from APPS.=20 The first step in the review process is internal review of the charter with the IESG and the IAB, which will result into discussion in the IESG telechat on 4/14 and then sending of the charter to external (all IETF review).=20 =20 Question - is this charter text OK for the internal review, or are there any text changes following the BOF?=20 Thanks and Regards, Dan =20 ________________________________ From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com Sent: Thursday, March 24, 2011 12:24 AM To: paws@ietf.org Subject: [paws] updated charter proposal =09 =09 Folks, =20 Here's an updated charter proposal. =20 But please read these two drafts before you come to the BOF: =20 I-D: Protocol to Access White Space database: Problem statement and Requirements http://www.ietf.org/id/draft-patil-paws-problem-stmt-00.txt =20 I-D: Protocol to Access White Space database: Overview and Use case scenarios =09 http://www.ietf.org/id/draft-probasco-paws-overview-usecases-00.txt =20 =20 =20 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. =09 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. =09 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. =09 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. =09 Since the location of a user device is involved, privacy implications arise, and the protocol will have to have robust security mechanisms. 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. =09 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. =09 Milestones =09 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 =09 =20 ------_=_NextPart_001_01CBF03F.24080BAB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
 

Hi,

I reported in the IESG = and IAB=20 meeting this morning about the PAWS BOF, which in my opinion went quite = well. My=20 recommendation to continue the process with the chartering of = a PAWS WG was=20 well received. The WG (if approved after the review process) will be in = the OPS=20 area with a Technical Advisor from APPS. =

The first step in the review process is internal review of = the=20 charter with the IESG and the IAB, which will result into discussion in = the IESG=20 telechat on 4/14 and then sending of the charter to external (all IETF = review).=20
 
Question - is this charter text OK for the internal review, = or are=20 there any text changes following the BOF?

Thanks and = Regards,

Dan
 

From: paws-bounces@ietf.org=20 [mailto:paws-bounces@ietf.org] On Behalf Of=20 Gabor.Bajko@nokia.com
Sent: Thursday, March 24, 2011 = 12:24=20 AM
To: paws@ietf.org
Subject: [paws] updated = charter=20 proposal

Folks,

 

Here’s an updated charter = proposal.

 

But please read these two drafts before you come to = the=20 BOF:

 

I-D: Protocol to Access White Space database: = Problem=20 statement and Requirements

http= ://www.ietf.org/id/draft-patil-paws-problem-stmt-00.txt  

I-D: Protocol to Access White Space database: = Overview and Use=20 case scenarios

http://www.ietf.org/id/draft-probasco-paws-overview-usecases-00.txt

 

 

 

Governments around the world continue to search = for new=20 pieces of radio spectrum which can be used by the expanding wireless=20 communications industry to provide more services in the usable = spectrum. =20 The concept of allowing secondary transmissions (licensed or = unlicensed) in=20 frequencies allocated to a primary user is a technique to "unlock" = existing=20 spectrum for new use. An obvious requirement is that these secondary=20 transmissions do not interfere with the primary use of the spectrum. = Often, in=20 a given physical location, the primary user(s) may not be using the = entire=20 band allocated to them.  The available spectrum for a secondary = use would=20 then depend on the location of the secondary user.  The primary = user may=20 have a schedule when it uses the spectrum, which may be available for=20 secondary use outside that schedule.  The fundamental issue is = how to=20 determine for a specific location and specific time, if any of the = primary=20 spectrum is available for secondary use. One simple mechanism is to = use a=20 geospatial database that records protected contours for primary users, = and=20 require the secondary users to check the database prior to selecting = what part=20 of the spectrum they use.  Such databases could be available on = the=20 Internet for query by users.

In a typical implementation of geolocation and = database to=20 access TV white space, a radio is configured with, or has the = capability to=20 determine its location in latitude and longitude.   At = power-on,=20 before the device can transmit or use any of the spectrum set aside = for=20 secondary use, the device must identify the relevant database to = query,=20 contact the database, provide its geolocation and receive in return a = list=20 of  unoccupied or "white space" spectrum (for example, in a TV = White=20 space implementation, the list of available channels at that = location). The=20 device can then select one of the channels from the list and begin to = transmit=20 and receive on the selected channel. The device must query the = database=20 subsequently on a periodic basis for a list of unoccupied channels = based on=20 certain conditions, e.g. a fixed amount of time has passed or the = device has=20 changed location beyond a specified threshold.

The databases are expected to be reachable via = the Internet=20 and the devices querying these databases are expected to have some = form of=20 Internet connectivity, directly or indirectly. The databases  may = be=20 country specific since the available spectrum and  regulations = may vary,=20 but the fundamental operation of the protocol should be country = independent,=20 thus extensibility of data structures will be required. The solution = will not=20 be tied to any specific spectrum, country, or phy/mac/air interface = but may=20 incorporate relevant aspects of these as needed for proper=20 operation.

The proposed working group will :

    - standardize a protocol for = querying=20 the database, which includes a location sensitive database discovery = mechanism=20 and security for  the protocol, and application = services.

    - Standardize the data = structure to be=20 carried by the query protocol.

Since the location of a user device is involved, = privacy=20 implications arise, and the protocol will have to have robust security = mechanisms.

Existing IETF location data structures and = privacy=20 mechanisms may be considered for use. The WG will also investigate the = need=20 for other mechanisms and related protocols to the White Space=20 DB.

The Working Group will set up and maintain = appropriate=20 contact and liaison with other relevant standards bodies and groups, = including=20 IEEE 802.11af and IEEE 802.22 to begin with. The working group may = also=20 consider input from regulatory entities that are involved in the = specification=20 of the rules for secondary use of spectrum in specific = bands.

Milestones

Sep = 2011        Submit=20 'Requirements and Framework' to the IESG for

      publication as=20 Informational

Apr = 2012        Submit=20 'Protocol for Querying a Whitespace Database'

      to the IESG for = publication=20 as Proposed Standard

Apr = 2012        Submit=20 'Data Model for Whitespace query protocol'

      to the IESG for = publication=20 as Proposed Standard

 

------_=_NextPart_001_01CBF03F.24080BAB-- From brian.rosen@neustar.biz Fri Apr 1 00:46:30 2011 Return-Path: X-Original-To: paws@core3.amsl.com Delivered-To: paws@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADD333A6BEC for ; Fri, 1 Apr 2011 00:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.084 X-Spam-Level: X-Spam-Status: No, score=-6.084 tagged_above=-999 required=5 tests=[AWL=0.514, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvnsf+rwNcgF for ; Fri, 1 Apr 2011 00:46:29 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by core3.amsl.com (Postfix) with ESMTP id 935D03A6AF8 for ; Fri, 1 Apr 2011 00:46:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1301644082; x=1616990268; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=8MLYUTGmOERhr+zSIrLZdOAL0eylhSUvS+P9Lefgxkk=; b=EbxR649K8wEg1z3GpEGLrjIdFPbqEN2Fx+iTrfLeUnaxCEcwsFrYWhCKDKitIa nvBCukDGtKN9KZIlJWCtRI8Q== Received: from ([10.31.13.242]) by chihiron2.nc.neustar.com with ESMTP with TLS id 5202415.36082925; Fri, 01 Apr 2011 03:48:01 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Fri, 1 Apr 2011 03:48:00 -0400 From: "Rosen, Brian" To: "Romascanu, Dan (Dan)" Date: Fri, 1 Apr 2011 03:47:56 -0400 Thread-Topic: [paws] updated charter proposal Thread-Index: AcvwQR8QuXK+f4/wSduRG7kOtNEtxA== Message-ID: References: <7DDB35B005136A4DB9FF33E7E286EF00066340@008-AM1MPN1-037.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 3O2IEJV9rN548+GszC3umw== Content-Type: multipart/alternative; boundary="_000_BFBD51869C2D4F10A65084A3FD64D289neustarbiz_" MIME-Version: 1.0 Cc: "Gabor.Bajko@nokia.com \(Nokia-CIC/SiliconValley\)" , "paws@ietf.org" , "Polk, William T." Subject: Re: [paws] updated charter proposal X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 07:46:30 -0000 --_000_BFBD51869C2D4F10A65084A3FD64D289neustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Good news! There were charter changes requested in the BoF in the security= section. I suggest that the line in the charter: Since the location of a user device is involved, privacy implications arise= , and the protocol will have to have robust security mechanisms. Be changed to: Since the location of a user device is involved, privacy implications arise= , and the protocol will have to have robust security and privacy mechanisms= . There are other security concerns, including spoofing and man in the mid= dle attacks that will require analysis and mechanisms for mitigation in the= protocol. Brian On Apr 1, 2011, at 9:33 AM, Romascanu, Dan (Dan) wrote: Hi, I reported in the IESG and IAB meeting this morning about the PAWS BOF, whi= ch in my opinion went quite well. My recommendation to continue the process= with the chartering of a PAWS WG was well received. The WG (if approved af= ter the review process) will be in the OPS area with a Technical Advisor fr= om APPS. The first step in the review process is internal review of the charter with= the IESG and the IAB, which will result into discussion in the IESG telech= at on 4/14 and then sending of the charter to external (all IETF review). Question - is this charter text OK for the internal review, or are there an= y text changes following the BOF? Thanks and Regards, Dan ________________________________ From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com Sent: Thursday, March 24, 2011 12:24 AM To: paws@ietf.org Subject: [paws] updated charter proposal Folks, Here=92s an updated charter proposal. But please read these two drafts before you come to the BOF: I-D: Protocol to Access White Space database: Problem statement and Require= ments http://www.ietf.org/id/draft-patil-paws-problem-stmt-00.txt I-D: Protocol to Access White Space database: Overview and Use case scenari= os http://www.ietf.org/id/draft-probasco-paws-overview-usecases-00.txt Governments around the world continue to search for new pieces of radio spe= ctrum which can be used by the expanding wireless communications industry t= o provide more services in the usable spectrum. The concept of allowing se= condary 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. T= he 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 schedul= e. The fundamental issue is how to determine for a specific location and s= pecific time, if any of the primary spectrum is available for secondary use= . One simple mechanism is to use a geospatial database that records protect= ed contours for primary users, and require the secondary users to check the= database prior to selecting what part of the spectrum they use. Such data= bases 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 l= ocation in latitude and longitude. At power-on, before the device can tra= nsmit or use any of the spectrum set aside for secondary use, the device mu= st identify the relevant database to query, contact the database, provide i= ts geolocation and receive in return a list of unoccupied or "white space"= spectrum (for example, in a TV White space implementation, the list of ava= ilable channels at that location). The device can then select one of the ch= annels from the list and begin to transmit and receive on the selected chan= nel. The device must query the database subsequently on a periodic basis fo= r a list of unoccupied channels based on certain conditions, e.g. a fixed a= mount of time has passed or the device has changed location beyond a specif= ied 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 connec= tivity, directly or indirectly. The databases may be country specific sinc= e the available spectrum and regulations may vary, but the fundamental ope= ration of the protocol should be country independent, thus extensibility of= data structures will be required. The solution will not be tied to any spe= cific spectrum, country, or phy/mac/air interface but may incorporate relev= ant aspects of these as needed for proper operation. The proposed working group will : - standardize a protocol for querying the database, which includes a lo= cation sensitive database discovery mechanism and security for the protoco= l, and application services. - Standardize the data structure to be carried by the query protocol. Since the location of a user device is involved, privacy implications arise= , and the protocol will have to have robust security mechanisms. Existing IETF location data structures and privacy mechanisms may be consid= ered for use. The WG will also investigate the need for other mechanisms an= d 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 an= d 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 fo= r secondary use of spectrum in specific bands. 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 --_000_BFBD51869C2D4F10A65084A3FD64D289neustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Since the location of a user device is invo= lved, privacy implications arise, and the protocol will have to have robust= security mechanisms.

Be changed to:
<= span class=3D"Apple-style-span" style=3D"font-size: 15px;">Since the locati= on of a user device is involved, privacy implications arise, and the protoc= ol will have to have robust security and privacy mechanisms.  There ar= e other security concerns, including spoofing and man in the middle attacks= that will require analysis and mechanisms for mitigation in the protocol.<= /span>

Brian

On Apr 1, 20= 11, at 9:33 AM, Romascanu, Dan (Dan) wrote:

=
 
<= div> 

Hi,

I reported in the IESG an= d IAB meeting this morning about the PAWS BOF, which in my opinion went qui= te well. My recommendation to continue the process with the chartering of a=  PAWS WG was well received. The WG (if approved after the review proce= ss) will be in the OPS area with a Technical Advisor from APPS.

The first step in the review proce= ss is internal review of the charter with the IESG and the IAB, which will = result into discussion in the IESG telechat on 4/14 and then sending of the= charter to external (all IETF review).
 
Question = - is this charter text OK for the internal review, or are there any text ch= anges following the BOF? =

Thanks and Reg= ards,

Dan
 

From:=  paws-b= ounces@ietf.org [mail= to:paws-bounces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com
Sent: Thursday, March 24, 2011 12:24 AM
To:<= /b> paws@ietf.o= rg
Subject: [paws] updated charter proposal

Folks,
 
Here=92s an updated ch= arter proposal.
 
=
But please read these two drafts before you come to the= BOF:
 
I-D: Protocol to Access White Space database: Problem statement a= nd Requirements=
 
I-D: Protoco= l to Access White Space database: Overview and Use case scenarios
 
 
 
Governments around the world co= ntinue 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 (lic= ensed or unlicensed) in frequencies allocated to a primary user is a techni= que to "unlock" existing spectrum for new use. An obvious requirement is th= at these secondary transmissions do not interfere with the primary use of t= he spectrum. Often, in a given physical location, the primary user(s) may n= ot be using the entire band allocated to them.  The available spectrum= for a secondary use would then depend on the location of the secondary use= r.  The primary user may have a schedule when it uses the spectrum, wh= ich may be available for secondary use outside that schedule.  The fun= damental issue is how to determine for a specific location and specific tim= e, if any of the primary spectrum is available for secondary use. One simpl= e mechanism is to use a geospatial database that records protected contours= for primary users, and require the secondary users to check the database p= rior 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 locati= on in latitude and longitude.   At power-on, before the device ca= n transmit or use any of the spectrum set aside for secondary use, the devi= ce must identify the relevant database to query, contact the database, prov= ide its geolocation and receive in return a list of  unoccupied or "wh= ite space" spectrum (for example, in a TV White space implementation, the l= ist 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 sel= ected channel. The device must query the database subsequently on a periodi= c 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 beyon= d a specified threshold.
The databases are expected to be re= achable via the Internet and the devices querying these databases are expec= ted to have some form of Internet connectivity, directly or indirectly. The= databases  may be country specific since the available spectrum and&n= bsp; regulations may vary, but the fundamental operation of the protocol sh= ould 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 n= eeded for proper operation.
The proposed working group will = :
    - standardize a protocol for querying the datab= ase, which includes a location sensitive database discovery mechanism and s= ecurity for  the protocol, and application services.
<= div style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0pt; margin= -left: 0in; font-family: Calibri, sans-serif; font-size: 11pt; "> &nbs= p;  - Standardize the data structure to be carried by the query protoc= ol.
Since the location of a user device is involved, privacy= implications arise, and the protocol will have to have robust security mec= hanisms.
Existing IETF location data structures and privacy mechanis= ms may be considered for use. The WG will also investigate the need for oth= er mechanisms and related protocols to the White Space DB.
=
T= he Working Group will set up and maintain appropriate contact and liaison w= ith 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.
Milestones
Sep 2011        Submit 'Requ= irements and Framework' to the IESG for
    &nbs= p; publication as Informational
Apr 2012    &nbs= p;   Submit 'Protocol for Querying a Whitespace Database'
=       to the IESG for publication as Proposed Stan= dard
Apr 2012        Submit 'Data= Model for Whitespace query protocol'
     = to the IESG for publication as Proposed Standard
<= div style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0pt; margin= -left: 0in; font-family: Calibri, sans-serif; font-size: 11pt; "> = ;
<ATT00001..txt>

= --_000_BFBD51869C2D4F10A65084A3FD64D289neustarbiz_-- From Gabor.Bajko@nokia.com Fri Apr 1 01:54:47 2011 Return-Path: X-Original-To: paws@core3.amsl.com Delivered-To: paws@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AE363A677C for ; Fri, 1 Apr 2011 01:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDbyI1HwTmy1 for ; Fri, 1 Apr 2011 01:54:46 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by core3.amsl.com (Postfix) with ESMTP id 10E843A63D2 for ; Fri, 1 Apr 2011 01:54:45 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p318uOOo002850 for ; Fri, 1 Apr 2011 11:56:25 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Apr 2011 11:56:18 +0300 Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 1 Apr 2011 10:56:18 +0200 Received: from 008-AM1MPN1-037.mgdnok.nokia.com ([169.254.7.42]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0270.002; Fri, 1 Apr 2011 10:56:10 +0200 From: To: Thread-Topic: PAWS BOF minutes Thread-Index: AcvwSaKGnaNDddv1T1meJ0NfNijlpg== Date: Fri, 1 Apr 2011 08:56:10 +0000 Message-ID: <7DDB35B005136A4DB9FF33E7E286EF000692A7@008-AM1MPN1-037.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-version: 3.3.7.12 x-putclassificationandsendinfointox-header: Classification: Personal Project: Subject: PAWS BOF minutes Sender Name: Bajko Gabor (Nokia-CIC/SiliconValley) Sender Email: Gabor.Bajko@nokia.com Send Date: Friday, April 01, 2011 Send Time: 1:56:11 AM x-tituslabs-classifications-30: TLPropertyRoot=Trial License;Classification=Personal; x-tituslabs-classificationhash-30: vIuV97GEeFCRyZrly38nSn6OvzBCDVj1dgBUJMvoy2Z7s7sBIsOiX04h3NFSUii6pxpN85zFoUPsub9hbS1PyXwEmmjQ3jVceVe6nzhA+qAcOGKfZ2uDakXlL7KST3bNRus4JUutXVADAUaZxWZds7ZSpM5dmHrpEiQlxaM48u2nV38Fwm7Yikm3dnoh+zSJ x-originating-ip: [130.129.23.15] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 01 Apr 2011 08:56:18.0639 (UTC) FILETIME=[AA58E5F0:01CBF04A] X-Nokia-AV: Clean Subject: [paws] PAWS BOF minutes X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 08:54:47 -0000 Below are the minutes of the bof taken by Raj. Let me know if you have addi= tions/modifications. Otherwise I'll upload it to datatracker. Thanks Raj for the minutes. -Gabor =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =09 Gabor introducing the PAWS BoF. Background: Two I-Ds have been posted. Minutes taker: Basavaraj Patil Jabber scribes : Les Kuku (?) Gabor: How many people have read and understood the PS I-D? Quite many people raised their hands. They have read and understood the PS I-D. Basavaraj presents "Introduction to white space" ------------------------------------------------ No questions Brian's presentation: --------------------- Dirk K.: Do you intend to use other distribution mechanisms? Brian: It is location dependent. You cannot use broadcast mechanisms. Subir: Is the type (On slide handling Mac/Phy independence) tied to every nation?=20 Brian: Not sure. There is some registry that will likely specify it. At least in some nation the contour defines the type. Nation specific type is not clear Jeff Thompson: Is the channel available for exclusive use after querying and getting a response? Brian: No.The channel is available as a shared resource. However long term goals in this area could consider such options. TBD:=20 Brian: 802.11af comes up with an air interface and is applicable in many countries then it would work everywhere. Generally speaking the goal of the IETF is to not require that kind of country and device t= ie in.=20 TBD: HTTP based querying may be complex for this kind of solution. Brian: Write some text and send to the list. Teco Boot: Decision making can also be on the client. Interference knowledge may be local and can be sent to the server. This could be part of the query semantics. Brian: The DB has knowledge of protected entities.=20 Warren Kumari: Confused by the concept of channel.=20 Brian: Protocol has to have a much more general notion and it could be a frequency range. Serge M.: Does the protocol write or only read to the database? Brian: It is read/query only Basavaraj: As a clarification, there is a requirement to perform authentication in some cases in which case you could consider that to be a sort of write operation Brian: Yes. We may need to work on some authentication aspects as an optional component Gabor's slide on "Related IEEE work" ------------------------------------ - There is work in 802.11af and also 802.22 has specified a new radio technology=20 - There is also co-existence work in .19 where the database work is relevant Charter discussion ------------------- Key points about the charter and the work to be done - The proposal is to work on these as standards track deliverables Alissa Cooper: Privacy considerations are good to have. Suggestion to improve the text about this in the charter Brian: "Robust privacy and security mechanisms" should be used in the charter Yiu Lee: User authentication will be there? Brian: When we get to the requirements there will be a need for some identification. Because in some cases the DB access may not be free. If you think it should be part of the charter we can add it as well.=20 Tim Polk: In addition to privacy and security mechanisms, there are significant security issues. You may want to address the security threats that need to be addressed. Brian: Is it charter material? Tim: Believes that it is charter material. Does not need to be a 4 page charter. Just wants to point out that charter needs to ensure it considers it. Philip Eardley: Charter looks good. Regarding the data model, how do you address the country specific aspects Brian: Thinking very carefully about how the XML data model is specified to ensure that it can be extended as new rules and regulations become available. Most of that is not really an issue. Dan Harkins: Is the DB dynamic? Do you get the same response? Brian: In some countries there is a schedule. Answer to question: You may get different results at different times. Subir: Refering to Scotts question about registration. Will the proposed WG do that part as well Brian: We ought to. The US requires it. The general notion of registration should be optional and part of the charter.=20 Juan Carlos - In ETSI there is RRA group. Is it worth mentioning it in the list as someone we want to liaison with Brian: Sure.=20 Jan someone(Jabber): Can you select a channel before transmission? Brian: Thinks there is potential for such work in the future would be to not charter that activity initially Yiu lee: Use case regarding region. Is there a single database per region=20 Brian: There could be multiple databases Yiu: Do the databases have to be synchronized Brian: Yes.=20 Yiu: How would this be done? Brian: Would like to keep this out of the initial charter. There is less need for the IETF to standardize them. You dont need anything standardized. It would be nice to have but not essential. Jeff Thompson: Is there any anticipation of making the query per region... Making it mobile basically? Brian: There is no work among the regulators to do this. You are getting ahead of the technology. Teco Boot: In this query, it is not single point that has a catalyst of channels. You have to define the area you are in and include transmission power and other parameters Brian: Do we want to do this right away or maybe as an extension? If it is simple we could do it. But otherwise postpone it.=20 Teco: To get permission to transmit at a location the device needs to query first. Brian: It is a highly regulated area=20 Teco: Would prefer to have a rich protocol Jeff Thompson: W.r.t the size of the space owned, the query is for a point and not the larger space? Brian: The protocol should not restrict it to a point. It should be broader (circle, polygons etc.) Questions to BoF =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Question 1: Is there interest in taking up the work to specify the messaging interface between devices and databases?=20 Hums:=20 Yes: Many No: None Question 2: Is the IETF the right place to do this? Hums: Yes: Many (Louder than the response for Q1) No: None Qusetion 3: How many of you would be willing to work on various I-Ds and helping with reviews? =20 Work on I-Ds: Yes: 11 hands Willing to review:=20 More than 11 + 2 in Jabber Q4: Should a WG be formed Hums: Yes: Even more than response for Q2 And we are done. From paul@marvell.com Fri Apr 1 10:54:34 2011 Return-Path: X-Original-To: paws@core3.amsl.com Delivered-To: paws@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0F093A686C for ; Fri, 1 Apr 2011 10:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.723 X-Spam-Level: X-Spam-Status: No, score=-6.723 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFOzOc0Oc743 for ; Fri, 1 Apr 2011 10:54:25 -0700 (PDT) Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) by core3.amsl.com (Postfix) with ESMTP id 5794E3A67B4 for ; Fri, 1 Apr 2011 10:54:23 -0700 (PDT) Received: from source ([65.219.4.130]) (using TLSv1) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKTZYRrauWjdX7U+8sCihRB6N/sWvcLvGq@postini.com; Fri, 01 Apr 2011 10:56:05 PDT Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa02.marvell.com ([10.93.76.22]) with mapi; Fri, 1 Apr 2011 10:52:55 -0700 From: Paul Lambert To: "Rosen, Brian" , "Romascanu, Dan (Dan)" Date: Fri, 1 Apr 2011 10:52:54 -0700 Thread-Topic: [paws] updated charter proposal Thread-Index: AcvwQR8QuXK+f4/wSduRG7kOtNEtxAAU53xg Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D014068D317A@SC-VEXCH2.marvell.com> References: <7DDB35B005136A4DB9FF33E7E286EF00066340@008-AM1MPN1-037.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7BAC95F5A7E67643AAFB2C31BEE662D014068D317ASCVEXCH2marve_" MIME-Version: 1.0 Cc: "Gabor.Bajko@nokia.com \(Nokia-CIC/SiliconValley\)" , "paws@ietf.org" , "Polk, William T." Subject: Re: [paws] updated charter proposal X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 17:54:34 -0000 --_000_7BAC95F5A7E67643AAFB2C31BEE662D014068D317ASCVEXCH2marve_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Friendly edit (below): Since the location of a user device is involved, privacy implications arise= . The protocol must have robust mechanisms for mutual authentication and m= ust prevent the unauthorized disclosure of a users location. Paul Paul A. Lambert | Marvell | +1 650 787 9141 From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Ros= en, Brian Sent: Friday, April 01, 2011 12:48 AM To: Romascanu, Dan (Dan) Cc: Gabor.Bajko@nokia.com (Nokia-CIC/SiliconValley); paws@ietf.org; Polk, W= illiam T. Subject: Re: [paws] updated charter proposal Good news! There were charter changes requested in the BoF in the security= section. I suggest that the line in the charter: Since the location of a user device is involved, privacy implications arise= , and the protocol will have to have robust security mechanisms. Be changed to: Since the location of a user device is involved, privacy implications arise= , and the protocol will have to have robust security and privacy mechanisms= . There are other security concerns, including spoofing and man in the mid= dle attacks that will require analysis and mechanisms for mitigation in the= protocol. Brian On Apr 1, 2011, at 9:33 AM, Romascanu, Dan (Dan) wrote: Hi, I reported in the IESG and IAB meeting this morning about the PAWS BOF, whi= ch in my opinion went quite well. My recommendation to continue the process= with the chartering of a PAWS WG was well received. The WG (if approved af= ter the review process) will be in the OPS area with a Technical Advisor fr= om APPS. The first step in the review process is internal review of the charter with= the IESG and the IAB, which will result into discussion in the IESG telech= at on 4/14 and then sending of the charter to external (all IETF review). Question - is this charter text OK for the internal review, or are there an= y text changes following the BOF? Thanks and Regards, Dan ________________________________ From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com Sent: Thursday, March 24, 2011 12:24 AM To: paws@ietf.org Subject: [paws] updated charter proposal Folks, Here's an updated charter proposal. But please read these two drafts before you come to the BOF: I-D: Protocol to Access White Space database: Problem statement and Require= ments http://www.ietf.org/id/draft-patil-paws-problem-stmt-00.txt I-D: Protocol to Access White Space database: Overview and Use case scenari= os http://www.ietf.org/id/draft-probasco-paws-overview-usecases-00.txt Governments around the world continue to search for new pieces of radio spe= ctrum which can be used by the expanding wireless communications industry t= o provide more services in the usable spectrum. The concept of allowing se= condary 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. T= he 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 schedul= e. The fundamental issue is how to determine for a specific location and s= pecific time, if any of the primary spectrum is available for secondary use= . One simple mechanism is to use a geospatial database that records protect= ed contours for primary users, and require the secondary users to check the= database prior to selecting what part of the spectrum they use. Such data= bases 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 l= ocation in latitude and longitude. At power-on, before the device can tra= nsmit or use any of the spectrum set aside for secondary use, the device mu= st identify the relevant database to query, contact the database, provide i= ts geolocation and receive in return a list of unoccupied or "white space"= spectrum (for example, in a TV White space implementation, the list of ava= ilable channels at that location). The device can then select one of the ch= annels from the list and begin to transmit and receive on the selected chan= nel. The device must query the database subsequently on a periodic basis fo= r a list of unoccupied channels based on certain conditions, e.g. a fixed a= mount of time has passed or the device has changed location beyond a specif= ied 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 connec= tivity, directly or indirectly. The databases may be country specific sinc= e the available spectrum and regulations may vary, but the fundamental ope= ration of the protocol should be country independent, thus extensibility of= data structures will be required. The solution will not be tied to any spe= cific spectrum, country, or phy/mac/air interface but may incorporate relev= ant aspects of these as needed for proper operation. The proposed working group will : - standardize a protocol for querying the database, which includes a lo= cation sensitive database discovery mechanism and security for the protoco= l, and application services. - Standardize the data structure to be carried by the query protocol. Since the location of a user device is involved, privacy implications arise= , and the protocol will have to have robust security mechanisms. Existing IETF location data structures and privacy mechanisms may be consid= ered for use. The WG will also investigate the need for other mechanisms an= d 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 an= d 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 fo= r secondary use of spectrum in specific bands. 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 --_000_7BAC95F5A7E67643AAFB2C31BEE662D014068D317ASCVEXCH2marve_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Friendly edit (below):

 

Since the locati= on of a user device is involved, privacy implications arise.  The prot= ocol must have robust mechanisms for mutual authentication and must prevent= the unauthorized disclosure of a users location.<= /p>

 

 

Paul

 

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

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behal= f Of Rosen, Brian
Sent: Friday, April 01, 2011 12:48 AM
To: Romascanu, Dan (Dan)
Cc: Gabor.Bajko@nokia.com (Nokia-CI= C/SiliconValley); paws@ietf.org; Polk, William T.
Subject: Re: [p= aws] updated charter proposal

 

Good news!  There w= ere charter changes requested in the BoF in the security section.  

 

I suggest that the line in the charter:

=

Since the location of a user d= evice is involved, privacy implications arise, and the protocol will have t= o have robust security mechanisms.

<= p class=3DMsoNormal> 

Be= changed to:

Since the location of a user device is involved, privacy implicatio= ns arise, and the protocol will have to have robust security and privacy me= chanisms.  There are other security concerns, including spoofing and m= an in the middle attacks that will require analysis and mechanisms for miti= gation in the protocol.

 

Brian

 

On Apr 1, 2011, at = 9:33 AM, Romascanu, Dan (Dan) wrote:



 

 

Hi,<= /span>

I reported in the IESG and IAB meeting this morning about the PAWS BOF, wh= ich in my opinion went quite well. My recommendation to continue the proces= s with the chartering of a PAWS WG was well received. The WG (if appro= ved after the review process) will be in the OPS area with a Technical Advi= sor from APPS.

The first= step in the review process is internal review of the charter with the IESG= and the IAB, which will result into discussion in the IESG telechat on 4/1= 4 and then sending of the charter to external (all IETF review).

 

<= div>

Question - is this charter text OK for the inter= nal review, or are there any text changes following the BOF? 

Thanks and Regards,
Dan

 

 

<= div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'>

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gab= or.Bajko@nokia.com
Sent:&= nbsp;Thursday, March 24, 2011 12:24 AM
To: paws@ietf= .org
Subject: [paws] updated charter proposal

<= div>

Folks,

&nbs= p;

Here’s an updated ch= arter proposal.

 

But please read these two drafts be= fore you come to the BOF:

&nb= sp;

I-D: Protocol to Access W= hite Space database: Problem statement and Requirements

 

I-D: Protocol to Access White Space database: Overview and Use case scen= arios

 

 

 

Governments around the world contin= ue to search for new pieces of radio spectrum which can be used by the expa= nding wireless communications industry to provide more services in the usab= le spectrum.  The concept of allowing secondary transmissions (license= d 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 us= e 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 sp= ectrum for a secondary use would then depend on the location of the seconda= ry user.  The primary user may have a schedule when it uses the spectr= um, which may be available for secondary use outside that schedule.  T= he fundamental issue is how to determine for a specific location and specif= ic time, if any of the primary spectrum is available for secondary use. One= simple mechanism is to use a geospatial database that records protected co= ntours for primary users, and require the secondary users to check the data= base prior to selecting what part of the spectrum they use.  Such data= bases 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 t= he capability to determine its location in latitude and longitude. &nb= sp; 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 ret= urn a list of  unoccupied or "white space" spectrum (for exa= mple, 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 li= st and begin to transmit and receive on the selected channel. The device mu= st query the database subsequently on a periodic basis for a list of unoccu= pied 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 ex= pected to have some form of Internet connectivity, directly or indirectly. = The databases  may be country specific since the available spectrum an= d  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, countr= y, or phy/mac/air interface but may incorporate relevant aspects of these a= s needed for proper operation.

The proposed working group will :

    - standardize a protocol for querying the databas= e, which includes a location sensitive database discovery mechanism and sec= urity for  the protocol, and application services.

    - Standardize the data struct= ure to be carried by the query protocol.

Since the location of a user device is involved, privacy implic= ations arise, and the protocol will have to have robust security mechanisms= .

Existing IETF location data= structures and privacy mechanisms may be considered for use. The WG will a= lso investigate the need for other mechanisms and related protocols to the = White Space DB.

The Working G= roup will set up and maintain appropriate contact and liaison with other re= levant standards bodies and groups, including IEEE 802.11af and IEEE 802.22= to begin with. The working group may also consider input from regulatory e= ntities that are involved in the specification of the rules for secondary u= se of spectrum in specific bands.

Milestones

Sep 2011&nbs= p;       Submit 'Requirements and Framework' = to the IESG for

  &= nbsp;   publication as Informational

<= div>

Apr 2012        Submit= 'Protocol for Querying a Whitespace Database'

<= div>

      to the IESG for publicatio= n as Proposed Standard

Apr 20= 12        Submit 'Data Model for Whitesp= ace query protocol'

 &nb= sp;    to the IESG for publication as Proposed Standard=

 

<ATT00001..txt>

 

= --_000_7BAC95F5A7E67643AAFB2C31BEE662D014068D317ASCVEXCH2marve_-- From brian.rosen@neustar.biz Fri Apr 1 10:56:36 2011 Return-Path: X-Original-To: paws@core3.amsl.com Delivered-To: paws@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E5693A67B4 for ; Fri, 1 Apr 2011 10:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.121 X-Spam-Level: X-Spam-Status: No, score=-6.121 tagged_above=-999 required=5 tests=[AWL=0.477, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Iq5vVSP9eUb for ; Fri, 1 Apr 2011 10:56:34 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by core3.amsl.com (Postfix) with ESMTP id 857933A686C for ; Fri, 1 Apr 2011 10:56:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1301680690; x=1617038901; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=bsu6wpoa38+phMSzRa9Z9DU3tkBWAMEL1xY4UyWqaEY=; b=H6pX36pdKC9dmvhRfBEi5qoMQcMOglSphIJnnmYaTWnKqjQ1E51odb+b9xWGk4 yr7n0xTxpDx7HieIuqSl2ANA== Received: from ([10.31.13.229]) by chihiron2.nc.neustar.com with ESMTP with TLS id 5202415.36096573; Fri, 01 Apr 2011 13:58:09 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Fri, 1 Apr 2011 13:58:09 -0400 From: "Rosen, Brian" To: Paul Lambert Date: Fri, 1 Apr 2011 13:58:04 -0400 Thread-Topic: [paws] updated charter proposal Thread-Index: Acvwllu5ZNDKp3pDRzWwBzl3FkZfgg== Message-ID: References: <7DDB35B005136A4DB9FF33E7E286EF00066340@008-AM1MPN1-037.mgdnok.nokia.com> <7BAC95F5A7E67643AAFB2C31BEE662D014068D317A@SC-VEXCH2.marvell.com> In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D014068D317A@SC-VEXCH2.marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 6mltY+LfomGyw98s8RIhSQ== Content-Type: multipart/alternative; boundary="_000_FC149AF53A2E41AC8356035D8304E4BEneustarbiz_" MIME-Version: 1.0 Cc: "Gabor.Bajko@nokia.com \(Nokia-CIC/SiliconValley\)" , "paws@ietf.org" , "Polk, William T." Subject: Re: [paws] updated charter proposal X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 17:56:36 -0000 --_000_FC149AF53A2E41AC8356035D8304E4BEneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I think Tim Polk wanted more words about security beyond just these. Brian On Apr 1, 2011, at 7:52 PM, Paul Lambert wrote: Friendly edit (below): Since the location of a user device is involved, privacy implications arise= . The protocol must have robust mechanisms for mutual authentication and m= ust prevent the unauthorized disclosure of a users location. Paul Paul A. Lambert | Marvell | +1 650 787 9141 From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Rosen, Brian Sent: Friday, April 01, 2011 12:48 AM To: Romascanu, Dan (Dan) Cc: Gabor.Bajko@nokia.com (Nokia-CIC/SiliconV= alley); paws@ietf.org; Polk, William T. Subject: Re: [paws] updated charter proposal Good news! There were charter changes requested in the BoF in the security= section. I suggest that the line in the charter: Since the location of a user device is involved, privacy implications arise= , and the protocol will have to have robust security mechanisms. Be changed to: Since the location of a user device is involved, privacy implications arise= , and the protocol will have to have robust security and privacy mechanisms= . There are other security concerns, including spoofing and man in the mid= dle attacks that will require analysis and mechanisms for mitigation in the= protocol. Brian On Apr 1, 2011, at 9:33 AM, Romascanu, Dan (Dan) wrote: Hi, I reported in the IESG and IAB meeting this morning about the PAWS BOF, whi= ch in my opinion went quite well. My recommendation to continue the process= with the chartering of a PAWS WG was well received. The WG (if approved af= ter the review process) will be in the OPS area with a Technical Advisor fr= om APPS. The first step in the review process is internal review of the charter with= the IESG and the IAB, which will result into discussion in the IESG telech= at on 4/14 and then sending of the charter to external (all IETF review). Question - is this charter text OK for the internal review, or are there an= y text changes following the BOF? Thanks and Regards, Dan ________________________________ From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com Sent: Thursday, March 24, 2011 12:24 AM To: paws@ietf.org Subject: [paws] updated charter proposal Folks, Here=92s an updated charter proposal. But please read these two drafts before you come to the BOF: I-D: Protocol to Access White Space database: Problem statement and Require= ments http://www.ietf.org/id/draft-patil-paws-problem-stmt-00.txt I-D: Protocol to Access White Space database: Overview and Use case scenari= os http://www.ietf.org/id/draft-probasco-paws-overview-usecases-00.txt Governments around the world continue to search for new pieces of radio spe= ctrum which can be used by the expanding wireless communications industry t= o provide more services in the usable spectrum. The concept of allowing se= condary 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. T= he 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 schedul= e. The fundamental issue is how to determine for a specific location and s= pecific time, if any of the primary spectrum is available for secondary use= . One simple mechanism is to use a geospatial database that records protect= ed contours for primary users, and require the secondary users to check the= database prior to selecting what part of the spectrum they use. Such data= bases 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 l= ocation in latitude and longitude. At power-on, before the device can tra= nsmit or use any of the spectrum set aside for secondary use, the device mu= st identify the relevant database to query, contact the database, provide i= ts geolocation and receive in return a list of unoccupied or "white space"= spectrum (for example, in a TV White space implementation, the list of ava= ilable channels at that location). The device can then select one of the ch= annels from the list and begin to transmit and receive on the selected chan= nel. The device must query the database subsequently on a periodic basis fo= r a list of unoccupied channels based on certain conditions, e.g. a fixed a= mount of time has passed or the device has changed location beyond a specif= ied 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 connec= tivity, directly or indirectly. The databases may be country specific sinc= e the available spectrum and regulations may vary, but the fundamental ope= ration of the protocol should be country independent, thus extensibility of= data structures will be required. The solution will not be tied to any spe= cific spectrum, country, or phy/mac/air interface but may incorporate relev= ant aspects of these as needed for proper operation. The proposed working group will : - standardize a protocol for querying the database, which includes a lo= cation sensitive database discovery mechanism and security for the protoco= l, and application services. - Standardize the data structure to be carried by the query protocol. Since the location of a user device is involved, privacy implications arise= , and the protocol will have to have robust security mechanisms. Existing IETF location data structures and privacy mechanisms may be consid= ered for use. The WG will also investigate the need for other mechanisms an= d 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 an= d 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 fo= r secondary use of spectrum in specific bands. 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 --_000_FC149AF53A2E41AC8356035D8304E4BEneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
 
 
= Since the location of a user device is involved, privacy implications arise= .  The protocol must have robust mechanisms for mutual authentication = and must prevent the unauthorized disclosure of a users location.
 <= /span>
 
Paul
 
Paul A. Lambert |  Marvell  | +1 650 787 9141
 
 
Good news!  There were = charter changes requested in the BoF in the security section.  
 
I suggest that the line = in the charter:
Since the= location of a user device is involved, privacy implications arise, and the= protocol will have to have robust security mechanisms.<= /o:p>
 
Be changed to:
Since the location of= a user device is involved, privacy implications arise, and the protocol wi= ll have to have robust security and privacy mechanisms.  There are oth= er security concerns, including spoofing and man in the middle attacks that= will require analysis and mechanisms for mitigation in the protocol.
 
Brian
 
On Apr 1, 2011, at 9:33 AM, Romascanu, Dan = (Dan) wrote:


 =
 

Hi,

I rep= orted in the IESG and IAB meeting this morning about the PAWS BOF, which in= my opinion went quite well. My recommendation to continue the process with= the chartering of a PAWS WG was well received. The WG (if approved af= ter the review process) will be in the OPS area with a Technical Advisor fr= om APPS.

The first step in the review pr= ocess is internal review of the charter with the IESG and the IAB, which wi= ll result into discussion in the IESG telechat on 4/14 and then sending of = the charter to external (all IETF review).
 
Question - is this charte= r text OK for the internal review, or are there any text changes following = the BOF? 

Thanks and Regards,

Dan
<= div style=3D"margin-right: 0in; margin-left: 0in; font-size: 12pt; font-fam= ily: 'Times New Roman', serif; margin-top: 0in; margin-bottom: 0.0001pt; ">= &nb= sp;
 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org]<= span class=3D"apple-converted-space"> On Behalf Of Gabor.Bajko@= nokia.com
Sent: Thursday, March 24, 2011 12:24 AM
To: paws@ietf.org
Subject:<= span class=3D"apple-converted-space"> [paws] updated charter pr= oposal

Folks,
Here=92s an updated charter proposal.<= o:p>
 
But please r= ead these two drafts before you come to the BOF:
I-D: Protocol to Access White Space da= tabase: Problem statement and R= equirements
 
 =
 
Government= s around the world continue to search for new pieces of radio spectrum whic= h can be used by the expanding wireless communications industry to provide = more services in the usable spectrum.  The concept of allowing seconda= ry transmissions (licensed or unlicensed) in frequencies allocated to a pri= mary user is a technique to "unlock" existing spectrum for new use. An obvi= ous 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.  T= he 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 sc= hedule.  The fundamental issue is how to determine for a specific loca= tion and specific time, if any of the primary spectrum is available for sec= ondary use. One simple mechanism is to use a geospatial database that recor= ds protected contours for primary users, and require the secondary users to= check the database prior to selecting what part of the spectrum they use.&= nbsp; 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 locatio= n). 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 Int= ernet connectivity, directly or indirectly. The databases  may be coun= try specific since the available spectrum and  regulations may vary, b= ut 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.<= o:p>
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.<= /span>
    - Standardize the data structure to be = carried by the query protocol.
Since the locati= on of a user device is involved, privacy implications arise, and the protoc= ol will have to have robust security mechanisms.
Th= e Working Group will set up and maintain appropriate contact and liaison wi= th 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 r= egulatory entities that are involved in the specification of the rules for = secondary use of spectrum in specific bands.
<= div>
Mi= lestones
Sep 2011     =    Submit 'Requirements and Framework' to the IESG for=
      publication as Information= al
Apr 2012      =   Submit 'Protocol for Querying a Whitespace Database'
      to the IESG for publication as = Proposed Standard
Apr 2012   &nb= sp;    Submit 'Data Model for Whitespace query protocol'
      to the IESG for pub= lication as Proposed Standard
 
<ATT00001..txt>
 
<= /blockquote>
= --_000_FC149AF53A2E41AC8356035D8304E4BEneustarbiz_-- From paul@marvell.com Fri Apr 1 11:25:14 2011 Return-Path: X-Original-To: paws@core3.amsl.com Delivered-To: paws@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F28D3A68C1 for ; Fri, 1 Apr 2011 11:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.709 X-Spam-Level: X-Spam-Status: No, score=-6.709 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ncu9ZjOPdPFm for ; Fri, 1 Apr 2011 11:25:03 -0700 (PDT) Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) by core3.amsl.com (Postfix) with ESMTP id 04E613A686C for ; Fri, 1 Apr 2011 11:24:58 -0700 (PDT) Received: from source ([65.219.4.129]) (using TLSv1) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKTZYY3Wqj17t6StEa8whcl5abjQhTVwbf@postini.com; Fri, 01 Apr 2011 11:26:43 PDT Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Fri, 1 Apr 2011 11:23:46 -0700 From: Paul Lambert To: "Rosen, Brian" , "Polk, William T." , "paws@ietf.org" Date: Fri, 1 Apr 2011 11:25:49 -0700 Thread-Topic: [paws] updated charter proposal Thread-Index: Acvwllu5ZNDKp3pDRzWwBzl3FkZfggAAI9CQ Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D014068D319A@SC-VEXCH2.marvell.com> References: <7DDB35B005136A4DB9FF33E7E286EF00066340@008-AM1MPN1-037.mgdnok.nokia.com> <7BAC95F5A7E67643AAFB2C31BEE662D014068D317A@SC-VEXCH2.marvell.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7BAC95F5A7E67643AAFB2C31BEE662D014068D319ASCVEXCH2marve_" MIME-Version: 1.0 Cc: "Gabor.Bajko@nokia.com \(Nokia-CIC/SiliconValley\)" Subject: Re: [paws] updated charter proposal X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 18:25:14 -0000 --_000_7BAC95F5A7E67643AAFB2C31BEE662D014068D319ASCVEXCH2marve_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > I think Tim Polk wanted more words about security beyond just these. Oh ... ok I believe these are the overall threat areas: device identity spoofing modification of device requests modification of channel enablement information impersonation of registered database services unauthorized disclosure of a users location There may be other broader ways to phrase these - but we need to be careful= not to slip into device internal security versus the security of the proto= col. Translating the above into charter speak and as a revised suggestion: The protocol must protect both the channel enablement process and the priva= cy of users. Robust security mechanisms are required to prevent: device identity spoofin= g, modification of device requests, modification of channel enablement information, imperso= nation of registered database services and unauthorized disclosure of a users locatio= n. Hope this helps ... Paul Paul A. Lambert | Marvell | +1 650 787 9141 From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] Sent: Friday, April 01, 2011 10:58 AM To: Paul Lambert Cc: Romascanu, Dan (Dan); Gabor.Bajko@nokia.com (Nokia-CIC/SiliconValley); = paws@ietf.org; Polk, William T. Subject: Re: [paws] updated charter proposal I think Tim Polk wanted more words about security beyond just these. Brian On Apr 1, 2011, at 7:52 PM, Paul Lambert wrote: Friendly edit (below): Since the location of a user device is involved, privacy implications arise= . The protocol must have robust mechanisms for mutual authentication and m= ust prevent the unauthorized disclosure of a users location. Paul Paul A. Lambert | Marvell | +1 650 787 9141 From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Rosen, Brian Sent: Friday, April 01, 2011 12:48 AM To: Romascanu, Dan (Dan) Cc: Gabor.Bajko@nokia.com (Nokia-CIC/SiliconV= alley); paws@ietf.org; Polk, William T. Subject: Re: [paws] updated charter proposal Good news! There were charter changes requested in the BoF in the security= section. I suggest that the line in the charter: Since the location of a user device is involved, privacy implications arise= , and the protocol will have to have robust security mechanisms. Be changed to: Since the location of a user device is involved, privacy implications arise= , and the protocol will have to have robust security and privacy mechanisms= . There are other security concerns, including spoofing and man in the mid= dle attacks that will require analysis and mechanisms for mitigation in the= protocol. Brian On Apr 1, 2011, at 9:33 AM, Romascanu, Dan (Dan) wrote: Hi, I reported in the IESG and IAB meeting this morning about the PAWS BOF, whi= ch in my opinion went quite well. My recommendation to continue the process= with the chartering of a PAWS WG was well received. The WG (if approved af= ter the review process) will be in the OPS area with a Technical Advisor fr= om APPS. The first step in the review process is internal review of the charter with= the IESG and the IAB, which will result into discussion in the IESG telech= at on 4/14 and then sending of the charter to external (all IETF review). Question - is this charter text OK for the internal review, or are there an= y text changes following the BOF? Thanks and Regards, Dan ________________________________ From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com Sent: Thursday, March 24, 2011 12:24 AM To: paws@ietf.org Subject: [paws] updated charter proposal Folks, Here's an updated charter proposal. But please read these two drafts before you come to the BOF: I-D: Protocol to Access White Space database: Problem statement and Require= ments http://www.ietf.org/id/draft-patil-paws-problem-stmt-00.txt I-D: Protocol to Access White Space database: Overview and Use case scenari= os http://www.ietf.org/id/draft-probasco-paws-overview-usecases-00.txt Governments around the world continue to search for new pieces of radio spe= ctrum which can be used by the expanding wireless communications industry t= o provide more services in the usable spectrum. The concept of allowing se= condary 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. T= he 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 schedul= e. The fundamental issue is how to determine for a specific location and s= pecific time, if any of the primary spectrum is available for secondary use= . One simple mechanism is to use a geospatial database that records protect= ed contours for primary users, and require the secondary users to check the= database prior to selecting what part of the spectrum they use. Such data= bases 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 l= ocation in latitude and longitude. At power-on, before the device can tra= nsmit or use any of the spectrum set aside for secondary use, the device mu= st identify the relevant database to query, contact the database, provide i= ts geolocation and receive in return a list of unoccupied or "white space"= spectrum (for example, in a TV White space implementation, the list of ava= ilable channels at that location). The device can then select one of the ch= annels from the list and begin to transmit and receive on the selected chan= nel. The device must query the database subsequently on a periodic basis fo= r a list of unoccupied channels based on certain conditions, e.g. a fixed a= mount of time has passed or the device has changed location beyond a specif= ied 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 connec= tivity, directly or indirectly. The databases may be country specific sinc= e the available spectrum and regulations may vary, but the fundamental ope= ration of the protocol should be country independent, thus extensibility of= data structures will be required. The solution will not be tied to any spe= cific spectrum, country, or phy/mac/air interface but may incorporate relev= ant aspects of these as needed for proper operation. The proposed working group will : - standardize a protocol for querying the database, which includes a lo= cation sensitive database discovery mechanism and security for the protoco= l, and application services. - Standardize the data structure to be carried by the query protocol. Since the location of a user device is involved, privacy implications arise= , and the protocol will have to have robust security mechanisms. Existing IETF location data structures and privacy mechanisms may be consid= ered for use. The WG will also investigate the need for other mechanisms an= d 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 an= d 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 fo= r secondary use of spectrum in specific bands. 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 --_000_7BAC95F5A7E67643AAFB2C31BEE662D014068D319ASCVEXCH2marve_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> I think Tim Polk wanted more words about security be= yond just these.

Oh … ok

 

I believe these are the overall threat areas:<= /span>

device identity spoofing

modificatio= n of device requests

modification of channel enabl= ement information

impersonation of registered data= base services

unauthorized disclosure of a users l= ocation

 

There may be other broader ways to phrase these – but we= need to be careful not to slip into device internal security versus the se= curity of the protocol.

<= span class=3Dapple-style-span> 

Translating the above into charter speak and as= a revised suggestion:

 

 

The protocol must= protect both the channel enablement process and the privacy of users. &nbs= p;
Robust security mechanisms are required to prevent: device identity s= poofing, modification
of device requests, modification of channel enabl= ement information, impersonation of
registered database services and un= authorized disclosure of a users location.

 

 

 =

Hope this helps &#= 8230;

 

Paul

 

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'> 

Paul A. Lambert |&n= bsp; Marvell  | +1 650 787 9141

 

From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]
Sent:= Friday, April 01, 2011 10:58 AM
To: Paul Lambert
Cc: Romascanu, Dan (Dan); Gabor.Bajko@nokia.com (Nokia-CIC/SiliconValley); p= aws@ietf.org; Polk, William T.
Subject: Re: [paws] updated charte= r proposal

 = ;

I think Tim Polk wanted more words about se= curity beyond just these.

&nbs= p;

Brian

=

 

On= Apr 1, 2011, at 7:52 PM, Paul Lambert wrote:



 

Friendly edit (below):

 

Since the location of a user device is involved, privacy implications = arise.  The protocol must have robust mechanisms for mutual authentica= tion and must prevent the unauthorized disclosure of a users location.

 

 

Paul=

 

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

 

From: paws-bounces@ietf.o= rg [mailto:paws-bounces= @ietf.org] On Behalf Of<= span class=3Dapple-converted-space> Rosen, Brian
Sent= : Friday, April 01, 201= 1 12:48 AM
To: Ro= mascanu, Dan (Dan)
Cc: <= /span>Gabor.Bajko@nokia.com (Nokia-CIC/SiliconValley); paws@ietf.org; Polk, William T.
Subject: Re: [paws] updated charter proposal<= o:p>

 =

Good news!  There were charter cha= nges requested in the BoF in the security section.  

 

I suggest that the line in the charter:

Since the lo= cation of a user device is involved, privacy implications arise, and the pr= otocol will have to have robust security mechanisms.

 

Be changed to:

Since the locati= on of a user device is involved, privacy implications arise, and the protoc= ol will have to have robust security and privacy mechanisms.  There ar= e other security concerns, including spoofing and man in the middle attacks= that will require analysis and mechanisms for mitigation in the protocol.<= /span>

&nbs= p;

Brian

 

On Apr 1, 2011, at 9:33 AM, Romascanu, Dan (Dan) wrote:




 

 

Hi,<= /o:p>

I reported in= the IESG and IAB meeting this morning about the PAWS BOF, which in my opin= ion went quite well. My recommendation to continue the process with the cha= rtering of a PAWS WG was well received. The WG (if approved after the = review process) will be in the OPS area with a Technical Advisor from APPS.=

The first step in th= e review process is internal review of the charter with the IESG and the IA= B, which will result into discussion in the IESG telechat on 4/14 and then = sending of the charter to external (all IETF review).

=

 

Question - is this charter text OK for = the internal review, or are there any text changes following the BOF? 

Thanks and Re= gards,

Dan

 

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com
Sent: Thursday, March 24, 2011 12:24 AM
To: paws= @ietf.org
Subject: <= /span>[paws] updated charter proposal

= Folks,<= /span>

 =

Here’s an updated chart= er proposal.

 = ;

But please read = these two drafts before you come to the BOF:

 

I-D: Protocol to Access White Space database: Problem state= ment and Requirements

 

= I-D: Protocol to Access White Space database: Overview and Use case scenari= os

 

 

 

Governments around the world continue to search for new pi= eces of radio spectrum which can be used by the expanding wireless communic= ations industry to provide more services in the usable spectrum.  The = concept of allowing secondary transmissions (licensed or unlicensed) in fre= quencies allocated to a primary user is a technique to "unlock" e= xisting spectrum for new use. An obvious requirement is that these secondar= y transmissions do not interfere with the primary use of the spectrum. Ofte= n, in a given physical location, the primary user(s) may not be using the e= ntire band allocated to them.  The available spectrum for a secondary = use would then depend on the location of the secondary user.  The prim= ary user may have a schedule when it uses the spectrum, which may be availa= ble 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 user= s, and require the secondary users to check the database prior to selecting= what part of the spectrum they use.  Such databases could be availabl= e 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 capabilit= y to determine its location in latitude and longitude.   At power= -on, before the device can transmit or use any of the spectrum set aside fo= r secondary use, the device must identify the relevant database to query, c= ontact the database, provide its geolocation and receive in return a list o= f  unoccupied or "white space" spectrum (for example, in a T= V White space implementation, the list of available channels at that locati= on). 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 channel= s based on certain conditions, e.g. a fixed amount of time has passed or th= e 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 exp= ected to have some form of Internet connectivity, directly or indirectly. T= he 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 b= e 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 discov= ery mechanism and security for  the protocol, and application services= .

  &nbs= p; - Standardize the data structure to be carried by the query protocol.

Since the location= of a user device is involved, privacy implications arise, and the protocol= will have to have robust security mechanisms.

<= /div>

Existing IETF location data structures and pri= vacy 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 wil= l set up and maintain appropriate contact and liaison with other relevant s= tandards bodies and groups, including IEEE 802.11af and IEEE 802.22 to begi= n with. The working group may also consider input from regulatory entities = that are involved in the specification of the rules for secondary use of sp= ectrum in specific bands.

Milestones

Sep 2011        Submit 'Requirements an= d Framework' to the IESG for

      publication as Informational

Apr 2012  &n= bsp;     Submit 'Protocol for Querying a Whitespace Dat= abase'

  = ;    to the IESG for publication as Proposed Standard=

Apr 2012  &nbs= p;     Submit 'Data Model for Whitespace query protocol= '

  &nbs= p;   to the IESG for publication as Proposed Standard=

 

<= /div>

<ATT00001..txt>

 <= /p>

 

= --_000_7BAC95F5A7E67643AAFB2C31BEE662D014068D319ASCVEXCH2marve_-- From dromasca@avaya.com Sun Apr 3 05:31:34 2011 Return-Path: X-Original-To: paws@core3.amsl.com Delivered-To: paws@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A3273A6979 for ; Sun, 3 Apr 2011 05:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.185 X-Spam-Level: X-Spam-Status: No, score=-103.185 tagged_above=-999 required=5 tests=[AWL=0.414, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42DKMqH7P-zj for ; Sun, 3 Apr 2011 05:31:33 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 235073A67C3 for ; Sun, 3 Apr 2011 05:31:33 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFMtcU2HCzI1/2dsb2JhbACmZXSkeQKZFoJ+AYJiBJAMiQM X-IronPort-AV: E=Sophos;i="4.63,291,1299474000"; d="scan'208";a="272810177" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 03 Apr 2011 08:33:14 -0400 X-IronPort-AV: E=Sophos;i="4.63,291,1299474000"; d="scan'208";a="634536935" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 03 Apr 2011 08:33:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 3 Apr 2011 14:33:12 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Charter text to be sent for IESG and IAB internal review Thread-Index: Acvx+0vlDL6sAVwzSsaB0QVuwQXSpg== From: "Romascanu, Dan (Dan)" To: Subject: [paws] Charter text to be sent for IESG and IAB internal review X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2011 12:31:34 -0000 Hi,=20 I have included the latest suggestions concerning security and came up with the following version of the charter which I am sending to be reviewed by the IESG and IAB.=20 Thanks and Regards, Dan=20 Protocol to Access White Space database (paws) ------------------------------------------------ Current Status: Proposed Working Group Last updated: 2011-04-02 Chairs: TBD=20 Operations and Management Area Directors: Ronald Bonica Dan Romascanu Operations and Management Area Advisor: Dan Romascanu Applications Area Advisor: TBD Mailing lists: Address: paws@ietf.org 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. 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 =20 From teco@inf-net.nl Mon Apr 4 02:48:05 2011 Return-Path: X-Original-To: paws@core3.amsl.com Delivered-To: paws@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BBB63A6954 for ; Mon, 4 Apr 2011 02:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s+sELjamMPxZ for ; Mon, 4 Apr 2011 02:48:03 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 531E63A6940 for ; Mon, 4 Apr 2011 02:48:02 -0700 (PDT) Received: by wyb29 with SMTP id 29so5073743wyb.31 for ; Mon, 04 Apr 2011 02:49:44 -0700 (PDT) Received: by 10.216.145.152 with SMTP id p24mr3576331wej.97.1301910583950; Mon, 04 Apr 2011 02:49:43 -0700 (PDT) Received: from [172.16.4.189] ([188.205.88.52]) by mx.google.com with ESMTPS id t5sm2169659wes.9.2011.04.04.02.49.41 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Apr 2011 02:49:42 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=windows-1252 From: Teco Boot In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D014068D319A@SC-VEXCH2.marvell.com> Date: Mon, 4 Apr 2011 11:49:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <26B8D793-D4EE-43ED-855F-3EDE5657E768@inf-net.nl> References: <7DDB35B005136A4DB9FF33E7E286EF00066340@008-AM1MPN1-037.mgdnok.nokia.com> <7BAC95F5A7E67643AAFB2C31BEE662D014068D317A@SC-VEXCH2.marvell.com> <7BAC95F5A7E67643AAFB2C31BEE662D014068D319A@SC-VEXCH2.marvell.com> To: Paul Lambert X-Mailer: Apple Mail (2.1082) Cc: "paws@ietf.org" , "Rosen, Brian" , "Polk, William T." , "Gabor.Bajko@nokia.com \(Nokia-CIC/SiliconValley\)" Subject: Re: [paws] updated charter proposal X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 09:48:05 -0000 I'm not sure on requirements for non-repudiation. Should a secondary = user keep evidence that it legally use (or used) a granted channel? It = may have impact on the protocol. Teco Op 1 apr 2011, om 20:25 heeft Paul Lambert het volgende geschreven: > > I think Tim Polk wanted more words about security beyond just these. > Oh =85 ok > =20 > I believe these are the overall threat areas: > device identity spoofing > modification of device requests > modification of channel enablement information > impersonation of registered database services > unauthorized disclosure of a users location > =20 > There may be other broader ways to phrase these =96 but we need to be = careful not to slip into device internal security versus the security of = the protocol. > =20 > Translating the above into charter speak and as a revised suggestion: > =20 > =20 > The protocol must protect both the channel enablement process and the = privacy of users. =20 > Robust security mechanisms are required to prevent: device identity = spoofing, modification=20 > of device requests, modification of channel enablement information, = impersonation of=20 > registered database services and unauthorized disclosure of a users = location. > =20 > =20 > =20 > Hope this helps =85 > =20 > Paul > =20 > =20 > Paul A. Lambert | Marvell | +1 650 787 9141 > =20 > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 > Sent: Friday, April 01, 2011 10:58 AM > To: Paul Lambert > Cc: Romascanu, Dan (Dan); Gabor.Bajko@nokia.com = (Nokia-CIC/SiliconValley); paws@ietf.org; Polk, William T. > Subject: Re: [paws] updated charter proposal > =20 > I think Tim Polk wanted more words about security beyond just these. > =20 > Brian > =20 > On Apr 1, 2011, at 7:52 PM, Paul Lambert wrote: >=20 >=20 > =20 > Friendly edit (below): > =20 > Since the location of a user device is involved, privacy implications = arise. The protocol must have robust mechanisms for mutual = authentication and must prevent the unauthorized disclosure of a users = location. > =20 > =20 > Paul > =20 > Paul A. Lambert | Marvell | +1 650 787 9141 > =20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of Rosen, Brian > Sent: Friday, April 01, 2011 12:48 AM > To: Romascanu, Dan (Dan) > Cc: Gabor.Bajko@nokia.com (Nokia-CIC/SiliconValley); paws@ietf.org; = Polk, William T. > Subject: Re: [paws] updated charter proposal > =20 > Good news! There were charter changes requested in the BoF in the = security section. =20 > =20 > I suggest that the line in the charter: > Since the location of a user device is involved, privacy implications = arise, and the protocol will have to have robust security mechanisms. > =20 > Be changed to: > Since the location of a user device is involved, privacy implications = arise, and the protocol will have to have robust security and privacy = mechanisms. There are other security concerns, including spoofing and = man in the middle attacks that will require analysis and mechanisms for = mitigation in the protocol. > =20 > Brian > =20 > On Apr 1, 2011, at 9:33 AM, Romascanu, Dan (Dan) wrote: >=20 >=20 >=20 > =20 > =20 > Hi, >=20 > I reported in the IESG and IAB meeting this morning about the PAWS = BOF, which in my opinion went quite well. My recommendation to continue = the process with the chartering of a PAWS WG was well received. The WG = (if approved after the review process) will be in the OPS area with a = Technical Advisor from APPS. >=20 > The first step in the review process is internal review of the charter = with the IESG and the IAB, which will result into discussion in the IESG = telechat on 4/14 and then sending of the charter to external (all IETF = review). > =20 > Question - is this charter text OK for the internal review, or are = there any text changes following the BOF?=20 >=20 > Thanks and Regards, >=20 > Dan > =20 > =20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of Gabor.Bajko@nokia.com > Sent: Thursday, March 24, 2011 12:24 AM > To: paws@ietf.org > Subject: [paws] updated charter proposal >=20 > Folks, > =20 > Here=92s an updated charter proposal. > =20 > But please read these two drafts before you come to the BOF: > =20 > I-D: Protocol to Access White Space database: Problem statement and = Requirements > http://www.ietf.org/id/draft-patil-paws-problem-stmt-00.txt > =20 > I-D: Protocol to Access White Space database: Overview and Use case = scenarios > http://www.ietf.org/id/draft-probasco-paws-overview-usecases-00.txt > =20 > =20 > =20 > 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. > Since the location of a user device is involved, privacy implications = arise, and the protocol will have to have robust security mechanisms. > 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. > 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 > =20 > > =20 > =20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From dromasca@avaya.com Mon Apr 4 08:53:39 2011 Return-Path: X-Original-To: paws@core3.amsl.com Delivered-To: paws@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9225E3A6839 for ; Mon, 4 Apr 2011 08:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.188 X-Spam-Level: X-Spam-Status: No, score=-103.188 tagged_above=-999 required=5 tests=[AWL=0.411, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dw6GEos+wO7w for ; Mon, 4 Apr 2011 08:53:38 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 4F46F28C126 for ; Mon, 4 Apr 2011 08:53:38 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlgHAFMtcU3GmAcF/2dsb2JhbACYaY18dKR5ApkWhWEEkAw X-IronPort-AV: E=Sophos;i="4.63,298,1299474000"; d="scan'208";a="240047551" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 04 Apr 2011 11:55:19 -0400 X-IronPort-AV: E=Sophos;i="4.63,298,1299474000"; d="scan'208";a="605079472" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 04 Apr 2011 11:55:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 4 Apr 2011 17:55:17 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PAWS - acronym already used Thread-Index: Acvy4LGGwEv+kQJcTXi0V9KKSNfDoQ== From: "Romascanu, Dan (Dan)" To: Subject: [paws] PAWS - acronym already used X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 15:53:39 -0000 Hi,=20 I am told that the acronym "PAWS" is already used in the IETF. See RFC 1323.=20 PAWS =3D Protect Against Wrapped Sequence (Numbers) In case this becomes an issue - do we have an alternate acronym for the WG?=20 Thanks and Regards, Dan=20 PS - if possible let us not make this discussion too long :-) From Basavaraj.Patil@nokia.com Mon Apr 4 09:11:09 2011 Return-Path: X-Original-To: paws@core3.amsl.com Delivered-To: paws@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCEF03A6830 for ; Mon, 4 Apr 2011 09:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.606 X-Spam-Level: X-Spam-Status: No, score=-102.606 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1d6l1I9Bsb7 for ; Mon, 4 Apr 2011 09:10:59 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id D882D3A682E for ; Mon, 4 Apr 2011 09:10:58 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p34GCJ0O014196; Mon, 4 Apr 2011 19:12:37 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Apr 2011 19:12:33 +0300 Received: from 008-AM1MMR1-005.mgdnok.nokia.com (65.54.30.60) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 4 Apr 2011 18:12:32 +0200 Received: from 008-AM1MPN1-023.mgdnok.nokia.com ([169.254.3.94]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0270.002; Mon, 4 Apr 2011 18:12:32 +0200 From: To: , Thread-Topic: [paws] PAWS - acronym already used Thread-Index: Acvy4LGGwEv+kQJcTXi0V9KKSNfDof//j3gA Date: Mon, 4 Apr 2011 16:12:31 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [172.19.59.137] Content-Type: text/plain; charset="us-ascii" Content-ID: <9BCA7937ADD48147B3BF38D2704E6860@nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 04 Apr 2011 16:12:33.0089 (UTC) FILETIME=[1AC64310:01CBF2E3] X-Nokia-AV: Clean Subject: Re: [paws] PAWS - acronym already used X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 16:11:11 -0000 Hi Dan, The fact that an RFC exists which uses the same acronym should not be an issue for reusing it as the name of the WG. I would be in favor of keeping the existing acronym for the WG. Alternatively:=20 WhiSQueP (White Space [DB] Query Protocol) -Raj On 4/4/11 10:55 AM, "ext Romascanu, Dan (Dan)" wrote: > > >Hi,=20 > >I am told that the acronym "PAWS" is already used in the IETF. See RFC >1323.=20 > >PAWS =3D Protect Against Wrapped Sequence (Numbers) > >In case this becomes an issue - do we have an alternate acronym for the >WG?=20 > >Thanks and Regards, > >Dan=20 > >PS - if possible let us not make this discussion too long :-) >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From dromasca@avaya.com Mon Apr 4 09:22:10 2011 Return-Path: X-Original-To: paws@core3.amsl.com Delivered-To: paws@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E84F93A69C2 for ; Mon, 4 Apr 2011 09:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.19 X-Spam-Level: X-Spam-Status: No, score=-103.19 tagged_above=-999 required=5 tests=[AWL=0.409, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zQpxs2VJcCv for ; Mon, 4 Apr 2011 09:21:53 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 7B93F3A69CC for ; Mon, 4 Apr 2011 09:21:46 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYAAFMtcU3GmAcF/2dsb2JhbACYKo47dKR5ApkWhWEEkAw X-IronPort-AV: E=Sophos;i="4.63,298,1299474000"; d="scan'208";a="240053845" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 04 Apr 2011 12:23:28 -0400 X-IronPort-AV: E=Sophos;i="4.63,298,1299474000"; d="scan'208";a="605092305" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 04 Apr 2011 12:23:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 4 Apr 2011 18:23:25 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [paws] PAWS - acronym already used Thread-Index: Acvy4LGGwEv+kQJcTXi0V9KKSNfDof//j3gA//+JA3A= References: From: "Romascanu, Dan (Dan)" To: , Subject: Re: [paws] PAWS - acronym already used X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 16:22:11 -0000 Hi,=20 You mean=20 > whisqy (WHIte Space [db] QuerY protocol)? :-) Seriously - I am also in favor of keeping PAWS. I hope that I can convince my colleagues that the acronym clash is not an issue.=20 =20 Thanks and Regards, Dan=20 =20 > -----Original Message----- > From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com]=20 > Sent: Monday, April 04, 2011 7:13 PM > To: Romascanu, Dan (Dan); paws@ietf.org > Subject: Re: [paws] PAWS - acronym already used >=20 >=20 > Hi Dan, >=20 > The fact that an RFC exists which uses the same acronym=20 > should not be an issue for reusing it as the name of the WG. >=20 > I would be in favor of keeping the existing acronym for the WG. >=20 > Alternatively:=20 > WhiSQueP (White Space [DB] Query Protocol) >=20 > -Raj >=20 > On 4/4/11 10:55 AM, "ext Romascanu, Dan (Dan)"=20 > wrote: >=20 > > > > > >Hi, > > > >I am told that the acronym "PAWS" is already used in the=20 > IETF. See RFC=20 > >1323. > > > >PAWS =3D Protect Against Wrapped Sequence (Numbers) > > > >In case this becomes an issue - do we have an alternate=20 > acronym for the=20 > >WG? > > > >Thanks and Regards, > > > >Dan > > > >PS - if possible let us not make this discussion too long :-)=20 > >_______________________________________________ > >paws mailing list > >paws@ietf.org > >https://www.ietf.org/mailman/listinfo/paws >=20 >=20 From caulfield.jesse@gmail.com Mon Apr 4 10:42:24 2011 Return-Path: X-Original-To: paws@core3.amsl.com Delivered-To: paws@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 353FC3A6A19 for ; Mon, 4 Apr 2011 10:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+LehInHMf3g for ; Mon, 4 Apr 2011 10:42:23 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id D7C2F3A6A18 for ; Mon, 4 Apr 2011 10:42:22 -0700 (PDT) Received: by qwc23 with SMTP id 23so601282qwc.31 for ; Mon, 04 Apr 2011 10:44:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=nCmXyCLg7QFrHZ4GSIN6yNi+8VtQG4duUd4AopH+M40=; b=f71GZJGRV+egXQPj9qCJ9p/Ww+lPzV/lGOTIlo+1RhH1OUQXzpipZHtDs+N+47GsmC FpAUjz4CBARNrU9qdRzyrhz6NULn3FyNiU4q1B704clDjt57dhx5tdD4XmP3NXzM9wiL ZMHH0laBk3H24qdMmR9aQPlqetNXyR53ZvJOo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; b=Xpe1tC1Ue4EnKce5z4TaB2PvRzl0mMO5TpS4cpZDiTexCRi8LdUl0IugvE6qQ6q2Dh kcQ1rPC/V3KSfc7ieVE8IfNRPFEg7NjbHYZvNH1VQ2cNrm7P3nF8XorvD/GkjwBjdXMd Wrr4/5qWgPXV1LRxJ2ahB7sCmTJP4w5yAmx0E= Received: by 10.229.42.73 with SMTP id r9mr5898192qce.189.1301939045251; Mon, 04 Apr 2011 10:44:05 -0700 (PDT) Received: from JMCLaptop (pool-173-66-247-16.washdc.fios.verizon.net [173.66.247.16]) by mx.google.com with ESMTPS id m7sm3603337qcg.29.2011.04.04.10.44.04 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Apr 2011 10:44:04 -0700 (PDT) From: "Jesse Caulfield" To: References: In-Reply-To: Date: Mon, 4 Apr 2011 13:44:01 -0400 Message-ID: <4d9a0364.8735e50a.3239.ffff9737@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acvy4LGGwEv+kQJcTXi0V9KKSNfDof//j3gA//9+4fA= Content-Language: en-us Subject: Re: [paws] PAWS - acronym already used / how about GSS X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 17:42:24 -0000 Group, My family is active in PAWS Chicago, an animal rescue effort, and the = free publicity will be great. Animal themes also work well for O'Reilly = books, so maybe PAWS is fine, but ... The white spaces concept is essentially a Coordinated Geographic = Spectrum Sharing strategy. There is a cognitive radio tie-in, but not necessarily = a strong one. Perhaps "GSS" or "CGSS" ? On a serious note: I'm very excited about the gathering momentum of this group. I look forward to providing whatever contributions to help it succeed. -- Jesse Caulfield, President Key Bridge Global LLC 1600 Tysons Blvd.,=A0 Suite 450 McLean, VA 22102 -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Basavaraj.Patil@nokia.com Sent: Monday, April 04, 2011 12:13 PM To: dromasca@avaya.com; paws@ietf.org Subject: Re: [paws] PAWS - acronym already used Hi Dan, The fact that an RFC exists which uses the same acronym should not be an issue for reusing it as the name of the WG. I would be in favor of keeping the existing acronym for the WG. Alternatively:=20 WhiSQueP (White Space [DB] Query Protocol) -Raj On 4/4/11 10:55 AM, "ext Romascanu, Dan (Dan)" = wrote: > > >Hi,=20 > >I am told that the acronym "PAWS" is already used in the IETF. See RFC >1323.=20 > >PAWS =3D Protect Against Wrapped Sequence (Numbers) > >In case this becomes an issue - do we have an alternate acronym for the >WG?=20 > >Thanks and Regards, > >Dan=20 > >PS - if possible let us not make this discussion too long :-) >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From brian.rosen@neustar.biz Mon Apr 4 10:51:04 2011 Return-Path: X-Original-To: paws@core3.amsl.com Delivered-To: paws@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2DF33A69C1 for ; Mon, 4 Apr 2011 10:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.153 X-Spam-Level: X-Spam-Status: No, score=-6.153 tagged_above=-999 required=5 tests=[AWL=0.446, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94Co4cvpE5BN for ; Mon, 4 Apr 2011 10:51:02 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by core3.amsl.com (Postfix) with ESMTP id 89D053A698E for ; Mon, 4 Apr 2011 10:51:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1301939560; x=1617278568; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=ac1jQjqiLctpxlPo5n4CA IrEoL++eawhjoe/ztUWaGg=; b=P4GQfstwJyJDgfmadQkwHNmu7Ijerl+VO5oak EBJAkzkiPsKThMEm79NgrQoGUmxsBPnDUui9P8hzphXphqF6w== Received: from ([10.31.13.229]) by stihiron1.va.neustar.com with ESMTP with TLS id G6K7MJ1.21240919; Mon, 04 Apr 2011 13:52:39 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Mon, 4 Apr 2011 13:52:38 -0400 From: "Rosen, Brian" To: Jesse Caulfield Date: Mon, 4 Apr 2011 13:52:37 -0400 Thread-Topic: [paws] PAWS - acronym already used / how about GSS Thread-Index: Acvy8RYeSPWuVL2LSE2q/ghpekkjNg== Message-ID: <8E81BE17-BBE9-4790-992E-89AE6426FBA8@neustar.biz> References: <4d9a0364.8735e50a.3239.ffff9737@mx.google.com> In-Reply-To: <4d9a0364.8735e50a.3239.ffff9737@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: /LEJqwrMp7YzX0pZH11k0Q== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] PAWS - acronym already used / how about GSS X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 17:51:04 -0000 Hi Jesse Unfortunately, GSS is a well known IETF acronym for Generic Security System= . The PAWS re-use is MUCH less of an intrusion on existing acronyms than anyt= hing related to GSS. It's generally true that IETF work groups contort the acronym definition to= make a pronounceable work group name.=20 Brian On Apr 4, 2011, at 1:44 PM, Jesse Caulfield wrote: > Group, >=20 > My family is active in PAWS Chicago, an animal rescue effort, and the fre= e > publicity will be great. Animal themes also work well for O'Reilly books,= so > maybe PAWS is fine, but ... >=20 > The white spaces concept is essentially a Coordinated Geographic Spectrum > Sharing strategy. There is a cognitive radio tie-in, but not necessarily = a > strong one. >=20 > Perhaps "GSS" or "CGSS" ? >=20 > On a serious note: I'm very excited about the gathering momentum of this > group. I look forward to providing whatever contributions to help it > succeed. >=20 > -- > Jesse Caulfield, President > Key Bridge Global LLC > 1600 Tysons Blvd., Suite 450 > McLean, VA 22102 >=20 >=20 >=20 > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of > Basavaraj.Patil@nokia.com > Sent: Monday, April 04, 2011 12:13 PM > To: dromasca@avaya.com; paws@ietf.org > Subject: Re: [paws] PAWS - acronym already used >=20 >=20 > Hi Dan, >=20 > The fact that an RFC exists which uses the same acronym should not be an > issue for reusing it as the name of the WG. >=20 > I would be in favor of keeping the existing acronym for the WG. >=20 > Alternatively:=20 > WhiSQueP (White Space [DB] Query Protocol) >=20 > -Raj >=20 > On 4/4/11 10:55 AM, "ext Romascanu, Dan (Dan)" wrote= : >=20 >>=20 >>=20 >> Hi,=20 >>=20 >> I am told that the acronym "PAWS" is already used in the IETF. See RFC >> 1323.=20 >>=20 >> PAWS =3D Protect Against Wrapped Sequence (Numbers) >>=20 >> In case this becomes an issue - do we have an alternate acronym for the >> WG?=20 >>=20 >> Thanks and Regards, >>=20 >> Dan=20 >>=20 >> PS - if possible let us not make this discussion too long :-) >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From richard@shockey.us Mon Apr 4 13:12:43 2011 Return-Path: X-Original-To: paws@core3.amsl.com Delivered-To: paws@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F2CF28C105 for ; Mon, 4 Apr 2011 13:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.142 X-Spam-Level: X-Spam-Status: No, score=-102.142 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Vew2yrJIhWY for ; Mon, 4 Apr 2011 13:12:42 -0700 (PDT) Received: from oproxy3-pub.bluehost.com (oproxy3-pub.bluehost.com [69.89.21.8]) by core3.amsl.com (Postfix) with SMTP id 76CF428C0F8 for ; Mon, 4 Apr 2011 13:12:42 -0700 (PDT) Received: (qmail 3754 invoked by uid 0); 4 Apr 2011 20:14:20 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy3.bluehost.com with SMTP; 4 Apr 2011 20:14:20 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=i5iOIGcWH2oTJgCZR3/69ozghYWNkIQSR4RY917kH1d4Hx0UgDdcidF3uTdZW6DGj+x6Nmd8S+kflwZkxlUbdhk8bQ7Yqx1NN5guIl5J6Ug0wSxWfFFeaRVrTJS+yIsA; Received: from pool-71-178-24-118.washdc.fios.verizon.net ([71.178.24.118] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Q6qAF-0004Ct-T1; Mon, 04 Apr 2011 14:14:20 -0600 From: "Richard Shockey" To: "'Romascanu, Dan \(Dan\)'" , References: In-Reply-To: Date: Mon, 4 Apr 2011 16:14:18 -0400 Message-ID: <003901cbf304$e1ab74c0$a5025e40$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acvy4LGGwEv+kQJcTXi0V9KKSNfDof//j3gA//+JA3D//tHn8A== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.178.24.118 authed with richard@shockey.us} Subject: Re: [paws] PAWS - acronym already used X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 20:12:43 -0000 Ok this is where it gets fun ..how about DAWGS (pronounced DOGS) Database Access to White space Geospatial information Systems They you can have all sorts of great ID's Hot-DAWGS Mustard-DAWGS Chili-DAWGS And of course my favorite Spotted-DAWGS -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Monday, April 04, 2011 12:23 PM To: Basavaraj.Patil@nokia.com; paws@ietf.org Subject: Re: [paws] PAWS - acronym already used Hi, You mean > whisqy (WHIte Space [db] QuerY protocol)? :-) Seriously - I am also in favor of keeping PAWS. I hope that I can convince my colleagues that the acronym clash is not an issue. Thanks and Regards, Dan > -----Original Message----- > From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] > Sent: Monday, April 04, 2011 7:13 PM > To: Romascanu, Dan (Dan); paws@ietf.org > Subject: Re: [paws] PAWS - acronym already used > > > Hi Dan, > > The fact that an RFC exists which uses the same acronym > should not be an issue for reusing it as the name of the WG. > > I would be in favor of keeping the existing acronym for the WG. > > Alternatively: > WhiSQueP (White Space [DB] Query Protocol) Yuck .. sorry. > > -Raj > > On 4/4/11 10:55 AM, "ext Romascanu, Dan (Dan)" > wrote: > > > > > > >Hi, > > > >I am told that the acronym "PAWS" is already used in the > IETF. See RFC > >1323. > > > >PAWS = Protect Against Wrapped Sequence (Numbers) > > > >In case this becomes an issue - do we have an alternate > acronym for the > >WG? > > > >Thanks and Regards, > > > >Dan > > > >PS - if possible let us not make this discussion too long :-) > >_______________________________________________ > >paws mailing list > >paws@ietf.org > >https://www.ietf.org/mailman/listinfo/paws > > _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From ajs@shinkuro.com Mon Apr 4 13:27:48 2011 Return-Path: X-Original-To: paws@core3.amsl.com Delivered-To: paws@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 680A628C0E2 for ; Mon, 4 Apr 2011 13:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTbuwaT73Yrp for ; Mon, 4 Apr 2011 13:27:46 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 7DB4728C0F8 for ; Mon, 4 Apr 2011 13:27:46 -0700 (PDT) Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id C50931ECB422 for ; Mon, 4 Apr 2011 20:29:28 +0000 (UTC) Date: Mon, 4 Apr 2011 16:29:27 -0400 From: Andrew Sullivan To: paws@ietf.org Message-ID: <20110404202926.GJ210@crankycanuck.ca> References: <003901cbf304$e1ab74c0$a5025e40$@us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003901cbf304$e1ab74c0$a5025e40$@us> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [paws] PAWS - acronym already used X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 20:27:48 -0000 Believe it or not, On Mon, Apr 04, 2011 at 04:14:18PM -0400, Richard Shockey wrote: > DAWGS (pronounced DOGS) > Hot-DAWGS only those two could be WG names. There's a length limit of 8, enshrined by RFC 2418. Which makes it rather more important that the IESG not go around the world looking for possibly conflicting acronyms. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From brian.rosen@neustar.biz Mon Apr 4 13:32:46 2011 Return-Path: X-Original-To: paws@core3.amsl.com Delivered-To: paws@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4C3928C0F8 for ; Mon, 4 Apr 2011 13:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.181 X-Spam-Level: X-Spam-Status: No, score=-6.181 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cx3vVJOTQCFE for ; Mon, 4 Apr 2011 13:32:45 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by core3.amsl.com (Postfix) with ESMTP id 7901128C0E5 for ; Mon, 4 Apr 2011 13:32:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1301949263; x=1617268732; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=poye6yVFxL+e6ZV7EWRuL GEKxQAFl5VT1KHV77OEJGU=; b=dMQ3iwGJWviZ9evian8f5Ww8IERDIynXAkYra K6lxtUy20ogaX7ruuqtuy2w09GgJisaKkvqA/rX90vN+V7UoQ== Received: from ([10.31.13.229]) by chihiron1.nc.neustar.com with ESMTP with TLS id 5202942.37785470; Mon, 04 Apr 2011 16:34:22 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Mon, 4 Apr 2011 16:34:21 -0400 From: "Rosen, Brian" To: Andrew Sullivan Date: Mon, 4 Apr 2011 16:34:20 -0400 Thread-Topic: [paws] PAWS - acronym already used Thread-Index: AcvzB61rI0cRQnGORwCMUthHOZA4rw== Message-ID: References: <003901cbf304$e1ab74c0$a5025e40$@us> <20110404202926.GJ210@crankycanuck.ca> In-Reply-To: <20110404202926.GJ210@crankycanuck.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: lRCm36u8nMApBIIAR3lhHQ== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] PAWS - acronym already used X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 20:32:47 -0000 I think the proposal was the work group name could be DAWGS, and the others= were derivative terms we could use for all kinds of mischief. Kind of like "CLUE-less" for the clue work group. Brian On Apr 4, 2011, at 4:29 PM, Andrew Sullivan wrote: > Believe it or not,=20 >=20 > On Mon, Apr 04, 2011 at 04:14:18PM -0400, Richard Shockey wrote: >=20 >> DAWGS (pronounced DOGS)=20 >> Hot-DAWGS >=20 > only those two could be WG names. There's a length limit of 8, > enshrined by RFC 2418. Which makes it rather more important that the > IESG not go around the world looking for possibly conflicting > acronyms. >=20 > A >=20 > --=20 > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From ajs@shinkuro.com Mon Apr 4 13:36:21 2011 Return-Path: X-Original-To: paws@core3.amsl.com Delivered-To: paws@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A64EA3A67D6 for ; Mon, 4 Apr 2011 13:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iz-JcREOmymU for ; Mon, 4 Apr 2011 13:36:21 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 1F8513A67D3 for ; Mon, 4 Apr 2011 13:36:21 -0700 (PDT) Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id BFC3E1ECB422; Mon, 4 Apr 2011 20:38:02 +0000 (UTC) Date: Mon, 4 Apr 2011 16:38:01 -0400 From: Andrew Sullivan To: "Rosen, Brian" Message-ID: <20110404203800.GL210@crankycanuck.ca> References: <003901cbf304$e1ab74c0$a5025e40$@us> <20110404202926.GJ210@crankycanuck.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "paws@ietf.org" Subject: Re: [paws] PAWS - acronym already used X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 20:36:21 -0000 On Mon, Apr 04, 2011 at 04:34:20PM -0400, Rosen, Brian wrote: > I think the proposal was the work group name could be DAWGS, and the others were derivative terms we could use for all kinds of mischief. > Ah, I see. Well, I still think the IESG shouldn't borrow trouble. It seems to arrive, with interest, on its own every day. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From richard@shockey.us Mon Apr 4 13:38:42 2011 Return-Path: X-Original-To: paws@core3.amsl.com Delivered-To: paws@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F00DA3A67E1 for ; Mon, 4 Apr 2011 13:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.313 X-Spam-Level: X-Spam-Status: No, score=-102.313 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAWZhEZJbJ-R for ; Mon, 4 Apr 2011 13:38:41 -0700 (PDT) Received: from oproxy1-pub.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id 7820E3A67B7 for ; Mon, 4 Apr 2011 13:38:34 -0700 (PDT) Received: (qmail 25984 invoked by uid 0); 4 Apr 2011 20:40:17 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by cpoproxy1.bluehost.com with SMTP; 4 Apr 2011 20:40:17 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=WigHqsh36k6a/dmHWyZdFL7dtq5UsY8hQY29SPu/7gSoJewQiaMHYxXFn4B4eexZ0GriSg/qn4Yrx3adC3rCe2ljzPl9H4o0nmFK3Y1qGq+NRyV/NELHzsXz//hVHaTJ; Received: from pool-71-178-24-118.washdc.fios.verizon.net ([71.178.24.118] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Q6qZM-0005tg-S6; Mon, 04 Apr 2011 14:40:17 -0600 From: "Richard Shockey" To: "'Rosen, Brian'" , "'Andrew Sullivan'" References: <003901cbf304$e1ab74c0$a5025e40$@us> <20110404202926.GJ210@crankycanuck.ca> In-Reply-To: Date: Mon, 4 Apr 2011 16:40:15 -0400 Message-ID: <004601cbf308$81afc860$850f5920$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvzB61rI0cRQnGORwCMUthHOZA4rwAADWkQ Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.178.24.118 authed with richard@shockey.us} Cc: paws@ietf.org Subject: Re: [paws] PAWS - acronym already used X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 20:38:42 -0000 Right DAWGS is the proposed WG name, we now have a long standing IETF tradition of mischievous ID names like RFC 6140 whos original ID name was. http://www.ietf.org/id/draft-ietf-martini-gin-13.txt we also had martini-olives etc.. sadly no martini-shakennotstired -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Rosen, Brian Sent: Monday, April 04, 2011 4:34 PM To: Andrew Sullivan Cc: paws@ietf.org Subject: Re: [paws] PAWS - acronym already used I think the proposal was the work group name could be DAWGS, and the others were derivative terms we could use for all kinds of mischief. Kind of like "CLUE-less" for the clue work group. Brian On Apr 4, 2011, at 4:29 PM, Andrew Sullivan wrote: > Believe it or not, > > On Mon, Apr 04, 2011 at 04:14:18PM -0400, Richard Shockey wrote: > >> DAWGS (pronounced DOGS) >> Hot-DAWGS > > only those two could be WG names. There's a length limit of 8, > enshrined by RFC 2418. Which makes it rather more important that the > IESG not go around the world looking for possibly conflicting > acronyms. > > A > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From richard@shockey.us Mon Apr 4 14:12:37 2011 Return-Path: X-Original-To: paws@core3.amsl.com Delivered-To: paws@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 054403A6805 for ; Mon, 4 Apr 2011 14:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.156 X-Spam-Level: X-Spam-Status: No, score=-102.156 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnTcrSP1UqrK for ; Mon, 4 Apr 2011 14:12:36 -0700 (PDT) Received: from cpoproxy3-pub.bluehost.com (cpoproxy3-pub.bluehost.com [67.222.54.6]) by core3.amsl.com (Postfix) with SMTP id 1C9B43A67AA for ; Mon, 4 Apr 2011 14:12:36 -0700 (PDT) Received: (qmail 19932 invoked by uid 0); 4 Apr 2011 21:14:18 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by cpoproxy3.bluehost.com with SMTP; 4 Apr 2011 21:14:18 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=l6TflKpTRGg+k7yXPe7BBTKokDeqRT7ln0GwzrHeb0bW7F8D1j+EHxGvDSmf8VIBA+NLUwwFlX0mzSEKBHadRu9s5zYdBEZ2X8xaPfu3ZCGzqJjm7GfhZzBXtN07b97/; Received: from pool-71-178-24-118.washdc.fios.verizon.net ([71.178.24.118] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Q6r6H-0005Zy-W3; Mon, 04 Apr 2011 15:14:18 -0600 From: "Richard Shockey" To: "'Andrew Sullivan'" , "'Rosen, Brian'" References: <003901cbf304$e1ab74c0$a5025e40$@us> <20110404202926.GJ210@crankycanuck.ca> <20110404203800.GL210@crankycanuck.ca> In-Reply-To: <20110404203800.GL210@crankycanuck.ca> Date: Mon, 4 Apr 2011 17:14:16 -0400 Message-ID: <005901cbf30d$42493710$c6dba530$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvzCDOHhjVTzHRBR6KcTaO95+xrcgABNMOg Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.178.24.118 authed with richard@shockey.us} Cc: paws@ietf.org Subject: Re: [paws] PAWS - acronym already used X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 21:12:37 -0000 You may have a point ..we certainly have not yet had our annual rite of spring .. the pointless and banal discussion of ASCII in Internet Drafts. That said .. if you cant have any fun doing this what's the point. -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Andrew Sullivan Sent: Monday, April 04, 2011 4:38 PM To: Rosen, Brian Cc: paws@ietf.org Subject: Re: [paws] PAWS - acronym already used On Mon, Apr 04, 2011 at 04:34:20PM -0400, Rosen, Brian wrote: > I think the proposal was the work group name could be DAWGS, and the others were derivative terms we could use for all kinds of mischief. > Ah, I see. Well, I still think the IESG shouldn't borrow trouble. It seems to arrive, with interest, on its own every day. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From scott.probasco@nokia.com Tue Apr 5 00:14:27 2011 Return-Path: X-Original-To: paws@core3.amsl.com Delivered-To: paws@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D957E3A68C6 for ; Tue, 5 Apr 2011 00:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.749 X-Spam-Level: X-Spam-Status: No, score=-2.749 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5O88+cG-jEv for ; Tue, 5 Apr 2011 00:14:25 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by core3.amsl.com (Postfix) with ESMTP id CB13A3A67EF for ; Tue, 5 Apr 2011 00:14:24 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p357G6ND030616; Tue, 5 Apr 2011 10:16:06 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 5 Apr 2011 10:15:55 +0300 Received: from 008-AM1MMR1-003.mgdnok.nokia.com (65.54.30.58) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 5 Apr 2011 09:15:46 +0200 Received: from 008-AM1MPN1-021.mgdnok.nokia.com ([169.254.1.101]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.01.0270.002; Tue, 5 Apr 2011 09:15:46 +0200 From: To: , , Thread-Topic: [paws] updated charter proposal Thread-Index: Acvpp7RYjKt+gGFGREWtx/nICrQjPAGlqm/w///j9gCAAKkHAIAAAXEAgAAHwYCABCbJAP/+eTvw Date: Tue, 5 Apr 2011 07:15:45 +0000 Message-ID: <88BE24FD9280884487DEAE0CE1FD3A5B047E4E@008-AM1MPN1-021.mgdnok.nokia.com> References: <7DDB35B005136A4DB9FF33E7E286EF00066340@008-AM1MPN1-037.mgdnok.nokia.com> <7BAC95F5A7E67643AAFB2C31BEE662D014068D317A@SC-VEXCH2.marvell.com> <7BAC95F5A7E67643AAFB2C31BEE662D014068D319A@SC-VEXCH2.marvell.com> <26B8D793-D4EE-43ED-855F-3EDE5657E768@inf-net.nl> In-Reply-To: <26B8D793-D4EE-43ED-855F-3EDE5657E768@inf-net.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-version: 3.2.55 x-tituslabs-classifications-30: TLPropertyRoot=Trial License;Classification=Personal; x-putclassificationandsendinfointox-header: Classification: Personal Project: Subject: RE: [paws] updated charter proposal Sender Name: Probasco Scott (Nokia-CIC/Dallas) Sender Email: scott.probasco@nokia.com Send Date: Tuesday, April 05, 2011 Send Time: 2:15:45 AM x-originating-ip: [10.236.12.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 05 Apr 2011 07:15:55.0762 (UTC) FILETIME=[4E15CD20:01CBF361] X-Nokia-AV: Clean Cc: Gabor.Bajko@nokia.com, Brian.Rosen@neustar.biz, william.polk@nist.gov Subject: Re: [paws] updated charter proposal X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 07:14:27 -0000 Hi, IMHO "Robust security mechanisms" is broad enough to include non-repudiatio= n without having to identify it specifically. Not saying at this point that= non-repudiation must be included in PAWS (a subtle vote for WG name), only= that I believe the proposed charter wording allows the possibility, if the= group decides it is needed. Regards, Scott -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= Teco Boot Sent: Monday, April 04, 2011 4:50 AM To: Paul Lambert Cc: paws@ietf.org; Rosen, Brian; Polk, William T.; Bajko Gabor (Nokia-CIC/S= iliconValley) Subject: Re: [paws] updated charter proposal I'm not sure on requirements for non-repudiation. Should a secondary user k= eep evidence that it legally use (or used) a granted channel? It may have i= mpact on the protocol. Teco Op 1 apr 2011, om 20:25 heeft Paul Lambert het volgende geschreven: > > I think Tim Polk wanted more words about security beyond just these. > Oh ... ok > =20 > I believe these are the overall threat areas: > device identity spoofing > modification of device requests > modification of channel enablement information > impersonation of registered database services > unauthorized disclosure of a users location > =20 > There may be other broader ways to phrase these - but we need to be caref= ul not to slip into device internal security versus the security of the pro= tocol. > =20 > Translating the above into charter speak and as a revised suggestion: > =20 > =20 > The protocol must protect both the channel enablement process and the pri= vacy of users. =20 > Robust security mechanisms are required to prevent: device identity spoof= ing, modification=20 > of device requests, modification of channel enablement information, imper= sonation of=20 > registered database services and unauthorized disclosure of a users locat= ion. > =20 > =20 > =20 > Hope this helps ... > =20 > Paul > =20 > =20 > Paul A. Lambert | Marvell | +1 650 787 9141 > =20 > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 > Sent: Friday, April 01, 2011 10:58 AM > To: Paul Lambert > Cc: Romascanu, Dan (Dan); Gabor.Bajko@nokia.com (Nokia-CIC/SiliconValley)= ; paws@ietf.org; Polk, William T. > Subject: Re: [paws] updated charter proposal > =20 > I think Tim Polk wanted more words about security beyond just these. > =20 > Brian > =20 > On Apr 1, 2011, at 7:52 PM, Paul Lambert wrote: >=20 >=20 > =20 > Friendly edit (below): > =20 > Since the location of a user device is involved, privacy implications ari= se. The protocol must have robust mechanisms for mutual authentication and= must prevent the unauthorized disclosure of a users location. > =20 > =20 > Paul > =20 > Paul A. Lambert | Marvell | +1 650 787 9141 > =20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of R= osen, Brian > Sent: Friday, April 01, 2011 12:48 AM > To: Romascanu, Dan (Dan) > Cc: Gabor.Bajko@nokia.com (Nokia-CIC/SiliconValley); paws@ietf.org; Polk,= William T. > Subject: Re: [paws] updated charter proposal > =20 > Good news! There were charter changes requested in the BoF in the securi= ty section. =20 > =20 > I suggest that the line in the charter: > Since the location of a user device is involved, privacy implications ari= se, and the protocol will have to have robust security mechanisms. > =20 > Be changed to: > Since the location of a user device is involved, privacy implications ari= se, and the protocol will have to have robust security and privacy mechanis= ms. There are other security concerns, including spoofing and man in the m= iddle attacks that will require analysis and mechanisms for mitigation in t= he protocol. > =20 > Brian > =20 > On Apr 1, 2011, at 9:33 AM, Romascanu, Dan (Dan) wrote: >=20 >=20 >=20 > =20 > =20 > Hi, >=20 > I reported in the IESG and IAB meeting this morning about the PAWS BOF, w= hich in my opinion went quite well. My recommendation to continue the proce= ss with the chartering of a PAWS WG was well received. The WG (if approved = after the review process) will be in the OPS area with a Technical Advisor = from APPS. >=20 > The first step in the review process is internal review of the charter wi= th the IESG and the IAB, which will result into discussion in the IESG tele= chat on 4/14 and then sending of the charter to external (all IETF review). > =20 > Question - is this charter text OK for the internal review, or are there = any text changes following the BOF?=20 >=20 > Thanks and Regards, >=20 > Dan > =20 > =20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of G= abor.Bajko@nokia.com > Sent: Thursday, March 24, 2011 12:24 AM > To: paws@ietf.org > Subject: [paws] updated charter proposal >=20 > Folks, > =20 > Here's an updated charter proposal. > =20 > But please read these two drafts before you come to the BOF: > =20 > I-D: Protocol to Access White Space database: Problem statement and Requi= rements > http://www.ietf.org/id/draft-patil-paws-problem-stmt-00.txt > =20 > I-D: Protocol to Access White Space database: Overview and Use case scena= rios > http://www.ietf.org/id/draft-probasco-paws-overview-usecases-00.txt > =20 > =20 > =20 > Governments around the world continue to search for new pieces of radio s= pectrum 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 t= o a primary user is a technique to "unlock" existing spectrum for new use. = An obvious requirement is that these secondary transmissions do not interfe= re with the primary use of the spectrum. Often, in a given physical locatio= n, 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 locati= on of the secondary user. The primary user may have a schedule when it use= s the spectrum, which may be available for secondary use outside that sched= ule. The fundamental issue is how to determine for a specific location and= specific time, if any of the primary spectrum is available for secondary u= se. One simple mechanism is to use a geospatial database that records prote= cted contours for primary users, and require the secondary users to check t= he database prior to selecting what part of the spectrum they use. Such da= tabases could be available on the Internet for query by users. > In a typical implementation of geolocation and database to access TV whit= e 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 t= ransmit 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 spac= e" spectrum (for example, in a TV White space implementation, the list of a= vailable 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 ch= annel. 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 spec= ified threshold. > The databases are expected to be reachable via the Internet and the devic= es querying these databases are expected to have some form of Internet conn= ectivity, directly or indirectly. The databases may be country specific si= nce the available spectrum and regulations may vary, but the fundamental o= peration of the protocol should be country independent, thus extensibility = of data structures will be required. The solution will not be tied to any s= pecific spectrum, country, or phy/mac/air interface but may incorporate rel= evant 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 proto= col, and application services. > - Standardize the data structure to be carried by the query protocol. > Since the location of a user device is involved, privacy implications ari= se, and the protocol will have to have robust security mechanisms. > Existing IETF location data structures and privacy mechanisms may be cons= idered 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 liaiso= n 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 fr= om regulatory entities that are involved in the specification of the rules = for secondary use of spectrum in specific bands. > 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 > =20 > > =20 > =20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From Ian.Ferrell@microsoft.com Tue Apr 5 07:22:11 2011 Return-Path: X-Original-To: paws@core3.amsl.com Delivered-To: paws@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C91A28C156 for ; Tue, 5 Apr 2011 07:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOxc8OfteQKK for ; Tue, 5 Apr 2011 07:22:04 -0700 (PDT) Received: from mail.exchange.microsoft.com (mail7.exchange.microsoft.com [131.107.1.27]) by core3.amsl.com (Postfix) with ESMTP id 9845028C155 for ; Tue, 5 Apr 2011 07:22:04 -0700 (PDT) Received: from df-h14-01.exchange.corp.microsoft.com (157.54.78.139) by DF-G14-02.exchange.corp.microsoft.com (157.54.87.56) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 5 Apr 2011 07:23:47 -0700 Received: from DF-M14-04.exchange.corp.microsoft.com ([169.254.1.156]) by DF-H14-01.exchange.corp.microsoft.com ([157.54.78.139]) with mapi id 14.01.0289.008; Tue, 5 Apr 2011 07:23:47 -0700 From: Ian Ferrell To: "paws@ietf.org" Thread-Topic: [paws] updated charter proposal Thread-Index: Acvpp7RYjKt+gGFGREWtx/nICrQjPAGlqm/wAA9a0QAAFSDTAAAALjIAAAD4GoAAhNkSAAAs6nuAAAAZwHA= Date: Tue, 5 Apr 2011 14:23:47 +0000 Message-ID: <0EFF0D1AF5667241950D9A9D1D681FBD4AE4C3FA@DF-M14-04.exchange.corp.microsoft.com> References: <7DDB35B005136A4DB9FF33E7E286EF00066340@008-AM1MPN1-037.mgdnok.nokia.com> <7BAC95F5A7E67643AAFB2C31BEE662D014068D317A@SC-VEXCH2.marvell.com> <7BAC95F5A7E67643AAFB2C31BEE662D014068D319A@SC-VEXCH2.marvell.com> <26B8D793-D4EE-43ED-855F-3EDE5657E768@inf-net.nl> <88BE24FD9280884487DEAE0CE1FD3A5B047E4E@008-AM1MPN1-021.mgdnok.nokia.com> In-Reply-To: <88BE24FD9280884487DEAE0CE1FD3A5B047E4E@008-AM1MPN1-021.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.110] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 05 Apr 2011 07:25:23 -0700 Subject: Re: [paws] updated charter proposal X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 14:23:21 -0000 Teco, are you concerned that a rogue entity could set up at a location and = tell devices around it that Channel X is available--when in fact the channe= l is occupied by a licensed broadcaster--and thus wreak havoc? So, in this = scenario, devices would need some mechanism to defend their channel use? FWIW, I didn't see anything about this in the FCC order--I think the assump= tion on their part is that Device FOO has some mechanism to determine it is= talking to a legal database so rogue entities would not be able to spoof b= ad permissions. -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of sco= tt.probasco@nokia.com Sent: Tuesday, April 05, 2011 12:16 AM To: teco@inf-net.nl; paul@marvell.com; paws@ietf.org Cc: Gabor.Bajko@nokia.com; Brian.Rosen@neustar.biz; william.polk@nist.gov Subject: Re: [paws] updated charter proposal Hi, IMHO "Robust security mechanisms" is broad enough to include non-repudiatio= n without having to identify it specifically. Not saying at this point that= non-repudiation must be included in PAWS (a subtle vote for WG name), only= that I believe the proposed charter wording allows the possibility, if the= group decides it is needed. Regards, Scott -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= Teco Boot Sent: Monday, April 04, 2011 4:50 AM To: Paul Lambert Cc: paws@ietf.org; Rosen, Brian; Polk, William T.; Bajko Gabor (Nokia-CIC/S= iliconValley) Subject: Re: [paws] updated charter proposal I'm not sure on requirements for non-repudiation. Should a secondary user k= eep evidence that it legally use (or used) a granted channel? It may have i= mpact on the protocol. Teco Op 1 apr 2011, om 20:25 heeft Paul Lambert het volgende geschreven: > > I think Tim Polk wanted more words about security beyond just these. > Oh ... ok > =20 > I believe these are the overall threat areas: > device identity spoofing > modification of device requests > modification of channel enablement information impersonation of=20 > registered database services unauthorized disclosure of a users=20 > location > =20 > There may be other broader ways to phrase these - but we need to be caref= ul not to slip into device internal security versus the security of the pro= tocol. > =20 > Translating the above into charter speak and as a revised suggestion: > =20 > =20 > The protocol must protect both the channel enablement process and the pri= vacy of users. =20 > Robust security mechanisms are required to prevent: device identity=20 > spoofing, modification of device requests, modification of channel=20 > enablement information, impersonation of registered database services and= unauthorized disclosure of a users location. > =20 > =20 > =20 > Hope this helps ... > =20 > Paul > =20 > =20 > Paul A. Lambert | Marvell | +1 650 787 9141 > =20 > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > Sent: Friday, April 01, 2011 10:58 AM > To: Paul Lambert > Cc: Romascanu, Dan (Dan); Gabor.Bajko@nokia.com (Nokia-CIC/SiliconValley)= ; paws@ietf.org; Polk, William T. > Subject: Re: [paws] updated charter proposal > =20 > I think Tim Polk wanted more words about security beyond just these. > =20 > Brian > =20 > On Apr 1, 2011, at 7:52 PM, Paul Lambert wrote: >=20 >=20 > =20 > Friendly edit (below): > =20 > Since the location of a user device is involved, privacy implications ari= se. The protocol must have robust mechanisms for mutual authentication and= must prevent the unauthorized disclosure of a users location. > =20 > =20 > Paul > =20 > Paul A. Lambert | Marvell | +1 650 787 9141 > =20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf=20 > Of Rosen, Brian > Sent: Friday, April 01, 2011 12:48 AM > To: Romascanu, Dan (Dan) > Cc: Gabor.Bajko@nokia.com (Nokia-CIC/SiliconValley); paws@ietf.org; Polk,= William T. > Subject: Re: [paws] updated charter proposal > =20 > Good news! There were charter changes requested in the BoF in the securi= ty section. =20 > =20 > I suggest that the line in the charter: > Since the location of a user device is involved, privacy implications ari= se, and the protocol will have to have robust security mechanisms. > =20 > Be changed to: > Since the location of a user device is involved, privacy implications ari= se, and the protocol will have to have robust security and privacy mechanis= ms. There are other security concerns, including spoofing and man in the m= iddle attacks that will require analysis and mechanisms for mitigation in t= he protocol. > =20 > Brian > =20 > On Apr 1, 2011, at 9:33 AM, Romascanu, Dan (Dan) wrote: >=20 >=20 >=20 > =20 > =20 > Hi, >=20 > I reported in the IESG and IAB meeting this morning about the PAWS BOF, w= hich in my opinion went quite well. My recommendation to continue the proce= ss with the chartering of a PAWS WG was well received. The WG (if approved = after the review process) will be in the OPS area with a Technical Advisor = from APPS. >=20 > The first step in the review process is internal review of the charter wi= th the IESG and the IAB, which will result into discussion in the IESG tele= chat on 4/14 and then sending of the charter to external (all IETF review). > =20 > Question - is this charter text OK for the internal review, or are there = any text changes following the BOF?=20 >=20 > Thanks and Regards, >=20 > Dan > =20 > =20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf=20 > Of Gabor.Bajko@nokia.com > Sent: Thursday, March 24, 2011 12:24 AM > To: paws@ietf.org > Subject: [paws] updated charter proposal >=20 > Folks, > =20 > Here's an updated charter proposal. > =20 > But please read these two drafts before you come to the BOF: > =20 > I-D: Protocol to Access White Space database: Problem statement and=20 > Requirements=20 > http://www.ietf.org/id/draft-patil-paws-problem-stmt-00.txt > =20 > I-D: Protocol to Access White Space database: Overview and Use case=20 > scenarios=20 > http://www.ietf.org/id/draft-probasco-paws-overview-usecases-00.txt > =20 > =20 > =20 > Governments around the world continue to search for new pieces of=20 > radio spectrum which can be used by the expanding wireless=20 > communications industry to provide more services in the usable=20 > spectrum. The concept of allowing secondary transmissions (licensed=20 > or unlicensed) in frequencies allocated to a primary user is a=20 > technique to "unlock" existing spectrum for new use. An obvious=20 > requirement is that these secondary transmissions do not interfere=20 > with the primary use of the spectrum. Often, in a given physical=20 > location, the primary user(s) may not be using the entire band=20 > allocated to them. The available spectrum for a secondary use would=20 > then depend on the location of the secondary user. The primary user=20 > may have a schedule when it uses the spectrum, which may be available=20 > for secondary use outside that schedule. The fundamental issue is how=20 > to determine for a specific location and specific time, if any of the=20 > 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 pr= ior 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 whit= e 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 t= ransmit 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 spac= e" spectrum (for example, in a TV White space implementation, the list of a= vailable 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 ch= annel. 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 spec= ified threshold. > The databases are expected to be reachable via the Internet and the devic= es querying these databases are expected to have some form of Internet conn= ectivity, directly or indirectly. The databases may be country specific si= nce the available spectrum and regulations may vary, but the fundamental o= peration of the protocol should be country independent, thus extensibility = of data structures will be required. The solution will not be tied to any s= pecific spectrum, country, or phy/mac/air interface but may incorporate rel= evant 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 proto= col, and application services. > - Standardize the data structure to be carried by the query protocol. > Since the location of a user device is involved, privacy implications ari= se, and the protocol will have to have robust security mechanisms. > Existing IETF location data structures and privacy mechanisms may be cons= idered 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 liaiso= n 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 fr= om regulatory entities that are involved in the specification of the rules = for secondary use of spectrum in specific bands. > 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 > =20 > > =20 > =20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From brian.rosen@neustar.biz Tue Apr 5 07:41:03 2011 Return-Path: X-Original-To: paws@core3.amsl.com Delivered-To: paws@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3614428C157 for ; Tue, 5 Apr 2011 07:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.206 X-Spam-Level: X-Spam-Status: No, score=-6.206 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k7ouL7SsXVYO for ; Tue, 5 Apr 2011 07:40:55 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by core3.amsl.com (Postfix) with ESMTP id 3473F28C0DE for ; Tue, 5 Apr 2011 07:40:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1302014556; x=1617373613; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=CNTYZhd5fAD9psYfH7hCq rfc4crmrlE+g8IYKg7nfgs=; b=U7uFiZwzuOfjO2HTrik9S5pURTt2lGbRyJvSz ZVtinbR12lequqotOXWcDZUEpZxz7+JwoJnT9B/ACqLcu3/lQ== Received: from ([10.31.13.228]) by chihiron2.nc.neustar.com with ESMTP with TLS id 5202415.36190652; Tue, 05 Apr 2011 10:42:35 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Tue, 5 Apr 2011 10:42:35 -0400 From: "Rosen, Brian" To: Ian Ferrell Date: Tue, 5 Apr 2011 10:42:33 -0400 Thread-Topic: [paws] updated charter proposal Thread-Index: Acvzn7N4Um6FQ+0FQnWTJnxw7bRndQ== Message-ID: <440F5EA6-C0E7-46B4-9E68-BA3B6A1762B2@neustar.biz> References: <7DDB35B005136A4DB9FF33E7E286EF00066340@008-AM1MPN1-037.mgdnok.nokia.com> <7BAC95F5A7E67643AAFB2C31BEE662D014068D317A@SC-VEXCH2.marvell.com> <7BAC95F5A7E67643AAFB2C31BEE662D014068D319A@SC-VEXCH2.marvell.com> <26B8D793-D4EE-43ED-855F-3EDE5657E768@inf-net.nl> <88BE24FD9280884487DEAE0CE1FD3A5B047E4E@008-AM1MPN1-021.mgdnok.nokia.com> <0EFF0D1AF5667241950D9A9D1D681FBD4AE4C3FA@DF-M14-04.exchange.corp.microsoft.com> In-Reply-To: <0EFF0D1AF5667241950D9A9D1D681FBD4AE4C3FA@DF-M14-04.exchange.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 32IwSpzHnUt4vIf0n56Y0w== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] updated charter proposal X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 14:41:03 -0000 First of all, I don't think we need this level of detail in the charter. W= e should discuss it when we get to requirements. It is important to have authentication of both ends of the query. The devi= ce needs to know that it is talking to the authoritative server for the loc= ation and band he is operating in. The server may need to know which clien= t it is serving, especially when there is a subscription relationship of so= me kind: some databases may only serve certain devices with whom they have = some relationship. That would address a rogue server (or a rogue device). Non repudiation is another story. I don't think we have a requirement for = that, but we'll see. That scenario would be that an authoritative server s= ent an incorrect channel to the device, and the device interfered. The dev= ice may could want to prove that the server sent it bad data. I don't thin= k that is a credible threat. =20 Brian On Apr 5, 2011, at 10:23 AM, Ian Ferrell wrote: > Teco, are you concerned that a rogue entity could set up at a location an= d tell devices around it that Channel X is available--when in fact the chan= nel is occupied by a licensed broadcaster--and thus wreak havoc? So, in thi= s scenario, devices would need some mechanism to defend their channel use? >=20 > FWIW, I didn't see anything about this in the FCC order--I think the assu= mption on their part is that Device FOO has some mechanism to determine it = is talking to a legal database so rogue entities would not be able to spoof= bad permissions. >=20 >=20 >=20 >=20 > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of s= cott.probasco@nokia.com > Sent: Tuesday, April 05, 2011 12:16 AM > To: teco@inf-net.nl; paul@marvell.com; paws@ietf.org > Cc: Gabor.Bajko@nokia.com; Brian.Rosen@neustar.biz; william.polk@nist.gov > Subject: Re: [paws] updated charter proposal >=20 > Hi, >=20 > IMHO "Robust security mechanisms" is broad enough to include non-repudiat= ion without having to identify it specifically. Not saying at this point th= at non-repudiation must be included in PAWS (a subtle vote for WG name), on= ly that I believe the proposed charter wording allows the possibility, if t= he group decides it is needed. >=20 > Regards, > Scott >=20 > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of e= xt Teco Boot > Sent: Monday, April 04, 2011 4:50 AM > To: Paul Lambert > Cc: paws@ietf.org; Rosen, Brian; Polk, William T.; Bajko Gabor (Nokia-CIC= /SiliconValley) > Subject: Re: [paws] updated charter proposal >=20 > I'm not sure on requirements for non-repudiation. Should a secondary user= keep evidence that it legally use (or used) a granted channel? It may have= impact on the protocol. >=20 > Teco >=20 > Op 1 apr 2011, om 20:25 heeft Paul Lambert het volgende geschreven: >=20 >>> I think Tim Polk wanted more words about security beyond just these. >> Oh ... ok >>=20 >> I believe these are the overall threat areas: >> device identity spoofing >> modification of device requests >> modification of channel enablement information impersonation of >> registered database services unauthorized disclosure of a users >> location >>=20 >> There may be other broader ways to phrase these - but we need to be care= ful not to slip into device internal security versus the security of the pr= otocol. >>=20 >> Translating the above into charter speak and as a revised suggestion: >>=20 >>=20 >> The protocol must protect both the channel enablement process and the pr= ivacy 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 an= d unauthorized disclosure of a users location. >>=20 >>=20 >>=20 >> Hope this helps ... >>=20 >> Paul >>=20 >>=20 >> Paul A. Lambert | Marvell | +1 650 787 9141 >>=20 >> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >> Sent: Friday, April 01, 2011 10:58 AM >> To: Paul Lambert >> Cc: Romascanu, Dan (Dan); Gabor.Bajko@nokia.com (Nokia-CIC/SiliconValley= ); paws@ietf.org; Polk, William T. >> Subject: Re: [paws] updated charter proposal >>=20 >> I think Tim Polk wanted more words about security beyond just these. >>=20 >> Brian >>=20 >> On Apr 1, 2011, at 7:52 PM, Paul Lambert wrote: >>=20 >>=20 >>=20 >> Friendly edit (below): >>=20 >> Since the location of a user device is involved, privacy implications ar= ise. The protocol must have robust mechanisms for mutual authentication an= d must prevent the unauthorized disclosure of a users location. >>=20 >>=20 >> Paul >>=20 >> Paul A. Lambert | Marvell | +1 650 787 9141 >>=20 >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf >> Of Rosen, Brian >> Sent: Friday, April 01, 2011 12:48 AM >> To: Romascanu, Dan (Dan) >> Cc: Gabor.Bajko@nokia.com (Nokia-CIC/SiliconValley); paws@ietf.org; Polk= , William T. >> Subject: Re: [paws] updated charter proposal >>=20 >> Good news! There were charter changes requested in the BoF in the secur= ity section. >>=20 >> I suggest that the line in the charter: >> Since the location of a user device is involved, privacy implications ar= ise, and the protocol will have to have robust security mechanisms. >>=20 >> Be changed to: >> Since the location of a user device is involved, privacy implications ar= ise, and the protocol will have to have robust security and privacy mechani= sms. There are other security concerns, including spoofing and man in the = middle attacks that will require analysis and mechanisms for mitigation in = the protocol. >>=20 >> Brian >>=20 >> On Apr 1, 2011, at 9:33 AM, Romascanu, Dan (Dan) wrote: >>=20 >>=20 >>=20 >>=20 >>=20 >> Hi, >>=20 >> I reported in the IESG and IAB meeting this morning about the PAWS BOF, = which in my opinion went quite well. My recommendation to continue the proc= ess with the chartering of a PAWS WG was well received. The WG (if approved= after the review process) will be in the OPS area with a Technical Advisor= from APPS. >>=20 >> The first step in the review process is internal review of the charter w= ith the IESG and the IAB, which will result into discussion in the IESG tel= echat on 4/14 and then sending of the charter to external (all IETF review)= . >>=20 >> Question - is this charter text OK for the internal review, or are there= any text changes following the BOF? >>=20 >> Thanks and Regards, >>=20 >> Dan >>=20 >>=20 >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf >> Of Gabor.Bajko@nokia.com >> Sent: Thursday, March 24, 2011 12:24 AM >> To: paws@ietf.org >> Subject: [paws] updated charter proposal >>=20 >> Folks, >>=20 >> Here's an updated charter proposal. >>=20 >> But please read these two drafts before you come to the BOF: >>=20 >> I-D: Protocol to Access White Space database: Problem statement and >> Requirements >> http://www.ietf.org/id/draft-patil-paws-problem-stmt-00.txt >>=20 >> I-D: Protocol to Access White Space database: Overview and Use case >> scenarios >> http://www.ietf.org/id/draft-probasco-paws-overview-usecases-00.txt >>=20 >>=20 >>=20 >> 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 p= rior 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 whi= te space, a radio is configured with, or has the capability to determine it= s 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, provid= e its geolocation and receive in return a list of unoccupied or "white spa= ce" 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 c= hannel. The device must query the database subsequently on a periodic basis= for a list of unoccupied channels based on certain conditions, e.g. a fixe= d amount of time has passed or the device has changed location beyond a spe= cified threshold. >> The databases are expected to be reachable via the Internet and the devi= ces querying these databases are expected to have some form of Internet con= nectivity, directly or indirectly. The databases may be country specific s= ince 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 re= levant 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 proto= col, and application services. >> - Standardize the data structure to be carried by the query protocol. >> Since the location of a user device is involved, privacy implications ar= ise, and the protocol will have to have robust security mechanisms. >> Existing IETF location data structures and privacy mechanisms may be con= sidered 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 liais= on 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 f= rom regulatory entities that are involved in the specification of the rules= for secondary use of spectrum in specific bands. >> 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 >>=20 >> >>=20 >>=20 >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From richard@shockey.us Tue Apr 5 07:50:22 2011 Return-Path: X-Original-To: paws@core3.amsl.com Delivered-To: paws@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6EA93A67DF for ; Tue, 5 Apr 2011 07:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.16 X-Spam-Level: X-Spam-Status: No, score=-102.16 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXJx1UIh2Z7p for ; Tue, 5 Apr 2011 07:50:15 -0700 (PDT) Received: from cpoproxy3-pub.bluehost.com (cpoproxy3-pub.bluehost.com [67.222.54.6]) by core3.amsl.com (Postfix) with SMTP id 4BDA728C120 for ; Tue, 5 Apr 2011 07:50:15 -0700 (PDT) Received: (qmail 15954 invoked by uid 0); 5 Apr 2011 14:51:58 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by cpoproxy3.bluehost.com with SMTP; 5 Apr 2011 14:51:58 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=F4tNWrnjkvx5FwJtdjsS+ZFDWoL2EhCPNlinOn3m6KljOvA83C6x2NlPPd8EgLxdvDhV1bEIBshu2YW21bz84NVAO62WzgRAyCLT83mda2JOOnY9BgQaQYeFrS7JTR7B; Received: from pool-71-178-24-118.washdc.fios.verizon.net ([71.178.24.118] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Q77bq-0005MY-2R; Tue, 05 Apr 2011 08:51:58 -0600 From: "Richard Shockey" To: "'Rosen, Brian'" , "'Ian Ferrell'" References: <7DDB35B005136A4DB9FF33E7E286EF00066340@008-AM1MPN1-037.mgdnok.nokia.com> <7BAC95F5A7E67643AAFB2C31BEE662D014068D317A@SC-VEXCH2.marvell.com> <7BAC95F5A7E67643AAFB2C31BEE662D014068D319A@SC-VEXCH2.marvell.com> <26B8D793-D4EE-43ED-855F-3EDE5657E768@inf-net.nl> <88BE24FD9280884487DEAE0CE1FD3A5B047E4E@008-AM1MPN1-021.mgdnok.nokia.com> <0EFF0D1AF5667241950D9A9D1D681FBD4AE4C3FA@DF-M14-04.exchange.corp.microsoft.com> <440F5EA6-C0E7-46B4-9E68-BA3B6A1762B2@neustar.biz> In-Reply-To: <440F5EA6-C0E7-46B4-9E68-BA3B6A1762B2@neustar.biz> Date: Tue, 5 Apr 2011 10:51:57 -0400 Message-ID: <002401cbf3a1$03d7f540$0b87dfc0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acvzn7N4Um6FQ+0FQnWTJnxw7bRndQAAQkUA Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.178.24.118 authed with richard@shockey.us} Cc: paws@ietf.org Subject: Re: [paws] updated charter proposal X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 14:50:22 -0000 Brian is absolutely right here ..this level of specificity is not necessary at the charter phase. The need here is to define reasonable scope, realistic deliverables and let the WG get on with it. The proposed charter is fine as is. It can always be amended. -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Rosen, Brian Sent: Tuesday, April 05, 2011 10:43 AM To: Ian Ferrell Cc: paws@ietf.org Subject: Re: [paws] updated charter proposal First of all, I don't think we need this level of detail in the charter. We should discuss it when we get to requirements. It is important to have authentication of both ends of the query. The device needs to know that it is talking to the authoritative server for the location and band he is operating in. The server may need to know which client it is serving, especially when there is a subscription relationship of some kind: some databases may only serve certain devices with whom they have some relationship. That would address a rogue server (or a rogue device). Non repudiation is another story. I don't think we have a requirement for that, but we'll see. That scenario would be that an authoritative server sent an incorrect channel to the device, and the device interfered. The device may could want to prove that the server sent it bad data. I don't think that is a credible threat. Brian On Apr 5, 2011, at 10:23 AM, Ian Ferrell wrote: > Teco, are you concerned that a rogue entity could set up at a location and tell devices around it that Channel X is available--when in fact the channel is occupied by a licensed broadcaster--and thus wreak havoc? So, in this scenario, devices would need some mechanism to defend their channel use? > > FWIW, I didn't see anything about this in the FCC order--I think the assumption on their part is that Device FOO has some mechanism to determine it is talking to a legal database so rogue entities would not be able to spoof bad permissions. > > > > > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of scott.probasco@nokia.com > Sent: Tuesday, April 05, 2011 12:16 AM > To: teco@inf-net.nl; paul@marvell.com; paws@ietf.org > Cc: Gabor.Bajko@nokia.com; Brian.Rosen@neustar.biz; william.polk@nist.gov > Subject: Re: [paws] updated charter proposal > > Hi, > > IMHO "Robust security mechanisms" is broad enough to include non-repudiation without having to identify it specifically. Not saying at this point that non-repudiation must be included in PAWS (a subtle vote for WG name), only that I believe the proposed charter wording allows the possibility, if the group decides it is needed. > > Regards, > Scott > > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Teco Boot > Sent: Monday, April 04, 2011 4:50 AM > To: Paul Lambert > Cc: paws@ietf.org; Rosen, Brian; Polk, William T.; Bajko Gabor (Nokia-CIC/SiliconValley) > Subject: Re: [paws] updated charter proposal > > I'm not sure on requirements for non-repudiation. Should a secondary user keep evidence that it legally use (or used) a granted channel? It may have impact on the protocol. > > Teco > > Op 1 apr 2011, om 20:25 heeft Paul Lambert het volgende geschreven: > >>> I think Tim Polk wanted more words about security beyond just these. >> Oh ... ok >> >> I believe these are the overall threat areas: >> device identity spoofing >> modification of device requests >> modification of channel enablement information impersonation of >> registered database services unauthorized disclosure of a users >> location >> >> There may be other broader ways to phrase these - but we need to be careful not to slip into device internal security versus the security of the protocol. >> >> Translating the above into charter speak and as a revised suggestion: >> >> >> 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. >> >> >> >> Hope this helps ... >> >> Paul >> >> >> Paul A. Lambert | Marvell | +1 650 787 9141 >> >> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >> Sent: Friday, April 01, 2011 10:58 AM >> To: Paul Lambert >> Cc: Romascanu, Dan (Dan); Gabor.Bajko@nokia.com (Nokia-CIC/SiliconValley); paws@ietf.org; Polk, William T. >> Subject: Re: [paws] updated charter proposal >> >> I think Tim Polk wanted more words about security beyond just these. >> >> Brian >> >> On Apr 1, 2011, at 7:52 PM, Paul Lambert wrote: >> >> >> >> Friendly edit (below): >> >> Since the location of a user device is involved, privacy implications arise. The protocol must have robust mechanisms for mutual authentication and must prevent the unauthorized disclosure of a users location. >> >> >> Paul >> >> Paul A. Lambert | Marvell | +1 650 787 9141 >> >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf >> Of Rosen, Brian >> Sent: Friday, April 01, 2011 12:48 AM >> To: Romascanu, Dan (Dan) >> Cc: Gabor.Bajko@nokia.com (Nokia-CIC/SiliconValley); paws@ietf.org; Polk, William T. >> Subject: Re: [paws] updated charter proposal >> >> Good news! There were charter changes requested in the BoF in the security section. >> >> I suggest that the line in the charter: >> Since the location of a user device is involved, privacy implications arise, and the protocol will have to have robust security mechanisms. >> >> Be changed to: >> Since the location of a user device is involved, privacy implications arise, and the protocol will have to have robust security and privacy mechanisms. There are other security concerns, including spoofing and man in the middle attacks that will require analysis and mechanisms for mitigation in the protocol. >> >> Brian >> >> On Apr 1, 2011, at 9:33 AM, Romascanu, Dan (Dan) wrote: >> >> >> >> >> >> Hi, >> >> I reported in the IESG and IAB meeting this morning about the PAWS BOF, which in my opinion went quite well. My recommendation to continue the process with the chartering of a PAWS WG was well received. The WG (if approved after the review process) will be in the OPS area with a Technical Advisor from APPS. >> >> The first step in the review process is internal review of the charter with the IESG and the IAB, which will result into discussion in the IESG telechat on 4/14 and then sending of the charter to external (all IETF review). >> >> Question - is this charter text OK for the internal review, or are there any text changes following the BOF? >> >> Thanks and Regards, >> >> Dan >> >> >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf >> Of Gabor.Bajko@nokia.com >> Sent: Thursday, March 24, 2011 12:24 AM >> To: paws@ietf.org >> Subject: [paws] updated charter proposal >> >> Folks, >> >> Here's an updated charter proposal. >> >> But please read these two drafts before you come to the BOF: >> >> I-D: Protocol to Access White Space database: Problem statement and >> Requirements >> http://www.ietf.org/id/draft-patil-paws-problem-stmt-00.txt >> >> I-D: Protocol to Access White Space database: Overview and Use case >> scenarios >> http://www.ietf.org/id/draft-probasco-paws-overview-usecases-00.txt >> >> >> >> 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. >> Since the location of a user device is involved, privacy implications arise, and the protocol will have to have robust security mechanisms. >> 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. >> 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 >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From caulfield.jesse@gmail.com Tue Apr 5 08:33:58 2011 Return-Path: X-Original-To: paws@core3.amsl.com Delivered-To: paws@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 620F93A67F5 for ; Tue, 5 Apr 2011 08:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9+EHfoRsEKU for ; Tue, 5 Apr 2011 08:33:55 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 670623A6819 for ; Tue, 5 Apr 2011 08:33:55 -0700 (PDT) Received: by vws12 with SMTP id 12so458774vws.31 for ; Tue, 05 Apr 2011 08:35:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=5hdERlicroHQvhI8Eruyw0scljbHNdO8pyc7W/n5gcs=; b=D0QLFrjH9ij//O8jYyqWOpLodIhEJETErHLeV6ZTd0ltiSSyS1XWFnrGOOHaxgcdW2 HraWMoRRvSjTGZKj1bbZIOWdSOgdKGKYLzYv4DWKIyiq5aaZQgfmZD2OtDwAz3FJnZ5x FEN8WYzM0M2h+JSdefLhuj/cF8NfJ1jPC8qtY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; b=kUUU81Zx+lGfsNs3g3u840iUDwcPnzT39OjFITdC6BzBgGkuw0FfO3pIZcomoopsvg lwBf8XyrQ+eI08LoVWNOejFtUYxVLZB9EpThflYdpvN4nzDIg+6Zs7yJ2NoDLlinZsWL 1GWNHdXjxg+8W3GtABMOUw9LMLXl8EenIcJyA= Received: by 10.52.92.161 with SMTP id cn1mr1486801vdb.253.1302017737287; Tue, 05 Apr 2011 08:35:37 -0700 (PDT) Received: from JMCLaptop (pool-173-66-247-16.washdc.fios.verizon.net [173.66.247.16]) by mx.google.com with ESMTPS id l9sm1421407vdv.34.2011.04.05.08.35.35 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Apr 2011 08:35:35 -0700 (PDT) From: "Jesse Caulfield" To: References: <7DDB35B005136A4DB9FF33E7E286EF00066340@008-AM1MPN1-037.mgdnok.nokia.com> <7BAC95F5A7E67643AAFB2C31BEE662D014068D317A@SC-VEXCH2.marvell.com> <7BAC95F5A7E67643AAFB2C31BEE662D014068D319A@SC-VEXCH2.marvell.com> <26B8D793-D4EE-43ED-855F-3EDE5657E768@inf-net.nl> <88BE24FD9280884487DEAE0CE1FD3A5B047E4E@008-AM1MPN1-021.mgdnok.nokia.com> <0EFF0D1AF5667241950D9A9D1D681FBD4AE4C3FA@DF-M14-04.exchange.corp.microsoft.com> <440F5EA6-C0E7-46B4-9E68-BA3B6A1762B2@neustar.biz> In-Reply-To: <440F5EA6-C0E7-46B4-9E68-BA3B6A1762B2@neustar.biz> Date: Tue, 5 Apr 2011 11:35:30 -0400 Message-ID: <4d9b36c7.8949340a.0265.798c@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acvzn7N4Um6FQ+0FQnWTJnxw7bRndQABn/wg Content-Language: en-us Subject: Re: [paws] updated charter proposal X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 15:33:58 -0000 Non-repudiation, or at least its functional equivalent in mutual-authentication + encryption, is required for US operation. Agree with B.Rosen and S.Probasco that such details are likely not needed in a charter and "robust security" is a sufficiently flexible mention. -- J.Caulfield -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Rosen, Brian Sent: Tuesday, April 05, 2011 10:43 AM To: Ian Ferrell Cc: paws@ietf.org Subject: Re: [paws] updated charter proposal First of all, I don't think we need this level of detail in the charter. We should discuss it when we get to requirements. It is important to have authentication of both ends of the query. The device needs to know that it is talking to the authoritative server for the location and band he is operating in. The server may need to know which client it is serving, especially when there is a subscription relationship of some kind: some databases may only serve certain devices with whom they have some relationship. That would address a rogue server (or a rogue device). Non repudiation is another story. I don't think we have a requirement for that, but we'll see. That scenario would be that an authoritative server sent an incorrect channel to the device, and the device interfered. The device may could want to prove that the server sent it bad data. I don't think that is a credible threat. Brian On Apr 5, 2011, at 10:23 AM, Ian Ferrell wrote: > Teco, are you concerned that a rogue entity could set up at a location and tell devices around it that Channel X is available--when in fact the channel is occupied by a licensed broadcaster--and thus wreak havoc? So, in this scenario, devices would need some mechanism to defend their channel use? > > FWIW, I didn't see anything about this in the FCC order--I think the assumption on their part is that Device FOO has some mechanism to determine it is talking to a legal database so rogue entities would not be able to spoof bad permissions. > > > > > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of scott.probasco@nokia.com > Sent: Tuesday, April 05, 2011 12:16 AM > To: teco@inf-net.nl; paul@marvell.com; paws@ietf.org > Cc: Gabor.Bajko@nokia.com; Brian.Rosen@neustar.biz; william.polk@nist.gov > Subject: Re: [paws] updated charter proposal > > Hi, > > IMHO "Robust security mechanisms" is broad enough to include non-repudiation without having to identify it specifically. Not saying at this point that non-repudiation must be included in PAWS (a subtle vote for WG name), only that I believe the proposed charter wording allows the possibility, if the group decides it is needed. > > Regards, > Scott > > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Teco Boot > Sent: Monday, April 04, 2011 4:50 AM > To: Paul Lambert > Cc: paws@ietf.org; Rosen, Brian; Polk, William T.; Bajko Gabor (Nokia-CIC/SiliconValley) > Subject: Re: [paws] updated charter proposal > > I'm not sure on requirements for non-repudiation. Should a secondary user keep evidence that it legally use (or used) a granted channel? It may have impact on the protocol. > > Teco > > Op 1 apr 2011, om 20:25 heeft Paul Lambert het volgende geschreven: > >>> I think Tim Polk wanted more words about security beyond just these. >> Oh ... ok >> >> I believe these are the overall threat areas: >> device identity spoofing >> modification of device requests >> modification of channel enablement information impersonation of >> registered database services unauthorized disclosure of a users >> location >> >> There may be other broader ways to phrase these - but we need to be careful not to slip into device internal security versus the security of the protocol. >> >> Translating the above into charter speak and as a revised suggestion: >> >> >> 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. >> >> >> >> Hope this helps ... >> >> Paul >> >> >> Paul A. Lambert | Marvell | +1 650 787 9141 >> >> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >> Sent: Friday, April 01, 2011 10:58 AM >> To: Paul Lambert >> Cc: Romascanu, Dan (Dan); Gabor.Bajko@nokia.com (Nokia-CIC/SiliconValley); paws@ietf.org; Polk, William T. >> Subject: Re: [paws] updated charter proposal >> >> I think Tim Polk wanted more words about security beyond just these. >> >> Brian >> >> On Apr 1, 2011, at 7:52 PM, Paul Lambert wrote: >> >> >> >> Friendly edit (below): >> >> Since the location of a user device is involved, privacy implications arise. The protocol must have robust mechanisms for mutual authentication and must prevent the unauthorized disclosure of a users location. >> >> >> Paul >> >> Paul A. Lambert | Marvell | +1 650 787 9141 >> >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf >> Of Rosen, Brian >> Sent: Friday, April 01, 2011 12:48 AM >> To: Romascanu, Dan (Dan) >> Cc: Gabor.Bajko@nokia.com (Nokia-CIC/SiliconValley); paws@ietf.org; Polk, William T. >> Subject: Re: [paws] updated charter proposal >> >> Good news! There were charter changes requested in the BoF in the security section. >> >> I suggest that the line in the charter: >> Since the location of a user device is involved, privacy implications arise, and the protocol will have to have robust security mechanisms. >> >> Be changed to: >> Since the location of a user device is involved, privacy implications arise, and the protocol will have to have robust security and privacy mechanisms. There are other security concerns, including spoofing and man in the middle attacks that will require analysis and mechanisms for mitigation in the protocol. >> >> Brian >> >> On Apr 1, 2011, at 9:33 AM, Romascanu, Dan (Dan) wrote: >> >> >> >> >> >> Hi, >> >> I reported in the IESG and IAB meeting this morning about the PAWS BOF, which in my opinion went quite well. My recommendation to continue the process with the chartering of a PAWS WG was well received. The WG (if approved after the review process) will be in the OPS area with a Technical Advisor from APPS. >> >> The first step in the review process is internal review of the charter with the IESG and the IAB, which will result into discussion in the IESG telechat on 4/14 and then sending of the charter to external (all IETF review). >> >> Question - is this charter text OK for the internal review, or are there any text changes following the BOF? >> >> Thanks and Regards, >> >> Dan >> >> >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf >> Of Gabor.Bajko@nokia.com >> Sent: Thursday, March 24, 2011 12:24 AM >> To: paws@ietf.org >> Subject: [paws] updated charter proposal >> >> Folks, >> >> Here's an updated charter proposal. >> >> But please read these two drafts before you come to the BOF: >> >> I-D: Protocol to Access White Space database: Problem statement and >> Requirements >> http://www.ietf.org/id/draft-patil-paws-problem-stmt-00.txt >> >> I-D: Protocol to Access White Space database: Overview and Use case >> scenarios >> http://www.ietf.org/id/draft-probasco-paws-overview-usecases-00.txt >> >> >> >> 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. >> Since the location of a user device is involved, privacy implications arise, and the protocol will have to have robust security mechanisms. >> 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. >> 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 >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From brian.rosen@neustar.biz Tue Apr 5 08:42:44 2011 Return-Path: X-Original-To: paws@core3.amsl.com Delivered-To: paws@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CC393A6955 for ; Tue, 5 Apr 2011 08:42:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.228 X-Spam-Level: X-Spam-Status: No, score=-6.228 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oum+MjeSiXqq for ; Tue, 5 Apr 2011 08:42:42 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by core3.amsl.com (Postfix) with ESMTP id 5540128C107 for ; Tue, 5 Apr 2011 08:42:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1302018263; x=1617373613; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=QFQeVI1Fj4p7VvasfvtOe q448HbogqF2LFLAu7WSwCA=; b=Gwa+FgxDc9OO+n/LbCKOwgtqckcQDLYNnQDmH wX4/+lPFA6rsjC+9Ggg41uPuB7HMvihseSksKJl/lv+7xPcDA== Received: from ([10.31.13.228]) by chihiron2.nc.neustar.com with ESMTP with TLS id 5202415.36192721; Tue, 05 Apr 2011 11:44:21 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Tue, 5 Apr 2011 11:44:21 -0400 From: "Rosen, Brian" To: Jesse Caulfield Date: Tue, 5 Apr 2011 11:44:20 -0400 Thread-Topic: [paws] updated charter proposal Thread-Index: AcvzqFSfUQ0dY6j/R2Gb+isQjcQzsQ== Message-ID: <2C2AEDA3-18EC-4E37-A995-36432DC14335@neustar.biz> References: <7DDB35B005136A4DB9FF33E7E286EF00066340@008-AM1MPN1-037.mgdnok.nokia.com> <7BAC95F5A7E67643AAFB2C31BEE662D014068D317A@SC-VEXCH2.marvell.com> <7BAC95F5A7E67643AAFB2C31BEE662D014068D319A@SC-VEXCH2.marvell.com> <26B8D793-D4EE-43ED-855F-3EDE5657E768@inf-net.nl> <88BE24FD9280884487DEAE0CE1FD3A5B047E4E@008-AM1MPN1-021.mgdnok.nokia.com> <0EFF0D1AF5667241950D9A9D1D681FBD4AE4C3FA@DF-M14-04.exchange.corp.microsoft.com> <440F5EA6-C0E7-46B4-9E68-BA3B6A1762B2@neustar.biz> <4d9b36c7.8949340a.0265.798c@mx.google.com> In-Reply-To: <4d9b36c7.8949340a.0265.798c@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: DR+El+hsH4uU7c7m4pgf8w== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] updated charter proposal X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 15:42:44 -0000 Nit picking, but there is a big difference between mutual authentication (d= o I know who I am talking to?) and non-repudiation (can I prove you sent me= something, even if you claim you didn't?). We need the former, I don't th= ink we need the latter (here, in the device to db query). Brian On Apr 5, 2011, at 11:35 AM, Jesse Caulfield wrote: > Non-repudiation, or at least its functional equivalent in > mutual-authentication + encryption, is required for US operation. > > Agree with B.Rosen and S.Probasco that such details are likely not needed= in > a charter and "robust security" is a sufficiently flexible mention. > -- > J.Caulfield > > > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of > Rosen, Brian > Sent: Tuesday, April 05, 2011 10:43 AM > To: Ian Ferrell > Cc: paws@ietf.org > Subject: Re: [paws] updated charter proposal > > First of all, I don't think we need this level of detail in the charter. = We > should discuss it when we get to requirements. > > It is important to have authentication of both ends of the query. The > device needs to know that it is talking to the authoritative server for t= he > location and band he is operating in. The server may need to know which > client it is serving, especially when there is a subscription relationshi= p > of some kind: some databases may only serve certain devices with whom the= y > have some relationship. That would address a rogue server (or a rogue > device). > > Non repudiation is another story. I don't think we have a requirement fo= r > that, but we'll see. That scenario would be that an authoritative server > sent an incorrect channel to the device, and the device interfered. The > device may could want to prove that the server sent it bad data. I don't > think that is a credible threat. > > Brian > > > > On Apr 5, 2011, at 10:23 AM, Ian Ferrell wrote: > >> Teco, are you concerned that a rogue entity could set up at a location a= nd > tell devices around it that Channel X is available--when in fact the chan= nel > is occupied by a licensed broadcaster--and thus wreak havoc? So, in this > scenario, devices would need some mechanism to defend their channel use? >> >> FWIW, I didn't see anything about this in the FCC order--I think the > assumption on their part is that Device FOO has some mechanism to determi= ne > it is talking to a legal database so rogue entities would not be able to > spoof bad permissions. >> >> >> >> >> -----Original Message----- >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of > scott.probasco@nokia.com >> Sent: Tuesday, April 05, 2011 12:16 AM >> To: teco@inf-net.nl; paul@marvell.com; paws@ietf.org >> Cc: Gabor.Bajko@nokia.com; Brian.Rosen@neustar.biz; william.polk@nist.go= v >> Subject: Re: [paws] updated charter proposal >> >> Hi, >> >> IMHO "Robust security mechanisms" is broad enough to include > non-repudiation without having to identify it specifically. Not saying at > this point that non-repudiation must be included in PAWS (a subtle vote f= or > WG name), only that I believe the proposed charter wording allows the > possibility, if the group decides it is needed. >> >> Regards, >> Scott >> >> -----Original Message----- >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of > ext Teco Boot >> Sent: Monday, April 04, 2011 4:50 AM >> To: Paul Lambert >> Cc: paws@ietf.org; Rosen, Brian; Polk, William T.; Bajko Gabor > (Nokia-CIC/SiliconValley) >> Subject: Re: [paws] updated charter proposal >> >> I'm not sure on requirements for non-repudiation. Should a secondary use= r > keep evidence that it legally use (or used) a granted channel? It may hav= e > impact on the protocol. >> >> Teco >> >> Op 1 apr 2011, om 20:25 heeft Paul Lambert het volgende geschreven: >> >>>> I think Tim Polk wanted more words about security beyond just these. >>> Oh ... ok >>> >>> I believe these are the overall threat areas: >>> device identity spoofing >>> modification of device requests >>> modification of channel enablement information impersonation of >>> registered database services unauthorized disclosure of a users >>> location >>> >>> There may be other broader ways to phrase these - but we need to be > careful not to slip into device internal security versus the security of = the > protocol. >>> >>> Translating the above into charter speak and as a revised suggestion: >>> >>> >>> 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 a= nd > unauthorized disclosure of a users location. >>> >>> >>> >>> Hope this helps ... >>> >>> Paul >>> >>> >>> Paul A. Lambert | Marvell | +1 650 787 9141 >>> >>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>> Sent: Friday, April 01, 2011 10:58 AM >>> To: Paul Lambert >>> Cc: Romascanu, Dan (Dan); Gabor.Bajko@nokia.com > (Nokia-CIC/SiliconValley); paws@ietf.org; Polk, William T. >>> Subject: Re: [paws] updated charter proposal >>> >>> I think Tim Polk wanted more words about security beyond just these. >>> >>> Brian >>> >>> On Apr 1, 2011, at 7:52 PM, Paul Lambert wrote: >>> >>> >>> >>> Friendly edit (below): >>> >>> Since the location of a user device is involved, privacy implications > arise. The protocol must have robust mechanisms for mutual authenticatio= n > and must prevent the unauthorized disclosure of a users location. >>> >>> >>> Paul >>> >>> Paul A. Lambert | Marvell | +1 650 787 9141 >>> >>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf >>> Of Rosen, Brian >>> Sent: Friday, April 01, 2011 12:48 AM >>> To: Romascanu, Dan (Dan) >>> Cc: Gabor.Bajko@nokia.com (Nokia-CIC/SiliconValley); paws@ietf.org; Pol= k, > William T. >>> Subject: Re: [paws] updated charter proposal >>> >>> Good news! There were charter changes requested in the BoF in the > security section. >>> >>> I suggest that the line in the charter: >>> Since the location of a user device is involved, privacy implications > arise, and the protocol will have to have robust security mechanisms. >>> >>> Be changed to: >>> Since the location of a user device is involved, privacy implications > arise, and the protocol will have to have robust security and privacy > mechanisms. There are other security concerns, including spoofing and ma= n > in the middle attacks that will require analysis and mechanisms for > mitigation in the protocol. >>> >>> Brian >>> >>> On Apr 1, 2011, at 9:33 AM, Romascanu, Dan (Dan) wrote: >>> >>> >>> >>> >>> >>> Hi, >>> >>> I reported in the IESG and IAB meeting this morning about the PAWS BOF, > which in my opinion went quite well. My recommendation to continue the > process with the chartering of a PAWS WG was well received. The WG (if > approved after the review process) will be in the OPS area with a Technic= al > Advisor from APPS. >>> >>> The first step in the review process is internal review of the charter > with the IESG and the IAB, which will result into discussion in the IESG > telechat on 4/14 and then sending of the charter to external (all IETF > review). >>> >>> Question - is this charter text OK for the internal review, or are ther= e > any text changes following the BOF? >>> >>> Thanks and Regards, >>> >>> Dan >>> >>> >>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf >>> Of Gabor.Bajko@nokia.com >>> Sent: Thursday, March 24, 2011 12:24 AM >>> To: paws@ietf.org >>> Subject: [paws] updated charter proposal >>> >>> Folks, >>> >>> Here's an updated charter proposal. >>> >>> But please read these two drafts before you come to the BOF: >>> >>> I-D: Protocol to Access White Space database: Problem statement and >>> Requirements >>> http://www.ietf.org/id/draft-patil-paws-problem-stmt-00.txt >>> >>> I-D: Protocol to Access White Space database: Overview and Use case >>> scenarios >>> http://www.ietf.org/id/draft-probasco-paws-overview-usecases-00.txt >>> >>> >>> >>> 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 contour= s > for primary users, and require the secondary users to check the database > prior to selecting what part of the spectrum they use. Such databases co= uld > 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 determi= ne > 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 devi= ce > must identify the relevant database to query, contact the database, provi= de > its geolocation and receive in return a list of unoccupied or "white spa= ce" > spectrum (for example, in a TV White space implementation, the list of > available channels at that location). The device can then select one of t= he > channels from the list and begin to transmit and receive on the selected > channel. The device must query the database subsequently on a periodic ba= sis > for a list of unoccupied channels based on certain conditions, e.g. a fix= ed > 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 Intern= et > connectivity, directly or indirectly. The databases may be country speci= fic > since the available spectrum and regulations may vary, but the fundament= al > operation of the protocol should be country independent, thus extensibili= ty > 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. >>> Since the location of a user device is involved, privacy implications > arise, and the protocol will have to have robust security mechanisms. >>> 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 consid= er > input from regulatory entities that are involved in the specification of = the > rules for secondary use of spectrum in specific bands. >>> 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 >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >> >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >> >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From dromasca@avaya.com Tue Apr 5 08:43:52 2011 Return-Path: X-Original-To: paws@core3.amsl.com Delivered-To: paws@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12EAD3A68E8 for ; Tue, 5 Apr 2011 08:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.191 X-Spam-Level: X-Spam-Status: No, score=-103.191 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMWi-Tc9BILQ for ; Tue, 5 Apr 2011 08:43:50 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id B4A9B3A67AF for ; Tue, 5 Apr 2011 08:43:49 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYAAFMtcU3GmAcF/2dsb2JhbACYKo47dKR5ApkWgn4BGYJJBJAMiQM X-IronPort-AV: E=Sophos;i="4.63,305,1299474000"; d="scan'208";a="240237890" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 05 Apr 2011 11:45:30 -0400 X-IronPort-AV: E=Sophos;i="4.63,305,1299474000"; d="scan'208";a="605513194" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 05 Apr 2011 11:45:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Apr 2011 17:45:27 +0200 Message-ID: In-Reply-To: <4d9b36c7.8949340a.0265.798c@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [paws] updated charter proposal Thread-Index: Acvzn7N4Um6FQ+0FQnWTJnxw7bRndQABn/wgAACCvNA= References: <7DDB35B005136A4DB9FF33E7E286EF00066340@008-AM1MPN1-037.mgdnok.nokia.com> <7BAC95F5A7E67643AAFB2C31BEE662D014068D317A@SC-VEXCH2.marvell.com> <7BAC95F5A7E67643AAFB2C31BEE662D014068D319A@SC-VEXCH2.marvell.com> <26B8D793-D4EE-43ED-855F-3EDE5657E768@inf-net.nl> <88BE24FD9280884487DEAE0CE1FD3A5B047E4E@008-AM1MPN1-021.mgdnok.nokia.com> <0EFF0D1AF5667241950D9A9D1D681FBD4AE4C3FA@DF-M14-04.exchange.corp.microsoft.com><440F5EA6-C0E7-46B4-9E68-BA3B6A1762B2@neustar.biz> <4d9b36c7.8949340a.0265.798c@mx.google.com> From: "Romascanu, Dan (Dan)" To: "Jesse Caulfield" , Subject: Re: [paws] updated charter proposal X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 15:43:52 -0000 Hi,=20 The Requirements and Framework informational document is probably the place were the detailed requirements (including those derived from the US regulatory requirements) should be listed.=20 Regards, Dan=20 =20 > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On=20 > Behalf Of Jesse Caulfield > Sent: Tuesday, April 05, 2011 6:36 PM > To: paws@ietf.org > Subject: Re: [paws] updated charter proposal >=20 > Non-repudiation, or at least its functional equivalent in=20 > mutual-authentication + encryption, is required for US operation. >=20 > Agree with B.Rosen and S.Probasco that such details are=20 > likely not needed in a charter and "robust security" is a=20 > sufficiently flexible mention. > -- > J.Caulfield >=20 >=20 > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On=20 > Behalf Of Rosen, Brian > Sent: Tuesday, April 05, 2011 10:43 AM > To: Ian Ferrell > Cc: paws@ietf.org > Subject: Re: [paws] updated charter proposal >=20 > First of all, I don't think we need this level of detail in=20 > the charter. We should discuss it when we get to requirements. >=20 > It is important to have authentication of both ends of the=20 > query. The device needs to know that it is talking to the=20 > authoritative server for the location and band he is=20 > operating in. The server may need to know which client it is=20 > serving, especially when there is a subscription relationship=20 > of some kind: some databases may only serve certain devices=20 > with whom they > have some relationship. That would address a rogue server=20 > (or a rogue > device). >=20 > Non repudiation is another story. I don't think we have a=20 > requirement for that, but we'll see. That scenario would be=20 > that an authoritative server sent an incorrect channel to the=20 > device, and the device interfered. The device may could want=20 > to prove that the server sent it bad data. I don't think=20 > that is a credible threat. =20 >=20 > Brian >=20 >=20 >=20 > On Apr 5, 2011, at 10:23 AM, Ian Ferrell wrote: >=20 > > Teco, are you concerned that a rogue entity could set up at=20 > a location=20 > > and > tell devices around it that Channel X is available--when in=20 > fact the channel is occupied by a licensed broadcaster--and=20 > thus wreak havoc? So, in this scenario, devices would need=20 > some mechanism to defend their channel use? > >=20 > > FWIW, I didn't see anything about this in the FCC order--I think the > assumption on their part is that Device FOO has some=20 > mechanism to determine it is talking to a legal database so=20 > rogue entities would not be able to spoof bad permissions. > >=20 > >=20 > >=20 > >=20 > > -----Original Message----- > > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org]=20 > On Behalf=20 > > Of > scott.probasco@nokia.com > > Sent: Tuesday, April 05, 2011 12:16 AM > > To: teco@inf-net.nl; paul@marvell.com; paws@ietf.org > > Cc: Gabor.Bajko@nokia.com; Brian.Rosen@neustar.biz;=20 > > william.polk@nist.gov > > Subject: Re: [paws] updated charter proposal > >=20 > > Hi, > >=20 > > IMHO "Robust security mechanisms" is broad enough to include > non-repudiation without having to identify it specifically.=20 > Not saying at this point that non-repudiation must be=20 > included in PAWS (a subtle vote for WG name), only that I=20 > believe the proposed charter wording allows the possibility,=20 > if the group decides it is needed. > >=20 > > Regards, > > Scott > >=20 > > -----Original Message----- > > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org]=20 > On Behalf=20 > > Of > ext Teco Boot > > Sent: Monday, April 04, 2011 4:50 AM > > To: Paul Lambert > > Cc: paws@ietf.org; Rosen, Brian; Polk, William T.; Bajko Gabor > (Nokia-CIC/SiliconValley) > > Subject: Re: [paws] updated charter proposal > >=20 > > I'm not sure on requirements for non-repudiation. Should a=20 > secondary=20 > > user > keep evidence that it legally use (or used) a granted=20 > channel? It may have impact on the protocol. > >=20 > > Teco > >=20 > > Op 1 apr 2011, om 20:25 heeft Paul Lambert het volgende geschreven: > >=20 > >>> I think Tim Polk wanted more words about security beyond=20 > just these. > >> Oh ... ok > >>=20 > >> I believe these are the overall threat areas: > >> device identity spoofing > >> modification of device requests > >> modification of channel enablement information impersonation of=20 > >> registered database services unauthorized disclosure of a users=20 > >> location > >>=20 > >> There may be other broader ways to phrase these - but we need to be > careful not to slip into device internal security versus the=20 > security of the protocol. > >>=20 > >> Translating the above into charter speak and as a revised=20 > suggestion: > >>=20 > >>=20 > >> The protocol must protect both the channel enablement=20 > process and the > privacy of users. > >> Robust security mechanisms are required to prevent: device=20 > identity=20 > >> spoofing, modification of device requests, modification of channel=20 > >> enablement information, impersonation of registered=20 > database services=20 > >> and > unauthorized disclosure of a users location. > >>=20 > >>=20 > >>=20 > >> Hope this helps ... > >>=20 > >> Paul > >>=20 > >>=20 > >> Paul A. Lambert | Marvell | +1 650 787 9141 > >>=20 > >> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > >> Sent: Friday, April 01, 2011 10:58 AM > >> To: Paul Lambert > >> Cc: Romascanu, Dan (Dan); Gabor.Bajko@nokia.com > (Nokia-CIC/SiliconValley); paws@ietf.org; Polk, William T. > >> Subject: Re: [paws] updated charter proposal > >>=20 > >> I think Tim Polk wanted more words about security beyond=20 > just these. > >>=20 > >> Brian > >>=20 > >> On Apr 1, 2011, at 7:52 PM, Paul Lambert wrote: > >>=20 > >>=20 > >>=20 > >> Friendly edit (below): > >>=20 > >> Since the location of a user device is involved, privacy=20 > implications > arise. The protocol must have robust mechanisms for mutual=20 > authentication and must prevent the unauthorized disclosure=20 > of a users location. > >>=20 > >>=20 > >> Paul > >>=20 > >> Paul A. Lambert | Marvell | +1 650 787 9141 > >>=20 > >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org]=20 > On Behalf=20 > >> Of Rosen, Brian > >> Sent: Friday, April 01, 2011 12:48 AM > >> To: Romascanu, Dan (Dan) > >> Cc: Gabor.Bajko@nokia.com (Nokia-CIC/SiliconValley);=20 > paws@ietf.org;=20 > >> Polk, > William T. > >> Subject: Re: [paws] updated charter proposal > >>=20 > >> Good news! There were charter changes requested in the BoF in the > security section. > >>=20 > >> I suggest that the line in the charter: > >> Since the location of a user device is involved, privacy=20 > implications > arise, and the protocol will have to have robust security mechanisms. > >>=20 > >> Be changed to: > >> Since the location of a user device is involved, privacy=20 > implications > arise, and the protocol will have to have robust security and=20 > privacy mechanisms. There are other security concerns,=20 > including spoofing and man in the middle attacks that will=20 > require analysis and mechanisms for mitigation in the protocol. > >>=20 > >> Brian > >>=20 > >> On Apr 1, 2011, at 9:33 AM, Romascanu, Dan (Dan) wrote: > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >> Hi, > >>=20 > >> I reported in the IESG and IAB meeting this morning about the PAWS=20 > >> BOF, > which in my opinion went quite well. My recommendation to=20 > continue the process with the chartering of a PAWS WG was=20 > well received. The WG (if approved after the review process)=20 > will be in the OPS area with a Technical Advisor from APPS. > >>=20 > >> The first step in the review process is internal review of the=20 > >> charter > with the IESG and the IAB, which will result into discussion=20 > in the IESG telechat on 4/14 and then sending of the charter=20 > to external (all IETF review). > >>=20 > >> Question - is this charter text OK for the internal review, or are=20 > >> there > any text changes following the BOF? > >>=20 > >> Thanks and Regards, > >>=20 > >> Dan > >>=20 > >>=20 > >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org]=20 > On Behalf=20 > >> Of Gabor.Bajko@nokia.com > >> Sent: Thursday, March 24, 2011 12:24 AM > >> To: paws@ietf.org > >> Subject: [paws] updated charter proposal > >>=20 > >> Folks, > >>=20 > >> Here's an updated charter proposal. > >>=20 > >> But please read these two drafts before you come to the BOF: > >>=20 > >> I-D: Protocol to Access White Space database: Problem=20 > statement and=20 > >> Requirements=20 > >> http://www.ietf.org/id/draft-patil-paws-problem-stmt-00.txt > >>=20 > >> I-D: Protocol to Access White Space database: Overview and=20 > Use case=20 > >> scenarios=20 > >> http://www.ietf.org/id/draft-probasco-paws-overview-usecases-00.txt > >>=20 > >>=20 > >>=20 > >> Governments around the world continue to search for new pieces of=20 > >> radio spectrum which can be used by the expanding wireless=20 > >> communications industry to provide more services in the usable=20 > >> spectrum. The concept of allowing secondary transmissions=20 > (licensed=20 > >> or unlicensed) in frequencies allocated to a primary user is a=20 > >> technique to "unlock" existing spectrum for new use. An obvious=20 > >> requirement is that these secondary transmissions do not interfere=20 > >> with the primary use of the spectrum. Often, in a given physical=20 > >> location, the primary user(s) may not be using the entire band=20 > >> allocated to them. The available spectrum for a secondary=20 > use would=20 > >> then depend on the location of the secondary user. The=20 > primary user=20 > >> may have a schedule when it uses the spectrum, which may=20 > be available=20 > >> for secondary use outside that schedule. The fundamental issue is=20 > >> how to determine for a specific location and specific=20 > time, if any of=20 > >> the primary spectrum is available for secondary use. One simple > > mechanism is to use a geospatial database that records protected=20 > > contours > for primary users, and require the secondary users to check=20 > the database prior to selecting what part of the spectrum=20 > they use. Such databases could be available on the Internet=20 > for query by users. > >> In a typical implementation of geolocation and database to=20 > access TV > white space, a radio is configured with, or has the=20 > capability to determine > its location in latitude and longitude. At power-on, before=20 > the device can > transmit or use any of the spectrum set aside for secondary=20 > use, the device must identify the relevant database to query,=20 > contact the database, provide its geolocation and receive in=20 > return a list of unoccupied or "white space" > spectrum (for example, in a TV White space implementation,=20 > the list of available channels at that location). The device=20 > can then select one of the channels from the list and begin=20 > to transmit and receive on the selected channel. The device=20 > must query the database subsequently on a periodic basis for=20 > a list of unoccupied channels based on certain conditions,=20 > e.g. a fixed amount of time has passed or the device has=20 > 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=20 > form of Internet connectivity, directly or indirectly. The=20 > databases may be country specific since the available=20 > spectrum and regulations may vary, but the fundamental=20 > operation of the protocol should be country independent, thus=20 > extensibility of data structures will be required. The=20 > solution will not be tied to any specific spectrum, country,=20 > or phy/mac/air interface but may incorporate relevant aspects=20 > of these as needed for proper operation. > >> The proposed working group will : > >> - standardize a protocol for querying the database,=20 > which includes=20 > >> a > location sensitive database discovery mechanism and security=20 > for the protocol, and application services. > >> - Standardize the data structure to be carried by the=20 > query protocol. > >> Since the location of a user device is involved, privacy=20 > implications > arise, and the protocol will have to have robust security mechanisms. > >> Existing IETF location data structures and privacy=20 > mechanisms may be > considered for use. The WG will also investigate the need for=20 > 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,=20 > including IEEE 802.11af and IEEE 802.22 to begin with. The=20 > working group may also consider input from regulatory=20 > entities that are involved in the specification of the rules=20 > for secondary use of spectrum in specific bands. > >> Milestones > >> Sep 2011 Submit 'Requirements and Framework' to the IESG for > >> publication as Informational > >> Apr 2012 Submit 'Protocol for Querying a Whitespace=20 > 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 > >>=20 > >> > >>=20 > >>=20 > >> _______________________________________________ > >> paws mailing list > >> paws@ietf.org > >> https://www.ietf.org/mailman/listinfo/paws > >=20 > > _______________________________________________ > > paws mailing list > > paws@ietf.org > > https://www.ietf.org/mailman/listinfo/paws > > _______________________________________________ > > paws mailing list > > paws@ietf.org > > https://www.ietf.org/mailman/listinfo/paws > >=20 > > _______________________________________________ > > paws mailing list > > paws@ietf.org > > https://www.ietf.org/mailman/listinfo/paws >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws >=20 From wphipps78@gmail.com Thu Apr 7 07:26:02 2011 Return-Path: X-Original-To: paws@core3.amsl.com Delivered-To: paws@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A63F28C11F for ; Thu, 7 Apr 2011 07:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hhhjaWE0m6A for ; Thu, 7 Apr 2011 07:26:01 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id E808D28C0E1 for ; Thu, 7 Apr 2011 07:26:00 -0700 (PDT) Received: by bwz13 with SMTP id 13so2331919bwz.31 for ; Thu, 07 Apr 2011 07:27:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=TboWYCEOWeSFyRF/wd4hj5wXd3DR89U28NS4zKCIKio=; b=x2HFU8YUTIQwk+hyaCM5ouNbjyLXW9S5LzyiSc4P/fKvTZ8bnlUd9dVzBka+rmb7c9 HaJZuZj+U7Jx7RRNxtS7zJI7tUWtH6pzZ6Fl4fwRry3y2Aesjs48LQ0rkwnifrXU5uaN PbjbGqrToppK6jLUjWdsaCqjPrl5OLQ1JV3xU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=uBnwkghFs4lAoByJk+rvGnC60wo1wvwLm8guQRxzXW1vxYtSQ9Od+vMHNHi6yUAXwI ykWGaNaX0RcDmyT/WeTxJ1Vj6C1UP7fqM26wBXqU68reHy2N6gLMBq/V0/iTp6nCtHDt vMXOTiu7PGz6TfW4ZPaH/SWVKwdNsJ4mGykhc= MIME-Version: 1.0 Received: by 10.204.26.132 with SMTP id e4mr852034bkc.142.1302186464999; Thu, 07 Apr 2011 07:27:44 -0700 (PDT) Received: by 10.204.38.66 with HTTP; Thu, 7 Apr 2011 07:27:44 -0700 (PDT) Date: Thu, 7 Apr 2011 15:27:44 +0100 Message-ID: From: William Phipps To: paws@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [paws] TVWS: Asia, Africa and Latin America X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 14:26:02 -0000 Folks, Apologies if this is not a topic that falls within the scope of the paws list: however, I know of no other place that has aggregated such a large number of experts and first adopters in this field. I wondered if anyone on the list may be aware of initiatives occurring in developed countries with regards to white spaces, or anyone/companies working in this area. Alternatively, any links to articles or blogs that cover this would be greatly appreciated. I read on a SpecNet ppt. that in Bangalore, something like 90% of the TV spectrum is unused. Best wishes, Will -- t: 07946 59 33 74 From warren@kumari.net Wed Apr 13 10:03:43 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 85962E079F for ; Wed, 13 Apr 2011 10:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMe6-bwo1REq for ; Wed, 13 Apr 2011 10:03:42 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfc.amsl.com (Postfix) with ESMTP id CD26AE0704 for ; Wed, 13 Apr 2011 10:03:42 -0700 (PDT) Received: from [172.19.118.183] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id D7FDE1B40CB5 for ; Wed, 13 Apr 2011 13:03:41 -0400 (EDT) Message-Id: <4D622A59-4EF8-4E94-A7CD-07B964EC6A1D@kumari.net> From: Warren Kumari To: paws@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 13 Apr 2011 13:03:40 -0400 X-Mailer: Apple Mail (2.936) Subject: [paws] [Somewhat off-topic] 'FCC head says mergers can't solve spectrum crunch' X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 17:03:43 -0000 Hi all, This is somewhat off-topic, but the list seemed low enough volume that folk wouldn't mind.... http://www.reuters.com/article/2011/04/12/us-fcc-spectrum-merger-idUSTRE73B7D020110412 W From Basavaraj.Patil@nokia.com Wed Apr 13 10:47:26 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 87F69E07EA for ; Wed, 13 Apr 2011 10:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.432 X-Spam-Level: X-Spam-Status: No, score=-104.432 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3cwMzrbDOum for ; Wed, 13 Apr 2011 10:47:25 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfc.amsl.com (Postfix) with ESMTP id C4A18E0841 for ; Wed, 13 Apr 2011 10:47:24 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p3DHl8nh007486; Wed, 13 Apr 2011 20:47:22 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Apr 2011 20:47:17 +0300 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 13 Apr 2011 19:47:17 +0200 Received: from 008-AM1MPN1-023.mgdnok.nokia.com ([169.254.3.94]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0270.002; Wed, 13 Apr 2011 19:47:16 +0200 From: To: , Thread-Topic: [paws] [Somewhat off-topic] 'FCC head says mergers can't solve spectrum crunch' Thread-Index: AQHL+gLUCq8sni7TGUS7Hcu7UbjaqQ== Date: Wed, 13 Apr 2011 17:47:16 +0000 Message-ID: In-Reply-To: <4D622A59-4EF8-4E94-A7CD-07B964EC6A1D@kumari.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [172.19.59.36] Content-Type: text/plain; charset="us-ascii" Content-ID: <6CA00BD94319EF4183BA6D2A409A727B@nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 13 Apr 2011 17:47:17.0641 (UTC) FILETIME=[D4BFCF90:01CBFA02] X-Nokia-AV: Clean Subject: Re: [paws] [Somewhat off-topic] 'FCC head says mergers can't solve spectrum crunch' X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 17:47:26 -0000 "Incentive auctions".... Does not mention anything about more unlicensed spectrum being freed up. On 4/13/11 12:03 PM, "ext Warren Kumari" wrote: >Hi all, > >This is somewhat off-topic, but the list seemed low enough volume that >folk wouldn't mind.... > >http://www.reuters.com/article/2011/04/12/us-fcc-spectrum-merger-idUSTRE73 >B7D020110412 > >W >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From horvitz@volny.cz Wed Apr 13 11:35:23 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7E75EE0723 for ; Wed, 13 Apr 2011 11:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.139 X-Spam-Level: X-Spam-Status: No, score=-0.139 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, SARE_HEAD_HDR_XSPAMTST=1.111] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YO7unRsgomg9 for ; Wed, 13 Apr 2011 11:35:21 -0700 (PDT) Received: from mxout.mail.volny.cz (mxout.mail.volny.cz [62.44.29.23]) by ietfc.amsl.com (Postfix) with ESMTP id 064AEE06AC for ; Wed, 13 Apr 2011 11:35:19 -0700 (PDT) Received: from kas30pipe.localhost (localhost.localdomain [127.0.0.1]) by mxout.mail.volny.cz (Postfix) with ESMTP id B3E8F1E0CCF for ; Wed, 13 Apr 2011 20:35:18 +0200 (CEST) Received: from webmail3.volny.internal (webmail3.volny.internal [172.20.100.63]) by mxout.mail.volny.cz (Postfix) with ESMTP id 995DF1E0CD2 for ; Wed, 13 Apr 2011 20:35:18 +0200 (CEST) Received: from webmail3.volny.internal (localhost.localdomain [127.0.0.1]) by webmail3.volny.internal (8.13.8/8.13.8) with ESMTP id p3DIZImv011369 for ; Wed, 13 Apr 2011 20:35:18 +0200 Received: (from apache@localhost) by webmail3.volny.internal (8.13.8/8.13.8/Submit) id p3DIZIU3011354; Wed, 13 Apr 2011 20:35:18 +0200 Received: from 91-103-38-154.dynamic.thecloud.net (91-103-38-154.dynamic.thecloud.net [91.103.38.154]) by mail3.volny.cz (mail3.volny.cz [62.44.29.43]) with HTTP; Wed, 13 Apr 2011 20:35:18 +0200 (CEST) MIME-Version: 1.0 From: horvitz@volny.cz X-Originating-Account: horvitz/volny.cz To: paws@ietf.org Date: Wed, 13 Apr 2011 20:35:03 +0200 (CEST) Message-ID: <29dd95d03a4acff43dd16b6a291e0dd1@mail3.volny.cz> X-Mailer: Volny.cz Webmail2 2.147 X-Originating-Ip: 91.103.38.154 X-Originating-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.204 Safari/534.16 X-Webmail2-Origin: horvitz/volny.cz [91.103.38.154] X-Priority: 3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-SpamTest-Envelope-From: horvitz@volny.cz X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 20764 [Apr 13 2011] X-SpamTest-Info: {RECEIVED: dynamic ip detected} X-SpamTest-Method: none X-SpamTest-Rate: 5 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0284], KAS30/Release Subject: [paws] =?iso-8859-2?q?White_space_developments_in_Europe=2C_Asia?= =?iso-8859-2?q?=2C_Africa=2C_Latin_America?= X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 18:35:23 -0000 Greetings all, I was sorry to miss the IETF meeting in Prague (since I live there) but I was in another part of the world at the time. Nevertheless I hope to be involved in PAWS from now on (if it's approved today by IETF). I am already involved in CEPT's working group SE43 (Cognitive Access to TV White Spaces), which is meeting 14-15 April in Copenhagen. where I am now. Here is the announcement for that meeting: http://www.ero.dk/594454CD-6109-468D-ACCD-91BCCCA05710.W5Doc?frames=no&id=19C3C5B7-32BE-4C26-88DC-AAD9E30EAFC5 Late last year, SE43 released its first recommendations on the cognitive use of white spaces in the CEPT member countries (including all of Europe and nearby regions). Here is it: http://www.ero.dk/D9634A59-1F13-40D1-91E9-DAE6468ED66C?frames=no& As you can see they differ from the FCC's approach and there are many important but still unanswered questions. So the group's mandate has been extended and the meeting in Copenhagen will discuss next steps, including device testing and the possibility of expanding the database to support other services in other bands (e.g. RLANs at 5 GHz). Just yesterday, a committee in the European Parliament strongly endorsed the release of white spaces for license exempt use by nonbroadcast services. This must be approved by the Parliament as a whole to become an EU policy, but it's an encouraging sign that may change the tone of the discussion in SE43, which has been dominated by their mandate to protect broadcasting and wireless microphones against intereference. In any case, I saw in the draft charter ("Proposed Working Group" for PAWS) that "The Working Group will set up and maintain appropriate contact and liaison with other relevant standards bodies and groups... [and] may also consider input from regulatory entities..." With that in mind, I sent the draft "use cases" document from Scott Probasco, Tom Derryberry and Basavaraj Patilem to the chairman of SE43, in order to get time during the meeting which starts tomorrow to alert SE43 members to IETF's possible interest in developing a global protocol for communication between WS devices and geolocation databases. SE43 has already explored and outlined the dimensions of this communication (in considerably more depth than PAWS, I might add), so it is appropriate for SE43 to discuss whether to begin cooperating with others (like IETF, the FCC, CITEL and other regional groupings) to seek global harmonisation, or to compete with other proposals and let CEPT member states decide what to require, leave the task to others, or follow some other arrangement. In any case, this note is to alert you to CEPT's work and ask you to start thinking about the appropriate relationship between PAWS and SE43, if any. A few days ago, William Phipps asked about white space developments in Latin America, Africa and Asia. I've been tracking those for the Open Spectrum Alliance. See http://www.openspectrum.eu/drupal6/node/23 Unfortunately, my survey hasn't been updated for a year, and there are lots of new things to report. About 20 countries have expressed interest in opening their white spaces, including China, I just haven't had time to put the new info online. Perhaps after Copenhagen. >BOB< -- Robert Horvitz Stichting Open Spectrum Slavikova 11, 120 00 Prague 2, Czech Republic Gelderlandplein 75 L, 1082 LV Amsterdam, Nederland mailto:bob@openspectrum.info http://www.openspectrum.info/ mob: +420 775024705 tel/fax: +420 222967456 From Basavaraj.Patil@nokia.com Wed Apr 13 12:24:09 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 97FC8E07B4 for ; Wed, 13 Apr 2011 12:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.724 X-Spam-Level: X-Spam-Status: No, score=-103.724 tagged_above=-999 required=5 tests=[AWL=-1.125, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYYho0bT60iG for ; Wed, 13 Apr 2011 12:24:07 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfc.amsl.com (Postfix) with ESMTP id 8EE20E07A4 for ; Wed, 13 Apr 2011 12:24:07 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p3DJNtS4016970; Wed, 13 Apr 2011 22:24:04 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Apr 2011 22:23:45 +0300 Received: from 008-AM1MMR1-003.mgdnok.nokia.com (65.54.30.58) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 13 Apr 2011 21:23:45 +0200 Received: from 008-AM1MPN1-023.mgdnok.nokia.com ([169.254.3.94]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.01.0270.002; Wed, 13 Apr 2011 21:23:44 +0200 From: To: , Thread-Topic: [paws] White space developments in Europe, Asia, Africa, Latin America Thread-Index: AQHL+gmUkb0+sVwZ4UafezFTKzGlH5RcKyXw Date: Wed, 13 Apr 2011 19:23:43 +0000 Message-ID: <21E7D9BD69CC7241AAE00F4EA183B71901A417@008-AM1MPN1-023.mgdnok.nokia.com> References: <29dd95d03a4acff43dd16b6a291e0dd1@mail3.volny.cz> In-Reply-To: <29dd95d03a4acff43dd16b6a291e0dd1@mail3.volny.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.59.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 13 Apr 2011 19:23:45.0191 (UTC) FILETIME=[4E65DB70:01CBFA10] X-Nokia-AV: Clean Subject: Re: [paws] White space developments in Europe, Asia, Africa, Latin America X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 19:24:09 -0000 Hi Bob, Thanks for the update. I do know about the work being done by SE43 and CEPT= .=20 Regarding your question about: " In any case, this note is to alert you to CEPT's work and ask you to start thinking about the appropriate relationship between PAWS and SE43, if any. " At the present time, there is an effort to at least establish a liaison wit= h IEEE. Maybe there could be a similar one with SE43?=20 I believe that a single global standard for the device-DB interface will be= nefit the technology in general vs having competing variants for the same p= urpose. I hope SE43 looks at the PAWS charter and the people therein contri= bute to the IETF effort with requirements and other expertise. -Basavaraj -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= horvitz@volny.cz Sent: Wednesday, April 13, 2011 1:35 PM To: paws@ietf.org Subject: [paws] White space developments in Europe, Asia, Africa, Latin Ame= rica Greetings all, I was sorry to miss the IETF meeting in Prague (since I live there) but I was in another part of the world at the time. Nevertheless I hope to be involved in PAWS from now on (if it's approved today by IETF). I am already involved in CEPT's working group SE43 (Cognitive Access to TV White Spaces), which is meeting 14-15 April in Copenhagen. where I am now. Here is the announcement for that meeting: http://www.ero.dk/594454CD-6109-468D-ACCD-91BCCCA05710.W5Doc?frames=3Dno&id= =3D19C3C5B7-32BE-4C26-88DC-AAD9E30EAFC5 Late last year, SE43 released its first recommendations on the cognitive use of white spaces in the CEPT member countries (including all of Europe and nearby regions). Here is it: http://www.ero.dk/D9634A59-1F13-40D1-91E9-DAE6468ED66C?frames=3Dno& As you can see they differ from the FCC's approach and there are many important but still unanswered questions. So the group's mandate has been extended and the meeting in Copenhagen will discuss next steps, including device testing and the possibility of expanding the database to support other services in other bands (e.g. RLANs at 5 GHz). Just yesterday, a committee in the European Parliament strongly endorsed the release of white spaces for license exempt use by nonbroadcast services. This must be approved by the Parliament as a whole to become an EU policy, but it's an encouraging sign that may change the tone of the discussion in SE43, which has been dominated by their mandate to protect broadcasting and wireless microphones against intereference. In any case, I saw in the draft charter ("Proposed Working Group" for PAWS) that=20 "The Working Group will set up and maintain appropriate contact and liaison with other relevant standards bodies and groups... [and] may also consider input from regulatory entities..." With that in mind, I sent the draft "use cases" document from Scott Probasco, Tom Derryberry and Basavaraj Patilem to the chairman of SE43, in order to get time during the meeting which starts tomorrow to alert SE43 members to IETF's possible interest in developing a global protocol for communication between WS devices and geolocation databases. SE43 has already explored and outlined the dimensions of this communication (in considerably more depth than PAWS, I might add), so it is appropriate for SE43 to discuss whether to begin cooperating with others (like IETF, the FCC, CITEL and other regional groupings) to seek global harmonisation, or to compete with other proposals and let CEPT member states decide what to require, leave the task to others, or follow some other arrangement.=20 In any case, this note is to alert you to CEPT's work and ask you to start thinking about the appropriate relationship between PAWS and SE43, if any. A few days ago, William Phipps asked about white space developments in Latin America, Africa and Asia. I've been tracking those for the Open Spectrum Alliance. See=20 http://www.openspectrum.eu/drupal6/node/23 Unfortunately, my survey hasn't been updated for a year, and there are lots of new things to report. About 20 countries have expressed interest in opening their white spaces, including China, I just haven't had time to put the new info online. Perhaps after Copenhagen. >BOB< --=20 Robert Horvitz Stichting Open Spectrum Slavikova 11, 120 00 Prague 2, Czech Republic Gelderlandplein 75 L, 1082 LV Amsterdam, Nederland mailto:bob@openspectrum.info http://www.openspectrum.info/ mob: +420 775024705 tel/fax: +420 222967456 _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From paul@marvell.com Wed Apr 13 15:24:36 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5EC5EE06F1 for ; Wed, 13 Apr 2011 15:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7gaM+TPr-pri for ; Wed, 13 Apr 2011 15:24:34 -0700 (PDT) Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by ietfc.amsl.com (Postfix) with ESMTP id 2B290E0697 for ; Wed, 13 Apr 2011 15:24:33 -0700 (PDT) Received: from SC-OWA01.marvell.com ([65.219.4.129]) (using TLSv1) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKTaYinNbC/PVVdZ7vj3Au08IdEWaCiaQQ@postini.com; Wed, 13 Apr 2011 15:24:34 PDT Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Wed, 13 Apr 2011 15:12:45 -0700 From: Paul Lambert To: "Basavaraj.Patil@nokia.com" , "horvitz@volny.cz" , "paws@ietf.org" Date: Wed, 13 Apr 2011 15:15:06 -0700 Thread-Topic: [paws] White space developments in Europe, Asia, Africa, Latin America Thread-Index: AQHL+gmUkb0+sVwZ4UafezFTKzGlH5RcKyXwgAApzwA= Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01406A194D6@SC-VEXCH2.marvell.com> References: <29dd95d03a4acff43dd16b6a291e0dd1@mail3.volny.cz> <21E7D9BD69CC7241AAE00F4EA183B71901A417@008-AM1MPN1-023.mgdnok.nokia.com> In-Reply-To: <21E7D9BD69CC7241AAE00F4EA183B71901A417@008-AM1MPN1-023.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [paws] White space developments in Europe, Asia, Africa, Latin America X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 22:24:36 -0000 Seems like there are a bunch of groups for potential liaison .... IEEE 802.11af - 802.11 in the TVWS band Wi-Fi Alliance TV White Spaces - specification (built on 802.11af),=20 certification and testing of TVWS devices and the device-to-GDB interfa= ce) IEEE SCC41 P1900 DYSPAN - dynamic spectrum access, cognitive radio,=20 interference management, coordination of wireless systems, advanced=20 spectrum management, and policy languages for next generation radio sys= tems IEEE 802.22 SE43 - Cognitive radio systems - White spaces (470 - 790 MHz) Others? Paul Paul A. Lambert | Marvell | +1 650 787 9141 > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of > Basavaraj.Patil@nokia.com > Sent: Wednesday, April 13, 2011 12:24 PM > To: horvitz@volny.cz; paws@ietf.org > Subject: Re: [paws] White space developments in Europe, Asia, Africa, > Latin America >=20 > Hi Bob, >=20 > Thanks for the update. I do know about the work being done by SE43 and > CEPT. > Regarding your question about: > " In any case, this note is to alert you to CEPT's work and ask you to > start thinking about the appropriate relationship between PAWS and > SE43, if any. > " >=20 > At the present time, there is an effort to at least establish a liaison > with IEEE. > Maybe there could be a similar one with SE43? > I believe that a single global standard for the device-DB interface > will benefit the technology in general vs having competing variants for > the same purpose. I hope SE43 looks at the PAWS charter and the people > therein contribute to the IETF effort with requirements and other > expertise. >=20 > -Basavaraj >=20 > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of > ext horvitz@volny.cz > Sent: Wednesday, April 13, 2011 1:35 PM > To: paws@ietf.org > Subject: [paws] White space developments in Europe, Asia, Africa, Latin > America >=20 > Greetings all, >=20 > I was sorry to miss the IETF meeting in Prague (since I live there) > but I was in another part of the world at the time. Nevertheless I > hope to be involved in PAWS from now on (if it's approved today by > IETF). I am already involved in CEPT's working group SE43 (Cognitive > Access to TV White Spaces), which is meeting 14-15 April in > Copenhagen. where I am now. Here is the announcement for that > meeting: >=20 > http://www.ero.dk/594454CD-6109-468D-ACCD- > 91BCCCA05710.W5Doc?frames=3Dno&id=3D19C3C5B7-32BE-4C26-88DC-AAD9E30EAFC5 >=20 > Late last year, SE43 released its first recommendations on the > cognitive use of white spaces in the CEPT member countries > (including all of Europe and nearby regions). Here is it: >=20 > http://www.ero.dk/D9634A59-1F13-40D1-91E9-DAE6468ED66C?frames=3Dno& >=20 > As you can see they differ from the FCC's approach and there are > many important but still unanswered questions. So the group's > mandate has been extended and the meeting in Copenhagen will discuss > next steps, including device testing and the possibility of > expanding the database to support other services in other bands > (e.g. RLANs at 5 GHz). >=20 > Just yesterday, a committee in the European Parliament strongly > endorsed the release of white spaces for license exempt use by > nonbroadcast services. This must be approved by the Parliament as a > whole to become an EU policy, but it's an encouraging sign that may > change the tone of the discussion in SE43, which has been dominated > by their mandate to protect broadcasting and wireless microphones > against intereference. >=20 > In any case, I saw in the draft charter ("Proposed Working Group" > for PAWS) that >=20 > "The Working Group will set up and maintain appropriate contact and > liaison with other relevant standards bodies and groups... [and] may > also consider input from regulatory entities..." >=20 > With that in mind, I sent the draft "use cases" document from Scott > Probasco, Tom Derryberry and Basavaraj Patilem to the chairman of > SE43, in order to get time during the meeting which starts tomorrow > to alert SE43 members to IETF's possible interest in developing a > global protocol for communication between WS devices and geolocation > databases. SE43 has already explored and outlined the dimensions of > this communication (in considerably more depth than PAWS, I might > add), so it is appropriate for SE43 to discuss whether to begin > cooperating with others (like IETF, the FCC, CITEL and other > regional groupings) to seek global harmonisation, or to compete with > other proposals and let CEPT member states decide what to require, > leave the task to others, or follow some other arrangement. >=20 > In any case, this note is to alert you to CEPT's work and ask you to > start thinking about the appropriate relationship between PAWS and > SE43, if any. >=20 > A few days ago, William Phipps asked about white space developments > in Latin America, Africa and Asia. I've been tracking those for the > Open Spectrum Alliance. See >=20 > http://www.openspectrum.eu/drupal6/node/23 >=20 > Unfortunately, my survey hasn't been updated for a year, and there > are lots of new things to report. About 20 countries have expressed > interest in opening their white spaces, including China, I just > haven't had time to put the new info online. Perhaps after > Copenhagen. >=20 > >BOB< >=20 >=20 > -- > Robert Horvitz > Stichting Open Spectrum > Slavikova 11, 120 00 Prague 2, Czech Republic > Gelderlandplein 75 L, 1082 LV Amsterdam, Nederland > mailto:bob@openspectrum.info > http://www.openspectrum.info/ > mob: +420 775024705 > tel/fax: +420 222967456 >=20 >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From brian.rosen@neustar.biz Wed Apr 13 16:13:04 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9174BE07E7 for ; Wed, 13 Apr 2011 16:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AA6rV1wStCkO for ; Wed, 13 Apr 2011 16:13:03 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfc.amsl.com (Postfix) with ESMTP id 1C609E07E9 for ; Wed, 13 Apr 2011 16:13:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1302736381; x=1618091146; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=lwSb/eYQSC+4bMO8zn6Sl h2lr4YPNSJQmWNJkgf7J5g=; b=WM4UdRapGV8SdALlViyjANmsg66dD+a+n8upi iFrzhI6MpZ3IOTP4rA7fndZPfacKjWTNphD0/1wFnxWZsXQmw== Received: from ([10.31.13.229]) by stihiron2.va.neustar.com with ESMTP with TLS id 5202732.44078003; Wed, 13 Apr 2011 19:13:00 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Wed, 13 Apr 2011 19:12:59 -0400 From: "Rosen, Brian" To: Paul Lambert Date: Wed, 13 Apr 2011 19:12:58 -0400 Thread-Topic: [paws] White space developments in Europe, Asia, Africa, Latin America Thread-Index: Acv6MFSTUOsLFn8PRQWqpC9Rej26LQ== Message-ID: References: <29dd95d03a4acff43dd16b6a291e0dd1@mail3.volny.cz> <21E7D9BD69CC7241AAE00F4EA183B71901A417@008-AM1MPN1-023.mgdnok.nokia.com> <7BAC95F5A7E67643AAFB2C31BEE662D01406A194D6@SC-VEXCH2.marvell.com> In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D01406A194D6@SC-VEXCH2.marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: pA4wbN+CKm/MAEg+GOZQxg== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] White space developments in Europe, Asia, Africa, Latin America X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 23:13:04 -0000 I just heard about 802.19.1 Not real familiar with their work, but they seem to be working on sharing o= f allowed channels (that is, if the database says channels 3, 5 and 10 are = available, but tells 100 devices the same thing, how do the devices spread = use over those channels). Out of our scope for now, but staying in touch m= ay be useful. Brian On Apr 13, 2011, at 6:15 PM, Paul Lambert wrote: > Seems like there are a bunch of groups for potential liaison .... >=20 > IEEE 802.11af - 802.11 in the TVWS band >=20 > Wi-Fi Alliance TV White Spaces - specification (built on 802.11af),=20 > certification and testing of TVWS devices and the device-to-GDB interf= ace) >=20 > IEEE SCC41 P1900 DYSPAN - dynamic spectrum access, cognitive radio,=20 > interference management, coordination of wireless systems, advanced=20 > spectrum management, and policy languages for next generation radio sy= stems >=20 > IEEE 802.22 >=20 > SE43 - Cognitive radio systems - White spaces (470 - 790 MHz) >=20 > Others? >=20 > Paul >=20 > Paul A. Lambert | Marvell | +1 650 787 9141 >=20 >> -----Original Message----- >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >> Basavaraj.Patil@nokia.com >> Sent: Wednesday, April 13, 2011 12:24 PM >> To: horvitz@volny.cz; paws@ietf.org >> Subject: Re: [paws] White space developments in Europe, Asia, Africa, >> Latin America >>=20 >> Hi Bob, >>=20 >> Thanks for the update. I do know about the work being done by SE43 and >> CEPT. >> Regarding your question about: >> " In any case, this note is to alert you to CEPT's work and ask you to >> start thinking about the appropriate relationship between PAWS and >> SE43, if any. >> " >>=20 >> At the present time, there is an effort to at least establish a liaison >> with IEEE. >> Maybe there could be a similar one with SE43? >> I believe that a single global standard for the device-DB interface >> will benefit the technology in general vs having competing variants for >> the same purpose. I hope SE43 looks at the PAWS charter and the people >> therein contribute to the IETF effort with requirements and other >> expertise. >>=20 >> -Basavaraj >>=20 >> -----Original Message----- >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >> ext horvitz@volny.cz >> Sent: Wednesday, April 13, 2011 1:35 PM >> To: paws@ietf.org >> Subject: [paws] White space developments in Europe, Asia, Africa, Latin >> America >>=20 >> Greetings all, >>=20 >> I was sorry to miss the IETF meeting in Prague (since I live there) >> but I was in another part of the world at the time. Nevertheless I >> hope to be involved in PAWS from now on (if it's approved today by >> IETF). I am already involved in CEPT's working group SE43 (Cognitive >> Access to TV White Spaces), which is meeting 14-15 April in >> Copenhagen. where I am now. Here is the announcement for that >> meeting: >>=20 >> http://www.ero.dk/594454CD-6109-468D-ACCD- >> 91BCCCA05710.W5Doc?frames=3Dno&id=3D19C3C5B7-32BE-4C26-88DC-AAD9E30EAFC5 >>=20 >> Late last year, SE43 released its first recommendations on the >> cognitive use of white spaces in the CEPT member countries >> (including all of Europe and nearby regions). Here is it: >>=20 >> http://www.ero.dk/D9634A59-1F13-40D1-91E9-DAE6468ED66C?frames=3Dno& >>=20 >> As you can see they differ from the FCC's approach and there are >> many important but still unanswered questions. So the group's >> mandate has been extended and the meeting in Copenhagen will discuss >> next steps, including device testing and the possibility of >> expanding the database to support other services in other bands >> (e.g. RLANs at 5 GHz). >>=20 >> Just yesterday, a committee in the European Parliament strongly >> endorsed the release of white spaces for license exempt use by >> nonbroadcast services. This must be approved by the Parliament as a >> whole to become an EU policy, but it's an encouraging sign that may >> change the tone of the discussion in SE43, which has been dominated >> by their mandate to protect broadcasting and wireless microphones >> against intereference. >>=20 >> In any case, I saw in the draft charter ("Proposed Working Group" >> for PAWS) that >>=20 >> "The Working Group will set up and maintain appropriate contact and >> liaison with other relevant standards bodies and groups... [and] may >> also consider input from regulatory entities..." >>=20 >> With that in mind, I sent the draft "use cases" document from Scott >> Probasco, Tom Derryberry and Basavaraj Patilem to the chairman of >> SE43, in order to get time during the meeting which starts tomorrow >> to alert SE43 members to IETF's possible interest in developing a >> global protocol for communication between WS devices and geolocation >> databases. SE43 has already explored and outlined the dimensions of >> this communication (in considerably more depth than PAWS, I might >> add), so it is appropriate for SE43 to discuss whether to begin >> cooperating with others (like IETF, the FCC, CITEL and other >> regional groupings) to seek global harmonisation, or to compete with >> other proposals and let CEPT member states decide what to require, >> leave the task to others, or follow some other arrangement. >>=20 >> In any case, this note is to alert you to CEPT's work and ask you to >> start thinking about the appropriate relationship between PAWS and >> SE43, if any. >>=20 >> A few days ago, William Phipps asked about white space developments >> in Latin America, Africa and Asia. I've been tracking those for the >> Open Spectrum Alliance. See >>=20 >> http://www.openspectrum.eu/drupal6/node/23 >>=20 >> Unfortunately, my survey hasn't been updated for a year, and there >> are lots of new things to report. About 20 countries have expressed >> interest in opening their white spaces, including China, I just >> haven't had time to put the new info online. Perhaps after >> Copenhagen. >>=20 >>> BOB< >>=20 >>=20 >> -- >> Robert Horvitz >> Stichting Open Spectrum >> Slavikova 11, 120 00 Prague 2, Czech Republic >> Gelderlandplein 75 L, 1082 LV Amsterdam, Nederland >> mailto:bob@openspectrum.info >> http://www.openspectrum.info/ >> mob: +420 775024705 >> tel/fax: +420 222967456 >>=20 >>=20 >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From paul@marvell.com Wed Apr 13 16:22:53 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B48A3E0707 for ; Wed, 13 Apr 2011 16:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oeY0Fqld9ZtM for ; Wed, 13 Apr 2011 16:22:52 -0700 (PDT) Received: from na3sys009aog101.obsmtp.com (na3sys009aog101.obsmtp.com [74.125.149.67]) by ietfc.amsl.com (Postfix) with ESMTP id 16A4CE06E8 for ; Wed, 13 Apr 2011 16:22:52 -0700 (PDT) Received: from SC-OWA01.marvell.com ([65.219.4.129]) (using TLSv1) by na3sys009aob101.postini.com ([74.125.148.12]) with SMTP ID DSNKTaYwRoKflSckav8E3/vNX7GO4QRsaHOX@postini.com; Wed, 13 Apr 2011 16:22:52 PDT Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Wed, 13 Apr 2011 16:14:24 -0700 From: Paul Lambert To: "Rosen, Brian" Date: Wed, 13 Apr 2011 16:16:44 -0700 Thread-Topic: [paws] White space developments in Europe, Asia, Africa, Latin America Thread-Index: Acv6MFSTUOsLFn8PRQWqpC9Rej26LQAABJPQ Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01406A19510@SC-VEXCH2.marvell.com> References: <29dd95d03a4acff43dd16b6a291e0dd1@mail3.volny.cz> <21E7D9BD69CC7241AAE00F4EA183B71901A417@008-AM1MPN1-023.mgdnok.nokia.com> <7BAC95F5A7E67643AAFB2C31BEE662D01406A194D6@SC-VEXCH2.marvell.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] White space developments in Europe, Asia, Africa, Latin America X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 23:22:53 -0000 Yes - 802.19.1 is not in scope since it's looking at coexistence issues and= not database enablement. The information exchanged (channels, frequencies= , power, might be similar). I'm also not sure what part of P1900 is related but again it's worth knowin= g they exist. There's also an ETSI standard on white spaces - but it's strictly sensing b= ased (not relevant).=20 Paul > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > Sent: Wednesday, April 13, 2011 4:13 PM > To: Paul Lambert > Cc: Basavaraj.Patil@nokia.com; horvitz@volny.cz; paws@ietf.org > Subject: Re: [paws] White space developments in Europe, Asia, Africa, > Latin America >=20 > I just heard about 802.19.1 >=20 > Not real familiar with their work, but they seem to be working on > sharing of allowed channels (that is, if the database says channels 3, > 5 and 10 are available, but tells 100 devices the same thing, how do > the devices spread use over those channels). Out of our scope for now, > but staying in touch may be useful. >=20 > Brian >=20 > On Apr 13, 2011, at 6:15 PM, Paul Lambert wrote: >=20 > > Seems like there are a bunch of groups for potential liaison .... > > > > IEEE 802.11af - 802.11 in the TVWS band > > > > Wi-Fi Alliance TV White Spaces - specification (built on > 802.11af), > > certification and testing of TVWS devices and the device-to-GDB > interface) > > > > IEEE SCC41 P1900 DYSPAN - dynamic spectrum access, cognitive > radio, > > interference management, coordination of wireless systems, > advanced > > spectrum management, and policy languages for next generation > radio systems > > > > IEEE 802.22 > > > > SE43 - Cognitive radio systems - White spaces (470 - 790 MHz) > > > > Others? > > > > Paul > > > > Paul A. Lambert | Marvell | +1 650 787 9141 > > > >> -----Original Message----- > >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf > Of > >> Basavaraj.Patil@nokia.com > >> Sent: Wednesday, April 13, 2011 12:24 PM > >> To: horvitz@volny.cz; paws@ietf.org > >> Subject: Re: [paws] White space developments in Europe, Asia, > Africa, > >> Latin America > >> > >> Hi Bob, > >> > >> Thanks for the update. I do know about the work being done by SE43 > and > >> CEPT. > >> Regarding your question about: > >> " In any case, this note is to alert you to CEPT's work and ask you > to > >> start thinking about the appropriate relationship between PAWS and > >> SE43, if any. > >> " > >> > >> At the present time, there is an effort to at least establish a > liaison > >> with IEEE. > >> Maybe there could be a similar one with SE43? > >> I believe that a single global standard for the device-DB interface > >> will benefit the technology in general vs having competing variants > for > >> the same purpose. I hope SE43 looks at the PAWS charter and the > people > >> therein contribute to the IETF effort with requirements and other > >> expertise. > >> > >> -Basavaraj > >> > >> -----Original Message----- > >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf > Of > >> ext horvitz@volny.cz > >> Sent: Wednesday, April 13, 2011 1:35 PM > >> To: paws@ietf.org > >> Subject: [paws] White space developments in Europe, Asia, Africa, > Latin > >> America > >> > >> Greetings all, > >> > >> I was sorry to miss the IETF meeting in Prague (since I live there) > >> but I was in another part of the world at the time. Nevertheless I > >> hope to be involved in PAWS from now on (if it's approved today by > >> IETF). I am already involved in CEPT's working group SE43 (Cognitive > >> Access to TV White Spaces), which is meeting 14-15 April in > >> Copenhagen. where I am now. Here is the announcement for that > >> meeting: > >> > >> http://www.ero.dk/594454CD-6109-468D-ACCD- > >> 91BCCCA05710.W5Doc?frames=3Dno&id=3D19C3C5B7-32BE-4C26-88DC-AAD9E30EAF= C5 > >> > >> Late last year, SE43 released its first recommendations on the > >> cognitive use of white spaces in the CEPT member countries > >> (including all of Europe and nearby regions). Here is it: > >> > >> http://www.ero.dk/D9634A59-1F13-40D1-91E9-DAE6468ED66C?frames=3Dno& > >> > >> As you can see they differ from the FCC's approach and there are > >> many important but still unanswered questions. So the group's > >> mandate has been extended and the meeting in Copenhagen will discuss > >> next steps, including device testing and the possibility of > >> expanding the database to support other services in other bands > >> (e.g. RLANs at 5 GHz). > >> > >> Just yesterday, a committee in the European Parliament strongly > >> endorsed the release of white spaces for license exempt use by > >> nonbroadcast services. This must be approved by the Parliament as a > >> whole to become an EU policy, but it's an encouraging sign that may > >> change the tone of the discussion in SE43, which has been dominated > >> by their mandate to protect broadcasting and wireless microphones > >> against intereference. > >> > >> In any case, I saw in the draft charter ("Proposed Working Group" > >> for PAWS) that > >> > >> "The Working Group will set up and maintain appropriate contact and > >> liaison with other relevant standards bodies and groups... [and] may > >> also consider input from regulatory entities..." > >> > >> With that in mind, I sent the draft "use cases" document from Scott > >> Probasco, Tom Derryberry and Basavaraj Patilem to the chairman of > >> SE43, in order to get time during the meeting which starts tomorrow > >> to alert SE43 members to IETF's possible interest in developing a > >> global protocol for communication between WS devices and geolocation > >> databases. SE43 has already explored and outlined the dimensions of > >> this communication (in considerably more depth than PAWS, I might > >> add), so it is appropriate for SE43 to discuss whether to begin > >> cooperating with others (like IETF, the FCC, CITEL and other > >> regional groupings) to seek global harmonisation, or to compete with > >> other proposals and let CEPT member states decide what to require, > >> leave the task to others, or follow some other arrangement. > >> > >> In any case, this note is to alert you to CEPT's work and ask you to > >> start thinking about the appropriate relationship between PAWS and > >> SE43, if any. > >> > >> A few days ago, William Phipps asked about white space developments > >> in Latin America, Africa and Asia. I've been tracking those for the > >> Open Spectrum Alliance. See > >> > >> http://www.openspectrum.eu/drupal6/node/23 > >> > >> Unfortunately, my survey hasn't been updated for a year, and there > >> are lots of new things to report. About 20 countries have expressed > >> interest in opening their white spaces, including China, I just > >> haven't had time to put the new info online. Perhaps after > >> Copenhagen. > >> > >>> BOB< > >> > >> > >> -- > >> Robert Horvitz > >> Stichting Open Spectrum > >> Slavikova 11, 120 00 Prague 2, Czech Republic > >> Gelderlandplein 75 L, 1082 LV Amsterdam, Nederland > >> mailto:bob@openspectrum.info > >> http://www.openspectrum.info/ > >> mob: +420 775024705 > >> tel/fax: +420 222967456 > >> > >> > >> _______________________________________________ > >> paws mailing list > >> paws@ietf.org > >> https://www.ietf.org/mailman/listinfo/paws > >> _______________________________________________ > >> paws mailing list > >> paws@ietf.org > >> https://www.ietf.org/mailman/listinfo/paws > > _______________________________________________ > > paws mailing list > > paws@ietf.org > > https://www.ietf.org/mailman/listinfo/paws From pierre-jean.muller@huawei.com Wed Apr 13 23:56:59 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A784AE082C for ; Wed, 13 Apr 2011 23:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQK1MD3sc5H2 for ; Wed, 13 Apr 2011 23:56:58 -0700 (PDT) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by ietfc.amsl.com (Postfix) with ESMTP id 06C45E0670 for ; Wed, 13 Apr 2011 23:56:58 -0700 (PDT) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJM00DYWRAWPO@usaga03-in.huawei.com> for paws@ietf.org; Thu, 14 Apr 2011 01:56:57 -0500 (CDT) Received: from p79098 ([217.167.116.161]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LJM00HJ5RAV7H@usaga03-in.huawei.com> for paws@ietf.org; Thu, 14 Apr 2011 01:56:56 -0500 (CDT) Date: Thu, 14 Apr 2011 08:57:03 +0200 From: Pierre-Jean Muller In-reply-to: <7BAC95F5A7E67643AAFB2C31BEE662D01406A19510@SC-VEXCH2.marvell.com> To: paws@ietf.org Message-id: <000001cbfa71$29ad1ad0$7d075070$%muller@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: Acv6MFSTUOsLFn8PRQWqpC9Rej26LQAABJPQAA+wJgA= References: <29dd95d03a4acff43dd16b6a291e0dd1@mail3.volny.cz> <21E7D9BD69CC7241AAE00F4EA183B71901A417@008-AM1MPN1-023.mgdnok.nokia.com> <7BAC95F5A7E67643AAFB2C31BEE662D01406A194D6@SC-VEXCH2.marvell.com> <7BAC95F5A7E67643AAFB2C31BEE662D01406A19510@SC-VEXCH2.marvell.com> Subject: Re: [paws] White space developments in Europe, Asia, Africa, Latin America X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 06:56:59 -0000 Dear all, ETSI, namely RRS is not only looking at sensing but covers the cognitive radio system as a whole including system and protocol aspects for DB, CPC, Radio Access Network ... and this for different applications such as UHF TV band WS, IMT and GSM bands macro and Public Safety. RRS covers SDR as well with a primary focus on mobile device architecture and interfaces. RRS is also working with SE43 Regards, Pierre-Jean -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Paul Lambert Sent: Thursday, April 14, 2011 1:17 AM To: Rosen, Brian Cc: paws@ietf.org Subject: Re: [paws] White space developments in Europe, Asia, Africa, Latin America Yes - 802.19.1 is not in scope since it's looking at coexistence issues and not database enablement. The information exchanged (channels, frequencies, power, might be similar). I'm also not sure what part of P1900 is related but again it's worth knowing they exist. There's also an ETSI standard on white spaces - but it's strictly sensing based (not relevant). Paul > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > Sent: Wednesday, April 13, 2011 4:13 PM > To: Paul Lambert > Cc: Basavaraj.Patil@nokia.com; horvitz@volny.cz; paws@ietf.org > Subject: Re: [paws] White space developments in Europe, Asia, Africa, > Latin America > > I just heard about 802.19.1 > > Not real familiar with their work, but they seem to be working on > sharing of allowed channels (that is, if the database says channels 3, > 5 and 10 are available, but tells 100 devices the same thing, how do > the devices spread use over those channels). Out of our scope for now, > but staying in touch may be useful. > > Brian > > On Apr 13, 2011, at 6:15 PM, Paul Lambert wrote: > > > Seems like there are a bunch of groups for potential liaison .... > > > > IEEE 802.11af - 802.11 in the TVWS band > > > > Wi-Fi Alliance TV White Spaces - specification (built on > 802.11af), > > certification and testing of TVWS devices and the device-to-GDB > interface) > > > > IEEE SCC41 P1900 DYSPAN - dynamic spectrum access, cognitive > radio, > > interference management, coordination of wireless systems, > advanced > > spectrum management, and policy languages for next generation > radio systems > > > > IEEE 802.22 > > > > SE43 - Cognitive radio systems - White spaces (470 - 790 MHz) > > > > Others? > > > > Paul > > > > Paul A. Lambert | Marvell | +1 650 787 9141 > > > >> -----Original Message----- > >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf > Of > >> Basavaraj.Patil@nokia.com > >> Sent: Wednesday, April 13, 2011 12:24 PM > >> To: horvitz@volny.cz; paws@ietf.org > >> Subject: Re: [paws] White space developments in Europe, Asia, > Africa, > >> Latin America > >> > >> Hi Bob, > >> > >> Thanks for the update. I do know about the work being done by SE43 > and > >> CEPT. > >> Regarding your question about: > >> " In any case, this note is to alert you to CEPT's work and ask you > to > >> start thinking about the appropriate relationship between PAWS and > >> SE43, if any. > >> " > >> > >> At the present time, there is an effort to at least establish a > liaison > >> with IEEE. > >> Maybe there could be a similar one with SE43? > >> I believe that a single global standard for the device-DB interface > >> will benefit the technology in general vs having competing variants > for > >> the same purpose. I hope SE43 looks at the PAWS charter and the > people > >> therein contribute to the IETF effort with requirements and other > >> expertise. > >> > >> -Basavaraj > >> > >> -----Original Message----- > >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf > Of > >> ext horvitz@volny.cz > >> Sent: Wednesday, April 13, 2011 1:35 PM > >> To: paws@ietf.org > >> Subject: [paws] White space developments in Europe, Asia, Africa, > Latin > >> America > >> > >> Greetings all, > >> > >> I was sorry to miss the IETF meeting in Prague (since I live there) > >> but I was in another part of the world at the time. Nevertheless I > >> hope to be involved in PAWS from now on (if it's approved today by > >> IETF). I am already involved in CEPT's working group SE43 (Cognitive > >> Access to TV White Spaces), which is meeting 14-15 April in > >> Copenhagen. where I am now. Here is the announcement for that > >> meeting: > >> > >> http://www.ero.dk/594454CD-6109-468D-ACCD- > >> 91BCCCA05710.W5Doc?frames=no&id=19C3C5B7-32BE-4C26-88DC-AAD9E30EAFC5 > >> > >> Late last year, SE43 released its first recommendations on the > >> cognitive use of white spaces in the CEPT member countries > >> (including all of Europe and nearby regions). Here is it: > >> > >> http://www.ero.dk/D9634A59-1F13-40D1-91E9-DAE6468ED66C?frames=no& > >> > >> As you can see they differ from the FCC's approach and there are > >> many important but still unanswered questions. So the group's > >> mandate has been extended and the meeting in Copenhagen will discuss > >> next steps, including device testing and the possibility of > >> expanding the database to support other services in other bands > >> (e.g. RLANs at 5 GHz). > >> > >> Just yesterday, a committee in the European Parliament strongly > >> endorsed the release of white spaces for license exempt use by > >> nonbroadcast services. This must be approved by the Parliament as a > >> whole to become an EU policy, but it's an encouraging sign that may > >> change the tone of the discussion in SE43, which has been dominated > >> by their mandate to protect broadcasting and wireless microphones > >> against intereference. > >> > >> In any case, I saw in the draft charter ("Proposed Working Group" > >> for PAWS) that > >> > >> "The Working Group will set up and maintain appropriate contact and > >> liaison with other relevant standards bodies and groups... [and] may > >> also consider input from regulatory entities..." > >> > >> With that in mind, I sent the draft "use cases" document from Scott > >> Probasco, Tom Derryberry and Basavaraj Patilem to the chairman of > >> SE43, in order to get time during the meeting which starts tomorrow > >> to alert SE43 members to IETF's possible interest in developing a > >> global protocol for communication between WS devices and geolocation > >> databases. SE43 has already explored and outlined the dimensions of > >> this communication (in considerably more depth than PAWS, I might > >> add), so it is appropriate for SE43 to discuss whether to begin > >> cooperating with others (like IETF, the FCC, CITEL and other > >> regional groupings) to seek global harmonisation, or to compete with > >> other proposals and let CEPT member states decide what to require, > >> leave the task to others, or follow some other arrangement. > >> > >> In any case, this note is to alert you to CEPT's work and ask you to > >> start thinking about the appropriate relationship between PAWS and > >> SE43, if any. > >> > >> A few days ago, William Phipps asked about white space developments > >> in Latin America, Africa and Asia. I've been tracking those for the > >> Open Spectrum Alliance. See > >> > >> http://www.openspectrum.eu/drupal6/node/23 > >> > >> Unfortunately, my survey hasn't been updated for a year, and there > >> are lots of new things to report. About 20 countries have expressed > >> interest in opening their white spaces, including China, I just > >> haven't had time to put the new info online. Perhaps after > >> Copenhagen. > >> > >>> BOB< > >> > >> > >> -- > >> Robert Horvitz > >> Stichting Open Spectrum > >> Slavikova 11, 120 00 Prague 2, Czech Republic > >> Gelderlandplein 75 L, 1082 LV Amsterdam, Nederland > >> mailto:bob@openspectrum.info > >> http://www.openspectrum.info/ > >> mob: +420 775024705 > >> tel/fax: +420 222967456 > >> > >> > >> _______________________________________________ > >> paws mailing list > >> paws@ietf.org > >> https://www.ietf.org/mailman/listinfo/paws > >> _______________________________________________ > >> paws mailing list > >> paws@ietf.org > >> https://www.ietf.org/mailman/listinfo/paws > > _______________________________________________ > > paws mailing list > > paws@ietf.org > > https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From horvitz@volny.cz Wed Apr 13 23:57:17 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A98B0E0845 for ; Wed, 13 Apr 2011 23:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.139 X-Spam-Level: X-Spam-Status: No, score=-0.139 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, SARE_HEAD_HDR_XSPAMTST=1.111] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSEePXI0W1MR for ; Wed, 13 Apr 2011 23:57:16 -0700 (PDT) Received: from mxout.mail.volny.cz (mxout.mail.volny.cz [62.44.29.23]) by ietfc.amsl.com (Postfix) with ESMTP id 8E94CE0670 for ; Wed, 13 Apr 2011 23:57:16 -0700 (PDT) Received: from kas30pipe.localhost (localhost.localdomain [127.0.0.1]) by mxout.mail.volny.cz (Postfix) with ESMTP id 816CE1E0B43 for ; Thu, 14 Apr 2011 08:57:16 +0200 (CEST) Received: from webmail1.volny.internal (webmail1.volny.internal [172.20.100.61]) by mxout.mail.volny.cz (Postfix) with ESMTP id 5E4FF1E0CE3 for ; Thu, 14 Apr 2011 08:57:16 +0200 (CEST) Received: from webmail1.volny.internal (localhost.localdomain [127.0.0.1]) by webmail1.volny.internal (8.13.8/8.13.8) with ESMTP id p3E6vExt007414 for ; Thu, 14 Apr 2011 08:57:14 +0200 Received: (from apache@localhost) by webmail1.volny.internal (8.13.8/8.13.8/Submit) id p3E6vDS9007402; Thu, 14 Apr 2011 08:57:13 +0200 Received: from 91-103-38-154.dynamic.thecloud.net (91-103-38-154.dynamic.thecloud.net [91.103.38.154]) by mail1.volny.cz (mail1.volny.cz [62.44.29.41]) with HTTP; Thu, 14 Apr 2011 08:57:13 +0200 (CEST) MIME-Version: 1.0 From: horvitz@volny.cz X-Originating-Account: horvitz/volny.cz To: paws@ietf.org Date: Thu, 14 Apr 2011 08:57:03 +0200 (CEST) Message-ID: <392fc5bd87c35914e2f7fd46a5df6335@mail1.volny.cz> X-Mailer: Volny.cz Webmail2 2.147 X-Originating-Ip: 91.103.38.154 X-Originating-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.204 Safari/534.16 X-Webmail2-Origin: horvitz/volny.cz [91.103.38.154] X-Priority: 3 In-Reply-To: <21E7D9BD69CC7241AAE00F4EA183B71901A417@008-AM1MPN1-023.mgdnok.nokia.com> References: <29dd95d03a4acff43dd16b6a291e0dd1@mail3.volny.cz> <21E7D9BD69CC7241AAE00F4EA183B71901A417@008-AM1MPN1-023.mgdnok.nokia.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-SpamTest-Envelope-From: horvitz@volny.cz X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 20781 [Apr 14 2011] X-SpamTest-Info: {RECEIVED: dynamic ip detected} X-SpamTest-Method: none X-SpamTest-Rate: 5 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0284], KAS30/Release Subject: [paws] SE43 meetings starts in 30 minutes X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 06:57:17 -0000 ----- ORIGINAL MESSAGE ----- From: Basavaraj.Patil@nokia.com > I believe that a single global standard for the > device-DB interface will benefit the technology > in general vs having competing variants for > the same purpose. I agree, Patil, and for that reason, liaison and cooperation are essential - as is speed. There will be a significant "first mover" advantage. The FCC has already authorized 9 firms to begin developing their geo-database services. So a delivery date for PAWS standards of April 2012 may be too late to have any chance for implementation. Beyond that, there's a basic tension between regulator requirements, harmonisation and "optimisation through competition". As Pal Gronsund wrote in his "Spectrum Broker" blog (18 February 2011): "...The FCC and [UK regulator] OFCOM approaches [were] compared in terms of database design, where it was discussed whether it is best that the market designs the database system as proposed by FCC or if the regulator designs the database system such as proposed by OFCOM... the former is beneficial in order to achieve the most optimized database system whereas the latter is beneficial in order to achieve harmonization between countries..." http://palgronsund.com/2011/02/18/key-experiences-from-cogntive-radio-standards-and-market-2010-database-vs-sensing-vs-cpc/ Either way, standardizing the interface and the flow of info between databases and devices will be necessary. The SE43 meeting starts in half an hour, so I'm off. If we're allowed to communicate with the outside world during the meeting, I may update the list as my introduction to PAWS is early on the agenda. >BOB< -- Robert Horvitz Stichting Open Spectrum Slavikova 11, 120 00 Prague 2, Czech Republic Gelderlandplein 75 L, 1082 LV Amsterdam, Nederland mailto:bob@openspectrum.info http://www.openspectrum.info/ mob: +420 775024705 tel/fax: +420 222967456 From paul@marvell.com Thu Apr 14 00:32:55 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E7488E065A for ; Thu, 14 Apr 2011 00:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RrbBdWl4yQ9C for ; Thu, 14 Apr 2011 00:32:54 -0700 (PDT) Received: from na3sys009aog116.obsmtp.com (na3sys009aog116.obsmtp.com [74.125.149.240]) by ietfc.amsl.com (Postfix) with ESMTP id 208C4E06D1 for ; Thu, 14 Apr 2011 00:32:53 -0700 (PDT) Received: from SC-OWA01.marvell.com ([65.219.4.129]) (using TLSv1) by na3sys009aob116.postini.com ([74.125.148.12]) with SMTP ID DSNKTaajBmnyHdTQrFmurBj0uYkpRvwDOv+E@postini.com; Thu, 14 Apr 2011 00:32:54 PDT Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Thu, 14 Apr 2011 00:28:55 -0700 From: Paul Lambert To: Pierre-Jean Muller , "paws@ietf.org" Date: Thu, 14 Apr 2011 00:31:16 -0700 Thread-Topic: [paws] White space developments in Europe, Asia, Africa, Latin America Thread-Index: Acv6MFSTUOsLFn8PRQWqpC9Rej26LQAABJPQAA+wJgAAAV84wA== Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01406A19601@SC-VEXCH2.marvell.com> References: <29dd95d03a4acff43dd16b6a291e0dd1@mail3.volny.cz> <21E7D9BD69CC7241AAE00F4EA183B71901A417@008-AM1MPN1-023.mgdnok.nokia.com> <7BAC95F5A7E67643AAFB2C31BEE662D01406A194D6@SC-VEXCH2.marvell.com> <7BAC95F5A7E67643AAFB2C31BEE662D01406A19510@SC-VEXCH2.marvell.com> <000001cbfa71$29ad1ad0$7d075070$%muller@huawei.com> In-Reply-To: <000001cbfa71$29ad1ad0$7d075070$%muller@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [paws] White space developments in Europe, Asia, Africa, Latin America X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 07:32:56 -0000 Interesting - thanks ... it looks like the ETSI RRS interface JJ-TN is sort= -of similar, but the architecture is carrier versus regulatory centric. The= whole functional model approach they take is very thorough, but I find it = lacking in any interesting model of the information to exchange that is the= topic for this working group. I assume that this and the P1900 work will = eventually produce a policy language that would then be used in a protocol = ... Overall it's missing a few critical aspects needed for regulatory based spe= ctral management. Paul Paul A. Lambert | Marvell | +1 650 787 9141 > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of > Pierre-Jean Muller > Sent: Wednesday, April 13, 2011 11:57 PM > To: paws@ietf.org > Subject: Re: [paws] White space developments in Europe, Asia, Africa, > Latin America >=20 > Dear all, >=20 > ETSI, namely RRS is not only looking at sensing but covers the > cognitive > radio system as a whole including system and protocol aspects for DB, > CPC, > Radio Access Network ... and this for different applications such as > UHF TV > band WS, IMT and GSM bands macro and Public Safety. >=20 > RRS covers SDR as well with a primary focus on mobile device > architecture > and interfaces. >=20 > RRS is also working with SE43 >=20 > Regards, > Pierre-Jean >=20 > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of > Paul > Lambert > Sent: Thursday, April 14, 2011 1:17 AM > To: Rosen, Brian > Cc: paws@ietf.org > Subject: Re: [paws] White space developments in Europe, Asia, Africa, > Latin > America >=20 > Yes - 802.19.1 is not in scope since it's looking at coexistence issues > and > not database enablement. The information exchanged (channels, > frequencies, > power, might be similar). >=20 > I'm also not sure what part of P1900 is related but again it's worth > knowing > they exist. >=20 > There's also an ETSI standard on white spaces - but it's strictly > sensing > based (not relevant). >=20 > Paul >=20 >=20 >=20 > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > > Sent: Wednesday, April 13, 2011 4:13 PM > > To: Paul Lambert > > Cc: Basavaraj.Patil@nokia.com; horvitz@volny.cz; paws@ietf.org > > Subject: Re: [paws] White space developments in Europe, Asia, Africa, > > Latin America > > > > I just heard about 802.19.1 > > > > Not real familiar with their work, but they seem to be working on > > sharing of allowed channels (that is, if the database says channels > 3, > > 5 and 10 are available, but tells 100 devices the same thing, how do > > the devices spread use over those channels). Out of our scope for > now, > > but staying in touch may be useful. > > > > Brian > > > > On Apr 13, 2011, at 6:15 PM, Paul Lambert wrote: > > > > > Seems like there are a bunch of groups for potential liaison .... > > > > > > IEEE 802.11af - 802.11 in the TVWS band > > > > > > Wi-Fi Alliance TV White Spaces - specification (built on > > 802.11af), > > > certification and testing of TVWS devices and the device-to-GDB > > interface) > > > > > > IEEE SCC41 P1900 DYSPAN - dynamic spectrum access, cognitive > > radio, > > > interference management, coordination of wireless systems, > > advanced > > > spectrum management, and policy languages for next generation > > radio systems > > > > > > IEEE 802.22 > > > > > > SE43 - Cognitive radio systems - White spaces (470 - 790 MHz) > > > > > > Others? > > > > > > Paul > > > > > > Paul A. Lambert | Marvell | +1 650 787 9141 > > > > > >> -----Original Message----- > > >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On > Behalf > > Of > > >> Basavaraj.Patil@nokia.com > > >> Sent: Wednesday, April 13, 2011 12:24 PM > > >> To: horvitz@volny.cz; paws@ietf.org > > >> Subject: Re: [paws] White space developments in Europe, Asia, > > Africa, > > >> Latin America > > >> > > >> Hi Bob, > > >> > > >> Thanks for the update. I do know about the work being done by SE43 > > and > > >> CEPT. > > >> Regarding your question about: > > >> " In any case, this note is to alert you to CEPT's work and ask > you > > to > > >> start thinking about the appropriate relationship between PAWS and > > >> SE43, if any. > > >> " > > >> > > >> At the present time, there is an effort to at least establish a > > liaison > > >> with IEEE. > > >> Maybe there could be a similar one with SE43? > > >> I believe that a single global standard for the device-DB > interface > > >> will benefit the technology in general vs having competing > variants > > for > > >> the same purpose. I hope SE43 looks at the PAWS charter and the > > people > > >> therein contribute to the IETF effort with requirements and other > > >> expertise. > > >> > > >> -Basavaraj > > >> > > >> -----Original Message----- > > >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On > Behalf > > Of > > >> ext horvitz@volny.cz > > >> Sent: Wednesday, April 13, 2011 1:35 PM > > >> To: paws@ietf.org > > >> Subject: [paws] White space developments in Europe, Asia, Africa, > > Latin > > >> America > > >> > > >> Greetings all, > > >> > > >> I was sorry to miss the IETF meeting in Prague (since I live > there) > > >> but I was in another part of the world at the time. Nevertheless I > > >> hope to be involved in PAWS from now on (if it's approved today by > > >> IETF). I am already involved in CEPT's working group SE43 > (Cognitive > > >> Access to TV White Spaces), which is meeting 14-15 April in > > >> Copenhagen. where I am now. Here is the announcement for that > > >> meeting: > > >> > > >> http://www.ero.dk/594454CD-6109-468D-ACCD- > > >> 91BCCCA05710.W5Doc?frames=3Dno&id=3D19C3C5B7-32BE-4C26-88DC- > AAD9E30EAFC5 > > >> > > >> Late last year, SE43 released its first recommendations on the > > >> cognitive use of white spaces in the CEPT member countries > > >> (including all of Europe and nearby regions). Here is it: > > >> > > >> http://www.ero.dk/D9634A59-1F13-40D1-91E9-DAE6468ED66C?frames=3Dno& > > >> > > >> As you can see they differ from the FCC's approach and there are > > >> many important but still unanswered questions. So the group's > > >> mandate has been extended and the meeting in Copenhagen will > discuss > > >> next steps, including device testing and the possibility of > > >> expanding the database to support other services in other bands > > >> (e.g. RLANs at 5 GHz). > > >> > > >> Just yesterday, a committee in the European Parliament strongly > > >> endorsed the release of white spaces for license exempt use by > > >> nonbroadcast services. This must be approved by the Parliament as > a > > >> whole to become an EU policy, but it's an encouraging sign that > may > > >> change the tone of the discussion in SE43, which has been > dominated > > >> by their mandate to protect broadcasting and wireless microphones > > >> against intereference. > > >> > > >> In any case, I saw in the draft charter ("Proposed Working Group" > > >> for PAWS) that > > >> > > >> "The Working Group will set up and maintain appropriate contact > and > > >> liaison with other relevant standards bodies and groups... [and] > may > > >> also consider input from regulatory entities..." > > >> > > >> With that in mind, I sent the draft "use cases" document from > Scott > > >> Probasco, Tom Derryberry and Basavaraj Patilem to the chairman of > > >> SE43, in order to get time during the meeting which starts > tomorrow > > >> to alert SE43 members to IETF's possible interest in developing a > > >> global protocol for communication between WS devices and > geolocation > > >> databases. SE43 has already explored and outlined the dimensions > of > > >> this communication (in considerably more depth than PAWS, I might > > >> add), so it is appropriate for SE43 to discuss whether to begin > > >> cooperating with others (like IETF, the FCC, CITEL and other > > >> regional groupings) to seek global harmonisation, or to compete > with > > >> other proposals and let CEPT member states decide what to require, > > >> leave the task to others, or follow some other arrangement. > > >> > > >> In any case, this note is to alert you to CEPT's work and ask you > to > > >> start thinking about the appropriate relationship between PAWS and > > >> SE43, if any. > > >> > > >> A few days ago, William Phipps asked about white space > developments > > >> in Latin America, Africa and Asia. I've been tracking those for > the > > >> Open Spectrum Alliance. See > > >> > > >> http://www.openspectrum.eu/drupal6/node/23 > > >> > > >> Unfortunately, my survey hasn't been updated for a year, and there > > >> are lots of new things to report. About 20 countries have > expressed > > >> interest in opening their white spaces, including China, I just > > >> haven't had time to put the new info online. Perhaps after > > >> Copenhagen. > > >> > > >>> BOB< > > >> > > >> > > >> -- > > >> Robert Horvitz > > >> Stichting Open Spectrum > > >> Slavikova 11, 120 00 Prague 2, Czech Republic > > >> Gelderlandplein 75 L, 1082 LV Amsterdam, Nederland > > >> mailto:bob@openspectrum.info > > >> http://www.openspectrum.info/ > > >> mob: +420 775024705 > > >> tel/fax: +420 222967456 > > >> > > >> > > >> _______________________________________________ > > >> paws mailing list > > >> paws@ietf.org > > >> https://www.ietf.org/mailman/listinfo/paws > > >> _______________________________________________ > > >> paws mailing list > > >> paws@ietf.org > > >> https://www.ietf.org/mailman/listinfo/paws > > > _______________________________________________ > > > paws mailing list > > > paws@ietf.org > > > https://www.ietf.org/mailman/listinfo/paws >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From horvitz@volny.cz Thu Apr 14 03:04:44 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 47251E06C3 for ; Thu, 14 Apr 2011 03:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.139 X-Spam-Level: X-Spam-Status: No, score=-0.139 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, SARE_HEAD_HDR_XSPAMTST=1.111] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ollPgQ23hNF for ; Thu, 14 Apr 2011 03:04:42 -0700 (PDT) Received: from mxout.mail.volny.cz (mxout.mail.volny.cz [62.44.29.23]) by ietfc.amsl.com (Postfix) with ESMTP id 814C1E06AF for ; Thu, 14 Apr 2011 03:04:41 -0700 (PDT) Received: from kas30pipe.localhost (localhost.localdomain [127.0.0.1]) by mxout.mail.volny.cz (Postfix) with ESMTP id 43EF41E1293 for ; Thu, 14 Apr 2011 12:04:40 +0200 (CEST) Received: from webmail3.volny.internal (webmail3.volny.internal [172.20.100.63]) by mxout.mail.volny.cz (Postfix) with ESMTP id 27CB51E124B for ; Thu, 14 Apr 2011 12:04:40 +0200 (CEST) Received: from webmail3.volny.internal (localhost.localdomain [127.0.0.1]) by webmail3.volny.internal (8.13.8/8.13.8) with ESMTP id p3EA4e3E030431 for ; Thu, 14 Apr 2011 12:04:40 +0200 Received: (from apache@localhost) by webmail3.volny.internal (8.13.8/8.13.8/Submit) id p3EA4e2v030427; Thu, 14 Apr 2011 12:04:40 +0200 Received: from cpe.atm2-0-90175.bynxx16.customer.tele.dk (cpe.atm2-0-90175.bynxx16.customer.tele.dk [87.62.2.110]) by mail3.volny.cz (mail3.volny.cz [62.44.29.43]) with HTTP; Thu, 14 Apr 2011 12:04:40 +0200 (CEST) MIME-Version: 1.0 From: horvitz@volny.cz X-Originating-Account: horvitz/volny.cz To: paws@ietf.org Date: Thu, 14 Apr 2011 12:04:39 +0200 (CEST) Message-ID: <6fec10b1017b8ef0ac9275a52ae8bdbf@mail3.volny.cz> X-Mailer: Volny.cz Webmail2 2.147 X-Originating-Ip: 87.62.2.110 X-Originating-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.204 Safari/534.16 X-Webmail2-Origin: horvitz/volny.cz [87.62.2.110] X-Priority: 3 In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D01406A19601@SC-VEXCH2.marvell.com> References: <29dd95d03a4acff43dd16b6a291e0dd1@mail3.volny.cz> <21E7D9BD69CC7241AAE00F4EA183B71901A417@008-AM1MPN1-023.mgdnok.nokia.com> <7BAC95F5A7E67643AAFB2C31BEE662D01406A194D6@SC-VEXCH2.marvell.com> <7BAC95F5A7E67643AAFB2C31BEE662D01406A19510@SC-VEXCH2.marvell.com> <000001cbfa71$29ad1ad0$7d075070$%muller@huawei.com> <7BAC95F5A7E67643AAFB2C31BEE662D01406A19601@SC-VEXCH2.marvell.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-SpamTest-Envelope-From: horvitz@volny.cz X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 20797 [Apr 14 2011] X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0284], KAS30/Release Subject: [paws] Live from SE43 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 10:04:44 -0000 It's the first coffee break at SE43 in Copenhagen, so time for a quick update. After the chairman opened the meeting, I spoke briefly, alerting the 40 attendees to the fact that IETF may constitute PAWS as a working group later today. Questions from the floor indicated (1) widespread ignorance about what IETF is, and (2) equal ignorance about how "internet drafts" work. The general response seemed to be "if its a voluntary standard and won't be released for another year, what difference could it possibly make?" To be frank, most of the people attending this meeting are radio engineers concerned with interference prevention, so their reaction is based on PAWS having no impact on their work. But about an hour later, the SE43 meeting chairman mentioned in passing that responsibility for developing recommendations on communication protocols linking geo-databases to WS devices in Europe now rests with the Electronic Communications Committee's Regulatory Affairs group on White Space Cognitive Radio (ECC RA WS_CR). The current head of ECC RA WS_CR is: Mr Andrew J. Gowans UK Office of Communication (OFCOM) Spectrum Policy Group Head of Exempt Technology Team Riverside House 2a Southwark Bridge Road London SE1 9HA Direct line: +44 20 7981 3191 Mobile: +44 7776 161813 E-mail: Andrew.gowans@ofcom.org.uk At the start of the coffee break, I spoke with two people representing LS Telecom. LS manages frequency databases for about 80 national regulators and are one of the firms authorised by the FCC to offer WS database service in the US. They told the SE43 meeting that the 9 firms have formed an association that will meet next week to sort out inter-database compatibility issues. The group is not yet legally constituted yet, but they have an interim secretary: Neeraj Srivastava (email: n.srivastava@spectrumbridge.com) Their provisional name is the US White Space Database Administrators Group. They are apparently getting very little guidance from the FCC and have not yet focused on compatibility between databases and devices. That will come soon - the LS Telecom reps see that as the bigger and more crucial problem to solve. They were happy to learn that IETF might take the lead on this, as they think it should be a neutral party, not a company or regulator or the ITU. So might I suggest someone who can represent PAWS to contact Mr. Srivastava before next week's meeting, to get a foot in the door and see how much cooperation is possible? >BOB< -- Robert Horvitz Stichting Open Spectrum Slavikova 11, 120 00 Prague 2, Czech Republic Gelderlandplein 75 L, 1082 LV Amsterdam, Nederland mailto:bob@openspectrum.info http://www.openspectrum.info/ mob: +420 775024705 tel/fax: +420 222967456 From Andrew.Gowans@ofcom.org.uk Thu Apr 14 05:44:16 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5A984E06D4 for ; Thu, 14 Apr 2011 05:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6mVs-Vz1Zp7 for ; Thu, 14 Apr 2011 05:44:14 -0700 (PDT) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfc.amsl.com (Postfix) with SMTP id 60817E068E for ; Thu, 14 Apr 2011 05:44:14 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Andrew.Gowans@ofcom.org.uk X-Msg-Ref: server-11.tower-182.messagelabs.com!1302785052!5048129!1 X-StarScan-Version: 6.2.9; banners=.,-,- X-Originating-IP: [194.33.160.63] Received: (qmail 16648 invoked from network); 14 Apr 2011 12:44:12 -0000 Received: from unknown (HELO WOK-INTRA-EDG01.intra.ofcom.local) (194.33.160.63) by server-11.tower-182.messagelabs.com with SMTP; 14 Apr 2011 12:44:12 -0000 Received: from WOK-INTRA-EXC01.intra.ofcom.local (10.130.130.67) by WOK-INTRA-EDG01.intra.ofcom.local (10.130.239.19) with Microsoft SMTP Server (TLS) id 14.1.289.1; Thu, 14 Apr 2011 13:43:31 +0100 Received: from WOK-INTRA-EXC02.intra.ofcom.local ([fe80::550e:933d:224e:6a19]) by WOK-INTRA-EXC01.intra.ofcom.local ([fe80::f0b6:2506:a722:c58b%15]) with mapi id 14.01.0289.001; Thu, 14 Apr 2011 13:44:12 +0100 From: Andrew Gowans To: "'horvitz@volny.cz'" , "'paws@ietf.org'" Thread-Topic: [paws] Live from SE43 Thread-Index: AQHL+otjT6MxxApvU0uWPkiPVld4u5RdTiPY Date: Thu, 14 Apr 2011 12:44:12 +0000 Message-ID: <9983D74B649EED43B27BF353837B20C5046358@WOK-INTRA-EXC02.intra.ofcom.local> In-Reply-To: <6fec10b1017b8ef0ac9275a52ae8bdbf@mail3.volny.cz> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.130.15] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [paws] Live from SE43 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 12:44:16 -0000 Robert, I will be at the se43 meeting either tonight (if there is an evening sessi= on) or tomorrow morning. I would be very interested to have a discussion a= bout a possible co-ordination of effort between ECC and standardisation gr= oups (ETSI, IETF and IEEE). Would particularly be interested in your views= (and others) on the role of the IETF paws work with respect to harmonisati= on going forward. Best Regards Andy Gowans Ofcom UK ----- Original Message ----- From: horvitz@volny.cz [mailto:horvitz@volny.cz] Sent: Thursday, April 14, 2011 11:04 AM To: paws@ietf.org Subject: [paws] Live from SE43 It's the first coffee break at SE43 in Copenhagen, so time for a quick update. After the chairman opened the meeting, I spoke briefly, alerting the 40 attendees to the fact that IETF may constitute PAWS as a working group later today. Questions from the floor indicated (1) widespread ignorance about what IETF is, and (2) equal ignorance about how "internet drafts" work. The general response seemed to be "if its a voluntary standard and won't be released for another year, what difference could it possibly make?" To be frank, most of the people attending this meeting are radio engineers concerned with interference prevention, so their reaction is based on PAWS having no impact on their work. But about an hour later, the SE43 meeting chairman mentioned in passing that responsibility for developing recommendations on communication protocols linking geo-databases to WS devices in Europe now rests with the Electronic Communications Committee's Regulatory Affairs group on White Space Cognitive Radio (ECC RA WS_CR). The current head of ECC RA WS_CR is: Mr Andrew J. Gowans UK Office of Communication (OFCOM) Spectrum Policy Group Head of Exempt Technology Team Riverside House 2a Southwark Bridge Road London SE1 9HA Direct line: +44 20 7981 3191 Mobile: +44 7776 161813 E-mail: Andrew.gowans@ofcom.org.uk At the start of the coffee break, I spoke with two people representing LS Telecom. LS manages frequency databases for about 80 national regulators and are one of the firms authorised by the FCC to offer WS database service in the US. They told the SE43 meeting that the 9 firms have formed an association that will meet next week to sort out inter-database compatibility issues. The group is not yet legally constituted yet, but they have an interim secretary: Neeraj Srivastava (email: n.srivastava@spectrumbridge.com) Their provisional name is the US White Space Database Administrators Group. They are apparently getting very little guidance from the FCC and have not yet focused on compatibility between databases and devices. That will come soon - the LS Telecom reps see that as the bigger and more crucial problem to solve. They were happy to learn that IETF might take the lead on this, as they think it should be a neutral party, not a company or regulator or the ITU. So might I suggest someone who can represent PAWS to contact Mr. Srivastava before next week's meeting, to get a foot in the door and see how=20much cooperation is possible? >BOB< -- Robert Horvitz Stichting Open Spectrum Slavikova 11, 120 00 Prague 2, Czech Republic Gelderlandplein 75 L, 1082 LV Amsterdam, Nederland mailto:bob@openspectrum.info http://www.openspectrum.info/ mob: +420 775024705 tel/fax: +420 222967456 _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws ________________________________ **************************************************************************= **************************************** For more information visit www.ofcom.org.uk This email (and any attachments) is confidential and intended for the use = of the addressee only. If you have received this email in error please notify the originator of t= he message and delete it from your system. This email has been scanned for viruses. However, you open any attachments= at your own risk. Any views expressed in this message are those of the individual sender and= do not represent the views or opinions of Ofcom unless expressly stated o= therwise. **************************************************************************= **************************************** ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email=20 ______________________________________________________________________ From brian.rosen@neustar.biz Thu Apr 14 06:00:51 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 81708E072F for ; Thu, 14 Apr 2011 06:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eV71PSr-NXhP for ; Thu, 14 Apr 2011 06:00:49 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfc.amsl.com (Postfix) with ESMTP id B6D6DE0700 for ; Thu, 14 Apr 2011 06:00:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1302786047; x=1618132547; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=YoKIMUh8MiiEiuYE1GdVF LG/mEozLraD3MxitOs3mbU=; b=f/eSElVZmNXfLlJ+1S+OS9yWo9J7Kea+w0q9R Rq9q1IaN831/S192cZBd9afl8mglqTl/Nk+U5FIqOMlkMrApQ== Received: from ([10.31.13.228]) by stihiron2.va.neustar.com with ESMTP with TLS id 5202732.44092612; Thu, 14 Apr 2011 09:00:46 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Thu, 14 Apr 2011 09:00:46 -0400 From: "Rosen, Brian" To: Andrew Gowans Date: Thu, 14 Apr 2011 09:00:44 -0400 Thread-Topic: [paws] Live from SE43 Thread-Index: Acv6o/fExwLk0xqnRR6+58fxpyMFYw== Message-ID: References: <9983D74B649EED43B27BF353837B20C5046358@WOK-INTRA-EXC02.intra.ofcom.local> In-Reply-To: <9983D74B649EED43B27BF353837B20C5046358@WOK-INTRA-EXC02.intra.ofcom.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 0kUCgnmWnP8MxAsldajGjQ== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Live from SE43 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 13:00:51 -0000 It doesn't seem hard to understand the value of a single database access pr= otocol which is independent of nation, band and layer 2. Even radio engine= ers should get that :) Andy, I would surely think IETF would welcome discussions with ECC on this = work. Brian On Apr 14, 2011, at 8:44 AM, Andrew Gowans wrote: > Robert, >=20 > I will be at the se43 meeting either tonight (if there is an evening sess= ion) or tomorrow morning. I would be very interested to have a discussion a= bout a possible co-ordination of effort between ECC and standardisation gro= ups (ETSI, IETF and IEEE). Would particularly be interested in your views(a= nd others) on the role of the IETF paws work with respect to harmonisation = going forward. >=20 > Best Regards >=20 > Andy Gowans > Ofcom UK >=20 > ----- Original Message ----- > From: horvitz@volny.cz [mailto:horvitz@volny.cz] > Sent: Thursday, April 14, 2011 11:04 AM > To: paws@ietf.org > Subject: [paws] Live from SE43 >=20 > It's the first coffee break at SE43 in Copenhagen, so time for a > quick update. >=20 > After the chairman opened the meeting, I spoke briefly, alerting the > 40 attendees to the fact that IETF may constitute PAWS as a working > group later today. Questions from the floor indicated (1) > widespread ignorance about what IETF is, and (2) equal ignorance > about how "internet drafts" work. The general response seemed to be > "if its a voluntary standard and won't be released for another year, > what difference could it possibly make?" To be frank, most of the > people attending this meeting are radio engineers concerned with > interference prevention, so their reaction is based on PAWS having > no impact on their work. >=20 > But about an hour later, the SE43 meeting chairman mentioned in > passing that responsibility for developing recommendations on > communication protocols linking geo-databases to WS devices in > Europe now rests with the Electronic Communications Committee's > Regulatory Affairs group on White Space Cognitive Radio (ECC RA > WS_CR). The current head of ECC RA WS_CR is: >=20 > Mr Andrew J. Gowans > UK Office of Communication (OFCOM) > Spectrum Policy Group > Head of Exempt Technology Team > Riverside House > 2a Southwark Bridge Road > London SE1 9HA > Direct line: +44 20 7981 3191 > Mobile: +44 7776 161813 > E-mail: Andrew.gowans@ofcom.org.uk >=20 > At the start of the coffee break, I spoke with two people > representing LS Telecom. LS manages frequency databases for about > 80 national regulators and are one of the firms authorised by the > FCC to offer WS database service in the US. They told the SE43 > meeting that the 9 firms have formed an association that will meet > next week to sort out inter-database compatibility issues. The > group is not yet legally constituted yet, but they have an interim > secretary: >=20 > Neeraj Srivastava (email: n.srivastava@spectrumbridge.com) >=20 > Their provisional name is the US White Space Database Administrators > Group. They are apparently getting very little guidance from the > FCC and have not yet focused on compatibility between databases and > devices. That will come soon - the LS Telecom reps see that as the > bigger and more crucial problem to solve. They were happy to learn > that IETF might take the lead on this, as they think it should be a > neutral party, not a company or regulator or the ITU. >=20 > So might I suggest someone who can represent PAWS to contact Mr. > Srivastava before next week's meeting, to get a foot in the door and > see how much cooperation is possible? >=20 >> BOB< >=20 >=20 >=20 > -- > Robert Horvitz > Stichting Open Spectrum > Slavikova 11, 120 00 Prague 2, Czech Republic > Gelderlandplein 75 L, 1082 LV Amsterdam, Nederland > mailto:bob@openspectrum.info > http://www.openspectrum.info/ > mob: +420 775024705 > tel/fax: +420 222967456 >=20 >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws >=20 > ________________________________ >=20 > *************************************************************************= ***************************************** > For more information visit www.ofcom.org.uk >=20 > This email (and any attachments) is confidential and intended for the use= of the addressee only. >=20 > If you have received this email in error please notify the originator of = the message and delete it from your system. >=20 > This email has been scanned for viruses. However, you open any attachment= s at your own risk. >=20 > Any views expressed in this message are those of the individual sender an= d do not represent the views or opinions of Ofcom unless expressly stated o= therwise. > *************************************************************************= ***************************************** >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email=20 > ______________________________________________________________________ > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From brian.rosen@neustar.biz Thu Apr 14 06:04:16 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 16ABAE06D9 for ; Thu, 14 Apr 2011 06:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Tp6v4L0BsHH for ; Thu, 14 Apr 2011 06:04:14 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfc.amsl.com (Postfix) with ESMTP id 7FF97E06A7 for ; Thu, 14 Apr 2011 06:04:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1302786215; x=1618132547; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=RnNmHgPwwgQKT3bFETKNc 3KyV8/qkrOcZAg3x21EAbI=; b=GVRov+jFdTFBn4SSzr/1H/UNrA2IrKvxHz7QN mfMe3iLq1dOUGmB+NWiBiOP1mygjAsUTxgpkgoatYaxsFGBZw== Received: from ([10.31.13.229]) by stihiron2.va.neustar.com with ESMTP with TLS id 5202732.44092726; Thu, 14 Apr 2011 09:03:34 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Thu, 14 Apr 2011 09:03:34 -0400 From: "Rosen, Brian" To: Pierre-Jean Muller Date: Thu, 14 Apr 2011 09:03:31 -0400 Thread-Topic: [paws] White space developments in Europe, Asia, Africa, Latin America Thread-Index: Acv6pFuHuV4lAdzSQ1maWI4+rdYgvQ== Message-ID: <5011E823-E96F-4365-B29A-BD4C911A70C1@neustar.biz> References: <29dd95d03a4acff43dd16b6a291e0dd1@mail3.volny.cz> <21E7D9BD69CC7241AAE00F4EA183B71901A417@008-AM1MPN1-023.mgdnok.nokia.com> <7BAC95F5A7E67643AAFB2C31BEE662D01406A194D6@SC-VEXCH2.marvell.com> <7BAC95F5A7E67643AAFB2C31BEE662D01406A19510@SC-VEXCH2.marvell.com> <000001cbfa71$29ad1ad0$7d075070$%muller@huawei.com> In-Reply-To: <000001cbfa71$29ad1ad0$7d075070$%muller@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: LYIRvPRc+h5+vpKD3tzAzg== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] White space developments in Europe, Asia, Africa, Latin America X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 13:04:16 -0000 Would communication between RRS and IETF be appropriate? Could you see bringing in RRS requirements into paws and taking our work ba= ck? Brian On Apr 14, 2011, at 2:57 AM, Pierre-Jean Muller wrote: > Dear all, >=20 > ETSI, namely RRS is not only looking at sensing but covers the cognitive > radio system as a whole including system and protocol aspects for DB, CPC= , > Radio Access Network ... and this for different applications such as UHF = TV > band WS, IMT and GSM bands macro and Public Safety.=20 >=20 > RRS covers SDR as well with a primary focus on mobile device architecture > and interfaces.=20 >=20 > RRS is also working with SE43 >=20 > Regards, > Pierre-Jean >=20 > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of P= aul > Lambert > Sent: Thursday, April 14, 2011 1:17 AM > To: Rosen, Brian > Cc: paws@ietf.org > Subject: Re: [paws] White space developments in Europe, Asia, Africa, Lat= in > America >=20 > Yes - 802.19.1 is not in scope since it's looking at coexistence issues a= nd > not database enablement. The information exchanged (channels, frequencie= s, > power, might be similar). >=20 > I'm also not sure what part of P1900 is related but again it's worth know= ing > they exist. >=20 > There's also an ETSI standard on white spaces - but it's strictly sensing > based (not relevant).=20 >=20 > Paul >=20 >=20 >=20 >> -----Original Message----- >> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >> Sent: Wednesday, April 13, 2011 4:13 PM >> To: Paul Lambert >> Cc: Basavaraj.Patil@nokia.com; horvitz@volny.cz; paws@ietf.org >> Subject: Re: [paws] White space developments in Europe, Asia, Africa, >> Latin America >>=20 >> I just heard about 802.19.1 >>=20 >> Not real familiar with their work, but they seem to be working on >> sharing of allowed channels (that is, if the database says channels 3, >> 5 and 10 are available, but tells 100 devices the same thing, how do >> the devices spread use over those channels). Out of our scope for now, >> but staying in touch may be useful. >>=20 >> Brian >>=20 >> On Apr 13, 2011, at 6:15 PM, Paul Lambert wrote: >>=20 >>> Seems like there are a bunch of groups for potential liaison .... >>>=20 >>> IEEE 802.11af - 802.11 in the TVWS band >>>=20 >>> Wi-Fi Alliance TV White Spaces - specification (built on >> 802.11af), >>> certification and testing of TVWS devices and the device-to-GDB >> interface) >>>=20 >>> IEEE SCC41 P1900 DYSPAN - dynamic spectrum access, cognitive >> radio, >>> interference management, coordination of wireless systems, >> advanced >>> spectrum management, and policy languages for next generation >> radio systems >>>=20 >>> IEEE 802.22 >>>=20 >>> SE43 - Cognitive radio systems - White spaces (470 - 790 MHz) >>>=20 >>> Others? >>>=20 >>> Paul >>>=20 >>> Paul A. Lambert | Marvell | +1 650 787 9141 >>>=20 >>>> -----Original Message----- >>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf >> Of >>>> Basavaraj.Patil@nokia.com >>>> Sent: Wednesday, April 13, 2011 12:24 PM >>>> To: horvitz@volny.cz; paws@ietf.org >>>> Subject: Re: [paws] White space developments in Europe, Asia, >> Africa, >>>> Latin America >>>>=20 >>>> Hi Bob, >>>>=20 >>>> Thanks for the update. I do know about the work being done by SE43 >> and >>>> CEPT. >>>> Regarding your question about: >>>> " In any case, this note is to alert you to CEPT's work and ask you >> to >>>> start thinking about the appropriate relationship between PAWS and >>>> SE43, if any. >>>> " >>>>=20 >>>> At the present time, there is an effort to at least establish a >> liaison >>>> with IEEE. >>>> Maybe there could be a similar one with SE43? >>>> I believe that a single global standard for the device-DB interface >>>> will benefit the technology in general vs having competing variants >> for >>>> the same purpose. I hope SE43 looks at the PAWS charter and the >> people >>>> therein contribute to the IETF effort with requirements and other >>>> expertise. >>>>=20 >>>> -Basavaraj >>>>=20 >>>> -----Original Message----- >>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf >> Of >>>> ext horvitz@volny.cz >>>> Sent: Wednesday, April 13, 2011 1:35 PM >>>> To: paws@ietf.org >>>> Subject: [paws] White space developments in Europe, Asia, Africa, >> Latin >>>> America >>>>=20 >>>> Greetings all, >>>>=20 >>>> I was sorry to miss the IETF meeting in Prague (since I live there) >>>> but I was in another part of the world at the time. Nevertheless I >>>> hope to be involved in PAWS from now on (if it's approved today by >>>> IETF). I am already involved in CEPT's working group SE43 (Cognitive >>>> Access to TV White Spaces), which is meeting 14-15 April in >>>> Copenhagen. where I am now. Here is the announcement for that >>>> meeting: >>>>=20 >>>> http://www.ero.dk/594454CD-6109-468D-ACCD- >>>> 91BCCCA05710.W5Doc?frames=3Dno&id=3D19C3C5B7-32BE-4C26-88DC-AAD9E30EAF= C5 >>>>=20 >>>> Late last year, SE43 released its first recommendations on the >>>> cognitive use of white spaces in the CEPT member countries >>>> (including all of Europe and nearby regions). Here is it: >>>>=20 >>>> http://www.ero.dk/D9634A59-1F13-40D1-91E9-DAE6468ED66C?frames=3Dno& >>>>=20 >>>> As you can see they differ from the FCC's approach and there are >>>> many important but still unanswered questions. So the group's >>>> mandate has been extended and the meeting in Copenhagen will discuss >>>> next steps, including device testing and the possibility of >>>> expanding the database to support other services in other bands >>>> (e.g. RLANs at 5 GHz). >>>>=20 >>>> Just yesterday, a committee in the European Parliament strongly >>>> endorsed the release of white spaces for license exempt use by >>>> nonbroadcast services. This must be approved by the Parliament as a >>>> whole to become an EU policy, but it's an encouraging sign that may >>>> change the tone of the discussion in SE43, which has been dominated >>>> by their mandate to protect broadcasting and wireless microphones >>>> against intereference. >>>>=20 >>>> In any case, I saw in the draft charter ("Proposed Working Group" >>>> for PAWS) that >>>>=20 >>>> "The Working Group will set up and maintain appropriate contact and >>>> liaison with other relevant standards bodies and groups... [and] may >>>> also consider input from regulatory entities..." >>>>=20 >>>> With that in mind, I sent the draft "use cases" document from Scott >>>> Probasco, Tom Derryberry and Basavaraj Patilem to the chairman of >>>> SE43, in order to get time during the meeting which starts tomorrow >>>> to alert SE43 members to IETF's possible interest in developing a >>>> global protocol for communication between WS devices and geolocation >>>> databases. SE43 has already explored and outlined the dimensions of >>>> this communication (in considerably more depth than PAWS, I might >>>> add), so it is appropriate for SE43 to discuss whether to begin >>>> cooperating with others (like IETF, the FCC, CITEL and other >>>> regional groupings) to seek global harmonisation, or to compete with >>>> other proposals and let CEPT member states decide what to require, >>>> leave the task to others, or follow some other arrangement. >>>>=20 >>>> In any case, this note is to alert you to CEPT's work and ask you to >>>> start thinking about the appropriate relationship between PAWS and >>>> SE43, if any. >>>>=20 >>>> A few days ago, William Phipps asked about white space developments >>>> in Latin America, Africa and Asia. I've been tracking those for the >>>> Open Spectrum Alliance. See >>>>=20 >>>> http://www.openspectrum.eu/drupal6/node/23 >>>>=20 >>>> Unfortunately, my survey hasn't been updated for a year, and there >>>> are lots of new things to report. About 20 countries have expressed >>>> interest in opening their white spaces, including China, I just >>>> haven't had time to put the new info online. Perhaps after >>>> Copenhagen. >>>>=20 >>>>> BOB< >>>>=20 >>>>=20 >>>> -- >>>> Robert Horvitz >>>> Stichting Open Spectrum >>>> Slavikova 11, 120 00 Prague 2, Czech Republic >>>> Gelderlandplein 75 L, 1082 LV Amsterdam, Nederland >>>> mailto:bob@openspectrum.info >>>> http://www.openspectrum.info/ >>>> mob: +420 775024705 >>>> tel/fax: +420 222967456 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From brian.rosen@neustar.biz Thu Apr 14 06:08:45 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 38774E0751 for ; Thu, 14 Apr 2011 06:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6qwzvCmZ19C for ; Thu, 14 Apr 2011 06:08:44 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfc.amsl.com (Postfix) with ESMTP id 1D5ABE073A for ; Thu, 14 Apr 2011 06:08:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1302786522; x=1618132547; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=ZTkMYrNrVV4o8NS6v9n6o +z8Cpsz/OCNKTWr3UB09zs=; b=q5bvLugKvCj4Npg5BRo11Zj9ofT9TtrbfqSK0 0MbatcdWzSNqIPSBxGuLvTSRiWZEntLqPbhWdawZfFZHfBcbg== Received: from ([10.31.13.229]) by stihiron2.va.neustar.com with ESMTP with TLS id 5202732.44092868; Thu, 14 Apr 2011 09:08:41 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Thu, 14 Apr 2011 09:08:40 -0400 From: "Rosen, Brian" To: " " Date: Thu, 14 Apr 2011 09:08:40 -0400 Thread-Topic: [paws] SE43 meetings starts in 30 minutes Thread-Index: Acv6pRMJDF6m2JLHRbuhC/jsHNI50A== Message-ID: <54102B1A-F19C-4627-BE20-FD0A0778384E@neustar.biz> References: <29dd95d03a4acff43dd16b6a291e0dd1@mail3.volny.cz> <21E7D9BD69CC7241AAE00F4EA183B71901A417@008-AM1MPN1-023.mgdnok.nokia.com> <392fc5bd87c35914e2f7fd46a5df6335@mail1.volny.cz> In-Reply-To: <392fc5bd87c35914e2f7fd46a5df6335@mail1.volny.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: W3myhJKWvO/aAMOJOTyHTQ== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] SE43 meetings starts in 30 minutes X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 13:08:45 -0000 There are several of the WS database operators in the U.S. who are followin= g this work closely, including me (Neustar is one of the 9 companies the FC= C authorized). While it's obvious that we will start operations prior to p= aws work completing, at least Neustar anticipates migrating to a paws inter= face, assuming the IETF does charter the work. The value of a single globa= l standard outweighs the cost of migration. Of course, we'll have to maint= ain older interfaces for devices already in service. =20 Brian On Apr 14, 2011, at 2:57 AM, wrote: > ----- ORIGINAL MESSAGE ----- > From: Basavaraj.Patil@nokia.com >=20 >> I believe that a single global standard for the=20 >> device-DB interface will benefit the technology=20 >> in general vs having competing variants for >> the same purpose. >=20 > I agree, Patil, and for that reason, liaison and cooperation are > essential - as is speed. There will be a significant "first mover" > advantage. The FCC has already authorized 9 firms to begin > developing their geo-database services. So a delivery date for PAWS > standards of April 2012 may be too late to have any chance for > implementation. >=20 > Beyond that, there's a basic tension between regulator requirements, > harmonisation and "optimisation through competition". As Pal > Gronsund wrote in his "Spectrum Broker" blog (18 February 2011): >=20 > "...The FCC and [UK regulator] OFCOM approaches [were] compared in > terms of database design, where it was discussed whether it is best > that the market designs the database system as proposed by FCC or if > the regulator designs the database system such as proposed by > OFCOM... the former is beneficial in order to achieve the most > optimized database system whereas the latter is beneficial in order > to achieve harmonization between countries..."=20 >=20 > http://palgronsund.com/2011/02/18/key-experiences-from-cogntive-radio-sta= ndards-and-market-2010-database-vs-sensing-vs-cpc/ >=20 > Either way, standardizing the interface and the flow of info between > databases and devices will be necessary. >=20 > The SE43 meeting starts in half an hour, so I'm off. If we're > allowed to communicate with the outside world during the meeting, I > may update the list as my introduction to PAWS is early on the > agenda.=20 >=20 >> BOB< >=20 > --=20 > Robert Horvitz > Stichting Open Spectrum > Slavikova 11, 120 00 Prague 2, Czech Republic > Gelderlandplein 75 L, 1082 LV Amsterdam, Nederland > mailto:bob@openspectrum.info > http://www.openspectrum.info/ > mob: +420 775024705 > tel/fax: +420 222967456 >=20 >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From pierre-jean.muller@huawei.com Thu Apr 14 07:18:29 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id AA172E088D for ; Thu, 14 Apr 2011 07:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZUaIm6QX8i3o for ; Thu, 14 Apr 2011 07:18:28 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by ietfc.amsl.com (Postfix) with ESMTP id 3606BE0709 for ; Thu, 14 Apr 2011 07:18:28 -0700 (PDT) Received: from huawei.com (usaml01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJN00GN2BQQ0J@usaga01-in.huawei.com> for paws@ietf.org; Thu, 14 Apr 2011 09:18:27 -0500 (CDT) Received: from p79098 ([217.167.116.161]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LJN008N6BQPS7@usaga01-in.huawei.com> for paws@ietf.org; Thu, 14 Apr 2011 09:18:26 -0500 (CDT) Date: Thu, 14 Apr 2011 16:18:32 +0200 From: Pierre-Jean Muller In-reply-to: <5011E823-E96F-4365-B29A-BD4C911A70C1@neustar.biz> To: "'Rosen, Brian'" Message-id: <007b01cbfaae$d6e1b200$84a51600$%muller@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: Acv6pFuHuV4lAdzSQ1maWI4+rdYgvQACMHsA References: <29dd95d03a4acff43dd16b6a291e0dd1@mail3.volny.cz> <21E7D9BD69CC7241AAE00F4EA183B71901A417@008-AM1MPN1-023.mgdnok.nokia.com> <7BAC95F5A7E67643AAFB2C31BEE662D01406A194D6@SC-VEXCH2.marvell.com> <7BAC95F5A7E67643AAFB2C31BEE662D01406A19510@SC-VEXCH2.marvell.com> <000001cbfa71$29ad1ad0$7d075070$%muller@huawei.com> <5011E823-E96F-4365-B29A-BD4C911A70C1@neustar.biz> Cc: paws@ietf.org Subject: Re: [paws] White space developments in Europe, Asia, Africa, Latin America X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 14:18:29 -0000 Hi Brian, Probably not as a formal dependency but nothing should prevent PAWS to consider RRS and CEPT requirements when available - personally if think RRS will be definitively interested by solutions that would be developed by PAWS. Regards, Pierre-Jean -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] Sent: Thursday, April 14, 2011 3:04 PM To: Pierre-Jean Muller Cc: paws@ietf.org Subject: Re: [paws] White space developments in Europe, Asia, Africa, Latin America Would communication between RRS and IETF be appropriate? Could you see bringing in RRS requirements into paws and taking our work back? Brian On Apr 14, 2011, at 2:57 AM, Pierre-Jean Muller wrote: > Dear all, > > ETSI, namely RRS is not only looking at sensing but covers the cognitive > radio system as a whole including system and protocol aspects for DB, CPC, > Radio Access Network ... and this for different applications such as UHF TV > band WS, IMT and GSM bands macro and Public Safety. > > RRS covers SDR as well with a primary focus on mobile device architecture > and interfaces. > > RRS is also working with SE43 > > Regards, > Pierre-Jean > > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Paul > Lambert > Sent: Thursday, April 14, 2011 1:17 AM > To: Rosen, Brian > Cc: paws@ietf.org > Subject: Re: [paws] White space developments in Europe, Asia, Africa, Latin > America > > Yes - 802.19.1 is not in scope since it's looking at coexistence issues and > not database enablement. The information exchanged (channels, frequencies, > power, might be similar). > > I'm also not sure what part of P1900 is related but again it's worth knowing > they exist. > > There's also an ETSI standard on white spaces - but it's strictly sensing > based (not relevant). > > Paul > > > >> -----Original Message----- >> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >> Sent: Wednesday, April 13, 2011 4:13 PM >> To: Paul Lambert >> Cc: Basavaraj.Patil@nokia.com; horvitz@volny.cz; paws@ietf.org >> Subject: Re: [paws] White space developments in Europe, Asia, Africa, >> Latin America >> >> I just heard about 802.19.1 >> >> Not real familiar with their work, but they seem to be working on >> sharing of allowed channels (that is, if the database says channels 3, >> 5 and 10 are available, but tells 100 devices the same thing, how do >> the devices spread use over those channels). Out of our scope for now, >> but staying in touch may be useful. >> >> Brian >> >> On Apr 13, 2011, at 6:15 PM, Paul Lambert wrote: >> >>> Seems like there are a bunch of groups for potential liaison .... >>> >>> IEEE 802.11af - 802.11 in the TVWS band >>> >>> Wi-Fi Alliance TV White Spaces - specification (built on >> 802.11af), >>> certification and testing of TVWS devices and the device-to-GDB >> interface) >>> >>> IEEE SCC41 P1900 DYSPAN - dynamic spectrum access, cognitive >> radio, >>> interference management, coordination of wireless systems, >> advanced >>> spectrum management, and policy languages for next generation >> radio systems >>> >>> IEEE 802.22 >>> >>> SE43 - Cognitive radio systems - White spaces (470 - 790 MHz) >>> >>> Others? >>> >>> Paul >>> >>> Paul A. Lambert | Marvell | +1 650 787 9141 >>> >>>> -----Original Message----- >>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf >> Of >>>> Basavaraj.Patil@nokia.com >>>> Sent: Wednesday, April 13, 2011 12:24 PM >>>> To: horvitz@volny.cz; paws@ietf.org >>>> Subject: Re: [paws] White space developments in Europe, Asia, >> Africa, >>>> Latin America >>>> >>>> Hi Bob, >>>> >>>> Thanks for the update. I do know about the work being done by SE43 >> and >>>> CEPT. >>>> Regarding your question about: >>>> " In any case, this note is to alert you to CEPT's work and ask you >> to >>>> start thinking about the appropriate relationship between PAWS and >>>> SE43, if any. >>>> " >>>> >>>> At the present time, there is an effort to at least establish a >> liaison >>>> with IEEE. >>>> Maybe there could be a similar one with SE43? >>>> I believe that a single global standard for the device-DB interface >>>> will benefit the technology in general vs having competing variants >> for >>>> the same purpose. I hope SE43 looks at the PAWS charter and the >> people >>>> therein contribute to the IETF effort with requirements and other >>>> expertise. >>>> >>>> -Basavaraj >>>> >>>> -----Original Message----- >>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf >> Of >>>> ext horvitz@volny.cz >>>> Sent: Wednesday, April 13, 2011 1:35 PM >>>> To: paws@ietf.org >>>> Subject: [paws] White space developments in Europe, Asia, Africa, >> Latin >>>> America >>>> >>>> Greetings all, >>>> >>>> I was sorry to miss the IETF meeting in Prague (since I live there) >>>> but I was in another part of the world at the time. Nevertheless I >>>> hope to be involved in PAWS from now on (if it's approved today by >>>> IETF). I am already involved in CEPT's working group SE43 (Cognitive >>>> Access to TV White Spaces), which is meeting 14-15 April in >>>> Copenhagen. where I am now. Here is the announcement for that >>>> meeting: >>>> >>>> http://www.ero.dk/594454CD-6109-468D-ACCD- >>>> 91BCCCA05710.W5Doc?frames=no&id=19C3C5B7-32BE-4C26-88DC-AAD9E30EAFC5 >>>> >>>> Late last year, SE43 released its first recommendations on the >>>> cognitive use of white spaces in the CEPT member countries >>>> (including all of Europe and nearby regions). Here is it: >>>> >>>> http://www.ero.dk/D9634A59-1F13-40D1-91E9-DAE6468ED66C?frames=no& >>>> >>>> As you can see they differ from the FCC's approach and there are >>>> many important but still unanswered questions. So the group's >>>> mandate has been extended and the meeting in Copenhagen will discuss >>>> next steps, including device testing and the possibility of >>>> expanding the database to support other services in other bands >>>> (e.g. RLANs at 5 GHz). >>>> >>>> Just yesterday, a committee in the European Parliament strongly >>>> endorsed the release of white spaces for license exempt use by >>>> nonbroadcast services. This must be approved by the Parliament as a >>>> whole to become an EU policy, but it's an encouraging sign that may >>>> change the tone of the discussion in SE43, which has been dominated >>>> by their mandate to protect broadcasting and wireless microphones >>>> against intereference. >>>> >>>> In any case, I saw in the draft charter ("Proposed Working Group" >>>> for PAWS) that >>>> >>>> "The Working Group will set up and maintain appropriate contact and >>>> liaison with other relevant standards bodies and groups... [and] may >>>> also consider input from regulatory entities..." >>>> >>>> With that in mind, I sent the draft "use cases" document from Scott >>>> Probasco, Tom Derryberry and Basavaraj Patilem to the chairman of >>>> SE43, in order to get time during the meeting which starts tomorrow >>>> to alert SE43 members to IETF's possible interest in developing a >>>> global protocol for communication between WS devices and geolocation >>>> databases. SE43 has already explored and outlined the dimensions of >>>> this communication (in considerably more depth than PAWS, I might >>>> add), so it is appropriate for SE43 to discuss whether to begin >>>> cooperating with others (like IETF, the FCC, CITEL and other >>>> regional groupings) to seek global harmonisation, or to compete with >>>> other proposals and let CEPT member states decide what to require, >>>> leave the task to others, or follow some other arrangement. >>>> >>>> In any case, this note is to alert you to CEPT's work and ask you to >>>> start thinking about the appropriate relationship between PAWS and >>>> SE43, if any. >>>> >>>> A few days ago, William Phipps asked about white space developments >>>> in Latin America, Africa and Asia. I've been tracking those for the >>>> Open Spectrum Alliance. See >>>> >>>> http://www.openspectrum.eu/drupal6/node/23 >>>> >>>> Unfortunately, my survey hasn't been updated for a year, and there >>>> are lots of new things to report. About 20 countries have expressed >>>> interest in opening their white spaces, including China, I just >>>> haven't had time to put the new info online. Perhaps after >>>> Copenhagen. >>>> >>>>> BOB< >>>> >>>> >>>> -- >>>> Robert Horvitz >>>> Stichting Open Spectrum >>>> Slavikova 11, 120 00 Prague 2, Czech Republic >>>> Gelderlandplein 75 L, 1082 LV Amsterdam, Nederland >>>> mailto:bob@openspectrum.info >>>> http://www.openspectrum.info/ >>>> mob: +420 775024705 >>>> tel/fax: +420 222967456 >>>> >>>> >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From sergem913@gmail.com Thu Apr 14 08:16:36 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5279EE0756 for ; Thu, 14 Apr 2011 08:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DuMq7COnSrGP for ; Thu, 14 Apr 2011 08:16:34 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfc.amsl.com (Postfix) with ESMTP id 21F7FE06E4 for ; Thu, 14 Apr 2011 08:16:34 -0700 (PDT) Received: by yic13 with SMTP id 13so939853yic.31 for ; Thu, 14 Apr 2011 08:16:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CNDZ2mjjn8McCzxCjsZP1dWNA6dtXQM23EvXGJNYG48=; b=RfdsmuQs/XiA9bFwm9OSSemi6So98g6olXIJ/wIj3PkAFpfpnTENn4PH5Qh4Qv8L+O JpdK3edgyAWRkVvHuwK5Heekd8doxDjUty8Eq2UGVcoor4jRCn0jLPIZtSK1qYJIqhDL w1Jshvur/Om6UFE4/ReNHGM018wAag6wqeNZs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=V+o8zj4T/3zO3XgY5gmmu1upzZOSPUAXyZAcXq6ciWAqtuLbaygFDXIjSqWgr0DcEH Usbum45pNpTUuWet9WqknglaYA1oD7rqK1XdxbUTXmy9um/8PiT1rGuvKse3JrbB6zNL GKPyFFgJsFlEVKoeVUDSQHPIil/qm2RBJY3l8= MIME-Version: 1.0 Received: by 10.151.8.6 with SMTP id l6mr1636801ybi.143.1302794192773; Thu, 14 Apr 2011 08:16:32 -0700 (PDT) Received: by 10.150.158.5 with HTTP; Thu, 14 Apr 2011 08:16:32 -0700 (PDT) In-Reply-To: <4D622A59-4EF8-4E94-A7CD-07B964EC6A1D@kumari.net> References: <4D622A59-4EF8-4E94-A7CD-07B964EC6A1D@kumari.net> Date: Thu, 14 Apr 2011 10:16:32 -0500 Message-ID: From: Serge Manning To: Warren Kumari Content-Type: multipart/alternative; boundary=000e0cd4ccc413627d04a0e26901 Cc: paws@ietf.org Subject: Re: [paws] [Somewhat off-topic] 'FCC head says mergers can't solve spectrum crunch' X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 15:16:36 -0000 --000e0cd4ccc413627d04a0e26901 Content-Type: text/plain; charset=ISO-8859-1 Looks like Europe is specifically calling for more "white space". http://www.laquadrature.net/en/eu-parliament-calls-for-free-wireless-communications On Wed, Apr 13, 2011 at 12:03 PM, Warren Kumari wrote: > Hi all, > > This is somewhat off-topic, but the list seemed low enough volume that folk > wouldn't mind.... > > > http://www.reuters.com/article/2011/04/12/us-fcc-spectrum-merger-idUSTRE73B7D020110412 > > W > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > -- --Serge --000e0cd4ccc413627d04a0e26901 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Looks like Europe is specifically calling for more "white space".=


On Wed, Apr 13, 2011 at 12:03= PM, Warren Kumari <warren@kumari.net> wrote:
Hi all,

This is somewhat off-topic, but the list seemed low enough volume that folk= wouldn't mind....

http://www.reuters.com/article/20= 11/04/12/us-fcc-spectrum-merger-idUSTRE73B7D020110412

W
_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws



--
--Serge

--000e0cd4ccc413627d04a0e26901-- From brian.rosen@neustar.biz Thu Apr 14 09:11:51 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9D9B9E089E for ; Thu, 14 Apr 2011 09:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4DX8lq5eM04 for ; Thu, 14 Apr 2011 09:11:50 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfc.amsl.com (Postfix) with ESMTP id A7C71E06CD for ; Thu, 14 Apr 2011 09:11:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1302797508; x=1618152428; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=OCEkSXVaeyLi4YYEDEUQU 6wBIXZL5qGqcYWK3f9880s=; b=F1zv2F6Lr5JWNdct8wlojmXzwe9ANJCk4ArUf rcudtT+Hl4+CaAWe9RJs2TLSZ8HBCOfrEif3P9qUPzNTy7S9Q== Received: from ([10.31.13.229]) by chihiron1.nc.neustar.com with ESMTP with TLS id 5202942.38052409; Thu, 14 Apr 2011 12:11:47 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Thu, 14 Apr 2011 12:11:46 -0400 From: "Rosen, Brian" To: "paws@ietf.org" Date: Thu, 14 Apr 2011 12:11:45 -0400 Thread-Topic: Suggested language change for the charter Thread-Index: Acv6vqavJvLbNTG8SVaorYEOLaB4mw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: aGuohg63hAtevRPnJX2O6w== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [paws] Suggested language change for the charter X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 16:11:51 -0000 In the review by IESG/IAB some issues came up that are basically interactio= ns between security, privacy and regulatory imperatives. The suggested ch= ange to the security text is: "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 may 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 requirements are expected to be the subject of various regulations in various countries so the WG must balance the need to adhere to regulation with the desire for Internet services to be the same regardless of location." Would everyone be okay with this change? Brian= From budden@nps.edu Thu Apr 14 10:35:30 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 72A1AE082B for ; Thu, 14 Apr 2011 10:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 186a-smqmv65 for ; Thu, 14 Apr 2011 10:35:29 -0700 (PDT) Received: from diamond.nps.edu (diamond.nps.edu [205.155.65.226]) by ietfc.amsl.com (Postfix) with ESMTP id 7B769E080D for ; Thu, 14 Apr 2011 10:35:29 -0700 (PDT) Received: from virginia.nps.edu ([205.155.65.15]) by diamond.nps.edu with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Apr 2011 10:35:28 -0700 Received: from [172.20.58.67] ([172.20.58.67]) by virginia.nps.edu with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Apr 2011 10:35:27 -0700 From: Rex Buddenberg To: paws@ietf.org In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Thu, 14 Apr 2011 10:35:25 -0700 Message-ID: <1302802525.2114.1692.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.32.0 (2.32.0-2.fc14) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Apr 2011 17:35:27.0712 (UTC) FILETIME=[5802FE00:01CBFACA] Subject: Re: [paws] Suggested language change for the charter X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 17:35:30 -0000 Brian, I think you have the priorities reversed. Authenticity of the data is always and universal. There will be no cases where authenticity is not a requirement in PAWS. Confidentiality is a requirement but it's not universal. On Thu, 2011-04-14 at 12:11 -0400, Rosen, Brian wrote: > In the review by IESG/IAB some issues came up that are basically interactions between security, privacy and regulatory imperatives. The suggested change to the security text is: > "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 may 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 requirements are expected to be the subject of > various regulations in various countries so the WG must balance > the need to adhere to regulation with the desire for Internet > services to be the same regardless of location." > > Would everyone be okay with this change? > > Brian > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From brian.rosen@neustar.biz Thu Apr 14 10:46:56 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3EADAE06CD for ; Thu, 14 Apr 2011 10:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVFiQpUp6ym3 for ; Thu, 14 Apr 2011 10:46:55 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfc.amsl.com (Postfix) with ESMTP id 50E65E0690 for ; Thu, 14 Apr 2011 10:46:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1302803212; x=1618163173; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=H4dSAL/M3zF4+uRqxERyw tkZhJ+OgzdRGxN3pRtXcwk=; b=IkguGx8vOSj+xOranRYD3aiZemvehWCSWz97B LuYOuTaZ02WMEAG0XeRgMcrQ3E0UOwozNfEWbqW+fDCGGANHA== Received: from ([10.31.13.228]) by stihiron2.va.neustar.com with ESMTP with TLS id 5202732.44103278; Thu, 14 Apr 2011 13:46:04 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Thu, 14 Apr 2011 13:46:04 -0400 From: "Rosen, Brian" To: Rex Buddenberg Date: Thu, 14 Apr 2011 13:46:02 -0400 Thread-Topic: [paws] Suggested language change for the charter Thread-Index: Acv6y9LTY8cLzIFBTuuOR+IPtq1rWg== Message-ID: <5A37B755-1B2B-4BC6-8F12-BD20CAFBB263@neustar.biz> References: <1302802525.2114.1692.camel@localhost.localdomain> In-Reply-To: <1302802525.2114.1692.camel@localhost.localdomain> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: YDj7mTeSoTmOZPqC7Dk72w== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Suggested language change for the charter X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 17:46:56 -0000 So you are worried that by lumping all of the mechanisms under "may be requ= ired" we short shrift some mechanisms that we believe will always be requir= ed? Could you suggest a wording change that achieves that? The text suggestion arises because lots of privacy sensitive data is requir= ed to be provided by some (i.e. U.S.) regulators, but may not be required b= y all. So some mechanisms may be optional to deploy. Brian On Apr 14, 2011, at 1:35 PM, Rex Buddenberg wrote: > Brian, >=20 > I think you have the priorities reversed. >=20 > Authenticity of the data is always and universal. There will be no > cases where authenticity is not a requirement in PAWS. =20 >=20 > Confidentiality is a requirement but it's not universal. >=20 >=20 >=20 > On Thu, 2011-04-14 at 12:11 -0400, Rosen, Brian wrote: >> In the review by IESG/IAB some issues came up that are basically interac= tions between security, privacy and regulatory imperatives. The suggested= change to the security text is: >> "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 may 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 requirements are expected to be the subject of >> various regulations in various countries so the WG must balance >> the need to adhere to regulation with the desire for Internet >> services to be the same regardless of location." >>=20 >> Would everyone be okay with this change? >>=20 >> Brian >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >=20 >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From Basavaraj.Patil@nokia.com Thu Apr 14 10:51:45 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DB08BE0690 for ; Thu, 14 Apr 2011 10:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.999 X-Spam-Level: X-Spam-Status: No, score=-103.999 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRqk5UfU3mkY for ; Thu, 14 Apr 2011 10:51:44 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfc.amsl.com (Postfix) with ESMTP id C04ACE065F for ; Thu, 14 Apr 2011 10:51:44 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p3EHoxhK023509; Thu, 14 Apr 2011 20:51:42 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Apr 2011 20:51:38 +0300 Received: from 008-AM1MMR1-005.mgdnok.nokia.com (65.54.30.60) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 14 Apr 2011 19:51:38 +0200 Received: from 008-AM1MPN1-023.mgdnok.nokia.com ([169.254.3.94]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0270.002; Thu, 14 Apr 2011 19:51:32 +0200 From: To: , Thread-Topic: [paws] Suggested language change for the charter Thread-Index: Acv6vqavJvLbNTG8SVaorYEOLaB4m///poAA Date: Thu, 14 Apr 2011 17:51:31 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [172.19.59.39] Content-Type: text/plain; charset="us-ascii" Content-ID: <619CB1BF2EFF2C4D8EC920792E3996B6@nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 14 Apr 2011 17:51:38.0147 (UTC) FILETIME=[9A6F9F30:01CBFACC] X-Nokia-AV: Clean Subject: Re: [paws] Suggested language change for the charter X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 17:51:46 -0000 Just one suggested change: S/Such requirements are expected to be the subject of various regulations in various countries so the WG must balance the need to adhere to regulation with the desire for Internet services to be the same regardless of location./Such security requirements may be in the scope of regulations which could 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. Otherwise looks fine. -Raj On 4/14/11 11:11 AM, "ext Rosen, Brian" wrote: >In the review by IESG/IAB some issues came up that are basically >interactions between security, privacy and regulatory imperatives. The >suggested change to the security text is: > "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 may 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 requirements are expected to be the subject of > various regulations in various countries so the WG must balance > the need to adhere to regulation with the desire for Internet > services to be the same regardless of location." > >Would everyone be okay with this change? > >Brian >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From dromasca@avaya.com Thu Apr 14 10:55:04 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D995AE0736 for ; Thu, 14 Apr 2011 10:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.043 X-Spam-Level: X-Spam-Status: No, score=-103.043 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhWystDGPNJ4 for ; Thu, 14 Apr 2011 10:55:03 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfc.amsl.com (Postfix) with ESMTP id DB63BE065F for ; Thu, 14 Apr 2011 10:55:02 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYAAFMtcU3GmAcF/2dsb2JhbACYKo47dKR5ApkWgn+CYgSQDA X-IronPort-AV: E=Sophos;i="4.64,212,1301889600"; d="scan'208";a="241772663" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 14 Apr 2011 13:55:01 -0400 X-IronPort-AV: E=Sophos;i="4.64,212,1301889600"; d="scan'208";a="608909897" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 14 Apr 2011 13:55:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Apr 2011 19:54:58 +0200 Message-ID: In-Reply-To: <5A37B755-1B2B-4BC6-8F12-BD20CAFBB263@neustar.biz> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [paws] Suggested language change for the charter Thread-Index: Acv6y9LTY8cLzIFBTuuOR+IPtq1rWgAAM4/A References: <1302802525.2114.1692.camel@localhost.localdomain> <5A37B755-1B2B-4BC6-8F12-BD20CAFBB263@neustar.biz> From: "Romascanu, Dan (Dan)" To: "Rosen, Brian" , "Rex Buddenberg" Cc: paws@ietf.org Subject: Re: [paws] Suggested language change for the charter X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 17:55:05 -0000 Hi,=20 In the IESG telechat today we decided to leave the text as it is for the time being and send the current charter text to external IETF review. The discussion can continue as part of the external review.=20 Regards, Dan=20 =20 > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On=20 > Behalf Of Rosen, Brian > Sent: Thursday, April 14, 2011 8:46 PM > To: Rex Buddenberg > Cc: paws@ietf.org > Subject: Re: [paws] Suggested language change for the charter >=20 > So you are worried that by lumping all of the mechanisms=20 > under "may be required" we short shrift some mechanisms that=20 > we believe will always be required? >=20 > Could you suggest a wording change that achieves that? >=20 > The text suggestion arises because lots of privacy sensitive=20 > data is required to be provided by some (i.e. U.S.)=20 > regulators, but may not be required by all. So some=20 > mechanisms may be optional to deploy. >=20 > Brian >=20 >=20 > On Apr 14, 2011, at 1:35 PM, Rex Buddenberg wrote: >=20 > > Brian, > >=20 > > I think you have the priorities reversed. > >=20 > > Authenticity of the data is always and universal. There will be no=20 > > cases where authenticity is not a requirement in PAWS. > >=20 > > Confidentiality is a requirement but it's not universal. > >=20 > >=20 > >=20 > > On Thu, 2011-04-14 at 12:11 -0400, Rosen, Brian wrote: > >> In the review by IESG/IAB some issues came up that are=20 > basically interactions between security, privacy and=20 > regulatory imperatives. The suggested change to the=20 > security text is: > >> "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 may be required to be used to prevent device identity > >> spoofing, modification of device requests, modification=20 > of channel > >> enablement information and impersonation of registered database > >> services. Such requirements are expected to be the subject of > >> various regulations in various countries so the WG must balance > >> the need to adhere to regulation with the desire for Internet > >> services to be the same regardless of location." > >>=20 > >> Would everyone be okay with this change? > >>=20 > >> Brian > >> _______________________________________________ > >> paws mailing list > >> paws@ietf.org > >> https://www.ietf.org/mailman/listinfo/paws > >=20 > >=20 > > _______________________________________________ > > paws mailing list > > paws@ietf.org > > https://www.ietf.org/mailman/listinfo/paws >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws >=20 From budden@nps.edu Thu Apr 14 11:04:49 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 949B1E079E for ; Thu, 14 Apr 2011 11:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kL59zR3nGINu for ; Thu, 14 Apr 2011 11:04:48 -0700 (PDT) Received: from diamond.nps.edu (diamond.nps.edu [205.155.65.226]) by ietfc.amsl.com (Postfix) with ESMTP id A0C87E0792 for ; Thu, 14 Apr 2011 11:04:48 -0700 (PDT) Received: from virginia.nps.edu ([205.155.65.15]) by diamond.nps.edu with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Apr 2011 11:04:48 -0700 Received: from [172.20.58.67] ([172.20.58.67]) by virginia.nps.edu with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Apr 2011 11:04:36 -0700 From: Rex Buddenberg To: "Rosen, Brian" In-Reply-To: <5A37B755-1B2B-4BC6-8F12-BD20CAFBB263@neustar.biz> References: <1302802525.2114.1692.camel@localhost.localdomain> <5A37B755-1B2B-4BC6-8F12-BD20CAFBB263@neustar.biz> Content-Type: text/plain; charset="UTF-8" Date: Thu, 14 Apr 2011 11:04:34 -0700 Message-ID: <1302804274.2114.1699.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.32.0 (2.32.0-2.fc14) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Apr 2011 18:04:36.0284 (UTC) FILETIME=[6A3DE7C0:01CBFACE] Cc: "paws@ietf.org" Subject: Re: [paws] Suggested language change for the charter X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 18:04:49 -0000 On Thu, 2011-04-14 at 13:46 -0400, Rosen, Brian wrote: > So you are worried that by lumping all of the mechanisms under "may be > required" we short shrift some mechanisms that we believe will always > be required? Brian, may be an allergic reaction on my part -- too many times I've seen attention to confidentiality but not authenticity. I hope this audience all knows that the way public key works, confidentiality does not confer authenticity. But the PKI necessary to hold up digital signature also holds up confidentiality. > > Could you suggest a wording change that achieves that? I'll try a couple notes below > > The text suggestion arises because lots of privacy sensitive data is > required to be provided by some (i.e. U.S.) regulators, but may not be > required by all. For the confidentiality subject, I agree with you. > So some mechanisms may be optional to deploy. Again, for confidentiality, agree. But show me a situation where authenticity is not a valid requirement? > > Brian > > > On Apr 14, 2011, at 1:35 PM, Rex Buddenberg wrote: > > > Brian, > > > > I think you have the priorities reversed. > > > > Authenticity of the data is always and universal. There will be no > > cases where authenticity is not a requirement in PAWS. > > > > Confidentiality is a requirement but it's not universal. > > > > > > > > On Thu, 2011-04-14 at 12:11 -0400, Rosen, Brian wrote: > >> In the review by IESG/IAB some issues came up that are basically interactions between security, privacy and regulatory imperatives. The suggested change to the security text is: > >> "The protocol must protect both the channel enablement process and > >> the privacy of users, and prevent unauthorized disclosure of a > >> user's location. s/ The protocol must authenticate data between users and the channel enablement process to preclude bogus or spoofed data. > In some circumstances the protocol must protect privacy of uses (one aspect of which would be unauthorized disclosure of that user's location). > robust security > >> mechanisms may 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. This is all authenticity so can be used to modify that part. > Such requirements are expected to be the subject of > >> various regulations in various countries so the WG must balance > >> the need to adhere to regulation with the desire for Internet > >> services to be the same regardless of location." > >> > >> Would everyone be okay with this change? > >> > >> Brian > >> _______________________________________________ > >> paws mailing list > >> paws@ietf.org > >> https://www.ietf.org/mailman/listinfo/paws > > > > > > _______________________________________________ > > paws mailing list > > paws@ietf.org > > https://www.ietf.org/mailman/listinfo/paws > From paul@marvell.com Thu Apr 14 16:56:58 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 00460E06EA for ; Thu, 14 Apr 2011 16:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCQkqS7N6JDg for ; Thu, 14 Apr 2011 16:56:57 -0700 (PDT) Received: from na3sys009aog110.obsmtp.com (na3sys009aog110.obsmtp.com [74.125.149.203]) by ietfc.amsl.com (Postfix) with ESMTP id C9CC2E06D0 for ; Thu, 14 Apr 2011 16:56:53 -0700 (PDT) Received: from sc-owa02.marvell.com ([65.219.4.130]) (using TLSv1) by na3sys009aob110.postini.com ([74.125.148.12]) with SMTP ID DSNKTaeJxJNE1/SV2U3/g+2e3qCrmpt6FfMK@postini.com; Thu, 14 Apr 2011 16:56:56 PDT Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa02.marvell.com ([10.93.76.22]) with mapi; Thu, 14 Apr 2011 16:44:55 -0700 From: Paul Lambert To: "Rosen, Brian" , "paws@ietf.org" Date: Thu, 14 Apr 2011 16:44:53 -0700 Thread-Topic: Suggested language change for the charter Thread-Index: Acv6vqavJvLbNTG8SVaorYEOLaB4mwAPpz7g Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01406AC4ED2@SC-VEXCH2.marvell.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [paws] Suggested language change for the charter X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 23:56:58 -0000 Minor comments: 1) "... In some circumstances robust security mechanisms may be.." =20 Is redundantly wishy-washy. I'd suggest "will" instead of "may" 2) "... various regulations in various countries ..." Reads poorly - suggest: " The security requirements are the subject of regulations that vary between countries so the WG must balance the need to adhere to regulation with the desire for Internet services to be the same regardless of location." =20 Paul > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of > Rosen, Brian > Sent: Thursday, April 14, 2011 9:12 AM > To: paws@ietf.org > Subject: [paws] Suggested language change for the charter >=20 > In the review by IESG/IAB some issues came up that are basically > interactions between security, privacy and regulatory imperatives. > The suggested change to the security text is: > "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 may 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 requirements are expected to be the subject of > various regulations in various countries so the WG must balance > the need to adhere to regulation with the desire for Internet > services to be the same regardless of location." >=20 > Would everyone be okay with this change? >=20 > Brian > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From wwwrun@ietfc.amsl.com Tue Apr 19 09:56:34 2011 Return-Path: X-Original-To: paws@ietf.org Delivered-To: paws@ietfc.amsl.com Received: by ietfc.amsl.com (Postfix, from userid 30) id CD24CE07CF; Tue, 19 Apr 2011 09:56:34 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110419165634.CD24CE07CF@ietfc.amsl.com> Date: Tue, 19 Apr 2011 09:56:34 -0700 (PDT) Cc: paws@ietf.org Subject: [paws] WG Review: Protocol to Access White Space database (paws) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: iesg@ietf.org List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 16:56:35 -0000 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 (iesg@ietf.org) 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: paws@ietf.org 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 jmh@joelhalpern.com Tue Apr 19 10:50:16 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 70F9CE0702; Tue, 19 Apr 2011 10:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.481 X-Spam-Level: X-Spam-Status: No, score=-102.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LbFDumY++q16; Tue, 19 Apr 2011 10:50:15 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by ietfc.amsl.com (Postfix) with ESMTP id 1FC73E0685; Tue, 19 Apr 2011 10:50:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 71D6143002C; Tue, 19 Apr 2011 10:50:14 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-50-206.clppva.btas.verizon.net [71.161.50.206]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 724A14300E5; Tue, 19 Apr 2011 10:50:12 -0700 (PDT) Message-ID: <4DADCB52.1020309@joelhalpern.com> Date: Tue, 19 Apr 2011 13:50:10 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: iesg@ietf.org References: <20110419165634.CD24CE07CF@ietfc.amsl.com> In-Reply-To: <20110419165634.CD24CE07CF@ietfc.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: paws@ietf.org, IETF discussion list Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 17:50:16 -0000 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 (iesg@ietf.org) 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: paws@ietf.org > 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 > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > From paul@marvell.com Tue Apr 19 12:54:14 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 90A8FE07AD; Tue, 19 Apr 2011 12:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id on8-tvFxv1Fj; Tue, 19 Apr 2011 12:54:13 -0700 (PDT) Received: from na3sys009aog105.obsmtp.com (na3sys009aog105.obsmtp.com [74.125.149.75]) by ietfc.amsl.com (Postfix) with ESMTP id 7A68CE079D; Tue, 19 Apr 2011 12:54:11 -0700 (PDT) Received: from SC-OWA01.marvell.com ([65.219.4.129]) (using TLSv1) by na3sys009aob105.postini.com ([74.125.148.12]) with SMTP ID DSNKTa3oSvpUfpiTwaslA3MP0Ix3UND2oA3z@postini.com; Tue, 19 Apr 2011 12:54:12 PDT Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Tue, 19 Apr 2011 12:47:43 -0700 From: Paul Lambert To: "Joel M. Halpern" , "iesg@ietf.org" , IETF discussion list , "paws@ietf.org" Date: Tue, 19 Apr 2011 12:47:41 -0700 Thread-Topic: [paws] WG Review: Protocol to Access White Space database (paws) Thread-Index: Acv+uedonCqyHha9TAGR+HDpqgU76wAECkWg Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01406AC564E@SC-VEXCH2.marvell.com> References: <20110419165634.CD24CE07CF@ietfc.amsl.com> <4DADCB52.1020309@joelhalpern.com> In-Reply-To: <4DADCB52.1020309@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 19:54:15 -0000 How does the area that the group is assigned impact the choices of technolo= gy? 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 infrastr= uctural component that needs careful design. There are good reasons that r= outing protocols don't use XML. Applications now days tend to go for the simple, quick to make a web applic= ation solutions using XML or the like ... My concern is that "Applications= " imply that efficiency does not matter. Paul > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of > Joel M. Halpern > Sent: Tuesday, April 19, 2011 10:50 AM > To: iesg@ietf.org > Cc: paws@ietf.org; IETF discussion list > Subject: Re: [paws] WG Review: Protocol to Access White Space database > (paws) >=20 > 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. >=20 > Yours, > Joel M. Halpern >=20 > 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 (iesg@ietf.org) 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: paws@ietf.org > > 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 > > paws@ietf.org > > https://www.ietf.org/mailman/listinfo/paws > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From Basavaraj.Patil@nokia.com Tue Apr 19 12:55:49 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6EF51E07C0; Tue, 19 Apr 2011 12:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.266 X-Spam-Level: X-Spam-Status: No, score=-103.266 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5t0YwBx7voV; Tue, 19 Apr 2011 12:55:48 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfc.amsl.com (Postfix) with ESMTP id 447BDE07B7; Tue, 19 Apr 2011 12:55:47 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p3JJtZce023690; Tue, 19 Apr 2011 22:55:46 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Apr 2011 22:55:31 +0300 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 19 Apr 2011 21:55:30 +0200 Received: from 008-AM1MPN1-025.mgdnok.nokia.com ([169.254.5.134]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0289.008; Tue, 19 Apr 2011 21:55:29 +0200 From: To: , Thread-Topic: [paws] WG Review: Protocol to Access White Space database (paws) Thread-Index: AQHL/rLAHraUh0DINEKp8P50E+1g05RlJLaA Date: Tue, 19 Apr 2011 19:55:29 +0000 Message-ID: In-Reply-To: <20110419165634.CD24CE07CF@ietfc.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [172.19.59.137] Content-Type: text/plain; charset="us-ascii" Content-ID: <67702680AA76F645932352623A3B2717@nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 19 Apr 2011 19:55:31.0074 (UTC) FILETIME=[BCDF0620:01CBFECB] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 19:55:49 -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 On 4/19/11 11:56 AM, "ext 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 (iesg@ietf.org) by Tuesday, April 26, 2011. > =20 > >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: paws@ietf.org >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 >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From stpeter@stpeter.im Tue Apr 19 13:08:36 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 489FFE081C; Tue, 19 Apr 2011 13:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HE8oBbv6LOnm; Tue, 19 Apr 2011 13:08:35 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by ietfc.amsl.com (Postfix) with ESMTP id 13521E0811; Tue, 19 Apr 2011 13:08:35 -0700 (PDT) Received: from dhcp-64-101-72-185.cisco.com (dhcp-64-101-72-185.cisco.com [64.101.72.185]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7403F40D6A; Tue, 19 Apr 2011 14:12:08 -0600 (MDT) Message-ID: <4DADEBC0.1060200@stpeter.im> Date: Tue, 19 Apr 2011 14:08:32 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Paul Lambert References: <20110419165634.CD24CE07CF@ietfc.amsl.com> <4DADCB52.1020309@joelhalpern.com> <7BAC95F5A7E67643AAFB2C31BEE662D01406AC564E@SC-VEXCH2.marvell.com> In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D01406AC564E@SC-VEXCH2.marvell.com> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020801000302000909070604" Cc: "paws@ietf.org" , "iesg@ietf.org" , IETF discussion list Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 20:08:36 -0000 This is a cryptographically signed message in MIME format. --------------ms020801000302000909070604 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 4/19/11 1:47 PM, Paul Lambert wrote: >=20 >=20 > How does the area that the group is assigned impact the choices of > technology? >=20 > 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. >=20 > 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 --=20 Peter Saint-Andre https://stpeter.im/ --------------ms020801000302000909070604 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDQx OTIwMDgzMlowIwYJKoZIhvcNAQkEMRYEFDZeFQ9KNyBGK3rvYRBiioj5si7cMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQA3VODZyDTTlqyP/UmGRJKW5g9JiaZ0Zt7nWnS6zuQhsgeHRyHN6DioD2NO xXQmc2IXQ2mgyRiIqwILVMxqBUu/ARm1bBTICUGQm2CD5de9lD9FBHZIv96REPfXIfoLt2xp M2RISL7K650493SeTzvvdKFtpPc8DmlrQG0jrZPuuNM8lhfnolASQ3HPMZ0KnygF81efrNdq wovTLLHfu3MzO7iGSYlrTK4uww1i6GjyEsr/1CPi9WAlpnn5R4ZzKAo7PYhiGf250MRzKsLc 03JspxrtmVPb5RVkqDZJInLd4xVOCwRkwuIPhcEsvDx8s5qSV78ysw22XSFqVr2GQx1MAAAA AAAA --------------ms020801000302000909070604-- From budden@nps.edu Tue Apr 19 14:21:48 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BCCB1E086D; Tue, 19 Apr 2011 14:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08+O1NcnVvdO; Tue, 19 Apr 2011 14:21:47 -0700 (PDT) Received: from diamond.nps.edu (diamond.nps.edu [205.155.65.226]) by ietfc.amsl.com (Postfix) with ESMTP id 694C7E089C; Tue, 19 Apr 2011 14:21:46 -0700 (PDT) Received: from virginia.nps.edu ([205.155.65.26]) by diamond.nps.edu with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Apr 2011 14:21:44 -0700 Received: from SKYTRAIN.ern.nps.edu ([172.20.24.112]) by virginia.nps.edu with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Apr 2011 14:21:44 -0700 Received: from GULFSTREAM.ern.nps.edu (172.20.24.113) by skytrain.ern.nps.edu (172.20.24.112) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 19 Apr 2011 14:21:43 -0700 Received: from [172.20.58.67] (172.20.58.67) by smtp.nps.edu (172.20.24.113) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 19 Apr 2011 14:21:43 -0700 From: Rex Buddenberg To: Paul Lambert In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D01406AC564E@SC-VEXCH2.marvell.com> References: <20110419165634.CD24CE07CF@ietfc.amsl.com> <4DADCB52.1020309@joelhalpern.com> <7BAC95F5A7E67643AAFB2C31BEE662D01406AC564E@SC-VEXCH2.marvell.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 19 Apr 2011 14:21:39 -0700 Message-ID: <1303248099.2209.105.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Apr 2011 21:21:44.0319 (UTC) FILETIME=[C85D90F0:01CBFED7] Cc: "paws@ietf.org" , "iesg@ietf.org" , IETF discussion list Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 21:21:48 -0000 On Tue, 2011-04-19 at 12:47 -0700, 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. While the DNS analogy works, I was thinking more a parallel -- or extension -- of SNMP. Still remain within 'applications', Joel? > > 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: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of > > Joel M. Halpern > > Sent: Tuesday, April 19, 2011 10:50 AM > > To: iesg@ietf.org > > Cc: paws@ietf.org; IETF discussion list > > Subject: Re: [paws] WG Review: Protocol to Access White Space database > > (paws) > > > > 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 (iesg@ietf.org) 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: paws@ietf.org > > > 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 > > > paws@ietf.org > > > https://www.ietf.org/mailman/listinfo/paws > > > > > _______________________________________________ > > paws mailing list > > paws@ietf.org > > https://www.ietf.org/mailman/listinfo/paws > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From richard@shockey.us Tue Apr 19 14:31:09 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 34EC8E07D2 for ; Tue, 19 Apr 2011 14:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGxiF5HJSXDD for ; Tue, 19 Apr 2011 14:31:08 -0700 (PDT) Received: from cpoproxy2-pub.bluehost.com (cpoproxy2-pub.bluehost.com [67.222.39.38]) by ietfc.amsl.com (Postfix) with SMTP id EE306E07B4 for ; Tue, 19 Apr 2011 14:31:07 -0700 (PDT) Received: (qmail 6403 invoked by uid 0); 19 Apr 2011 21:31:07 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by cpoproxy2.bluehost.com with SMTP; 19 Apr 2011 21:31:07 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=K3RYEtO/JLwDTiEVhow2uKcePyMr7R1nBCS912DGu8e5f5ntyjjONbQc/KI4BDg8ffeLnt1Y7xq+ZwM8pkKcF/3lmI5dRjt29FiKnpsJmGh+Plgcdh8qe1FHdZ2VyBto; Received: from pool-71-178-24-118.washdc.fios.verizon.net ([71.178.24.118] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1QCIVm-000222-TS; Tue, 19 Apr 2011 15:31:07 -0600 From: "Richard Shockey" To: "'Peter Saint-Andre'" , "'Paul Lambert'" References: <20110419165634.CD24CE07CF@ietfc.amsl.com> <4DADCB52.1020309@joelhalpern.com> <7BAC95F5A7E67643AAFB2C31BEE662D01406AC564E@SC-VEXCH2.marvell.com> <4DADEBC0.1060200@stpeter.im> In-Reply-To: <4DADEBC0.1060200@stpeter.im> Date: Tue, 19 Apr 2011 17:31:06 -0400 Message-ID: <004601cbfed9$18879c50$4996d4f0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acv+zZTlgXow9KXPTZKwzEPFvgerjAACbrHw Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.178.24.118 authed with richard@shockey.us} Cc: paws@ietf.org, iesg@ietf.org Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 21:31:09 -0000 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=E2=80=99t see that happening = at the first pass.=20 And as for using DNS like things .. don=E2=80=99t go there. I've = already had my fights with the IAB and IESG on that one. -----Original Message----- From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of = Peter Saint-Andre Sent: Tuesday, April 19, 2011 4:09 PM To: Paul Lambert Cc: paws@ietf.org; iesg@ietf.org; IETF discussion list Subject: Re: [paws] WG Review: Protocol to Access White Space database = (paws) On 4/19/11 1:47 PM, Paul Lambert wrote: >=20 >=20 > How does the area that the group is assigned impact the choices of=20 > technology? >=20 > I'm an advocate for an efficient solution set for PAWS ... it will be=20 > much like DNS for spectrum in the future and should be viewed as a=20 > core infrastructural component that needs careful design. There are=20 > good reasons that routing protocols don't use XML. >=20 > Applications now days tend to go for the simple, quick to make a web=20 > application solutions using XML or the like ... My concern is that=20 > "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@cs.tcd.ie Tue Apr 19 14:28:18 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DEFC3E06DC; Tue, 19 Apr 2011 14:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zr+IJRVwd1PE; Tue, 19 Apr 2011 14:28:18 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfc.amsl.com (Postfix) with ESMTP id D649AE06BE; Tue, 19 Apr 2011 14:28:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 917BC171C1E; Tue, 19 Apr 2011 22:28:15 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1303248494; bh=QZfH1GSTosY99L m11AdI23c5lVaY9tiTj7Xfl5XQNaE=; b=OM/kvkqXApryA+NMH+Cw7ArWAtdbsa PtyQoV+77Wy0WnYWzBXdXy6Q9uHIv7rG+8RvH3OkzM+QW5WeK31mvKVfOPNNLulb vMjPNjYgc/g+ign381QCaLk+IjlDvhK/Cs5qNyd0lbOqBjGpzMKAD6v2zy/LazQ5 ihmYxe1gnMxGhSIg03DWJamhLusD43DB/iNiyHrIJ9erd+WXPZRCTRgXwnbuCPCQ gZOV+xeqVfQ3Z66IFCKRLDG94II+sLuUt3HQqUBi9CXd7MtKAbru3xBNe0Ra61jp K6TYI4vvcRgqbyuzbDU+/r04XJc4ce2b7gpllABvtbkSrOG+nhspYQMw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id FBQ5tlgAjSB7; Tue, 19 Apr 2011 22:28:14 +0100 (IST) Received: from [10.87.48.10] (unknown [86.42.177.204]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 8A32E171C1B; Tue, 19 Apr 2011 22:28:14 +0100 (IST) Message-ID: <4DADFE6D.3050107@cs.tcd.ie> Date: Tue, 19 Apr 2011 22:28:13 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: IETF-Discussion References: <20110419165634.CD24CE07CF@ietfc.amsl.com> In-Reply-To: <20110419165634.CD24CE07CF@ietfc.amsl.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 19 Apr 2011 14:40:25 -0700 Cc: paws@ietf.org, iesg@ietf.org Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 21:28:19 -0000 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: > The protocol must protect both the channel enablement process and the > privacy of users. That part is fine but it goes on to say: > Robust security mechanisms are required to prevent: > device identity spoofing, modification of device requests, modification > 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@marvell.com Tue Apr 19 15:58:49 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CB03AE0660; Tue, 19 Apr 2011 15:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9hFJJ+rBwKN; Tue, 19 Apr 2011 15:58:48 -0700 (PDT) Received: from na3sys009aog107.obsmtp.com (na3sys009aog107.obsmtp.com [74.125.149.197]) by ietfc.amsl.com (Postfix) with ESMTP id 56D71E07FE; Tue, 19 Apr 2011 15:58:48 -0700 (PDT) Received: from sc-owa02.marvell.com ([65.219.4.130]) (using TLSv1) by na3sys009aob107.postini.com ([74.125.148.12]) with SMTP ID DSNKTa4TmsMWbAlrs8L8lCEwHQcF/7lO9PvJ@postini.com; Tue, 19 Apr 2011 15:58:48 PDT Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa02.marvell.com ([10.93.76.22]) with mapi; Tue, 19 Apr 2011 15:56:22 -0700 From: Paul Lambert To: Richard Shockey , 'Peter Saint-Andre' Date: Tue, 19 Apr 2011 15:53:52 -0700 Thread-Topic: [paws] WG Review: Protocol to Access White Space database (paws) Thread-Index: Acv+zZTlgXow9KXPTZKwzEPFvgerjAACbrHwAAMcGkA= Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01406AC56CF@SC-VEXCH2.marvell.com> References: <20110419165634.CD24CE07CF@ietfc.amsl.com> <4DADCB52.1020309@joelhalpern.com> <7BAC95F5A7E67643AAFB2C31BEE662D01406AC564E@SC-VEXCH2.marvell.com> <4DADEBC0.1060200@stpeter.im> <004601cbfed9$18879c50$4996d4f0$@us> In-Reply-To: <004601cbfed9$18879c50$4996d4f0$@us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "paws@ietf.org" , "iesg@ietf.org" Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 22:58:50 -0000 DQo+IEdpdmVuIGluaXRpYWwgdGltZSB0byBtYXJrZXQgaXNzdWVzLCAgSSBkb27igJl0IHNlZSB0 aGF0IGhhcHBlbmluZyBhdCB0aGUNCj4gZmlyc3QgcGFzcy4NCg0KQSBwb29yIGFyZ3VtZW50IC4u LiBYTUwgaXMgYWN0dWFsbHkgaGFyZGVyIGFuZCBzbG93ZXIgdG8gbWFya2V0IGZvciBzb21lIGRl dmljZXMuICBUaGVyZSBhcmUgYWxzbyB2ZXJ5IGZhc3QtdG8tbWFya2V0IGVmZmljaWVudCBlbmNv ZGluZyBhcHByb2FjaGVzLiBXZSBzaG91bGQgYmFzZSBkZWNpc2lvbnMgb24gYWdyZWVkIHJlcXVp cmVtZW50cyB2ZXJzdXMgaW5kaXZpZHVhbCBwZXJjZXB0aW9ucyBvZiBpbXBsZW1lbnRhdGlvbiBz Y2hlZHVsZXMuDQoNClBhdWwNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy b206IFJpY2hhcmQgU2hvY2tleSBbbWFpbHRvOnJpY2hhcmRAc2hvY2tleS51c10NCj4gU2VudDog VHVlc2RheSwgQXByaWwgMTksIDIwMTEgMjozMSBQTQ0KPiBUbzogJ1BldGVyIFNhaW50LUFuZHJl JzsgUGF1bCBMYW1iZXJ0DQo+IENjOiBwYXdzQGlldGYub3JnOyBpZXNnQGlldGYub3JnDQo+IFN1 YmplY3Q6IFJFOiBbcGF3c10gV0cgUmV2aWV3OiBQcm90b2NvbCB0byBBY2Nlc3MgV2hpdGUgU3Bh Y2UgZGF0YWJhc2UNCj4gKHBhd3MpDQo+IA0KPiBQYXVsIHRoZSBjaG9pY2Ugb2YgRGlyZWN0b3Jh dGVzIGhlcmUgaXMgc29tZXdoYXQgaXJyZWxldmFudC4gVGhpcyB3b3JrDQo+IGNvdWxkIGJlIHN1 Y2Nlc3NmdWxseSBkb25lIGFueXdoZXJlIGluIHRoZSBJRVRGLCB0aG91Z2ggQVBQUyBpcw0KPiBw cm9iYWJseSB0aGUgcmF0aW9uYWwgY2hvaWNlLiAgSm9lbCB0aGUgbGFzdCB0aGluZyB3ZSBuZWVk IGlzIHRvIGNsb2cNCj4gdXAgUkFJIGFueSBtb3JlIHRoYW4gaXQgaXMsIHRob3VnaCB5b3UgYXJl IHJpZ2h0IGFsbW9zdCBhbGwgdGhlDQo+IHJlbGV2YW50IGdlb2xvY2F0aW9uIHN0dWZmIHdpbGwg Y29tZSBvdXQgb2YgdGhlcmUuDQo+IA0KPiBQYXVsJ3MgcG9pbnQgaXMgdGhlcmUgYXJlIHR3byBs ZWdpdGltYXRlIHZpZXdzIG9mIGhvdyB0aGUgV1NEQiBzaG91bGQNCj4gb3BlcmF0ZS4gIFlvdSBj YW4gY2VydGFpbmx5IHVzZSB0aGUgSUVURiBzdGFuZGFyZCB0b29sIGJveCBvZiBIVFRQIFRMUw0K PiBYTUwgQUEgZXRjIEpTT04gKG1heWJlKSBidXQgaWYgeW91IHZpZXcgdGhlIHdvcmxkIGZyb20g YSBjaGlwDQo+IG1hbnVmYWN0dXJlciB5b3UgYXJlIGxvb2tpbmcgYXQgY29zdCBvZiBpbXBsZW1l bnRhdGlvbiBvZiB0aGUgc3RhY2sgYW5kDQo+IHNvbWV0aGluZyB0aGF0IGxvb2tzIG1vcmUgbGln aHR3ZWlnaHQgb3IgYmluYXJ5IG1ha2VzIHNlbnNlLg0KPiANCj4gR2l2ZW4gaW5pdGlhbCB0aW1l IHRvIG1hcmtldCBpc3N1ZXMsICBJIGRvbuKAmXQgc2VlIHRoYXQgaGFwcGVuaW5nIGF0IHRoZQ0K PiBmaXJzdCBwYXNzLg0KPiANCj4gQW5kIGFzIGZvciB1c2luZyBETlMgbGlrZSB0aGluZ3MgLi4g ZG9u4oCZdCBnbyB0aGVyZS4gIEkndmUgYWxyZWFkeSBoYWQNCj4gbXkgZmlnaHRzIHdpdGggdGhl IElBQiBhbmQgSUVTRyBvbiB0aGF0IG9uZS4NCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IGlldGYtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmlldGYtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+IFBldGVyIFNhaW50LUFuZHJlDQo+IFNlbnQ6IFR1ZXNk YXksIEFwcmlsIDE5LCAyMDExIDQ6MDkgUE0NCj4gVG86IFBhdWwgTGFtYmVydA0KPiBDYzogcGF3 c0BpZXRmLm9yZzsgaWVzZ0BpZXRmLm9yZzsgSUVURiBkaXNjdXNzaW9uIGxpc3QNCj4gU3ViamVj dDogUmU6IFtwYXdzXSBXRyBSZXZpZXc6IFByb3RvY29sIHRvIEFjY2VzcyBXaGl0ZSBTcGFjZSBk YXRhYmFzZQ0KPiAocGF3cykNCj4gDQo+IE9uIDQvMTkvMTEgMTo0NyBQTSwgUGF1bCBMYW1iZXJ0 IHdyb3RlOg0KPiA+DQo+ID4NCj4gPiBIb3cgZG9lcyB0aGUgYXJlYSB0aGF0IHRoZSBncm91cCBp cyBhc3NpZ25lZCBpbXBhY3QgdGhlIGNob2ljZXMgb2YNCj4gPiB0ZWNobm9sb2d5Pw0KPiA+DQo+ ID4gSSdtIGFuIGFkdm9jYXRlIGZvciBhbiBlZmZpY2llbnQgc29sdXRpb24gc2V0IGZvciBQQVdT IC4uLiBpdCB3aWxsIGJlDQo+ID4gbXVjaCBsaWtlIEROUyBmb3Igc3BlY3RydW0gaW4gdGhlIGZ1 dHVyZSBhbmQgc2hvdWxkIGJlIHZpZXdlZCBhcyBhDQo+ID4gY29yZSBpbmZyYXN0cnVjdHVyYWwg Y29tcG9uZW50IHRoYXQgbmVlZHMgY2FyZWZ1bCBkZXNpZ24uICBUaGVyZSBhcmUNCj4gPiBnb29k IHJlYXNvbnMgdGhhdCByb3V0aW5nIHByb3RvY29scyBkb24ndCB1c2UgWE1MLg0KPiA+DQo+ID4g QXBwbGljYXRpb25zIG5vdyBkYXlzIHRlbmQgdG8gZ28gZm9yIHRoZSBzaW1wbGUsIHF1aWNrIHRv IG1ha2UgYSB3ZWINCj4gPiBhcHBsaWNhdGlvbiBzb2x1dGlvbnMgdXNpbmcgWE1MIG9yIHRoZSBs aWtlIC4uLiAgTXkgY29uY2VybiBpcyB0aGF0DQo+ID4gIkFwcGxpY2F0aW9ucyIgaW1wbHkgdGhh dCBlZmZpY2llbmN5IGRvZXMgbm90IG1hdHRlci4NCj4gDQo+IEEgcXVpY2sgbG9vayBhdCB0aGUg c3BlY2lmaWNhdGlvbnMgZm9yIHRoZSBDT1JFIFdHIGluIHRoZSBBcHBsaWNhdGlvbnMNCj4gQXJl YSB3aWxsIHNob3cgeW91IHRoYXQgd2UncmUgYWJsZSB0byBwcm9kdWNlIHByb3RvY29scyB0aGF0 IGFyZSBxdWl0ZQ0KPiBzbGltIG9uIHRoZSB3aXJlLg0KPiANCj4gUGV0ZXINCj4gDQo+IC0tDQo+ IFBldGVyIFNhaW50LUFuZHJlDQo+IGh0dHBzOi8vc3RwZXRlci5pbS8NCj4gDQo+IA0KPiANCg0K From richard@shockey.us Tue Apr 19 17:25:16 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3E4D4E07C8 for ; Tue, 19 Apr 2011 17:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyGMaPNxOYJ6 for ; Tue, 19 Apr 2011 17:25:15 -0700 (PDT) Received: from cpoproxy1-pub.bluehost.com (cpoproxy1-pub.bluehost.com [69.89.21.11]) by ietfc.amsl.com (Postfix) with SMTP id 19E4FE077A for ; Tue, 19 Apr 2011 17:25:15 -0700 (PDT) Received: (qmail 13543 invoked by uid 0); 20 Apr 2011 00:25:13 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by cpoproxy1.bluehost.com with SMTP; 20 Apr 2011 00:25:13 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=KnHcnV+WP1xdQI+VmnUvaXO9WZKGq1EGEXZT6dLcUUkIMMN8tIAsLIethyImjrJ7Ni1aKWgmYlPMUpr/vAOe2Idz07J5hZhdTVNZCU4uqmzFuiTL1zPxchR6o04LOMSO; Received: from pool-71-178-24-118.washdc.fios.verizon.net ([71.178.24.118] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1QCLEH-000812-BL; Tue, 19 Apr 2011 18:25:13 -0600 From: "Richard Shockey" To: "'Paul Lambert'" , "'Peter Saint-Andre'" References: <20110419165634.CD24CE07CF@ietfc.amsl.com> <4DADCB52.1020309@joelhalpern.com> <7BAC95F5A7E67643AAFB2C31BEE662D01406AC564E@SC-VEXCH2.marvell.com> <4DADEBC0.1060200@stpeter.im> <004601cbfed9$18879c50$4996d4f0$@us> <7BAC95F5A7E67643AAFB2C31BEE662D01406AC56CF@SC-VEXCH2.marvell.com> In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D01406AC56CF@SC-VEXCH2.marvell.com> Date: Tue, 19 Apr 2011 20:25:12 -0400 Message-ID: <007e01cbfef1$6b1569d0$41403d70$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acv+zZTlgXow9KXPTZKwzEPFvgerjAACbrHwAAMcGkAAA09nAA== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.178.24.118 authed with richard@shockey.us} Cc: paws@ietf.org, iesg@ietf.org Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 00:25:16 -0000 Well we certainly hope to see your input to the requirements. I deeply = respect your views here. > Given initial time to market issues, I don=E2=80=99t see that = happening at the > first pass. 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 > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: Tuesday, April 19, 2011 2:31 PM > To: 'Peter Saint-Andre'; Paul Lambert > Cc: paws@ietf.org; iesg@ietf.org > Subject: RE: [paws] WG Review: Protocol to Access White Space database > (paws) >=20 > 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. >=20 > 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. >=20 > Given initial time to market issues, I don=E2=80=99t see that = happening at the > first pass. >=20 > And as for using DNS like things .. don=E2=80=99t go there. I've = already had > my fights with the IAB and IESG on that one. >=20 > -----Original Message----- > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf = Of > Peter Saint-Andre > Sent: Tuesday, April 19, 2011 4:09 PM > To: Paul Lambert > Cc: paws@ietf.org; iesg@ietf.org; IETF discussion list > Subject: Re: [paws] WG Review: Protocol to Access White Space database > (paws) >=20 > 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. >=20 > 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. >=20 > Peter >=20 > -- > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 >=20 From jmh@joelhalpern.com Tue Apr 19 19:13:29 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8B1BEE0670; Tue, 19 Apr 2011 19:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aV4rbnj82Dyi; Tue, 19 Apr 2011 19:13:28 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by ietfc.amsl.com (Postfix) with ESMTP id B03DAE0815; Tue, 19 Apr 2011 19:13:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 02CE243004E; Tue, 19 Apr 2011 19:13:16 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-50-206.clppva.btas.verizon.net [71.161.50.206]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id D47BA430052; Tue, 19 Apr 2011 19:13:14 -0700 (PDT) Message-ID: <4DAE4139.9@joelhalpern.com> Date: Tue, 19 Apr 2011 22:13:13 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Paul Lambert References: <20110419165634.CD24CE07CF@ietfc.amsl.com> <4DADCB52.1020309@joelhalpern.com> <7BAC95F5A7E67643AAFB2C31BEE662D01406AC564E@SC-VEXCH2.marvell.com> In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D01406AC564E@SC-VEXCH2.marvell.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "paws@ietf.org" , IETF discussion list Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 02:13:29 -0000 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: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >> Joel M. Halpern >> Sent: Tuesday, April 19, 2011 10:50 AM >> To: iesg@ietf.org >> Cc: paws@ietf.org; IETF discussion list >> Subject: Re: [paws] WG Review: Protocol to Access White Space database >> (paws) >> >> 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 (iesg@ietf.org) 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: paws@ietf.org >>> 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 >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >>> >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws > From jmh@joelhalpern.com Tue Apr 19 19:17:46 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DD2CCE0834; Tue, 19 Apr 2011 19:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.493 X-Spam-Level: X-Spam-Status: No, score=-102.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKWh3NHWRSgI; Tue, 19 Apr 2011 19:17:45 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by ietfc.amsl.com (Postfix) with ESMTP id 83B62E0814; Tue, 19 Apr 2011 19:17:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2382A4300E5; Tue, 19 Apr 2011 19:17:45 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-50-206.clppva.btas.verizon.net [71.161.50.206]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 9B92343004E; Tue, 19 Apr 2011 19:17:43 -0700 (PDT) Message-ID: <4DAE4246.7080200@joelhalpern.com> Date: Tue, 19 Apr 2011 22:17:42 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Rex Buddenberg References: <20110419165634.CD24CE07CF@ietfc.amsl.com> <4DADCB52.1020309@joelhalpern.com> <7BAC95F5A7E67643AAFB2C31BEE662D01406AC564E@SC-VEXCH2.marvell.com> <1303248099.2209.105.camel@localhost.localdomain> In-Reply-To: <1303248099.2209.105.camel@localhost.localdomain> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "paws@ietf.org" , "iesg@ietf.org" , IETF discussion list Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 02:17:47 -0000 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: >> >> 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. > > While the DNS analogy works, I was thinking more a parallel -- or > extension -- of SNMP. > > Still remain within 'applications', Joel? > >> >> 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: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >>> Joel M. Halpern >>> Sent: Tuesday, April 19, 2011 10:50 AM >>> To: iesg@ietf.org >>> Cc: paws@ietf.org; IETF discussion list >>> Subject: Re: [paws] WG Review: Protocol to Access White Space database >>> (paws) >>> >>> 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 (iesg@ietf.org) 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: paws@ietf.org >>>> 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 >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>>> >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws > > > From Basavaraj.Patil@nokia.com Tue Apr 19 20:00:36 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F3992E067C; Tue, 19 Apr 2011 20:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tfzNAtEoGAHx; Tue, 19 Apr 2011 20:00:35 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfc.amsl.com (Postfix) with ESMTP id CFC9EE0660; Tue, 19 Apr 2011 20:00:34 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p3K30DxG017244; Wed, 20 Apr 2011 06:00:32 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Apr 2011 06:00:31 +0300 Received: from 008-AM1MMR1-005.mgdnok.nokia.com (65.54.30.60) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 20 Apr 2011 05:00:30 +0200 Received: from 008-AM1MPN1-025.mgdnok.nokia.com ([169.254.5.134]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0289.008; Wed, 20 Apr 2011 05:00:30 +0200 From: To: , , Thread-Topic: [paws] WG Review: Protocol to Access White Space database (paws) Thread-Index: AQHL/rLAHraUh0DINEKp8P50E+1g05RlVYcAgAAg1YCAAAXUAIAAFxEAgAAXIACAABrVYA== Date: Wed, 20 Apr 2011 03:00:30 +0000 Message-ID: <21E7D9BD69CC7241AAE00F4EA183B719023EA2@008-AM1MPN1-025.mgdnok.nokia.com> References: <20110419165634.CD24CE07CF@ietfc.amsl.com> <4DADCB52.1020309@joelhalpern.com> <7BAC95F5A7E67643AAFB2C31BEE662D01406AC564E@SC-VEXCH2.marvell.com> <4DADEBC0.1060200@stpeter.im> <004601cbfed9$18879c50$4996d4f0$@us> <7BAC95F5A7E67643AAFB2C31BEE662D01406AC56CF@SC-VEXCH2.marvell.com> In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D01406AC56CF@SC-VEXCH2.marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.64.197.89] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 20 Apr 2011 03:00:31.0373 (UTC) FILETIME=[1C3BDBD0:01CBFF07] X-Nokia-AV: Clean Cc: paws@ietf.org, iesg@ietf.org Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 03:00:36 -0000 DQpJIGJlbGlldmUgd2UgYXJlIHJ1c2hpbmcgdG8gY29uY2x1c2lvbnMgYWJvdXQgd2hhdCB0aGUg YWN0dWFsIHByb3RvY29sIGl0c2VsZiB3aWxsIGJlLg0KUmlnaHQgbm93IHRoZSBvbmx5IGRpc2N1 c3Npb24gaXMgYWJvdXQgdGhlIHByb3Bvc2VkIGNoYXJ0ZXIgYW5kIHNjb3BlLiBBIGNhc2Ugb2Yg cHV0dGluZyB0aGUgY2FydCBiZWZvcmUgdGhlIGhvcnNlLg0KDQotQmFzYXZhcmFqDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBwYXdzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBleHQgUGF1bCBMYW1iZXJ0DQpT ZW50OiBUdWVzZGF5LCBBcHJpbCAxOSwgMjAxMSA1OjU0IFBNDQpUbzogUmljaGFyZCBTaG9ja2V5 OyAnUGV0ZXIgU2FpbnQtQW5kcmUnDQpDYzogcGF3c0BpZXRmLm9yZzsgaWVzZ0BpZXRmLm9yZw0K U3ViamVjdDogUmU6IFtwYXdzXSBXRyBSZXZpZXc6IFByb3RvY29sIHRvIEFjY2VzcyBXaGl0ZSBT cGFjZSBkYXRhYmFzZSAocGF3cykNCg0KDQo+IEdpdmVuIGluaXRpYWwgdGltZSB0byBtYXJrZXQg aXNzdWVzLCAgSSBkb27igJl0IHNlZSB0aGF0IGhhcHBlbmluZyBhdCB0aGUNCj4gZmlyc3QgcGFz cy4NCg0KQSBwb29yIGFyZ3VtZW50IC4uLiBYTUwgaXMgYWN0dWFsbHkgaGFyZGVyIGFuZCBzbG93 ZXIgdG8gbWFya2V0IGZvciBzb21lIGRldmljZXMuICBUaGVyZSBhcmUgYWxzbyB2ZXJ5IGZhc3Qt dG8tbWFya2V0IGVmZmljaWVudCBlbmNvZGluZyBhcHByb2FjaGVzLiBXZSBzaG91bGQgYmFzZSBk ZWNpc2lvbnMgb24gYWdyZWVkIHJlcXVpcmVtZW50cyB2ZXJzdXMgaW5kaXZpZHVhbCBwZXJjZXB0 aW9ucyBvZiBpbXBsZW1lbnRhdGlvbiBzY2hlZHVsZXMuDQoNCg0KUGF1bA0KDQoNCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUmljaGFyZCBTaG9ja2V5IFttYWlsdG86cmlj aGFyZEBzaG9ja2V5LnVzXQ0KPiBTZW50OiBUdWVzZGF5LCBBcHJpbCAxOSwgMjAxMSAyOjMxIFBN DQo+IFRvOiAnUGV0ZXIgU2FpbnQtQW5kcmUnOyBQYXVsIExhbWJlcnQNCj4gQ2M6IHBhd3NAaWV0 Zi5vcmc7IGllc2dAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IFtwYXdzXSBXRyBSZXZpZXc6IFBy b3RvY29sIHRvIEFjY2VzcyBXaGl0ZSBTcGFjZSBkYXRhYmFzZQ0KPiAocGF3cykNCj4gDQo+IFBh dWwgdGhlIGNob2ljZSBvZiBEaXJlY3RvcmF0ZXMgaGVyZSBpcyBzb21ld2hhdCBpcnJlbGV2YW50 LiBUaGlzIHdvcmsNCj4gY291bGQgYmUgc3VjY2Vzc2Z1bGx5IGRvbmUgYW55d2hlcmUgaW4gdGhl IElFVEYsIHRob3VnaCBBUFBTIGlzDQo+IHByb2JhYmx5IHRoZSByYXRpb25hbCBjaG9pY2UuICBK b2VsIHRoZSBsYXN0IHRoaW5nIHdlIG5lZWQgaXMgdG8gY2xvZw0KPiB1cCBSQUkgYW55IG1vcmUg dGhhbiBpdCBpcywgdGhvdWdoIHlvdSBhcmUgcmlnaHQgYWxtb3N0IGFsbCB0aGUNCj4gcmVsZXZh bnQgZ2VvbG9jYXRpb24gc3R1ZmYgd2lsbCBjb21lIG91dCBvZiB0aGVyZS4NCj4gDQo+IFBhdWwn cyBwb2ludCBpcyB0aGVyZSBhcmUgdHdvIGxlZ2l0aW1hdGUgdmlld3Mgb2YgaG93IHRoZSBXU0RC IHNob3VsZA0KPiBvcGVyYXRlLiAgWW91IGNhbiBjZXJ0YWlubHkgdXNlIHRoZSBJRVRGIHN0YW5k YXJkIHRvb2wgYm94IG9mIEhUVFAgVExTDQo+IFhNTCBBQSBldGMgSlNPTiAobWF5YmUpIGJ1dCBp ZiB5b3UgdmlldyB0aGUgd29ybGQgZnJvbSBhIGNoaXANCj4gbWFudWZhY3R1cmVyIHlvdSBhcmUg bG9va2luZyBhdCBjb3N0IG9mIGltcGxlbWVudGF0aW9uIG9mIHRoZSBzdGFjayBhbmQNCj4gc29t ZXRoaW5nIHRoYXQgbG9va3MgbW9yZSBsaWdodHdlaWdodCBvciBiaW5hcnkgbWFrZXMgc2Vuc2Uu DQo+IA0KPiBHaXZlbiBpbml0aWFsIHRpbWUgdG8gbWFya2V0IGlzc3VlcywgIEkgZG9u4oCZdCBz ZWUgdGhhdCBoYXBwZW5pbmcgYXQgdGhlDQo+IGZpcnN0IHBhc3MuDQo+IA0KPiBBbmQgYXMgZm9y IHVzaW5nIEROUyBsaWtlIHRoaW5ncyAuLiBkb27igJl0IGdvIHRoZXJlLiAgSSd2ZSBhbHJlYWR5 IGhhZA0KPiBteSBmaWdodHMgd2l0aCB0aGUgSUFCIGFuZCBJRVNHIG9uIHRoYXQgb25lLg0KPiAN Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaWV0Zi1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86aWV0Zi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gUGV0ZXIg U2FpbnQtQW5kcmUNCj4gU2VudDogVHVlc2RheSwgQXByaWwgMTksIDIwMTEgNDowOSBQTQ0KPiBU bzogUGF1bCBMYW1iZXJ0DQo+IENjOiBwYXdzQGlldGYub3JnOyBpZXNnQGlldGYub3JnOyBJRVRG IGRpc2N1c3Npb24gbGlzdA0KPiBTdWJqZWN0OiBSZTogW3Bhd3NdIFdHIFJldmlldzogUHJvdG9j b2wgdG8gQWNjZXNzIFdoaXRlIFNwYWNlIGRhdGFiYXNlDQo+IChwYXdzKQ0KPiANCj4gT24gNC8x OS8xMSAxOjQ3IFBNLCBQYXVsIExhbWJlcnQgd3JvdGU6DQo+ID4NCj4gPg0KPiA+IEhvdyBkb2Vz IHRoZSBhcmVhIHRoYXQgdGhlIGdyb3VwIGlzIGFzc2lnbmVkIGltcGFjdCB0aGUgY2hvaWNlcyBv Zg0KPiA+IHRlY2hub2xvZ3k/DQo+ID4NCj4gPiBJJ20gYW4gYWR2b2NhdGUgZm9yIGFuIGVmZmlj aWVudCBzb2x1dGlvbiBzZXQgZm9yIFBBV1MgLi4uIGl0IHdpbGwgYmUNCj4gPiBtdWNoIGxpa2Ug RE5TIGZvciBzcGVjdHJ1bSBpbiB0aGUgZnV0dXJlIGFuZCBzaG91bGQgYmUgdmlld2VkIGFzIGEN Cj4gPiBjb3JlIGluZnJhc3RydWN0dXJhbCBjb21wb25lbnQgdGhhdCBuZWVkcyBjYXJlZnVsIGRl c2lnbi4gIFRoZXJlIGFyZQ0KPiA+IGdvb2QgcmVhc29ucyB0aGF0IHJvdXRpbmcgcHJvdG9jb2xz IGRvbid0IHVzZSBYTUwuDQo+ID4NCj4gPiBBcHBsaWNhdGlvbnMgbm93IGRheXMgdGVuZCB0byBn byBmb3IgdGhlIHNpbXBsZSwgcXVpY2sgdG8gbWFrZSBhIHdlYg0KPiA+IGFwcGxpY2F0aW9uIHNv bHV0aW9ucyB1c2luZyBYTUwgb3IgdGhlIGxpa2UgLi4uICBNeSBjb25jZXJuIGlzIHRoYXQNCj4g PiAiQXBwbGljYXRpb25zIiBpbXBseSB0aGF0IGVmZmljaWVuY3kgZG9lcyBub3QgbWF0dGVyLg0K PiANCj4gQSBxdWljayBsb29rIGF0IHRoZSBzcGVjaWZpY2F0aW9ucyBmb3IgdGhlIENPUkUgV0cg aW4gdGhlIEFwcGxpY2F0aW9ucw0KPiBBcmVhIHdpbGwgc2hvdyB5b3UgdGhhdCB3ZSdyZSBhYmxl IHRvIHByb2R1Y2UgcHJvdG9jb2xzIHRoYXQgYXJlIHF1aXRlDQo+IHNsaW0gb24gdGhlIHdpcmUu DQo+IA0KPiBQZXRlcg0KPiANCj4gLS0NCj4gUGV0ZXIgU2FpbnQtQW5kcmUNCj4gaHR0cHM6Ly9z dHBldGVyLmltLw0KPiANCj4gDQo+IA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KcGF3cyBtYWlsaW5nIGxpc3QNCnBhd3NAaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0K From ajs@shinkuro.com Wed Apr 20 04:22:50 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 09807E0682; Wed, 20 Apr 2011 04:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.615 X-Spam-Level: X-Spam-Status: No, score=-102.615 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tjy1jHK6Su3Q; Wed, 20 Apr 2011 04:22:49 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfc.amsl.com (Postfix) with ESMTP id 746E2E0680; Wed, 20 Apr 2011 04:22:49 -0700 (PDT) Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 4BA541ECB408; Wed, 20 Apr 2011 11:22:48 +0000 (UTC) Date: Wed, 20 Apr 2011 07:21:51 -0400 From: Andrew Sullivan To: "Joel M. Halpern" Message-ID: <20110420112150.GA5201@crankycanuck.ca> References: <20110419165634.CD24CE07CF@ietfc.amsl.com> <4DADCB52.1020309@joelhalpern.com> <7BAC95F5A7E67643AAFB2C31BEE662D01406AC564E@SC-VEXCH2.marvell.com> <4DAE4139.9@joelhalpern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DAE4139.9@joelhalpern.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "paws@ietf.org" , IETF discussion list Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 11:22:50 -0000 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 ajs@shinkuro.com Shinkuro, Inc. From scott.probasco@nokia.com Wed Apr 20 07:41:40 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 80C48E070D; Wed, 20 Apr 2011 07:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMCKg8CryHS9; Wed, 20 Apr 2011 07:41:39 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfc.amsl.com (Postfix) with ESMTP id 49632E0705; Wed, 20 Apr 2011 07:41:38 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-sa01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p3KEfS9D020329; Wed, 20 Apr 2011 17:41:34 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Apr 2011 17:41:33 +0300 Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 20 Apr 2011 16:41:24 +0200 Received: from 008-AM1MPN1-023.mgdnok.nokia.com ([169.254.3.210]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0289.008; Wed, 20 Apr 2011 16:41:24 +0200 From: To: , Thread-Topic: [paws] WG Review: Protocol to Access White Space database (paws) Thread-Index: AQHL/rLA5Czj0i0wfE+ujEk1m1AO2ZRlknOAgAE/lXA= Date: Wed, 20 Apr 2011 14:41:23 +0000 Message-ID: <88BE24FD9280884487DEAE0CE1FD3A5B060F1B@008-AM1MPN1-023.mgdnok.nokia.com> References: <20110419165634.CD24CE07CF@ietfc.amsl.com> <4DADFE6D.3050107@cs.tcd.ie> In-Reply-To: <4DADFE6D.3050107@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-version: 3.2.55 x-tituslabs-classifications-30: TLPropertyRoot=Trial License;Classification=Personal; x-putclassificationandsendinfointox-header: Classification: Personal Project: Subject: RE: [paws] WG Review: Protocol to Access White Space database (paws) Sender Name: Probasco Scott (Nokia-CIC/Dallas) Sender Email: scott.probasco@nokia.com Send Date: Wednesday, April 20, 2011 Send Time: 9:41:21 AM x-originating-ip: [172.19.60.53] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 20 Apr 2011 14:41:33.0088 (UTC) FILETIME=[0AF83A00:01CBFF69] X-Nokia-AV: Clean Cc: paws@ietf.org, iesg@ietf.org Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 14:41:40 -0000 Hi Stephen, All, I believe the current wording >> Robust security mechanisms are required to prevent: >> device identity spoofing, modification of device requests, modification >> 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 Re= gulator requirements globally, and thus I believe there will be procedures = or capabilities which are "required" to be in the protocol but will be "opt= ional" during run time. Thus different or conflicting requirements from dif= ferent regions of the world can be supported. (Several regulatory groups ar= ound the world are still developing their views and requirements). It's not the time to dig deep into proposed solutions, just my opinion is t= he current proposed wording is an acceptable definition to allow a Work Gro= up to get started defining the details. Regards, Scott -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= Stephen Farrell Sent: Tuesday, April 19, 2011 4:28 PM To: IETF-Discussion Cc: paws@ietf.org; iesg@ietf.org Subject: Re: [paws] WG Review: Protocol to Access White Space database (paw= s) 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: > The protocol must protect both the channel enablement process and the > privacy of users.=20 That part is fine but it goes on to say: > Robust security mechanisms are required to prevent: > device identity spoofing, modification of device requests, modification > 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=3Decfr&sid=3D3e9c322addf1f7= e897d8c84a6c7aca78&rgn=3Ddiv8&view=3Dtext&node=3D47:1.0.1.1.14.8.243.9&idno= =3D47 _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From alexey.melnikov@isode.com Wed Apr 20 02:26:14 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B01A2E0689; Wed, 20 Apr 2011 02:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.472 X-Spam-Level: X-Spam-Status: No, score=-102.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HN4PpF4H5-8; Wed, 20 Apr 2011 02:26:14 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfc.amsl.com (Postfix) with ESMTP id 5EA04E0670; Wed, 20 Apr 2011 02:26:10 -0700 (PDT) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 20 Apr 2011 10:26:08 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4DAEA6A5.6020803@isode.com> Date: Wed, 20 Apr 2011 10:25:57 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Paul Lambert References: <20110419165634.CD24CE07CF@ietfc.amsl.com> <4DADCB52.1020309@joelhalpern.com> <7BAC95F5A7E67643AAFB2C31BEE662D01406AC564E@SC-VEXCH2.marvell.com> <4DADEBC0.1060200@stpeter.im> In-Reply-To: <4DADEBC0.1060200@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 20 Apr 2011 07:59:37 -0700 Cc: "paws@ietf.org" , "iesg@ietf.org" , IETF discussion list Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 09:26:14 -0000 Peter Saint-Andre wrote: >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. >> >> 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.) >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. > Exactly. From bernard_aboba@hotmail.com Wed Apr 20 07:55:52 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CC665E06E1; Wed, 20 Apr 2011 07:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4l10DSnSVNl; Wed, 20 Apr 2011 07:55:51 -0700 (PDT) Received: from blu0-omc1-s35.blu0.hotmail.com (blu0-omc1-s35.blu0.hotmail.com [65.55.116.46]) by ietfc.amsl.com (Postfix) with ESMTP id 86964E06AD; Wed, 20 Apr 2011 07:55:51 -0700 (PDT) Received: from BLU152-W2 ([65.55.116.8]) by blu0-omc1-s35.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Apr 2011 07:55:51 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_4df9682d-8165-4654-90d2-699137dbe4e5_" X-Originating-IP: [98.203.198.61] From: Bernard Aboba To: , , Date: Wed, 20 Apr 2011 07:55:50 -0700 Importance: Normal In-Reply-To: <88BE24FD9280884487DEAE0CE1FD3A5B060F1B@008-AM1MPN1-023.mgdnok.nokia.com> References: <20110419165634.CD24CE07CF@ietfc.amsl.com>, <4DADFE6D.3050107@cs.tcd.ie>, <88BE24FD9280884487DEAE0CE1FD3A5B060F1B@008-AM1MPN1-023.mgdnok.nokia.com> MIME-Version: 1.0 X-OriginalArrivalTime: 20 Apr 2011 14:55:51.0094 (UTC) FILETIME=[0A618D60:01CBFF6B] X-Mailman-Approved-At: Wed, 20 Apr 2011 07:59:37 -0700 Cc: paws@ietf.org, "iesg@ietf.org" Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 14:55:53 -0000 --_4df9682d-8165-4654-90d2-699137dbe4e5_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable When I hear the term "device identity spoofing"=2C IEEE 802.1ar comes to mi= nd (see http://standards.ieee.org/getieee802/download/802.1AR.-2009.pdf). = =20 In addition to the liaisons with IEEE 802.19=2C 802.22 and IEEE 802.11af=2C= is there a liaison contemplated to IEEE 802.1 relating to "device identity= "? > From: scott.probasco@nokia.com > To: stephen.farrell@cs.tcd.ie=3B ietf@ietf.org > Subject: RE: [paws] WG Review: Protocol to Access White Space database (p= aws) > Date: Wed=2C 20 Apr 2011 14:41:23 +0000 > CC: paws@ietf.org=3B iesg@ietf.org >=20 > Hi Stephen=2C All=2C >=20 > I believe the current wording > >> Robust security mechanisms are required to prevent: > >> device identity spoofing=2C modification of device requests=2C modific= ation > >> of channel enablement information=2C ... > is acceptable because "mechanisms are required" means they should be in t= he protocol=2C it does not mean they cannot be optional. PAWS should suppor= t Regulator requirements globally=2C and thus I believe there will be proce= dures or capabilities which are "required" to be in the protocol but will b= e "optional" during run time. Thus different or conflicting requirements fr= om different regions of the world can be supported. (Several regulatory gro= ups around the world are still developing their views and requirements). >=20 > It's not the time to dig deep into proposed solutions=2C just my opinion = is the current proposed wording is an acceptable definition to allow a Work= Group to get started defining the details. >=20 > Regards=2C > Scott >=20 > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of e= xt Stephen Farrell > Sent: Tuesday=2C April 19=2C 2011 4:28 PM > To: IETF-Discussion > Cc: paws@ietf.org=3B iesg@ietf.org > Subject: Re: [paws] WG Review: Protocol to Access White Space database (p= aws) >=20 >=20 > I think this is a good and timely thing for the IETF to do. >=20 > One part of this where I think it might be useful to get > some broader input (which may have happened already=2C I'm not > sure) is the following: >=20 > On 19/04/11 17:56=2C IESG Secretary wrote: > > The protocol must protect both the channel enablement process and the > > privacy of users.=20 >=20 > That part is fine but it goes on to say: >=20 > > Robust security mechanisms are required to prevent: > > device identity spoofing=2C modification of device requests=2C modifica= tion > > of channel enablement information=2C ... >=20 > 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=2C for some value of securely) > sent with the query. >=20 > Those appear to be real regulatory requirements in the > US=2C 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=2C I'm not at all sure=2C not being > from there=3B-) >=20 > So my questions: >=20 > Are there may be similar (or conflicting!) requirements > elsewhere? >=20 > Does this bit of the charter text need changes to work > well for other regions? >=20 > Separately=2C 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. >=20 > I'm more concerned in case e.g. some other regional regulation > called for this protocol to be completely anonymous or > something=2C in which case the current charter text might > be problematic. >=20 > Cheers=2C > Stephen. >=20 > [1] > http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=3Decfr&sid=3D3e9c322addf1= f7e897d8c84a6c7aca78&rgn=3Ddiv8&view=3Dtext&node=3D47:1.0.1.1.14.8.243.9&id= no=3D47 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws = --_4df9682d-8165-4654-90d2-699137dbe4e5_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable When I hear the term "device identity spoofing"=2C IEEE 802.1ar comes to mi= nd (see http://standards.ieee.org/getieee802/download/802.1AR.-2009.pdf).&n= bsp=3B

In addition to the liaisons with IEEE 802.19=2C 802.22 and I= EEE 802.11af=2C is there a liaison contemplated to IEEE 802.1 relating to "= device identity"?

>=3B From: scott.probasco@nokia.com
>=3B To= : stephen.farrell@cs.tcd.ie=3B ietf@ietf.org
>=3B Subject: RE: [paws] = WG Review: Protocol to Access White Space database (paws)
>=3B Date: W= ed=2C 20 Apr 2011 14:41:23 +0000
>=3B CC: paws@ietf.org=3B iesg@ietf.o= rg
>=3B
>=3B Hi Stephen=2C All=2C
>=3B
>=3B I believe= the current wording
>=3B >=3B>=3B Robust security mechanisms are = required to prevent:
>=3B >=3B>=3B device identity spoofing=2C mod= ification of device requests=2C modification
>=3B >=3B>=3B of chan= nel enablement information=2C ...
>=3B is acceptable because "mechanis= ms are required" means they should be in the protocol=2C it does not mean t= hey cannot be optional. PAWS should support Regulator requirements globally= =2C 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. Thu= s different or conflicting requirements from different regions of the world= can be supported. (Several regulatory groups around the world are still de= veloping their views and requirements).
>=3B
>=3B It's not the t= ime to dig deep into proposed solutions=2C just my opinion is the current p= roposed wording is an acceptable definition to allow a Work Group to get st= arted defining the details.
>=3B
>=3B Regards=2C
>=3B Scott=
>=3B
>=3B -----Original Message-----
>=3B From: paws-bounc= es@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Stephen Farrell=
>=3B Sent: Tuesday=2C April 19=2C 2011 4:28 PM
>=3B To: IETF-Dis= cussion
>=3B Cc: paws@ietf.org=3B iesg@ietf.org
>=3B Subject: Re:= [paws] WG Review: Protocol to Access White Space database (paws)
>=3B=
>=3B
>=3B I think this is a good and timely thing for the IETF= to do.
>=3B
>=3B One part of this where I think it might be use= ful to get
>=3B some broader input (which may have happened already=2C= I'm not
>=3B sure) is the following:
>=3B
>=3B On 19/04/11= 17:56=2C IESG Secretary wrote:
>=3B >=3B The protocol must protect = both the channel enablement process and the
>=3B >=3B privacy of use= rs.
>=3B
>=3B That part is fine but it goes on to say:
>= =3B
>=3B >=3B Robust security mechanisms are required to prevent:>=3B >=3B device identity spoofing=2C modification of device requests= =2C modification
>=3B >=3B of channel enablement information=2C ...<= br>>=3B
>=3B I'm told (and believe) this in response to (at least) = US
>=3B FCC requirements that call for a device ID and sometimes
&g= t=3B serial number to be (securely=2C for some value of securely)
>=3B= sent with the query.
>=3B
>=3B Those appear to be real regulato= ry requirements in the
>=3B US=2C presumably so the regulator can stom= p on someone who
>=3B messes about in the wrong spectrum at the wrong = time.
>=3B (The link below [1] may be to the right or wrong bit of
= >=3B those US regulations=2C I'm not at all sure=2C not being
>=3B f= rom there=3B-)
>=3B
>=3B So my questions:
>=3B
>=3B A= re there may be similar (or conflicting!) requirements
>=3B elsewhere?=
>=3B
>=3B Does this bit of the charter text need changes to wor= k
>=3B well for other regions?
>=3B
>=3B Separately=2C I'm = not sure how to square those kinds of
>=3B regulatory requirements wit= h protecting privacy where the
>=3B device is carried by a person and = has some FCC device ID
>=3B (which lots do I guess) and the person mig= ht not want
>=3B the database operator to know who's asking. But I thi= nk
>=3B that's ok as something for the WG to figure out since
>= =3B the charter already calls for respecting privacy.
>=3B
>=3B = I'm more concerned in case e.g. some other regional regulation
>=3B ca= lled for this protocol to be completely anonymous or
>=3B something=2C= in which case the current charter text might
>=3B be problematic.
= >=3B
>=3B Cheers=2C
>=3B Stephen.
>=3B
>=3B [1]
= >=3B http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=3Decfr&=3Bsid=3D3= e9c322addf1f7e897d8c84a6c7aca78&=3Brgn=3Ddiv8&=3Bview=3Dtext&=3Bno= de=3D47:1.0.1.1.14.8.243.9&=3Bidno=3D47
>=3B ______________________= _________________________
>=3B paws mailing list
>=3B paws@ietf.o= rg
>=3B https://www.ietf.org/mailman/listinfo/paws
= --_4df9682d-8165-4654-90d2-699137dbe4e5_-- From jmh@joelhalpern.com Wed Apr 20 08:41:00 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5EC4DE07ED; Wed, 20 Apr 2011 08:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rejY80qsxMqn; Wed, 20 Apr 2011 08:40:59 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by ietfc.amsl.com (Postfix) with ESMTP id F3366E06C4; Wed, 20 Apr 2011 08:40:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4ECAF430107; Wed, 20 Apr 2011 08:40:56 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-50-206.clppva.btas.verizon.net [71.161.50.206]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 2BCD74300F7; Wed, 20 Apr 2011 08:40:55 -0700 (PDT) Message-ID: <4DAEFE86.7030000@joelhalpern.com> Date: Wed, 20 Apr 2011 11:40:54 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Bernard Aboba References: <20110419165634.CD24CE07CF@ietfc.amsl.com>, <4DADFE6D.3050107@cs.tcd.ie>, <88BE24FD9280884487DEAE0CE1FD3A5B060F1B@008-AM1MPN1-023.mgdnok.nokia.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: paws@ietf.org, "iesg@ietf.org" , ietf@ietf.org, stephen.farrell@cs.tcd.ie Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 15:41:00 -0000 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 daedulus@btconnect.com Wed Apr 20 11:20:37 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DB1BCE06A6; Wed, 20 Apr 2011 11:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rD6e8AkuZS-f; Wed, 20 Apr 2011 11:20:36 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr09.btconnect.com [213.123.20.127]) by ietfc.amsl.com (Postfix) with ESMTP id C39D5E067D; Wed, 20 Apr 2011 11:20:35 -0700 (PDT) Received: from host86-134-204-18.range86-134.btcentralplus.com (HELO pc6) ([86.134.204.18]) by c2bthomr09.btconnect.com with SMTP id CQA03480; Wed, 20 Apr 2011 19:20:28 +0100 (BST) Message-ID: <01d701cbff7f$1c913940$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Joel M. Halpern" References: <20110419165634.CD24CE07CF@ietfc.amsl.com> <4DADCB52.1020309@joelhalpern.com> <7BAC95F5A7E67643AAFB2C31BEE662D01406AC564E@SC-VEXCH2.marvell.com><1303248099.2209.105.camel@localhost.localdomain> <4DAE4246.7080200@joelhalpern.com> Date: Wed, 20 Apr 2011 19:19:26 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4DAF23EB.008B, actions=tag X-Junkmail-Premium-Raw: score=26/50, refid=2.7.2:2011.4.20.173315:17:26.894, ip=86.134.204.18, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __FRAUD_CONTACT_ADDY_B, __CP_URI_IN_BODY, __INT_PROD_TV, BODY_SIZE_10000_PLUS, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, __URI_NS, SXL_IP_DYNAMIC[18.204.134.86.fur], RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP X-Junkmail-Status: score=38/50, host=c2bthomr09.btconnect.com X-Junkmail-Signature-Raw: score=suspect(3), refid=str=0001.0A0B0206.4DAF23EE.0092,ss=2,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false X-Mailman-Approved-At: Wed, 20 Apr 2011 11:21:48 -0700 Cc: paws@ietf.org, iesg@ietf.org, IETF discussion list Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 18:20:38 -0000 ----- Original Message ----- From: "Joel M. Halpern" To: "Rex Buddenberg" Cc: "Paul Lambert" ; ; ; "IETF discussion list" Sent: Wednesday, April 20, 2011 4:17 AM Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) > 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. 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 > 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: > >> > >> 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. > > > > While the DNS analogy works, I was thinking more a parallel -- or > > extension -- of SNMP. > > > > Still remain within 'applications', Joel? > > > >> > >> 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: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of > >>> Joel M. Halpern > >>> Sent: Tuesday, April 19, 2011 10:50 AM > >>> To: iesg@ietf.org > >>> Cc: paws@ietf.org; IETF discussion list > >>> Subject: Re: [paws] WG Review: Protocol to Access White Space database > >>> (paws) > >>> > >>> 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 (iesg@ietf.org) 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: paws@ietf.org > >>>> 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 > >>>> paws@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/paws > >>>> > >>> _______________________________________________ > >>> paws mailing list > >>> paws@ietf.org > >>> https://www.ietf.org/mailman/listinfo/paws > >> _______________________________________________ > >> paws mailing list > >> paws@ietf.org > >> https://www.ietf.org/mailman/listinfo/paws > > > > > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From fluffy@cisco.com Wed Apr 20 11:23:07 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DA961E073E; Wed, 20 Apr 2011 11:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.585 X-Spam-Level: X-Spam-Status: No, score=-110.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OyrxvdSFUpK; Wed, 20 Apr 2011 11:23:06 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfc.amsl.com (Postfix) with ESMTP id 1B556E0732; Wed, 20 Apr 2011 11:23:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=6676; q=dns/txt; s=iport; t=1303323784; x=1304533384; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=cKWdl2kHU2VpnLzKGXA0YOivG8TR6L1jmr/qqaZYrbI=; b=L7EX/3xDU9IhWbHFzGX45TeGG40lYliI1q0Z4Vh5H1p6RaIdcUkNmHPH gr11XtroipU52Dn74kneulu6/1kGFZGKoTIYyqU+bOvEhyd8Hnm/Bq5FA 6Sy48kxo4EGy46uKpjauYuJHrT/KY1HAOWj0+JXW1xPMh+Ev/CxOf/LLD Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkgBAG8jr02rRDoJ/2dsb2JhbACXM44Kd4hvojmcdoJ/AYJxBIV0iC6Df4of X-IronPort-AV: E=Sophos;i="4.64,247,1301875200"; d="scan'208";a="298657412" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 20 Apr 2011 18:23:03 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3KIN2A6012654; Wed, 20 Apr 2011 18:23:02 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4DADCB52.1020309@joelhalpern.com> Date: Wed, 20 Apr 2011 12:23:01 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <76B1A6A1-F704-45F3-9A82-C590308C60F7@cisco.com> References: <20110419165634.CD24CE07CF@ietfc.amsl.com> <4DADCB52.1020309@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Wed, 20 Apr 2011 17:21:47 -0700 Cc: paws@ietf.org, IETF discussion list Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 18:23:08 -0000 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.=20 Cullen On Apr 19, 2011, at 11:50 AM, Joel M. Halpern wrote: > 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. >=20 > Yours, > Joel M. Halpern >=20 > 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 (iesg@ietf.org) by Tuesday, April 26, 2011. >>=20 >>=20 >> Protocol to Access White Space database (paws) >> ------------------------------------------------ >> Current Status: Proposed Working Group >> Last updated: 2011-04-14 >>=20 >> Chairs: >> TBD >>=20 >> Area Directors: >> TBD >>=20 >> Area Advisor: >> TBD >>=20 >> Mailing lists: >> Address: paws@ietf.org >> To Subscribe: https://www.ietf.org/mailman/listinfo/paws >> Archive: http://www.ietf.org/mail-archive/web/paws/ >>=20 >> Description of Working Group: >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> Goals and Milestones >>=20 >> Sep 2011 Submit 'Requirements and Framework' to the IESG for >> publication as Informational >>=20 >> Apr 2012 Submit 'Protocol for Querying a Whitespace Database' to >> the IESG for publication as Proposed Standard >>=20 >> Apr 2012 Submit 'Data Model for Whitespace query protocol' to the >> IESG for publication as Proposed Standard >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >>=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From ietfdbh@comcast.net Wed Apr 20 16:18:57 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1FBA5E0783 for ; Wed, 20 Apr 2011 16:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jMO5fRKJSuQQ for ; Wed, 20 Apr 2011 16:18:55 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by ietfc.amsl.com (Postfix) with ESMTP id AF904E0721 for ; Wed, 20 Apr 2011 16:18:55 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta15.westchester.pa.mail.comcast.net with comcast id Zyfq1g0071swQuc5FzJwcu; Wed, 20 Apr 2011 23:18:56 +0000 Received: from davidPC ([67.189.235.106]) by omta15.westchester.pa.mail.comcast.net with comcast id ZzJu1g01q2JQnJT3bzJvoY; Wed, 20 Apr 2011 23:18:55 +0000 From: "David Harrington" To: , , References: <20110419165634.CD24CE07CF@ietfc.amsl.com> In-Reply-To: Date: Wed, 20 Apr 2011 19:18:43 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.1.7600.16776 Thread-index: AQHL/rLAHraUh0DINEKp8P50E+1g05RlJLaAgAIrV+A= X-Mailman-Approved-At: Wed, 20 Apr 2011 17:21:48 -0700 Cc: paws@ietf.org Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 23:18:57 -0000 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 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. 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 ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On > Behalf Of Basavaraj.Patil@nokia.com > Sent: Tuesday, April 19, 2011 3:55 PM > To: iesg@ietf.org; ietf-announce@ietf.org > Cc: paws@ietf.org > 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" > 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 (iesg@ietf.org) 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: paws@ietf.org > >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 > >paws@ietf.org > >https://www.ietf.org/mailman/listinfo/paws > > From Basavaraj.Patil@nokia.com Wed Apr 20 21:00:45 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9474DE077E; Wed, 20 Apr 2011 21:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6la+4XXyfvVO; Wed, 20 Apr 2011 21:00:44 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfc.amsl.com (Postfix) with ESMTP id D36B5E06DB; Wed, 20 Apr 2011 21:00:43 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p3L40Vt4005977; Thu, 21 Apr 2011 07:00:41 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Apr 2011 06:59:03 +0300 Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 21 Apr 2011 05:58:30 +0200 Received: from 008-AM1MPN1-025.mgdnok.nokia.com ([169.254.5.134]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0289.008; Thu, 21 Apr 2011 05:58:29 +0200 From: To: , , Thread-Topic: [paws] WG Review: Protocol to Access White Space database (paws) Thread-Index: AQHL/rLAHraUh0DINEKp8P50E+1g05RlJLaAgAIrV+D//zxv8A== Date: Thu, 21 Apr 2011 03:58:29 +0000 Message-ID: <21E7D9BD69CC7241AAE00F4EA183B7190245AD@008-AM1MPN1-025.mgdnok.nokia.com> References: <20110419165634.CD24CE07CF@ietfc.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AKKZ A0xj BUkH HwGj J4fs LVWD L60a MD0s N2tw QCx5 TxKu ZWGu bib9 dovJ fzx1 rFld; 4; aQBlAHMAZwBAAGkAZQB0AGYALgBvAHIAZwA7AGkAZQB0AGYALQBhAG4AbgBvAHUAbgBjAGUAQABpAGUAdABmAC4AbwByAGcAOwBpAGUAdABmAGQAYgBoAEAAYwBvAG0AYwBhAHMAdAAuAG4AZQB0ADsAcABhAHcAcwBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {F917F929-09B7-4052-BC25-096B28372594}; YgBhAHMAYQB2AGEAcgBhAGoALgBwAGEAdABpAGwAQABuAG8AawBpAGEALgBjAG8AbQA=; Wed, 20 Apr 2011 10:30:39 GMT; UgBFADoAIABbAHAAYQB3AHMAXQAgAFcARwAgAFIAZQB2AGkAZQB3ADoAIABQAHIAbwB0AG8AYwBvAGwAIAB0AG8AIABBAGMAYwBlAHMAcwAgAFcAaABpAHQAZQAgAFMAcABhAGMAZQAgAGQAYQB0AGEAYgBhAHMAZQAgACgAcABhAHcAcwApAA== x-cr-puzzleid: {F917F929-09B7-4052-BC25-096B28372594} x-originating-ip: [173.64.197.89] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 21 Apr 2011 03:59:03.0878 (UTC) FILETIME=[74435660:01CBFFD8] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 04:00:45 -0000 I really don't understand the premises for your comments. Did you attend th= e PAWS BoF? Have you read the I-Ds? I am amazed at your response and questioning whethe= r 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 dat= abases. There are other SDOs such as IEEE defining the Phy/MAC for example and ther= e are regulatory bodies defining how spectrum is used in the context of cog= nitive radio technologies. But that does not imply the IETF has no role her= e. 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 pro= blem 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 hav= e wider experience of WS technology and understanding resulting from partic= ipation and involvement in other forums and SDOs. Rgds, -Basavaraj -----Original Message----- From: ext David Harrington [mailto:ietfdbh@comcast.net]=20 Sent: Wednesday, April 20, 2011 6:19 PM To: Patil Basavaraj (Nokia-CTO/Dallas); iesg@ietf.org; ietf-announce@ietf.o= rg Cc: paws@ietf.org Subject: RE: [paws] WG Review: Protocol to Access White Space database (paw= s) 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 regulatory agencies: > >The Working Group will set up and maintain appropriate contact and > >liaison with other relevant standards bodies and groups,=20 > 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. 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 ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On=20 > Behalf Of Basavaraj.Patil@nokia.com > Sent: Tuesday, April 19, 2011 3:55 PM > To: iesg@ietf.org; ietf-announce@ietf.org > Cc: paws@ietf.org > Subject: Re: [paws] WG Review: Protocol to Access White Space=20 > database (paws) >=20 >=20 > 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. >=20 > -Basavaraj >=20 > On 4/19/11 11:56 AM, "ext IESG Secretary"=20 > wrote: >=20 > >A new IETF working group has been proposed. The IESG has=20 > not made any > >determination as yet. The following draft charter was=20 > submitted, and is > >provided for informational purposes only. Please send your=20 > comments to the > >IESG mailing list (iesg@ietf.org) by Tuesday, April 26, 2011. > > =20 > > > >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: paws@ietf.org > >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=20 > 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=20 > user(s) may > >not be using the entire band allocated to them. The=20 > available spectrum > >for a secondary use would then depend on the location of the=20 > 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=20 > for secondary > >use. One simple mechanism is to use a geospatial database=20 > that records > >protected contours for primary users, and require the=20 > 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=20 > 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=20 > 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=20 > a list of > >unoccupied channels based on certain conditions, e.g. a=20 > 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=20 > regulations may vary, > >but the fundamental operation of the protocol should be country > >independent, thus extensibility of data structures will be=20 > required. The > >solution will not be tied to any specific spectrum, country, or > >phy/mac/air interface but may incorporate relevant aspects=20 > 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,=20 > modification > >of channel enablement information, impersonation of=20 > 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,=20 > 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 > >paws@ietf.org > >https://www.ietf.org/mailman/listinfo/paws >=20 >=20 From acooper@cdt.org Thu Apr 21 04:01:50 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6648AE06C8; Thu, 21 Apr 2011 04:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YdklWDG9tmjt; Thu, 21 Apr 2011 04:01:49 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfc.amsl.com (Postfix) with ESMTP id 34E1DE06CD; Thu, 21 Apr 2011 04:01:49 -0700 (PDT) Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Thu, 21 Apr 2011 07:01:29 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Alissa Cooper In-Reply-To: <88BE24FD9280884487DEAE0CE1FD3A5B060F1B@008-AM1MPN1-023.mgdnok.nokia.com> Date: Thu, 21 Apr 2011 12:01:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110419165634.CD24CE07CF@ietfc.amsl.com> <4DADFE6D.3050107@cs.tcd.ie> <88BE24FD9280884487DEAE0CE1FD3A5B060F1B@008-AM1MPN1-023.mgdnok.nokia.com> To: X-Mailer: Apple Mail (2.1084) Cc: paws@ietf.org, iesg@ietf.org, ietf@ietf.org, stephen.farrell@cs.tcd.ie Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 11:01:50 -0000 On Apr 20, 2011, at 3:41 PM, = wrote: > Hi Stephen, All, >=20 > I believe the current wording >>> Robust security mechanisms are required to prevent: >>> device identity spoofing, modification of device requests, = modification >>> 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). >=20 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:=20 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 > 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. >=20 > Regards, > Scott >=20 > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of ext Stephen Farrell > Sent: Tuesday, April 19, 2011 4:28 PM > To: IETF-Discussion > Cc: paws@ietf.org; iesg@ietf.org > Subject: Re: [paws] WG Review: Protocol to Access White Space database = (paws) >=20 >=20 > I think this is a good and timely thing for the IETF to do. >=20 > 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: >=20 > On 19/04/11 17:56, IESG Secretary wrote: >> The protocol must protect both the channel enablement process and the >> privacy of users.=20 >=20 > That part is fine but it goes on to say: >=20 >> Robust security mechanisms are required to prevent: >> device identity spoofing, modification of device requests, = modification >> of channel enablement information, ... >=20 > 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. >=20 > 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;-) >=20 > So my questions: >=20 > Are there may be similar (or conflicting!) requirements > elsewhere? >=20 > Does this bit of the charter text need changes to work > well for other regions? >=20 > 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. >=20 > 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. >=20 > Cheers, > Stephen. >=20 > [1] > = http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=3Decfr&sid=3D3e9c322addf1f= 7e897d8c84a6c7aca78&rgn=3Ddiv8&view=3Dtext&node=3D47:1.0.1.1.14.8.243.9&id= no=3D47 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf >=20 From scott.probasco@nokia.com Thu Apr 21 06:06:14 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8D4BCE0775; Thu, 21 Apr 2011 06:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzDQBNbkpT1f; Thu, 21 Apr 2011 06:06:13 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfc.amsl.com (Postfix) with ESMTP id 46419E076F; Thu, 21 Apr 2011 06:06:13 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p3LD5IIu020071; Thu, 21 Apr 2011 16:05:49 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Apr 2011 16:05:20 +0300 Received: from 008-AM1MMR1-002.mgdnok.nokia.com (65.54.30.57) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 21 Apr 2011 15:05:19 +0200 Received: from 008-AM1MPN1-023.mgdnok.nokia.com ([169.254.3.210]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0289.008; Thu, 21 Apr 2011 15:05:16 +0200 From: To: Thread-Topic: [paws] WG Review: Protocol to Access White Space database (paws) Thread-Index: AQHL/rLA5Czj0i0wfE+ujEk1m1AO2ZRlknOAgAE/lXCAATXygIAAQm6A Date: Thu, 21 Apr 2011 13:05:15 +0000 Message-ID: <88BE24FD9280884487DEAE0CE1FD3A5B06182F@008-AM1MPN1-023.mgdnok.nokia.com> References: <20110419165634.CD24CE07CF@ietfc.amsl.com> <4DADFE6D.3050107@cs.tcd.ie> <88BE24FD9280884487DEAE0CE1FD3A5B060F1B@008-AM1MPN1-023.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-version: 3.2.55 x-tituslabs-classifications-30: TLPropertyRoot=Trial License;Classification=Personal; x-putclassificationandsendinfointox-header: Classification: Personal Project: Subject: RE: [paws] WG Review: Protocol to Access White Space database (paws) Sender Name: Probasco Scott (Nokia-CIC/Dallas) Sender Email: scott.probasco@nokia.com Send Date: Thursday, April 21, 2011 Send Time: 8:05:10 AM x-originating-ip: [10.243.2.236] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 21 Apr 2011 13:05:20.0115 (UTC) FILETIME=[C46C3430:01CC0024] X-Nokia-AV: Clean Cc: paws@ietf.org, iesg@ietf.org, ietf@ietf.org, stephen.farrell@cs.tcd.ie Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 13:06:14 -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 includi= ng or using in PAWS the security tools developed by appropriate expert grou= ps. "Inclusion of robust security mechanisms is required:..." ?? Regards, Scott -----Original Message----- From: ext Alissa Cooper [mailto:acooper@cdt.org]=20 Sent: Thursday, April 21, 2011 6:01 AM To: Probasco Scott (Nokia-CIC/Dallas) Cc: stephen.farrell@cs.tcd.ie; ietf@ietf.org; paws@ietf.org; iesg@ietf.org Subject: Re: [paws] WG Review: Protocol to Access White Space database (paw= s) On Apr 20, 2011, at 3:41 PM, wrote: > Hi Stephen, All, >=20 > I believe the current wording >>> Robust security mechanisms are required to prevent: >>> device identity spoofing, modification of device requests, modification >>> of channel enablement information, ... > is acceptable because "mechanisms are required" means they should be in t= he protocol, it does not mean they cannot be optional. PAWS should support = Regulator requirements globally, and thus I believe there will be procedure= s or capabilities which are "required" to be in the protocol but will be "o= ptional" during run time. Thus different or conflicting requirements from d= ifferent regions of the world can be supported. (Several regulatory groups = around the world are still developing their views and requirements). >=20 Agreed on this point, although I think the charter could make it a little l= ess ambiguous by saying "Development of robust security mechanisms is requi= red . . .," that way it's not indicating that the actual mechanisms themsel= ves 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:=20 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 ide= ntity. Alissa > 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 G= roup to get started defining the details. >=20 > Regards, > Scott >=20 > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of e= xt Stephen Farrell > Sent: Tuesday, April 19, 2011 4:28 PM > To: IETF-Discussion > Cc: paws@ietf.org; iesg@ietf.org > Subject: Re: [paws] WG Review: Protocol to Access White Space database (p= aws) >=20 >=20 > I think this is a good and timely thing for the IETF to do. >=20 > 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: >=20 > On 19/04/11 17:56, IESG Secretary wrote: >> The protocol must protect both the channel enablement process and the >> privacy of users.=20 >=20 > That part is fine but it goes on to say: >=20 >> Robust security mechanisms are required to prevent: >> device identity spoofing, modification of device requests, modification >> of channel enablement information, ... >=20 > 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. >=20 > 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;-) >=20 > So my questions: >=20 > Are there may be similar (or conflicting!) requirements > elsewhere? >=20 > Does this bit of the charter text need changes to work > well for other regions? >=20 > 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. >=20 > 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. >=20 > Cheers, > Stephen. >=20 > [1] > http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=3Decfr&sid=3D3e9c322addf1= f7e897d8c84a6c7aca78&rgn=3Ddiv8&view=3Dtext&node=3D47:1.0.1.1.14.8.243.9&id= no=3D47 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf >=20 From hannes.tschofenig@gmx.net Thu Apr 21 00:36:14 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 42577E074A for ; Thu, 21 Apr 2011 00:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.254 X-Spam-Level: X-Spam-Status: No, score=-102.254 tagged_above=-999 required=5 tests=[AWL=0.345, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvGDbtBu0IIx for ; Thu, 21 Apr 2011 00:36:12 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfc.amsl.com (Postfix) with SMTP id D445DE0741 for ; Thu, 21 Apr 2011 00:36:11 -0700 (PDT) Received: (qmail invoked by alias); 21 Apr 2011 07:36:09 -0000 Received: from unknown (EHLO [10.255.138.232]) [192.100.123.77] by mail.gmx.net (mp057) with SMTP; 21 Apr 2011 09:36:09 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/27LR9HIT21N78JQKdZYOwgpKiejTMrV68rwadSg 1Evly+elEEfC9n Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Thu, 21 Apr 2011 10:36:04 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <7798A906-6513-4777-8A56-351D7D5A5EE3@gmx.net> References: <20110419165634.CD24CE07CF@ietfc.amsl.com> To: "David Harrington" X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 X-Mailman-Approved-At: Thu, 21 Apr 2011 08:00:03 -0700 Cc: paws@ietf.org, Hannes Tschofenig , The IESG , IETF Announcement list Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 07:36:14 -0000 Hi David,=20 let me share my thoughts with you; see inline:=20 On Apr 21, 2011, at 2:18 AM, David Harrington wrote: > Hi, >=20 > I question whether IETF is the appropriate forum for this work. > The IETF certainly has protocol-development expertise, especially for > interoperability. >=20 > 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. >=20 > 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. >=20 > 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.=20 This is conceptually very similar to finding out what emergency services = are available in a given location.=20 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?=20 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.=20 In fact, the entire IETF security work is highly relevant for the "cyber = security" debates happening everywhere in the world.=20 (If you do a s/cyber security/Internet security then this relationship = is more obvious.) >=20 > 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,=20 >> 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. >=20 > 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.=20 In fact, this is done frequently.=20 Just to give you a few example:=20 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:=20 " 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.=20 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.=20 As SDOs came along we started interacting with them. If you look at the = ECRIT charter text you will find the following paragraph:=20 " 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.=20 The last one of these workshops actually happened last week in Budapest = with 250 people attending! =20 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.=20 I still believe it is important to be explicit about this interaction.=20= > 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.=20 The IAB has liaisons shepherds appointed with the IEEE already.=20 We maintain a good relationship with the IEEE and this interaction, I = believe, will be smooth.=20 =20 >=20 > 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.=20 > 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.=20 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. =20 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.=20 > 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. >=20 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).=20 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).=20 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.=20 So, what could be the worst case that this group produces?=20 - A protocol that does not work?=20 - Does not consider all requirements and then cannot be used?=20 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.=20 Ciao Hannes > David Harrington > Director, IETF Transport Area > ietfdbh@comcast.net (preferred for ietf) > dbharrington@huaweisymantec.com > +1 603 828 1401 (cell) >=20 >=20 >> -----Original Message----- >> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On=20 >> Behalf Of Basavaraj.Patil@nokia.com >> Sent: Tuesday, April 19, 2011 3:55 PM >> To: iesg@ietf.org; ietf-announce@ietf.org >> Cc: paws@ietf.org >> Subject: Re: [paws] WG Review: Protocol to Access White Space=20 >> database (paws) >>=20 >>=20 >> 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. >>=20 >> -Basavaraj >>=20 >> On 4/19/11 11:56 AM, "ext IESG Secretary"=20 >> wrote: >>=20 >>> A new IETF working group has been proposed. The IESG has=20 >> not made any >>> determination as yet. The following draft charter was=20 >> submitted, and is >>> provided for informational purposes only. Please send your=20 >> comments to the >>> IESG mailing list (iesg@ietf.org) by Tuesday, April 26, 2011. >>>=20 >>>=20 >>> Protocol to Access White Space database (paws) >>> ------------------------------------------------ >>> Current Status: Proposed Working Group >>> Last updated: 2011-04-14 >>>=20 >>> Chairs: >>> TBD >>>=20 >>> Area Directors: >>> TBD >>>=20 >>> Area Advisor: >>> TBD >>>=20 >>> Mailing lists: >>> Address: paws@ietf.org >>> To Subscribe: https://www.ietf.org/mailman/listinfo/paws >>> Archive: http://www.ietf.org/mail-archive/web/paws/ >>>=20 >>> Description of Working Group: >>>=20 >>> Governments around the world continue to search for new=20 >> 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=20 >> user(s) may >>> not be using the entire band allocated to them. The=20 >> available spectrum >>> for a secondary use would then depend on the location of the=20 >> 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=20 >> for secondary >>> use. One simple mechanism is to use a geospatial database=20 >> that records >>> protected contours for primary users, and require the=20 >> 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. >>>=20 >>> 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=20 >> 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=20 >> 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=20 >> a list of >>> unoccupied channels based on certain conditions, e.g. a=20 >> fixed amount of >>> time has passed or the device has changed location beyond a > specified >>> threshold. >>>=20 >>> 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=20 >> regulations may vary, >>> but the fundamental operation of the protocol should be country >>> independent, thus extensibility of data structures will be=20 >> required. The >>> solution will not be tied to any specific spectrum, country, or >>> phy/mac/air interface but may incorporate relevant aspects=20 >> of these as >>> needed for proper operation. >>>=20 >>> 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. >>>=20 >>> 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,=20 >> modification >>> of channel enablement information, impersonation of=20 >> registered database >>> services and unauthorized disclosure of a users location. >>>=20 >>> 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. >>>=20 >>> The Working Group will set up and maintain appropriate contact and >>> liaison with other relevant standards bodies and groups,=20 >> 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. >>>=20 >>> Goals and Milestones >>>=20 >>> Sep 2011 Submit 'Requirements and Framework' to the IESG for >>> publication as Informational >>>=20 >>> Apr 2012 Submit 'Protocol for Querying a Whitespace Database' to >>> the IESG for publication as Proposed Standard >>>=20 >>> Apr 2012 Submit 'Data Model for Whitespace query protocol' to the >>> IESG for publication as Proposed Standard >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >>=20 >>=20 >=20 From paul@marvell.com Thu Apr 21 11:34:15 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 50927E0804; Thu, 21 Apr 2011 11:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIbJA+eKLCrU; Thu, 21 Apr 2011 11:34:13 -0700 (PDT) Received: from na3sys009aog112.obsmtp.com (na3sys009aog112.obsmtp.com [74.125.149.207]) by ietfc.amsl.com (Postfix) with ESMTP id 101CAE07AF; Thu, 21 Apr 2011 11:34:12 -0700 (PDT) Received: from sc-owa02.marvell.com ([65.219.4.130]) (using TLSv1) by na3sys009aob112.postini.com ([74.125.148.12]) with SMTP ID DSNKTbB4n2JoXP6ndahcu+75Awo22l6jASCA@postini.com; Thu, 21 Apr 2011 11:34:13 PDT Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa02.marvell.com ([10.93.76.22]) with mapi; Thu, 21 Apr 2011 11:33:05 -0700 From: Paul Lambert To: David Harrington , "Basavaraj.Patil@nokia.com" , "iesg@ietf.org" , "ietf-announce@ietf.org" Date: Thu, 21 Apr 2011 11:33:04 -0700 Thread-Topic: [paws] WG Review: Protocol to Access White Space database (paws) Thread-Index: AQHL/rLAHraUh0DINEKp8P50E+1g05RlJLaAgAIrV+CAAVPz8A== Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01406AC5B97@SC-VEXCH2.marvell.com> References: <20110419165634.CD24CE07CF@ietfc.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 18:34:15 -0000 > 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. The IETF is an appropriate forum for the development of protocols for the d= escribed charter. We must work to ensure that devices using spectrum can b= e 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 spectr= um:=20 - PAWS provides protocols for determining a devices spectral rights within= a regulatory domain=20 - Regulatory domains run the databases with PAWS interface that distribute= and control these rights (effectively the content provider) > 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. Country specific policies and procedures do NOT need to be defined by the w= orking group - only identified. Manufactures will still have the burden to= build devices that are compliant with regulations. We just need to provid= e the means to determine the named policies and associated available spectr= um. =20 Paul Paul A. Lambert | Marvell | +1 650 787 9141 > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of > David Harrington > Sent: Wednesday, April 20, 2011 4:19 PM > To: Basavaraj.Patil@nokia.com; iesg@ietf.org; ietf-announce@ietf.org > Cc: paws@ietf.org > Subject: Re: [paws] WG Review: Protocol to Access White Space database > (paws) >=20 > Hi, >=20 > I question whether IETF is the appropriate forum for this work. > The IETF certainly has protocol-development expertise, especially for > interoperability. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > David Harrington > Director, IETF Transport Area > ietfdbh@comcast.net (preferred for ietf) > dbharrington@huaweisymantec.com > +1 603 828 1401 (cell) >=20 >=20 > > -----Original Message----- > > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On > > Behalf Of Basavaraj.Patil@nokia.com > > Sent: Tuesday, April 19, 2011 3:55 PM > > To: iesg@ietf.org; ietf-announce@ietf.org > > Cc: paws@ietf.org > > 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" > > 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 (iesg@ietf.org) 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: paws@ietf.org > > >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 > > >paws@ietf.org > > >https://www.ietf.org/mailman/listinfo/paws > > > > >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From stephen.farrell@cs.tcd.ie Fri Apr 22 05:35:26 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 56429E06C8; Fri, 22 Apr 2011 05:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZRNS3oeqCtz; Fri, 22 Apr 2011 05:35:25 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfc.amsl.com (Postfix) with ESMTP id 80D84E068A; Fri, 22 Apr 2011 05:35:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 55F15171C5F; Fri, 22 Apr 2011 13:35:23 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1303475723; bh=tE6x0cazKF6ecr XgAarj3oR2+434jKbsghOd2GkvaVQ=; b=LYTbG0u7M0VyTNUKA9BfC2J0OlgtX7 PXKPTvKhTfsy1FAaDzuUep5dauN3Ehf8j5YAUy5b2eKj4uRxeFm3EA9qWDSeW9CW FxKonbsHghKByIDJCltTbZ6XkOJ1CZd83HIP2oPVxiwXXAnISeP7vJ4VtT8CxiDT MtdeTr0/YNPcR9eLAFdJpnKU7eiw+lFe0lKt9ZBCse8KCSqwktu1ggiOIx7ck/td MSAGF9F+GakupiJBK58x+aLqk6hZZjkHZagl0tFfY46+xYM/Hr8fqxY9AAZuyH1S Y/AxyG3iRybKYJw9B7e4x85daQEbOkqI79gha6YkierBfS4/seyjsADg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id vHv3ERBmcyEH; Fri, 22 Apr 2011 13:35:23 +0100 (IST) Received: from [10.87.48.10] (unknown [86.44.75.91]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id F3816171C5B; Fri, 22 Apr 2011 13:35:19 +0100 (IST) Message-ID: <4DB17604.4000806@cs.tcd.ie> Date: Fri, 22 Apr 2011 13:35:16 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Paul Lambert References: <20110419165634.CD24CE07CF@ietfc.amsl.com> <7BAC95F5A7E67643AAFB2C31BEE662D01406AC5B97@SC-VEXCH2.marvell.com> In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D01406AC5B97@SC-VEXCH2.marvell.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "paws@ietf.org" , David Harrington , "iesg@ietf.org" , "ietf-announce@ietf.org" Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 12:35:26 -0000 On 21/04/11 19:33, Paul Lambert wrote: > 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) 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@inf-net.nl Fri Apr 22 05:53:37 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6CA9CE067C; Fri, 22 Apr 2011 05:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDGn-ay14bOr; Fri, 22 Apr 2011 05:53:36 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfc.amsl.com (Postfix) with ESMTP id 6DE05E0664; Fri, 22 Apr 2011 05:53:35 -0700 (PDT) Received: by wyb29 with SMTP id 29so480096wyb.31 for ; Fri, 22 Apr 2011 05:53:35 -0700 (PDT) Received: by 10.227.29.30 with SMTP id o30mr1076655wbc.185.1303476815102; Fri, 22 Apr 2011 05:53:35 -0700 (PDT) Received: from [192.168.2.150] (ip56530916.direct-adsl.nl [86.83.9.22]) by mx.google.com with ESMTPS id b20sm1735338wbb.33.2011.04.22.05.53.33 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Apr 2011 05:53:34 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <4DB17604.4000806@cs.tcd.ie> Date: Fri, 22 Apr 2011 14:53:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110419165634.CD24CE07CF@ietfc.amsl.com> <7BAC95F5A7E67643AAFB2C31BEE662D01406AC5B97@SC-VEXCH2.marvell.com> <4DB17604.4000806@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1084) Cc: "paws@ietf.org" , David Harrington , "iesg@ietf.org" , "ietf-announce@ietf.org" Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 12:53:37 -0000 The protocol may provide the knob for an authority to limit usage. For sure IETF is not the authority. It *en*ables spectrum users=20 and authorized bodies to make smart usage of possibilities. It helps to make the Internet work better. Thanks, Teco Op 22 apr 2011, om 14:35 heeft Stephen Farrell het volgende geschreven: >=20 >=20 > On 21/04/11 19:33, Paul Lambert wrote: >> One could view these protocols as Digital Right Management (DRM) for = spectrum:=20 >> - PAWS provides protocols for determining a devices spectral rights = within a regulatory domain=20 >> - Regulatory domains run the databases with PAWS interface that = distribute and control these rights >> (effectively the content provider) >=20 > DRM? Yuk. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > I had assumed we were talking about the latter, and hope this > was just a bad analogy but can we confirm that? >=20 > S. >=20 >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From stephen.farrell@cs.tcd.ie Fri Apr 22 06:14:25 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9E8D7E071B; Fri, 22 Apr 2011 06:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aU7Uh2fI3Hg1; Fri, 22 Apr 2011 06:14:24 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfc.amsl.com (Postfix) with ESMTP id 07487E06FD; Fri, 22 Apr 2011 06:14:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 7CBE315F525; Fri, 22 Apr 2011 14:14:23 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1303478063; bh=e51kQTuwT2+Jkb Y5UEOod3e76HlN2MynlYR7r/a7wcI=; b=5aOAnsSimKSOk3SsB2LnrrqFu3baAM HJTdg1WC1JlGph8tjqlLEggVrPZVIC+T7tezkyoWQIl2VOO3pZb2BXN8/tdyzOd/ 6chm8kuS9zrRLwvpVGg4B1kapBiWzlQK8Rg5/B3Vpr6WmxxR6zsQUfQIve/hx/dk 5mnK3bmN5+/OvjG7H98vqH+74pH+XxLNmO5N6PfqaV/UgP1fjY7HBGczCQidFOmp smdw2viSUIdG7cfdByxAAbJ5kOFQLGrWXk7OVOXcqa6+GFmg6dmye60u+S8Xj/k4 iXv0hbCOieQs4VpY9jzHG/Meli4tuGV04/k1aZofzdT4HD7EtfNzC/0g== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id I-pAxslZFHaH; Fri, 22 Apr 2011 14:14:23 +0100 (IST) Received: from [10.87.48.10] (unknown [86.44.75.91]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 17874171C5B; Fri, 22 Apr 2011 14:14:21 +0100 (IST) Message-ID: <4DB17F2B.9090002@cs.tcd.ie> Date: Fri, 22 Apr 2011 14:14:19 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Teco Boot References: <20110419165634.CD24CE07CF@ietfc.amsl.com> <7BAC95F5A7E67643AAFB2C31BEE662D01406AC5B97@SC-VEXCH2.marvell.com> <4DB17604.4000806@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "paws@ietf.org" , David Harrington , "iesg@ietf.org" , "ietf-announce@ietf.org" Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 13:14:25 -0000 On 22/04/11 13:53, Teco Boot wrote: > 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. > 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 > > Op 22 apr 2011, om 14:35 heeft Stephen Farrell het volgende geschreven: > >> >> >> On 21/04/11 19:33, Paul Lambert wrote: >>> 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) >> >> 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. >> >> >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws > From brian.rosen@neustar.biz Fri Apr 22 06:59:11 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 158F0E0674; Fri, 22 Apr 2011 06:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLf1PkauRHER; Fri, 22 Apr 2011 06:59:10 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfc.amsl.com (Postfix) with ESMTP id 2254DE06AB; Fri, 22 Apr 2011 06:59:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1303480743; x=1618839958; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=c5zBT1Ix/B4gkPsQjU+Gt js1oOwk5f6ETNkxi89kVdU=; b=p1ggR59ePLq7ldTtOOEt07QkuREI1M6FVj+jO A7vrZedFKNKUSNfXPvx03w3whm06StSuMyNAGe0mDh43ZA+EQ== Received: from ([10.31.13.229]) by stihiron2.va.neustar.com with ESMTP with TLS id 5202732.44325616; Fri, 22 Apr 2011 09:59:02 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Fri, 22 Apr 2011 09:59:02 -0400 From: "Rosen, Brian" To: Stephen Farrell Date: Fri, 22 Apr 2011 09:58:59 -0400 Thread-Topic: [paws] WG Review: Protocol to Access White Space database (paws) Thread-Index: AcwA9W7jSN/sUgfaSxy2xoOWv1ScXw== Message-ID: References: <20110419165634.CD24CE07CF@ietfc.amsl.com> <7BAC95F5A7E67643AAFB2C31BEE662D01406AC5B97@SC-VEXCH2.marvell.com> <4DB17604.4000806@cs.tcd.ie> In-Reply-To: <4DB17604.4000806@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: /jd+HJMGPSihInjDj22IQQ== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" , David Harrington , "iesg@ietf.org" , "ietf-announce@ietf.org" Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 13:59:11 -0000 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 the= ir use, i.e. non interfering. While the algorithm the server uses to deter= mine the available spectrum is regulator-specified, the protocol used to ge= t the available spectrum is not. That's the part paws is working on. There is no right, it's just avoiding interference. Brian On Apr 22, 2011, at 8:35 AM, Stephen Farrell wrote: >=20 >=20 > On 21/04/11 19:33, Paul Lambert wrote: >> One could view these protocols as Digital Right Management (DRM) for spe= ctrum:=20 >> - PAWS provides protocols for determining a devices spectral rights with= in a regulatory domain=20 >> - Regulatory domains run the databases with PAWS interface that distribu= te and control these rights >> (effectively the content provider) >=20 > DRM? Yuk. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > I had assumed we were talking about the latter, and hope this > was just a bad analogy but can we confirm that? >=20 > S. >=20 >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From scott.probasco@nokia.com Fri Apr 22 07:02:22 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C71C5E07E6; Fri, 22 Apr 2011 07:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBgnCg6G7OEU; Fri, 22 Apr 2011 07:02:22 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfc.amsl.com (Postfix) with ESMTP id C65B9E0674; Fri, 22 Apr 2011 07:02:21 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p3ME1PlK001362; Fri, 22 Apr 2011 17:02:16 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Apr 2011 17:02:00 +0300 Received: from 008-AM1MMR1-003.mgdnok.nokia.com (65.54.30.58) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 22 Apr 2011 16:02:00 +0200 Received: from 008-AM1MPN1-021.mgdnok.nokia.com ([169.254.1.188]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.01.0289.008; Fri, 22 Apr 2011 16:02:00 +0200 From: To: , Thread-Topic: [paws] WG Review: Protocol to Access White Space database (paws) Thread-Index: AQHL/rLA5Czj0i0wfE+ujEk1m1AO2ZRleIqAgAHLHYCAAUKGAIABLl0AgAAFGgCAAAXPgIAALDRw Date: Fri, 22 Apr 2011 14:01:59 +0000 Message-ID: <88BE24FD9280884487DEAE0CE1FD3A5B0313565D@008-AM1MPN1-021.mgdnok.nokia.com> References: <20110419165634.CD24CE07CF@ietfc.amsl.com> <7BAC95F5A7E67643AAFB2C31BEE662D01406AC5B97@SC-VEXCH2.marvell.com> <4DB17604.4000806@cs.tcd.ie> <4DB17F2B.9090002@cs.tcd.ie> In-Reply-To: <4DB17F2B.9090002@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-version: 3.2.55 x-tituslabs-classifications-30: TLPropertyRoot=Trial License;Classification=Personal; x-putclassificationandsendinfointox-header: Classification: Personal Project: Subject: RE: [paws] WG Review: Protocol to Access White Space database (paws) Sender Name: Probasco Scott (Nokia-CIC/Dallas) Sender Email: scott.probasco@nokia.com Send Date: Friday, April 22, 2011 Send Time: 9:01:57 AM x-originating-ip: [172.19.60.23] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 22 Apr 2011 14:02:00.0749 (UTC) FILETIME=[D9C585D0:01CC00F5] X-Nokia-AV: Clean Cc: paws@ietf.org, ietfdbh@comcast.net, iesg@ietf.org, ietf-announce@ietf.org Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 14:02:22 -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 Re= gulator. PAWS is simply a tool to enable a standardized means for devices t= o interact with a database.=20 Enforcement does not enter into the PAWS picture. Local Regulators make the= rules, compliant devices (i.e. the device which include the radio transmit= ter) 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: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= Stephen Farrell Sent: Friday, April 22, 2011 8:14 AM To: Teco Boot Cc: paws@ietf.org; David Harrington; iesg@ietf.org; ietf-announce@ietf.org Subject: Re: [paws] WG Review: Protocol to Access White Space database (paw= s) On 22/04/11 13:53, Teco Boot wrote: > 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. > For sure IETF is not the authority. It *en*ables spectrum users=20 > and authorized bodies to make smart usage of possibilities. It helps > to make the Internet work better. >=20 > Thanks, Teco >=20 > Op 22 apr 2011, om 14:35 heeft Stephen Farrell het volgende geschreven: >=20 >> >> >> On 21/04/11 19:33, Paul Lambert wrote: >>> One could view these protocols as Digital Right Management (DRM) for sp= ectrum:=20 >>> - PAWS provides protocols for determining a devices spectral rights wit= hin a regulatory domain=20 >>> - Regulatory domains run the databases with PAWS interface that distrib= ute and control these rights >>> (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. >> >> >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >=20 _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From teco@inf-net.nl Fri Apr 22 07:03:23 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E06F6E0735; Fri, 22 Apr 2011 07:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3t+FYBzeldDI; Fri, 22 Apr 2011 07:03:23 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfc.amsl.com (Postfix) with ESMTP id C80BFE067C; Fri, 22 Apr 2011 07:03:22 -0700 (PDT) Received: by wyb29 with SMTP id 29so515080wyb.31 for ; Fri, 22 Apr 2011 07:03:22 -0700 (PDT) Received: by 10.216.121.201 with SMTP id r51mr1137777weh.56.1303481001227; Fri, 22 Apr 2011 07:03:21 -0700 (PDT) Received: from [192.168.2.150] (ip56530916.direct-adsl.nl [86.83.9.22]) by mx.google.com with ESMTPS id m2sm1412057wer.37.2011.04.22.07.03.16 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Apr 2011 07:03:17 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <4DB17F2B.9090002@cs.tcd.ie> Date: Fri, 22 Apr 2011 16:03:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <42ADFDD5-4F51-4AE5-914E-848FD81F0573@inf-net.nl> References: <20110419165634.CD24CE07CF@ietfc.amsl.com> <7BAC95F5A7E67643AAFB2C31BEE662D01406AC5B97@SC-VEXCH2.marvell.com> <4DB17604.4000806@cs.tcd.ie> <4DB17F2B.9090002@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1084) Cc: "paws@ietf.org" , David Harrington , "iesg@ietf.org" , "ietf-announce@ietf.org" Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 14:03:24 -0000 Op 22 apr 2011, om 15:14 heeft Stephen Farrell het volgende geschreven: > On 22/04/11 13:53, Teco Boot wrote: >> The protocol may provide the knob for an authority to limit usage. >=20 > 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? The protocol provides some way to tell what frequency can be used on a=20= particular location. 700MHz could not be listed.=20 >=20 > 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. Correct. Teco >=20 > S. >=20 >> For sure IETF is not the authority. It *en*ables spectrum users=20 >> and authorized bodies to make smart usage of possibilities. It helps >> to make the Internet work better. >>=20 >> Thanks, Teco >>=20 >> Op 22 apr 2011, om 14:35 heeft Stephen Farrell het volgende = geschreven: >>=20 >>>=20 >>>=20 >>> On 21/04/11 19:33, Paul Lambert wrote: >>>> One could view these protocols as Digital Right Management (DRM) = for spectrum:=20 >>>> - PAWS provides protocols for determining a devices spectral rights = within a regulatory domain=20 >>>> - Regulatory domains run the databases with PAWS interface that = distribute and control these rights >>>> (effectively the content provider) >>>=20 >>> DRM? Yuk. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> I had assumed we were talking about the latter, and hope this >>> was just a bad analogy but can we confirm that? >>>=20 >>> S. >>>=20 >>>=20 >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >>=20 From gwz@net-zen.net Thu Apr 21 18:42:14 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A6B02E0719 for ; Thu, 21 Apr 2011 18:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7MP745hr6-hZ for ; Thu, 21 Apr 2011 18:42:14 -0700 (PDT) Received: from smtpauth21.prod.mesa1.secureserver.net (smtpauth21.prod.mesa1.secureserver.net [64.202.165.38]) by ietfc.amsl.com (Postfix) with SMTP id 38DA8E06E2 for ; Thu, 21 Apr 2011 18:42:13 -0700 (PDT) Received: (qmail 23221 invoked from network); 22 Apr 2011 01:35:33 -0000 Received: from unknown (124.120.98.54) by smtpauth21.prod.mesa1.secureserver.net (64.202.165.38) with ESMTP; 22 Apr 2011 01:35:32 -0000 Message-ID: <4DB0DB5F.8020806@net-zen.net> Date: Fri, 22 Apr 2011 08:35:27 +0700 From: Glen Zorn Organization: Network Zen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: scott.probasco@nokia.com References: <20110419165634.CD24CE07CF@ietfc.amsl.com> <4DADFE6D.3050107@cs.tcd.ie> <88BE24FD9280884487DEAE0CE1FD3A5B060F1B@008-AM1MPN1-023.mgdnok.nokia.com> <88BE24FD9280884487DEAE0CE1FD3A5B06182F@008-AM1MPN1-023.mgdnok.nokia.com> In-Reply-To: <88BE24FD9280884487DEAE0CE1FD3A5B06182F@008-AM1MPN1-023.mgdnok.nokia.com> X-Enigmail-Version: 1.1.1 Content-Type: multipart/mixed; boundary="------------050405030501010207010101" X-Mailman-Approved-At: Fri, 22 Apr 2011 08:20:24 -0700 Cc: paws@ietf.org, iesg@ietf.org, ietf@ietf.org Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 01:42:14 -0000 This is a multi-part message in MIME format. --------------050405030501010207010101 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 4/21/2011 8:05 PM, scott.probasco@nokia.com wrote: > 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. > I agree. > "Inclusion of robust security mechanisms is required:..." > ?? > > Regards, > Scott > > > > -----Original Message----- > From: ext Alissa Cooper [mailto:acooper@cdt.org] > Sent: Thursday, April 21, 2011 6:01 AM > To: Probasco Scott (Nokia-CIC/Dallas) > Cc: stephen.farrell@cs.tcd.ie; ietf@ietf.org; paws@ietf.org; iesg@ietf.org > Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) > > On Apr 20, 2011, at 3:41 PM, wrote: > >> Hi Stephen, All, >> >> I believe the current wording >>>> Robust security mechanisms are required to prevent: >>>> device identity spoofing, modification of device requests, modification >>>> 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). >> > > 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 > >> 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: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Stephen Farrell >> Sent: Tuesday, April 19, 2011 4:28 PM >> To: IETF-Discussion >> Cc: paws@ietf.org; iesg@ietf.org >> Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) >> >> >> 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: >>> The protocol must protect both the channel enablement process and the >>> privacy of users. >> >> That part is fine but it goes on to say: >> >>> Robust security mechanisms are required to prevent: >>> device identity spoofing, modification of device requests, modification >>> 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 >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf >> > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > > --------------050405030501010207010101 Content-Type: text/x-vcard; charset=utf-8; name="gwz.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gwz.vcf" begin:vcard fn:Glen Zorn n:Zorn;Glen org:Network Zen adr:;;;Seattle;WA;;USA email;internet:gwz@net-zen.net tel;cell:+66 87 040 4617 note:PGP Key Fingerprint: DAD3 F5D3 ACE6 4195 9C5C 2EE1 6E17 B5F6 5953 B45F version:2.1 end:vcard --------------050405030501010207010101-- From paul@marvell.com Fri Apr 22 10:51:10 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 316CBE0691; Fri, 22 Apr 2011 10:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4h50koxFJeU; Fri, 22 Apr 2011 10:51:09 -0700 (PDT) Received: from na3sys009aog101.obsmtp.com (na3sys009aog101.obsmtp.com [74.125.149.67]) by ietfc.amsl.com (Postfix) with ESMTP id 20199E0611; Fri, 22 Apr 2011 10:51:07 -0700 (PDT) Received: from SC-OWA01.marvell.com ([65.219.4.129]) (using TLSv1) by na3sys009aob101.postini.com ([74.125.148.12]) with SMTP ID DSNKTbHAAlI/npfPdKW3ebaeLHlQ5XDTdhYa@postini.com; Fri, 22 Apr 2011 10:51:09 PDT Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Fri, 22 Apr 2011 10:48:24 -0700 From: Paul Lambert To: "scott.probasco@nokia.com" , "stephen.farrell@cs.tcd.ie" , "teco@inf-net.nl" Date: Fri, 22 Apr 2011 10:48:25 -0700 Thread-Topic: [paws] WG Review: Protocol to Access White Space database (paws) Thread-Index: AQHL/rLA5Czj0i0wfE+ujEk1m1AO2ZRleIqAgAHLHYCAAUKGAIABLl0AgAAFGgCAAAXPgIAALDRwgAA+hTA= Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01406B72980@SC-VEXCH2.marvell.com> References: <20110419165634.CD24CE07CF@ietfc.amsl.com> <7BAC95F5A7E67643AAFB2C31BEE662D01406AC5B97@SC-VEXCH2.marvell.com> <4DB17604.4000806@cs.tcd.ie> <4DB17F2B.9090002@cs.tcd.ie> <88BE24FD9280884487DEAE0CE1FD3A5B0313565D@008-AM1MPN1-021.mgdnok.nokia.com> In-Reply-To: <88BE24FD9280884487DEAE0CE1FD3A5B0313565D@008-AM1MPN1-021.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" , "ietfdbh@comcast.net" , "iesg@ietf.org" , "ietf-announce@ietf.org" Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 17:51:10 -0000 > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of > scott.probasco@nokia.com ... >=20 > Hi, >=20 > 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. >=20 > 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. >=20 > 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 c= ase TVWS) and are issues a registered model type and have a unique associated seri= al number. The regulatory authorities=20 2) The databases provide a specific named device with "available spectrum"= =20 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. =20 Paul >=20 > Regards, > Scott >=20 >=20 > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of > ext Stephen Farrell > Sent: Friday, April 22, 2011 8:14 AM > To: Teco Boot > Cc: paws@ietf.org; David Harrington; iesg@ietf.org; ietf- > announce@ietf.org > Subject: Re: [paws] WG Review: Protocol to Access White Space database > (paws) >=20 >=20 >=20 > On 22/04/11 13:53, Teco Boot wrote: > > The protocol may provide the knob for an authority to limit usage. >=20 > 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? >=20 > 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. >=20 > S. >=20 > > 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 > > > > Op 22 apr 2011, om 14:35 heeft Stephen Farrell het volgende > geschreven: > > > >> > >> > >> On 21/04/11 19:33, Paul Lambert wrote: > >>> 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) > >> > >> 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. > >> > >> > >> _______________________________________________ > >> paws mailing list > >> paws@ietf.org > >> https://www.ietf.org/mailman/listinfo/paws > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From richard@shockey.us Fri Apr 22 12:29:06 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 77C90E0848 for ; Fri, 22 Apr 2011 12:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.432 X-Spam-Level: X-Spam-Status: No, score=-102.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rw82nVfD2lmd for ; Fri, 22 Apr 2011 12:29:05 -0700 (PDT) Received: from oproxy1-pub.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by ietfc.amsl.com (Postfix) with SMTP id 53A92E0816 for ; Fri, 22 Apr 2011 12:29:05 -0700 (PDT) Received: (qmail 23254 invoked by uid 0); 22 Apr 2011 19:29:04 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by cpoproxy1.bluehost.com with SMTP; 22 Apr 2011 19:29:04 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=AA3qjIakd1mLXk6bBPqJQIiWmB+ZawPJxud8/1el14sVZF2gQhn4t7M8JCmPWuHTEY+fUzB1+pB2ITqYdkP8duEMRh9Hw7+iaCGXxCrfFWHlToluU+Xz4zD0++h34pQV; Received: from pool-71-178-24-118.washdc.fios.verizon.net ([71.178.24.118] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1QDM2K-0004ES-7U; Fri, 22 Apr 2011 13:29:04 -0600 From: "Richard Shockey" To: "'Paul Lambert'" , , , References: <20110419165634.CD24CE07CF@ietfc.amsl.com> <7BAC95F5A7E67643AAFB2C31BEE662D01406AC5B97@SC-VEXCH2.marvell.com> <4DB17604.4000806@cs.tcd.ie> <4DB17F2B.9090002@cs.tcd.ie> <88BE24FD9280884487DEAE0CE1FD3A5B0313565D@008-AM1MPN1-021.mgdnok.nokia.com> <7BAC95F5A7E67643AAFB2C31BEE662D01406B72980@SC-VEXCH2.marvell.com> In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D01406B72980@SC-VEXCH2.marvell.com> Date: Fri, 22 Apr 2011 15:29:03 -0400 Message-ID: <001f01cc0123$8b153dd0$a13fb970$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHL/rLA5Czj0i0wfE+ujEk1m1AO2ZRleIqAgAHLHYCAAUKGAIABLl0AgAAFGgCAAAXPgIAALDRwgAA+hTCAAB4nUA== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.178.24.118 authed with richard@shockey.us} Cc: paws@ietf.org, ietfdbh@comcast.net, iesg@ietf.org, ietf-announce@ietf.org Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 19:29:06 -0000 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. > > 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 From richard@shockey.us Fri Apr 22 12:32:28 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E0929E0869 for ; Fri, 22 Apr 2011 12:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.32 X-Spam-Level: X-Spam-Status: No, score=-102.32 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yge1daLAbpGV for ; Fri, 22 Apr 2011 12:32:28 -0700 (PDT) Received: from oproxy4-pub.bluehost.com (oproxy4-pub.bluehost.com [69.89.21.11]) by ietfc.amsl.com (Postfix) with SMTP id 3AF6BE0855 for ; Fri, 22 Apr 2011 12:32:25 -0700 (PDT) Received: (qmail 22716 invoked by uid 0); 22 Apr 2011 19:32:24 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by cpoproxy1.bluehost.com with SMTP; 22 Apr 2011 19:32:24 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=iYbaiIziOlirqIIt9+hkvxJwc1R8F/zq4a/sMJQvOpwabbFvWBfmJPp5A/PsVTejkd6+f53o24PLBf6vjd8ZAmZK10DLHgZM8gseu53FXlvvHRl5nCAxr9XqaHjnt4qL; Received: from pool-71-178-24-118.washdc.fios.verizon.net ([71.178.24.118] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1QDM5Y-0006WM-35 for paws@ietf.org; Fri, 22 Apr 2011 13:32:24 -0600 From: "Richard Shockey" To: Date: Fri, 22 Apr 2011 15:32:24 -0400 Message-ID: <002001cc0124$0237e610$06a7b230$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01CC0102.7B264610" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcwBJAGKH0jImkIASCis2uz0Rbzo6Q== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.178.24.118 authed with richard@shockey.us} Subject: [paws] FYI FCC web page on Whitespaces X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 19:32:29 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0021_01CC0102.7B264610 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Including presentations made at the Workshops this week. http://www.fcc.gov/oet/whitespace/ Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 < mailto:richard(at)shockey.us> skype-linkedin-facebook: rshockey101 http//www.sipforum.org ------=_NextPart_000_0021_01CC0102.7B264610 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Including = presentations made at the Workshops this week.

 

http://www.fcc.gov/oet/whitespace/

 

Richard = Shockey
Shockey Consulting
Chairman of the Board of Directors SIP = Forum
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us>
skype= -linkedin-facebook: rshockey101
http//www.sipforum.org

 

------=_NextPart_000_0021_01CC0102.7B264610-- From paul@marvell.com Fri Apr 22 14:56:51 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7896DE06C0; Fri, 22 Apr 2011 14:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.979 X-Spam-Level: X-Spam-Status: No, score=-5.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gt0Kn97yIZtW; Fri, 22 Apr 2011 14:56:50 -0700 (PDT) Received: from na3sys009aog103.obsmtp.com (na3sys009aog103.obsmtp.com [74.125.149.71]) by ietfc.amsl.com (Postfix) with ESMTP id 28323E0613; Fri, 22 Apr 2011 14:56:50 -0700 (PDT) Received: from SC-OWA01.marvell.com ([65.219.4.129]) (using TLSv1) by na3sys009aob103.postini.com ([74.125.148.12]) with SMTP ID DSNKTbH5mlHHUur4HebqfpRI9e/fCri1bsPq@postini.com; Fri, 22 Apr 2011 14:56:50 PDT Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Fri, 22 Apr 2011 14:54:08 -0700 From: Paul Lambert To: Stephen Farrell Date: Fri, 22 Apr 2011 14:56:38 -0700 Thread-Topic: [paws] WG Review: Protocol to Access White Space database (paws) Thread-Index: AcwA6WXNM9x+s4jNRYuP2i1Bv5sahgATM+Hw Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01406B729EB@SC-VEXCH2.marvell.com> References: <20110419165634.CD24CE07CF@ietfc.amsl.com> <7BAC95F5A7E67643AAFB2C31BEE662D01406AC5B97@SC-VEXCH2.marvell.com> <4DB17604.4000806@cs.tcd.ie> In-Reply-To: <4DB17604.4000806@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" , David Harrington , "iesg@ietf.org" , "ietf-announce@ietf.org" Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 21:56:51 -0000 I also dislike the DRM comparison .. but introduced because it is appropria= te for our problem domain. The regulatory authorities "own" the spectrum a= nd 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 cha= nnel set in a particular manner (power, modulation) in a particular region. PAWS and geolocation databases for spectral allocation are "enabling" becau= se they provide additional licenses to use spectrum beyond just the incumbe= nts (e.g. TV broadcasting). More licenses and usage are a good thing ... b= ut are still regulatory authority controlled. =20 Paul > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Friday, April 22, 2011 5:35 AM > To: Paul Lambert > Cc: David Harrington; Basavaraj.Patil@nokia.com; iesg@ietf.org; ietf- > announce@ietf.org; paws@ietf.org > Subject: Re: [paws] WG Review: Protocol to Access White Space database > (paws) >=20 >=20 >=20 > On 21/04/11 19:33, Paul Lambert wrote: > > 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) >=20 > DRM? Yuk. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > I had assumed we were talking about the latter, and hope this > was just a bad analogy but can we confirm that? >=20 > S. >=20 From paul@marvell.com Fri Apr 22 17:42:05 2011 Return-Path: X-Original-To: paws@ietfc.amsl.com Delivered-To: paws@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BC1EDE0694; Fri, 22 Apr 2011 17:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.53 X-Spam-Level: X-Spam-Status: No, score=-6.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zOkWqbp-Nlpc; Fri, 22 Apr 2011 17:42:05 -0700 (PDT) Received: from na3sys009aog108.obsmtp.com (na3sys009aog108.obsmtp.com [74.125.149.199]) by ietfc.amsl.com (Postfix) with ESMTP id E6546E066B; Fri, 22 Apr 2011 17:42:03 -0700 (PDT) Received: from sc-owa02.marvell.com ([65.219.4.130]) (using TLSv1) by na3sys009aob108.postini.com ([74.125.148.12]) with SMTP ID DSNKTbIgVvp3C9d4AossPwUPwz2Uqq/6MRNh@postini.com; Fri, 22 Apr 2011 17:42:04 PDT Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa02.marvell.com ([10.93.76.22]) with mapi; Fri, 22 Apr 2011 17:41:58 -0700 From: Paul Lambert To: "Rosen, Brian" , Stephen Farrell Date: Fri, 22 Apr 2011 17:41:56 -0700 Thread-Topic: [paws] WG Review: Protocol to Access White Space database (paws) Thread-Index: AcwA9W7jSN/sUgfaSxy2xoOWv1ScXwAWVJ9g Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01406B72A54@SC-VEXCH2.marvell.com> References: <20110419165634.CD24CE07CF@ietfc.amsl.com> <7BAC95F5A7E67643AAFB2C31BEE662D01406AC5B97@SC-VEXCH2.marvell.com> <4DB17604.4000806@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" , David Harrington , "iesg@ietf.org" , "ietf-announce@ietf.org" Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2011 00:42:05 -0000 >> 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 > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > Sent: Friday, April 22, 2011 6:59 AM > To: Stephen Farrell > Cc: Paul Lambert; paws@ietf.org; David Harrington; iesg@ietf.org; ietf- > announce@ietf.org > Subject: Re: [paws] WG Review: Protocol to Access White Space database > (paws) >=20 > Going off the deep end folks. >=20 > 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. >=20 > There is no right, it's just avoiding interference. >=20 > Brian >=20 >=20 > On Apr 22, 2011, at 8:35 AM, Stephen Farrell wrote: >=20 > > > > > > On 21/04/11 19:33, Paul Lambert wrote: > >> 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) > > > > 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. > > > > > > _______________________________________________ > > paws mailing list > > paws@ietf.org > > https://www.ietf.org/mailman/listinfo/paws From dromasca@avaya.com Thu Apr 28 10:57:46 2011 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBBC7E06AF for ; Thu, 28 Apr 2011 10:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.137 X-Spam-Level: X-Spam-Status: No, score=-103.137 tagged_above=-999 required=5 tests=[AWL=0.462, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhTqqvjcvnXO for ; Thu, 28 Apr 2011 10:57:46 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id BD2B6E0689 for ; Thu, 28 Apr 2011 10:57:45 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At8HAMqpuU3GmAcF/2dsb2JhbACYUY0yd6YVg1gCmkyFdgSTDIlb X-IronPort-AV: E=Sophos;i="4.64,282,1301889600"; d="scan'208";a="243866672" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 28 Apr 2011 13:57:44 -0400 X-IronPort-AV: E=Sophos;i="4.64,282,1301889600"; d="scan'208";a="614016741" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 28 Apr 2011 13:57:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Apr 2011 19:57:38 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Decision on PAWS WG deferred Thread-Index: AcwFzcL10U70eTlyTauGSI28RdoaPQ== From: "Romascanu, Dan (Dan)" To: Subject: [paws] Decision on PAWS WG deferred X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 17:57:47 -0000 Hi,=20 Several AD's could not make the IESG telechat today. The IESG decided to discuss the WG approval in more detail during the IESG retreat session next week (May 2nd and 3rd) and than validate the decision (if there will be a decision by then) at the telechat scheduled for 5/12.=20 =20 Regards, Dan=20